Re: [aerogear-dev] First go at stats/activity wireframes

On May 21, 2014, at 4:24 PM, Matthias Wessendorf <matzew@apache.org<javascript:_e(%7B%7D,'cvml','matzew@apache.org');>> wrote: On Wed, May 21, 2014 at 9:55 PM, Burr Sutter <bsutter@redhat.com<javascript:_e(%7B%7D,'cvml','bsutter@redhat.com');> > wrote: > > On May 21, 2014, at 3:43 PM, Matthias Wessendorf <matzew@apache.org<javascript:_e(%7B%7D,'cvml','matzew@apache.org');>> > wrote: > > BTW. on the top box (first screen), I am querying the DB per user: > - "my" applications (the active is worthless) > > OK - so the "5" in the wireframe would be the "Total of My Apps"? > yes > - notifications delivered by "my" apps > > Yes, that makes sense > > - devices registered with "my" apps > > > And when did we add the concept of "my" apps, I thought there was only > "super-user" who sees all apps. > we had that already on the 'agenda' for the initial user-management - but we skipped our own impl. due to Keycloak adpotion; A recent thread: http://lists.jboss.org/pipermail/aerogear-dev/2014-May/007783.html In here I describe a 'super-user' and a 'PushAdmin': http://lists.jboss.org/pipermail/aerogear-dev/2014-May/007784.html Or do you think a 'shared' super-user is good enough? IMO it would be odd if HR Manager and Marketing Manager would be seeing each others apps; I was thinking that the HR Manager & Marketing Manager would not be "push admins" - they would not know how to upload the pubkey from Apple. I like the idea of having a PushAdmin per app - so that they only break their own apps. But it would still likely be an IT person who pays the $99 and sets everything up. Feel free to chime in on that related thread https://raw.githubusercontent.com/hbons/aerogear-design/master/Unified%20... It would be odd if I see how many apps are on the entire server etc ;-) On Wed, May 21, 2014 at 8:41 PM, Burr Sutter <bsutter(a)redhat.com&gt; wrote: On May 21, 2014, at 12:19 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > Hey, > > The "Status" column only show errors. If there are none it will say > something amongst the lines of "Everything is fine". I guess what threw me off was that the Status box links to the Activity page - at least based on how I read that orange arrow connecting the two. > > About the graphic: Sure, it's just the wireframe and may still change in > the visual design depending on what looks good. > > Thanks, > > Hylke > > On 19/05/2014 16:48, Matt Carrano wrote: >> Hey Hylke, >> >> This is looking good. I had a few minor comments/questions about the layout and labeling. Take a look at the marked up wireframe (attached). >> >> -Matt >> >> ----- Original Message ----- >> From: "Hylke Bons" <hbons(a)redhat.com&gt; >> To: aerogear-dev(a)lists.jboss.org >> Cc: "Matt Carrano" <mcarrano(a)redhat.com&gt; >> Sent: Monday, May 19, 2014 8:03:13 AM >> Subject: Re: [aerogear-dev] First go at stats/activity wireframes >> >> Hello, >> >> Here are some updates based on the feedback from the meetings: >> https://raw.githubusercontent.com/hbons/aerogear-design/master/Unified%20... >> - Simplified dashboard stats >> - Apps notifications table >> - Defined entry points >> >> Let me know what you think. I hope that covers everything. >> >> Thanks, >> >> Hylke >> >> >> >> On 15/05/2014 16:19, Hylke Bons wrote: >>> Hey, >>> >>> Here's an initial version: >>> https://raw.githubusercontent.com/hbons/aerogear-design/master/Unified%20... >>> >>> I tried to incorporate most wishes expressed in the other thread. >>> >>> Most notable things: >>> - Landing page with an overview of stats, most active apps, and error >>> messages >>> - Activity table shows both registration and notification events >>> - Activity table is per variant, and not all activity on the server. >>> Unless there's a usecase to have every event for every app/variant in a >>> table I don't think we actually need it. The important thing is to get >>> to error messages easily. >>> >>> Things to do/think about: >>> - links/entry