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 anything nice…" 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 can 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 result 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 having 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 quite 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 environments; we'll pass any audit by default.


### 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 requests (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 represent 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 behaviour 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 series 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 icons 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 can use modernizr rules like    .ie8 .webfont .icon, .icon{…image stuff here… }   /   .webfont{…font rule here.}

its also important to note that superfluous graphics are a very very bad thing. they create lots of noise and confusion; put too many graphics together 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 using 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 has access to and serve them up as empty <divs> or <section>'s 

after that, we can selectively lazy load the expensive view content once the view is requested via the anchor; but getting to the view initially should 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 forgetting 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 when js is active)  we know the no-js version is active and to serve them the 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 IE)

If target exists,  we can keep the views in tabs with a small concession being that the active tab is no longer rendered  in an active state (but still works )  here's a dumb demo of tabs with no JS http://jsfiddle.net/andyfitz/QwAwK/  (There are other methods we can use that preserve the functionality 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 accommodations
 - 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 the viewport 
 - a save button (otherwise hidden by JS) will be fixed at the bottom of the 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://jqueryfordesigners.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 ways 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 to 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 client 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 there 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 confirmation.


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 different css is on the cards

we can apply custom styling to any components we reference inside the notification.  e.g. progress bars can look black and white, buttons can appear simpler.  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 query begins at the end of the stylesheet  but i always put them in for safe measure as they can't hurt any other display type when specified inside a media query.

also the total page printing thing is an exercise in discipline.  we may not always serve all views in the one page, but we should be able to and getting 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 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 and only undergo minor changes to the HAML/SASS so that features may be integrated 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... plain and simple ;-P

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.

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).   

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.




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@redhat.com ](mailto:andy.fitzsimon@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 monitoring views and so that seasoned admins with huge deployments can glance at issues 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 for 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'll hear more from others soon

- Andy