From matt.wagner at redhat.com Wed Aug 19 15:23:42 2015 Content-Type: multipart/mixed; boundary="===============6218218180340865321==" MIME-Version: 1.0 From: Matt Wagner To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Mon, 06 Feb 2012 12:20:39 -0500 Message-ID: <20120206172039.GA7642@mawagner-desktop.usersys.redhat.com> In-Reply-To: 2B4CAECF-6B24-4F5D-8CD0-4B164EE44B01@redhat.com --===============6218218180340865321== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Andy, Apologies for the week-long delay in responding. I've replied inline below: On Mon, Jan 30, 2012 at 03:51:07PM +1000, Andy Fitzsimon wrote: > Hi all, > = > I've spent quite some time thinking about global UI improvements we can m= ake to conductor for a future release. > Now it's time for me to share a small summary of those ideas and hopefull= y get some feedback. > = > I'll be updating http://ndftz.com/playground/ with much the stuff mention= ed below but as of right now it is not a representation of the functionalit= y described; so if you have seen it before, please disregard everything asi= de from the responsiveness and the vector icons aspects. I'll now switch g= ears to get the mock interface up to speed with all the client side feature= s described. I'd chatted with you a bit on IRC about this in the past, but to reiterate: this looks *awesome*! > = > (attached is a formatted copy in-case you don't like reading markdown) > = > .. so here we go.. > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > #Goals for a better UI > = > = > > This is a plan to evolve the conductor UI into a lean, adaptive, beauti= ful and considered experience. > = > = > ### Specifically, we hope to address: > * Navigating and issuing tasks quickly = > * Without unnecessary http-roundtrips just to check on a view. > * Without having to learn new components in every view > * Without having to refer to documentation to be assisted in core tasks. > = > * Keeping the =E2=80=98big 6=E2=80=99 consistent: = > * Consistent aesthetic > * Consistent behaviour > * Consistent notification = > * Consistent messaging = > * Consistent help > * Consistent referencing > = > * Address as many media types as we can get *for free* > * __Mobile__ - 480px and up via minor accommodations in our UI > * __Workstation__ 640px-1280px - our default view > * __Section 508__ compliance including screen readers > * __Printable__ - As a read-only inventory manifest of a users entire a= ccess. I've sort of been watching the "responsive design" movement from the sidelines and am rather intrigued. The ability to have one layout that works across a wide variety of devices would be fantastic. > * Feel like a 2012 client app = > * Cutting edge UI conventions > * Swiss style visual metaphors & elements of typographic style > * Baseline grid aligned typography consisting of 2 weights with single = leading. > * Use only vector graphics This one gets a "Whoa, _that_ is nifty" reaction from me. :) > * Blazingly fast client side render times > = > = > # Glossary of terms / explanation of features. > = > = > = > ## Views > = > One distinct category of content. > = > ### explained > = > =E2=80=9Cthe users view=E2=80=9D or =E2=80=9Cthe providers view=E2=80=9D. > A views name can even be as specific as =E2=80=9CuserXX-provider-permissi= ons view=E2=80=9D or =E2=80=9Cadmin-provider-permissions-userXX view=E2=80= =9D Does this imply that we are moving away from the "pretty view" vs. "detail view" system? (I would not be averse to this at all, but wanted to be clear.) > = > For more information on how we implement views, see 'View anchors' below > = > ****** > = > = > ## Classes > = > Think HTML/CSS/JS classes > = > Classes track status or content type but not display. > = > = > online` >
Ec2=E2=80=A6=
> = > ### Classing convention > = > = > #### Reserved classes > = > .active = > is reserved for navigating views > = > .enabling .disabling .verifying .deleting .requesting > are action classes reserved for client side action confirmation > = > .enabled .disabled .verified .complete .building > are action classes reserved for server events > = > .warning .note .info .tip .caution > are reserved for assistive content > = > .static-reference .assist-reference > reserved for anchored clones of content via static and assistive referenc= ing (see section) > = > .progress .loading .building .compiling .altering > are progress classed to be used in conjunction with a numerical class > = > .50 .10 .20 .25 .75 .100 .30 etc=E2=80=A6 > are percentage classes to be used in conjunction with a value > = > e.g.: `75% of 300gb or better: `225gb of 300gb = > .usage .progress .load .capacity > are **status** classes reserved for identifying the **type** of measureme= nt > = > .instance .provider .user .pool .group > are object classes to be used on any object = I think I need a bit longer for all of this to sink in. > = > ### Lack of classes for layout > We will __NOT__ use classes for defining grid layout e.g. `.span-12` or `= .left-120/` > = > All layouts will be defined in CSS via a combination of their parent view= and the relevant media query. > = > = > for example we will use the CSS = > #admin #providers .account .summary{width:33.333%} > rather than relying on injecting style logic into the html like this `` This feels much cleaner, though I fear the old pattern will be a hard habit to break. (For me, at least.) > = > ****** > = > ## Graceful degradation > = > Support for all core functionality in as many scenarios as possible > = > * New browser features (subtle animation, gradients etc) > * Older browsers lacking features = > * Browsers with javascript turned off +1000 for doing this. Right now we badly misbehave in some sections if JavaScript is disabled. > * Screen readers (section 508, we=E2=80=99re going there) > = > ****** > = > = > ## Responsive design > = > Support for viewing from various media eg cellphones, touchscreen device= s, kiosks, tv=E2=80=99s, even print. > = > = > ### Explained > = > 1. We collapse tables into record views for narrow screens. > 2. We Grow fonts and icons for tremendously high resolutions or touchabl= e large screens. > 3. We use only vector graphics (css /webfonts) for adaptive scaling and = themeing. > Anchor referencing with js inlining means repeated content is printed onl= y once. a print version would read like an infrastructure status report fr= om the users perspective. > = > ****** > = > = > ## Visual Metaphors & Vector Graphics > = > Visual metaphors are graphics symbolic of the function they perform. > Vector graphics are a resolution independent implementation. > = > ### Explained = > All icons, visual indicators and ornamental graphics are implemented lik= e this: > = > * Vector glyphs are encoded into a woff webfont = > * The woff font is base64 encoded in the stylesheet to minimise http req= uests (the current set of 30 icons is ~5k) so this is very acceptable. This is my first real exposure to this concept, but this sounds really novel. > * We fallback to url linked images supplies for legacy browsers (no .WOF= F support) by using [modernizr](http://www.modernizr.com/) classes `.no-web= fonts` and `.webfonts` to discriminate our implementation through css > = > = > ****** > = > ## View anchors - or 'single page app' > = > View anchors are portions of our design implemented within the one DOM us= ing basic anchoring functionality. > = > ### Explained > In the proposed change, the entire conductor is one page for all default = views, = What I still don't quite understand here is whether this means that, when we render this page, we need to render *all* views in advance, or if they're lazy-loaded via AJAX. The former sounds like it will be rather slow (on the back-end), since we have a few pages that make expensive calls to external services. > 1. Link anchors will activate the specific view or sub-view. = > = > 2. Anchors that do not resolve will initiate a "cannot find" message whic= h will most commonly occur when a user does not have access to an object an= d has manually entered a custom # URL. the two exceptions to this will be = ~/# and ~/#top which will initiate the default app view. > = > ### In action > = > For example: = > = > > The URL below should open the admin > providers > ec2eastcoast > connec= tivity view. > = > https://conductor/#ec2eastcoast-connectivity > ^ ^ ^ > Server ObjectID ChildView > = > = > #### What the html does > e.g. the `
` representing admin > providers > ec2eastcoast would look= like = > = >
.. ec2 east coast information goes here > = > = > and the connectivity tab which exists inside the ec2eastcoast provider wo= uld look like = > = >
> ^ ^ > objectID ChildViewname > = > Why? > Because the provider _ec2eastcoast_ lives natively within the _admin > pr= ovider_ section, it does not need to be referenced in the ID.. it simply ha= s to be unique. But because the connectivity tab is only unique because of= the provider it is associated with, it needs to be prefixed with the objec= tID = > = > = > All direct links to the provider view would look like `EC2 East Coast which would activate the provider tab. > = > = > #### what JS does > = > 1. JS hides all non active views except for the default view (classed as = active by the js) How does this behave in a browser without JavaScript / with JS disabled? > 2. = > 3. when an ID is requested the object and all parent views get classed `.= active` = > 4. [hashchange for old browsers](http://benalman.com/projects/jquery-hash= change-plugin/) to preserve browsing history As Scott brought up on IRC this morning, there appear to be places where we currently break the "Back" button. If we're able to become consistent in preserving history, that would be fantastic. > #### what the CSS does > The body class `.nojs` is removed once Javascript is loaded so the CSS sp= ecifies that only views be visible when they are classed as `.active` = > = > = > .js div{display:none} // Hiding all views > .js div.active{display:block} // Showing active views > .nojs div{display:block} // All views are shown when tabs don't = work. > = > ****** > = > = > ## Referenced content > = > > Referenced content is a live-copy of any existing part of the applicati= on. It can be implemented with static references or assistive references = > = > > See [this JS Fiddle demo](http://jsfiddle.net/andyfitz/hRqGa/191/) = > = > #### example > = > 1. Global help content can be referenced from many places at once so as t= o avoid redundancy and annoying ajax requests.. if the section the help com= es from is loaded, so is the help. Semi-related, the concept of "global help" at all would be fantastic! ;) Right now we have some confusing content with no help on-page. > 2. Inspecting an object via a link can call the objects entire content in= to view. > = > ****** > = > ### Static-references > = > Where an anchor link to another section has been replaced with a live cop= y of the section it links to. > = > .static-reference > = > > An example would be any monitoring view that requires various metrics a= lready rendered elsewhere be included. > = > = > ****** > = > ### Assist-references > = > like a static reference but with the link-text preserved and the section = only visible when the link-text has focus (has been clicked). > = > .assist-reference > = > > An example would be a permissions editor referencing the objects that a= user has permissions to by name and allowing the user to inspect that obj= ect in-place with a single click, without having to visit the object in que= stions default view. > = > ****** > = > = > ## Help & content > = > Written content to help describe a feature or scenario. = > Combined with admonition classes = > = > .warning .note .info .tip .caution > = > Often implemented via one of the following methods = > = > * Included in the view relevant to its description > * As static-references where the help content can be dismissed (via an X= in the top right corner) > * As assist-references where the help content can be revealed upon click= ing a referring link > = > = > = > = > Practically speaking this is text that can be placed inline with a view t= hat it represents or hidden in a non displayed useful content area to be st= atic or assist-referenced by many places. > = > = > ### Explained > = > For example: _=E2=80=9Cdon=E2=80=99t be silly=E2=80=9C_ is a generic tip= that may apply to an enormous variety of contexts. This is useful to be p= laced in the "generic tips" area and linked to via `now please r= emember..` which means it wil be rendered inline of where it is referen= ced. > = > ****** > = > = > ##Client-side status polling > = > All objects relevant to a view are classed with the viewname > On any action inside the view, a status classname is added to the view as= well as any objects that reference it regardless of where they are display= ed = > = > = > link = >
UserXX View
. > = > We watch the referenced views classes and mimic them on all referencing l= inks always as they can contain or be updated with new event styles (for ex= ample: failed, warning, upgraded, admin-only etc) > = > ****** > = > ## Server status events *investigating* > = > Right now we can use ajax calls to update each view but in future it woul= d make sense to use eventSource for more advanced monitoring: [eventSource:= server sent events](http://html5doctor.com/server-sent-events/) = > = > ****** > = > ## Client verification / fast feedback > = > Interactive assurance that an action has been requested without the verif= ication that the server has performed the action. > = > For example a user clicks the enable button.. we immediately apply =E2=80= =9Cenabling=E2=80=9D status to the button but wait for the server to return= with the =E2=80=9Cenabled=E2=80=9D confirmation... > = > ### How it works > = > > **Assumption** intermittent states like verifying, enabling and disabli= ng states are safe for client side validation. > = > > They confirm an action has been requested but not applied. > = > As a rule, all elements are given the status of the objects they represen= t as well as classed with the object ID.. e.g.: all buttons with `class=3D= "providerid12451-*"` get the additional class of their intermittent state `= `"enabling/disabling/verifying/whatever"`` When a functional object relate= d to them has been actioned. > = > 1. On the client javascript side, we set the actioning classname to all = elements with the same object objectid class. > = > 2. Once the action has been done an ajax call confirm the change and ref= reshes the class to "enabled/disabled/done/whatever" and removes the interm= ediary state It's not clear to me from this, but does this actually require a second call? It seems like, on clicking 'submit' or whatnot, we could change the status like you describe, and then, when the request completes naturally, apply the update. That saves us from an extra AJAX query to check the status. > = > ****** > = > ## Important action certification > = > [JS Fiddle demo](http://jsfiddle.net/andyfitz/mvdST/) > = > = > Requiring the user to certify that they understand the action before allo= wing it to take place. > for example: = > = > > =E2=80=9CDo you understand what you are doing?[yes] okay, here=E2=80=99= s the button [click]=E2=80=9D > = > ###explained > = > > Enabling and disabling providers, deleting users etc = > = > We will use three methods to verify that a user has accepted the severity= of the task they are about to perform: > = > 1. CSS physical obfuscation. = > Where the confirmation toggle sits physically on top of the action toggle= so that an action can not be clicked without clicking the confirmation tog= gle first. this helps simplify the component to one physical space part of= the same consideration set. > = > 2. javascript validation. = > The action button beneath is disabled until the confirmation toggle has b= een clicked > 3. final server verification. = > the submitted action is not accepted by the system unless the post contai= ns both the verification enabled and the action. the server then pushes the= update Right now we're just using JS verification in a handful of places, because Rails includes an easy helper for this. Is there much of an advantage to involving CSS and server-side verification as well? > = > = > ****** > = > ##Global status and system notification stack. = > = > Important information about the entire system or a current process, displ= ayed prominently. > ###explained > = > Using the referenced content heavily, we throw system, warning and notifi= cation content to the top of the page in a collapsing, growl-style notifica= tion system=E2=80=9D > = >
>

