On Fri, Jun 21, 2013 at 5:16 PM, Deepali Khushraj <dkhushra(a)redhat.com>wrote:
Just saw this email. The updates look good.
Matthias, also one question to you: can a single variant have multiple
push networks (APNS, GCM etc) associated with it? All the examples in the
spec have only a single push network associated with a "variant", so that
part was not clear.
The idea is:
PushApp: Overall mobile App (e.g. "AeroGear Sports News").
Variant: A _variation_ of this (for a specific target). "AeroGear Sports
News for iOS", "AeroGear Sports News for Android" or "AeroGear Sports
News
for Web".
Now... with a bit more "fine tuning" (e.g. the the user/company wants to be
fancy and offer specific apps (to the app-store) for iPhone/iPad or Android
Tablets/Phones"), these following "variants" could exist for the
"AeroGear
Sports News" Push Application:
* "AeroGear Sports News for iPhone"
* "AeroGear Sports News for iPad"
* "AeroGear Sports News for iPad mini"
* "AeroGear Sports News for Android-Table"
* "AeroGear Sports News for Google-Glasses"
Since a variant targets a specific platform, there is no real sense in
having the one variant supporting different PushNetworks. thins like that
are group under a PushApplication (as explained above).
Does that make sense? Do you feel I need to be more clear on that in the
spec ?
-Matthias
D.
On Jun 17, 2013, at 8:19 AM, Hylke Bons <hbons(a)redhat.com> wrote:
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...
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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf