1 / 40

Institutional Web Management Workshop / Birmingham - July 2004

Implementing Web Standards across the institution: Trials and tribulations of a redesign Patrick H. Lauke, Web Editor, University of Salford. Institutional Web Management Workshop / Birmingham - July 2004. Workshop programme. Workshop aims. At the end of the session participants will:

emmet
Download Presentation

Institutional Web Management Workshop / Birmingham - July 2004

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Workshop programme

  3. 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

  4. 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

  5. Why are you here?

  6. 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!)

  7. Case study: trials and tribulations of a redesign – the Salford experience “How we got from there…

  8. Case study: trials and tribulations of a redesign – the Salford experience (cont.) … to here”

  9. 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)

  10. 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?”

  11. 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

  12. Case study: problems with the site (cont.) • Pages didn’t print well • Need for “printer friendly” versions

  13. Case study: problems with the site (cont.) …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…

  14. 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: • Simply slap new facade on decrepit old building? • Make a fresh start, learning from past mistakes?

  15. 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”

  16. 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)

  17. 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)

  18. 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

  19. Case study: approach - template Ideal situation: • Create page structure • Style the structure

  20. 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

  21. 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

  22. 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?

  23. 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)

  24. 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

  25. 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”

  26. 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

  27. 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)

  28. Case study: does the design solve original problems? (cont.) Technical: • Separation content/presentation • “lighter” code (20%-30% saving or better) • Templates far easier

  29. Case study: does the design solve original problems? (cont.) • No need for “printer friendly” pages (print stylesheet)

  30. Case study: does the design solve original problems? (cont.) • No need for graphical buttons • Navigation now pure list of links: accessible, “spiderable”

  31. 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

  32. 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)?

  33. That was easy… …now for the hard part!

  34. 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…

  35. 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

  36. 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…

  37. 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)

  38. 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

  39. 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

  40. Contact Patrick H. Lauke Web Editor Marketing & Communications External Relations Division University of Salford E-mail: p.h.lauke@salford.ac.uk Web: http://www.salford.ac.uk Personal site (on web standards, css, experimental techniques,etc): http://www.splintered.co.uk

More Related