The User and the Web

Steven Pemberton, CWI, Amsterdam and W3C
Chair, W3C HTML and Forms Working Groups
Editor in chief, ACM/interactions

An Auspicious Time and Place

March 15-17, 1982, Gaithersburg: The first CHI Conference

Bill Curtis, Chair

"The Washington DC Chapter of the ACM asked me if we had any conference ideas they could support with some of their surplus funds. I [...] described our ideas for a conference that we estimated would attract about 250 people, probably most from the DC area. They provided us $2000 with the proviso that while they did not want any money back, they did not want us to get them in debt. Armed with this seed money we went to the National Bureau of Standards in Gaithersburg, MD. and got their support for facilities and mailing.

...

(Gaithersburg 1982)

907 people came from all over North America and many from Europe. Never in our wildest estimates did we anticipate so many people attending. The lunch line at the National Bureau of Standards was 200 yards long. [...] Ultimately the conference committee double-crossed the Washington DC Chapter of the ACM. The chapter had wanted to reduce their $10,000 cash surplus. The conference returned somewhere between $70,000 and $100,000 and now they really had a surplus problem."

See: http://www.acm.org/sigchi/bulletin/1996.1/conf-chairs.html#HDR0

What are the important properties of a website?

Forrester did research among 8000+ users on why they chose one website above another equivalent one. Reasons were:

What are the important properties of a website?

Forrester did research among 8000+ users on why they chose one website above another equivalent one. Reasons were:

Content 75%

What are the important properties of a website?

Forrester did research among 8000+ users on why they chose one website above another equivalent one. Reasons were:

Content 75%
Usability 66%

What are the important properties of a website?

Forrester did research among 8000+ users on why they chose one website above another equivalent one. Reasons were:

Content 75%
Usability 66%
Speed 58%

What are the important properties of a website?

Forrester did research among 8000+ users on why they chose one website above another equivalent one. Reasons were:

Content 75%
Usability 66%
Speed 58%
Freshness 54%

What are the important properties of a website?

Forrester did research among 8000+ users on why they chose one website above another equivalent one. Reasons were:

Content 75%
Usability 66%
Speed 58%
Freshness 54%

All other reasons were 14% or lower.

Why we are here: W3C Working Groups

W3C, The World Wide Web Organisation, is "Leading the Web to its Full Potential..."

It has a (large) number of working groups, responsible for doing this:


X M L	C S S	H T M L	.	.	.	e t c .

Why we are here: W3C Working Groups

W3C, The World Wide Web Organisation, is "Leading the Web to its Full Potential..."

It has a (large) number of working groups, responsible for doing this.

Above these, it has a number of 'horizontal' working groups, covering all areas:


Accessibility
Internationalisation
Device Independence
Quality assurance
X M L	C S S	H T M L	.	.	.	e t c .

Why we are here: W3C Working Groups

Clearly, usability is missing from this picture:


Accessibility
Internationalisation
Device Independence
Quality assurance
Usability
X M L	C S S	H T M L	.	.	.	e t c .

What might a Usability Group do?

Specifications: content

Specifications: style

General awareness

Guidelines

