* 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
_______________________________________________