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