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(a)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