The clone of documents war

A web project manager produces different kinds of documents including analysis, presentations, benchmarking, debrief, even wireframes. I work for many different companies and it happens that i am asked to use ready-to-use templates with institutional logos, colors and fonts.

This is where the battle begins. If it usually takes a couple of hours to produce the documentation, trying to make it fit into the template that was handed to me is often a titanic task.

The problem is that it is not, in most cases, a real template, but a clone of documents that have been emptied of content and with no trace of formatting guidelines.

Font type and size have not been made as document styles, but they have been applied to the text whenever necessary. And even if styles were used, they were only for the main text and (perhaps) for a type of header.

This approach is inefficient for several reasons:

  • every time you insert a new element, such as a title, you have to copy its style from the previous one
  • you lose the “semantics” of the document: headers should be as that because the information is specified in the document, while in these documents they are headers simply because the font is “bigger” than the one used for normal text
  • quality will degrade over time: the first two documents will comply with the standard in some way, the next will lose almost all the formatting
  • it is not possible to apply the styles at a later time, for example in the case of documents already produced; they have to be re-edited item by item

This occurs with Word documents, but not only. Powerpoint and Keynote also suffer the same problem. Rather than invest a half a day to create the master slide which can then be applied in each presentation, it is considered a simpler approach to create a presentation with some slides which are then copied and pasted over and over again.

Whenever I can I ask for the clients their “template” before producing documentation, so that I can check how they are made. If the quality is not satisfactory to me, but the number of documents that I plan to write is small, I still use these templates to produce the documentation.

But if have to write many documents, I usually prefer to invest some hours to completely rebuild the template. The operation usually takes me a couple of hours (in case of a presentation a little more), but it is time well spent, especially for me.

On the surface, compared to the template that was handed to me, nothing changes. But the work of producing the documentation is surely reduced.

Designing with paper

For some months now I am using with satisfaction a different tool for the design phase that follows the definition of the online strategy and precedes the creation of prototypes. I take a sheet of paper and hand-made sketches which can then be shared and evaluated together with the User Experience team.

Nothing new or that I had never tried, but I believe it is a practice too hastily abandoned because considered unprofessional.

Two readings helped me change my mind: Paper Prototyping by Carolyn Snyder and the recent Prototyping written by Todd Zaki Warfel and published by Rosenfeld Media. Both texts provide excellent tips on how to build prototypes with the paper and the book by Carolyn Snyder also explain how to use these prototypes for real usability test sessions with users.

I don’t prototype with paper. Paper helps me to design in the form of sketches the interface and the interaction of different ideas that can then be evaluated, rejected, selected with the team UX. It is therefore a quantitative approach, which aims to produce in a very short time several sketches that can then be analyzed by the team and criticized without the fear of having wasted hours or days of work. Each sketch should take no more than half an hour to be drawn.

I find the use of paper effective also when working with remote teams: I scan it and the sketch can be shared with the rest of the world.

Normally I do not use a sheet of white paper, but I do use a simple template that include the browser interface and some guidelines (for example, the most common resolution). On the Internet you can find dozens: I personally am very happy with the work of UIStencil (the template is available in PDF format).

The different designs are then evaluated together with the rest of the US team and usually put on a wall or blackboard.

Zaki Warfel in Prototyping summarized how this process should take place.

PT001: Figure 2.1

Diagram of the iterative design and critique process. Warfel, Todd Zaki. 2009. Prototyping: A Practitioner's Guide. New York: Rosenfeld Media. http://www.rosenfeldmedia.com/books/prototyping/

It is, as you can see in the diagram, an iterative process.

Sketching is the generative part of the process, whose objective is to propose different ideas without paying attention to details or inconsistencies (fast and furious).

The purpose of the critique phase is to find, among the different ideas, the best. The one that created the sketch lists the strengths while your teammates highlight gaps and require further investigation. This phase should last only a few minutes, because the details will be taken into account during the process of creation of real prototypes.

It’s at this point – that is, for prototyping and usability testing with users – that i abandon the paper. I prefer in fact to use tools to simulate a little more in detail the transitions of a typical web page, such as Ajax interactions. In this sense my favorite tool is Axure RP: it’s expensive, but allows you to create real prototypes rather than wireframes, on which the paper still wins.

The lifecycle of web accessibility

Nowadays, building a web site is a task that requires many different professional skills, each one with its own life cycle. Development, as we learned in some software engineering class, has a life cycle and so have usability, design and content.

However, when we discuss web accessibility, it often seems that this discipline comes into play only when we develop templates or write content.
Instead, this is rarely the case.

In this article we’ll divide the life cycle of web accessibility into 5 different phases and we’ll see how they are strictly interconnected with other disciplines such as graphic design, development and content management.

Please note that this cycle is not intended as a linear sequence of steps and that it focuses on skills rather than on people (because the same person can master more than one skill, especially for small size projects).

Requirement Analysis

What’s In This Phase?

During the requirement analysis phase you define the target audience of the site, the business expectations, the technical constraints and the user’s goals. You interact with your client to have an understanding of the site purpose and to know which resources and which tools are needed to build it.

Usually, if you’re doing a good job, you will prepare different scenarios. A scenario is a hypothetical representation of how a specific (imaginary) person will interact with the site, it contains a user profile (called persona) and a schedule of their typical day.

How Web Accessibility Comes Into Play

You need to define specific profiles of people that will use your site, being as detailed as you can. This means that you have to take into account people with a combination of disabilities that can be physical, mental or technological. An excellent example can be found reading Mark Pilgrim’s Dive Into Accessibility, a tutorial meant to help developers in building accessible web logs (and websites), where the author presents 4 different scenarios based on disabled people.

Which disability considered in your scenarios depends on the audience of your site, but bear in mind that a disabled person interacts with almost every kind of site. You could think, for example, that a blind person will never use a site that sells books, but this is far from being the truth. What if this person wants to buy a present for a friend? Can you afford to exclude him?

The scenarios you’ll write can affect several aspect of your project.
If you are redesigning a site, for example, you may decide to exclude previously written content from your site (because it’s totally non accessible) or to convert it in accessible format. This can have a huge impact on costs, so you have to take this decision at this early stage.
If you are evaluating a CMS, you may decide to adopt it or not depending on its support of accessible tags (you may even decide to build your own). What about your content providers? Do they have the required skills to produce accessible content or do they need training?

Conceptual Design

What’s In This Phase

Here you need to define the workflow and information architecture of the site. You will describe the way users interact with your site, how they move through the pages and how they achieve their goals. In this phase you will also structure, organize and label the content of you site, design the search functionalities and last but not least, define the navigational paths.

How Web Accessibility Comes Into Play

The purpose of this phase is to present an interface so that the user can easily use the site and find out what he’s looking for. Accessibility shouldn’t be taken for granted, just remember that you have to address specific needs.

A person affected by dyslexia, for example, may find it difficult to understand the labels you used for the menu bar. For the same reason, limit the number of items on a list and limit the length of a page as well.

On the other hand, a blind person using a screen reader lacks an overall picture of the page, so you have to organize content in a way that can provide him a short summary of what he can find. In this sense an effective search functionality is extremely important because a blind person can’t scan the page and will generally trust the first results he receives (usually, we all do).

A word of caution: don’t design an alternative text-only version of the site: disabled people are not second class citizens; they can and have the right to experience the same page as you do. Don’t forget that web accessibility is an additive process: you have to add things (accessible tags and attributes), not get rid of them. You can read more in an interesting article by Usability Infocentre.

Prototyping and Production

What’s In This Phase?

As you can imagine, this is the core phase. Here you build graphics and HTML templates, develop all the needed software applications and write the content for the site.

How Web Accessibility Comes Into Play

This phase is deeply affected by accessibility issues.

Graphic Templates