[More: that's what this workshop is about]

One essential ingredient

Non-usable specifications can be fixed with tutorials

Guidelines are being produced by others

But if the technology described by a specification is not usable, then we are stuck!

Usability of Technologies: Example: image maps

Original server-side:

<a href="sample.map">
   <img src="sample.gif" ismap>
</a>

Client-side:

<img src="image.gif" usemap="#sample">
<map name="sample">
  <area shape="rect" coords="20,27,82,111"
        href="hot1.html">
  <area shape="circle" coords="129,113,29"
        href="hot2.html">
  <area shape="rect" coords="21,158,170,211"
        href="mailto:webmaster@ihip.com">
  <area shape="default" nohref>
</map>

The client-side version offers better usability because the user agent can show what is clickable, and give feedback on where it will take you (it also offers more accessibility, and is better scalable, since more work is done on the client).

Example: Frames

As an example of poor usability, current frames are a disaster!

The [back] button works unintuitively in many cases.
You cannot bookmark a collection of documents in a frameset.
If you do a [reload], the result may be different to what you had.
[page up] and [page down] are often hard to do.
You can get trapped in a frameset.
Search engines find HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.

Frames continued

Since you can't content negotiatiate, <noframes> markup is necessary for user agents that don't support frames. Search engines are 'user agents' that don't support frames! But despite that, almost no one produces <noframes> content, and so it ruins web searches (and makes builders of such sites look stupid!)
There are security problems caused by the fact that it is not visible to the user when different frames come from different sources.

Currently the HTML WG is devising XFrames, a replacement for Frames.

Usabilities of Notations: Example: XLink

In HTML:

<img alt="..." src="img.gif"
     longdesc="desc.html" usemap="#map"/>

with XLink:

<img xlink:type="extended" alt="..." >
<xlink:locator role="src" href="img.gif"/>
<xlink:locator role="longdesc"
               href="desc.html"/>
<xlink:locator role="usemap" href="#map"/>
<xlink:locator role="self" 
               href="#xptr(here())"/>
<xlink:arc from="self" to="src" 
           show="embed" actuate="auto"/>
<xlink:arc from="self" to="longdesc" 
           show="new" actuate="html:user2"/>
<xlink:arc from="self" to="usemap"
           show="html:imagemap" actuate="onRequest"/>
</img>

For the author this second version is clearly less usable, with no concomitant advantage.

Example HTML (then)

<html>
<head>
<title>My web page</title>
<body>
...
</body>
</html>

Example HTML (coming soon)

Because of the way XML technologies are designed in isolation, without an eye for how they all fit together, there is no top-level desing, and so you risk getting results like the following:

<?xml version="1.1" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="xhtml2.css"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "xhtml2.dtd"[
<!ATTLIST html
xmlns:xsi CDATA #FIXED "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation CDATA #IMPLIED >

]>
<html xmlns="http://www.w3.org/2002/06/xhtml2" xml:lang="en"
xmlns:ev="http://www.w3.org/2001/xml-events"
xmlns:xfm="http://www.w3.org/2002/01/xforms"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2002/06/xhtml2 xhtml2.xsd ...">
<head>
<title>My web page</title>
</head>
<body>
...
</body>
</html>

(Several things have been left out here for briefness)

Example: Schemas

They were supposed to replace DTDs, but:

They don't support the definition of entities:

Instead of € write €
Instead of ™ write ™
etc.

which makes it harder to author documents.

Not easy to read (or write)

Schema fragment

<elementType name='table'>
   <refines>
      <archetypeRef name='common'/>
      <archetypeRef name='simpleBlockDisplay'/>
   </refines>

   <sequence>
      <elementTypeRef name='caption'
          minOccur='0' maxOccur='1'/>
      <choice>
          <elementTypeRef name='col'
               minOccur='0' maxOccur='*'/>
          <elementTypeRef name='colgroup' 
               minOccur='0' maxOccur='*'/>
      </choice>

more >>>

(schema fragment)

      <choice>
         <sequence>
            <elementTypeRef name='thead'
               minOccur='0' maxOccur='1'/>
            <elementTypeRef name='tfoot'
               minOccur='0' maxOccur='1'/>
            <elementTypeRef name='tbody'
               minOccur='1' maxOccur='*'/>
         </sequence>
         <elementTypeRef name='tr'
            minOccur='1' maxOccur='*'/>
      </choice>
   </sequence>
</elementType>

(equivalent DTD)

The schema fragment above is the equivalent to the following DTD fragment:

<!ELEMENT table
     (caption?, (col*|colgroup*), thead?,   
      tfoot?, (tbody+|tr+))>

Working groups and Interest groups

Working Groups typically produce deliverables (Recommendation track technical reports, software, test suites, reviews of the deliverables of other groups, etc.) There are participation requirements for a Working Group

The primary goal of an Interest Group is to bring together people who wish to evaluate potential Web technologies and policies. An Interest Group is a forum for the exchange of ideas. There are not generally participation requirements for an Interest Group.

Creating a group

The Director creates, modifies, or extends a Working Group or Interest Group by sending a call for participation to the Advisory Committee. The call for participation must include a reference to the charter, the name(s) of the group's Chair(s), the name of the Team contact, and instructions for joining the group. A group does not exist prior to the initial call for participation.

Charter (must)

A Working Group or Interest Group charter must include the following information.

The group's mission (e.g., develop a technology or process, review the work of other groups, write the charter of another group, etc.);
The scope of the group's work and criteria for success;
The duration of the group (typically from six months to two years);
The nature of any deliverables (technical reports, reviews of the deliverables of other groups, software, etc.), expected milestones, and the process for the group participants to approve the release of these deliverables (including public intermediate results). A charter is not required to include the schedule of a review of another group's deliverables;
Any dependencies of other entities on the deliverables of this group. For any dependencies, the charter must specify the mechanisms for communication about the deliverables (contact people, names of Coordination Groups, names of W3C contacts, etc.). The charter should identify any requirements documents that may be required by other entities;
Any dependencies of this group on other entities. For example, one group's charter may specify that another group is expected to review a technical report before it can become a Recommendation. For any dependencies, the charter must specify when required deliverables are expected from the other entities. The charter should set expectations about how coordination with those entities will take place. Finally, the charter should specify expected conformance to the deliverables of the other entities;
The level of confidentiality of the group's proceedings and deliverables and, in particular, whether the charter itself will be public. The charter should include rationale for any level of confidentiality other than public;
IPR disclosure requirements(see W3C's IPR policy);
Meeting mechanisms and expected frequency;
Communication mechanisms to be employed within the group, between the group and the rest of W3C, and with the general public;
The expected level of involvement by the Team (e.g., to track developments, write and edit technical reports, develop code, organize pilot experiments, etc.).
An estimate of the expected time commitment from participants.

Charter (may)

A Working Group or Interest Group charter may also include the following information:

Requirements that a quorum of group participants support any formal decision of the group.
Voting procedures for making decisions about substantive issues. Any chartered voting procedure must include the following requirements:
- Each Member organization or group of related Members must only be allowed one vote, even though each Member may have several participants in the group. If more than one vote is received from a Member organization or group of related Members, the votes must be counted as one vote if they agree, otherwise they must be ignored and the Chair must inform the participant's Advisory Committee representative(s) of the discrepancy.
- In a Working Group, only Working Group participants may vote.
- All votes must be archived.

A charter may include provisions other than those required by this document. The charter should highlight whether additional provisions impose constraints beyond those of the W3C Process Document (e.g., limits on the number of individuals employed by the same Member organization or group of related Members who may join a Working Group).

What we have to do

Decide if it's a good idea

Decide what should be covered

Write a charter

Get people involved!

These slides

http://www.w3.org/2002/Talks/1104-usability-workshop/