W3C

Yet Another Design in W3C Team

Working at W3C is an interesting experience. The Team is usually composed of 60 to 70 persons, with the possibility to edit mostly all parts of the Web site which is under cvs (thank you for giving the possibility of digging back old pages.). People from the staff have different levels of experience with regards to Web design and different perspectives.

  • some people care only about information and content
  • some will care about the structure
  • some will have in addition a sensitivity for design

Everyone has write and read access on the content, the style, etc.

I would love to know from the Web designers/webmasters who are following this weblog, what are the techniques they used to keep the look and feel of a web site shared between multiple people with full access. Guidelines? Templates? Social Engineering? Checkers? “Use a CMS” is not the answer.

5 thoughts on “Yet Another Design in W3C Team

  1. In the work I do, large websites have a specific role assigned to each person. This is based on what each person is best at.

    From the start of a project:

    1. Good information architects (IA) figure out how things should be organised and what types of pages are needed. They create a list of areas the site will have and describe what should go in them.
    2. Good designers (visual and interaction) figure out how this should be presented. They create pictures (usually called “visuals”) showing exactly how each type of page should look.
    3. Front-end developers (like me) decide how the visual should become actual pages. We then create the HTML, CSS and graphics for one instance of each type of page. These are called the “templates”.
    4. Good programmers, database designers and other engineers figure out how these templates should work (sometimes grouped as “back-end developers”). They build systems which wrap the templates around content. They provide a front-end for authors to add new content. Sometimes they provide a repository where authors get the templates from.
    5. Authors either use the database system front-end to write content or they use the repository and fill in the content area as they wish.
    6. People good at Quality Assurance (QA) keep an eye on what the authors are adding to the site. This includes keeping design consistent between departments, ensuring accessibility standards, editing typos and poor writing, so on. Often authors’ work must be approved by a QA person before it “goes live” for the public to read it.

    All these groups communicate with each other as necessary. As examples:

    • QA person specialises with writing. Helps train authors about writing for the web.
    • Front-end developer knows about the current generation of web browsers. Talks to the designers about what effects are feasible.
    • Author wants to start a new area. Talks to IA people about where it should go. Interaction designer helps decide what to call it and whether the navigation bars should change. Visual designer works out how any changes should look. Front-end developer updates the templates. Back-end developer adds the new area to the system or updates the repository.

    By letting each person work on the thing they are best at, and to some extent control it, quality is kept high for every aspect. It also means nobody is given more work than they can handle.

    Having high quality templates and good communication between all groups are the key aspects, imho. And I really like the design improvements W3C are making to areas like this blog.

  2. Guidelines? Templates? Social Engineering? Checkers?

    yes, yes, and yes. in addition, i find that one of the most important things is to explain to the various authors what the corporate guidelines and style guides are, why they’re important, and how they can implement them. regardless of any technological or managerial systems, if people don’t like or understand the consistent look and feel a company is trying to portray, they’ll always find a loophole or simply attempt to ignore it…which then demands convoluted QA processes to catch and rectify breaches. i remember a time when one of the major reasons for moving to a CMS in our company was “so we can lock down and control the look and feel”. a CMS is not a tool of compliance to foist onto authors. and again, they’ll simply try to find loopholes (e.g. starting to simply link out to other, non-CMS pages they maintain directly, or sprinkling iframes and font elements into any raw markup fields that then have to be locked down even further). so, first and foremost, people need to want to follow the CI/style.

  3. Yes you must have people working on a site that share a common vision, and it is hard to find that but fortunately you are working at W3C and not a big commercialized company where advertisers and management want to use such and such flash application to show all the content or something. Things could be worse.

  4. I´m wondering that all members have full access to the W3C site, especially when you said that the staff have different levels of experience. If you don´t want to use restrictions, it is necessary to make persons responsible for parts of the site, like content(parts), design, …. It is also important to have guidelines which makes it easier for new members to work with the site.

Comments are closed.