Hi, It seems that most of us are happy with the wireframes for the Unified Push Server admin UI. I've used the feedback to make a few small changes: https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_pus...

The next step is to look at the the missing features like the user management and authentication. It would be good to have a discussion about this, and I have some questions too. If I understand things correctly, the Push Server can run "standalone" or as a component in JBoss AS (or something else).

So we'll need a UI for user management when we run standalone, but one that can be disabled and be plugged in by different existing auth systems that are running on the server or somewhere else.

Some questions that come to mind: How is the server bootstrapped? And how is the initial user account configured?

The most essential basic role would be to access the UI and to configure push notifications (and one to add other (admin) users). Are there any other roles that we should be considering? Things that should be disabled for some users?

Thanks, Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 04/06/2013 16:36, Matthias Wessendorf wrote: How is the server bootstrapped? And how is the initial user account > configured? I thought about initially storing a developer user "Admin:Admin" user in the database. Users are asked to modify (or even delete) that. We could ask to create a user and password on the first run when you visit the console? Would be a bit nicer I think (and probably safer as well?).

Do we need things in place like resetting the password and sending password reminders? In that case we'll need to know email addresses as well, we might as well use those to log in instead of usernames?

Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi, It seems that most of us are happy with the wireframes for the Unified Push Server admin UI. I've used the feedback to make a few small changes: https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_pus... The next step is to look at the the missing features like the user management and authentication. It would be good to have a discussion about this, and I have some questions too. If I understand things correctly, the Push Server can run "standalone" or as a component in JBoss AS (or something else). So we'll need a UI for user management when we run standalone, but one that can be disabled and be plugged in by different existing auth systems that are running on the server or somewhere else. Some questions that come to mind: How is the server bootstrapped? And how is the initial user account configured? The most essential basic role would be to access the UI and to configure push notifications (and one to add other (admin) users). Are there any other roles that we should be considering? Things that should be disabled for some users? Thanks, Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Thu, Jun 6, 2013 at 2:38 AM, Deepali Khushraj <dkhushra(a)redhat.com&gt;wrote: > Sorry I am chiming in late. > > I like the mock-ups. A few comments: > > * 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. . > yes. HR-iPad, HR-iWatch, HR-Android-watch, HR-Android-Tablet etc > > 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. > see above > > * Apple's Push network has prod and dev environment options, a flag would > be useful. > See https://issues.jboss.org/browse/AGPUSH-88 > > * 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" > "active" implies running ? User instance is better...... basically it's the installation of the actual app > * I found the name "Variants and Push Networks" confusing. I would > suggest we use one :) > Not sure I follow (variant != Push Network) > * 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 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 > "Help" section? Has links to SDK, tutorial etc ?? > > * We need to check the security aspect of showing end-user emails in the > instances tab to the developers of the app. > Well, it can be some other aspect. But .... the developer of company X will be able to query all users for company X... It's not that Manager of company Y sees them.

If you feel this is really important, please open a JIRA > * 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. > Pagination will be there, At least I was expecting that, even if the mockups do not show that. > > * Is the check-mark in first screen used to make an app active Vs > inactive? > He will do that in a later round, Hylke said > > * I like that you show the variants summary in first screen, wondering if > we could use icons there for iOS, Android & web. > > * 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. > > I am compiling a list of future use cases, will share that on the list > next. > > What you have is already very nice. > > Thanks! > Deepali. > > > > > > > > > > > On Jun 4, 2013, at 11:26 AM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > > Hi, > > It seems that most of us are happy with the wireframes for the Unified > Push Server admin UI. I've used the feedback to make a few small > changes: > > https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_pus... > > The next step is to look at the the missing features like the user > management and authentication. It would be good to have a discussion > about this, and I have some questions too. > > If I understand things correctly, the Push Server can run "standalone" > or as a component in JBoss AS (or something else). So we'll need a UI > for user management when we run standalone, but one that can be disabled > and be plugged in by different existing auth systems that are running on > the server or somewhere else. > > Some questions that come to mind: > > How is the server bootstrapped? And how is the initial user account > configured? The most essential basic role would be to access the UI and > to configure push notifications (and one to add other (admin) users). > Are there any other roles that we should be considering? Things that > should be disabled for some users? > > Thanks, > > 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

On Jun 6, 2013, at 1:51 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Thu, Jun 6, 2013 at 2:38 AM, Deepali Khushraj <dkhushra(a)redhat.com&gt;wrote: > Sorry I am chiming in late. > > I like the mock-ups. A few comments: > > * 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. . > yes. HR-iPad, HR-iWatch, HR-Android-watch, HR-Android-Tablet etc Hylke: I didn't hear back to you on this, so asking again. How would the user provide names for these mobile app variants using current designs? I don't see a field to capture this.

Also I think a separate area maybe required to show the user API credentials (app keys/secrets etc.)-- required to start using the PushEE REST API.

> > 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. > see above > > * Apple's Push network has prod and dev environment options, a flag would > be useful. > See https://issues.jboss.org/browse/AGPUSH-88 > > * 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" > "active" implies running ? User instance is better...... basically it's the installation of the actual app > * I found the name "Variants and Push Networks" confusing. I would > suggest we use one :) > Not sure I follow (variant != Push Network) > * 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 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 > "Help" section? Has links to SDK, tutorial etc ?? > > * We need to check the security aspect of showing end-user emails in the > instances tab to the developers of the app. > Well, it can be some other aspect. But .... the developer of company X will be able to query all users for company X... It's not that Manager of company Y sees them. If you feel this is really important, please open a JIRA > * 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. > Pagination will be there, At least I was expecting that, even if the mockups do not show that. > > * Is the check-mark in first screen used to make an app active Vs > inactive? > He will do that in a later round, Hylke said > > * I like that you show the variants summary in first screen, wondering if > we could use icons there for iOS, Android & web. > > * 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. > > I am compiling a list of future use cases, will share that on the list > next. > > What you have is already very nice. > > Thanks! > Deepali. > > > > > > > > > > > On Jun 4, 2013, at 11:26 AM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > > Hi, > > It seems that most of us are happy with the wireframes for the Unified > Push Server admin UI. I've used the feedback to make a few small > changes: > > https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_pus... > > The next step is to look at the the missing features like the user > management and authentication. It would be good to have a discussion > about this, and I have some questions too. > > If I understand things correctly, the Push Server can run "standalone" > or as a component in JBoss AS (or something else). So we'll need a UI > for user management when we run standalone, but one that can be disabled > and be plugged in by different existing auth systems that are running on > the server or somewhere else. > > Some questions that come to mind: > > How is the server bootstrapped? And how is the initial user account > configured? The most essential basic role would be to access the UI and > to configure push notifications (and one to add other (admin) users). > Are there any other roles that we should be considering? Things that > should be disabled for some users? > > Thanks, > > 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 _______________________________________________ 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

On 11/06/2013 19:23, Deepali Khushraj wrote: Hylke: I didn't hear back to you on this, so asking again. How would the user provide names for these mobile app variants using current designs? I don't see a field to capture this. Also I think a separate area maybe required to show the user API credentials (app keys/secrets etc.)-- required to start using the PushEE REST API. Sorry, I'm still updating the mockups with this. I'll respond with in more detail later. I haven't seen anything about "user API credentials" in the spec. Can someone explain what this is?

Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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

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

also, do we need a background image on the login page, or will this be on all pages

On Jun 21, 2013, at 10:38 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > design is looking good. > > Some Comments: > > On the First screen after login( and subsequent detail pages ), i would probably remove the "View Details" button and just make the value in the Name column clickable. Probably makes sense to remove the "Remove" button too and put a "delete" icon or something next to the name of the app > > either that or when a row is clicked, those button(s) appear. More of an implementation detail really > > On Jun 17, 2013, at 8:19 AM, Hylke Bons <hbons(a)redhat.com&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

design is looking good. Some Comments: On the First screen after login( and subsequent detail pages ), i would probably remove the "View Details" button and just make the value in the Name column clickable. Probably makes sense to remove the "Remove" button too and put a "delete" icon or something next to the name of the app either that or when a row is clicked, those button(s) appear. More of an implementation detail really

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 https://lists.jboss.org/mailman/listinfo/aerogear-dev

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.

