iwmw 2004: implementing web standards across the institution - trials and tribulations of a redesign...

Date or reference

Implementing Web Standards across the institution:Trials and tribulations of a redesignPatrick H. Lauke, Web Editor, University of Salford

Institutional Web Management Workshop / Birmingham - July 2004

IWMW2004 / Birmingham 2

Workshop programme

Time Topic16:00 Introduction to the workshop

16:05-16:10 Setting the scene: what do we mean by “web standards”

16:10-16:50 Case study: trials and tribulations of a redesign – the Salford experienceQuestions

16:50 Exercise 2: Implementing web standards – identifying common problems and possible solutionsReport backFinal discussions and conclusion


Workshop aims

At the end of the session participants will:• Be familiar with “web standards"• Have gained an insight into the advantages of

“web standards”• Be aware of potential problems, and approaches

to resolve them


So why am I here?

• Web Editor for University of Salford• Small central team, 30+ devolved web authors• September 2003 University relaunched new

“web standards” based core site• A few trials and tribulations along the way• Many web people considering move to web

standards• Here to share my experiences• Not a guru, don’t have all the answers – simply a

method that worked for us• Hoping to generate good discussion

http://www.google.co.uk/search?q=patrick+h.+lauke


Why are you here?


Setting the scene: what do we mean by “web standards”

Technical:• working to a common, agreed syntax (W3C

spec)• no proprietary markup - compatibility• generating code that validates (so you can have

your little badge on the site?)

“Ethos”:• Return to basic principles: HTML for content,

CSS for presentation• semantic/structural markup (no validator for that!)


Case study: trials and tribulations of a redesign – the Salford experience

“How we got from there…


… to here”

Case study: trials and tribulations of a redesign – the Salford experience (cont.)


Case study: background

• University website redesigned December 2000• first effort by External Relations to bring consistent look

and feel• external design company• happy to say: I didn't do it! (started in January 2001)


Case study: problems with the site

Purely from design point of view:

• Compliant with CI, but tied to print campaign

• Dominant design feature in its own right

• “Naff”/”Kitsch”/{insert expletive here}

• Structurally confusing: “where am I?”


Case study: problems with the site (cont.)

Technical issues:

• Cluttered code: FONT, TABLE

• HTML not made for “round corners” = more markup to fake it

• As result: templates cumbersome



• Pages didn’t print well• Need for “printer friendly”

versions



…and many more problems:

• graphical buttons• dropdown navigation

(accessibility and “spiders”?)

In short: a mess.But…we’ll keep it for a while.Fixed some issues, but most problems remained…


Case study: fast forward 2 years…

• Beginning of 2003 University started CI review• Tightening of lax guidelines, creation of new

ones• Web would need “face lift”• Stricter rules for Faculties/Schools/etc: adopt

the templates!

Do you:a) Simply slap new facade on decrepit old

building?b) Make a fresh start, learning from past mistakes?


Case study: why “web standards”?

• Nowadays: “web standards” buzzword• At the time: just trying to follow best practices• Separation of content/presentation• Lighter code – quicker download times• Accessibility concerns (SENDA/DDA): making

site work in maximum number of browsers – no proprietary markup

• What about next redesign?• “work smarter” / “web design on a shoestring”


Case study: why XHTML specifically?

• Separation of content/presentation can be achieved with HTML4.01 just the same

• Requires “personal” discipline• Stricter syntax for XHTML removes most/all

presentational markup - validation brings more things to light

• Future plans of CMS – repurposing content: XHTML is XML, so simple tools available (XSLT)


Case study: why abandon tables?

• Syntax of XHTML still allows tables (rightly so)• “Ethos” however: tables for tabular data, not

layout• Using pure CSS driven layout: increased

flexibility for future redesigns• Same page / different delivery channels (screen,

print, etc)


Case study: approach - structure

“tabula rasa” – start from scratch• New development server• Inventory of current content• Working out new structure, discarding

old/redundant content• Initially, simply copied pages to new directory

structure


Case study: approach - template

Ideal situation:1. Create page structure2. Style the structure


Case study: approach – template page structure

• Concentrated on identifying “functional blocks”– Branding (logo)– Search box– Navigation– Breadcrumb trail– Content– Footer

• Tempting, but don’t think about what it looks like!(however, think about order in which blocks appear in code)

• Directly translates to XHTML – DIVs (or appropriate block level elements – FORM)

• Try choosing most “semantically appropriate” elements (e.g. navigation as list)

• Validate


Case study: approach – template style

• Creating stylesheet probably took longest• Ideally, XHTML “frozen”• However, occasional need to revisit XHTML: re-

ordering elements, adding “hooks” for specific styling


Case study: approach – template style (cont.)

• Develop for most compliant, then work backwards

