Matthias, I was trying to show how GH handles screens when they are empty, it doesn't matter its NO notifications or NO variants or NO apps. The idea is what to show when there ir nothing to show :)

Patternfly doesn't have a pattern for blank slates, so we are discussing with the UX team how to show them on our consoles. It will probably follow what we do on our console.

----- Original Message -----
From: "Matthias Wessendorf" <matzew@apache.org>
To: "AeroGear Developer Mailing List" <aerogear-dev@lists.jboss.org>

Sent: Tuesday, January 6, 2015 10:22:06 AM
Subject: Re: [aerogear-dev] UP console questions



On Tue, Jan 6, 2015 at 1:22 PM, Andres Galante < agalante@redhat.com > wrote:


Thanks Matthias and Daniel. This really helps.

Matthias we do need to be more explicit along the way.
For first time users we need a blank slate[1] followed by a wizard. Plus blank slate for each empty page (like no variants). We can't assume that everyone will read the documentation first.

the notifications from GH are just an example here, right? And we would need this being applied to Push Apps and Variants, right?
Because it's not the intention of the UPS console to actually read the notifcations. Sure the dashboard shows them and info, but thats more monitoring (e.g. did something go wrong while delivering to Apple/Google/Microsoft)


Apart from that we need to guide users as they set up backend and device configuration.

yeah, we had previously thought about a better integration of our doc. The doc for the UPS is here:
https://aerogear.org/docs/unifiedpush/ups_userguide/



I am working on all this and rearranging IA so it makes more sense.

[1] https://dl.dropboxusercontent.com/u/4371641/blank.jpg

----- Original Message -----
From: "Matthias Wessendorf" < matzew@apache.org >
To: "AeroGear Developer Mailing List" < aerogear-dev@lists.jboss.org >
Sent: Tuesday, January 6, 2015 8:55:14 AM
Subject: Re: [aerogear-dev] UP console questions



On Tue, Jan 6, 2015 at 11:35 AM, Daniel Passos < daniel@passos.me > wrote:





On Tue, Jan 6, 2015 at 6:57 AM, Matthias Wessendorf < matzew@apache.org > wrote:









On Mon, Jan 5, 2015 at 5:53 PM, Andres Galante < agalante@redhat.com > wrote:


Hey!

I am working on the push console, and I have some questions:

1- What is the main action on the console? What is the main goal a user want to achieve?
I notice that the console is center on creating and seeing up apps and not so much in sending notifications. Is sending notifications usually done on code and not the console?

the console is nice to send test messages. But in reality a backend (e.g. a MBaaS) will send a request to UPS to force it to deliver the push to Apple and GCM.

The main goal is managaement (and overview/stats) around Apps, their Variants and their installations.



2- Under each app we have some information mixed with actions:
No variants - Activity - Send Push - admin
What does "admin" do, can an app be manage by other thats not the admin?

we allow to roles:
* admin
* user
a user (like Andres or Matthias) can do all the CRUD actions. Andres see his apps, Matthias see his own apps too. An Admin (e.g. Jay) sees apps from both users Andres and Matthias




3- Once you click on an app name you get a yellow box with "Sending push notifications" set up information. But when you create a variant you also get an specific info box for each variant.
What is the difference between them?

not sure what you are asking







The first box ( Sending push notifications ) when you create a new application is a snippet of code to you use in you backend (using our sender API[1]) to send a message to UPS and it delivery to the devices like it[2]. The second box ( Registering installations ) when you create a variant is a snippet of code to you use in you mobile app to register you device in that application like it[3]

Ah, ok. I now think that the provide text/headers and icons for the two different boxes are perhaps not good enough. Andres, would it make sense to be more explicit there? I think some of what passos wrote could be perhaps baked into the boxes, right ?





[1] https://aerogear.org/docs/unifiedpush/GetStartedwithJavaSender/
[2] https://github.com/danielpassos/aerogear-jaxrs-backend/blob/master/src/main/java/me/passos/talks/aerogear/ProductService.java#L56-L69
[3] https://github.com/danielpassos/AeroProduct/blob/master/src/me/passos/talks/aerogear/AeroProductsApplication.java#L36-L60










Thanks!






​

_______________________________________________
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