D. On Jun 17, 2013, at 8:19 AM, Hylke Bons <hbons(a)redhat.com&gt; 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

On Jun 21, 2013, at 11:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Fri, Jun 21, 2013 at 5:16 PM, Deepali Khushraj <dkhushra(a)redhat.com&gt;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?

-Matthias > > D. > > On Jun 17, 2013, at 8:19 AM, Hylke Bons <hbons(a)redhat.com&gt; 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 _______________________________________________ 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

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&gt; wrote: > > > > On Fri, Jun 21, 2013 at 5:38 PM, Deepali Khushraj <dkhushra(a)redhat.com&gt; wrote: > > On Jun 21, 2013, at 11:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Fri, Jun 21, 2013 at 5:16 PM, Deepali Khushraj <dkhushra(a)redhat.com&gt; 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&gt; 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 >> _______________________________________________ >> 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 > _______________________________________________ > 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

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

On Jun 24, 2013, at 2:30 PM, Hylke Bons wrote: > Hey, > > I'd really like to opt for Bootstrap as the base for the presentation/CSS. > It has all the components I need, and I've got experience with theming Bootstrap already. This seems reasonable way to reduce risk for the admin console. Especially if we are going to using a new framework for the non-UI (ember). > > Hylke > > > On 24/06/2013 17:07, Sebastien Blanc wrote: >> 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&gt; 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&gt; 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&gt; wrote: >>> >>>> >>>> >>>> >>>> On Fri, Jun 21, 2013 at 5:38 PM, Deepali Khushraj <dkhushra(a)redhat.com&gt; wrote: >>>> >>>> On Jun 21, 2013, at 11:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Jun 21, 2013 at 5:16 PM, Deepali Khushraj <dkhushra(a)redhat.com&gt; 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&gt; 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 >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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

On Mon, Jul 01, 2013 at 11:06:13AM -0400, Lucas Holmquist wrote: > Just wanted to see what we decided here: > > I believe going with ember has been decided(?), but what about the css framework. > > I know there are some who would like to see us start using topcoat, > but thats up to the team I think we need to get there, not sure if having two new things at the same time is wise :)

-- qmx _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jul 1, 2013, at 11:24, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > On Jul 1, 2013, at 11:58 AM, Douglas Campos <qmx(a)qmx.me&gt; wrote: > >> On Mon, Jul 01, 2013 at 11:06:13AM -0400, Lucas Holmquist wrote: >>> Just wanted to see what we decided here: >>> >>> I believe going with ember has been decided(?), but what about the css framework. >>> >>> I know there are some who would like to see us start using topcoat, >>> but thats up to the team >> I think we need to get there, not sure if having two new things at the >> same time is wise :) > i can agree with that, just wanted to see what the teams thoughts are here My thought is picking up a new CSS framework isn't that hard and work has already started with ember so why not both. Someone's going to have to figure out the appropriate classes in bootstrap if that was used instead so why not use something better? Just my 2 cents.

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

