Conductor UI - some ideas for a better conductor

Jan Provaznik jprovazn at redhat.com
Thu Mar 1 11:07:51 UTC 2012


On 01/30/2012 06:51 AM, Andy Fitzsimon wrote:
> Hi all,
>

Hi Andy,
overall it looks great.

<snip>
> ## 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’re going there)
>
> ******

<snip>

> ******
>
> ## View anchors - or 'single page app'
>
> View anchors are portions of our design implemented within the one DOM using 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 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>  connectivity view.
>
>      https://conductor/#ec2eastcoast-connectivity
>                 ^            ^              ^
>              Server     ObjectID       ChildView
>
>
> #### What the html does
> e.g. the `<div>` representing admin>  providers>  ec2eastcoast would look like
>
>      <div id="ec2eastcoast">.. ec2 east coast information goes here
>
>
> and the connectivity tab which exists inside the ec2eastcoast provider would look like
>
>      <div id="ec2eastcoast-connectivity">
>                   ^             ^
>               objectID       ChildViewname
>
> Why?
> Because the provider _ec2eastcoast_ lives natively within the _admin>  provider_ 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 the provider it is associated with, it needs to be prefixed with the objectID
>
>
> All direct links to the provider view would look like `<a href=#ec2eastcoast>EC2 East Coast</a>  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-hashchange-plugin/)  to preserve browsing history
>


Jan



More information about the aeolus-devel mailing list