In 2011 KPMG needed a “cleanup” of their existing public site, with a focus on information architecture, best practices, conformance to accessibility standards, clear terminology, removing redundant code, integration with SharePoint, and bringing the technical development team up to speed on good process. A big part of my task was to Guide the process and stakeholders in making KPMG’s public site manageable.

Here’s my Scope of Work proposal…

Yes, this document is kinda boring.  But it mapped the path forward for an extremely complex, large-scale, systemic challenge, involving scores of template files,  CSS files, and WebPart files, as well as more than 2600 CSS tags.  This article is nerdy and something of a “deep dive” into implementation issues.

View the original Case Study of this engagement and the descriptive ‘for example’ thumbnail.

Overview

These ‘cleanup’ tasks are presented more or less in order of how they must be addressed:

  • Visualize & Map
  • Correlate
  • Explain & Annotate
  • Clean & Compact
  • Name/Label
  • Group
  • Comply

Visualize & Map

There should be visual mapping of the CSS tags to their on-screen containers.  These should map relationships among Master templates, Layout templates, individual page instances, CSS files, CSS tags and SharePoint zones

  • Index of CSS files
  • Master Templates (3)
  • Layout templates (~25)

Correlate

There are 3 main “views” of the UI:

Focus                                        Perspective

CSS                                            IT/Dev

Sharepoint                            Content Management

Branding                                Marketing

We need to “map” across all three areas.  This has implications for the Naming effort.

  • Cross-reference CSS tags to SharePoint zones.
  • Cross-reference CSS tags with Branding Standards labels so that KPMG design, marketing, management and development groups are “on the same page” as regards how branding is implemented in kpmg.com.

Explain & Annotate

Every file should have a self-evident introductory overview that provides essential information about the purpose and usage of the file.  Several individual CSS tags should also be annotated as to their usage.

  • There should be a “library index” or table that explains how CSS files are being used.
  • Each of the Index of CSS files (~12) must be annotated as to their usage.
  • Certain types of CSS tags must be annotated as to their usage. Critical:  Layout ID tags, Panel tags (s.a. SP zones, webparts, pods)

Clean & Compact

Reduce redundancy.  This requires a holistic grasp of the interrelationship of css tagging structure within a page.

This conversion effort requires a solid understanding of the “box structure” nesting relationship of the tags and the paths of inheritance.

  • Remove inline attributes from templates and transfer – when necessary – to CSS files. May involve creating new CSS tags.
  • Concatenate redundant tags and attributes.

Name/Label

Existing CSS tags need to use consistent, sensible naming conventions and styling.  We can pursue this only when we have a clear understanding of current CSS structure.

  • Grouping and Naming of CSS tags are closely interdependent.

Group

Classes & ID’s should be organized by function and/or application in CSS file.  Some of this has already been done in existing CSS files, but there are large numbers of newly-added tags that are arranged randomly in the files. We can pursue this only when we have a clear understanding of current CSS structure.

  • Grouping and Naming of CSS tags are closely interdependent.

Comply

CSS attributes conform to W3C accessibility standards and general best practices

  • Define primary Design Challenges
  • Solution technique: Convert font-sizing to ems
  • Solution technique: Convert widths to percent
  • Solution technique: Convert colors to websafe palette

 

This is a reorganization, simplification, and “chunking” of the UX tasks into several stages.

When using the term “modules”, we refer to both webparts and pods, as well as any other code-driven components that are re-useable within the SharePoint template environment.

The Templates/Pods, Webparts and Pages stages all assume to make in-page changes to underlying html files, as well as css.  They deal with the contents of existing CSS tags in existing CSS files and do not involve changes to in-page code – which would involve code changes and devteam and require substantial testing.

The Optimization stage is where final cleanup and infrastructure work happens, as well as cleanup of XSL files.

The Infrastructure stage is somewhat un-dependent on other stages.  Some of these tasks can be accomplished “in parallel”.

The Administration stage involves the same range of tasks as the Templates/Pods and Webparts stages.

 

Templates/Pods

Volume/Scale:  5 aspx Master Template files, 25 aspx Layout Template files, 7 ascx pods, 8 CSS files.   Include “Editing Mode” CSS and HTML, as well as Chinese-language CSS (43KB)

CSS Structure within a Template or Pod

  • Map the CSS tags that are in each template and pod; structure

Focus: Identify the “core” CSS design tags (mostly done)