On Jun 17, 2013, at 8:19 AM, Hylke Bons <hbons@redhat.com<javascript:_e({}, 'cvml', &#39;hbons(a)redhat.com&#39;);&gt;&gt; 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

* 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 <javascript:_e({}, 'cvml', &#39;aerogear-dev(a)lists.jboss.org&#39;);&gt; https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jun 26, 2013, at 3:38 PM, Matthias Wessendorf <matzew@apache.org<javascript:_e({}, 'cvml', &#39;matzew(a)apache.org&#39;);&gt;&gt; wrote: On Wednesday, June 26, 2013, Lucas Holmquist wrote: > > On Jun 17, 2013, at 8:19 AM, Hylke Bons <hbons(a)redhat.com&gt; 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

>> 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 > > > I don't see this in the spec. Can you point me to the lines that mention this?

Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 27/06/2013 08:12, Matthias Wessendorf wrote: > See: > https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-... > > Thanks. So what's the use case for this? Why would you not want to not use push networks specified for the main app? Also, how common is this?

Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 28/06/2013 11:52, Matthias Wessendorf wrote: Thanks. So what's the use case for this? Why would you not want to not > use push networks specified for the main app? Also, how common is this? > in apple, every app id (== variant) needs it's OWN certificate. That's why it is modeled that way This only applies to Apple APNs? I'd say if there isn't a technical reason why you'd want to this for the other networks we leave it out for those.

Thanks, Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 28/06/2013 11:58, Matthias Wessendorf wrote: > This only applies to Apple APNs? I'd say if there isn't a technical > reason why you'd want to this for the other networks we leave it out > for those. > > In Google you would use different API keys - in SimplePush it could be > a different cloud provider etc > > > Not sure why this would be a problem I'm just trying to figure out the reasons for it so we can present it in the right way. Still, we would you want to use different settings if the result, getting a message to the client, is the same?

Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I'm not even sure we're talking about the same thing. :) Just to make sure, this is _not_ about the ID/Secret shown in the wireframes for the app and its variants? (the variant ones show up in "tooltips").

Hylke On 28/06/2013 12:09, Matthias Wessendorf wrote: Still, we would you want to use different settings if the result, > getting a message to the client, is the same? > you lost me. Not sure what you are asking :) Are you concerned about the "payload" (message) is represented differently ? If one PushApp has several variants: * HR-iOS-Tablet free * HR-iOS-Tablet paid * HR-iOS-Phone free * HR-Android-Phone paid * HR-Android-Watch free Each has it's OWN cert/key. Still if you send out something like: curl -u "{PushApplicationID}:{MasterSecret}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"key":"value", "alert":"HELLO!"}' http://localhost:8080/ag-push/rest/sender/broadcast the message would be delivered to all clients - regardless of the underlying "PushNetwork" > > Hylke > > _______________________________________________ > 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 listaerogear-dev@lists.jboss.orghttps://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

perhaps a workflow explanation will clear things up a bit i log in to the admin console and the first screen should be where i create a "Push Application", which isn't really an application, but just a grouping name essentially. then under the "Push Applications" details, this is where we actually create the "apps"( or the different variants of the grouping ). Each of these would need there own certificate/googleApiKey.

On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > I'm not even sure we're talking about the same thing. :) > > Just to make sure, this is _not_ about the ID/Secret shown in the > wireframes for the app and its variants? (the variant ones show up in > "tooltips"). > Of course, every variant also has it's own variantID/secret > > > > Hylke > > > On 28/06/2013 12:09, Matthias Wessendorf wrote: > > > > Still, we would you want to use different settings if the result, >> getting a message to the client, is the same? >> > > you lost me. Not sure what you are asking :) > > Are you concerned about the "payload" (message) is represented > differently ? > > If one PushApp has several variants: > * HR-iOS-Tablet free > * HR-iOS-Tablet paid > * HR-iOS-Phone free > * HR-Android-Phone paid > * HR-Android-Watch free > > > Each has it's OWN cert/key. Still if you send out something like: > > curl -u "{PushApplicationID}:{MasterSecret}" > -v -H "Accept: application/json" -H "Content-type: application/json" > -X POST > -d '{"key":"value", "alert":"HELLO!"}' > http://localhost:8080/ag-push/rest/sender/broadcast > > > the message would be delivered to all clients - regardless of the > underlying "PushNetwork" > > > >> >> Hylke >> >> _______________________________________________ >> 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 listaerogear-dev@lists.jboss.orghttps://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 _______________________________________________ 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

Alright, so after a chat with Matthias on IRC about the potential use cases I'm updating the wireframes with the requirement. I'll post an update here soon. Thanks, Hylke On 28/06/2013 12:38, Matthias Wessendorf wrote: > > > > On Fri, Jun 28, 2013 at 1:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > perhaps a workflow explanation will clear things up a bit > > > i log in to the admin console and the first screen should be where i create a "Push Application", which isn't really an application, but just a grouping name essentially. > > then under the "Push Applications" details, this is where we actually create the "apps"( or the different variants of the grouping ). Each of these would need there own certificate/googleApiKey. > > exactly > > > > > > > > > On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: >> I'm not even sure we're talking about the same thing. :) >> >> Just to make sure, this is _not_ about the ID/Secret shown in the wireframes for the app and its variants? (the variant ones show up in "tooltips"). >> >> Of course, every variant also has it's own variantID/secret >> >> >> >> >> Hylke >> >> >> On 28/06/2013 12:09, Matthias Wessendorf wrote: >>> >>> >>> Still, we would you want to use different settings if the result, >>> getting a message to the client, is the same? >>> >>> you lost me. Not sure what you are asking :) >>> >>> Are you concerned about the "payload" (message) is represented differently ? >>> >>> If one PushApp has several variants: >>> * HR-iOS-Tablet free >>> * HR-iOS-Tablet paid >>> * HR-iOS-Phone free >>> * HR-Android-Phone paid >>> * HR-Android-Watch free >>> >>> >>> Each has it's OWN cert/key. Still if you send out something like: >>> >>> curl -u "{PushApplicationID}:{MasterSecret}" >>> -v -H "Accept: application/json" -H "Content-type: application/json" >>> -X POST >>> -d '{"key":"value", "alert":"HELLO!"}' >>> >>> http://localhost:8080/ag-push/rest/sender/broadcast >>> >>> the message would be delivered to all clients - regardless of the underlying "PushNetwork" >>> >>> >>> >>> Hylke >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Jul 1, 2013 at 8:18 PM, Lucas Holmquist <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: HI, just wanted to see if there was any update to those wireframes yet I'd be interested as well :) -Matthias On Jun 28, 2013, at 1:06 PM, Hylke Bons <hbons(a)redhat.com <mailto:hbons@redhat.com>> wrote: > Alright, so after a chat with Matthias on IRC about the potential > use cases I'm updating the wireframes with the requirement. I'll > post an update here soon. > > Thanks, > > Hylke > > > On 28/06/2013 12:38, Matthias Wessendorf wrote: >> >> >> >> On Fri, Jun 28, 2013 at 1:35 PM, Lucas Holmquist >> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: >> >> perhaps a workflow explanation will clear things up a bit >> >> >> i log in to the admin console and the first screen should be >> where i create a "Push Application", which isn't really an >> application, but just a grouping name essentially. >> >> then under the "Push Applications" details, this is where >> we actually create the "apps"( or the different variants of >> the grouping ). Each of these would need there own >> certificate/googleApiKey. >> >> >> exactly >> >> >> >> >> >> >> On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf >> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >> >>> >>> >>> >>> On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons >>> <hbons(a)redhat.com <mailto:hbons@redhat.com>> wrote: >>> >>> I'm not even sure we're talking about the same thing. :) >>> >>> Just to make sure, this is _not_ about the ID/Secret >>> shown in the wireframes for the app and its variants? >>> (the variant ones show up in "tooltips"). >>> >>> >>> Of course, every variant also has it's own variantID/secret >>> >>> >>> >>> >>> Hylke >>> >>> >>> On 28/06/2013 12:09, Matthias Wessendorf wrote: >>>> >>>> >>>> Still, we would you want to use different settings >>>> if the result, >>>> getting a message to the client, is the same? >>>> >>>> >>>> you lost me. Not sure what you are asking :) >>>> >>>> Are you concerned about the "payload" (message) is >>>> represented differently ? >>>> >>>> If one PushApp has several variants: >>>> * HR-iOS-Tablet free >>>> * HR-iOS-Tablet paid >>>> * HR-iOS-Phone free >>>> * HR-Android-Phone paid >>>> * HR-Android-Watch free >>>> >>>> >>>> Each has it's OWN cert/key. Still if you send out >>>> something like: >>>> >>>> |curl -u "{PushApplicationID}:{MasterSecret}" >>>> -v -H "Accept: application/json" -H "Content-type: application/json" >>>> -X POST >>>> -d '{"key":"value", "alert":"HELLO!"}' >>>> >>>> http://localhost:8080/ag-push/rest/sender/broadcast| >>>> >>>> the message would be delivered to all clients - >>>> regardless of the underlying "PushNetwork" >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> 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 >> >> >> >> >> -- >> 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 -- 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