System Messages

> = >

you should to install aeolus-= all to properly use conductor

> = >

> href=3D=E2=80=9Dprovider123-build-status=E2=80=9D = > class=3D=E2=80=9Dreflink 50=E2=80=9D> > building provider123 50% Complete > >

> = >
>From talking to a few people who don't use Conductor every day, it sounds like our current flash messages are easy to miss / overlook. I'd love to make them much more prominent. > = > = > ****** > = > ## Printable manifest > = > Because our content is not replicated, and all enabled views are included= in the DOM; = > our app can actually print as if it were a manifest for the authenticated= user. > = > We get this feature for free by proxy of our method for referencing views= and content. > = > Having the ability to produce a hard copy infrastructure report may be a = gimmick, but it's an easy way to show how conductor can help respond an IT = audit situation. > = > ### example print stylesheet changes > = > @media print { > = > a:after { > content: " ("attr(href)") ";} > = > div:before{ > content: " ("attr(id)") ";}} > = > } > = > This will preserve all references and links throughout the UI. > = > Also, we can manually define sections to be printed. > = > @media print { > = > div{display:none} > = > #providers, #instances, #users, #global-tips {display:block !importan= t} I will definitely yield to you here because you are astronomically more experienced with this stuff than I am, but I thought that using !important was a bit of a hack to be avoided except where you needed to override styles on a particular page. Is this not correct? > = > } > = > Which means only sections we desire to be included in the manifest get pr= inted > = > also = > = > @media print { > = > .tabs:before{ > page-break-before: always; > content:"This section contains the following:"; > .tabs li a:after{content:""} > .tabs { font-size: 2em;page-break-after: always;} > .tabs li{display:list} > } > = > Which will convert our tabs into whole page section summaries. > = > > remember, this feature is free because we are designing conductor to gr= acefully degrade. Very little effort goes into preserving this feature so l= ong as our standards are maintained. > = > = > # Existing conductor paradigms > = > These changes don't create any changes to terminology, or have much impac= t for pre-existing views for components already built into conductor. It i= s likely that the majority of what has already been done will be preserved = and only undergo minor changes to the HAML/SASS so that features may be int= egrated into the global view. So this brings me to one point that I do want to stress... I think this outline and the demo you have are fantastic, and I hope we're able to implement it. But at the same time, I've been here for just over a year and have already seen 3 wholly different user interfaces implemented, to the point that it's almost a running joke that we rip out and reimplement our UI when the seasons change. I think our sanity would be greatly preserved if we could approach this as a series of evolutionary improvements, as opposed to a revolutionary, "reboot"-style implementation of a fourth totally-new UI. > This has been written purely to start discussion on how we evolve Conduct= or going forward and I'd love to hear your thoughts: [andy.fitzsimon(a)redh= at.com ](mailto:andy.fitzsimon(a)redhat.com) One other thing I've noticed is that both the current UI and your mockup are pretty gray. I'm not necessarily lobbying for a technicolor UI, but I find the monochromatic interface to be kind of bleak. Is it possible to add some splashes of color? -- Matt --===============6218218180340865321==--