UPS console new UI review
by Andres Galante
Hey!
Today Lukas, Sebastien help me review UPS new UI.
I also did some usability testing yesterday (over dinner with slightly drunk programmers friends of mine).
Here are the results and a bunch of questions for us to discuss:
- Code snippets need a “copy” btn like http://getbootstrap.com/components/
- Descriptions on apps and variants. Can we just remove them? Are they useful?
- "Add a variant" form. There is going to be a validation of the form to make sure connections are correctly set up.
- Variants page [1]. If the user has lots of variants set up, the list would be huge. I am working on solutions, Lukas and Sebastien had very good ideas.
- "Send notification" form has the same problem. Lukas suggested a great solution, to use Multiple select boxes https://select2.github.io/examples.html
- Warnings. Where to show them? How to display them? How to make them disappear once the issue is solve?
- Delete apps or variants takes a lot of time. there is a JIRA about this.
- Add a progress bar to show progress of notifications been sent.
- Add links to documentation everywhere.
- We talked about adding sorting options on the variants list (by name, or by creation date) but it seems that search would be enough. although there was one tester that asked for sorting options.
- It also come to my attention that the name “Variant” is too general. Every non UPS developer I've shown the console asked me “what are variants” and when I explain, they asked me “Why don’t you find a better name that represent “group of devices”?
Lukas mention that a change of wording at this point would be very hard since we have the word “Variant” all over our docs. But maybe for 2.0 we can think of a better way to help the user understand what a Variant is.
Here is the prototype, click around and send feedback :)
http://andresgalante.com/ups-console/login.html
[1]http://andresgalante.com/ups-console/app-detail-variants.html
10 years, 11 months
Feature based landing page (and new UI)
by Matthias Wessendorf
Hi,
for all of our different push offerings, we have a central landing page
([1]), and soon that page will also list our work on the WebPush spec ([2])
Since this model is quite handy, having a centralized landing page, I'd
propose we do that for other features, like OAuth2 and Sync as well.
With the new design, the "feature" is more a module, which is fine. The
Screenshot of the modules page ([3]), we list all of our feature, or more
modules ;-)
While for PUSH we have more than just one repo (UPS, SimplePush and now
WebPush + demos), I think the getting started should go to a 'feature' (or
module) landing page. For AeroGearPush that would be [1], or something
similar. Basically, on this "module landing page", I'd like to list all
relevant GH repos, link to JIRA and perhaps other resources.
Any thoughts?
Now, taking a different example, sync, we would list these repos:
iOS:
https://github.com/aerogear/aerogear-ios-sync
https://github.com/aerogear/aerogear-ios-sync-client
https://github.com/aerogear/aerogear-ios-sync-demo
Android:
https://github.com/aerogear/aerogear-android-sync
JS:
https://github.com/aerogear/aerogear-js (part of the lib)
https://github.com/aerogear/aerogear-js-cookbook (a sync demo, based on
node)
Sync-Server:
https://github.com/aerogear/aerogear-sync-server
+ linking to the JIRAs tracked for the different Sync milestones (currently
the ones with the 'sync-1.0.0.alpha.1' label)
When we have clear "module" entry or landing pages, it's easy for new
users, to get an understanding what it is all about. Instead of jump around
on the site (which is why we generally do the new site :-))
Does that make sense ?
-Matthias
[1] https://aerogear.org/push/
[2] https://github.com/aerogear/aerogear.org/pull/468
[3]
https://www.dropbox.com/s/zypkqd3nn3wma9w/Screen%20Shot%202015-01-20%20at...
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 11 months
native ui
by Erik Jan de Wit
Hi,
My idea having a native UI, but all logic in javascript has to have a name so let’s call it hybrid Cordova.
I experimented a bit yesterday with the idea and it seems very feasible. On the Cordova home page they have already a guide how to include the Cordova web view on a native project, with that creating a interface to be able to call javascript is almost to easy.
What I have now is a native (android) button that calls a javascript function. It uses a plugin to call the javascript and offers a static method for the execution.
So to take this to the next level, I think we need a bit of a javascript api to do page navigation. And have a bit of a Java Api to initialise the WebView and specify the name of the script to load. Or just pickup all scripts in a assets directory.
WDYT, is it worth exploring further?
Cheers,
Erik Jan
10 years, 11 months
AeroGear.org website UI Done
by Andres Galante
Hi!
Before I continue with UPS console redesign, I want to make sure that everyone has review the new website.
>From your point of view UI is done. What is left to be done:
1- Review overall design and UI again.
2- JS on news and the parts, Lukas is taking care of it.
3- Check if index pages (roadmap, guides, docs and demos) are ok and pointing to the right direction.
4- Text! Review text, make sure there are no typos and dummy texts are fill out.
5- Am I missing something?
You can see this on new-design branch: https://github.com/andresgalante/aerogear.org/tree/new-design
Thanks!
Andrés
10 years, 11 months
