Sorry I am chiming in late.I like the mock-ups. A few comments:* It seems from the designs that the user can add only a single OS-specific variant per app. For example, I can create "Mobile HR" app with a single "HR iOS" variant, but not two variants like "HR iPad" and "HR iPhone free". I believe Matthias' lexicon states such multiple variants are possible per app. .
I think the way you've done is fine. However, if we choose this path then, I think, we need to update the specification and ensure the REST API won't allow multiple OS-specific variants per app, otherwise, they can't be shown in the UI.
* Apple's Push network has prod and dev environment options, a flag would be useful.
* The terms "Instance" and "Variant" will be unfamiliar terminologies to a new user. A help icon on the screen or just some text explaining the meanings of these terms to new comers would be helpful* Terminology suggestion:Instance -> "Active user instances" or just "User instances"
* I found the name "Variants and Push Networks" confusing. I would suggest we use one :)
* I noticed you added links to download client SDKs, which is great. I think a link to the Sender REST API spec would be useful too.* I found our iOS tutorial to be really helpful. It got the user up and running really quickly. This is something I struggled with Urban Airship and other services. Linking ours to the console could be a real value add to first-time users
* We need to check the security aspect of showing end-user emails in the instances tab to the developers of the app.
* Also, if an app gets really popular then this list will likely be really long, like thousands of users. Not sure if our console could handle that. I think this feature of being able to see instances is great in "development mode" or during apps' "beta testing" though.
* Is the check-mark in first screen used to make an app active Vs inactive?
* I like that you show the variants summary in first screen, wondering if we could use icons there for iOS, Android & web.* I was wondering if we could consider some UX ideas for first-time user experience. I imagine a lot of users using this service would never have used Push before, so they may need some hand holding and the UI is a great way to start that.I am compiling a list of future use cases, will share that on the list next.What you have is already very nice.Thanks!Deepali.
On Jun 4, 2013, at 11:26 AM, Hylke Bons <hbons@redhat.com> wrote:Hi,
It seems that most of us are happy with the wireframes for the Unified
Push Server admin UI. I've used the feedback to make a few small
changes:
https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui.png
The next step is to look at the the missing features like the user
management and authentication. It would be good to have a discussion
about this, and I have some questions too.
If I understand things correctly, the Push Server can run "standalone"
or as a component in JBoss AS (or something else). So we'll need a UI
for user management when we run standalone, but one that can be disabled
and be plugged in by different existing auth systems that are running on
the server or somewhere else.
Some questions that come to mind:
How is the server bootstrapped? And how is the initial user account
configured? The most essential basic role would be to access the UI and
to configure push notifications (and one to add other (admin) users).
Are there any other roles that we should be considering? Things that
should be disabled for some users?
Thanks,
Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev