the IdeasBlog

Process: CRM, CSS and Template Cleanup

Advertisements

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

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

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.

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.

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.

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.

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.

Comply

CSS attributes conform to W3C accessibility standards and general best practices

 

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

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

CSS Mapping among Templates & Pods

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

Cleanup

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

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

CSS Mapping among webparts

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

Cleanup

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

Issues: The volume of pages is currently un-scoped

CSS Cleanup

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

Focus:  Implement CSS design Best practices

Restructure CSS attribute code in tags

Rename CSS tags & files

Focus: Common terminology across 3 cultural platforms

XSL cleanup

Infrastructure

Correlate

Infrastructure: Maintenance

Compliance (Define criteria)

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

Compliance (presentational  backup)

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

Best Practices

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

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

CSS Mapping among admin pages

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

Cleanup

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

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

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