From jtomasek at redhat.com Wed Aug 19 15:23:43 2015 Content-Type: multipart/mixed; boundary="===============3876813327633036252==" MIME-Version: 1.0 From: Jirka Tomasek To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Tue, 07 Feb 2012 11:26:27 +0100 Message-ID: <4F30FC53.4050103@redhat.com> In-Reply-To: 2B4CAECF-6B24-4F5D-8CD0-4B164EE44B01@redhat.com --===============3876813327633036252== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 01/30/2012 06:51 AM, 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. > > (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, beautif= ul 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 task= s. > > * 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 = access. > > * 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 > * 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 > > 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 > > ### 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 `` > > ****** > > ## 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 > * 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 touchab= le 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 re= quests (the current set of 30 icons is ~5k) so this is very acceptable. > * We fallback to url linked images supplies for legacy browsers (no .WO= FF support) by using [modernizr](http://www.modernizr.com/) classes `.no-we= bfonts` 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, > > 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> connect= ivity 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) > 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 > > #### 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 applicatio= n. 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. > 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 al= ready 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 obje= ct in-place with a single click, without having to visit the object in ques= tions 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 clic= king 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 disablin= g 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 re= freshes the class to "enabled/disabled/done/whatever" and removes the inter= mediary state > > ****** > > ## 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=99s= 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 > > > ****** > > ##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 provider12350% Complete > >

> >
> > > ****** > > ## 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 !importa= nt} > > } > > 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 gra= cefully degrade. Very little effort goes into preserving this feature so lo= ng 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. > > 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) Hey, I have read thorugh your ideas and I must say it looks really impressive. I'd like to point out a few things. For a developer the most important = thing is to have a strict guide how to use certain website elements and = blocks. Strictly given structure of application elements are really = important to keep application layout consistent. So we should have given = library of "small" elements (buttons, pagination, headers, lists, = tables...) and "layout level structures" like content sections, = tab-containers... With these, abiding the haml structure is as important = as actual styling of the elements. Haml structure is the actual thing = that everyone of us creates, so there must be strictly given what is the = page and elements structure through the app. The css part is often developed by far less people ( but one person is = definitely not enough ), its also important to have a unified style = pieces too, which is quite easily maintained by mixins. Using view anchors (#something) in urls is nice idea which works nice in = rails routes by specifiing :anchor = (http://lists.rubyonrails.org/pipermail/rails/2006-June/046488.html). Andy how would you like to strucure the css? I would like to see you = opinion on this. I mean how would the actual scss files organize? How = would we implement various features in it? The way it is now or some = other way? From the yesterdays discussion on irc it seems (afaik) that we are = going to have changes in the UI, but haven't seen talk about these you = propose. It also seems that we are heading direction to unify our UI = elements with Katello. From my point of view the actual styling is not that important (It can = be quite easily changed) but what I find really important is unifiing = features and elements structures through the application (haml stuff = basicly) which is not so easy to change during the time and can base = this work on what we have now. Having library of haml templates of = various features would greatly help I think. I would really like to see the structural changes you propose in our app. Jirka --===============3876813327633036252==--