• From general to specific (e.g. rough block position, before tackling padding/margin)

• Validate

What about old browsers?


Case study: approach – populating the template

Now bringing it all together:• Content from existing site extracted from pages

(sounds easier than it is: find/replace, retagging, etc)• Same process:

– Create most appropriate XHTML– Where necessary: new page/section specific styles

• In theory: simply “pop it into the template” (plus few manual tweaks)


Case study: approach – populating the template (cont.)

• “Relatively easy” to create beautiful CSS driven layouts with known, “frozen” content(cfr. CSSZenGarden)

• Real-world content offers “interesting” challenges• Often requires revisiting content XHTML, or even template

XHTML/CSS

http://www.csszengarden.com/


Case study: approach – let’s get dynamic

• Static pages converted, but not forgetting database driven areas (e.g. news/events, course finder)

• Mostly simply updating server-side scripts’ output• Databases containing badly formed HTML:

– UPDATEing db tables after cleanup– Solving problem at the root: ensuring HTML data

well formed (if not valid) before committing to database: Editize and “sanity checks”

http://www.editize.com/


Case study: launch

• After final validation and browser testing: launched September 2003

• Set up redirections / rewrite rules on server for new structure

• Monitoring error logs / 404s


Case study: does the design solve original problems?

Design:

• In line with tighter CI• More neutral: allows page-

specific design elements• Feedback: “professional” /

”polished”• Less confusing for visitor

(breadcrumbs, visible navigation)


Case study: does the design solve original problems? (cont.)

Technical:• Separation

content/presentation• “lighter” code (20%-30%

saving or better)• Templates far easier



• No need for “printer friendly” pages (print stylesheet)



• No need for graphical buttons• Navigation now pure list of links: accessible,

“spiderable”


Case study: problems experienced

• Majority due to inexperience with XHTML/CSS – learning by doing

• Choosing semantically most appropriate elements not straightforward (but XHTML is flawed!)

• Authoring tools still not good enough: DW code view, glorified text editor with FTP client

• Flaky CSS support and browser bugs: most annoying

• Testing on multiple platforms not always possible: Mac and different versions of IE

http://www.danvine.com/icapture

http://www.skyzyx.com/archives/000094.php


Case study: what would I have done differently?

• Learning XHTML/CSS while going along resulted in frequent re-starts (now would probably take less time)

• Not using XHTML 1.0 Transitional, but straight to Strict

• Not gone far enough in terms of “semantics”• Although minimal use of “modularisation”

(includes), would go further: more includes, template engine (SMARTY)?

http://smarty.php.net/


That was easy…

…now for the hard part!


Hard part: getting web authors to follow

• Redesign of core site was fairly easy: single developer

• How to get 30+ web authors, with varying skill levels, to follow my lead?

Answers on a postcard…but in the meantime, this is the approach we’re taking…


Hard part: approach

• All sub-sites physically hosted on same server• Created templates, based closely on core site

templates• Use of global includes for header• Stick: new web publishing guidelines, stricter

rules (plus teeth to enforce them) and best practice recommendations

• Carrot: all imperative guidelines taken care of automatically if web authors use templates


Hard part: approach (cont.)

• Education, education, education: replace generic “how to use Dreamweaver” with tailored staff dev sessions

• Web strategy: ensuring Faculties/Schools/etc recognise technical requirements of post, and resource accordingly (still growing teeth to enforce)

• Any 3rd party supplier needs to adhere to standards as fundamental requirement

Majority of sub-sites now transitioned to new design, however this is not the end…


Hard part: continuous QA

• “But it was valid when I first created it…”• Validation of XHTML/CSS as routine, second

nature• Making it as simple as possible: URI based

validation, using right tools for the job• Automatic checks (based on server access logs)

and alerts (e.g. “validator to RSS”)• Any “external” data sources either fixed at

source, or run through filters (TIDY)

http://www.w3.org/QA/Tools/LogValidator/

http://www.benhammersley.com/tools/xhtml_validator_to_rss.html

http://tidy.sourceforge.net/


Conclusion

Brian Kelly: “People may be interested to know how you managed to get your homepage to validate as XHTML 1.0 Strict”

Hmmm…through hard work.• No magic bullet• steep initial learning curve• “Paradigm shift”• Continuous monitoring / QA


Doing it for yourselves: exercise

• Split into groups• Identify problems of implementing web standards

in your own institutions• Discuss solutions/strategies to overcome them• Feed back


Contact

Patrick H. Lauke

Web EditorMarketing & CommunicationsExternal Relations DivisionUniversity of Salford

E-mail: [email protected]: http://www.salford.ac.uk

Personal site (on web standards, css, experimental techniques,etc):http://www.splintered.co.uk

mailto:[email protected]

http://www.salford.ac.uk/

http://www.splintered.co.uk/