2:40 p.m.
On Jun 26, 2013, at 3:38 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Wednesday, June 26, 2013, Lucas Holmquist wrote:
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.
i was looking at this again and a question popped into my head. Doesn't each variant
need there own certificate/google key.
So, for example, we have an "HR App", this app has 3 variants
1. free version
2. paid version
3. some other really cool version
i'm assuming that should be 3 different certs/keys ( for development, another set for
prod ). i'm not sure the wireframes represent this correctly
yes. the spec is indicating that!
Does the UI lead to confusion?
In it's current wireframe form yes.
But with this confirmation. we should be good going forward
>
>> * 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
> _______________________________________________
> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev