Weblogs: Web Standards

@Media 2005: Web standards workflow by Molly Holzschlag

Sunday, June 26, 2005

Molly Holzschlag is the guiding light of the Web Standards Project. Author of a bookshelf of web-related books, the two most recent are Spring into HTML and Zen of CSS design. She presents on web standards workflow - how and where to incorporate web standards.

Working on The Zen of CSS Design was an opportunity to get into the minds of 26 web designers. A CSS Tips sheet is available.

Web Standards Project

In the audience today are the following WaSP members:

The Browse Happy campaign

The Browse Happy website was recently given to WordPress. We, in WaSP, sting when we have to. Last year we exploited the fact that Internet Explorer vulnerabilities was a visible topic in the United States, for example CERT issued an advisory that people shouldn't use Internet Explorer. We took the opportunity to do a browser switch campaign.

Time, people and the environment change. Environment-wise, the opening of Microsoft's doors, particularly the efforts of Channel 9, and the allowance of many people in Microsoft to blog and make public expressions. This was a unique move for Microsoft, their marketing guys like to keep their people muzzled. There was recognition of Microsoft developers as our peers, they are very much the same as we: software developers, engineers and web designers. We don't want to be adversarial. A decision was made on that basis to ditch the BrowserHappy campaign, and pass it over to WordPress.

Acid 2

This test was created by Hakon Lie, Ian Hickson, Molly Holzschlag and others. It was created and promoted as a test for CSS 2.1 compliance as well as testing for alpha transparency. Authoring tools like Dreamweaver and Go-Dead (I mean Go-Live) are working to achieve compliance. Creating a W3C test suite takes too long, so Lie went down the WaSP track. Opera, Safari have invested time to make their browsers compliant. Both browser and tool developers are working towards Acid 2 compliance - except for Microsoft.

Macrodobia

We don't know what is happening as a result of the merger between Macromedia and Adobe. One representative deep inside Adobe has commented that there is strong standards support within the company. Rachel Andrew and Drew McLellan are still carrying forward their consultancy with Macromedia. Before the merger Macromedia were testing their products against the Acid 2 test.

One bet I will make, I bet that we won't have stability on the web. Because of new technologies always emerging, the web won't have time to become stable.

Web standards workflow

The original vision for the web was as a globally accessible. It works on any platform, in any user agent, for any person. Its an international community with many languages. The web is to be meaningfully searchable and useful.

Past workflow

The past was about conventional and presentational web design, like a layered cake, But where the cake is best when complete with icing. We developed sites that looked good - which is far away from being globally accessible.

The typical approach to a web site workflow goes through the following stages:

  1. Photoshop designs
  2. Wireframe
  3. Presentational HTML, using Dreamweaver with no or little CSS
  4. Client prototype
  5. Produce website
  6. Modify website from client changes
  7. Signoff website
  8. Maintenance

The lessons we learned included that prototyping is a time consuming process. It involves graphical prototyping. Recreating graphics is a time consuming process. Each page is hard-coded with a table-based design and presentational-based HTML. This is not easy to update. Its a nightmare to manage, and causes accessibility problems. The end result is overly marked up documents, graphically and script intensive. Its a case of Organic Growth Syndrome (OGS).

The original vision of the Web was obscured within one or two years.

Present workflow

Our present workflow involves contemporary future-proof, or bulletproof, design. We look for ways to write our markup so that we don't have to change it later. The primary motivation is to create good looking, accessible and lightweight websites and designs.

The typical workflow becomes:

  1. Photoshop layout
  2. CSS Wireframes - this becomes helpful when working across offices in different countries. Netscape devedge used CSS Wireframes. Using no presentational HTML, a phone call, an instant message, any discussion and the wireframe can be refined quickly. There's less time needed to make these changes, and all we need to do after that is add in a colour layer.
  3. presentational independent HTML
  4. Client prototype
  5. Produce website
  6. Modify website from client changes
  7. Signoff website
  8. Maintenance

Its a new challenge. CSS Wireframes are much faster than the old prototyping methods, the decision making process is also much faster. Client modifications can be addresses quicker. Since the prototype is already marked up (in cruft-free markup) very little markup needs to be trimmed or refined to be ready for production use.

