On Tue, Jan 6, 2015 at 2:39 PM, Andres Galante <agalante(a)redhat.com> wrote:
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(a)apache.org>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)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(a)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(a)apache.org >
To: "AeroGear Developer Mailing List" < aerogear-dev(a)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(a)passos.me > wrote:
On Tue, Jan 6, 2015 at 6:57 AM, Matthias Wessendorf < matzew(a)apache.org >
wrote:
On Mon, Jan 5, 2015 at 5:53 PM, Andres Galante < agalante(a)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/ma...
[3]
https://github.com/danielpassos/AeroProduct/blob/master/src/me/passos/tal...
Thanks!
_______________________________________________
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