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