Re: Transition (was Re: Capitalize across "span")

At 02:49 PM 2/10/98 -0800, you wrote:
>John Udall wrote:
>
>>	From practically the beginning, some people just didn't get it.  They
>>tried to force HTML to make a document "look" just right.  And it didn't
[-snip-]
>Not to rehash the past, but rather than blaming users, I think the
>widespread use of tables for layout (and I will be the first the admit that
>they're a kludgy workaround that causes me no end of grief) shows that the
>spec was insufficient for the needs of users. Presentation *can be* an
>important aid to comprehension, as shown by numerous studies that are cited
>in Karen Shriver's "Dynamics of Document Design."
>
	Agreed.  The early versions of the spec were insufficient.  It left too
much display control up to the browser.  And the people who wrote the
browsers didn't know enough about design to "get it right".  Anyway, as you
say, there's no point rehashing the past.  I had only brought it up to
provide context for how we got to where we are today. 

[-snip-]
>One reason the populace rebeled is that earlier HTML and browsers forced us
>to abandon "user interface" techniques for content that have been developed
>and beta tested over the past five centures (arguably I could go back
[-snip-]
>Yes, the Web is *not* print, and I do believe pages should be scalable to
>multiple browsers, monitors and platforms. However, print has had a long
>time to experiment and develop principles for how to present content
>effectively. For example, the guideline that leading needs to be increased

	In this sense we really are in the dark-ages of electronic publishing.  We
don't know a lot about how people interact with electronic documents.  We
also don't know alot about how electronic documents should be integrated
with each other, for example hyperlinking, document embedding (a la OLE or
OpenDoc), or even document reuse within other applications.
  
	People have a lot of ideas.  Their expectations are very high.  But it
takes time to build stuff.  Just because it happens to involve a computer
doesn't mean that the results are instantaneous. If people don't get what
they want or expect, they are disappointed. Creating content takes time.
Designing the content takes time.  Creating applications to support these
processes does too. Cutting down on the hype and getting down to the
business of building stuff can go a long way towards meeting people's
expectations.

[-snip-]
>(since HTML was like the DTP revolution all over again), those of us who
>did were found HTML to be painful to work with.
>
	Spot on! When the desktop publishing (DTP) fad came out, everybody thought
they could publish a newsletter from home.  Some people succeeded. Others
discovered that they didn't have the design or editorial skills necessary
to do a successful job, even if they did have the content expertise and
good writing skills.  The tools were poor initially. They were good enough
for simple uses, but not good enough for the professionals.  HTML was that
all over again. Everyone wants a home page, because it's cool.  It seems to
be smoothing itself out though now, at least somewhat.  The coolness factor
is wearing off, and people are becoming aware of the challenges.  The ones
who are being truly successful are using the web to integrate with existing
business practices or to create new opportunities and efficiencies.
Content is still king.  Content that looks good and is easy to use is even
better!

>>A good XML markup tool will provide
>>affordances for capturing the structure of a document.  Basic style sheets
>>for common output devices, coupled with a good tool for customizing them
>>will give people the control that they want over the look of the final
>>product without alientating particular user populations.
>
>I feel like we're now at the point where we really starting to get all
>three legs of the tripod -- HTML for basic structural elements, CSS for
>presentation and XML to handle the data about the content, which could
>include the structural data if needed. Once we reach the point where these
>are widely supported, I'm willing to hang up my mask and live within the

	I think that this is what a lot of us are waiting for. As they used to
say, "Prosperity is just around the corner.  I'm just trying to figure out
which corner." :-)

>law. The biggest problem I have now if supporting legacy documents and that
>means mixing in layout tables for the moment.
>
	Support for these mogrel legacy documents is the hardest part.  If people
conformed to the standard and didn't force the look too much with little
tricks, at least there is a chance to automate a migration to the new
technologies, like XML.  Otherwise, we're all up for a major task of
managing legacy documents, as well as support for legacy browsers.

[-snip-]
>
>>	I don't think that the move to a "pure" separation between document
>>structure and display is impossible.
>
>I'm a bit more dubious. In my experience, presenting content most
>effectively often entails intertwining
>structure and display.  For example, take the widely-used two-column layout

	I'm sorry, I guess I wasn't too clear here.  I just think that the display
and structure of a document can be separated from each other, but they
should be kept together in the sense of encapsulating them both within a
single object which is really the document itself.  You may have multiple
displays for a single document, for different output devices.  You might
also have different "versions" of the content, for example one which shows
annotations or a history of the document content, or an abridged version.
All would draw from the same content materials.  All would be encompassed
within the same object which is the document. I don't want to argue that
the content and the display should be completely and totally separated from
each other.  You can get some really ugly documents when you do that.
There are plenty of failed user interface design projects to show that.
Good design and appropriate display enhances document content.

[-snip-]
>>The
>>people who will be hard to bring around are those who don't even know what
>>the standard is, and they don't subscribe to www-style.
>
>Again I think one of the keys is making sure that standards meet the needs
>of those using them, which makes it a lot easier to convince people to live
>within the standards. I'd agree everyone is trying to be helpful here, I
>just think the academic/programming backgrounds of many of those here have
>sometimes left blindspots to important issues of how HTML/CSS/XML etc. will
>likely be used by those outside the  academic/programming circles.
>
	Yep.  Principle number 1 of user interface design and software design is
to know your users.  If you haven't tried to actually use the stuff, to
apply the proposed standards in a real-world situation, then you almost
certainly don't have a good grasp on what the full requirements are.
That's what these lists are for, to solicit feedback from the people who
are really using the stuff.  It's part of the reason the standards process
takes so long.  And it's a good thing, too.

-John

>
>
>George Olsen
>Web Architect/Designer
>mailto:golsen@2lm.com
>2-Lane Media
>http://www.2lm.com
>vox 310/473-3706 x2225                                         fax
310/473-6736
>
>
>
>

Standard Disclamer -- The opinions expessed here are my own. They do not
represent official advice or opinions of Cornell Cooperative Extension 
or Cornell University.

John Udall,                                       
      Programmer/Systems Administrator            40 Warren Hall
Extension Electronic Technologies Group           Cornell University
Cornell Cooperative Extension                     Ithaca, NY 14853
email: jsu1@cornell.edu                           Phone: (607) 255-8127

Received on Wednesday, 11 February 1998 11:45:12 UTC