So this is not really a design question. So the admin console will allow developers/admins to "register" so they can log into the UI, should there be a section in the UI that allows for user management? or is this a separate thing? Probably not a priority atm, but just thinking out load

On Jul 2, 2013, at 10:21 AM, Hylke Bons <hbons(a)redhat.com&gt; wrote: Hold you horses, I barely had a day to work on them... :) I'll post them as soon as possible. Hylke On 02/07/2013 14:50, Matthias Wessendorf wrote: On Mon, Jul 1, 2013 at 8:18 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > HI, > > just wanted to see if there was any update to those wireframes yet > I'd be interested as well :) -Matthias > > On Jun 28, 2013, at 1:06 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > > Alright, so after a chat with Matthias on IRC about the potential use > cases I'm updating the wireframes with the requirement. I'll post an update > here soon. > > Thanks, > > Hylke > > > On 28/06/2013 12:38, Matthias Wessendorf wrote: > > > > > On Fri, Jun 28, 2013 at 1:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> perhaps a workflow explanation will clear things up a bit >> >> >> i log in to the admin console and the first screen should be where i >> create a "Push Application", which isn't really an application, but just a >> grouping name essentially. >> >> then under the "Push Applications" details, this is where we actually >> create the "apps"( or the different variants of the grouping ). Each of >> these would need there own certificate/googleApiKey. >> > > exactly > > > >> >> >> >> >> >> >> On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: >> >>> I'm not even sure we're talking about the same thing. :) >>> >>> Just to make sure, this is _not_ about the ID/Secret shown in the >>> wireframes for the app and its variants? (the variant ones show up in >>> "tooltips"). >>> >> >> Of course, every variant also has it's own variantID/secret >> >> >>> >>> >>> >>> Hylke >>> >>> >>> On 28/06/2013 12:09, Matthias Wessendorf wrote: >>> >>> >>> >>> Still, we would you want to use different settings if the result, >>>> getting a message to the client, is the same? >>>> >>> >>> you lost me. Not sure what you are asking :) >>> >>> Are you concerned about the "payload" (message) is represented >>> differently ? >>> >>> If one PushApp has several variants: >>> * HR-iOS-Tablet free >>> * HR-iOS-Tablet paid >>> * HR-iOS-Phone free >>> * HR-Android-Phone paid >>> * HR-Android-Watch free >>> >>> >>> Each has it's OWN cert/key. Still if you send out something like: >>> >>> curl -u "{PushApplicationID}:{MasterSecret}" >>> -v -H "Accept: application/json" -H "Content-type: application/json" >>> -X POST >>> -d '{"key":"value", "alert":"HELLO!"}' >>> http://localhost:8080/ag-push/rest/sender/broadcast >>> >>> >>> the message would be delivered to all clients - regardless of the >>> underlying "PushNetwork" >>> >>> >>> >>>> >>>> Hylke >>>> >>>> _______________________________________________ >>>> 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 listaerogear-dev@lists.jboss.orghttps://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 >> _______________________________________________ >> 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 > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 > > > > _______________________________________________ > 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 listaerogear-dev@lists.jboss.orghttps://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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