The resulting HTMLdocuments are innately lighter and more accessible. Accessibility doesn't matter, it doesn't need its own special checkpoint, good web designers are already implementing it in the wireframe phase, so they don't have to come back and redo the prototype for accessibility.

The resulting sites are easily well ranked by search engines.

Back to the future

The web will be beyond the desktop. Wireless is in the picture, requiring different types of visuals. We'll need to create beautiful sites that work everywhere. We'll do this by using a web standards based workflow. Moving beyond the desktop returns us back to the original vision of the web.

Tim Berners Lee in a conference stated that if we don't clean up this layer of the web, its not going to be stable. He is concerned that we won't get to the next level of the web. Our structured markup assists in advancing both the uppercase and lowercase Semantic web.

The uppercase Semantic Web is the W3C work around RDF. Its about extending the web to allow machines to talk to each other.

The lowercase Semantic Web is the idea that we already have some things in HTMLthat we can use to further the idea of the Semantic Web without reinventing the Web. It uses pieces of HTMLmarkup, like class attributes that we can tap into, or a rel attribute. We create hooks in the markup which we can then use for greater search capabilities, for example XFN, Flickr sensitive tags, Technorati tags. Already with the lowercase Semantic Web we have the tools to answer queries like "Search for movies showing on Saturday that have been seen and recommended by a friend, with a rating of child-friendly, and somewhere nearby I can go."

The envisioned workflow could be as follows:

  1. Photoshop mockups.
  2. CSS Wireframes (for all media types, for example desktop browsers and PDAs).
  3. Semantic documents, no presentational HTML. Using Microformats and adopting internationalisation features.
  4. Client prototype
  5. Produce website
  6. Modify website from client changes
  7. Signoff website
  8. Maintenance

The potential problems with this workflow are that the CSS becomes more complex, and there's more CSS to manage.

Web designers today are not educated from the ground up with CSS and so spend much of their time refitting and reworking non-CSS designs. They are struggling with CSS because of the band-aid effect (spending time retrofitting non-CSS designs). More and more people are benefiting from not having to deal with tables-based layout.

A centralised CSS is the best approach when starting a new site, rather than trying to retrofit.

Development time will be increased because of multiple device design, also the scope and detail of the website increases in complexity because it is now feasible to do so. More stuff is added to the website. Maintenance time is increased, because of the scope and detail of the site.

Redesigns are achieved far more quickly. Its less time consuming and less costly.

Radical results

The HTMLdocuments are extremely light, flexible and accessible. The documents are already tagged, supporting Microformats. They are tagged for improved search and content aggregation. They are really accessible - accessible to humans - which meets the original vision of the web. The web was not envisioned as a visual medium, but it is one now, but now it is not limited to that. Websites can be multilingual.

Technology and methods are changing drastically. We need to manage the Organic Growth Syndrome (OGS) by critical planning. The future proofing requires minimal, but semantic markup, and also involves in centralising scripts and styles. We need to ask ourselves the same questions over and over again, for example when deciding to drop support for a browser (or drop in hack supports in the meantime.

Questions and answers

About streaming and dynamic content without third party apps: SMIL has been having implementation problems, and the lack of speed from the W3C is a concern.

We've been asked not to blog about the details of the current work WaSP are undertaking until the formal press releases.

About the difference between CSS Wireframes and the final website result: The CSS wireframe contains minimal markup and style, it tends to have no colour.

About case studies for CSS Wireframes: there are no case studies currently available per se. The Netscape devedge process is documented, also Eric Meyer talks about CSS Wireframes on his blog.

About the impact of Microsoft Office XML format on the web: Molly is under an NDA about this.

About Content Management Systems: There has been a rise in the number and quality of Open Source and highly customisable CMS. CMS in general are notoriously problematic in regards to web standards, its a good example of the damper-sand phenomenon. Economically, CMS is expensive to implement. Retrofitting a current website is still difficult when starting without a standards savvy CMS systems. We need to ask how will this CMS serve us for the future. We need to articulate these problems, there are lots of conversations in the Open Source environment on such ideas, for example Mozilla and Wordpress.

Other coverage

[ Weblog | Categories and feeds | 2011 | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 ]