A web designer will translate inputs coming from the preceding phase into something that’s visually appealing. You are surely aware of the constraints about a graphic template that will eventually be translated in HTML by a web developer. But this is not enough. You have to know how to meet a disabled person’s expectations. Here is a non-exhaustive list of things to keep in mind:

  1. try not to use graphics for menu and forms if text can suffice (and, most importantly, don’t use small text on these graphics)
  2. use legible fonts
  3. don’t use small graphics if they are linked (they can be difficult to click)
  4. do not create precision layouts that need to be translated in HTML as fixed pages, prefer liquid layouts
  5. avoid using colors for meaningful descriptions
  6. use high contrast
  7. avoid hiding menu items (that will be rendered using DHTML or applets)
  8. don’t get rid of submit buttons in forms (that will require Javascript)
  9. provide enough space for accessibility-related items (transcripts, D links, skip navigation links, form labels, accesskey descriptions). In other words: don’t design to the pixel
HTML Templates

The work of a web developer is fundamental for assuring the required level of accessibility. The best choice is by far the adoption of standard such as XHTML and CSS (also for layout), but an accessible site can be built also with simple HTML. Whatever is your choice, the code must be valid. This means that you need the help of the graphic designer, because if they have built a very precise, complex and fixed template, you’ll have a hard time reproducing it using only valid markup.

When you build an HTML template you have to use all of the tags and attributes available regarding accessibility:

  1. when coding forms, use a rich set of tags to enhance accessibility
  2. make sure that all meaningful graphics have text equivalents
  3. don’t use DHTML, Javascript or Applet if it’s not strictly necessary (and if you use them, provide alternate access to the information)
  4. include links that a user can click to skip repetitive regions of the page
  5. use the right markup (don’t leave h1h6 on the shelves, use them)
  6. the page has to be read also if CSS are turned off
  7. use relative font size so a user can easily change them from the browser interface
  8. create a logical tab order through links
Application Development

Every application used for publishing content on the site has to accept accessible input and has to produce accessible output. This is especially important for applications like CMS.

If this system doesn’t accept alternative text and descriptions for multimedia (input), the page generated can’t be considered accessible. On the other hand, if it produces a questionnaire using non standard HTML or without description labels, the page can’t still be considered accessible. This is a key point for the accessibility of a medium/large scale web site.

You can spend a lot of time and energy developing accessible templates and content, but if the system doesn’t manage them, all your efforts will be vanished.

Content Development

As a content manager, you need specific skills to produce accessible content. First of all, you need to know how to write for the web, because this skill is strictly related to web accessibility: use a clear and simple language, write short sentences, use the active form whenever possible, and so on. You can find a valuable resource reading Hot Text – Web Writing That Works.

Concerning web accessibility, the list of things to consider seems intimidating:

  1. provide alternative text for images
  2. write audio captioning and transcription
  3. write video subtitling, captioning and transcription
  4. insert data table supplementary information
  5. use the right markup (paragraphs, heading, titles, keywords)
  6. produce content that validates
  7. use the title attribute whenever is applicable
  8. specify changes in natural language

The above are the minimum requirements, but a good content manager needs to possess a general understanding of semantic, so that content can be organized, archived and presented to the user in different ways.

Testing and Launch

What’s In This Phase?

Applications are evaluated to test their adherence to specifications and initial requirements.

How Web Accessibility Comes Into Play

Web accessibility of the entire site can’t be evaluated using automated applications, such as Bobby and A-Prompt. Yes, these tools can give you some suggestions and catch macroscopic errors, but testing accessibility is a human intense task.

Depending on your site, on your content and on your audience, your accessibility level can vary. Using different browsers such as screen readers, voice browsers, or text-only browsers, try to use your site keeping in mind your audience and their goals. Moreover, with the evolution of technology, be ready to refine your accessibility in the future and limit the use of "ad interim" solutions.

Maintenance

What’s In This Phase?

New content is added, new applications are built, new sections are opened.

How Web Accessibility Comes Into Play

Never forget that you have to check all your new initiatives with an eye towards accessibility. The risk is to slowly lose the accessibility of your site by way of non-accessible content, templates and applications. Every modification to your site, no matter how small, needs to be tested for accessibility.

You can’t imagine how easy is to transform an accessible site into an inaccessible one.