From afitzsim at redhat.com Wed Aug 19 15:23:28 2015 Content-Type: multipart/mixed; boundary="===============7812347200950457265==" MIME-Version: 1.0 From: Andrew Fitzsimon To: aeolus-devel at lists.fedorahosted.org Subject: Conductor UI - some ideas for a better conductor Date: Mon, 30 Jan 2012 15:51:07 +1000 Message-ID: <2B4CAECF-6B24-4F5D-8CD0-4B164EE44B01@redhat.com> --===============7812347200950457265== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, I've spent quite some time thinking about global UI improvements we can mak= e to conductor for a future release. Now it's time for me to share a small summary of those ideas and hopefully = get some feedback. I'll be updating http://ndftz.com/playground/ with much the stuff mentioned= below but as of right now it is not a representation of the functionality = described; so if you have seen it before, please disregard everything aside= from the responsiveness and the vector icons aspects. I'll now switch gea= rs to get the mock interface up to speed with all the client side features = 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, beautifu= l 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 acc= ess. * 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 le= ading. * 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-permission= s 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 referencin= g (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 225gb of 300gb ` ****** ## 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 devices,= 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 touchable = large screens. 3. We use only vector graphics (css /webfonts) for adaptive scaling and th= emeing. Anchor referencing with js inlining means repeated content is printed only = once. a print version would read like an infrastructure status report from= 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 like = this: * Vector glyphs are encoded into a woff webfont = * The woff font is base64 encoded in the stylesheet to minimise http reque= sts (the current set of 30 icons is ~5k) so this is very acceptable. * We fallback to url linked images supplies for legacy browsers (no .WOFF = support) by using [modernizr](http://www.modernizr.com/) classes `.no-webfo= nts` 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 usin= g basic anchoring functionality. ### Explained In the proposed change, the entire conductor is one page for all default vi= ews, = 1. Link anchors will activate the specific view or sub-view. = 2. Anchors that do not resolve will initiate a "cannot find" message which = will most commonly occur when a user does not have access to an object and = 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 > connecti= vity view. https://conductor/#ec2eastcoast-connectivity ^ ^ ^ Server ObjectID ChildView #### What the html does e.g. the `
` representing admin > providers > ec2eastcoast would look l= ike =
.. ec2 east coast information goes here and the connectivity tab which exists inside the ec2eastcoast provider woul= d look like =
^ ^ objectID ChildViewname Why? Because the provider _ec2eastcoast_ lives natively within the _admin > prov= ider_ section, it does not need to be referenced in the ID.. it simply has = to be unique. But because the connectivity tab is only unique because of t= he provider it is associated with, it needs to be prefixed with the objectI= D = 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 ac= tive by the js) 2. = 3. when an ID is requested the object and all parent views get classed `.ac= tive` = 4. [hashchange for old browsers](http://benalman.com/projects/jquery-hashch= ange-plugin/) to preserve browsing history #### what the CSS does The body class `.nojs` is removed once Javascript is loaded so the CSS spec= ifies 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 wo= rk. ****** ## Referenced content > Referenced content is a live-copy of any existing part of the application= . 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 to = avoid redundancy and annoying ajax requests.. if the section the help comes= from is loaded, so is the help. 2. Inspecting an object via a link can call the objects entire content into= view. ****** ### Static-references Where an anchor link to another section has been replaced with a live copy = of the section it links to. .static-reference > An example would be any monitoring view that requires various metrics alr= eady rendered elsewhere be included. ****** ### Assist-references like a static reference but with the link-text preserved and the section on= ly visible when the link-text has focus (has been clicked). .assist-reference > An example would be a permissions editor referencing the objects that a u= ser has permissions to by name and allowing the user to inspect that objec= t in-place with a single click, without having to visit the object in quest= ions 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 i= n the top right corner) * As assist-references where the help content can be revealed upon clickin= g a referring link Practically speaking this is text that can be placed inline with a view tha= t it represents or hidden in a non displayed useful content area to be stat= ic or assist-referenced by many places. ### Explained For example: _=E2=80=9Cdon=E2=80=99t be silly=E2=80=9C_ is a generic tip t= hat may apply to an enormous variety of contexts. This is useful to be pla= ced in the "generic tips" area and linked to via `now please rem= ember..` which means it wil be rendered inline of where it is reference= d. ****** ##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 w= ell as any objects that reference it regardless of where they are displayed= = link =
UserXX View
. We watch the referenced views classes and mimic them on all referencing lin= ks always as they can contain or be updated with new event styles (for exam= ple: 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 would = make sense to use eventSource for more advanced monitoring: [eventSource: s= erver sent events](http://html5doctor.com/server-sent-events/) = ****** ## Client verification / fast feedback Interactive assurance that an action has been requested without the verific= ation 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 disabling= 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 represent = as well as classed with the object ID.. e.g.: all buttons with `class=3D"p= roviderid12451-*"` get the additional class of their intermittent state ``"= enabling/disabling/verifying/whatever"`` When a functional object related = to them has been actioned. 1. On the client javascript side, we set the actioning classname to all el= ements with the same object objectid class. 2. Once the action has been done an ajax call confirm the change and refre= shes the class to "enabled/disabled/done/whatever" and removes the intermed= iary state ****** ## Important action certification [JS Fiddle demo](http://jsfiddle.net/andyfitz/mvdST/) Requiring the user to certify that they understand the action before allowi= ng 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 o= f the task they are about to perform: 1. CSS physical obfuscation. = Where the confirmation toggle sits physically on top of the action toggle s= o that an action can not be clicked without clicking the confirmation toggl= e first. this helps simplify the component to one physical space part of t= he same consideration set. 2. javascript validation. = The action button beneath is disabled until the confirmation toggle has bee= n clicked 3. final server verification. = the submitted action is not accepted by the system unless the post contains= both the verification enabled and the action. the server then pushes the u= pdate ****** ##Global status and system notification stack. = Important information about the entire system or a current process, display= ed prominently. ###explained Using the referenced content heavily, we throw system, warning and notifica= tion content to the top of the page in a collapsing, growl-style notificati= on system=E2=80=9D

System Messages

=

you should to install aeolus-al= l to properly use conductor

=

building provider123 50% Complete

****** ## Printable manifest Because our content is not replicated, and all enabled views are included i= n the DOM; = our app can actually print as if it were a manifest for the authenticated u= ser. We get this feature for free by proxy of our method for referencing views a= nd content. Having the ability to produce a hard copy infrastructure report may be a gi= mmick, but it's an easy way to show how conductor can help respond an IT au= dit 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 !important} = } Which means only sections we desire to be included in the manifest get prin= ted 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 grac= efully degrade. Very little effort goes into preserving this feature so lon= g as our standards are maintained. # Existing conductor paradigms These changes don't create any changes to terminology, or have much impact = for pre-existing views for components already built into conductor. It is = likely that the majority of what has already been done will be preserved an= d only undergo minor changes to the HAML/SASS so that features may be integ= rated into the global view. This has been written purely to start discussion on how we evolve Conductor= going forward and I'd love to hear your thoughts: [andy.fitzsimon(a)redhat= .com ](mailto:andy.fitzsimon(a)redhat.com) --===============7812347200950457265== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ui-readme.html" PCFkb2N0eXBlIGh0bWw+CjxodG1sPgo8aGVhZD4KPG1ldGEgY2hhcnNldD0idXRmLTgiPgo8c3R5 bGU+CmgxLApoMiwKaDMsCmg0LApoNSwKaDYsCnAsCmJsb2NrcXVvdGUgewogICAgbWFyZ2luOiAw OwogICAgcGFkZGluZzogMDsKfQpib2R5IHsKICAgIGZvbnQtZmFtaWx5OiAiSGVsdmV0aWNhIE5l dWUiLCBIZWx2ZXRpY2EsICJIaXJhZ2lubyBTYW5zIEdCIiwgQXJpYWwsIHNhbnMtc2VyaWY7CiAg ICBmb250LXNpemU6IDEzcHg7CiAgICBsaW5lLWhlaWdodDogMThweDsKICAgIGNvbG9yOiAjNzM3 MzczOwogICAgbWFyZ2luOiAxMHB4IDEzcHggMTBweCAxM3B4Owp9CmEgewogICAgY29sb3I6ICMw MDY5ZDY7Cn0KYTpob3ZlciB7CiAgICBjb2xvcjogIzAwNTBhMzsKICAgIHRleHQtZGVjb3JhdGlv bjogbm9uZTsKfQphIGltZyB7CiAgICBib3JkZXI6IG5vbmU7Cn0KcCB7CiAgICBtYXJnaW4tYm90 dG9tOiA5cHg7Cn0KaDEsCmgyLApoMywKaDQsCmg1LApoNiB7CiAgICBjb2xvcjogIzQwNDA0MDsK ICAgIGxpbmUtaGVpZ2h0OiAzNnB4Owp9CmgxIHsKICAgIG1hcmdpbi1ib3R0b206IDE4cHg7CiAg ICBmb250LXNpemU6IDMwcHg7Cn0KaDIgewogICAgZm9udC1zaXplOiAyNHB4Owp9CmgzIHsKICAg IGZvbnQtc2l6ZTogMThweDsKfQpoNCB7CiAgICBmb250LXNpemU6IDE2cHg7Cn0KaDUgewogICAg Zm9udC1zaXplOiAxNHB4Owp9Cmg2IHsKICAgIGZvbnQtc2l6ZTogMTNweDsKfQpociB7CiAgICBt YXJnaW46IDAgMCAxOXB4OwogICAgYm9yZGVyOiAwOwogICAgYm9yZGVyLWJvdHRvbTogMXB4IHNv bGlkICNjY2M7Cn0KYmxvY2txdW90ZSB7CiAgICBwYWRkaW5nOiAxM3B4IDEzcHggMjFweCAxNXB4 OwogICAgbWFyZ2luLWJvdHRvbTogMThweDsKICAgIGZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWY7 CiAgICBmb250LXN0eWxlOiBpdGFsaWM7Cn0KYmxvY2txdW90ZTpiZWZvcmUgewogICAgY29udGVu dDoiXDIwMUMiOwogICAgZm9udC1zaXplOjQwcHg7CiAgICBtYXJnaW4tbGVmdDotMTBweDsKICAg IGZvbnQtZmFtaWx5Omdlb3JnaWEsc2VyaWY7CiAgICBjb2xvcjojZWVlOwp9CmJsb2NrcXVvdGUg cCB7CiAgICBmb250LXNpemU6IDE0cHg7CiAgICBmb250LXdlaWdodDogMzAwOwogICAgbGluZS1o ZWlnaHQ6IDE4cHg7CiAgICBtYXJnaW4tYm90dG9tOiAwOwogICAgZm9udC1zdHlsZTogaXRhbGlj Owp9CmNvZGUsIHByZSB7CiAgICBmb250LWZhbWlseTogTW9uYWNvLCBBbmRhbGUgTW9ubywgQ291 cmllciBOZXcsIG1vbm9zcGFjZTsKfQpjb2RlIHsKICAgIGJhY2tncm91bmQtY29sb3I6ICNmZWU5 Y2M7CiAgICBjb2xvcjogcmdiYSgwLCAwLCAwLCAwLjc1KTsKICAgIHBhZGRpbmc6IDFweCAzcHg7 CiAgICBmb250LXNpemU6IDEycHg7CiAgICAtd2Via2l0LWJvcmRlci1yYWRpdXM6IDNweDsKICAg IC1tb3otYm9yZGVyLXJhZGl1czogM3B4OwogICAgYm9yZGVyLXJhZGl1czogM3B4Owp9CnByZSB7 CiAgICBkaXNwbGF5OiBibG9jazsKICAgIHBhZGRpbmc6IDE0cHg7CiAgICBtYXJnaW46IDAgMCAx OHB4OwogICAgbGluZS1oZWlnaHQ6IDE2cHg7CiAgICBmb250LXNpemU6IDExcHg7CiAgICBib3Jk ZXI6IDFweCBzb2xpZCAjZDlkOWQ5OwogICAgd2hpdGUtc3BhY2U6IHByZS13cmFwOwogICAgd29y ZC13cmFwOiBicmVhay13b3JkOwp9CnByZSBjb2RlIHsKICAgIGJhY2tncm91bmQtY29sb3I6ICNm ZmY7CiAgICBjb2xvcjojNzM3MzczOwogICAgZm9udC1zaXplOiAxMXB4OwogICAgcGFkZGluZzog MDsKfQpAbWVkaWEgc2NyZWVuIGFuZCAobWluLXdpZHRoOiA3NjhweCkgewogICAgYm9keSB7CiAg ICAgICAgd2lkdGg6IDc0OHB4OwogICAgICAgIG1hcmdpbjoxMHB4IGF1dG87CiAgICB9Cn0KPC9z dHlsZT4KPHRpdGxlPnVpLXJlYWRtZS5odG1sPC90aXRsZT4KPC9oZWFkPgo8Ym9keT4KPGgxPkdv YWxzIGZvciBhIGJldHRlciBVSTwvaDE+Cgo8YmxvY2txdW90ZT48cD5UaGlzIGlzIGEgcGxhbiB0 byBldm9sdmUgdGhlIGNvbmR1Y3RvciBVSSBpbnRvIGEgbGVhbiwgYWRhcHRpdmUsIGJlYXV0aWZ1 bCBhbmQgY29uc2lkZXJlZCBleHBlcmllbmNlLjwvcD48L2Jsb2NrcXVvdGU+Cgo8aDM+U3BlY2lm aWNhbGx5LCB3ZSBob3BlIHRvIGFkZHJlc3M6PC9oMz4KCjx1bD4KPGxpPjxwPk5hdmlnYXRpbmcg YW5kIGlzc3VpbmcgdGFza3MgcXVpY2tseTwvcD4KCjx1bD4KPGxpPldpdGhvdXQgdW5uZWNlc3Nh cnkgaHR0cC1yb3VuZHRyaXBzIGp1c3QgdG8gY2hlY2sgb24gYSB2aWV3LjwvbGk+CjxsaT5XaXRo b3V0IGhhdmluZyB0byBsZWFybiBuZXcgY29tcG9uZW50cyBpbiBldmVyeSB2aWV3PC9saT4KPGxp PldpdGhvdXQgaGF2aW5nIHRvIHJlZmVyIHRvIGRvY3VtZW50YXRpb24gdG8gYmUgYXNzaXN0ZWQg aW4gY29yZSB0YXNrcy48L2xpPgo8L3VsPgo8L2xpPgo8bGk+PHA+S2VlcGluZyB0aGUg4oCYYmln IDbigJkgY29uc2lzdGVudDo8L3A+Cgo8dWw+CjxsaT5Db25zaXN0ZW50IGFlc3RoZXRpYzwvbGk+ CjxsaT5Db25zaXN0ZW50IGJlaGF2aW91cjwvbGk+CjxsaT5Db25zaXN0ZW50IG5vdGlmaWNhdGlv bjwvbGk+CjxsaT5Db25zaXN0ZW50IG1lc3NhZ2luZzwvbGk+CjxsaT5Db25zaXN0ZW50IGhlbHA8 L2xpPgo8bGk+Q29uc2lzdGVudCByZWZlcmVuY2luZzwvbGk+CjwvdWw+CjwvbGk+CjxsaT48cD5B ZGRyZXNzIGFzIG1hbnkgbWVkaWEgdHlwZXMgYXMgd2UgY2FuIGdldCA8ZW0+Zm9yIGZyZWU8L2Vt PjwvcD4KCjx1bD4KPGxpPjxzdHJvbmc+TW9iaWxlPC9zdHJvbmc+ICZuZGFzaDsgNDgwcHggYW5k IHVwIHZpYSBtaW5vciBhY2NvbW1vZGF0aW9ucyBpbiBvdXIgVUk8L2xpPgo8bGk+PHN0cm9uZz5X b3Jrc3RhdGlvbjwvc3Ryb25nPiA2NDBweC0xMjgwcHggJm5kYXNoOyBvdXIgZGVmYXVsdCB2aWV3 PC9saT4KPGxpPjxzdHJvbmc+U2VjdGlvbiA1MDg8L3N0cm9uZz4gY29tcGxpYW5jZSBpbmNsdWRp bmcgc2NyZWVuIHJlYWRlcnM8L2xpPgo8bGk+PHN0cm9uZz5QcmludGFibGU8L3N0cm9uZz4gJm5k YXNoOyBBcyBhIHJlYWQtb25seSBpbnZlbnRvcnkgbWFuaWZlc3Qgb2YgYSB1c2VycyBlbnRpcmUg YWNjZXNzLjwvbGk+CjwvdWw+CjwvbGk+CjxsaT48cD5GZWVsIGxpa2UgYSAyMDEyIGNsaWVudCBh cHA8L3A+Cgo8dWw+CjxsaT5DdXR0aW5nIGVkZ2UgVUkgY29udmVudGlvbnM8L2xpPgo8bGk+U3dp c3Mgc3R5bGUgdmlzdWFsIG1ldGFwaG9ycyAmYW1wOyBlbGVtZW50cyBvZiB0eXBvZ3JhcGhpYyBz dHlsZTwvbGk+CjxsaT5CYXNlbGluZSBncmlkIGFsaWduZWQgdHlwb2dyYXBoeSBjb25zaXN0aW5n IG9mIDIgd2VpZ2h0cyB3aXRoIHNpbmdsZSBsZWFkaW5nLjwvbGk+CjxsaT5Vc2Ugb25seSB2ZWN0 b3IgZ3JhcGhpY3M8L2xpPgo8bGk+QmxhemluZ2x5IGZhc3QgY2xpZW50IHNpZGUgcmVuZGVyIHRp bWVzPC9saT4KPC91bD4KPC9saT4KPC91bD4KCgo8aDE+R2xvc3Nhcnkgb2YgdGVybXMgLyBleHBs YW5hdGlvbiBvZiBmZWF0dXJlcy48L2gxPgoKPGgyPlZpZXdzPC9oMj4KCjxwPk9uZSBkaXN0aW5j dCBjYXRlZ29yeSBvZiBjb250ZW50LjwvcD4KCjxoMz5leHBsYWluZWQ8L2gzPgoKPHA+4oCcdGhl IHVzZXJzIHZpZXfigJ0gb3Ig4oCcdGhlIHByb3ZpZGVycyB2aWV34oCdLgpBIHZpZXdzIG5hbWUg Y2FuIGV2ZW4gYmUgYXMgc3BlY2lmaWMgYXMg4oCcdXNlclhYLXByb3ZpZGVyLXBlcm1pc3Npb25z IHZpZXfigJ0gIG9yIOKAnGFkbWluLXByb3ZpZGVyLXBlcm1pc3Npb25zLXVzZXJYWCB2aWV34oCd PC9wPgoKPHA+Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24gaG93IHdlIGltcGxlbWVudCB2aWV3cywg c2VlICZsc3F1bztWaWV3IGFuY2hvcnMmcnNxdW87IGJlbG93PC9wPgoKPGhyIC8+Cgo8aDI+Q2xh c3NlczwvaDI+Cgo8cD5UaGluayBIVE1ML0NTUy9KUyBjbGFzc2VzPC9wPgoKPHA+Q2xhc3NlcyB0 cmFjayBzdGF0dXMgb3IgY29udGVudCB0eXBlIGJ1dCBub3QgZGlzcGxheS48L3A+Cgo8cHJlPjxj b2RlPiZsdDthIGhyZWY9IiNwcm92aWRlcjIzIiBjbGFzcz0icHJvdmlkZXIyMyBlbmFibGluZyBl YzIiICZndDtvbmxpbmUmbHQ7L2EmZ3Q7YAombHQ7ZGl2IGlkPSJwcm92aWRlcjIzIiBjbGFzcz0i cHJvdmlkZXIyMyBlbmFibGluZyBlYzIiJmd0O0VjMuKApiZsdDsvZGl2Jmd0Owo8L2NvZGU+PC9w cmU+Cgo8aDM+Q2xhc3NpbmcgY29udmVudGlvbjwvaDM+Cgo8aDQ+UmVzZXJ2ZWQgY2xhc3Nlczwv aDQ+Cgo8cHJlPjxjb2RlPi5hY3RpdmUgCjwvY29kZT48L3ByZT4KCjxwPmlzIHJlc2VydmVkIGZv ciBuYXZpZ2F0aW5nIHZpZXdzPC9wPgoKPHByZT48Y29kZT4uZW5hYmxpbmcgLmRpc2FibGluZyAu dmVyaWZ5aW5nIC5kZWxldGluZyAucmVxdWVzdGluZwo8L2NvZGU+PC9wcmU+Cgo8cD5hcmUgYWN0 aW9uIGNsYXNzZXMgcmVzZXJ2ZWQgZm9yIGNsaWVudCBzaWRlIGFjdGlvbiBjb25maXJtYXRpb248 L3A+Cgo8cHJlPjxjb2RlPi5lbmFibGVkIC5kaXNhYmxlZCAudmVyaWZpZWQgLmNvbXBsZXRlIC5i dWlsZGluZwo8L2NvZGU+PC9wcmU+Cgo8cD5hcmUgYWN0aW9uIGNsYXNzZXMgcmVzZXJ2ZWQgZm9y IHNlcnZlciBldmVudHM8L3A+Cgo8cHJlPjxjb2RlPi53YXJuaW5nIC5ub3RlIC5pbmZvIC50aXAg LmNhdXRpb24KPC9jb2RlPjwvcHJlPgoKPHA+YXJlIHJlc2VydmVkIGZvciBhc3Npc3RpdmUgY29u dGVudDwvcD4KCjxwcmU+PGNvZGU+LnN0YXRpYy1yZWZlcmVuY2UgLmFzc2lzdC1yZWZlcmVuY2UK PC9jb2RlPjwvcHJlPgoKPHA+cmVzZXJ2ZWQgZm9yIGFuY2hvcmVkIGNsb25lcyBvZiBjb250ZW50 IHZpYSBzdGF0aWMgYW5kIGFzc2lzdGl2ZSByZWZlcmVuY2luZyAoc2VlIHNlY3Rpb24pPC9wPgoK PHByZT48Y29kZT4ucHJvZ3Jlc3MgLmxvYWRpbmcgLmJ1aWxkaW5nIC5jb21waWxpbmcgLmFsdGVy aW5nCjwvY29kZT48L3ByZT4KCjxwPmFyZSBwcm9ncmVzcyBjbGFzc2VkIHRvIGJlIHVzZWQgaW4g Y29uanVuY3Rpb24gd2l0aCBhIG51bWVyaWNhbCBjbGFzczwvcD4KCjxwcmU+PGNvZGU+LjUwIC4x MCAuMjAgLjI1IC43NSAuMTAwIC4zMCBldGPigKYKPC9jb2RlPjwvcHJlPgoKPHA+YXJlIHBlcmNl bnRhZ2UgY2xhc3NlcyB0byBiZSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGggYSB2YWx1ZTwvcD4K CjxwPmUuZy46IDxjb2RlPiZsdDtzcGFuIGNsYXNzPSI3NSB1c2FnZSImZ3Q7NzUlIG9mIDMwMGdi ICZsdDsvLi4uPC9jb2RlPgpvciBiZXR0ZXI6IDxjb2RlPiZsdDtzcGFuIGNsYXNzPSI3NSB1c2Fn ZSImZ3Q7MjI1Z2Igb2YgMzAwZ2IgJmx0Oy8uLi48L2NvZGU+PC9wPgoKPHByZT48Y29kZT4udXNh Z2UgLnByb2dyZXNzIC5sb2FkIC5jYXBhY2l0eQo8L2NvZGU+PC9wcmU+Cgo8cD5hcmUgPHN0cm9u Zz5zdGF0dXM8L3N0cm9uZz4gY2xhc3NlcyByZXNlcnZlZCBmb3IgaWRlbnRpZnlpbmcgdGhlIDxz dHJvbmc+dHlwZTwvc3Ryb25nPiBvZiBtZWFzdXJlbWVudDwvcD4KCjxwcmU+PGNvZGU+Lmluc3Rh bmNlIC5wcm92aWRlciAudXNlciAucG9vbCAuZ3JvdXAKPC9jb2RlPjwvcHJlPgoKPHA+YXJlIG9i amVjdCBjbGFzc2VzIHRvIGJlIHVzZWQgb24gYW55IG9iamVjdDwvcD4KCjxoMz5MYWNrIG9mIGNs YXNzZXMgZm9yIGxheW91dDwvaDM+Cgo8cD5XZSB3aWxsIDxzdHJvbmc+Tk9UPC9zdHJvbmc+IHVz ZSBjbGFzc2VzIGZvciBkZWZpbmluZyBncmlkIGxheW91dCBlLmcuIDxjb2RlPi5zcGFuLTEyPC9j b2RlPiBvciA8Y29kZT4ubGVmdC0xMjAvPC9jb2RlPjwvcD4KCjxwPkFsbCBsYXlvdXRzIHdpbGwg YmUgZGVmaW5lZCBpbiBDU1MgdmlhIGEgY29tYmluYXRpb24gb2YgdGhlaXIgcGFyZW50IHZpZXcg YW5kIHRoZSByZWxldmFudCBtZWRpYSBxdWVyeS48L3A+Cgo8cD5mb3IgZXhhbXBsZSB3ZSB3aWxs IHVzZSB0aGUgQ1NTPC9wPgoKPHByZT48Y29kZT4jYWRtaW4gI3Byb3ZpZGVycyAuYWNjb3VudCAu c3VtbWFyeXt3aWR0aDozMy4zMzMlfQo8L2NvZGU+PC9wcmU+Cgo8cD5yYXRoZXIgdGhhbiByZWx5 aW5nIG9uIGluamVjdGluZyBzdHlsZSBsb2dpYyBpbnRvIHRoZSBodG1sIGxpa2UgdGhpcyA8Y29k ZT4mbHQ7Y2xhc3M9InN1bW1hcnkgc3Bhbi00IiZndDs8L2NvZGU+PC9wPgoKPGhyIC8+Cgo8aDI+ R3JhY2VmdWwgZGVncmFkYXRpb248L2gyPgoKPHA+U3VwcG9ydCBmb3IgYWxsIGNvcmUgZnVuY3Rp b25hbGl0eSBpbiBhcyBtYW55IHNjZW5hcmlvcyBhcyBwb3NzaWJsZTwvcD4KCjx1bD4KPGxpPk5l dyBicm93c2VyIGZlYXR1cmVzIChzdWJ0bGUgYW5pbWF0aW9uLCBncmFkaWVudHMgZXRjKTwvbGk+ CjxsaT5PbGRlciBicm93c2VycyBsYWNraW5nIGZlYXR1cmVzPC9saT4KPGxpPkJyb3dzZXJzIHdp dGggamF2YXNjcmlwdCB0dXJuZWQgb2ZmPC9saT4KPGxpPlNjcmVlbiByZWFkZXJzIChzZWN0aW9u IDUwOCwgd2XigJlyZSBnb2luZyB0aGVyZSk8L2xpPgo8L3VsPgoKCjxociAvPgoKPGgyPlJlc3Bv bnNpdmUgZGVzaWduPC9oMj4KCjxwPlN1cHBvcnQgZm9yIHZpZXdpbmcgZnJvbSB2YXJpb3VzIG1l ZGlhIGVnICBjZWxscGhvbmVzLCB0b3VjaHNjcmVlbiBkZXZpY2VzLCBraW9za3MsIHR24oCZcywg ZXZlbiBwcmludC48L3A+Cgo8aDM+RXhwbGFpbmVkPC9oMz4KCjxvbD4KPGxpPldlIGNvbGxhcHNl IHRhYmxlcyBpbnRvIHJlY29yZCB2aWV3cyBmb3IgbmFycm93IHNjcmVlbnMuPC9saT4KPGxpPldl IEdyb3cgZm9udHMgYW5kIGljb25zIGZvciB0cmVtZW5kb3VzbHkgaGlnaCByZXNvbHV0aW9ucyBv ciB0b3VjaGFibGUgbGFyZ2Ugc2NyZWVucy48L2xpPgo8bGk+V2UgdXNlIG9ubHkgdmVjdG9yIGdy YXBoaWNzIChjc3MgL3dlYmZvbnRzKSBmb3IgYWRhcHRpdmUgc2NhbGluZyBhbmQgdGhlbWVpbmcu CkFuY2hvciByZWZlcmVuY2luZyB3aXRoIGpzIGlubGluaW5nIG1lYW5zIHJlcGVhdGVkIGNvbnRl bnQgaXMgcHJpbnRlZCBvbmx5IG9uY2UuICBhIHByaW50IHZlcnNpb24gd291bGQgcmVhZCBsaWtl IGFuIGluZnJhc3RydWN0dXJlIHN0YXR1cyByZXBvcnQgZnJvbSB0aGUgdXNlcnMgcGVyc3BlY3Rp dmUuPC9saT4KPC9vbD4KCgo8aHIgLz4KCjxoMj5WaXN1YWwgTWV0YXBob3JzICZhbXA7IFZlY3Rv ciBHcmFwaGljczwvaDI+Cgo8cD5WaXN1YWwgbWV0YXBob3JzIGFyZSBncmFwaGljcyBzeW1ib2xp YyBvZiB0aGUgZnVuY3Rpb24gdGhleSBwZXJmb3JtLgpWZWN0b3IgZ3JhcGhpY3MgYXJlIGEgcmVz b2x1dGlvbiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbi48L3A+Cgo8aDM+RXhwbGFpbmVkPC9o Mz4KCjxwPkFsbCBpY29ucywgdmlzdWFsIGluZGljYXRvcnMgYW5kIG9ybmFtZW50YWwgZ3JhcGhp Y3MgIGFyZSBpbXBsZW1lbnRlZCBsaWtlIHRoaXM6PC9wPgoKPHVsPgo8bGk+VmVjdG9yIGdseXBo cyBhcmUgZW5jb2RlZCBpbnRvIGEgd29mZiB3ZWJmb250PC9saT4KPGxpPlRoZSB3b2ZmIGZvbnQg aXMgYmFzZTY0IGVuY29kZWQgaW4gdGhlIHN0eWxlc2hlZXQgdG8gbWluaW1pc2UgaHR0cCByZXF1 ZXN0cyAodGhlIGN1cnJlbnQgc2V0IG9mIDMwIGljb25zIGlzIH41aykgc28gdGhpcyBpcyB2ZXJ5 IGFjY2VwdGFibGUuPC9saT4KPGxpPldlIGZhbGxiYWNrIHRvIHVybCBsaW5rZWQgaW1hZ2VzIHN1 cHBsaWVzIGZvciBsZWdhY3kgYnJvd3NlcnMgKG5vIC5XT0ZGIHN1cHBvcnQpIGJ5IHVzaW5nIDxh IGhyZWY9Imh0dHA6Ly93d3cubW9kZXJuaXpyLmNvbS8iPm1vZGVybml6cjwvYT4gY2xhc3NlcyA8 Y29kZT4ubm8td2ViZm9udHM8L2NvZGU+IGFuZCA8Y29kZT4ud2ViZm9udHM8L2NvZGU+IHRvIGRp c2NyaW1pbmF0ZSBvdXIgaW1wbGVtZW50YXRpb24gdGhyb3VnaCBjc3M8L2xpPgo8L3VsPgoKCjxo ciAvPgoKPGgyPlZpZXcgYW5jaG9ycyAmbmRhc2g7IG9yICZsc3F1bztzaW5nbGUgcGFnZSBhcHAm cnNxdW87PC9oMj4KCjxwPlZpZXcgYW5jaG9ycyBhcmUgcG9ydGlvbnMgb2Ygb3VyIGRlc2lnbiBp bXBsZW1lbnRlZCB3aXRoaW4gdGhlIG9uZSBET00gdXNpbmcgYmFzaWMgYW5jaG9yaW5nIGZ1bmN0 aW9uYWxpdHkuPC9wPgoKPGgzPkV4cGxhaW5lZDwvaDM+Cgo8cD5JbiB0aGUgcHJvcG9zZWQgY2hh bmdlLCB0aGUgZW50aXJlIGNvbmR1Y3RvciBpcyBvbmUgcGFnZSBmb3IgYWxsIGRlZmF1bHQgdmll d3MsPC9wPgoKPG9sPgo8bGk+PHA+TGluayBhbmNob3JzIHdpbGwgYWN0aXZhdGUgdGhlIHNwZWNp ZmljIHZpZXcgb3Igc3ViLXZpZXcuPC9wPjwvbGk+CjxsaT48cD5BbmNob3JzIHRoYXQgZG8gbm90 IHJlc29sdmUgd2lsbCBpbml0aWF0ZSBhICZsZHF1bztjYW5ub3QgZmluZCZyZHF1bzsgbWVzc2Fn ZSB3aGljaCB3aWxsIG1vc3QgY29tbW9ubHkgb2NjdXIgd2hlbiBhIHVzZXIgZG9lcyBub3QgaGF2 ZSBhY2Nlc3MgdG8gYW4gb2JqZWN0IGFuZCBoYXMgbWFudWFsbHkgZW50ZXJlZCBhIGN1c3RvbSAj IFVSTC4gIHRoZSB0d28gZXhjZXB0aW9ucyB0byB0aGlzIHdpbGwgYmUgfi8jIGFuZCB+LyN0b3Ag d2hpY2ggd2lsbCBpbml0aWF0ZSB0aGUgZGVmYXVsdCBhcHAgdmlldy48L3A+PC9saT4KPC9vbD4K Cgo8aDM+SW4gYWN0aW9uPC9oMz4KCjxwPkZvciBleGFtcGxlOjwvcD4KCjxibG9ja3F1b3RlPjxw PlRoZSBVUkwgYmVsb3cgc2hvdWxkIG9wZW4gdGhlIGFkbWluID4gcHJvdmlkZXJzID4gZWMyZWFz dGNvYXN0ID4gY29ubmVjdGl2aXR5IHZpZXcuPC9wPjwvYmxvY2txdW90ZT4KCjxwcmU+PGNvZGU+ aHR0cHM6Ly9jb25kdWN0b3IvI2VjMmVhc3Rjb2FzdC1jb25uZWN0aXZpdHkKICAgICAgICAgICBe ICAgICAgICAgICAgXiAgICAgICAgICAgICAgXgogICAgICAgIFNlcnZlciAgICAgT2JqZWN0SUQg ICAgICAgQ2hpbGRWaWV3CjwvY29kZT48L3ByZT4KCjxoND5XaGF0IHRoZSBodG1sIGRvZXM8L2g0 PgoKPHA+ZS5nLiB0aGUgPGNvZGU+Jmx0O2RpdiZndDs8L2NvZGU+IHJlcHJlc2VudGluZyBhZG1p biA+IHByb3ZpZGVycyA+IGVjMmVhc3Rjb2FzdCB3b3VsZCBsb29rIGxpa2U8L3A+Cgo8cHJlPjxj b2RlPiZsdDtkaXYgaWQ9ImVjMmVhc3Rjb2FzdCImZ3Q7Li4gZWMyIGVhc3QgY29hc3QgaW5mb3Jt YXRpb24gZ29lcyBoZXJlCjwvY29kZT48L3ByZT4KCjxwPmFuZCB0aGUgY29ubmVjdGl2aXR5IHRh YiB3aGljaCBleGlzdHMgaW5zaWRlIHRoZSBlYzJlYXN0Y29hc3QgcHJvdmlkZXIgd291bGQgbG9v ayBsaWtlPC9wPgoKPHByZT48Y29kZT4mbHQ7ZGl2IGlkPSJlYzJlYXN0Y29hc3QtY29ubmVjdGl2 aXR5IiZndDsKICAgICAgICAgICAgIF4gICAgICAgICAgICAgXgogICAgICAgICBvYmplY3RJRCAg ICAgICBDaGlsZFZpZXduYW1lCjwvY29kZT48L3ByZT4KCjxwPldoeT8KQmVjYXVzZSB0aGUgcHJv dmlkZXIgPGVtPmVjMmVhc3Rjb2FzdDwvZW0+IGxpdmVzIG5hdGl2ZWx5IHdpdGhpbiB0aGUgPGVt PmFkbWluID4gcHJvdmlkZXI8L2VtPiBzZWN0aW9uLCBpdCBkb2VzIG5vdCBuZWVkIHRvIGJlIHJl ZmVyZW5jZWQgaW4gdGhlIElELi4gaXQgc2ltcGx5IGhhcyB0byBiZSB1bmlxdWUuICBCdXQgYmVj YXVzZSB0aGUgY29ubmVjdGl2aXR5IHRhYiBpcyBvbmx5IHVuaXF1ZSBiZWNhdXNlIG9mIHRoZSBw cm92aWRlciBpdCBpcyBhc3NvY2lhdGVkIHdpdGgsIGl0IG5lZWRzIHRvIGJlIHByZWZpeGVkIHdp dGggdGhlIG9iamVjdElEPC9wPgoKPHA+QWxsIGRpcmVjdCBsaW5rcyB0byB0aGUgcHJvdmlkZXIg dmlldyB3b3VsZCBsb29rIGxpa2UgYDxhIGhyZWY9I2VjMmVhc3Rjb2FzdD5FQzIgRWFzdCBDb2Fz dDwvYT4gd2hpY2ggd291bGQgYWN0aXZhdGUgdGhlIHByb3ZpZGVyIHRhYi48L3A+Cgo8aDQ+d2hh dCBKUyBkb2VzPC9oND4KCjxvbD4KPGxpPkpTIGhpZGVzIGFsbCBub24gYWN0aXZlIHZpZXdzIGV4 Y2VwdCBmb3IgdGhlIGRlZmF1bHQgdmlldyAoY2xhc3NlZCBhcyBhY3RpdmUgYnkgdGhlIGpzKTwv bGk+CjxsaT48L2xpPgo8bGk+d2hlbiBhbiBJRCBpcyByZXF1ZXN0ZWQgdGhlIG9iamVjdCBhbmQg YWxsIHBhcmVudCB2aWV3cyBnZXQgY2xhc3NlZCA8Y29kZT4uYWN0aXZlPC9jb2RlPjwvbGk+Cjxs aT48YSBocmVmPSJodHRwOi8vYmVuYWxtYW4uY29tL3Byb2plY3RzL2pxdWVyeS1oYXNoY2hhbmdl LXBsdWdpbi8iPmhhc2hjaGFuZ2UgZm9yIG9sZCBicm93c2VyczwvYT4gIHRvIHByZXNlcnZlIGJy b3dzaW5nIGhpc3Rvcnk8L2xpPgo8L29sPgoKCjxoND53aGF0IHRoZSBDU1MgZG9lczwvaDQ+Cgo8 cD5UaGUgYm9keSBjbGFzcyA8Y29kZT4ubm9qczwvY29kZT4gaXMgcmVtb3ZlZCBvbmNlIEphdmFz Y3JpcHQgaXMgbG9hZGVkIHNvIHRoZSBDU1Mgc3BlY2lmaWVzIHRoYXQgb25seSB2aWV3cyBiZSB2 aXNpYmxlIHdoZW4gdGhleSBhcmUgY2xhc3NlZCBhcyA8Y29kZT4uYWN0aXZlPC9jb2RlPjwvcD4K CjxwcmU+PGNvZGU+LmpzIGRpdntkaXNwbGF5Om5vbmV9ICAgICAgICAgLy8gSGlkaW5nIGFsbCB2 aWV3cwouanMgZGl2LmFjdGl2ZXtkaXNwbGF5OmJsb2NrfSAvLyBTaG93aW5nIGFjdGl2ZSB2aWV3 cwoubm9qcyBkaXZ7ZGlzcGxheTpibG9ja30gICAgICAvLyBBbGwgdmlld3MgYXJlIHNob3duIHdo ZW4gdGFicyBkb24ndCB3b3JrLgo8L2NvZGU+PC9wcmU+Cgo8aHIgLz4KCjxoMj5SZWZlcmVuY2Vk IGNvbnRlbnQ8L2gyPgoKPGJsb2NrcXVvdGU+PHA+UmVmZXJlbmNlZCBjb250ZW50IGlzIGEgbGl2 ZS1jb3B5IG9mIGFueSBleGlzdGluZyBwYXJ0IG9mIHRoZSBhcHBsaWNhdGlvbi4gSXQgY2FuIGJl IGltcGxlbWVudGVkIHdpdGggc3RhdGljIHJlZmVyZW5jZXMgb3IgYXNzaXN0aXZlIHJlZmVyZW5j ZXM8L3A+Cgo8cD5TZWUgPGEgaHJlZj0iaHR0cDovL2pzZmlkZGxlLm5ldC9hbmR5Zml0ei9oUnFH YS8xOTEvIj50aGlzIEpTIEZpZGRsZSBkZW1vPC9hPjwvcD48L2Jsb2NrcXVvdGU+Cgo8aDQ+ZXhh bXBsZTwvaDQ+Cgo8b2w+CjxsaT5HbG9iYWwgaGVscCBjb250ZW50IGNhbiBiZSByZWZlcmVuY2Vk IGZyb20gbWFueSBwbGFjZXMgYXQgb25jZSBzbyBhcyB0byBhdm9pZCByZWR1bmRhbmN5IGFuZCBh bm5veWluZyBhamF4IHJlcXVlc3RzLi4gaWYgdGhlIHNlY3Rpb24gdGhlIGhlbHAgY29tZXMgZnJv bSBpcyBsb2FkZWQsIHNvIGlzIHRoZSBoZWxwLjwvbGk+CjxsaT5JbnNwZWN0aW5nIGFuIG9iamVj dCB2aWEgYSBsaW5rIGNhbiBjYWxsIHRoZSBvYmplY3RzIGVudGlyZSBjb250ZW50IGludG8gdmll dy48L2xpPgo8L29sPgoKCjxociAvPgoKPGgzPlN0YXRpYy1yZWZlcmVuY2VzPC9oMz4KCjxwPldo ZXJlIGFuIGFuY2hvciBsaW5rIHRvIGFub3RoZXIgc2VjdGlvbiBoYXMgYmVlbiByZXBsYWNlZCB3 aXRoIGEgbGl2ZSBjb3B5IG9mIHRoZSBzZWN0aW9uIGl0IGxpbmtzIHRvLjwvcD4KCjxwcmU+PGNv ZGU+LnN0YXRpYy1yZWZlcmVuY2UKPC9jb2RlPjwvcHJlPgoKPGJsb2NrcXVvdGU+PHA+QW4gZXhh bXBsZSB3b3VsZCBiZSBhbnkgbW9uaXRvcmluZyB2aWV3IHRoYXQgcmVxdWlyZXMgdmFyaW91cyBt ZXRyaWNzIGFscmVhZHkgcmVuZGVyZWQgZWxzZXdoZXJlIGJlIGluY2x1ZGVkLjwvcD48L2Jsb2Nr cXVvdGU+Cgo8aHIgLz4KCjxoMz5Bc3Npc3QtcmVmZXJlbmNlczwvaDM+Cgo8cD5saWtlIGEgc3Rh dGljIHJlZmVyZW5jZSBidXQgd2l0aCB0aGUgbGluay10ZXh0IHByZXNlcnZlZCBhbmQgdGhlIHNl Y3Rpb24gb25seSB2aXNpYmxlIHdoZW4gdGhlIGxpbmstdGV4dCBoYXMgZm9jdXMgKGhhcyBiZWVu IGNsaWNrZWQpLjwvcD4KCjxwcmU+PGNvZGU+LmFzc2lzdC1yZWZlcmVuY2UKPC9jb2RlPjwvcHJl PgoKPGJsb2NrcXVvdGU+PHA+QW4gZXhhbXBsZSB3b3VsZCBiZSBhIHBlcm1pc3Npb25zIGVkaXRv ciByZWZlcmVuY2luZyB0aGUgb2JqZWN0cyB0aGF0IGEgdXNlciBoYXMgcGVybWlzc2lvbnMgdG8g YnkgbmFtZSAgYW5kIGFsbG93aW5nIHRoZSB1c2VyIHRvIGluc3BlY3QgdGhhdCBvYmplY3QgaW4t cGxhY2Ugd2l0aCBhIHNpbmdsZSBjbGljaywgd2l0aG91dCBoYXZpbmcgdG8gdmlzaXQgdGhlIG9i amVjdCBpbiBxdWVzdGlvbnMgZGVmYXVsdCB2aWV3LjwvcD48L2Jsb2NrcXVvdGU+Cgo8aHIgLz4K CjxoMj5IZWxwICZhbXA7IGNvbnRlbnQ8L2gyPgoKPHA+V3JpdHRlbiBjb250ZW50IHRvIGhlbHAg ZGVzY3JpYmUgYSBmZWF0dXJlIG9yIHNjZW5hcmlvLgpDb21iaW5lZCB3aXRoIGFkbW9uaXRpb24g Y2xhc3NlczwvcD4KCjxwcmU+PGNvZGU+Lndhcm5pbmcgLm5vdGUgLmluZm8gLnRpcCAuY2F1dGlv bgo8L2NvZGU+PC9wcmU+Cgo8cD5PZnRlbiBpbXBsZW1lbnRlZCB2aWEgb25lIG9mIHRoZSBmb2xs b3dpbmcgbWV0aG9kczwvcD4KCjx1bD4KPGxpPkluY2x1ZGVkIGluIHRoZSB2aWV3IHJlbGV2YW50 IHRvIGl0cyBkZXNjcmlwdGlvbjwvbGk+CjxsaT5BcyBzdGF0aWMtcmVmZXJlbmNlcyB3aGVyZSB0 aGUgaGVscCBjb250ZW50IGNhbiBiZSBkaXNtaXNzZWQgKHZpYSBhbiBYIGluIHRoZSB0b3Agcmln aHQgY29ybmVyKTwvbGk+CjxsaT5BcyBhc3Npc3QtcmVmZXJlbmNlcyB3aGVyZSB0aGUgaGVscCBj b250ZW50IGNhbiBiZSByZXZlYWxlZCB1cG9uIGNsaWNraW5nIGEgcmVmZXJyaW5nIGxpbms8L2xp Pgo8L3VsPgoKCjxwPlByYWN0aWNhbGx5IHNwZWFraW5nIHRoaXMgaXMgdGV4dCB0aGF0IGNhbiBi ZSBwbGFjZWQgaW5saW5lIHdpdGggYSB2aWV3IHRoYXQgaXQgcmVwcmVzZW50cyBvciBoaWRkZW4g aW4gYSBub24gZGlzcGxheWVkIHVzZWZ1bCBjb250ZW50IGFyZWEgdG8gYmUgc3RhdGljIG9yIGFz c2lzdC1yZWZlcmVuY2VkIGJ5IG1hbnkgcGxhY2VzLjwvcD4KCjxoMz5FeHBsYWluZWQ8L2gzPgoK PHA+Rm9yIGV4YW1wbGU6ICA8ZW0+4oCcZG9u4oCZdCBiZSBzaWxseeKAnDwvZW0+IGlzIGEgZ2Vu ZXJpYyB0aXAgdGhhdCBtYXkgYXBwbHkgdG8gYW4gZW5vcm1vdXMgdmFyaWV0eSBvZiBjb250ZXh0 cy4gIFRoaXMgaXMgdXNlZnVsIHRvIGJlIHBsYWNlZCBpbiB0aGUgJmxkcXVvO2dlbmVyaWMgdGlw cyZyZHF1bzsgYXJlYSBhbmQgbGlua2VkIHRvIHZpYSA8Y29kZT4mbHQ7YSBocmVmPeKAnSNkb250 IGJlLXNpbGx54oCdIGNsYXNzPeKAnWFzc2lzdC1yZWZlcmVuY2XigJ0mZ3Q7bm93IHBsZWFzZSBy ZW1lbWJlci4uJmx0Oy9hJmd0OzwvY29kZT4gd2hpY2ggbWVhbnMgaXQgd2lsIGJlIHJlbmRlcmVk IGlubGluZSBvZiB3aGVyZSBpdCBpcyByZWZlcmVuY2VkLjwvcD4KCjxociAvPgoKPGgyPkNsaWVu dC1zaWRlIHN0YXR1cyBwb2xsaW5nPC9oMj4KCjxwPkFsbCBvYmplY3RzIHJlbGV2YW50IHRvIGEg dmlldyBhcmUgY2xhc3NlZCB3aXRoIHRoZSB2aWV3bmFtZQpPbiBhbnkgYWN0aW9uIGluc2lkZSB0 aGUgdmlldywgYSBzdGF0dXMgY2xhc3NuYW1lIGlzIGFkZGVkIHRvIHRoZSB2aWV3IGFzIHdlbGwg YXMgYW55IG9iamVjdHMgdGhhdCByZWZlcmVuY2UgaXQgcmVnYXJkbGVzcyBvZiB3aGVyZSB0aGV5 IGFyZSBkaXNwbGF5ZWQ8L3A+Cgo8cHJlPjxjb2RlPiZsdDthIGhyZWY9I3VzZXIgY2xhc3M94oCd dXNlclhYIGVuYWJsaW5n4oCdJmd0O2xpbmsmbHQ7L2EmZ3Q7IAombHQ7ZGl2IGlkPSPigJ11c2Vy WFjigJ0gY2xhc3M94oCddXNlclhYIGVuYWJsaW5n4oCdICZndDtVc2VyWFggVmlldyZsdDsvZGl2 Jmd0Oy4KPC9jb2RlPjwvcHJlPgoKPHA+V2Ugd2F0Y2ggdGhlIHJlZmVyZW5jZWQgdmlld3MgY2xh c3NlcyBhbmQgbWltaWMgdGhlbSBvbiBhbGwgcmVmZXJlbmNpbmcgbGlua3MgYWx3YXlzIGFzIHRo ZXkgY2FuIGNvbnRhaW4gb3IgYmUgdXBkYXRlZCB3aXRoIG5ldyBldmVudCBzdHlsZXMgKGZvciBl eGFtcGxlOiBmYWlsZWQsIHdhcm5pbmcsIHVwZ3JhZGVkLCBhZG1pbi1vbmx5IGV0Yyk8L3A+Cgo8 aHIgLz4KCjxoMj5TZXJ2ZXIgc3RhdHVzIGV2ZW50cyA8ZW0+aW52ZXN0aWdhdGluZzwvZW0+PC9o Mj4KCjxwPlJpZ2h0IG5vdyB3ZSBjYW4gdXNlIGFqYXggY2FsbHMgdG8gdXBkYXRlIGVhY2ggdmll dyBidXQgaW4gZnV0dXJlIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gdXNlIGV2ZW50U291cmNlIGZv ciBtb3JlIGFkdmFuY2VkIG1vbml0b3Jpbmc6IDxhIGhyZWY9Imh0dHA6Ly9odG1sNWRvY3Rvci5j b20vc2VydmVyLXNlbnQtZXZlbnRzLyI+ZXZlbnRTb3VyY2U6IHNlcnZlciBzZW50IGV2ZW50czwv YT48L3A+Cgo8aHIgLz4KCjxoMj5DbGllbnQgdmVyaWZpY2F0aW9uIC8gZmFzdCBmZWVkYmFjazwv aDI+Cgo8cD5JbnRlcmFjdGl2ZSBhc3N1cmFuY2UgdGhhdCBhbiBhY3Rpb24gaGFzIGJlZW4gcmVx dWVzdGVkIHdpdGhvdXQgdGhlIHZlcmlmaWNhdGlvbiB0aGF0IHRoZSBzZXJ2ZXIgaGFzIHBlcmZv cm1lZCB0aGUgYWN0aW9uLjwvcD4KCjxwPkZvciBleGFtcGxlIGEgdXNlciBjbGlja3MgdGhlIGVu YWJsZSBidXR0b24uLiB3ZSBpbW1lZGlhdGVseSBhcHBseSDigJxlbmFibGluZ+KAnSBzdGF0dXMg dG8gdGhlIGJ1dHRvbiBidXQgd2FpdCBmb3IgdGhlIHNlcnZlciB0byByZXR1cm4gd2l0aCB0aGUg 4oCcZW5hYmxlZOKAnSBjb25maXJtYXRpb24maGVsbGlwOzwvcD4KCjxoMz5Ib3cgaXQgd29ya3M8 L2gzPgoKPGJsb2NrcXVvdGU+PHA+PHN0cm9uZz5Bc3N1bXB0aW9uPC9zdHJvbmc+IGludGVybWl0 dGVudCBzdGF0ZXMgbGlrZSB2ZXJpZnlpbmcsIGVuYWJsaW5nIGFuZCBkaXNhYmxpbmcgc3RhdGVz IGFyZSBzYWZlIGZvciBjbGllbnQgc2lkZSB2YWxpZGF0aW9uLjwvcD4KCjxwPlRoZXkgY29uZmly bSBhbiBhY3Rpb24gaGFzIGJlZW4gcmVxdWVzdGVkIGJ1dCBub3QgYXBwbGllZC48L3A+PC9ibG9j a3F1b3RlPgoKPHA+QXMgYSBydWxlLCBhbGwgZWxlbWVudHMgYXJlIGdpdmVuIHRoZSBzdGF0dXMg b2YgdGhlIG9iamVjdHMgdGhleSByZXByZXNlbnQgYXMgd2VsbCBhcyBjbGFzc2VkIHdpdGggdGhl IG9iamVjdCBJRC4uICBlLmcuOiBhbGwgYnV0dG9ucyB3aXRoIDxjb2RlPmNsYXNzPSJwcm92aWRl cmlkMTI0NTEtKiI8L2NvZGU+IGdldCB0aGUgYWRkaXRpb25hbCBjbGFzcyBvZiB0aGVpciBpbnRl cm1pdHRlbnQgc3RhdGUgPGNvZGU+ImVuYWJsaW5nL2Rpc2FibGluZy92ZXJpZnlpbmcvd2hhdGV2 ZXIiPC9jb2RlPiAgV2hlbiBhIGZ1bmN0aW9uYWwgb2JqZWN0IHJlbGF0ZWQgdG8gdGhlbSBoYXMg YmVlbiBhY3Rpb25lZC48L3A+Cgo8b2w+CjxsaT48cD5PbiB0aGUgY2xpZW50IGphdmFzY3JpcHQg c2lkZSwgd2Ugc2V0IHRoZSBhY3Rpb25pbmcgY2xhc3NuYW1lIHRvIGFsbCBlbGVtZW50cyB3aXRo IHRoZSBzYW1lIG9iamVjdCBvYmplY3RpZCBjbGFzcy48L3A+PC9saT4KPGxpPjxwPk9uY2UgdGhl IGFjdGlvbiBoYXMgYmVlbiBkb25lIGFuIGFqYXggY2FsbCBjb25maXJtIHRoZSBjaGFuZ2UgYW5k IHJlZnJlc2hlcyB0aGUgY2xhc3MgdG8gJmxkcXVvO2VuYWJsZWQvZGlzYWJsZWQvZG9uZS93aGF0 ZXZlciZyZHF1bzsgYW5kIHJlbW92ZXMgdGhlIGludGVybWVkaWFyeSBzdGF0ZTwvcD48L2xpPgo8 L29sPgoKCjxociAvPgoKPGgyPkltcG9ydGFudCBhY3Rpb24gY2VydGlmaWNhdGlvbjwvaDI+Cgo8 cD48YSBocmVmPSJodHRwOi8vanNmaWRkbGUubmV0L2FuZHlmaXR6L212ZFNULyI+SlMgRmlkZGxl IGRlbW88L2E+PC9wPgoKPHA+UmVxdWlyaW5nIHRoZSB1c2VyIHRvIGNlcnRpZnkgdGhhdCB0aGV5 IHVuZGVyc3RhbmQgdGhlIGFjdGlvbiBiZWZvcmUgYWxsb3dpbmcgaXQgdG8gdGFrZSBwbGFjZS4K Zm9yIGV4YW1wbGU6PC9wPgoKPGJsb2NrcXVvdGU+PHA+4oCcRG8geW91IHVuZGVyc3RhbmQgd2hh dCB5b3UgYXJlIGRvaW5nP1t5ZXNdIG9rYXksIGhlcmXigJlzIHRoZSBidXR0b24gW2NsaWNrXeKA nTwvcD48L2Jsb2NrcXVvdGU+Cgo8aDM+ZXhwbGFpbmVkPC9oMz4KCjxibG9ja3F1b3RlPjxwPkVu YWJsaW5nIGFuZCBkaXNhYmxpbmcgcHJvdmlkZXJzLCAgZGVsZXRpbmcgdXNlcnMgZXRjPC9wPjwv YmxvY2txdW90ZT4KCjxwPldlIHdpbGwgdXNlIHRocmVlIG1ldGhvZHMgdG8gdmVyaWZ5IHRoYXQg YSB1c2VyIGhhcyBhY2NlcHRlZCB0aGUgc2V2ZXJpdHkgb2YgdGhlIHRhc2sgdGhleSBhcmUgYWJv dXQgdG8gcGVyZm9ybTo8L3A+Cgo8b2w+CjxsaT48cD5DU1MgcGh5c2ljYWwgb2JmdXNjYXRpb24u CldoZXJlIHRoZSBjb25maXJtYXRpb24gdG9nZ2xlIHNpdHMgcGh5c2ljYWxseSBvbiB0b3Agb2Yg dGhlIGFjdGlvbiB0b2dnbGUgc28gdGhhdCBhbiBhY3Rpb24gY2FuIG5vdCBiZSBjbGlja2VkIHdp dGhvdXQgY2xpY2tpbmcgdGhlIGNvbmZpcm1hdGlvbiB0b2dnbGUgZmlyc3QuICB0aGlzIGhlbHBz IHNpbXBsaWZ5IHRoZSBjb21wb25lbnQgdG8gb25lIHBoeXNpY2FsIHNwYWNlIHBhcnQgb2YgdGhl IHNhbWUgY29uc2lkZXJhdGlvbiBzZXQuPC9wPjwvbGk+CjxsaT48cD5qYXZhc2NyaXB0IHZhbGlk YXRpb24uPGJyLz4KVGhlIGFjdGlvbiBidXR0b24gYmVuZWF0aCBpcyBkaXNhYmxlZCB1bnRpbCB0 aGUgY29uZmlybWF0aW9uIHRvZ2dsZSBoYXMgYmVlbiBjbGlja2VkPC9wPjwvbGk+CjxsaT5maW5h bCBzZXJ2ZXIgdmVyaWZpY2F0aW9uLjxici8+CnRoZSBzdWJtaXR0ZWQgYWN0aW9uIGlzIG5vdCBh Y2NlcHRlZCBieSB0aGUgc3lzdGVtIHVubGVzcyB0aGUgcG9zdCBjb250YWlucyBib3RoIHRoZSB2 ZXJpZmljYXRpb24gZW5hYmxlZCBhbmQgdGhlIGFjdGlvbi4gdGhlIHNlcnZlciB0aGVuIHB1c2hl cyB0aGUgdXBkYXRlPC9saT4KPC9vbD4KCgo8aHIgLz4KCjxoMj5HbG9iYWwgc3RhdHVzIGFuZCBz eXN0ZW0gbm90aWZpY2F0aW9uIHN0YWNrLjwvaDI+Cgo8cD5JbXBvcnRhbnQgaW5mb3JtYXRpb24g YWJvdXQgdGhlIGVudGlyZSBzeXN0ZW0gb3IgYSBjdXJyZW50IHByb2Nlc3MsIGRpc3BsYXllZCBw cm9taW5lbnRseS48L3A+Cgo8aDM+ZXhwbGFpbmVkPC9oMz4KCjxwPlVzaW5nIHRoZSByZWZlcmVu Y2VkIGNvbnRlbnQgaGVhdmlseSwgd2UgdGhyb3cgc3lzdGVtLCB3YXJuaW5nIGFuZCBub3RpZmlj YXRpb24gY29udGVudCB0byB0aGUgdG9wIG9mIHRoZSBwYWdlIGluIGEgY29sbGFwc2luZywgZ3Jv d2wtc3R5bGUgbm90aWZpY2F0aW9uIHN5c3RlbeKAnTwvcD4KCjxwcmU+PGNvZGU+Jmx0O2RpdiBp ZD0ibm90aWZpY2F0aW9ucyImZ3Q7CiAgICAmbHQ7aDEmZ3Q7U3lzdGVtIE1lc3NhZ2VzJmx0Oy9o MSZndDsKCiAgICAmbHQ7cCBjbGFzcz3igJ1zeXN0ZW3igJ0mZ3Q7eW91IHNob3VsZCB0byBpbnN0 YWxsIGFlb2x1cy1hbGwgdG8gcHJvcGVybHkgdXNlIGNvbmR1Y3RvciZsdDsvcCZndDsKCiAgICAm bHQ7cCBjbGFzcz3igJ1zdGF0dXMgcHJvdmlkZXIxMjMgYnVpbGTigJ0mZ3Q7CiAgICAgICZsdDth IAogICAgICAgICBocmVmPeKAnXByb3ZpZGVyMTIzLWJ1aWxkLXN0YXR1c+KAnSAKICAgICAgICAg Y2xhc3M94oCdcmVmbGluayA1MOKAnSZndDsKICAgICAgICBidWlsZGluZyBwcm92aWRlcjEyMyAm bHQ7c3BhbiZndDs1MCUgQ29tcGxldGUmbHQ7L3NwYW4mZ3Q7CiAgICAgICZsdDsvYSZndDsKICAg ICZsdDsvcCZndDsKCiZsdDsvZGl2Jmd0Owo8L2NvZGU+PC9wcmU+Cgo8aHIgLz4KCjxoMj5Qcmlu dGFibGUgbWFuaWZlc3Q8L2gyPgoKPHA+QmVjYXVzZSBvdXIgY29udGVudCBpcyBub3QgcmVwbGlj YXRlZCwgYW5kIGFsbCBlbmFibGVkIHZpZXdzIGFyZSBpbmNsdWRlZCBpbiB0aGUgRE9NOwpvdXIg YXBwIGNhbiBhY3R1YWxseSBwcmludCBhcyBpZiBpdCB3ZXJlIGEgbWFuaWZlc3QgZm9yIHRoZSBh dXRoZW50aWNhdGVkIHVzZXIuPC9wPgoKPHA+V2UgZ2V0IHRoaXMgZmVhdHVyZSBmb3IgZnJlZSBi eSBwcm94eSBvZiBvdXIgbWV0aG9kIGZvciByZWZlcmVuY2luZyB2aWV3cyBhbmQgY29udGVudC48 L3A+Cgo8cD5IYXZpbmcgdGhlIGFiaWxpdHkgdG8gcHJvZHVjZSBhIGhhcmQgY29weSBpbmZyYXN0 cnVjdHVyZSByZXBvcnQgbWF5IGJlIGEgZ2ltbWljaywgYnV0IGl0JnJzcXVvO3MgYW4gZWFzeSB3 YXkgdG8gc2hvdyBob3cgY29uZHVjdG9yIGNhbiBoZWxwIHJlc3BvbmQgYW4gSVQgYXVkaXQgc2l0 dWF0aW9uLjwvcD4KCjxoMz5leGFtcGxlIHByaW50IHN0eWxlc2hlZXQgY2hhbmdlczwvaDM+Cgo8 cHJlPjxjb2RlPkBtZWRpYSBwcmludCB7CgphOmFmdGVyIHsKICAgIGNvbnRlbnQ6ICIgKCJhdHRy KGhyZWYpIikgIjt9CgpkaXY6YmVmb3JlewogICAgY29udGVudDogIiAoImF0dHIoaWQpIikgIjt9 fQoKfQo8L2NvZGU+PC9wcmU+Cgo8cD5UaGlzIHdpbGwgcHJlc2VydmUgYWxsIHJlZmVyZW5jZXMg YW5kIGxpbmtzIHRocm91Z2hvdXQgdGhlIFVJLjwvcD4KCjxwPkFsc28sIHdlIGNhbiBtYW51YWxs eSBkZWZpbmUgc2VjdGlvbnMgdG8gYmUgcHJpbnRlZC48L3A+Cgo8cHJlPjxjb2RlPkBtZWRpYSBw cmludCB7CgpkaXZ7ZGlzcGxheTpub25lfQoKI3Byb3ZpZGVycywgI2luc3RhbmNlcywgI3VzZXJz LCAjZ2xvYmFsLXRpcHMge2Rpc3BsYXk6YmxvY2sgIWltcG9ydGFudH0KPC9jb2RlPjwvcHJlPgoK PHA+ICAgfTwvcD4KCjxwPldoaWNoIG1lYW5zIG9ubHkgc2VjdGlvbnMgd2UgZGVzaXJlIHRvIGJl IGluY2x1ZGVkIGluIHRoZSBtYW5pZmVzdCBnZXQgcHJpbnRlZDwvcD4KCjxwPmFsc288L3A+Cgo8 cHJlPjxjb2RlPkBtZWRpYSBwcmludCB7CgoudGFiczpiZWZvcmV7CiAgIHBhZ2UtYnJlYWstYmVm b3JlOiBhbHdheXM7CiAgIGNvbnRlbnQ6IlRoaXMgc2VjdGlvbiBjb250YWlucyB0aGUgZm9sbG93 aW5nOiI7CiAudGFicyBsaSBhOmFmdGVye2NvbnRlbnQ6IiJ9CiAudGFicyB7IGZvbnQtc2l6ZTog MmVtO3BhZ2UtYnJlYWstYWZ0ZXI6IGFsd2F5czt9CiAudGFicyBsaXtkaXNwbGF5Omxpc3R9Cn0K PC9jb2RlPjwvcHJlPgoKPHA+V2hpY2ggd2lsbCBjb252ZXJ0IG91ciB0YWJzIGludG8gd2hvbGUg cGFnZSBzZWN0aW9uIHN1bW1hcmllcy48L3A+Cgo8YmxvY2txdW90ZT48cD5yZW1lbWJlciwgdGhp cyBmZWF0dXJlIGlzIGZyZWUgYmVjYXVzZSB3ZSBhcmUgZGVzaWduaW5nIGNvbmR1Y3RvciB0byBn cmFjZWZ1bGx5IGRlZ3JhZGUuIFZlcnkgbGl0dGxlIGVmZm9ydCBnb2VzIGludG8gcHJlc2Vydmlu ZyB0aGlzIGZlYXR1cmUgc28gbG9uZyBhcyBvdXIgc3RhbmRhcmRzIGFyZSBtYWludGFpbmVkLjwv cD48L2Jsb2NrcXVvdGU+Cgo8aDE+RXhpc3RpbmcgY29uZHVjdG9yIHBhcmFkaWdtczwvaDE+Cgo8 cD5UaGVzZSBjaGFuZ2VzIGRvbiZyc3F1bzt0IGNyZWF0ZSBhbnkgY2hhbmdlcyB0byB0ZXJtaW5v bG9neSwgb3IgaGF2ZSBtdWNoIGltcGFjdCBmb3IgcHJlLWV4aXN0aW5nIHZpZXdzIGZvciBjb21w b25lbnRzIGFscmVhZHkgYnVpbHQgaW50byBjb25kdWN0b3IuICBJdCBpcyBsaWtlbHkgdGhhdCB0 aGUgbWFqb3JpdHkgb2Ygd2hhdCBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgd2lsbCBiZSBwcmVzZXJ2 ZWQgYW5kIG9ubHkgdW5kZXJnbyBtaW5vciBjaGFuZ2VzIHRvIHRoZSBIQU1ML1NBU1Mgc28gdGhh dCBmZWF0dXJlcyBtYXkgYmUgaW50ZWdyYXRlZCBpbnRvIHRoZSBnbG9iYWwgdmlldy48L3A+Cgo8 cD5UaGlzIGhhcyBiZWVuIHdyaXR0ZW4gcHVyZWx5IHRvIHN0YXJ0IGRpc2N1c3Npb24gb24gaG93 IHdlIGV2b2x2ZSBDb25kdWN0b3IgZ29pbmcgZm9yd2FyZCBhbmQgSSZyc3F1bztkIGxvdmUgdG8g aGVhciB5b3VyIHRob3VnaHRzOiA8YSBocmVmPSJtYWlsdG86YW5keS5maXR6c2ltb25AcmVkaGF0 LmNvbSI+YW5keS5maXR6c2ltb25AcmVkaGF0LmNvbSA8L2E+PC9wPgo8L2JvZHk+CjwvaHRtbD4= --===============7812347200950457265==-- From afitzsim at redhat.com Wed Aug 19 15:23:28 2015 Content-Type: multipart/mixed; boundary="===============7939497121634218661==" MIME-Version: 1.0 From: Andrew Fitzsimon To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Mon, 30 Jan 2012 18:48:04 +1000 Message-ID: <7C7F94FC-8264-43A1-82E5-08BF846F8612@redhat.com> In-Reply-To: 2B4CAECF-6B24-4F5D-8CD0-4B164EE44B01@redhat.com --===============7939497121634218661== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Some source can be found in my fork of the UI proposal. = https://github.com/andyfitz/aeolus-ux-designs/tree/master/UI%20Proposal As mentioned, I'll be working on updating the playground mock. Andy On 30/01/2012, at 3:51 PM, 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 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 ac= cess. > = > * 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 l= eading. > * 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<= /div> > = > ### 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 touchable= large screens. > 3. We use only vector graphics (css /webfonts) for adaptive scaling and t= hemeing. > 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 requ= ests (the current set of 30 icons is ~5k) so this is very acceptable. > * We fallback to url linked images supplies for legacy browsers (no .WOFF= support) by using [modernizr](http://www.modernizr.com/) classes `.no-webf= onts` 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 w= ork. > = > ****** > = > = > ## 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 clicki= ng 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 e= lements with the same object objectid class. > = > 2. Once the action has been done an ajax call confirm the change and refr= eshes the class to "enabled/disabled/done/whatever" and removes the interme= diary 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-a= ll 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 > >

> = >
> = > = > ****** > = > ## 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 !important} > = > } > = > 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) > --===============7939497121634218661== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj48ZGl2PlNvbWUgc291cmNlIGNhbiBiZSBmb3VuZCBpbiBteSBmb3JrIG9mIHRoZSBV SSBwcm9wb3NhbC4mbmJzcDs8L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9h bmR5Zml0ei9hZW9sdXMtdXgtZGVzaWducy90cmVlL21hc3Rlci9VSSBQcm9wb3NhbCI+aHR0cHM6 Ly9naXRodWIuY29tL2FuZHlmaXR6L2Flb2x1cy11eC1kZXNpZ25zL3RyZWUvbWFzdGVyL1VJJTIw UHJvcG9zYWw8L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BcyBtZW50aW9uZWQsIEknbGwg YmUgd29ya2luZyBvbiB1cGRhdGluZyB0aGUgcGxheWdyb3VuZCBtb2NrLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+QW5keTwvZGl2PjxkaXY+PGJyPjxkaXY+PGRpdj5PbiAzMC8wMS8yMDEyLCBh dCAzOjUxIFBNLCBBbmR5IEZpdHpzaW1vbiB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+SGkgYWxsLDxi cj48YnI+SSd2ZSBzcGVudCBxdWl0ZSBzb21lIHRpbWUgdGhpbmtpbmcgYWJvdXQgZ2xvYmFsIFVJ IGltcHJvdmVtZW50cyB3ZSBjYW4gbWFrZSB0byBjb25kdWN0b3IgZm9yIGEgZnV0dXJlIHJlbGVh c2UuPGJyPk5vdyBpdCdzIHRpbWUgZm9yIG1lIHRvIHNoYXJlIGEgc21hbGwgc3VtbWFyeSBvZiB0 aG9zZSBpZGVhcyBhbmQgaG9wZWZ1bGx5IGdldCBzb21lIGZlZWRiYWNrLjxicj48YnI+SSdsbCBi ZSB1cGRhdGluZyA8YSBocmVmPSJodHRwOi8vbmRmdHouY29tL3BsYXlncm91bmQvIj5odHRwOi8v bmRmdHouY29tL3BsYXlncm91bmQvPC9hPiB3aXRoIG11Y2ggdGhlIHN0dWZmIG1lbnRpb25lZCBi ZWxvdyBidXQgYXMgb2YgcmlnaHQgbm93IGl0IGlzIG5vdCBhIHJlcHJlc2VudGF0aW9uIG9mIHRo ZSBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZDsgc28gaWYgeW91IGhhdmUgc2VlbiBpdCBiZWZvcmUs IHBsZWFzZSBkaXNyZWdhcmQgZXZlcnl0aGluZyBhc2lkZSBmcm9tIHRoZSByZXNwb25zaXZlbmVz cyBhbmQgdGhlIHZlY3RvciBpY29ucyBhc3BlY3RzLiAmbmJzcDtJJ2xsIG5vdyBzd2l0Y2ggZ2Vh cnMgdG8gZ2V0IHRoZSBtb2NrIGludGVyZmFjZSB1cCB0byBzcGVlZCB3aXRoIGFsbCB0aGUgY2xp ZW50IHNpZGUgZmVhdHVyZXMgZGVzY3JpYmVkLjxicj48YnI+KGF0dGFjaGVkIGlzIGEgZm9ybWF0 dGVkIGNvcHkgaW4tY2FzZSB5b3UgZG9uJ3QgbGlrZSByZWFkaW5nIG1hcmtkb3duKTxicj48YnI+ IC4uIHNvIGhlcmUgd2UgZ28uLjxicj48YnI+PT09PT09PT09PT09PT09PT09PT09PTxicj48YnI+ I0dvYWxzIGZvciBhIGJldHRlciBVSTxicj48YnI+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PlRoaXMgaXMgYSBwbGFuIHRvIGV2b2x2ZSB0aGUgY29uZHVjdG9yIFVJIGludG8gYSBsZWFuLCBh ZGFwdGl2ZSwgYmVhdXRpZnVsIGFuZCBjb25zaWRlcmVkIGV4cGVyaWVuY2UuPGJyPjwvYmxvY2tx dW90ZT48YnI+PGJyPiMjIyBTcGVjaWZpY2FsbHksIHdlIGhvcGUgdG8gYWRkcmVzczo8YnI+KiBO YXZpZ2F0aW5nIGFuZCBpc3N1aW5nIHRhc2tzIHF1aWNrbHkgPGJyPiAmbmJzcDsqIFdpdGhvdXQg dW5uZWNlc3NhcnkgaHR0cC1yb3VuZHRyaXBzIGp1c3QgdG8gY2hlY2sgb24gYSB2aWV3Ljxicj4g Jm5ic3A7KiBXaXRob3V0IGhhdmluZyB0byBsZWFybiBuZXcgY29tcG9uZW50cyBpbiBldmVyeSB2 aWV3PGJyPiAmbmJzcDsqIFdpdGhvdXQgaGF2aW5nIHRvIHJlZmVyIHRvIGRvY3VtZW50YXRpb24g dG8gYmUgYXNzaXN0ZWQgaW4gY29yZSB0YXNrcy48YnI+PGJyPiogS2VlcGluZyB0aGUgkWJpZyA2 kiBjb25zaXN0ZW50OiAmbmJzcDs8YnI+ICZuYnNwOyogQ29uc2lzdGVudCBhZXN0aGV0aWM8YnI+ ICZuYnNwOyogQ29uc2lzdGVudCBiZWhhdmlvdXI8YnI+ICZuYnNwOyogQ29uc2lzdGVudCBub3Rp ZmljYXRpb24gPGJyPiAmbmJzcDsqIENvbnNpc3RlbnQgbWVzc2FnaW5nIDxicj4gJm5ic3A7KiBD b25zaXN0ZW50IGhlbHA8YnI+ICZuYnNwOyogQ29uc2lzdGVudCByZWZlcmVuY2luZzxicj48YnI+ KiBBZGRyZXNzIGFzIG1hbnkgbWVkaWEgdHlwZXMgYXMgd2UgY2FuIGdldCAqZm9yIGZyZWUqPGJy PiAmbmJzcDsqIF9fTW9iaWxlX18gLSA0ODBweCBhbmQgdXAgdmlhIG1pbm9yIGFjY29tbW9kYXRp b25zIGluIG91ciBVSTxicj4gJm5ic3A7KiBfX1dvcmtzdGF0aW9uX18gNjQwcHgtMTI4MHB4IC0g b3VyIGRlZmF1bHQgdmlldzxicj4gJm5ic3A7KiBfX1NlY3Rpb24gNTA4X18gY29tcGxpYW5jZSBp bmNsdWRpbmcgc2NyZWVuIHJlYWRlcnM8YnI+ICZuYnNwOyogX19QcmludGFibGVfXyAtIEFzIGEg cmVhZC1vbmx5IGludmVudG9yeSBtYW5pZmVzdCBvZiBhIHVzZXJzIGVudGlyZSBhY2Nlc3MuPGJy Pjxicj4qIEZlZWwgbGlrZSBhIDIwMTIgY2xpZW50IGFwcCA8YnI+ICZuYnNwOyogQ3V0dGluZyBl ZGdlIFVJIGNvbnZlbnRpb25zPGJyPiAmbmJzcDsqIFN3aXNzIHN0eWxlIHZpc3VhbCBtZXRhcGhv cnMgJmFtcDsgZWxlbWVudHMgb2YgdHlwb2dyYXBoaWMgc3R5bGU8YnI+ICZuYnNwOyogQmFzZWxp bmUgZ3JpZCBhbGlnbmVkIHR5cG9ncmFwaHkgY29uc2lzdGluZyBvZiAyIHdlaWdodHMgd2l0aCBz aW5nbGUgbGVhZGluZy48YnI+ICZuYnNwOyogVXNlIG9ubHkgdmVjdG9yIGdyYXBoaWNzPGJyPiAm bmJzcDsqIEJsYXppbmdseSBmYXN0IGNsaWVudCBzaWRlIHJlbmRlciB0aW1lczxicj48YnI+PGJy PiMgR2xvc3Nhcnkgb2YgdGVybXMgLyBleHBsYW5hdGlvbiBvZiBmZWF0dXJlcy48YnI+PGJyPjxi cj48YnI+IyMgVmlld3M8YnI+PGJyPk9uZSBkaXN0aW5jdCBjYXRlZ29yeSBvZiBjb250ZW50Ljxi cj48YnI+IyMjIGV4cGxhaW5lZDxicj48YnI+k3RoZSB1c2VycyB2aWV3lCBvciCTdGhlIHByb3Zp ZGVycyB2aWV3lC48YnI+QSB2aWV3cyBuYW1lIGNhbiBldmVuIGJlIGFzIHNwZWNpZmljIGFzIJN1 c2VyWFgtcHJvdmlkZXItcGVybWlzc2lvbnMgdmlld5QgJm5ic3A7b3Igk2FkbWluLXByb3ZpZGVy LXBlcm1pc3Npb25zLXVzZXJYWCB2aWV3lDxicj48YnI+Rm9yIG1vcmUgaW5mb3JtYXRpb24gb24g aG93IHdlIGltcGxlbWVudCB2aWV3cywgc2VlICdWaWV3IGFuY2hvcnMnIGJlbG93PGJyPjxicj4q KioqKio8YnI+PGJyPjxicj4jIyBDbGFzc2VzPGJyPjxicj5UaGluayBIVE1ML0NTUy9KUyBjbGFz c2VzPGJyPjxicj5DbGFzc2VzIHRyYWNrIHN0YXR1cyBvciBjb250ZW50IHR5cGUgYnV0IG5vdCBk aXNwbGF5Ljxicj48YnI+PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7YSBocmVmPSIjcHJvdmlk ZXIyMyIgY2xhc3M9InByb3ZpZGVyMjMgZW5hYmxpbmcgZWMyIiAmZ3Q7b25saW5lJmx0Oy9hJmd0 O2A8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZsdDtkaXYgaWQ9InByb3ZpZGVyMjMiIGNsYXNzPSJw cm92aWRlcjIzIGVuYWJsaW5nIGVjMiImZ3Q7RWMyhSZsdDsvZGl2Jmd0Ozxicj48YnI+IyMjIENs YXNzaW5nIGNvbnZlbnRpb248YnI+PGJyPjxicj4jIyMjIFJlc2VydmVkIGNsYXNzZXM8YnI+PGJy PiAmbmJzcDsmbmJzcDsmbmJzcDsuYWN0aXZlIDxicj5pcyByZXNlcnZlZCBmb3IgbmF2aWdhdGlu ZyB2aWV3czxicj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOy5lbmFibGluZyAuZGlzYWJsaW5nIC52 ZXJpZnlpbmcgLmRlbGV0aW5nIC5yZXF1ZXN0aW5nPGJyPmFyZSBhY3Rpb24gY2xhc3NlcyByZXNl cnZlZCBmb3IgY2xpZW50IHNpZGUgYWN0aW9uIGNvbmZpcm1hdGlvbjxicj48YnI+ICZuYnNwOyZu YnNwOyZuYnNwOy5lbmFibGVkIC5kaXNhYmxlZCAudmVyaWZpZWQgLmNvbXBsZXRlIC5idWlsZGlu Zzxicj5hcmUgYWN0aW9uIGNsYXNzZXMgcmVzZXJ2ZWQgZm9yIHNlcnZlciBldmVudHM8YnI+PGJy PiAmbmJzcDsmbmJzcDsmbmJzcDsud2FybmluZyAubm90ZSAuaW5mbyAudGlwIC5jYXV0aW9uPGJy PmFyZSByZXNlcnZlZCBmb3IgYXNzaXN0aXZlIGNvbnRlbnQ8YnI+PGJyPiAmbmJzcDsmbmJzcDsm bmJzcDsuc3RhdGljLXJlZmVyZW5jZSAuYXNzaXN0LXJlZmVyZW5jZTxicj5yZXNlcnZlZCBmb3Ig YW5jaG9yZWQgY2xvbmVzIG9mIGNvbnRlbnQgdmlhIHN0YXRpYyBhbmQgYXNzaXN0aXZlIHJlZmVy ZW5jaW5nIChzZWUgc2VjdGlvbik8YnI+PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsucHJvZ3Jlc3Mg LmxvYWRpbmcgLmJ1aWxkaW5nIC5jb21waWxpbmcgLmFsdGVyaW5nPGJyPmFyZSBwcm9ncmVzcyBj bGFzc2VkIHRvIGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0aCBhIG51bWVyaWNhbCBjbGFzczxi cj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOy41MCAuMTAgLjIwIC4yNSAuNzUgLjEwMCAuMzAgZXRj hTxicj5hcmUgcGVyY2VudGFnZSBjbGFzc2VzIHRvIGJlIHVzZWQgaW4gY29uanVuY3Rpb24gd2l0 aCBhIHZhbHVlPGJyPjxicj5lLmcuOiBgJmx0O3NwYW4gY2xhc3M9Ijc1IHVzYWdlIiZndDs3NSUg b2YgMzAwZ2IgJmx0Oy8uLi5gIDxicj5vciBiZXR0ZXI6IGAmbHQ7c3BhbiBjbGFzcz0iNzUgdXNh Z2UiJmd0OzIyNWdiIG9mIDMwMGdiICZsdDsvLi4uYDxicj48YnI+ICZuYnNwOyZuYnNwOyZuYnNw Oy51c2FnZSAucHJvZ3Jlc3MgLmxvYWQgLmNhcGFjaXR5PGJyPmFyZSAqKnN0YXR1cyoqIGNsYXNz ZXMgcmVzZXJ2ZWQgZm9yIGlkZW50aWZ5aW5nIHRoZSAqKnR5cGUqKiBvZiBtZWFzdXJlbWVudDxi cj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOy5pbnN0YW5jZSAucHJvdmlkZXIgLnVzZXIgLnBvb2wg Lmdyb3VwPGJyPmFyZSBvYmplY3QgY2xhc3NlcyB0byBiZSB1c2VkIG9uIGFueSBvYmplY3QgPGJy Pjxicj4jIyMgJm5ic3A7TGFjayBvZiBjbGFzc2VzIGZvciBsYXlvdXQ8YnI+V2Ugd2lsbCBfX05P VF9fIHVzZSBjbGFzc2VzIGZvciBkZWZpbmluZyBncmlkIGxheW91dCBlLmcuIGAuc3Bhbi0xMmAg b3IgYC5sZWZ0LTEyMC9gPGJyPjxicj5BbGwgbGF5b3V0cyB3aWxsIGJlIGRlZmluZWQgaW4gQ1NT IHZpYSBhIGNvbWJpbmF0aW9uIG9mIHRoZWlyIHBhcmVudCB2aWV3IGFuZCB0aGUgcmVsZXZhbnQg bWVkaWEgcXVlcnkuPGJyPjxicj48YnI+Zm9yIGV4YW1wbGUgd2Ugd2lsbCB1c2UgdGhlIENTUyA8 YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyNhZG1pbiAjcHJvdmlkZXJzIC5hY2NvdW50IC5zdW1tYXJ5 e3dpZHRoOjMzLjMzMyV9PGJyPnJhdGhlciB0aGFuIHJlbHlpbmcgb24gaW5qZWN0aW5nIHN0eWxl IGxvZ2ljIGludG8gdGhlIGh0bWwgbGlrZSB0aGlzIGAmbHQ7Y2xhc3M9InN1bW1hcnkgc3Bhbi00 IiZndDtgPGJyPjxicj4qKioqKio8YnI+PGJyPiMjIEdyYWNlZnVsIGRlZ3JhZGF0aW9uPGJyPjxi cj5TdXBwb3J0IGZvciBhbGwgY29yZSBmdW5jdGlvbmFsaXR5IGluIGFzIG1hbnkgc2NlbmFyaW9z IGFzIHBvc3NpYmxlPGJyPjxicj4gKiBOZXcgYnJvd3NlciBmZWF0dXJlcyAoc3VidGxlIGFuaW1h dGlvbiwgZ3JhZGllbnRzIGV0Yyk8YnI+ICogT2xkZXIgYnJvd3NlcnMgbGFja2luZyBmZWF0dXJl cyA8YnI+ICogQnJvd3NlcnMgd2l0aCBqYXZhc2NyaXB0IHR1cm5lZCBvZmY8YnI+ICogU2NyZWVu IHJlYWRlcnMgKHNlY3Rpb24gNTA4LCB3ZZJyZSBnb2luZyB0aGVyZSk8YnI+PGJyPioqKioqKjxi cj48YnI+PGJyPiMjIFJlc3BvbnNpdmUgZGVzaWduPGJyPjxicj5TdXBwb3J0IGZvciB2aWV3aW5n IGZyb20gdmFyaW91cyBtZWRpYSBlZyAmbmJzcDtjZWxscGhvbmVzLCB0b3VjaHNjcmVlbiBkZXZp Y2VzLCBraW9za3MsIHR2knMsIGV2ZW4gcHJpbnQuPGJyPjxicj48YnI+IyMjIEV4cGxhaW5lZDxi cj48YnI+IDEuIFdlIGNvbGxhcHNlIHRhYmxlcyBpbnRvIHJlY29yZCB2aWV3cyBmb3IgbmFycm93 IHNjcmVlbnMuPGJyPiAyLiBXZSBHcm93IGZvbnRzIGFuZCBpY29ucyBmb3IgdHJlbWVuZG91c2x5 IGhpZ2ggcmVzb2x1dGlvbnMgb3IgdG91Y2hhYmxlIGxhcmdlIHNjcmVlbnMuPGJyPiAzLiBXZSB1 c2Ugb25seSB2ZWN0b3IgZ3JhcGhpY3MgKGNzcyAvd2ViZm9udHMpIGZvciBhZGFwdGl2ZSBzY2Fs aW5nIGFuZCB0aGVtZWluZy48YnI+QW5jaG9yIHJlZmVyZW5jaW5nIHdpdGgganMgaW5saW5pbmcg bWVhbnMgcmVwZWF0ZWQgY29udGVudCBpcyBwcmludGVkIG9ubHkgb25jZS4gJm5ic3A7YSBwcmlu dCB2ZXJzaW9uIHdvdWxkIHJlYWQgbGlrZSBhbiBpbmZyYXN0cnVjdHVyZSBzdGF0dXMgcmVwb3J0 IGZyb20gdGhlIHVzZXJzIHBlcnNwZWN0aXZlLjxicj48YnI+KioqKioqPGJyPjxicj48YnI+IyMg VmlzdWFsIE1ldGFwaG9ycyAmYW1wOyBWZWN0b3IgR3JhcGhpY3M8YnI+PGJyPlZpc3VhbCBtZXRh cGhvcnMgYXJlIGdyYXBoaWNzIHN5bWJvbGljIG9mIHRoZSBmdW5jdGlvbiB0aGV5IHBlcmZvcm0u PGJyPlZlY3RvciBncmFwaGljcyBhcmUgYSByZXNvbHV0aW9uIGluZGVwZW5kZW50IGltcGxlbWVu dGF0aW9uLjxicj48YnI+IyMjIEV4cGxhaW5lZCA8YnI+QWxsIGljb25zLCB2aXN1YWwgaW5kaWNh dG9ycyBhbmQgb3JuYW1lbnRhbCBncmFwaGljcyAmbmJzcDthcmUgaW1wbGVtZW50ZWQgbGlrZSB0 aGlzOjxicj48YnI+ICogVmVjdG9yIGdseXBocyBhcmUgZW5jb2RlZCBpbnRvIGEgd29mZiB3ZWJm b250IDxicj4gKiBUaGUgd29mZiBmb250IGlzIGJhc2U2NCBlbmNvZGVkIGluIHRoZSBzdHlsZXNo ZWV0IHRvIG1pbmltaXNlIGh0dHAgcmVxdWVzdHMgKHRoZSBjdXJyZW50IHNldCBvZiAzMCBpY29u cyBpcyB+NWspIHNvIHRoaXMgaXMgdmVyeSBhY2NlcHRhYmxlLjxicj4gKiBXZSBmYWxsYmFjayB0 byB1cmwgbGlua2VkIGltYWdlcyBzdXBwbGllcyBmb3IgbGVnYWN5IGJyb3dzZXJzIChubyAuV09G RiBzdXBwb3J0KSBieSB1c2luZyBbbW9kZXJuaXpyXSg8YSBocmVmPSJodHRwOi8vd3d3Lm1vZGVy bml6ci5jb20vIj5odHRwOi8vd3d3Lm1vZGVybml6ci5jb20vPC9hPikgY2xhc3NlcyBgLm5vLXdl YmZvbnRzYCBhbmQgYC53ZWJmb250c2AgdG8gZGlzY3JpbWluYXRlIG91ciBpbXBsZW1lbnRhdGlv biB0aHJvdWdoIGNzczxicj48YnI+PGJyPioqKioqKjxicj48YnI+IyMgVmlldyBhbmNob3JzIC0g b3IgJ3NpbmdsZSBwYWdlIGFwcCc8YnI+PGJyPlZpZXcgYW5jaG9ycyBhcmUgcG9ydGlvbnMgb2Yg b3VyIGRlc2lnbiBpbXBsZW1lbnRlZCB3aXRoaW4gdGhlIG9uZSBET00gdXNpbmcgYmFzaWMgYW5j aG9yaW5nIGZ1bmN0aW9uYWxpdHkuPGJyPjxicj4jIyMgRXhwbGFpbmVkPGJyPkluIHRoZSBwcm9w b3NlZCBjaGFuZ2UsIHRoZSBlbnRpcmUgY29uZHVjdG9yIGlzIG9uZSBwYWdlIGZvciBhbGwgZGVm YXVsdCB2aWV3cywgPGJyPjxicj4xLiBMaW5rIGFuY2hvcnMgd2lsbCBhY3RpdmF0ZSB0aGUgc3Bl Y2lmaWMgdmlldyBvciBzdWItdmlldy4gJm5ic3A7PGJyPjxicj4yLiBBbmNob3JzIHRoYXQgZG8g bm90IHJlc29sdmUgd2lsbCBpbml0aWF0ZSBhICJjYW5ub3QgZmluZCIgbWVzc2FnZSB3aGljaCB3 aWxsIG1vc3QgY29tbW9ubHkgb2NjdXIgd2hlbiBhIHVzZXIgZG9lcyBub3QgaGF2ZSBhY2Nlc3Mg dG8gYW4gb2JqZWN0IGFuZCBoYXMgbWFudWFsbHkgZW50ZXJlZCBhIGN1c3RvbSAjIFVSTC4gJm5i c3A7dGhlIHR3byBleGNlcHRpb25zIHRvIHRoaXMgd2lsbCBiZSB+LyMgYW5kIH4vI3RvcCB3aGlj aCB3aWxsIGluaXRpYXRlIHRoZSBkZWZhdWx0IGFwcCB2aWV3Ljxicj48YnI+IyMjIEluIGFjdGlv bjxicj48YnI+Rm9yIGV4YW1wbGU6IDxicj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhl IFVSTCBiZWxvdyBzaG91bGQgb3BlbiB0aGUgYWRtaW4gJmd0OyBwcm92aWRlcnMgJmd0OyBlYzJl YXN0Y29hc3QgJmd0OyBjb25uZWN0aXZpdHkgdmlldy48YnI+PC9ibG9ja3F1b3RlPjxicj4gJm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9jb25kdWN0b3IvI2VjMmVhc3Rjb2FzdC1j b25uZWN0aXZpdHkiPmh0dHBzOi8vY29uZHVjdG9yLyNlYzJlYXN0Y29hc3QtY29ubmVjdGl2aXR5 PC9hPjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7XiAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDteICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO148YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NlcnZlciAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtPYmplY3RJRCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDaGlsZFZpZXc8 YnI+PGJyPjxicj4jIyMjIFdoYXQgdGhlIGh0bWwgZG9lczxicj5lLmcuIHRoZSBgJmx0O2RpdiZn dDtgIHJlcHJlc2VudGluZyBhZG1pbiAmZ3Q7IHByb3ZpZGVycyAmZ3Q7IGVjMmVhc3Rjb2FzdCB3 b3VsZCBsb29rIGxpa2UgPGJyPjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2RpdiBpZD0iZWMy ZWFzdGNvYXN0IiZndDsuLiBlYzIgZWFzdCBjb2FzdCBpbmZvcm1hdGlvbiBnb2VzIGhlcmU8YnI+ PGJyPjxicj5hbmQgdGhlIGNvbm5lY3Rpdml0eSB0YWIgd2hpY2ggZXhpc3RzIGluc2lkZSB0aGUg ZWMyZWFzdGNvYXN0IHByb3ZpZGVyIHdvdWxkIGxvb2sgbGlrZSA8YnI+PGJyPiAmbmJzcDsmbmJz cDsmbmJzcDsmbHQ7ZGl2IGlkPSJlYzJlYXN0Y29hc3QtY29ubmVjdGl2aXR5IiZndDs8YnI+ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO14gJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Xjxi cj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7b2JqZWN0SUQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Q2hpbGRWaWV3bmFtZTxicj48YnI+V2h5Pzxicj5CZWNhdXNlIHRoZSBwcm92aWRlciBf ZWMyZWFzdGNvYXN0XyBsaXZlcyBuYXRpdmVseSB3aXRoaW4gdGhlIF9hZG1pbiAmZ3Q7IHByb3Zp ZGVyXyBzZWN0aW9uLCBpdCBkb2VzIG5vdCBuZWVkIHRvIGJlIHJlZmVyZW5jZWQgaW4gdGhlIElE Li4gaXQgc2ltcGx5IGhhcyB0byBiZSB1bmlxdWUuICZuYnNwO0J1dCBiZWNhdXNlIHRoZSBjb25u ZWN0aXZpdHkgdGFiIGlzIG9ubHkgdW5pcXVlIGJlY2F1c2Ugb2YgdGhlIHByb3ZpZGVyIGl0IGlz IGFzc29jaWF0ZWQgd2l0aCwgaXQgbmVlZHMgdG8gYmUgcHJlZml4ZWQgd2l0aCB0aGUgb2JqZWN0 SUQgPGJyPjxicj48YnI+QWxsIGRpcmVjdCBsaW5rcyB0byB0aGUgcHJvdmlkZXIgdmlldyB3b3Vs ZCBsb29rIGxpa2UgYCZsdDthIGhyZWY9I2VjMmVhc3Rjb2FzdCZndDtFQzIgRWFzdCBDb2FzdCZs dDsvYSZndDsgd2hpY2ggd291bGQgYWN0aXZhdGUgdGhlIHByb3ZpZGVyIHRhYi48YnI+PGJyPjxi cj4jIyMjIHdoYXQgSlMgZG9lczxicj48YnI+MS4gSlMgaGlkZXMgYWxsIG5vbiBhY3RpdmUgdmll d3MgZXhjZXB0IGZvciB0aGUgZGVmYXVsdCB2aWV3IChjbGFzc2VkIGFzIGFjdGl2ZSBieSB0aGUg anMpPGJyPjIuIDxicj4zLiB3aGVuIGFuIElEIGlzIHJlcXVlc3RlZCB0aGUgb2JqZWN0IGFuZCBh bGwgcGFyZW50IHZpZXdzIGdldCBjbGFzc2VkIGAuYWN0aXZlYCA8YnI+NC4gW2hhc2hjaGFuZ2Ug Zm9yIG9sZCBicm93c2Vyc10oPGEgaHJlZj0iaHR0cDovL2JlbmFsbWFuLmNvbS9wcm9qZWN0cy9q cXVlcnktaGFzaGNoYW5nZS1wbHVnaW4vIj5odHRwOi8vYmVuYWxtYW4uY29tL3Byb2plY3RzL2px dWVyeS1oYXNoY2hhbmdlLXBsdWdpbi88L2E+KSAmbmJzcDt0byBwcmVzZXJ2ZSBicm93c2luZyBo aXN0b3J5PGJyPjxicj4jIyMjIHdoYXQgdGhlIENTUyBkb2VzPGJyPlRoZSBib2R5IGNsYXNzIGAu bm9qc2AgaXMgcmVtb3ZlZCBvbmNlIEphdmFzY3JpcHQgaXMgbG9hZGVkIHNvIHRoZSBDU1Mgc3Bl Y2lmaWVzIHRoYXQgb25seSB2aWV3cyBiZSB2aXNpYmxlIHdoZW4gdGhleSBhcmUgY2xhc3NlZCBh cyBgLmFjdGl2ZWAgPGJyPjxicj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOy5qcyBkaXZ7ZGlzcGxh eTpub25lfSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsv LyBIaWRpbmcgYWxsIHZpZXdzPGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsuanMgZGl2LmFjdGl2ZXtk aXNwbGF5OmJsb2NrfSAvLyBTaG93aW5nIGFjdGl2ZSB2aWV3czxicj4gJm5ic3A7Jm5ic3A7Jm5i c3A7Lm5vanMgZGl2e2Rpc3BsYXk6YmxvY2t9ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Oy8vIEFsbCB2aWV3cyBhcmUgc2hvd24gd2hlbiB0YWJzIGRvbid0IHdvcmsuPGJyPjxicj4qKioq Kio8YnI+PGJyPjxicj4jIyBSZWZlcmVuY2VkIGNvbnRlbnQ8YnI+PGJyPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPlJlZmVyZW5jZWQgY29udGVudCBpcyBhIGxpdmUtY29weSBvZiBhbnkgZXhpc3Rp bmcgcGFydCBvZiB0aGUgYXBwbGljYXRpb24uIEl0IGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRoIHN0 YXRpYyByZWZlcmVuY2VzIG9yIGFzc2lzdGl2ZSByZWZlcmVuY2VzIDxicj48L2Jsb2NrcXVvdGU+ PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlNlZSBbdGhpcyBKUyBGaWRkbGUgZGVtb10oPGEg aHJlZj0iaHR0cDovL2pzZmlkZGxlLm5ldC9hbmR5Zml0ei9oUnFHYS8xOTEvIj5odHRwOi8vanNm aWRkbGUubmV0L2FuZHlmaXR6L2hScUdhLzE5MS88L2E+KSA8YnI+PC9ibG9ja3F1b3RlPjxicj4j IyMjIGV4YW1wbGU8YnI+PGJyPjEuIEdsb2JhbCBoZWxwIGNvbnRlbnQgY2FuIGJlIHJlZmVyZW5j ZWQgZnJvbSBtYW55IHBsYWNlcyBhdCBvbmNlIHNvIGFzIHRvIGF2b2lkIHJlZHVuZGFuY3kgYW5k IGFubm95aW5nIGFqYXggcmVxdWVzdHMuLiBpZiB0aGUgc2VjdGlvbiB0aGUgaGVscCBjb21lcyBm cm9tIGlzIGxvYWRlZCwgc28gaXMgdGhlIGhlbHAuPGJyPjIuIEluc3BlY3RpbmcgYW4gb2JqZWN0 IHZpYSBhIGxpbmsgY2FuIGNhbGwgdGhlIG9iamVjdHMgZW50aXJlIGNvbnRlbnQgaW50byB2aWV3 Ljxicj48YnI+KioqKioqPGJyPjxicj4jIyMgU3RhdGljLXJlZmVyZW5jZXM8YnI+PGJyPldoZXJl IGFuIGFuY2hvciBsaW5rIHRvIGFub3RoZXIgc2VjdGlvbiBoYXMgYmVlbiByZXBsYWNlZCB3aXRo IGEgbGl2ZSBjb3B5IG9mIHRoZSBzZWN0aW9uIGl0IGxpbmtzIHRvLjxicj48YnI+ICZuYnNwOyZu YnNwOyZuYnNwOy5zdGF0aWMtcmVmZXJlbmNlPGJyPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij5BbiBleGFtcGxlIHdvdWxkIGJlIGFueSBtb25pdG9yaW5nIHZpZXcgdGhhdCByZXF1aXJlcyB2 YXJpb3VzIG1ldHJpY3MgYWxyZWFkeSByZW5kZXJlZCBlbHNld2hlcmUgYmUgaW5jbHVkZWQuPGJy PjwvYmxvY2txdW90ZT48YnI+PGJyPioqKioqKjxicj48YnI+IyMjIEFzc2lzdC1yZWZlcmVuY2Vz PGJyPjxicj5saWtlIGEgc3RhdGljIHJlZmVyZW5jZSBidXQgd2l0aCB0aGUgbGluay10ZXh0IHBy ZXNlcnZlZCBhbmQgdGhlIHNlY3Rpb24gb25seSB2aXNpYmxlIHdoZW4gdGhlIGxpbmstdGV4dCBo YXMgZm9jdXMgKGhhcyBiZWVuIGNsaWNrZWQpLjxicj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOy5h c3Npc3QtcmVmZXJlbmNlPGJyPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5BbiBleGFtcGxl IHdvdWxkIGJlIGEgcGVybWlzc2lvbnMgZWRpdG9yIHJlZmVyZW5jaW5nIHRoZSBvYmplY3RzIHRo YXQgYSB1c2VyIGhhcyBwZXJtaXNzaW9ucyB0byBieSBuYW1lICZuYnNwO2FuZCBhbGxvd2luZyB0 aGUgdXNlciB0byBpbnNwZWN0IHRoYXQgb2JqZWN0IGluLXBsYWNlIHdpdGggYSBzaW5nbGUgY2xp Y2ssIHdpdGhvdXQgaGF2aW5nIHRvIHZpc2l0IHRoZSBvYmplY3QgaW4gcXVlc3Rpb25zIGRlZmF1 bHQgdmlldy48YnI+PC9ibG9ja3F1b3RlPjxicj4qKioqKio8YnI+PGJyPjxicj4jIyBIZWxwICZh bXA7IGNvbnRlbnQ8YnI+PGJyPldyaXR0ZW4gY29udGVudCB0byBoZWxwIGRlc2NyaWJlIGEgZmVh dHVyZSBvciBzY2VuYXJpby4gPGJyPkNvbWJpbmVkIHdpdGggYWRtb25pdGlvbiBjbGFzc2VzIDxi cj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOy53YXJuaW5nIC5ub3RlIC5pbmZvIC50aXAgLmNhdXRp b248YnI+PGJyPk9mdGVuIGltcGxlbWVudGVkIHZpYSBvbmUgb2YgdGhlIGZvbGxvd2luZyBtZXRo b2RzIDxicj48YnI+ICogSW5jbHVkZWQgaW4gdGhlIHZpZXcgcmVsZXZhbnQgdG8gaXRzIGRlc2Ny aXB0aW9uPGJyPiAqIEFzIHN0YXRpYy1yZWZlcmVuY2VzIHdoZXJlIHRoZSBoZWxwIGNvbnRlbnQg Y2FuIGJlIGRpc21pc3NlZCAodmlhIGFuIFggaW4gdGhlIHRvcCByaWdodCBjb3JuZXIpPGJyPiAq IEFzIGFzc2lzdC1yZWZlcmVuY2VzIHdoZXJlIHRoZSBoZWxwIGNvbnRlbnQgY2FuIGJlIHJldmVh bGVkIHVwb24gY2xpY2tpbmcgYSByZWZlcnJpbmcgbGluazxicj48YnI+PGJyPjxicj48YnI+UHJh Y3RpY2FsbHkgc3BlYWtpbmcgdGhpcyBpcyB0ZXh0IHRoYXQgY2FuIGJlIHBsYWNlZCBpbmxpbmUg d2l0aCBhIHZpZXcgdGhhdCBpdCByZXByZXNlbnRzIG9yIGhpZGRlbiBpbiBhIG5vbiBkaXNwbGF5 ZWQgdXNlZnVsIGNvbnRlbnQgYXJlYSB0byBiZSBzdGF0aWMgb3IgYXNzaXN0LXJlZmVyZW5jZWQg YnkgbWFueSBwbGFjZXMuPGJyPjxicj48YnI+IyMjIEV4cGxhaW5lZDxicj48YnI+Rm9yIGV4YW1w bGU6ICZuYnNwO1+TZG9uknQgYmUgc2lsbHmTXyBpcyBhIGdlbmVyaWMgdGlwIHRoYXQgbWF5IGFw cGx5IHRvIGFuIGVub3Jtb3VzIHZhcmlldHkgb2YgY29udGV4dHMuICZuYnNwO1RoaXMgaXMgdXNl ZnVsIHRvIGJlIHBsYWNlZCBpbiB0aGUgImdlbmVyaWMgdGlwcyIgYXJlYSBhbmQgbGlua2VkIHRv IHZpYSBgJmx0O2EgaHJlZj2UI2RvbnQgYmUtc2lsbHmUIGNsYXNzPZRhc3Npc3QtcmVmZXJlbmNl lCZndDtub3cgcGxlYXNlIHJlbWVtYmVyLi4mbHQ7L2EmZ3Q7YCB3aGljaCBtZWFucyBpdCB3aWwg YmUgcmVuZGVyZWQgaW5saW5lIG9mIHdoZXJlIGl0IGlzIHJlZmVyZW5jZWQuPGJyPjxicj4qKioq Kio8YnI+PGJyPjxicj4jI0NsaWVudC1zaWRlIHN0YXR1cyBwb2xsaW5nPGJyPjxicj5BbGwgb2Jq ZWN0cyByZWxldmFudCB0byBhIHZpZXcgYXJlIGNsYXNzZWQgd2l0aCB0aGUgdmlld25hbWU8YnI+ T24gYW55IGFjdGlvbiBpbnNpZGUgdGhlIHZpZXcsIGEgc3RhdHVzIGNsYXNzbmFtZSBpcyBhZGRl ZCB0byB0aGUgdmlldyBhcyB3ZWxsIGFzIGFueSBvYmplY3RzIHRoYXQgcmVmZXJlbmNlIGl0IHJl Z2FyZGxlc3Mgb2Ygd2hlcmUgdGhleSBhcmUgZGlzcGxheWVkICZuYnNwOzxicj48YnI+PGJyPiAm bmJzcDsmbmJzcDsmbmJzcDsmbHQ7YSBocmVmPSN1c2VyIGNsYXNzPZR1c2VyWFggZW5hYmxpbmeU Jmd0O2xpbmsmbHQ7L2EmZ3Q7IDxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2RpdiBpZD0jlHVz ZXJYWJQgY2xhc3M9lHVzZXJYWCBlbmFibGluZ5QgJmd0O1VzZXJYWCBWaWV3Jmx0Oy9kaXYmZ3Q7 Ljxicj48YnI+V2Ugd2F0Y2ggdGhlIHJlZmVyZW5jZWQgdmlld3MgY2xhc3NlcyBhbmQgbWltaWMg dGhlbSBvbiBhbGwgcmVmZXJlbmNpbmcgbGlua3MgYWx3YXlzIGFzIHRoZXkgY2FuIGNvbnRhaW4g b3IgYmUgdXBkYXRlZCB3aXRoIG5ldyBldmVudCBzdHlsZXMgKGZvciBleGFtcGxlOiBmYWlsZWQs IHdhcm5pbmcsIHVwZ3JhZGVkLCBhZG1pbi1vbmx5IGV0Yyk8YnI+PGJyPioqKioqKjxicj48YnI+ IyMgU2VydmVyIHN0YXR1cyBldmVudHMgKmludmVzdGlnYXRpbmcqPGJyPjxicj5SaWdodCBub3cg d2UgY2FuIHVzZSBhamF4IGNhbGxzIHRvIHVwZGF0ZSBlYWNoIHZpZXcgYnV0IGluIGZ1dHVyZSBp dCB3b3VsZCBtYWtlIHNlbnNlIHRvIHVzZSBldmVudFNvdXJjZSBmb3IgbW9yZSBhZHZhbmNlZCBt b25pdG9yaW5nOiBbZXZlbnRTb3VyY2U6IHNlcnZlciBzZW50IGV2ZW50c10oPGEgaHJlZj0iaHR0 cDovL2h0bWw1ZG9jdG9yLmNvbS9zZXJ2ZXItc2VudC1ldmVudHMvIj5odHRwOi8vaHRtbDVkb2N0 b3IuY29tL3NlcnZlci1zZW50LWV2ZW50cy88L2E+KSA8YnI+PGJyPioqKioqKjxicj48YnI+IyMg Q2xpZW50IHZlcmlmaWNhdGlvbiAvIGZhc3QgZmVlZGJhY2s8YnI+PGJyPkludGVyYWN0aXZlIGFz c3VyYW5jZSB0aGF0IGFuIGFjdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgd2l0aG91dCB0aGUgdmVy aWZpY2F0aW9uIHRoYXQgdGhlIHNlcnZlciBoYXMgcGVyZm9ybWVkIHRoZSBhY3Rpb24uPGJyPjxi cj5Gb3IgZXhhbXBsZSBhIHVzZXIgY2xpY2tzIHRoZSBlbmFibGUgYnV0dG9uLi4gd2UgaW1tZWRp YXRlbHkgYXBwbHkgk2VuYWJsaW5nlCBzdGF0dXMgdG8gdGhlIGJ1dHRvbiBidXQgd2FpdCBmb3Ig dGhlIHNlcnZlciB0byByZXR1cm4gd2l0aCB0aGUgk2VuYWJsZWSUIGNvbmZpcm1hdGlvbi4uLjxi cj48YnI+IyMjIEhvdyBpdCB3b3Jrczxicj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KipB c3N1bXB0aW9uKiogaW50ZXJtaXR0ZW50IHN0YXRlcyBsaWtlIHZlcmlmeWluZywgZW5hYmxpbmcg YW5kIGRpc2FibGluZyBzdGF0ZXMgYXJlIHNhZmUgZm9yIGNsaWVudCBzaWRlIHZhbGlkYXRpb24u PGJyPjwvYmxvY2txdW90ZT48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhleSBjb25maXJt IGFuIGFjdGlvbiBoYXMgYmVlbiByZXF1ZXN0ZWQgYnV0IG5vdCBhcHBsaWVkLjxicj48L2Jsb2Nr cXVvdGU+PGJyPkFzIGEgcnVsZSwgYWxsIGVsZW1lbnRzIGFyZSBnaXZlbiB0aGUgc3RhdHVzIG9m IHRoZSBvYmplY3RzIHRoZXkgcmVwcmVzZW50IGFzIHdlbGwgYXMgY2xhc3NlZCB3aXRoIHRoZSBv YmplY3QgSUQuLiAmbmJzcDtlLmcuOiBhbGwgYnV0dG9ucyB3aXRoIGBjbGFzcz0icHJvdmlkZXJp ZDEyNDUxLSoiYCBnZXQgdGhlIGFkZGl0aW9uYWwgY2xhc3Mgb2YgdGhlaXIgaW50ZXJtaXR0ZW50 IHN0YXRlIGBgImVuYWJsaW5nL2Rpc2FibGluZy92ZXJpZnlpbmcvd2hhdGV2ZXIiYGAgJm5ic3A7 V2hlbiBhIGZ1bmN0aW9uYWwgb2JqZWN0IHJlbGF0ZWQgdG8gdGhlbSBoYXMgYmVlbiBhY3Rpb25l ZC48YnI+PGJyPiAxLiBPbiB0aGUgY2xpZW50IGphdmFzY3JpcHQgc2lkZSwgd2Ugc2V0IHRoZSBh Y3Rpb25pbmcgY2xhc3NuYW1lIHRvIGFsbCBlbGVtZW50cyB3aXRoIHRoZSBzYW1lIG9iamVjdCBv YmplY3RpZCBjbGFzcy48YnI+PGJyPiAyLiBPbmNlIHRoZSBhY3Rpb24gaGFzIGJlZW4gZG9uZSBh biBhamF4IGNhbGwgY29uZmlybSB0aGUgY2hhbmdlIGFuZCByZWZyZXNoZXMgdGhlIGNsYXNzIHRv ICJlbmFibGVkL2Rpc2FibGVkL2RvbmUvd2hhdGV2ZXIiIGFuZCByZW1vdmVzIHRoZSBpbnRlcm1l ZGlhcnkgc3RhdGU8YnI+PGJyPioqKioqKjxicj48YnI+IyMgSW1wb3J0YW50IGFjdGlvbiBjZXJ0 aWZpY2F0aW9uPGJyPjxicj5bSlMgRmlkZGxlIGRlbW9dKDxhIGhyZWY9Imh0dHA6Ly9qc2ZpZGRs ZS5uZXQvYW5keWZpdHovbXZkU1QvIj5odHRwOi8vanNmaWRkbGUubmV0L2FuZHlmaXR6L212ZFNU LzwvYT4pPGJyPjxicj48YnI+UmVxdWlyaW5nIHRoZSB1c2VyIHRvIGNlcnRpZnkgdGhhdCB0aGV5 IHVuZGVyc3RhbmQgdGhlIGFjdGlvbiBiZWZvcmUgYWxsb3dpbmcgaXQgdG8gdGFrZSBwbGFjZS48 YnI+Zm9yIGV4YW1wbGU6ICZuYnNwOzxicj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+k0Rv IHlvdSB1bmRlcnN0YW5kIHdoYXQgeW91IGFyZSBkb2luZz9beWVzXSBva2F5LCBoZXJlknMgdGhl IGJ1dHRvbiBbY2xpY2tdlDxicj48L2Jsb2NrcXVvdGU+PGJyPiMjI2V4cGxhaW5lZDxicj48YnI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+RW5hYmxpbmcgYW5kIGRpc2FibGluZyBwcm92aWRlcnMs ICZuYnNwO2RlbGV0aW5nIHVzZXJzIGV0YyA8YnI+PC9ibG9ja3F1b3RlPjxicj5XZSB3aWxsIHVz ZSB0aHJlZSBtZXRob2RzIHRvIHZlcmlmeSB0aGF0IGEgdXNlciBoYXMgYWNjZXB0ZWQgdGhlIHNl dmVyaXR5IG9mIHRoZSB0YXNrIHRoZXkgYXJlIGFib3V0IHRvIHBlcmZvcm06PGJyPjxicj4gMS4g Q1NTIHBoeXNpY2FsIG9iZnVzY2F0aW9uLiA8YnI+V2hlcmUgdGhlIGNvbmZpcm1hdGlvbiB0b2dn bGUgc2l0cyBwaHlzaWNhbGx5IG9uIHRvcCBvZiB0aGUgYWN0aW9uIHRvZ2dsZSBzbyB0aGF0IGFu IGFjdGlvbiBjYW4gbm90IGJlIGNsaWNrZWQgd2l0aG91dCBjbGlja2luZyB0aGUgY29uZmlybWF0 aW9uIHRvZ2dsZSBmaXJzdC4gJm5ic3A7dGhpcyBoZWxwcyBzaW1wbGlmeSB0aGUgY29tcG9uZW50 IHRvIG9uZSBwaHlzaWNhbCBzcGFjZSBwYXJ0IG9mIHRoZSBzYW1lIGNvbnNpZGVyYXRpb24gc2V0 Ljxicj48YnI+IDIuIGphdmFzY3JpcHQgdmFsaWRhdGlvbi4gJm5ic3A7PGJyPlRoZSBhY3Rpb24g YnV0dG9uIGJlbmVhdGggaXMgZGlzYWJsZWQgdW50aWwgdGhlIGNvbmZpcm1hdGlvbiB0b2dnbGUg aGFzIGJlZW4gY2xpY2tlZDxicj4gMy4gZmluYWwgc2VydmVyIHZlcmlmaWNhdGlvbi4gJm5ic3A7 PGJyPnRoZSBzdWJtaXR0ZWQgYWN0aW9uIGlzIG5vdCBhY2NlcHRlZCBieSB0aGUgc3lzdGVtIHVu bGVzcyB0aGUgcG9zdCBjb250YWlucyBib3RoIHRoZSB2ZXJpZmljYXRpb24gZW5hYmxlZCBhbmQg dGhlIGFjdGlvbi4gdGhlIHNlcnZlciB0aGVuIHB1c2hlcyB0aGUgdXBkYXRlPGJyPjxicj48YnI+ KioqKioqPGJyPjxicj4jI0dsb2JhbCBzdGF0dXMgYW5kIHN5c3RlbSBub3RpZmljYXRpb24gc3Rh Y2suIDxicj48YnI+SW1wb3J0YW50IGluZm9ybWF0aW9uIGFib3V0IHRoZSBlbnRpcmUgc3lzdGVt IG9yIGEgY3VycmVudCBwcm9jZXNzLCBkaXNwbGF5ZWQgcHJvbWluZW50bHkuPGJyPiMjI2V4cGxh aW5lZDxicj48YnI+VXNpbmcgdGhlIHJlZmVyZW5jZWQgY29udGVudCBoZWF2aWx5LCB3ZSB0aHJv dyBzeXN0ZW0sIHdhcm5pbmcgYW5kIG5vdGlmaWNhdGlvbiBjb250ZW50IHRvIHRoZSB0b3Agb2Yg dGhlIHBhZ2UgaW4gYSBjb2xsYXBzaW5nLCBncm93bC1zdHlsZSBub3RpZmljYXRpb24gc3lzdGVt lDxicj48YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZsdDtkaXYgaWQ9Im5vdGlmaWNhdGlvbnMiJmd0 Ozxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2gxJmd0 O1N5c3RlbSBNZXNzYWdlcyZsdDsvaDEmZ3Q7PGJyPjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O3AgY2xhc3M9lHN5c3RlbZQmZ3Q7eW91IHNob3VsZCB0 byBpbnN0YWxsIGFlb2x1cy1hbGwgdG8gcHJvcGVybHkgdXNlIGNvbmR1Y3RvciZsdDsvcCZndDs8 YnI+PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cCBj bGFzcz2Uc3RhdHVzIHByb3ZpZGVyMTIzIGJ1aWxklCZndDs8YnI+ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDthIDxicj4gJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7aHJlZj2UcHJvdmlkZXIxMjMtYnVpbGQtc3RhdHVzlCA8YnI+ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2NsYXNzPZRyZWZsaW5rIDUwlCZndDs8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2J1aWxkaW5nIHByb3ZpZGVyMTIz ICZsdDtzcGFuJmd0OzUwJSBDb21wbGV0ZSZsdDsvc3BhbiZndDs8YnI+ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvYSZndDs8YnI+ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvcCZndDs8YnI+PGJy PiAmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L2RpdiZndDs8YnI+PGJyPjxicj4qKioqKio8YnI+PGJy PiMjIFByaW50YWJsZSBtYW5pZmVzdDxicj48YnI+QmVjYXVzZSBvdXIgY29udGVudCBpcyBub3Qg cmVwbGljYXRlZCwgYW5kIGFsbCBlbmFibGVkIHZpZXdzIGFyZSBpbmNsdWRlZCBpbiB0aGUgRE9N OyA8YnI+b3VyIGFwcCBjYW4gYWN0dWFsbHkgcHJpbnQgYXMgaWYgaXQgd2VyZSBhIG1hbmlmZXN0 IGZvciB0aGUgYXV0aGVudGljYXRlZCB1c2VyLjxicj48YnI+V2UgZ2V0IHRoaXMgZmVhdHVyZSBm b3IgZnJlZSBieSBwcm94eSBvZiBvdXIgbWV0aG9kIGZvciByZWZlcmVuY2luZyB2aWV3cyBhbmQg Y29udGVudC48YnI+PGJyPkhhdmluZyB0aGUgYWJpbGl0eSB0byBwcm9kdWNlIGEgaGFyZCBjb3B5 IGluZnJhc3RydWN0dXJlIHJlcG9ydCBtYXkgYmUgYSBnaW1taWNrLCBidXQgaXQncyBhbiBlYXN5 IHdheSB0byBzaG93IGhvdyBjb25kdWN0b3IgY2FuIGhlbHAgcmVzcG9uZCBhbiBJVCBhdWRpdCBz aXR1YXRpb24uPGJyPjxicj4jIyMgZXhhbXBsZSBwcmludCBzdHlsZXNoZWV0IGNoYW5nZXM8YnI+ PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDtAbWVkaWEgcHJpbnQgezxicj48YnI+ICZuYnNwOyZuYnNw OyZuYnNwO2E6YWZ0ZXIgezxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y29udGVudDogIiAoImF0dHIoaHJlZikiKSAiO308YnI+PGJyPiAmbmJzcDsmbmJzcDsm bmJzcDtkaXY6YmVmb3Jlezxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Y29udGVudDogIiAoImF0dHIoaWQpIikgIjt9fTxicj48YnI+ICZuYnNwOyZuYnNwOyZu YnNwO308YnI+PGJyPlRoaXMgd2lsbCBwcmVzZXJ2ZSBhbGwgcmVmZXJlbmNlcyBhbmQgbGlua3Mg dGhyb3VnaG91dCB0aGUgVUkuPGJyPjxicj5BbHNvLCB3ZSBjYW4gbWFudWFsbHkgZGVmaW5lIHNl Y3Rpb25zIHRvIGJlIHByaW50ZWQuPGJyPjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7QG1lZGlhIHBy aW50IHs8YnI+PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDtkaXZ7ZGlzcGxheTpub25lfTxicj48YnI+ ICZuYnNwOyZuYnNwOyZuYnNwOyNwcm92aWRlcnMsICNpbnN0YW5jZXMsICN1c2VycywgI2dsb2Jh bC10aXBzIHtkaXNwbGF5OmJsb2NrICFpbXBvcnRhbnR9PGJyPjxicj4gJm5ic3A7Jm5ic3A7fTxi cj48YnI+V2hpY2ggbWVhbnMgb25seSBzZWN0aW9ucyB3ZSBkZXNpcmUgdG8gYmUgaW5jbHVkZWQg aW4gdGhlIG1hbmlmZXN0IGdldCBwcmludGVkPGJyPjxicj5hbHNvIDxicj48YnI+ICZuYnNwOyZu YnNwOyZuYnNwO0BtZWRpYSBwcmludCB7PGJyPjxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7LnRhYnM6 YmVmb3Jlezxicj4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cGFnZS1icmVh ay1iZWZvcmU6IGFsd2F5czs8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2NvbnRlbnQ6IlRoaXMgc2VjdGlvbiBjb250YWlucyB0aGUgZm9sbG93aW5nOiI7PGJyPiAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsudGFicyBsaSBhOmFmdGVye2NvbnRlbnQ6IiJ9PGJyPiAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsudGFicyB7IGZvbnQtc2l6ZTogMmVtO3BhZ2UtYnJlYWstYWZ0 ZXI6IGFsd2F5czt9PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsudGFicyBsaXtkaXNwbGF5 Omxpc3R9PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDt9PGJyPjxicj5XaGljaCB3aWxsIGNvbnZlcnQg b3VyIHRhYnMgaW50byB3aG9sZSBwYWdlIHNlY3Rpb24gc3VtbWFyaWVzLjxicj48YnI+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+cmVtZW1iZXIsIHRoaXMgZmVhdHVyZSBpcyBmcmVlIGJlY2F1c2Ug d2UgYXJlIGRlc2lnbmluZyBjb25kdWN0b3IgdG8gZ3JhY2VmdWxseSBkZWdyYWRlLiBWZXJ5IGxp dHRsZSBlZmZvcnQgZ29lcyBpbnRvIHByZXNlcnZpbmcgdGhpcyBmZWF0dXJlIHNvIGxvbmcgYXMg b3VyIHN0YW5kYXJkcyBhcmUgbWFpbnRhaW5lZC48YnI+PC9ibG9ja3F1b3RlPjxicj48YnI+IyBF eGlzdGluZyBjb25kdWN0b3IgcGFyYWRpZ21zPGJyPjxicj5UaGVzZSBjaGFuZ2VzIGRvbid0IGNy ZWF0ZSBhbnkgY2hhbmdlcyB0byB0ZXJtaW5vbG9neSwgb3IgaGF2ZSBtdWNoIGltcGFjdCBmb3Ig cHJlLWV4aXN0aW5nIHZpZXdzIGZvciBjb21wb25lbnRzIGFscmVhZHkgYnVpbHQgaW50byBjb25k dWN0b3IuICZuYnNwO0l0IGlzIGxpa2VseSB0aGF0IHRoZSBtYWpvcml0eSBvZiB3aGF0IGhhcyBh bHJlYWR5IGJlZW4gZG9uZSB3aWxsIGJlIHByZXNlcnZlZCBhbmQgb25seSB1bmRlcmdvIG1pbm9y IGNoYW5nZXMgdG8gdGhlIEhBTUwvU0FTUyBzbyB0aGF0IGZlYXR1cmVzIG1heSBiZSBpbnRlZ3Jh dGVkIGludG8gdGhlIGdsb2JhbCB2aWV3Ljxicj48YnI+VGhpcyBoYXMgYmVlbiB3cml0dGVuIHB1 cmVseSB0byBzdGFydCBkaXNjdXNzaW9uIG9uIGhvdyB3ZSBldm9sdmUgQ29uZHVjdG9yIGdvaW5n IGZvcndhcmQgYW5kIEknZCBsb3ZlIHRvIGhlYXIgeW91ciB0aG91Z2h0czogWzxhIGhyZWY9Im1h aWx0bzphbmR5LmZpdHpzaW1vbkByZWRoYXQuY29tIj5hbmR5LmZpdHpzaW1vbkByZWRoYXQuY29t PC9hPiBdKDxhIGhyZWY9Im1haWx0bzphbmR5LmZpdHpzaW1vbkByZWRoYXQuY29tIj5tYWlsdG86 YW5keS5maXR6c2ltb25AcmVkaGF0LmNvbTwvYT4pPGJyPjxzcGFuPiZsdDt1aS1yZWFkbWUuaHRt bCZndDs8L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2JvZHk+PC9o dG1sPg== --===============7939497121634218661==-- From matt.wagner at redhat.com Wed Aug 19 15:23:42 2015 Content-Type: multipart/mixed; boundary="===============8160822653279027957==" 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 --===============8160822653279027957== 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 --===============8160822653279027957==-- From afitzsim at redhat.com Wed Aug 19 15:23:43 2015 Content-Type: multipart/mixed; boundary="===============3779171767965523058==" MIME-Version: 1.0 From: Andrew Fitzsimon To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Tue, 07 Feb 2012 14:33:29 +1000 Message-ID: <568C1928-6388-4779-BC17-6632CA55B9B5@redhat.com> In-Reply-To: 20120206172039.GA7642@mawagner-desktop.usersys.redhat.com --===============3779171767965523058== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable > = > Apologies for the week-long delay in responding. I've replied inline > below: Hey not a worry, = That you responded at all makes you first in line for hi-5's. = I'm only hoping everyone else isn't practising the "if you can't say anythi= ng nice=E2=80=A6" rule > = > 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. > = And all it takes is very very minor considerations per display like "this c= an go away" or "make this bigger" to make all the difference >> ## Views >> = >> One distinct category of content. > = > 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.) > = This doesn't address that at all. The 'pretty view' concept still holds a= lot of weight. = I'm investigating some ways that we can do the switch automatically for all= areas when the user reaches ~6-10 items of content in a view without loss = of functionality or changed UI concepts. = I'll show you how it goes. >> = >> ### Lack of classes for layout >> We will __NOT__ use classes for defining grid layout e.g. `.span-12` or = `.left-120/` >> = > = > This feels much cleaner, though I fear the old pattern will be a hard > habit to break. (For me, at least.) > = Hopefully that is not the case. I can take responsibility for the end resu= lt if the haml is written responsibly without conflicting classes or weird = style rules added inline. = All you'll have to remember to do is to _not do_ things. I'm hoping not ha= ving to touch any SASS at all might be a blessing for many. >> * Browsers with javascript turned off > = > +1000 for doing this. Right now we badly misbehave in some sections if > JavaScript is disabled. > = There is no reason why not to do this. and our fall-back solutions can be q= uite elegant and simple. I'm not honestly saying >2% of users would be the= lynx grokking, screen reader-equipped sysadmins that we all know and love.= but the more levels of compatability we support, the more appreciated and= compatible we will become. especially in restrictive/conservative environm= ents; we'll pass any audit by default. >> = >> ### Explained = >> All icons, visual indicators and ornamental graphics are implemented li= ke 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. > = There's a heap of benefit for teaching the user symbolic glyphs to represen= t functions and zones. = - we can include those glyphs in more constrained views without having to = explain list the full text - we can change terminology around but the visual metaphor for the behavio= ur can be consistent. - we can navigate a translated interface more effectively. What we don't want is 80+ image requests for all browsers or a monstrous se= ries of image sprites to maintain. With the web font approach we target the majority of modern browsers with a= very acceptable fallback and get a stack of flexibility in styling the ico= ns via colour; background-color; text-shadow/ box-shadow; and more. IE and older firefoxes/operas etc do not support .woff but do support other= web font types. We'll be ignoring that and serving them images anyway to = avoid issues like lack of multiple text-shadow support and encoding all the= font variations into our css. To do all the selecting of those cases we c= an use modernizr rules like .ie8 .webfont .icon, .icon{=E2=80=A6image st= uff here=E2=80=A6 } / .webfont{=E2=80=A6font rule here.} its also important to note that superfluous graphics are a very very bad th= ing. they create lots of noise and confusion; put too many graphics togethe= r and the uninitiated will become overwhelmed.right now our monitoring view= suffers from this. >> = >> = >> ## View anchors - or 'single page app' >> = >> View anchors are portions of our design implemented within the one DOM u= sing 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. > = Well we need to at least cache the placeholders for which views the user ha= s access to and serve them up as empty or
's = after that, we can selectively lazy load the expensive view content once th= e view is requested via the anchor; but getting to the view initially shoul= d be instantaneous. the chrome should never flicker. The no--js fallback would be a link inside the blank view areas that posts = and returns with the app-shell active at the new loaded view, maybe even fo= rgetting the other loaded view. basically just wrap each view in the cached shell. The good part is that gor the js version, all changes are done via ajax so = if we ever see the included submit button post (which is otherwise hidden w= hen js is active) we know the no-js version is active and to serve them th= e wrapped view content and return them to their anchor. >> = >> #### 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? > = It depends if :target css selector is allowed or not. (on everything but I= E) If target exists, we can keep the views in tabs with a small concession be= ing that the active tab is no longer rendered in an active state (but stil= l works ) here's a dumb demo of tabs with no JS http://jsfiddle.net/andyfi= tz/QwAwK/ (There are other methods we can use that preserve the functional= ity but they aren't worth changing our html structure for) However; if the browser does not have javascript enabled then they will get= the entire app as one long un-tabbed page with the following accommodatio= ns - the page links will anchor to the section they requested. = - a fixated 'top' link that follows the viewport will appear (hidden when= js is enabled) - the primary and secondary navigation always remain fixed at the top of t= he viewport = - a save button (otherwise hidden by JS) will be fixed at the bottom of th= e view port and will submit all forms on the page. > = > 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. > = This article is relevant and is exactly what we will do http://jqueryford= esigners.com/enabling-the-back-button/ >> = > = > Semi-related, the concept of "global help" at all would be fantastic! ;) > Right now we have some confusing content with no help on-page. > = Thanks :-) allowing helper content to be injected into the page in more way= s that just a tooltip is a must. this approach keeps our dom sane. having the help snippets in a global section or view specific but calling t= o it whenever needed is essential. we can't be inundating accustomed folks= with text but prompting with relevant information is essential. >> = >> = >> ## Client verification / fast feedback >> = > = > 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. Effectively yes. one ajax query coupled with immediate changes to the clie= nt page to signal the change is underway. >> = >> = >> ## Important action certification >> = >> = > = > 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? > = This isn't so much CSS verification as it is occlusion as a safety measure = and ease of use bringer. We don't change the spatial zone where the actions are taking place so ther= e is less confusion of where to go once confirmation has taken place. this gives us both more physical real-estate to the total action as well as= less jumping around for the customer who just wants to complete the action= ; and it looks cool. nothing is more annoying than hunting for the checkbox you forgot to click = after-the-fact. = and nothing is more risky than having important functions without safety co= nfirmation. > = > 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. > = a modified, stripped down version of http://boedesign.com/demos/gritter/ or= https://github.com/ehynds/jquery-notify (sticky notification only) with di= fferent css is on the cards we can apply custom styling to any components we reference inside the notif= ication. e.g. progress bars can look black and white, buttons can appear s= impler. also I plan to collapse the stack to an icon which shows/hides the= entire stack. >> = > = > 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? > = the important declarations were actually superfluous as the print media que= ry begins at the end of the stylesheet but i always put them in for safe m= easure as they can't hurt any other display type when specified inside a me= dia query. also the total page printing thing is an exercise in discipline. we may no= t always serve all views in the one page, but we should be able to and gett= ing a print version that makes sense for free is a good way to check up on = how we're doing that everybody can easily review. >> = >> # Existing conductor paradigms >> = >> These changes don't create any changes to terminology, or have much impa= ct for pre-existing views for components already built into conductor. It = is 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 in= tegrated 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. Well, if we keep doing it wrong we're always going to have to redo it... pl= ain and simple ;-P But I appreciate the thought and it is top of my mind to not waste our ener= gy. From what I've seen, the history is hardly considered from both an imp= lementors AND designers perspective and solutions aren't resolving with a c= ompromise but rather a cop-out. There's heaps of salvageable code and concepts from our existing UI to evol= ve from. I hardly think the idea of monitoring and administering modes are= going away and I can't imagine we will want to ditch pretty and grid view = outright (though it would be great if we could get them both for free). = The majority of these ideas are attempting to isolate components and implem= ent them as part of a considered set so that we can change and evolve at an= y time without tea bagging our users workflow simply because a query got to= o expensive so we gave it some random new view. Right now if we want to mitigate the number of http-requests we do we have = to seriously re-architect our haml. but with a app-shell approach we can e= asily switch which aspects are getting too expensive for the initial load a= nd nominate they be ajaxed when requested only. Right now if we want to tweak the monitoring view to be used in some weird = way like a data centre kiosk it would require a serious effort and lots of = cost-benefit soul-searching before we painstaikingly construct the views ma= nually with plenty of duplication along the way. if we keep our componen= ts homogenous and use a global app shell approach, a completely different d= isplay is as simple as changing one class which specifies what to show/hide. > = >> This has been written purely to start discussion on how we evolve Conduc= tor going forward and I'd love to hear your thoughts: [andy.fitzsimon(a)red= hat.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 colour? So the tradition here (to my understanding) is that error states of objects= are always going to be displayed in red.. this is mostly for the monitorin= g views and so that seasoned admins with huge deployments can glance at iss= ues and make assessments without having to comb through our admin section. things functioning fine are not so important unless it's for the first time= so unfortunately if we are going to use tone and colour contrast to serve = as an indicator, we're going to have to keep it pretty homogenous elsewhere. Not to say that when a task is being done we can't brighten up peoples day = with kick-ass success prompts and the like. The default views however need to chill out so that the content can speak f= or itself. everything else is up for grabs so I agree; lets not waste the= opportunity! Thanks again for your feedback Matt, it's really appreciated. Hopefully I'l= l hear more from others soon - Andy --===============3779171767965523058== Content-Type: text/html MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj48ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGJyPkFwb2xvZ2llcyBm b3IgdGhlIHdlZWstbG9uZyBkZWxheSBpbiByZXNwb25kaW5nLiBJJ3ZlIHJlcGxpZWQgaW5saW5l PGJyPmJlbG93Ojxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+SGV5IG5vdCBh IHdvcnJ5LCAmbmJzcDs8L2Rpdj48ZGl2PlRoYXQgeW91IHJlc3BvbmRlZCBhdCBhbGwgbWFrZXMg eW91IGZpcnN0IGluIGxpbmUgZm9yIGhpLTUncy4mbmJzcDs8L2Rpdj48ZGl2PkknbSBvbmx5IGhv cGluZyBldmVyeW9uZSBlbHNlIGlzbid0IHByYWN0aXNpbmcgdGhlICJpZiB5b3UgY2FuJ3Qgc2F5 IGFueXRoaW5nIG5pY2WFIiBydWxlPC9kaXY+PGRpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9IiM3YWEwMzQiPjxi cj48L2ZvbnQ+SSd2ZSBzb3J0IG9mIGJlZW4gd2F0Y2hpbmcgdGhlICJyZXNwb25zaXZlIGRlc2ln biIgbW92ZW1lbnQgZnJvbSB0aGU8YnI+c2lkZWxpbmVzIGFuZCBhbSByYXRoZXIgaW50cmlndWVk LiBUaGUgYWJpbGl0eSB0byBoYXZlIG9uZSBsYXlvdXQgdGhhdDxicj53b3JrcyBhY3Jvc3MgYSB3 aWRlIHZhcmlldHkgb2YgZGV2aWNlcyB3b3VsZCBiZSBmYW50YXN0aWMuPGJyPjxicj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+QW5kIGFsbCBpdCB0YWtlcyBpcyB2ZXJ5IHZlcnkg bWlub3IgY29uc2lkZXJhdGlvbnMgcGVyIGRpc3BsYXkgbGlrZSAidGhpcyBjYW4gZ28gYXdheSIg Jm5ic3A7b3IgIm1ha2UgdGhpcyBiaWdnZXIiIHRvIG1ha2UgYWxsIHRoZSBkaWZmZXJlbmNlPGJy Pjxicj48L2Rpdj48ZGl2Pjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPiMjIFZpZXdzPGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uZSBkaXN0 aW5jdCBjYXRlZ29yeSBvZiBjb250ZW50LjwvYmxvY2txdW90ZT48Zm9udCBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgY29sb3I9IiM3YWEwMzQiPjxicj48L2ZvbnQ+RG9lcyB0aGlzIGltcGx5IHRo YXQgd2UgYXJlIG1vdmluZyBhd2F5IGZyb20gdGhlICJwcmV0dHkgdmlldyIgdnMuPGJyPiJkZXRh aWwgdmlldyIgc3lzdGVtPyAoSSB3b3VsZCBub3QgYmUgYXZlcnNlIHRvIHRoaXMgYXQgYWxsLCBi dXQgd2FudGVkPGJyPnRvIGJlIGNsZWFyLik8YnI+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2 PlRoaXMgZG9lc24ndCBhZGRyZXNzIHRoYXQgYXQgYWxsLiAmbmJzcDtUaGUgJ3ByZXR0eSB2aWV3 JyAmbmJzcDtjb25jZXB0IHN0aWxsIGhvbGRzIGEgbG90IG9mIHdlaWdodC4gJm5ic3A7PC9kaXY+ PGRpdj5JJ20gaW52ZXN0aWdhdGluZyBzb21lIHdheXMgdGhhdCB3ZSBjYW4gZG8gdGhlIHN3aXRj aCBhdXRvbWF0aWNhbGx5IGZvciBhbGwgYXJlYXMgd2hlbiB0aGUgdXNlciByZWFjaGVzIH42LTEw IGl0ZW1zIG9mIGNvbnRlbnQgaW4gYSB2aWV3IHdpdGhvdXQgbG9zcyBvZiBmdW5jdGlvbmFsaXR5 IG9yIGNoYW5nZWQgVUkgY29uY2VwdHMuJm5ic3A7PC9kaXY+PGRpdj5JJ2xsIHNob3cgeW91IGhv dyBpdCBnb2VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFw cGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjMDAwMDAwIj48YnI+PC9mb250PjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4jIyMgJm5ic3A7TGFjayBvZiBjbGFzc2VzIGZvciBsYXlv dXQ8YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPldlIHdpbGwgX19OT1Rf XyB1c2UgY2xhc3NlcyBmb3IgZGVmaW5pbmcgZ3JpZCBsYXlvdXQgZS5nLiBgLnNwYW4tMTJgIG9y IGAubGVmdC0xMjAvYDxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJy PjwvYmxvY2txdW90ZT48YnI+VGhpcyBmZWVscyBtdWNoIGNsZWFuZXIsIHRob3VnaCBJIGZlYXIg dGhlIG9sZCBwYXR0ZXJuIHdpbGwgYmUgYSBoYXJkPGJyPmhhYml0IHRvIGJyZWFrLiAoRm9yIG1l LCBhdCBsZWFzdC4pPGJyPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJyPkhvcGVmdWxseSB0aGF0 IGlzIG5vdCB0aGUgY2FzZS4gJm5ic3A7SSBjYW4gdGFrZSByZXNwb25zaWJpbGl0eSBmb3IgdGhl IGVuZCByZXN1bHQgaWYgdGhlIGhhbWwgaXMgd3JpdHRlbiByZXNwb25zaWJseSB3aXRob3V0IGNv bmZsaWN0aW5nIGNsYXNzZXMgb3Igd2VpcmQgc3R5bGUgcnVsZXMgYWRkZWQgaW5saW5lLiZuYnNw OzwvZGl2PjxkaXY+QWxsIHlvdSdsbCBoYXZlIHRvIHJlbWVtYmVyIHRvIGRvIGlzIHRvIF9ub3Qg ZG9fIHRoaW5ncy4gJm5ic3A7SSdtIGhvcGluZyZuYnNwO25vdCBoYXZpbmcgdG8gdG91Y2ggYW55 IFNBU1MgYXQgYWxsIG1pZ2h0IGJlIGEgYmxlc3NpbmcgZm9yIG1hbnkuPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4gKiBCcm93c2VycyB3aXRoIGphdmFzY3JpcHQgdHVybmVkIG9mZjxicj48L2Js b2NrcXVvdGU+PGJyPisxMDAwIGZvciBkb2luZyB0aGlzLiBSaWdodCBub3cgd2UgYmFkbHkgbWlz YmVoYXZlIGluIHNvbWUgc2VjdGlvbnMgaWY8YnI+SmF2YVNjcmlwdCBpcyBkaXNhYmxlZC48YnI+ PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZXJlIGlzIG5vIHJl YXNvbiB3aHkgbm90IHRvIGRvIHRoaXMuIGFuZCBvdXIgZmFsbC1iYWNrIHNvbHV0aW9ucyBjYW4g YmUgcXVpdGUgZWxlZ2FudCBhbmQgc2ltcGxlLiAmbmJzcDtJJ20gbm90IGhvbmVzdGx5IHNheWlu ZyAmZ3Q7MiUgb2YgdXNlcnMgd291bGQgYmUgdGhlIGx5bnggZ3Jva2tpbmcsIHNjcmVlbiByZWFk ZXItZXF1aXBwZWQgc3lzYWRtaW5zIHRoYXQgd2UgYWxsIGtub3cgYW5kIGxvdmUuICZuYnNwO2J1 dCB0aGUgbW9yZSBsZXZlbHMgb2YgY29tcGF0YWJpbGl0eSB3ZSBzdXBwb3J0LCB0aGUgbW9yZSBh cHByZWNpYXRlZCBhbmQgY29tcGF0aWJsZSB3ZSB3aWxsIGJlY29tZS4gZXNwZWNpYWxseSBpbiBy ZXN0cmljdGl2ZS9jb25zZXJ2YXRpdmUgZW52aXJvbm1lbnRzOyB3ZSdsbCBwYXNzIGFueSBhdWRp dCBieSBkZWZhdWx0LjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PGRpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3Rl PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPiMjIyBFeHBsYWluZWQgPGJyPjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5BbGwgaWNvbnMsIHZpc3VhbCBpbmRpY2F0b3JzIGFuZCBv cm5hbWVudGFsIGdyYXBoaWNzICZuYnNwO2FyZSBpbXBsZW1lbnRlZCBsaWtlIHRoaXM6PGJyPjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPiAqIFZlY3RvciBnbHlwaHMgYXJlIGVuY29kZWQgaW50byBhIHdv ZmYgd2ViZm9udCA8YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPiAqIFRo ZSB3b2ZmIGZvbnQgaXMgYmFzZTY0IGVuY29kZWQgaW4gdGhlIHN0eWxlc2hlZXQgdG8gbWluaW1p c2UgaHR0cCByZXF1ZXN0cyAodGhlIGN1cnJlbnQgc2V0IG9mIDMwIGljb25zIGlzIH41aykgc28g dGhpcyBpcyB2ZXJ5IGFjY2VwdGFibGUuPGJyPjwvYmxvY2txdW90ZT48YnI+VGhpcyBpcyBteSBm aXJzdCByZWFsIGV4cG9zdXJlIHRvIHRoaXMgY29uY2VwdCwgYnV0IHRoaXMgc291bmRzIHJlYWxs eTxicj5ub3ZlbC48YnI+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5UaGVy ZSdzIGEgaGVhcCBvZiBiZW5lZml0IGZvciB0ZWFjaGluZyB0aGUgdXNlciBzeW1ib2xpYyBnbHlw aHMgdG8gcmVwcmVzZW50IGZ1bmN0aW9ucyBhbmQgem9uZXMuICZuYnNwOyZuYnNwOzwvZGl2Pjxk aXY+Jm5ic3A7LSB3ZSBjYW4gaW5jbHVkZSB0aG9zZSBnbHlwaHMgaW4gbW9yZSBjb25zdHJhaW5l ZCB2aWV3cyB3aXRob3V0IGhhdmluZyB0byBleHBsYWluIGxpc3QgdGhlIGZ1bGwgdGV4dDwvZGl2 PjxkaXY+Jm5ic3A7LSB3ZSBjYW4gY2hhbmdlIHRlcm1pbm9sb2d5IGFyb3VuZCBidXQgdGhlIHZp c3VhbCBtZXRhcGhvciBmb3IgdGhlIGJlaGF2aW91ciBjYW4gYmUgY29uc2lzdGVudC48L2Rpdj48 ZGl2PiZuYnNwOy0gd2UgY2FuIG5hdmlnYXRlIGEgdHJhbnNsYXRlZCBpbnRlcmZhY2UgbW9yZSBl ZmZlY3RpdmVseS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldoYXQgd2UgZG9uJ3Qgd2FudCBp cyA4MCsgaW1hZ2UgcmVxdWVzdHMgZm9yIGFsbCBicm93c2VycyBvciBhIG1vbnN0cm91cyBzZXJp ZXMgb2YgaW1hZ2Ugc3ByaXRlcyB0byBtYWludGFpbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PldpdGggdGhlIHdlYiBmb250IGFwcHJvYWNoIHdlIHRhcmdldCB0aGUgbWFqb3JpdHkgb2YgbW9k ZXJuIGJyb3dzZXJzIHdpdGggYSB2ZXJ5IGFjY2VwdGFibGUgZmFsbGJhY2sgYW5kIGdldCBhIHN0 YWNrIG9mIGZsZXhpYmlsaXR5IGluIHN0eWxpbmcgdGhlIGljb25zIHZpYSAmbmJzcDtjb2xvdXI7 IGJhY2tncm91bmQtY29sb3I7IHRleHQtc2hhZG93LyBib3gtc2hhZG93OyBhbmQgbW9yZS48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PklFIGFuZCBvbGRlciBmaXJlZm94ZXMvb3BlcmFzIGV0YyBk byBub3Qgc3VwcG9ydCAud29mZiBidXQgZG8gc3VwcG9ydCBvdGhlciB3ZWIgZm9udCB0eXBlcy4g Jm5ic3A7V2UnbGwgYmUgaWdub3JpbmcgdGhhdCBhbmQgc2VydmluZyB0aGVtIGltYWdlcyBhbnl3 YXkgdG8gYXZvaWQgaXNzdWVzIGxpa2UgbGFjayBvZiBtdWx0aXBsZSB0ZXh0LXNoYWRvdyBzdXBw b3J0IGFuZCBlbmNvZGluZyBhbGwgdGhlIGZvbnQgdmFyaWF0aW9ucyBpbnRvIG91ciBjc3MuICZu YnNwO1RvIGRvIGFsbCB0aGUgc2VsZWN0aW5nIG9mIHRob3NlIGNhc2VzIHdlIGNhbiB1c2UgbW9k ZXJuaXpyIHJ1bGVzIGxpa2UgJm5ic3A7ICZuYnNwOy5pZTggLndlYmZvbnQgLmljb24sJm5ic3A7 Lmljb257hWltYWdlIHN0dWZmIGhlcmWFIH0gJm5ic3A7IC8gJm5ic3A7IC53ZWJmb250e4Vmb250 IHJ1bGUgaGVyZS59PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5pdHMgYWxzbyBpbXBvcnRhbnQg dG8gbm90ZSB0aGF0IHN1cGVyZmx1b3VzIGdyYXBoaWNzIGFyZSBhIHZlcnkgdmVyeSBiYWQgdGhp bmcuIHRoZXkgY3JlYXRlIGxvdHMgb2Ygbm9pc2UgYW5kIGNvbmZ1c2lvbjsgcHV0IHRvbyBtYW55 IGdyYXBoaWNzIHRvZ2V0aGVyIGFuZCB0aGUgdW5pbml0aWF0ZWQgd2lsbCBiZWNvbWUgb3Zlcndo ZWxtZWQucmlnaHQgbm93IG91ciBtb25pdG9yaW5nIHZpZXcgc3VmZmVycyBmcm9tIHRoaXMuPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+IyMgVmlldyBh bmNob3JzIC0gb3IgJ3NpbmdsZSBwYWdlIGFwcCc8YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Vmll dyBhbmNob3JzIGFyZSBwb3J0aW9ucyBvZiBvdXIgZGVzaWduIGltcGxlbWVudGVkIHdpdGhpbiB0 aGUgb25lIERPTSB1c2luZyBiYXNpYyBhbmNob3JpbmcgZnVuY3Rpb25hbGl0eS48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+IyMjIEV4cGxhaW5lZDxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+SW4gdGhlIHByb3Bvc2VkIGNoYW5nZSwgdGhlIGVudGlyZSBjb25kdWN0b3Ig aXMgb25lIHBhZ2UgZm9yIGFsbCBkZWZhdWx0IHZpZXdzLCA8YnI+PC9ibG9ja3F1b3RlPjxicj5X aGF0IEkgc3RpbGwgZG9uJ3QgcXVpdGUgdW5kZXJzdGFuZCBoZXJlIGlzIHdoZXRoZXIgdGhpcyBt ZWFucyB0aGF0LDxicj53aGVuIHdlIHJlbmRlciB0aGlzIHBhZ2UsIHdlIG5lZWQgdG8gcmVuZGVy ICphbGwqIHZpZXdzIGluIGFkdmFuY2UsIG9yPGJyPmlmIHRoZXkncmUgbGF6eS1sb2FkZWQgdmlh IEFKQVguIFRoZSBmb3JtZXIgc291bmRzIGxpa2UgaXQgd2lsbCBiZTxicj5yYXRoZXIgc2xvdyAo b24gdGhlIGJhY2stZW5kKSwgc2luY2Ugd2UgaGF2ZSBhIGZldyBwYWdlcyB0aGF0IG1ha2U8YnI+ ZXhwZW5zaXZlIGNhbGxzIHRvIGV4dGVybmFsIHNlcnZpY2VzLjxicj48YnI+PC9kaXY+PC9ibG9j a3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+V2VsbCB3ZSBuZWVkIHRvIGF0IGxlYXN0IGNhY2hl IHRoZSBwbGFjZWhvbGRlcnMgZm9yIHdoaWNoIHZpZXdzIHRoZSB1c2VyIGhhcyBhY2Nlc3MgdG8g YW5kIHNlcnZlIHRoZW0gdXAgYXMgZW1wdHkgJmx0O2RpdnMmZ3Q7IG9yICZsdDtzZWN0aW9uJmd0 OydzJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5hZnRlciB0aGF0LCB3ZSBjYW4gc2Vs ZWN0aXZlbHkgbGF6eSBsb2FkIHRoZSBleHBlbnNpdmUgdmlldyBjb250ZW50IG9uY2UgdGhlIHZp ZXcgaXMgcmVxdWVzdGVkIHZpYSB0aGUgYW5jaG9yOyBidXQgZ2V0dGluZyB0byB0aGUgdmlldyBp bml0aWFsbHkgc2hvdWxkIGJlIGluc3RhbnRhbmVvdXMuICZuYnNwO3RoZSBjaHJvbWUgc2hvdWxk IG5ldmVyIGZsaWNrZXIuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbm8tLWpzIGZhbGxi YWNrIHdvdWxkIGJlIGEgbGluayBpbnNpZGUgdGhlIGJsYW5rIHZpZXcgYXJlYXMgdGhhdCBwb3N0 cyBhbmQgcmV0dXJucyB3aXRoIHRoZSBhcHAtc2hlbGwgYWN0aXZlIGF0IHRoZSBuZXcgbG9hZGVk IHZpZXcsIG1heWJlIGV2ZW4gZm9yZ2V0dGluZyB0aGUgb3RoZXIgbG9hZGVkIHZpZXcuPC9kaXY+ PGRpdj5iYXNpY2FsbHkganVzdCB3cmFwIGVhY2ggdmlldyBpbiB0aGUgY2FjaGVkIHNoZWxsLjwv ZGl2PjxkaXY+VGhlIGdvb2QgcGFydCBpcyB0aGF0IGdvciB0aGUganMgdmVyc2lvbiwmbmJzcDth bGwgY2hhbmdlcyBhcmUgZG9uZSB2aWEgYWpheCBzbyBpZiB3ZSBldmVyIHNlZSB0aGUgaW5jbHVk ZWQgc3VibWl0IGJ1dHRvbiBwb3N0ICh3aGljaCBpcyBvdGhlcndpc2UgaGlkZGVuIHdoZW4ganMg aXMgYWN0aXZlKSAmbmJzcDt3ZSBrbm93IHRoZSBuby1qcyB2ZXJzaW9uIGlzIGFjdGl2ZSBhbmQg dG8gc2VydmUgdGhlbSB0aGUgd3JhcHBlZCB2aWV3IGNvbnRlbnQgYW5kIHJldHVybiB0aGVtIHRv IHRoZWlyIGFuY2hvci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2Nr cXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+IyMjIyB3aGF0IEpTIGRvZXM8YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+MS4gSlMgaGlkZXMgYWxsIG5vbiBhY3RpdmUgdmlld3MgZXhjZXB0IGZv ciB0aGUgZGVmYXVsdCB2aWV3IChjbGFzc2VkIGFzIGFjdGl2ZSBieSB0aGUganMpPGJyPjwvYmxv Y2txdW90ZT48YnI+SG93IGRvZXMgdGhpcyBiZWhhdmUgaW4gYSBicm93c2VyIHdpdGhvdXQgSmF2 YVNjcmlwdCAvIHdpdGggSlMgZGlzYWJsZWQ/PGJyPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRp dj48YnI+PC9kaXY+PGRpdj5JdCBkZXBlbmRzIGlmIDp0YXJnZXQgY3NzIHNlbGVjdG9yIGlzIGFs bG93ZWQgb3Igbm90LiAmbmJzcDsob24gZXZlcnl0aGluZyBidXQgSUUpPC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5JZiB0YXJnZXQgZXhpc3RzLCAmbmJzcDt3ZSBjYW4ga2VlcCB0aGUgdmlld3Mg aW4gdGFicyB3aXRoIGEgc21hbGwgY29uY2Vzc2lvbiBiZWluZyB0aGF0IHRoZSBhY3RpdmUgdGFi IGlzIG5vIGxvbmdlciByZW5kZXJlZCAmbmJzcDtpbiBhbiBhY3RpdmUgc3RhdGUgKGJ1dCBzdGls bCB3b3JrcyApICZuYnNwO2hlcmUncyBhIGR1bWIgZGVtbyBvZiB0YWJzIHdpdGggbm8gSlMmbmJz cDs8YSBocmVmPSJodHRwOi8vanNmaWRkbGUubmV0L2FuZHlmaXR6L1F3QXdLLyI+aHR0cDovL2pz ZmlkZGxlLm5ldC9hbmR5Zml0ei9Rd0F3Sy88L2E+Jm5ic3A7IChUaGVyZSBhcmUgb3RoZXIgbWV0 aG9kcyB3ZSBjYW4gdXNlIHRoYXQgcHJlc2VydmUgdGhlIGZ1bmN0aW9uYWxpdHkgYnV0IHRoZXkg YXJlbid0IHdvcnRoIGNoYW5naW5nIG91ciBodG1sIHN0cnVjdHVyZSBmb3IpPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5Ib3dldmVyOyBpZiB0aGUgYnJvd3NlciBkb2VzIG5vdCBoYXZlIGphdmFz Y3JpcHQgZW5hYmxlZCB0aGVuIHRoZXkgd2lsbCBnZXQgdGhlIGVudGlyZSBhcHAgYXMgb25lIGxv bmcgJm5ic3A7dW4tdGFiYmVkIHBhZ2Ugd2l0aCB0aGUgZm9sbG93aW5nIGFjY29tbW9kYXRpb25z PC9kaXY+PGRpdj4mbmJzcDstIHRoZSBwYWdlIGxpbmtzIHdpbGwgYW5jaG9yIHRvIHRoZSBzZWN0 aW9uIHRoZXkgcmVxdWVzdGVkLiZuYnNwOzwvZGl2PjxkaXY+Jm5ic3A7LSBhIGZpeGF0ZWQgJ3Rv cCcgbGluayB0aGF0IGZvbGxvd3MgdGhlIHZpZXdwb3J0ICZuYnNwO3dpbGwgYXBwZWFyIChoaWRk ZW4gd2hlbiBqcyBpcyBlbmFibGVkKTwvZGl2PjxkaXY+Jm5ic3A7LSB0aGUgcHJpbWFyeSBhbmQg c2Vjb25kYXJ5IG5hdmlnYXRpb24gYWx3YXlzIHJlbWFpbiBmaXhlZCBhdCB0aGUgdG9wIG9mIHRo ZSB2aWV3cG9ydCZuYnNwOzwvZGl2PjxkaXY+Jm5ic3A7LSBhIHNhdmUgYnV0dG9uIChvdGhlcndp c2UgaGlkZGVuIGJ5IEpTKSB3aWxsIGJlIGZpeGVkIGF0IHRoZSBib3R0b20gb2YgdGhlIHZpZXcg cG9ydCBhbmQgd2lsbCBzdWJtaXQgYWxsIGZvcm1zIG9uIHRoZSBwYWdlLjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGJyPkFz IFNjb3R0IGJyb3VnaHQgdXAgb24gSVJDIHRoaXMgbW9ybmluZywgdGhlcmUgYXBwZWFyIHRvIGJl IHBsYWNlcyB3aGVyZTxicj53ZSBjdXJyZW50bHkgYnJlYWsgdGhlICJCYWNrIiBidXR0b24uIElm IHdlJ3JlIGFibGUgdG8gYmVjb21lIGNvbnNpc3RlbnQ8YnI+aW4gcHJlc2VydmluZyBoaXN0b3J5 LCB0aGF0IHdvdWxkIGJlIGZhbnRhc3RpYy48YnI+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT5UaGlz IGFydGljbGUgaXMgcmVsZXZhbnQgJm5ic3A7YW5kIGlzIGV4YWN0bHkgd2hhdCB3ZSB3aWxsIGRv ICZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9qcXVlcnlmb3JkZXNpZ25lcnMuY29tL2VuYWJsaW5nLXRo ZS1iYWNrLWJ1dHRvbi8iPmh0dHA6Ly9qcXVlcnlmb3JkZXNpZ25lcnMuY29tL2VuYWJsaW5nLXRo ZS1iYWNrLWJ1dHRvbi88L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+ PGJyPlNlbWktcmVsYXRlZCwgdGhlIGNvbmNlcHQgb2YgImdsb2JhbCBoZWxwIiBhdCBhbGwgd291 bGQgYmUgZmFudGFzdGljISA7KTxicj5SaWdodCBub3cgd2UgaGF2ZSBzb21lIGNvbmZ1c2luZyBj b250ZW50IHdpdGggbm8gaGVscCBvbi1wYWdlLjxicj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxk aXY+PGJyPjwvZGl2PlRoYW5rcyA6LSkgYWxsb3dpbmcgaGVscGVyIGNvbnRlbnQgdG8gYmUgaW5q ZWN0ZWQgaW50byB0aGUgcGFnZSBpbiBtb3JlIHdheXMgdGhhdCBqdXN0IGEgdG9vbHRpcCBpcyBh IG11c3QuICZuYnNwO3RoaXMgYXBwcm9hY2gga2VlcHMgb3VyIGRvbSBzYW5lLjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+aGF2aW5nIHRoZSBoZWxwIHNuaXBwZXRzIGluIGEgZ2xvYmFsIHNlY3Rp b24gb3IgdmlldyBzcGVjaWZpYyBidXQgY2FsbGluZyB0byBpdCB3aGVuZXZlciBuZWVkZWQgaXMg ZXNzZW50aWFsLiAmbmJzcDt3ZSBjYW4ndCBiZSBpbnVuZGF0aW5nIGFjY3VzdG9tZWQgZm9sa3Mg d2l0aCB0ZXh0IGJ1dCBwcm9tcHRpbmcgd2l0aCByZWxldmFudCBpbmZvcm1hdGlvbiBpcyBlc3Nl bnRpYWwuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4jIyBD bGllbnQgdmVyaWZpY2F0aW9uIC8gZmFzdCBmZWVkYmFjazxicj48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJyPjwvYmxvY2txdW90ZT48YnI+SXQncyBub3QgY2xlYXIgdG8g bWUgZnJvbSB0aGlzLCBidXQgZG9lcyB0aGlzIGFjdHVhbGx5IHJlcXVpcmUgYSBzZWNvbmQ8YnI+ Y2FsbD8gSXQgc2VlbXMgbGlrZSwgb24gY2xpY2tpbmcgJ3N1Ym1pdCcgb3Igd2hhdG5vdCwgd2Ug Y291bGQgY2hhbmdlPGJyPnRoZSBzdGF0dXMgbGlrZSB5b3UgZGVzY3JpYmUsIGFuZCB0aGVuLCB3 aGVuIHRoZSByZXF1ZXN0IGNvbXBsZXRlczxicj5uYXR1cmFsbHksIGFwcGx5IHRoZSB1cGRhdGUu IFRoYXQgc2F2ZXMgdXMgZnJvbSBhbiBleHRyYSBBSkFYIHF1ZXJ5IHRvPGJyPmNoZWNrIHRoZSBz dGF0dXMuPGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5FZmZlY3RpdmVseSB5 ZXMuICZuYnNwO29uZSBhamF4IHF1ZXJ5IGNvdXBsZWQgd2l0aCBpbW1lZGlhdGUgY2hhbmdlcyB0 byB0aGUgY2xpZW50IHBhZ2UgdG8gc2lnbmFsIHRoZSBjaGFuZ2UgaXMgdW5kZXJ3YXkuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+IyMgSW1wb3J0YW50 IGFjdGlvbiBjZXJ0aWZpY2F0aW9uPGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2Nr cXVvdGU+PGJyPlJpZ2h0IG5vdyB3ZSdyZSBqdXN0IHVzaW5nIEpTIHZlcmlmaWNhdGlvbiBpbiBh IGhhbmRmdWwgb2YgcGxhY2VzLDxicj5iZWNhdXNlIFJhaWxzIGluY2x1ZGVzIGFuIGVhc3kgaGVs cGVyIGZvciB0aGlzLiBJcyB0aGVyZSBtdWNoIG9mIGFuPGJyPmFkdmFudGFnZSB0byBpbnZvbHZp bmcgQ1NTIGFuZCBzZXJ2ZXItc2lkZSB2ZXJpZmljYXRpb24gYXMgd2VsbD88YnI+PGJyPjwvZGl2 PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5UaGlzIGlzbid0IHNvIG11Y2ggQ1NTIHZlcmlm aWNhdGlvbiBhcyBpdCBpcyBvY2NsdXNpb24gYXMgYSBzYWZldHkgbWVhc3VyZSBhbmQgZWFzZSBv ZiB1c2UgYnJpbmdlci48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldlIGRvbid0IGNoYW5nZSB0 aGUgc3BhdGlhbCB6b25lIHdoZXJlIHRoZSBhY3Rpb25zIGFyZSB0YWtpbmcgcGxhY2Ugc28gdGhl cmUgaXMgbGVzcyBjb25mdXNpb24gb2Ygd2hlcmUgdG8gZ28gb25jZSBjb25maXJtYXRpb24gaGFz IHRha2VuIHBsYWNlLjwvZGl2PjxkaXY+dGhpcyBnaXZlcyB1cyBib3RoIG1vcmUgcGh5c2ljYWwg cmVhbC1lc3RhdGUgdG8gdGhlIHRvdGFsIGFjdGlvbiBhcyB3ZWxsIGFzIGxlc3MganVtcGluZyBh cm91bmQgZm9yIHRoZSBjdXN0b21lciB3aG8ganVzdCB3YW50cyB0byBjb21wbGV0ZSB0aGUgYWN0 aW9uOyBhbmQgaXQgbG9va3MgY29vbC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pm5vdGhpbmcg aXMgbW9yZSBhbm5veWluZyB0aGFuIGh1bnRpbmcgZm9yIHRoZSBjaGVja2JveCB5b3UgZm9yZ290 IHRvIGNsaWNrIGFmdGVyLXRoZS1mYWN0LiZuYnNwOzwvZGl2PjxkaXY+YW5kJm5ic3A7bm90aGlu ZyBpcyBtb3JlIHJpc2t5IHRoYW4gaGF2aW5nIGltcG9ydGFudCBmdW5jdGlvbnMgd2l0aG91dCBz YWZldHkgY29uZmlybWF0aW9uLjwvZGl2PjxkaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGNvbG9yPSIjN2FhMDM0Ij48YnI+ PC9mb250PkZyb20gdGFsa2luZyB0byBhIGZldyBwZW9wbGUgd2hvIGRvbid0IHVzZSBDb25kdWN0 b3IgZXZlcnkgZGF5LCBpdDxicj5zb3VuZHMgbGlrZSBvdXIgY3VycmVudCBmbGFzaCBtZXNzYWdl cyBhcmUgZWFzeSB0byBtaXNzIC8gb3Zlcmxvb2suIEknZDxicj5sb3ZlIHRvIG1ha2UgdGhlbSBt dWNoIG1vcmUgcHJvbWluZW50Ljxicj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PmEgbW9kaWZpZWQsIHN0cmlwcGVkIGRvd24gdmVyc2lvbiBvZiZuYnNwOzxhIGhyZWY9Imh0 dHA6Ly9ib2VkZXNpZ24uY29tL2RlbW9zL2dyaXR0ZXIvIj5odHRwOi8vYm9lZGVzaWduLmNvbS9k ZW1vcy9ncml0dGVyLzwvYT4mbmJzcDtvciZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9laHluZHMvanF1ZXJ5LW5vdGlmeSI+aHR0cHM6Ly9naXRodWIuY29tL2VoeW5kcy9qcXVlcnkt bm90aWZ5PC9hPiZuYnNwOyhzdGlja3kgbm90aWZpY2F0aW9uIG9ubHkpIHdpdGggZGlmZmVyZW50 IGNzcyBpcyBvbiB0aGUgY2FyZHM8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PndlIGNhbiBhcHBs eSBjdXN0b20gc3R5bGluZyB0byBhbnkgY29tcG9uZW50cyB3ZSByZWZlcmVuY2UgaW5zaWRlIHRo ZSBub3RpZmljYXRpb24uICZuYnNwO2UuZy4gcHJvZ3Jlc3MgYmFycyBjYW4gbG9vayBibGFjayBh bmQgd2hpdGUsIGJ1dHRvbnMgY2FuIGFwcGVhciBzaW1wbGVyLiAmbmJzcDthbHNvIEkgcGxhbiB0 byBjb2xsYXBzZSB0aGUgc3RhY2sgdG8gYW4gaWNvbiB3aGljaCBzaG93cy9oaWRlcyB0aGUgZW50 aXJlIHN0YWNrLjwvZGl2PjxkaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGNvbG9y PSIjMDAwMDAwIj48YnI+PC9mb250PjwvYmxvY2txdW90ZT48YnI+SSB3aWxsIGRlZmluaXRlbHkg eWllbGQgdG8geW91IGhlcmUgYmVjYXVzZSB5b3UgYXJlIGFzdHJvbm9taWNhbGx5IG1vcmU8YnI+ ZXhwZXJpZW5jZWQgd2l0aCB0aGlzIHN0dWZmIHRoYW4gSSBhbSwgYnV0IEkgdGhvdWdodCB0aGF0 IHVzaW5nPGJyPiFpbXBvcnRhbnQgd2FzIGEgYml0IG9mIGEgaGFjayB0byBiZSBhdm9pZGVkIGV4 Y2VwdCB3aGVyZSB5b3UgbmVlZGVkIHRvPGJyPm92ZXJyaWRlIHN0eWxlcyBvbiBhIHBhcnRpY3Vs YXIgcGFnZS4gSXMgdGhpcyBub3QgY29ycmVjdD88YnI+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48 ZGl2Pjxicj48L2Rpdj50aGUgaW1wb3J0YW50IGRlY2xhcmF0aW9ucyB3ZXJlIGFjdHVhbGx5IHN1 cGVyZmx1b3VzIGFzIHRoZSBwcmludCBtZWRpYSBxdWVyeSBiZWdpbnMgYXQgdGhlIGVuZCBvZiB0 aGUgc3R5bGVzaGVldCAmbmJzcDtidXQgaSBhbHdheXMgcHV0IHRoZW0gaW4gZm9yIHNhZmUgbWVh c3VyZSBhcyB0aGV5IGNhbid0IGh1cnQgYW55IG90aGVyIGRpc3BsYXkgdHlwZSB3aGVuIHNwZWNp ZmllZCBpbnNpZGUgYSBtZWRpYSBxdWVyeS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmFsc28g dGhlIHRvdGFsIHBhZ2UgcHJpbnRpbmcgdGhpbmcgaXMgYW4gZXhlcmNpc2UgaW4gZGlzY2lwbGlu ZS4gJm5ic3A7d2UgbWF5IG5vdCBhbHdheXMgc2VydmUgYWxsIHZpZXdzIGluIHRoZSBvbmUgcGFn ZSwgYnV0IHdlIHNob3VsZCBiZSBhYmxlIHRvIGFuZCBnZXR0aW5nIGEgcHJpbnQgdmVyc2lvbiB0 aGF0IG1ha2VzIHNlbnNlIGZvciBmcmVlIGlzIGEgZ29vZCB3YXkgdG8gY2hlY2sgdXAgb24gaG93 IHdlJ3JlIGRvaW5nIHRoYXQgZXZlcnlib2R5IGNhbiBlYXNpbHkgcmV2aWV3LjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPiMgRXhp c3RpbmcgY29uZHVjdG9yIHBhcmFkaWdtczxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5UaGVzZSBj aGFuZ2VzIGRvbid0IGNyZWF0ZSBhbnkgY2hhbmdlcyB0byB0ZXJtaW5vbG9neSwgb3IgaGF2ZSBt dWNoIGltcGFjdCBmb3IgcHJlLWV4aXN0aW5nIHZpZXdzIGZvciBjb21wb25lbnRzIGFscmVhZHkg YnVpbHQgaW50byBjb25kdWN0b3IuICZuYnNwO0l0IGlzIGxpa2VseSB0aGF0IHRoZSBtYWpvcml0 eSBvZiB3aGF0IGhhcyBhbHJlYWR5IGJlZW4gZG9uZSB3aWxsIGJlIHByZXNlcnZlZCBhbmQgb25s eSB1bmRlcmdvIG1pbm9yIGNoYW5nZXMgdG8gdGhlIEhBTUwvU0FTUyBzbyB0aGF0IGZlYXR1cmVz IG1heSBiZSBpbnRlZ3JhdGVkIGludG8gdGhlIGdsb2JhbCB2aWV3Ljxicj48L2Jsb2NrcXVvdGU+ PGJyPlNvIHRoaXMgYnJpbmdzIG1lIHRvIG9uZSBwb2ludCB0aGF0IEkgZG8gd2FudCB0byBzdHJl c3MuLi4gSSB0aGluayB0aGlzPGJyPm91dGxpbmUgYW5kIHRoZSBkZW1vIHlvdSBoYXZlIGFyZSBm YW50YXN0aWMsIGFuZCBJIGhvcGUgd2UncmUgYWJsZSB0bzxicj5pbXBsZW1lbnQgaXQuIEJ1dCBh dCB0aGUgc2FtZSB0aW1lLCBJJ3ZlIGJlZW4gaGVyZSBmb3IganVzdCBvdmVyIGEgeWVhcjxicj5h bmQgaGF2ZSBhbHJlYWR5IHNlZW4gMyB3aG9sbHkgZGlmZmVyZW50IHVzZXIgaW50ZXJmYWNlcyBp bXBsZW1lbnRlZCwgdG88YnI+dGhlIHBvaW50IHRoYXQgaXQncyBhbG1vc3QgYSBydW5uaW5nIGpv a2UgdGhhdCB3ZSByaXAgb3V0IGFuZDxicj5yZWltcGxlbWVudCBvdXIgVUkgd2hlbiB0aGUgc2Vh c29ucyBjaGFuZ2UuIEkgdGhpbmsgb3VyIHNhbml0eSB3b3VsZCBiZTxicj5ncmVhdGx5IHByZXNl cnZlZCBpZiB3ZSBjb3VsZCBhcHByb2FjaCB0aGlzIGFzIGEgc2VyaWVzIG9mIGV2b2x1dGlvbmFy eTxicj5pbXByb3ZlbWVudHMsIGFzIG9wcG9zZWQgdG8gYSByZXZvbHV0aW9uYXJ5LCAicmVib290 Ii1zdHlsZTxicj5pbXBsZW1lbnRhdGlvbiBvZiBhIGZvdXJ0aCB0b3RhbGx5LW5ldyBVSS48YnI+ PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+V2VsbCwgaWYgd2Uga2VlcCBk b2luZyBpdCB3cm9uZyB3ZSdyZSBhbHdheXMgZ29pbmcgdG8gaGF2ZSB0byByZWRvIGl0Li4uIHBs YWluIGFuZCBzaW1wbGUgOy1QPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CdXQgSSBhcHByZWNp YXRlIHRoZSB0aG91Z2h0IGFuZCBpdCBpcyB0b3Agb2YgbXkgbWluZCB0byBub3Qgd2FzdGUgb3Vy IGVuZXJneS4gJm5ic3A7RnJvbSB3aGF0IEkndmUgc2VlbiwgdGhlIGhpc3RvcnkgaXMgaGFyZGx5 IGNvbnNpZGVyZWQgZnJvbSBib3RoIGFuIGltcGxlbWVudG9ycyBBTkQgZGVzaWduZXJzIHBlcnNw ZWN0aXZlIGFuZCBzb2x1dGlvbnMgYXJlbid0IHJlc29sdmluZyB3aXRoIGEgY29tcHJvbWlzZSBi dXQgcmF0aGVyIGEgY29wLW91dC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZXJlJ3MgaGVh cHMgb2Ygc2FsdmFnZWFibGUgY29kZSBhbmQgY29uY2VwdHMgZnJvbSBvdXIgZXhpc3RpbmcgVUkg dG8gZXZvbHZlIGZyb20uICZuYnNwO0kgaGFyZGx5IHRoaW5rIHRoZSBpZGVhIG9mIG1vbml0b3Jp bmcgYW5kIGFkbWluaXN0ZXJpbmcgbW9kZXMgYXJlIGdvaW5nIGF3YXkgYW5kIEkgY2FuJ3QgaW1h Z2luZSB3ZSB3aWxsIHdhbnQgdG8gZGl0Y2ggcHJldHR5IGFuZCBncmlkIHZpZXcgb3V0cmlnaHQg KHRob3VnaCBpdCB3b3VsZCBiZSBncmVhdCBpZiB3ZSBjb3VsZCBnZXQgdGhlbSBib3RoIGZvciBm cmVlKS4gJm5ic3A7Jm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgbWFqb3JpdHkg b2YgdGhlc2UgaWRlYXMgYXJlIGF0dGVtcHRpbmcgdG8gaXNvbGF0ZSBjb21wb25lbnRzIGFuZCBp bXBsZW1lbnQgdGhlbSBhcyBwYXJ0IG9mIGEgY29uc2lkZXJlZCBzZXQgc28gdGhhdCB3ZSBjYW4g Y2hhbmdlIGFuZCBldm9sdmUgYXQgYW55IHRpbWUgd2l0aG91dCB0ZWEgYmFnZ2luZyBvdXIgdXNl cnMgd29ya2Zsb3cgc2ltcGx5IGJlY2F1c2UgYSBxdWVyeSBnb3QgdG9vIGV4cGVuc2l2ZSBzbyB3 ZSBnYXZlIGl0IHNvbWUgcmFuZG9tIG5ldyB2aWV3LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ UmlnaHQgbm93IGlmIHdlIHdhbnQgdG8gbWl0aWdhdGUgdGhlIG51bWJlciBvZiBodHRwLXJlcXVl c3RzIHdlIGRvIHdlIGhhdmUgdG8gc2VyaW91c2x5IHJlLWFyY2hpdGVjdCBvdXIgaGFtbC4gJm5i c3A7YnV0IHdpdGggYSBhcHAtc2hlbGwgYXBwcm9hY2ggd2UgY2FuIGVhc2lseSBzd2l0Y2ggd2hp Y2ggYXNwZWN0cyBhcmUgZ2V0dGluZyB0b28gZXhwZW5zaXZlIGZvciB0aGUgaW5pdGlhbCBsb2Fk IGFuZCBub21pbmF0ZSB0aGV5IGJlIGFqYXhlZCB3aGVuIHJlcXVlc3RlZCBvbmx5LjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxkaXY+UmlnaHQgbm93IGlmIHdlIHdhbnQgdG8gdHdlYWsgdGhlIG1vbml0 b3JpbmcgdmlldyB0byBiZSB1c2VkIGluIHNvbWUgd2VpcmQgd2F5IGxpa2UgYSBkYXRhIGNlbnRy ZSBraW9zayBpdCB3b3VsZCByZXF1aXJlIGEgc2VyaW91cyBlZmZvcnQgYW5kIGxvdHMgb2YgY29z dC1iZW5lZml0IHNvdWwtc2VhcmNoaW5nIGJlZm9yZSB3ZSBwYWluc3RhaWtpbmdseSBjb25zdHJ1 Y3QgdGhlIHZpZXdzIG1hbnVhbGx5IHdpdGggcGxlbnR5IG9mIGR1cGxpY2F0aW9uIGFsb25nIHRo ZSB3YXkuICZuYnNwOyAmbmJzcDtpZiB3ZSBrZWVwIG91ciBjb21wb25lbnRzIGhvbW9nZW5vdXMg YW5kIHVzZSBhIGdsb2JhbCBhcHAgc2hlbGwgYXBwcm9hY2gsIGEgY29tcGxldGVseSBkaWZmZXJl bnQgZGlzcGxheSBpcyBhcyBzaW1wbGUgYXMgY2hhbmdpbmcgb25lIGNsYXNzIHdoaWNoIHNwZWNp ZmllcyB3aGF0IHRvIHNob3cvaGlkZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp dj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+VGhpcyBoYXMgYmVlbiB3cml0dGVuIHB1cmVseSB0byBzdGFydCBkaXNjdXNzaW9uIG9u IGhvdyB3ZSBldm9sdmUgQ29uZHVjdG9yIGdvaW5nIGZvcndhcmQgYW5kIEknZCBsb3ZlIHRvIGhl YXIgeW91ciB0aG91Z2h0czogWzxhIGhyZWY9Im1haWx0bzphbmR5LmZpdHpzaW1vbkByZWRoYXQu Y29tIj5hbmR5LmZpdHpzaW1vbkByZWRoYXQuY29tPC9hPiBdKDxhIGhyZWY9Im1haWx0bzphbmR5 LmZpdHpzaW1vbkByZWRoYXQuY29tIj5tYWlsdG86YW5keS5maXR6c2ltb25AcmVkaGF0LmNvbTwv YT4pPGJyPjwvYmxvY2txdW90ZT48YnI+T25lIG90aGVyIHRoaW5nIEkndmUgbm90aWNlZCBpcyB0 aGF0IGJvdGggdGhlIGN1cnJlbnQgVUkgYW5kIHlvdXIgbW9ja3VwPGJyPmFyZSBwcmV0dHkgZ3Jh eS4gSSdtIG5vdCBuZWNlc3NhcmlseSBsb2JieWluZyBmb3IgYSB0ZWNobmljb2xvciBVSSwgYnV0 PGJyPkkgZmluZCB0aGUgbW9ub2Nocm9tYXRpYyBpbnRlcmZhY2UgdG8gYmUga2luZCBvZiBibGVh ay4gSXMgaXQgcG9zc2libGU8YnI+dG8gYWRkIHNvbWUgc3BsYXNoZXMgb2YgY29sb3VyPzxicj48 L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5TbyB0aGUgdHJhZGl0aW9uIGhlcmUgKHRvIG15IHVuZGVyc3RhbmRpbmcpIGlz IHRoYXQgZXJyb3Igc3RhdGVzIG9mIG9iamVjdHMgYXJlIGFsd2F5cyBnb2luZyB0byBiZSBkaXNw bGF5ZWQgaW4gcmVkLi4gdGhpcyBpcyBtb3N0bHkgZm9yIHRoZSBtb25pdG9yaW5nIHZpZXdzIGFu ZCBzbyB0aGF0IHNlYXNvbmVkIGFkbWlucyB3aXRoIGh1Z2UgZGVwbG95bWVudHMgY2FuIGdsYW5j ZSBhdCBpc3N1ZXMgYW5kIG1ha2UgYXNzZXNzbWVudHMgd2l0aG91dCBoYXZpbmcgdG8gY29tYiB0 aHJvdWdoIG91ciBhZG1pbiBzZWN0aW9uLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+dGhpbmdz IGZ1bmN0aW9uaW5nIGZpbmUgYXJlIG5vdCBzbyBpbXBvcnRhbnQgdW5sZXNzIGl0J3MgZm9yIHRo ZSBmaXJzdCB0aW1lIHNvJm5ic3A7dW5mb3J0dW5hdGVseSBpZiB3ZSBhcmUgZ29pbmcgdG8gdXNl IHRvbmUgYW5kIGNvbG91ciBjb250cmFzdCB0byBzZXJ2ZSBhcyBhbiBpbmRpY2F0b3IsIHdlJ3Jl IGdvaW5nIHRvIGhhdmUgdG8ga2VlcCBpdCBwcmV0dHkgaG9tb2dlbm91cyBlbHNld2hlcmUuPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ob3QgdG8gc2F5IHRoYXQgd2hlbiBhIHRhc2sgaXMgYmVp bmcgZG9uZSB3ZSBjYW4ndCBicmlnaHRlbiB1cCBwZW9wbGVzIGRheSB3aXRoIGtpY2stYXNzIHN1 Y2Nlc3MgcHJvbXB0cyBhbmQgdGhlIGxpa2UuPC9kaXY+PGRpdj5UaGUgZGVmYXVsdCB2aWV3cyBo b3dldmVyIG5lZWQgdG8gY2hpbGwgb3V0IHNvIHRoYXQgdGhlIGNvbnRlbnQgY2FuIHNwZWFrIGZv ciBpdHNlbGYuICZuYnNwOyBldmVyeXRoaW5nIGVsc2UgaXMgdXAgZm9yIGdyYWJzIHNvIEkgYWdy ZWU7IGxldHMgbm90IHdhc3RlIHRoZSBvcHBvcnR1bml0eSE8L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyBhZ2FpbiBmb3IgeW91ciBm ZWVkYmFjayBNYXR0LCBpdCdzIHJlYWxseSBhcHByZWNpYXRlZC4mbmJzcDtIb3BlZnVsbHkgSSds bCBoZWFyIG1vcmUgZnJvbSBvdGhlcnMgc29vbjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2Pi0g QW5keTwvYm9keT48L2h0bWw+ --===============3779171767965523058==-- From jtomasek at redhat.com Wed Aug 19 15:23:43 2015 Content-Type: multipart/mixed; boundary="===============5540007988887171912==" 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 --===============5540007988887171912== 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 --===============5540007988887171912==-- From afitzsim at redhat.com Wed Aug 19 15:23:45 2015 Content-Type: multipart/mixed; boundary="===============5778788218656934637==" MIME-Version: 1.0 From: Andrew Fitzsimon To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Wed, 08 Feb 2012 06:47:31 -0500 Message-ID: <5A477320-8A54-437F-859D-2D4C357B17E1@redhat.com> In-Reply-To: 4F30FC53.4050103@redhat.com --===============5778788218656934637== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable >> = > = > 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 th= ing is to have a strict guide how to use certain website elements and block= s. Strictly given structure of application elements are really important to= keep application layout consistent. So we should have given library of "sm= all" elements (buttons, pagination, headers, lists, tables...) and "layout = level structures" like content sections, tab-containers... With these, abid= ing the haml structure is as important as actual styling of the elements. H= aml structure is the actual thing that everyone of us creates, so there mus= t be strictly given what is the page and elements structure through the app. So the haml of a view should be constrained to its respective parent. The = view name and the parent #ID of here it exists should be the same to make t= his easy. On the shell/chrome level the parent haml and sub views are known= . Beyond that we get a little tricky with having to check that a view appli= es to the session or has been requested. I'm still working on some demo haml to illustrate the higher up haml struct= ure of where our views fit in but if you're online I can ping you with more= specific info. I'll need help with things like how we implement global and per-user cachin= g and weighing up what things are too expensive to do by default. (hoping= to catch Scott sometime this week for a sanity check of ideas) > = > The css part is often developed by far less people ( but one person is de= finitely not enough ), its also important to have a unified style pieces to= o, which is quite easily maintained by mixins. > = As mentioned there will still be style rules allocated to functional compon= ents but I understand that we need to document this further for each contex= t. > 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). > = Yes I am aware it was possible :-). Whole page requests are very very disr= espectful of the client if they aren't absolutely needed.. Not doing this w= ith sane caching and ajaxing expensive requests might fix up a lot of our s= tuff. > Andy how would you like to strucure the css? I would like to see you opin= ion 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? > = All sass to be rendered into style.css This means all views, layout chrome and components are loaded with the init= ial hit. There is no reason why our CSS should be so expensive as to make this a pro= blem. As for the scss file layout, I imagine it would resemble something like th= is : Layout Chrome Globals (including widgets) Views-global (user views etc) Views-monitor Views-admin Views-*..... Etc Media rules And be rendered in that hierarchy down to style.css > = > 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 feature= s and elements structures through the application (haml stuff basicly) whic= h is not so easy to change during the time and can base this work on what w= e have now. Having library of haml templates of various features would grea= tly help I think. > = I totally understand. I'm putting a draft haml structure together. the layout/component/views parts are easy, right now I'm still wrangling sy= stem global changes and other small things like status notification. > I would really like to see the structural changes you propose in our app. > = Me too :-) remember, it's going to be a mock-draft but I hope it will be u= seful Thanks for your reply! --===============5778788218656934637==-- From mmorsi at redhat.com Wed Aug 19 15:23:46 2015 Content-Type: multipart/mixed; boundary="===============0719709796301792331==" MIME-Version: 1.0 From: Mo Morsi To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Wed, 08 Feb 2012 15:00:37 -0500 Message-ID: <4F32D465.1020902@redhat.com> In-Reply-To: 568C1928-6388-4779-BC17-6632CA55B9B5@redhat.com --===============0719709796301792331== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/06/2012 11:33 PM, Andy Fitzsimon wrote: > >> >> 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. +1 We need to make sure that at we invest an equal amount of time into = developing and hardening the backend, eg the restful API and the CLI = interface. Ultimately, while not graphical, the backend is an equally important = aspect of conductor as it allows the end-user to develop interfaces of = their own to meet their needs. It might make sense at some point to = extract the service layer stuff into its own subproject and build the = graphical web app separately ontop of that. > > Well, if we keep doing it wrong we're always going to have to redo = > it... plain and simple ;-P The tough aspect w/ GUIs is that there is no right or wrong way, and = different end users are going to be looking at using different graphical = interfaces / workflows. > > But I appreciate the thought and it is top of my mind to not waste our = > energy. From what I've seen, the history is hardly considered from = > both an implementors AND designers perspective and solutions aren't = > resolving with a compromise but rather a cop-out. Not sure I agree, since we started Aeolus the web dev's have been = working pretty closely w/ the designers to flush out and realize = requirements. I remember working w/ Tim and then Jeremy going back to = the original oVirt days and then on the first Deltacloud Aggregator = designs and rewrites (there have been more than 3 up to this point). > > There's heaps of salvageable code and concepts from our existing UI to = > evolve from. I hardly think the idea of monitoring and administering = > modes are going away and I can't imagine we will want to ditch pretty = > and grid view outright (though it would be great if we could get them = > both for free). This is good, but I am concerned w/ the number of issues regarding = fixing various aspects as to the UI and amount of time we already spend = on them at the end of every sprint / when doing triaging. Spending more time on and emphasising the backends while proving the = capacity for end users to aggregate services and consume them in their = own frontends would mitigate alot of this. > > The majority of these ideas are attempting to isolate components and = > implement them as part of a considered set so that we can change and = > evolve at any time without tea bagging our users workflow simply = > because a query got too expensive so we gave it some random new view. > > Right now if we want to mitigate the number of http-requests we do we = > have to seriously re-architect our haml. but with a app-shell = > approach we can easily switch which aspects are getting too expensive = > for the initial load and nominate they be ajaxed when requested only. > > Right now if we want to tweak the monitoring view to be used in some = > weird way like a data centre kiosk it would require a serious effort = > and lots of cost-benefit soul-searching before we painstaikingly = > construct the views manually with plenty of duplication along the way. = > if we keep our components homogenous and use a global app shell = > approach, a completely different display is as simple as changing one = > class which specifies what to show/hide. > Intriguing but this raises the question as to why have a unified web = interface whatsoever if things in it are going to be isolated / = modularized. Rather wouldn't it make sense to have seperate interfaces = infront of each Aeolus component (they can all be served by the same = webserver) with a shared layout / css stylesheet. That way everything = would look the same, but the administrator can enable / disable = components using the native system tooling rather than our own custom = web-shell. -Mo --===============0719709796301792331==-- From athomas at redhat.com Wed Aug 19 15:23:46 2015 Content-Type: multipart/mixed; boundary="===============2060965654051680703==" MIME-Version: 1.0 From: Angus Thomas To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Thu, 09 Feb 2012 10:24:09 +0000 Message-ID: <4F339EC9.2000703@redhat.com> In-Reply-To: 4F32D465.1020902@redhat.com --===============2060965654051680703== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/08/2012 08:00 PM, Mo Morsi wrote: > On 02/06/2012 11:33 PM, Andy Fitzsimon wrote: >> >>> >>> 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. > > +1 > > We need to make sure that at we invest an equal amount of time into = > developing and hardening the backend, eg the restful API and the CLI = > interface. > +1 The value of Andy's proposals, which is substantial, is somewhat = independent of the rate at which we're going to implement them. Before long, we're going to get out of the bug fix/stabilisation cycles = that have dominated recently, and get back to planning and implementing = new features & improvements in sprints. The backlog is, I expect, going to be pretty full because, as well as = the issues that all of the developers surely have in mind, we're about = to start getting a lot more feedback from users of the Aeolus (albeit in = a productised form). So, rather than either recoiling against, or resigning to, the idea that = we're about to re-implement the UI, I think the opportunity at this = stage is to get a shared understanding of a properly discussed set of = improvements that we can make incrementally. A couple of points which mitigate against a radical change to look and = feel, in favour of incremental improvements: - We have a lot in common with Katello, in that the functionalities of = our apps are entirely complimentary. There's some effort going into = making the two apps more visually similar, so that users can switch = between them without a jarring disconnect. In order to continue to = derive that benefit, we'll need to make major UI changes with some = amount of agreement with the Katello folks. - We're getting an increasing number of users, a lot of whom are going = to become attached to our current UI (How could they not? ;-)) and, even = the ones who aren't fond of it will become familiar with it. The need to = carry that community with us in the design changes we make in future = shouldn't be a blocker, but it should make us proceed with caution. > Ultimately, while not graphical, the backend is an equally important = > aspect of conductor as it allows the end-user to develop interfaces of = > their own to meet their needs. It might make sense at some point to = > extract the service layer stuff into its own subproject and build the = > graphical web app separately ontop of that. > > You're entirely right about the need for the API and CLI tools. I've = enthused before about how cool spacecmd* is before. We should aim to = have something similar. However, I'm wary of the idea that we can separate out the building of = the web UI somehow. As long as the capabilities of Conductor, = deltacloud, imagefactory etc. are continuing to evolve at the current = rate, there just isn't enough predictability for UI design to be able to = succeed as a relatively isolated effort. Instead, we need ongoing discussion of the UI's requirements and = capabilities to be tied into the overall development. This thread is a = very good example of the kind of open discussion and review that I think = will serve us well. * http://www.ohloh.net/p/spacecmd - To be clear, I don't only mean cool = as in an impressive app to have put together, though it is, I also mean = massively useful. Wrangling many hundreds of instances in RHN is made a = tonne easier by the ability to write wrapper scripts around spacecmd. > > > >> >> Well, if we keep doing it wrong we're always going to have to redo = >> it... plain and simple ;-P > > The tough aspect w/ GUIs is that there is no right or wrong way, and = > different end users are going to be looking at using different = > graphical interfaces / workflows. > > > >> >> But I appreciate the thought and it is top of my mind to not waste = >> our energy. From what I've seen, the history is hardly considered = >> from both an implementors AND designers perspective and solutions = >> aren't resolving with a compromise but rather a cop-out. > > Not sure I agree, since we started Aeolus the web dev's have been = > working pretty closely w/ the designers to flush out and realize = > requirements. I remember working w/ Tim and then Jeremy going back to = > the original oVirt days and then on the first Deltacloud Aggregator = > designs and rewrites (there have been more than 3 up to this point). > > > > >> >> There's heaps of salvageable code and concepts from our existing UI = >> to evolve from. I hardly think the idea of monitoring and = >> administering modes are going away and I can't imagine we will want = >> to ditch pretty and grid view outright (though it would be great if = >> we could get them both for free). > > This is good, but I am concerned w/ the number of issues regarding = > fixing various aspects as to the UI and amount of time we already = > spend on them at the end of every sprint / when doing triaging. > > Spending more time on and emphasising the backends while proving the = > capacity for end users to aggregate services and consume them in their = > own frontends would mitigate alot of this. > > > >> >> The majority of these ideas are attempting to isolate components and = >> implement them as part of a considered set so that we can change and = >> evolve at any time without tea bagging our users workflow simply = >> because a query got too expensive so we gave it some random new view. >> >> Right now if we want to mitigate the number of http-requests we do we = >> have to seriously re-architect our haml. but with a app-shell = >> approach we can easily switch which aspects are getting too expensive = >> for the initial load and nominate they be ajaxed when requested only. >> >> Right now if we want to tweak the monitoring view to be used in some = >> weird way like a data centre kiosk it would require a serious effort = >> and lots of cost-benefit soul-searching before we painstaikingly = >> construct the views manually with plenty of duplication along the = >> way. if we keep our components homogenous and use a global app = >> shell approach, a completely different display is as simple as = >> changing one class which specifies what to show/hide. >> > > Intriguing but this raises the question as to why have a unified web = > interface whatsoever if things in it are going to be isolated / = > modularized. Rather wouldn't it make sense to have seperate interfaces = > infront of each Aeolus component (they can all be served by the same = > webserver) with a shared layout / css stylesheet. That way everything = > would look the same, but the administrator can enable / disable = > components using the native system tooling rather than our own custom = > web-shell. > > -Mo > > --===============2060965654051680703==-- From whayutin at redhat.com Wed Aug 19 15:23:47 2015 Content-Type: multipart/mixed; boundary="===============8877248474880179862==" MIME-Version: 1.0 From: wes hayutin To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Thu, 09 Feb 2012 10:21:34 -0500 Message-ID: <1328800896.17663.10.camel@minidoe> In-Reply-To: 4F339EC9.2000703@redhat.com --===============8877248474880179862== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, 2012-02-09 at 10:24 +0000, Angus Thomas wrote: > On 02/08/2012 08:00 PM, Mo Morsi wrote: > > On 02/06/2012 11:33 PM, Andy Fitzsimon wrote: > >> > >>> > >>> So this brings me to one point that I do want to stress... I think th= is > >>> 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 ye= ar > >>> 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 evolutiona= ry > >>> improvements, as opposed to a revolutionary, "reboot"-style > >>> implementation of a fourth totally-new UI. > > > > +1 > > > > We need to make sure that at we invest an equal amount of time into = > > developing and hardening the backend, eg the restful API and the CLI = > > interface. > > > = > +1 > = > The value of Andy's proposals, which is substantial, is somewhat = > independent of the rate at which we're going to implement them. > = > Before long, we're going to get out of the bug fix/stabilisation cycles = > that have dominated recently, and get back to planning and implementing = > new features & improvements in sprints. > = > The backlog is, I expect, going to be pretty full because, as well as = > the issues that all of the developers surely have in mind, we're about = > to start getting a lot more feedback from users of the Aeolus (albeit in = > a productised form). > = > So, rather than either recoiling against, or resigning to, the idea that = > we're about to re-implement the UI, I think the opportunity at this = > stage is to get a shared understanding of a properly discussed set of = > improvements that we can make incrementally. > = > = > A couple of points which mitigate against a radical change to look and = > feel, in favour of incremental improvements: > = > - We have a lot in common with Katello, in that the functionalities of = > our apps are entirely complimentary. There's some effort going into = > making the two apps more visually similar, so that users can switch = > between them without a jarring disconnect. In order to continue to = > derive that benefit, we'll need to make major UI changes with some = > amount of agreement with the Katello folks. > = > - We're getting an increasing number of users, a lot of whom are going = > to become attached to our current UI (How could they not? ;-)) and, even = > the ones who aren't fond of it will become familiar with it. The need to = > carry that community with us in the design changes we make in future = > shouldn't be a blocker, but it should make us proceed with caution. > = > > Ultimately, while not graphical, the backend is an equally important = > > aspect of conductor as it allows the end-user to develop interfaces of = > > their own to meet their needs. It might make sense at some point to = > > extract the service layer stuff into its own subproject and build the = > > graphical web app separately ontop of that. > > > > > = > You're entirely right about the need for the API and CLI tools. I've = > enthused before about how cool spacecmd* is before. We should aim to = > have something similar. > = > However, I'm wary of the idea that we can separate out the building of = > the web UI somehow. As long as the capabilities of Conductor, = > deltacloud, imagefactory etc. are continuing to evolve at the current = > rate, there just isn't enough predictability for UI design to be able to = > succeed as a relatively isolated effort. > = > Instead, we need ongoing discussion of the UI's requirements and = > capabilities to be tied into the overall development. This thread is a = > very good example of the kind of open discussion and review that I think = > will serve us well. > = > = > * http://www.ohloh.net/p/spacecmd - To be clear, I don't only mean cool = > as in an impressive app to have put together, though it is, I also mean = > massively useful. Wrangling many hundreds of instances in RHN is made a = > tonne easier by the ability to write wrapper scripts around spacecmd. my 2cents.. revolutionary changes in the UI dramatically affect QE's test coverage. spacecmd is a great tool... also one that is very difficult to automate tests for. I worked on satellite and RHUI which both use spacecmd, having cmdline parity for scripting is essential when implementing a spacecmd like interface. > = > > > > > > > >> > >> Well, if we keep doing it wrong we're always going to have to redo = > >> it... plain and simple ;-P > > > > The tough aspect w/ GUIs is that there is no right or wrong way, and = > > different end users are going to be looking at using different = > > graphical interfaces / workflows. > > > > > > > >> > >> But I appreciate the thought and it is top of my mind to not waste = > >> our energy. From what I've seen, the history is hardly considered = > >> from both an implementors AND designers perspective and solutions = > >> aren't resolving with a compromise but rather a cop-out. > > > > Not sure I agree, since we started Aeolus the web dev's have been = > > working pretty closely w/ the designers to flush out and realize = > > requirements. I remember working w/ Tim and then Jeremy going back to = > > the original oVirt days and then on the first Deltacloud Aggregator = > > designs and rewrites (there have been more than 3 up to this point). > > > > > > > > > >> > >> There's heaps of salvageable code and concepts from our existing UI = > >> to evolve from. I hardly think the idea of monitoring and = > >> administering modes are going away and I can't imagine we will want = > >> to ditch pretty and grid view outright (though it would be great if = > >> we could get them both for free). > > > > This is good, but I am concerned w/ the number of issues regarding = > > fixing various aspects as to the UI and amount of time we already = > > spend on them at the end of every sprint / when doing triaging. > > > > Spending more time on and emphasising the backends while proving the = > > capacity for end users to aggregate services and consume them in their = > > own frontends would mitigate alot of this. > > > > > > > >> > >> The majority of these ideas are attempting to isolate components and = > >> implement them as part of a considered set so that we can change and = > >> evolve at any time without tea bagging our users workflow simply = > >> because a query got too expensive so we gave it some random new view. > >> > >> Right now if we want to mitigate the number of http-requests we do we = > >> have to seriously re-architect our haml. but with a app-shell = > >> approach we can easily switch which aspects are getting too expensive = > >> for the initial load and nominate they be ajaxed when requested only. > >> > >> Right now if we want to tweak the monitoring view to be used in some = > >> weird way like a data centre kiosk it would require a serious effort = > >> and lots of cost-benefit soul-searching before we painstaikingly = > >> construct the views manually with plenty of duplication along the = > >> way. if we keep our components homogenous and use a global app = > >> shell approach, a completely different display is as simple as = > >> changing one class which specifies what to show/hide. > >> > > > > Intriguing but this raises the question as to why have a unified web = > > interface whatsoever if things in it are going to be isolated / = > > modularized. Rather wouldn't it make sense to have seperate interfaces = > > infront of each Aeolus component (they can all be served by the same = > > webserver) with a shared layout / css stylesheet. That way everything = > > would look the same, but the administrator can enable / disable = > > components using the native system tooling rather than our own custom = > > web-shell. > > > > -Mo > > > > > = --===============8877248474880179862==-- From bkearney at redhat.com Wed Aug 19 15:23:47 2015 Content-Type: multipart/mixed; boundary="===============5773173686364621791==" MIME-Version: 1.0 From: Bryan Kearney To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Thu, 09 Feb 2012 10:23:33 -0500 Message-ID: <4F33E4F5.7050901@redhat.com> In-Reply-To: 1328800896.17663.10.camel@minidoe --===============5773173686364621791== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 02/09/2012 10:21 AM, wes hayutin wrote: > On Thu, 2012-02-09 at 10:24 +0000, Angus Thomas wrote: >> On 02/08/2012 08:00 PM, Mo Morsi wrote: >>> On 02/06/2012 11:33 PM, Andy Fitzsimon wrote: >>>> >>>>> >>>>> So this brings me to one point that I do want to stress... I think th= is >>>>> 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 ye= ar >>>>> 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 evolutiona= ry >>>>> improvements, as opposed to a revolutionary, "reboot"-style >>>>> implementation of a fourth totally-new UI. >>> >>> +1 >>> >>> We need to make sure that at we invest an equal amount of time into >>> developing and hardening the backend, eg the restful API and the CLI >>> interface. >>> >> >> +1 >> >> The value of Andy's proposals, which is substantial, is somewhat >> independent of the rate at which we're going to implement them. >> >> Before long, we're going to get out of the bug fix/stabilisation cycles >> that have dominated recently, and get back to planning and implementing >> new features& improvements in sprints. >> >> The backlog is, I expect, going to be pretty full because, as well as >> the issues that all of the developers surely have in mind, we're about >> to start getting a lot more feedback from users of the Aeolus (albeit in >> a productised form). >> >> So, rather than either recoiling against, or resigning to, the idea that >> we're about to re-implement the UI, I think the opportunity at this >> stage is to get a shared understanding of a properly discussed set of >> improvements that we can make incrementally. >> >> >> A couple of points which mitigate against a radical change to look and >> feel, in favour of incremental improvements: >> >> - We have a lot in common with Katello, in that the functionalities of >> our apps are entirely complimentary. There's some effort going into >> making the two apps more visually similar, so that users can switch >> between them without a jarring disconnect. In order to continue to >> derive that benefit, we'll need to make major UI changes with some >> amount of agreement with the Katello folks. >> >> - We're getting an increasing number of users, a lot of whom are going >> to become attached to our current UI (How could they not? ;-)) and, even >> the ones who aren't fond of it will become familiar with it. The need to >> carry that community with us in the design changes we make in future >> shouldn't be a blocker, but it should make us proceed with caution. >> >>> Ultimately, while not graphical, the backend is an equally important >>> aspect of conductor as it allows the end-user to develop interfaces of >>> their own to meet their needs. It might make sense at some point to >>> extract the service layer stuff into its own subproject and build the >>> graphical web app separately ontop of that. >>> >>> >> >> You're entirely right about the need for the API and CLI tools. I've >> enthused before about how cool spacecmd* is before. We should aim to >> have something similar. >> >> However, I'm wary of the idea that we can separate out the building of >> the web UI somehow. As long as the capabilities of Conductor, >> deltacloud, imagefactory etc. are continuing to evolve at the current >> rate, there just isn't enough predictability for UI design to be able to >> succeed as a relatively isolated effort. >> >> Instead, we need ongoing discussion of the UI's requirements and >> capabilities to be tied into the overall development. This thread is a >> very good example of the kind of open discussion and review that I think >> will serve us well. >> >> >> * http://www.ohloh.net/p/spacecmd - To be clear, I don't only mean cool >> as in an impressive app to have put together, though it is, I also mean >> massively useful. Wrangling many hundreds of instances in RHN is made a >> tonne easier by the ability to write wrapper scripts around spacecmd. > > my 2cents.. revolutionary changes in the UI dramatically affect QE's > test coverage. > > spacecmd is a great tool... also one that is very difficult to automate > tests for. I worked on satellite and RHUI which both use spacecmd, > having cmdline parity for scripting is essential when implementing a > spacecmd like interface. > why is it hard to test? is it because there is no straight command line? -- bk --===============5773173686364621791==-- From whayutin at redhat.com Wed Aug 19 15:23:47 2015 Content-Type: multipart/mixed; boundary="===============2215425679136514861==" MIME-Version: 1.0 From: wes hayutin To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Thu, 09 Feb 2012 10:46:32 -0500 Message-ID: <1328802393.17663.13.camel@minidoe> In-Reply-To: 4F33E4F5.7050901@redhat.com --===============2215425679136514861== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Thu, 2012-02-09 at 10:23 -0500, Bryan Kearney wrote: > On 02/09/2012 10:21 AM, wes hayutin wrote: > > On Thu, 2012-02-09 at 10:24 +0000, Angus Thomas wrote: > >> On 02/08/2012 08:00 PM, Mo Morsi wrote: > >>> On 02/06/2012 11:33 PM, Andy Fitzsimon wrote: > >>>> > >>>>> > >>>>> 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 woul= d be > >>>>> greatly preserved if we could approach this as a series of evolutio= nary > >>>>> improvements, as opposed to a revolutionary, "reboot"-style > >>>>> implementation of a fourth totally-new UI. > >>> > >>> +1 > >>> > >>> We need to make sure that at we invest an equal amount of time into > >>> developing and hardening the backend, eg the restful API and the CLI > >>> interface. > >>> > >> > >> +1 > >> > >> The value of Andy's proposals, which is substantial, is somewhat > >> independent of the rate at which we're going to implement them. > >> > >> Before long, we're going to get out of the bug fix/stabilisation cycles > >> that have dominated recently, and get back to planning and implementing > >> new features& improvements in sprints. > >> > >> The backlog is, I expect, going to be pretty full because, as well as > >> the issues that all of the developers surely have in mind, we're about > >> to start getting a lot more feedback from users of the Aeolus (albeit = in > >> a productised form). > >> > >> So, rather than either recoiling against, or resigning to, the idea th= at > >> we're about to re-implement the UI, I think the opportunity at this > >> stage is to get a shared understanding of a properly discussed set of > >> improvements that we can make incrementally. > >> > >> > >> A couple of points which mitigate against a radical change to look and > >> feel, in favour of incremental improvements: > >> > >> - We have a lot in common with Katello, in that the functionalities of > >> our apps are entirely complimentary. There's some effort going into > >> making the two apps more visually similar, so that users can switch > >> between them without a jarring disconnect. In order to continue to > >> derive that benefit, we'll need to make major UI changes with some > >> amount of agreement with the Katello folks. > >> > >> - We're getting an increasing number of users, a lot of whom are going > >> to become attached to our current UI (How could they not? ;-)) and, ev= en > >> the ones who aren't fond of it will become familiar with it. The need = to > >> carry that community with us in the design changes we make in future > >> shouldn't be a blocker, but it should make us proceed with caution. > >> > >>> Ultimately, while not graphical, the backend is an equally important > >>> aspect of conductor as it allows the end-user to develop interfaces of > >>> their own to meet their needs. It might make sense at some point to > >>> extract the service layer stuff into its own subproject and build the > >>> graphical web app separately ontop of that. > >>> > >>> > >> > >> You're entirely right about the need for the API and CLI tools. I've > >> enthused before about how cool spacecmd* is before. We should aim to > >> have something similar. > >> > >> However, I'm wary of the idea that we can separate out the building of > >> the web UI somehow. As long as the capabilities of Conductor, > >> deltacloud, imagefactory etc. are continuing to evolve at the current > >> rate, there just isn't enough predictability for UI design to be able = to > >> succeed as a relatively isolated effort. > >> > >> Instead, we need ongoing discussion of the UI's requirements and > >> capabilities to be tied into the overall development. This thread is a > >> very good example of the kind of open discussion and review that I thi= nk > >> will serve us well. > >> > >> > >> * http://www.ohloh.net/p/spacecmd - To be clear, I don't only mean cool > >> as in an impressive app to have put together, though it is, I also mean > >> massively useful. Wrangling many hundreds of instances in RHN is made= a > >> tonne easier by the ability to write wrapper scripts around spacecmd. > > > > my 2cents.. revolutionary changes in the UI dramatically affect QE's > > test coverage. > > > > spacecmd is a great tool... also one that is very difficult to automate > > tests for. I worked on satellite and RHUI which both use spacecmd, > > having cmdline parity for scripting is essential when implementing a > > spacecmd like interface. > > > = > = > why is it hard to test? is it because there is no straight command line? Its difficult to script automation tests... At the time I was looking at it only the "expect" tool was a possible option. Using expect really blows. Having parity w/ standard cli commands makes a spacecmd like interface more digestible to QE, and sysadmins probably. > = > -- bk --===============2215425679136514861==-- From jprovazn at redhat.com Wed Aug 19 15:24:33 2015 Content-Type: multipart/mixed; boundary="===============3634550830904552169==" MIME-Version: 1.0 From: =?utf-8?q?Jan_Provazn=C3=ADk_=3Cjprovazn_at_redhat=2Ecom=3E?= To: aeolus-devel at lists.fedorahosted.org Subject: Re: Conductor UI - some ideas for a better conductor Date: Thu, 01 Mar 2012 12:07:51 +0100 Message-ID: <4F4F5887.8090509@redhat.com> In-Reply-To: 2B4CAECF-6B24-4F5D-8CD0-4B164EE44B01@redhat.com --===============3634550830904552169== 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, > Hi Andy, overall it looks great. > ## 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 -1 Taking the risk I'll be stoned to death. It sounds great when written on = goals-list and 2 years ago I would happily agree with this. But in = practice this turned out to be very painful on this project. Though I'll = probably change my mind if I'll see that new "single-page-app" approach = could work ;). I think any user with JS turned off (<2%) will use our API/CLI instead = of UI anyway. > * Screen readers (section 508, we=E2=80=99re going there) > > ****** > ****** > > ## 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, > Somehow I can't imagine how this could work in Conductor. From text = bellow and from demo (http://file.bne.redhat.com/~afitzsim/static/) the = plan is to load whole Conductor (or some part) in one request, JS is = used only for hiding inactive parts. I suppose you don't mean whole Conductor (including all views), but only = some logical subsection, right? But even inside a subsection are usually = many pages which can't be preloaded - all object show pages, edit pages, = index pages for nested resources... In your demo page I see, that you have separate edit form + anchor for = for each provider, then you have list of accounts for each provider,... It will take ages to load all this content in single page. > 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 > Jan --===============3634550830904552169==--