Re: [aerogear-dev] Unified Push Server user management questions

I agree with Kris about Ember. We already made some tests/apps with angular and backbone. We should also chose a "presentation framework", my suggestion for this would be topcoat (as we already played a bit with the others) On Mon, Jun 24, 2013 at 6:01 PM, Kris Borchers <kris(a)redhat.com <mailto:kris@redhat.com>> wrote: I would personally love to see us dive into Ember here but am happy to hear what others on the team think. I think it's a good opportunity to see what is different and show our stuff working with yet another JS framework since it doesn't seem like any single one is winning at the moment. On Jun 24, 2013, at 10:59 AM, Lucas Holmquist <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: > So i'm going to use this thread to discuss if we have a > requirement for what framework to use for the Admin UI console thing > > Here are some choices, but not an exhaustive list: > > Ember > Backbone > Angular > Just Straight up HTML/JS/CSS > Other Buzz Words > > Since this is going to be part of the Push server( installed in > an App server ) and not a quick start or showcase app, do we need > to adhere to a specific framework? > > > On Jun 21, 2013, at 12:25 PM, Matthias Wessendorf > <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > >> >> >> >> On Fri, Jun 21, 2013 at 5:38 PM, Deepali Khushraj >> <dkhushra(a)redhat.com <mailto:dkhushra@redhat.com>> wrote: >> >> >> On Jun 21, 2013, at 11:23 AM, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> >>> >>> >>> >>> On Fri, Jun 21, 2013 at 5:16 PM, Deepali Khushraj >>> <dkhushra(a)redhat.com <mailto:dkhushra@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 ? >> >> Your approach sounds reasonable. Perhaps just a line in the >> spec, explicitly stating this, could be useful. >> >> Do you plan to allow the user to configure both dev and prod >> certificates of APNS for a single iOS variant? >> >> >> >> yes. And I think Hylke's wireframes already indicate that >> >> >>> >>> >>> -Matthias >>> >>> >>> >>> D. >>> >>> On Jun 17, 2013, at 8:19 AM, Hylke Bons >>> <hbons(a)redhat.com <mailto:hbons@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 <http://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 >>>> <mailto:aerogear-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> <mailto:aerogear-dev@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 >>> <mailto:aerogear-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> <mailto:aerogear-dev@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 <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@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