tl;dr On Jul 3, 2013, at 8:18 AM, Matthias Wessendorf <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: > > > > On Wed, Jul 3, 2013 at 2:14 PM, Lucas Holmquist <lholmqui(a)redhat.com > <mailto:lholmqui@redhat.com>> wrote: > > So this is not really a design question. > > So the admin console will allow developers/admins to "register" > so they can log into the UI, should there be a section in the > UI that allows for user management? or is this a separate thing? > Probably not a priority atm, but just thinking out load > > > yes, and I think we have had that already in this thread, that some > sort of user management is needed. > > Quote from first email in this thread: "The next step is to look at > the the missing features like the user > management and authentication." > > > -Matthias > > > > On Jul 2, 2013, at 10:21 AM, Hylke Bons <hbons(a)redhat.com > <mailto:hbons@redhat.com>> wrote: > >> Hold you horses, I barely had a day to work on them... :) >> I'll post them as soon as possible. >> >> Hylke >> >> >> On 02/07/2013 14:50, Matthias Wessendorf wrote: >>> >>> >>> >>> On Mon, Jul 1, 2013 at 8:18 PM, Lucas Holmquist >>> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: >>> >>> HI, >>> >>> just wanted to see if there was any update to those >>> wireframes yet >>> >>> >>> I'd be interested as well :) >>> >>> >>> -Matthias >>> >>> >>> On Jun 28, 2013, at 1:06 PM, Hylke Bons <hbons(a)redhat.com >>> <mailto:hbons@redhat.com>> wrote: >>> >>>> Alright, so after a chat with Matthias on IRC about the >>>> potential use cases I'm updating the wireframes with the >>>> requirement. I'll post an update here soon. >>>> >>>> Thanks, >>>> >>>> Hylke >>>> >>>> >>>> On 28/06/2013 12:38, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Jun 28, 2013 at 1:35 PM, Lucas Holmquist >>>>> <lholmqui(a)redhat.com <mailto:lholmqui@redhat.com>> wrote: >>>>> >>>>> perhaps a workflow explanation will clear things up a bit >>>>> >>>>> >>>>> i log in to the admin console and the first screen >>>>> should be where i create a "Push Application", which >>>>> isn't really an application, but just a grouping name >>>>> essentially. >>>>> >>>>> then under the "Push Applications" details, this is >>>>> where we actually create the "apps"( or the different >>>>> variants of the grouping ). Each of these would need >>>>> there own certificate/googleApiKey. >>>>> >>>>> >>>>> exactly >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf >>>>> <matzew(a)apache.org <mailto:matzew@apache.org>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons >>>>>> <hbons(a)redhat.com <mailto:hbons@redhat.com>> wrote: >>>>>> >>>>>> I'm not even sure we're talking about the same >>>>>> thing. :) >>>>>> >>>>>> Just to make sure, this is _not_ about the >>>>>> ID/Secret shown in the wireframes for the app >>>>>> and its variants? (the variant ones show up in >>>>>> "tooltips"). >>>>>> >>>>>> >>>>>> Of course, every variant also has it's own >>>>>> variantID/secret >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hylke >>>>>> >>>>>> >>>>>> On 28/06/2013 12:09, Matthias Wessendorf wrote: >>>>>>> >>>>>>> >>>>>>> Still, we would you want to use different >>>>>>> settings if the result, >>>>>>> getting a message to the client, is the same? >>>>>>> >>>>>>> >>>>>>> you lost me. Not sure what you are asking :) >>>>>>> >>>>>>> Are you concerned about the "payload" (message) >>>>>>> is represented differently ? >>>>>>> >>>>>>> If one PushApp has several variants: >>>>>>> * HR-iOS-Tablet free >>>>>>> * HR-iOS-Tablet paid >>>>>>> * HR-iOS-Phone free >>>>>>> * HR-Android-Phone paid >>>>>>> * HR-Android-Watch free >>>>>>> >>>>>>> >>>>>>> Each has it's OWN cert/key. Still if you send >>>>>>> out something like: >>>>>>> >>>>>>> |curl -u "{PushApplicationID}:{MasterSecret}" >>>>>>> -v -H "Accept: application/json" -H "Content-type: application/json" >>>>>>> -X POST >>>>>>> -d '{"key":"value", "alert":"HELLO!"}' >>>>>>> >>>>>>> http://localhost:8080/ag-push/rest/sender/broadcast| >>>>>>> >>>>>>> the message would be delivered to all clients - >>>>>>> regardless of the underlying "PushNetwork" >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>> >>> >>> >>> >>> -- >>> 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 > > > > > -- > 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 https://lists.jboss.org/mailman/listinfo/aerogear-dev

I would like to reboot the discussion of css frameworks the 2 that are in question are bootstrap and topcoat. i would like to here why one is "better" than the other. or why the preference. Ready, Go.

