[aerogear-dev] Unified Push Server user management questions

[Hylke Bons]

Hello,

I've updated the wireframes with the points raised, you can find it 
here: 
https://raw.github.com/hbons/aerogear-design/master/aerogear_unified_push_server_admin_ui.png

I'll address your feedback inline.

On 06/06/2013 01:38, Deepali Khushraj wrote:
> * 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.
>
I forgot a to add this usecase. This can now be done in the "Variants" tab.

> * Apple's Push network has prod and dev environment options, a flag 
> would be useful.
>

Two certificate files can now be provided: one for production and one 
for development. Any of the two can be used by mobile apps whether 
they're deployed or for debugging purposes.

> * 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've changed this to "Mobile Instances" for now, but we can discuss this.


> * I found the name "Variants and Push Networks" confusing. I would 
> suggest we use one :)
>

Push Networks it is.

> * 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 think this is something we need to fix on the aerogear.org website 
itself. There should be easy access from the downloads to the API as a 
"next step".


> * 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.
>
Like mentioned by Matthias, this can be anything, not just email 
addressses. It depends on how the developer sets the system up.

> * 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.
>
It can be a long list and we probably will have to add pagination and 
filtering. The main usecase here is removing instances to stop them from 
receiving new push notifications.

> * Is the check-mark in first screen used to make an app active Vs 
> inactive?
>

It was to to select applications and perform actions on them. I already 
thought this would be confusing, so I removed them now. An app is active 
when it has at least one push network enabled.


> * I like that you show the variants summary in first screen, wondering 
> if we could use icons there for iOS, Android & web.

Yep, potentially.

>
> * 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.
>
>
Yes, I've added some paragraphs to make things more friendlier, but 
there's room for improvement. We can fix this as we go.

Thanks for the feedback. It's been really useful!

Hylke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130617/6729c637/attachment.html