CSS Mapping among Templates & Pods

  • Identify which CSS tags are shared among which templates

Focus: Identify the profile of the usage of CSS tags across templates (partially done)

Cleanup

  • Remove html tables (convert to divs)
  • Remove <script> in templates & pods (create”common.js” file)
  • Remove <style> in templates, modules, pages (migrate to css files)
  • Remove attribute redundancies
  • Convert CSS attributes to accessibility best practices (use of ems and %)

Focus:  Reduction in code overhead. Complies with Accessibility “Green Points”

Webparts

Volume/scale: 96 ascx WebPart files, 1 CSS file

CSS Structure within a webpart

  • Map the CSS tags in each webpart, and in what structure

Focus: Identify the “core” CSS design tags for webparts

CSS Mapping among webparts

  • Identify which CSS tags are shared among which webparts

Focus: Identify the profile of the  usage of CSS tags across webparts

Cleanup

  • Remove html tables (convert to divs)
  • Remove <script> in templates, modules, pages (create”common.js” file)
  • Remove <style> in webparts (migrate to css files)
  • Remove attribute redundancies
  • Convert CSS attributes to accessibility best practices (use of ems and %)

Focus:  Reduction in code overhead.  Complies with Accessibility “Green Points”.

Pages

Volume/scale:  Large unknown number of CSS tags – essentially: What’s left after accomplishing Templates/Pods stage and Webparts stage.)  This stage is not scoped at this point, as mapping it is dependent on completion of the Template Stage and the Module Stage.

The CSS tags themselves represent the bulk of the “messy”, ad hoc CSS tags that are disorganized, poorly-configured, badly-named and redundant.

CSS Structure

  • Map the CSS tags to the pages in which they appear

Issues: The volume of pages is currently un-scoped

CSS Cleanup

  • Reorganize tags into appropriate files
  • Annotate tags as to usage
  • Remove attribute redundancies
  • Convert CSS attributes to accessibility best practices (use of ems and %)

Focus:  Improved CSS files, “map” of CSS tag usage, some Accessibility compliance.  Goals: Reduce number of css tags dramatically

 

Optimize CSS

Scale/scope: (Across all CSS files, CSS tags, Templates, Modules and Pages)  This stage is has substantial impact on CSS, but it also has major impact on HTML.  As a result, it has substantial implications for in-page code and involves significant Dev testing. The sole QA issue is whether the pages still look the same.

Reconfigure tagging format in templates and modules

  • Organize the CSS tags into groups in the CSS files
  • Annotate tags as to usage

Focus:  Implement CSS design Best practices

Restructure CSS attribute code in tags

  • Concatenate tags when appropriate

Rename CSS tags & files

  • Rename tags sensibly and consistently
  • Map the CSS tags to Marketing Redline   Cross-reference CSS tags to SharePoint and Branding labels

Focus: Common terminology across 3 cultural platforms

XSL cleanup

  • Remove html tables,<script>,<style>, attribute redundancies
  • Convert CSS attributes to accessibility best practices (use of ems and %)
  • Reorganize & annotate tags

Infrastructure

Correlate

  • Map CSS tags in templates to CSS files
  • Map CSS tags to templates
  • Map templates to pages / pages to templates
  • Create“ Index” of CSS files

Infrastructure: Maintenance

  • Capture in database / table (SharePoint?)

Compliance (Define criteria)

  • Compile & document Accessibility Compliance Checklist
  • Requires signoff by stakeholders re KPMG’s compliance criteria

Focus:  Ensure that dev group has guidance for compliance criteria that they implement

Compliance (presentational  backup)

  • Create “compliance-friendly” stylesheet versions

Focus: Ensure that page will display appropriately for people with accessibility issues

Best Practices

  • Compile generic set of UI best practices, focusing on CSS
  • Define Process for UI

Focus: Ensure that dev group and designers have formalized UI  guidance

Administration

Volume/scale: 23 aspx Admin files.  Admin files seem to vary substantially as to size & complexity. Estimates of duration may be overly generous. These may involve some of the same conditions as Editing Mode stage (below)

CSS Structure within an admin page

  • Map the CSS tags in each admin page, and in what structure

Focus: Identify the “core” CSS design tags for webparts

CSS Mapping among admin pages

  • Identify which CSS tags are shared among which admin pages

Focus:  Identify the profile of the  usage of CSS tags across webparts

Cleanup

  • Remove html tables (convert to divs)
  • Remove <script> in templates, modules, pages (create”common.js” file)
  • Remove <style> in webparts (migrate to css files)
  • Remove attribute redundancies
  • Convert CSS attributes to accessibility best practices (use of ems and %)

Focus: Reduction in code overhead.  Complies with Accessibility “Green Points”.


Background and Rationale of the UX Challenge

 

The four disciplines of User Experience (UX) are:

  1. Information Architecture (Semantic Structure)
  2. Interaction Design (Workflow)
  3. Usability (Behaviors)
  4. Creative (Presentational styling)

This is not simply “a coat of paint” on the surface of functional code.  It is integral to the creation and maintenance of the code itself.  UX has substantial implications for the IT DevTeam – Especially in a project like this one, which “cleans up” and retrofits existing program code.

Initial Stage:  Information Architecture & CSS Cleanup

The initial stage of the KPMG UX Challenge is CSS Cleanup.  This stage deals exclusively with the “information architecture” of kpmg.com, which is embodied in the tags of the site’s Cascading Stylesheets (CSS).

These CSS tags are the common ground among the IT Development Team, Marketing, which defines presentational standards, and the SharePoint Content Management System which is the structural backbone of kpmg.com.  The CSS is the semantic structure of KPMG’s web presence.  It is the fundamental building block of any intelligent information system. Any changes to CSS have implications across all vectors of the endeavor: programming, database maintenance, design and “user interface”.

Kpmg.com is the model for more than 140 global websites which are maintained and customized locally.  The scale and scope of all of those sites are directly affected by the CSS Cleanup.

This is why it is necessary to execute a fully-featured Proof of Concept for the CSS Cleanup stage.

We expect to address Workflow, Behaviors and Presentational Styling issues in future stages.

CSS Cleanup

In CSS Cleanup we focus on Four main areas:

  • Best Practices
  • Compliance with Accessibility Standards
  • Management & Maintenance Process
  • Design Platform

Best Practices

IT’s CSS Cleanup process conforms to industry “best practices”, which ensure that the CSS is well configured, well-formed and well-integrated.  These are being captured as reference-able guidance documents.

Compliance with Accessibility Standards

IT’s commitment to Best Practices also inherently implies our conformance with KPMG’s Accessibility, SEO and Usability policies (recently released), which echo accepted industry standards.

Effective Management & Maintenance Process

You can’t fix it until you know what you have, where it is, and what it’s called.  CSS Cleanup provides the map, as well as the first phase of solutions.  The implications for ongoing management, maintenance and cross-discipline & enterprise-wide communication should be obvious.

The information identification and mapping collateral that we produce in the course of CSS Cleanup have “legs” beyond IT and fixing the code.  The knowledge management aspects of this project should not be overlooked.

Viable Design Platform

  • KPMG Marketing wants to maintain brand identify & consistency
  • Site creators and managers want a simple, easy-to-use editorial environment that is based on pre-formatted, re-usable components
  • … that still allow for some flexibility (the notion that you have some creative elbow room within a well-defined, well-regulated structure)

The CSS Cleanup stage is fundamental to achieving any of these goals.  The Proof of Concept is essential for implementation of the initial stage of CSS Cleanup.

Proof of Concept

The challenge of CSS Cleanup is daunting because we do not have the luxury of “a clean slate”.  The CSS Cleanup is expected to deal with substantial legacy problems. CSS Cleanup has implications for both technical code environment (IT DevTeam) and the user interface design arena (Marketing and the Editorial interface).

The POC is driven by several factors:

  • The style sheets, the templates, design components, code generation modules and the SharePoint platform are inextricably intertwined. It is almost impossible to work on one without also addressing the others.
  • The inter-relationship among the technical programming and design elements is highly complex. They must be addressed, tested, and solved in context.
  • One reason for bringing UX expertise onboard in order to implement CSS Cleanup is because the fundamental information architecture aspect of CSS in the legacy kpmg.com was not particularly well organized or documented up to this point.
  • The production and design environment is made more complex by the inclusion of 3rd party CMS software SharePoint, which imposes its own CSS structure and coding metaphor.
  • A goal of the UX engagement is to provide best practices guidance and workable, efficient process in the handling of CSS going forward.

The POC allows the CSS-oriented UX resource and the IT DevTeam to work out and test the underlying assumptions regarding the CSS cleanup across this range of challenges.

 

 

© The Communication Studio LLC

Advertisements