Another iteration is up in the same place. Hylke On 08/07/2013 15:01, Hylke Bons wrote: > Updated wireframes can be found here: https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_pus... > > Hylke > > > On 03/07/2013 13:19, Lucas Holmquist wrote: >> tl;dr >> On Jul 3, 2013, at 8:18 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Wed, Jul 3, 2013 at 2:14 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>> So this is not really a design question. >>> >>> So the admin console will allow developers/admins to "register" so they can log into the UI, should there be a section in the UI that allows for user management? or is this a separate thing? Probably not a priority atm, but just thinking out load >>> >>> yes, and I think we have had that already in this thread, that some sort of user management is needed. >>> >>> Quote from first email in this thread: "The next step is to look at the the missing features like the user >>> management and authentication." >>> >>> >>> -Matthias >>> >>> >>> >>> >>> On Jul 2, 2013, at 10:21 AM, Hylke Bons <hbons(a)redhat.com&gt; wrote: >>> >>>> Hold you horses, I barely had a day to work on them... :) >>>> I'll post them as soon as possible. >>>> >>>> Hylke >>>> >>>> >>>> On 02/07/2013 14:50, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Jul 1, 2013 at 8:18 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>>>> HI, >>>>> >>>>> just wanted to see if there was any update to those wireframes yet >>>>> >>>>> I'd be interested as well :) >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> >>>>> On Jun 28, 2013, at 1:06 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: >>>>> >>>>>> Alright, so after a chat with Matthias on IRC about the potential use cases I'm updating the wireframes with the requirement. I'll post an update here soon. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Hylke >>>>>> >>>>>> >>>>>> On 28/06/2013 12:38, Matthias Wessendorf wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 28, 2013 at 1:35 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>>>>>> perhaps a workflow explanation will clear things up a bit >>>>>>> >>>>>>> >>>>>>> i log in to the admin console and the first screen should be where i create a "Push Application", which isn't really an application, but just a grouping name essentially. >>>>>>> >>>>>>> then under the "Push Applications" details, this is where we actually create the "apps"( or the different variants of the grouping ). Each of these would need there own certificate/googleApiKey. >>>>>>> >>>>>>> exactly >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: >>>>>>>> I'm not even sure we're talking about the same thing. :) >>>>>>>> >>>>>>>> Just to make sure, this is _not_ about the ID/Secret shown in the wireframes for the app and its variants? (the variant ones show up in "tooltips"). >>>>>>>> >>>>>>>> Of course, every variant also has it's own variantID/secret >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hylke >>>>>>>> >>>>>>>> >>>>>>>> On 28/06/2013 12:09, Matthias Wessendorf wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Still, we would you want to use different settings if the result, >>>>>>>>> getting a message to the client, is the same? >>>>>>>>> >>>>>>>>> you lost me. Not sure what you are asking :) >>>>>>>>> >>>>>>>>> Are you concerned about the "payload" (message) is represented differently ? >>>>>>>>> >>>>>>>>> If one PushApp has several variants: >>>>>>>>> * HR-iOS-Tablet free >>>>>>>>> * HR-iOS-Tablet paid >>>>>>>>> * HR-iOS-Phone free >>>>>>>>> * HR-Android-Phone paid >>>>>>>>> * HR-Android-Watch free >>>>>>>>> >>>>>>>>> >>>>>>>>> Each has it's OWN cert/key. Still if you send out something like: >>>>>>>>> >>>>>>>>> curl -u "{PushApplicationID}:{MasterSecret}" >>>>>>>>> -v -H "Accept: application/json" -H "Content-type: application/json" >>>>>>>>> -X POST >>>>>>>>> -d '{"key":"value", "alert":"HELLO!"}' >>>>>>>>> >>>>>>>>> http://localhost:8080/ag-push/rest/sender/broadcast >>>>>>>>> >>>>>>>>> the message would be delivered to all clients - regardless of the underlying "PushNetwork" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hylke >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> _______________________________________________ >> 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

So i've been playing with the latest wireframes and i'm not sure how well a "Master/Detail" view is going to scale when there are a lot of Apps. The list of Created applications could be potentially really long, or if on a smaller screen( not necessarily a mobile screen ) , then we have scrolling on the side bar, and also could have scrolling on the main detail section. which gets a bit annoying. I'm wondering, and would like others thoughts, if we should get rid of the sidebar stuff, which is really there for navigation i think.