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.


On Jul 8, 2013, at 1:28 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:

thanks,  i'll take a look


here is the repo where development is happening https://github.com/aerogear/aerogear-unified-push-server-admin-ui

i added mocks and the read me should explain how to set it up

On Jul 8, 2013, at 1:21 PM, Hylke Bons <hbons@redhat.com> wrote:

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_push_server_admin_ui.png

Hylke


On 03/07/2013 13:19, Lucas Holmquist wrote:
tl;dr
On Jul 3, 2013, at 8:18 AM, Matthias Wessendorf <matzew@apache.org> wrote:




On Wed, Jul 3, 2013 at 2:14 PM, Lucas Holmquist <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@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@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@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@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@apache.org> wrote:




On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons <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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


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


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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


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



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev