Re: validator results page - don't break web with fancy features - show information with more clicks

Olivier,

olivier Thereaux wrote:
...
 > On Mar 2, 2007, at 02:29 , Daniel Barclay wrote:
 >> The CSS validator's results page's use of fancy features breaks the
 >> way the web normally works.
 >
 > This sounds a little exaggerated to me. The way I see it:
 > ...
 > * Validation results include errors if any, and warnings. The warnings
 > have caused some unease, and we tried having them take less space
 > through a mix of scripting and style

(See below for another possible solution to that problem.)


 > * the mechanism used is not breaking anything.

What it breaks is the ability of the user to have a URI that gets a
result page that already displays the information the user requested.

Before the change, the user could validate some page, e-mail the
result URI to someone and say "look at all these warnings," and know
that the recipient would see the (freshly regenerated) warnings.

After the change, the user can't do that.  The user has to add "and
then click on the Warnings heading."

(Compare that to the difference between identifying a web page by
1) giving someone the URI of the home page of some web site, telling
him to (find and) click on the Xyz link, click on the Abc link, and
then click on the Pdq link,  versus 2) simply giving the URI of the
intended page.)


At a higher level, what seems to have been broken or not followed
is the principle of having each resource identified by a URI (as
recommended by _Architecture of the World Wide Web, Volume One_
at http://www.w3.org/TR/webarch/#uri-benefits).

Before the change, there was a URI for a page that displayed the
warnings (well, technically, for the resource that generates the
page) as well as a separate URI for a page that did not display
warnings.

After the change, there is only one URI for both of those views.

(Yes, one could say that the current page, which contains the
warning, doesn't display them initially and can display them with
a click, is a resource, and that that resource has a URI, so there
is no problem.

However, pretty clearly, having two separately addressable
resources is better.  (You can choose which view to get by choosing
the URI once and then repeatedly go to that view without any further
choosing.  With the change, you have to do something extra (click on
the Warnings link) _each_time_ you want to go to that view.)


Another way to look at it is that the change has made the validator
more application-like instead of being web-like.

After the change, it is application-like in that even after going
to a saved URI the user has to go through some application-specified
set of steps (clicking on the Warnings link) every time to get back to
a given view (the view with the warnings displayed).

Before the change, it was web-like in that the user could get back
_directly_ to the wanted view via a URI (using whatever mechanism
the user wanted to use: bookmarking, memory, e-mail, link, etc.).)



 >> If the pages of the W3C don't reflect the philosophy of paying
 >> attention to good design (or do reflect faddish or ill-considered
 >> use of powerful features), we can't count on the W3C for guidance
 >> any more.
 >
 > This is a bit over-dramatic, isn't it?

Maybe it's overly dramatic, but I don't think the point is invalid.

When I see a web page that does something it shouldn't (e.g., reducing
the font size relative to the user's choice, or being of a fixed width
and not adjusing to fit the user's chosen browser window width), I
can usually point to a W3C page that does things "right" as an example
of what should be done.

Note that some guidance is implicit.  If the W3C's page do bad
things, it's hard to argue that such things are bad.  (Someone could
say, well, the W3C does it on their pages, and they're the experts
(they think about web architecture and how to make the web work),
so what's wrong with doing that on my page?)



 > Let's try and look at it
 > constructively:
 >
 > * The changes have been made to satisfy a demand from the user community
 > to have smaller, more easily usable results page, and with warnings
 > taking less space. Do you have any suggestion of a change that would
 > still satisfy this demand, but please you more?

Why not have the default settings generate a page without warnings,
and (assuming you still want the page generated with default settings
to have easy access to the warnings), make the warnings heading/link
be a (regular) link to a page with the warnings?


Hey, this might be better:

To the current design, when the warnings are displayed, add a link with
a URI that returns a page with the warnings already displayed.

That is, when the user clicks on the Warnings link to display the
warnings that are already contained in the returned HTML, also display
a link with a URI that will retrieve the page with the warnings
displayed (not hidden).

That way:
- You could still avoid cluttering the default page with the displayed
   warnings.
- You could still provide access to the warnings without re-running
   the validator and the request/response delay.
- Someone who wanted a URI to save to be able to get to a page with
   the warnings already displayed could get that (and could re-validate
   and see the warnings without also having to click on the Warnings
   link every time).



 > ... At this point I've been
 > experimenting with a slightly adapted look and feel for the Markup
 > Validator:
 > http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fwww.apple.com%2F;ss;st
 >
 > Would this also work for the CSS validator? Would it be better than what
 > we have at present?

I'm not sure which aspect of it you're asking about.



However, I do notice two problems:

1.  Something in the page structure prevents the browser from wrapping
     the wrappable text (the error message text, e.g., "You have used
     the attribute named above...") to fit the browser window.  The
     page requires the user to scroll horizontally more that the user
     should have to do so.

     (Yes, of course, the pre-formatted text can't be wrapped, might
     not fit, and therefor might require horizontal scrolling.  However,
     the regular (non-preformatted) text should wrap to fit and not
     require additional horizontal scrolling.)

     The error text acts as if it is enclosed in table cells in a
     column that also contains something with a fixed width (or a fixed
     minimum width).  (The item with a fixed width forces the column to
     at least that width, and then the wrappable text, being enclosed
     in that column, is wrapped to the column's width instead of being
     wrapped to the width of the browser window.

     (Yes, it's true that the page and text column don't simply have a
     fixed width; the wrappable text does wrap to different widths as
     you widen and narrow the browser window.  However, as you narrow
     the window, the wrappable text column stops getting narrower long
     before it should stop).

2.  The Cleaned-Up Source section has a serious usability problem
     because it tries to do scrolling internally:

     To scroll right horizontally to see the part of the cleaned-up
     source text that isn't visible initially, the user has to:
     - first, scroll the browser window vertically to get all the way
       down to the bottom of the internal scrolling region to get to
       that scrolling region's horizontal scrollbar,
     - scroll the internal scrolling horizontally,
     - and then scroll the browser window vertically all the way back
       to the line whose part wasn't visible before.


     Consider the example instantiation you gave (checking the Apple
     page).  Imagine trying to read a long line near the top of the
     Cleaned-Up Source box, for example the pics-label line (about
     line 8).

     (If you happen to use a very wide browser window (and/or very
     small fonts), temporarily adjust your browser so that line
     doesn't fit and you need to scroll horizontally.)

     How try scrolling the text horizontally (moving it to the left)
     so you can see the text that is to the right of what you see
     initially.

     First, you have to scroll down 5 or 10 windows' worth (well,
     pane's worth) (depending on your window height and font size, of
     course).

     Then you can click on or drag in the scrolling region's
     scrollbar to scroll its contents horizontally.  However, you
     can't see the pics-label line whose right-most part you're trying
     to make visible.  (You can't tell if you scrolled far enough or
     too far.)

     Finally, you have to scroll back up the same amount as before
     (either counting or estimating the same distance, or scanning for
     the line you're looking for--which is hard since now you'll be
     seeing a different part of the line that you saw before).

     That's horrible!  Yes, "horrible" might seem too strong, but
     how is that not an extremely bad (inefficient, user-unfriendly)
     design and result?


     Consider how simple (and normal) it would be if the page author
     had not tried to use the fancy feature of using internal
     scrolling:

     The user would simply scroll the browser window horizontally
     using the browser's horizontal scrollbar--which stays visible
     and stays in the same place regardless of the vertical scrolling
     position of the page.


     The currently design is the kind of bad example the that W3C
     should _not_ be setting.  Surely you would agree with that, or
     at least some significant part of that.




Daniel

Received on Thursday, 8 March 2007 19:59:28 UTC