Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Jason Withrow ([email protected])
Creating a Web Style Guide
Jason Withrow ([email protected])
Overview• Introducing Style Guides• The Value of Style Guides• Issues with Style Guides• Style Guide Development Process• Writing the Style Guide• Rules for Interface/Interaction Design• Rules for Form Design
Jason Withrow ([email protected])
Web Style Guides: A Broad Focus• Traditionally, a style guide was focused on
rules for writing and verbal expression • While writing is one part of a Web style
guide, we need to look more broadly (the Web is much more than a book):– Interface design– Fonts and other aspects of visual presentation– Interaction issues, such as form validation and
error handling, launching a new window, etc.
Jason Withrow ([email protected])
The Developer’s ‘How To’ Guide• Think of a style guide as a ‘how to’ guide for
the development team– Used primarily for development and
maintenance purposes– Created along with use cases
• Authored by business analysts, the target audiences are typically: – Programmers / Coders– Graphic designers– Any other interested stakeholder
Jason Withrow ([email protected])
Style Guide Content: Sets of Rules• Each instruction/guideline in the style guide
is referred to as a rule• Rules are grouped at a high level based on
core categories/aspects of the website– Within those core groupings are sub-groupings
used to cluster rules at a more precise level– As there are often a number of rules, breaking
them down into these smaller groupings speeds up the process of locating a desired rule or sub-group of rules
Jason Withrow ([email protected])
Choosing Top-Level Categories• Depends primarily on the scope of the style
guide; the ‘correct’ categories are ones that divide the content up in a meaningful way.
• Is the goal:– To describe the ins and out of form design on
the website?– To be a general interface/interaction style guide,
considering a wide range of issues?– Focused on a specific web application, so
content is tailored to that specific functionality?
Jason Withrow ([email protected])
Audience Considerations• Ideally, a style guide addresses all the
questions raised by the programmers and graphic designers (or other members of the development/site maintenance team)
• Stated bluntly, the goal is to prevent the programmers from doing interface and interaction design by giving explicit rules– For the graphic designers it is more about
restraining any ‘creativity’ during development that introduces design inconsistencies
Jason Withrow ([email protected])
Life Without a Style Guide• As each programmer is coding and
gets to an undefined aspect of the layout, two things can happen:
1. They consult with the business analyst or graphic designer or
2. They decide to ‘wing it’• Sadly, the second option is often the
one chosen. Across multiple programmers this is quite a mess.
Jason Withrow ([email protected])
The Limits of a Mockup/Storyboard• Mockups and storyboards can only get
developers so far, because they display a static image
– Compared to mockups the storyboards are more useful, but in both cases relatively few specific details (e.g., font sizes) about the interface are conveyed
– Not every page has been mocked-up or storyboarded (storyboards show more screens than mockups, so are more useful)
Jason Withrow ([email protected])
A Document for Future Teams• Over time websites will often change
‘ownership’, in terms of who is in charge of site maintenance/additions– Due to team members changing jobs, layoffs,
new hires, organizational restructuring, etc.• A very real danger is that the new team will
not have sufficient information to keep the design and interaction consistent
• The style guide conveys the guidelines necessary for consistent design over time
Jason Withrow ([email protected])
Also Useful with a CMS• Even using a Content Management
System, which automates publishing with a series of layout templates, there are questions that arise:– What situations call for a 2-column layout?– What situations call for a 3-column layout?– When can boldface and italics be used?– When should headings be used?– What capitalization style should be used?– What rules govern creation of a new template?
Jason Withrow ([email protected])
Relationship to Other Deliverables• Various tie-ins exist with other deliverables:
– Functional Specifications (detailing how specifications will be visually displayed, although rules are generic and specifications are highly specific so it is not a 1-to-1 relationship)
– Technical Specifications and Personas(ensuring that specifications are met and that the needs of personas, such as font size scaling for low vision users, are also met)
Jason Withrow ([email protected])
Relationship to Other Deliverables• Various tie-ins exist with other deliverables:
– Mockups and Storyboards (providing details such as fonts to use, font sizing, use of white space between sections of content, etc.)
– Other deliverables?
Jason Withrow ([email protected])
The Value of a Style Guide• Increased consistency (especially when
multiple authors are involved)– Makes the site look more professional
• Improved efficiency– Due to fewer questions from developers
• Fewer errors– Reduces development costs
• Less confusion when the site is ‘turned over’ to another group
Jason Withrow ([email protected])
Issues with Style Guides• Political concerns
– These arise because so many individuals are potentially impacted by the style guide
– The big question: Will they use the style guide?– May need buy-in at various levels of the
organization• Time and cost
– To do these well takes careful planning– Not just text; good style guides include visual
examples as well
Jason Withrow ([email protected])
Issues with Style Guides• Iterative looping
– Simply put, you might not get it right the first time through
– During production it becomes apparent that some things look good on paper but don’t work well when implemented
– ‘Fixing’ rules during production requires going back to earlier code and changing it, but at least future production should be free from errors and (hopefully) further changes
Jason Withrow ([email protected])
Style Guide Development Process• The topic covered by a style guide can be
as broad or as narrow as desired:– Focused just on form design– Considering the entire website interface and
interaction design– For specific web-based applications– Dealing with internationalization of a website– For hand-held devices– Other topics?
Jason Withrow ([email protected])
Development Timeline• The style guide needs to be developed prior
to the interface being coded• Tailor rules to the specific client needs, but
keep in mind that you could generalize the rules to all forms, or all hand-held devices, and then use the guide on other projects
• If you develop a general-purpose style guide (one not tailored to a specific client) you could also use screenshots from websites showing desired practices
Jason Withrow ([email protected])
Finalizing the Style Guide• Final changes to the rules will need to occur
prior to launching the website or web application; at that point the site (and style guide) are turned over to other parties– This could be the client (if they are doing
maintenance)– It could be another group inside MCIT– Or it could be your own team
Jason Withrow ([email protected])
Writing the Style Guide• Start with a cover page
– If done in landscape mode with 2 columns the title/website name/author name/version number could be on the left-hand side and the table of contents could be on the right-hand side
• Begin the content by noting:– The target audience for the document– The purpose/function of the document– See the sample style guide for an example
Jason Withrow ([email protected])
Phrasing Rules• Write these as instructions, which means
conveying a tone of authority and being direct
• Be firm in your phrasing– Avoid ‘probably’, ‘usually’, ‘often’, ‘sometimes’,
‘maybe’ or any other hedging terminology• Maintain third person and the active voice• Never phrase rules as questions
Jason Withrow ([email protected])
Presenting Rules• Rules should be shown in boldface• Additional explanatory text following the rule
should be in the same paragraph and should not be boldface
• Groups and sub-groups of rules are numbered similarly to site diagrams– e.g., 2 leads to 2.1 which leads to 2.1.1– These will mirror the numbers given in the table
of contents
Jason Withrow ([email protected])
Uses of Explanatory Text• Useful for noting what exceptions might
occur with the rule when it is implemented. – The rule itself should not indicate the exception.
• Used to clarify why a rule is necessary. – This can educate the client and/or developer
concerning usability.• Should not be included with every rule.
– Only include when further details are deemed necessary. Some rules are self-explanatory.
Jason Withrow ([email protected])
Including Examples & Illustrations• For some rules you will find yourself writing
a paragraph. While brevity is good, there are times when you need multiple sentences to convey precise instructions.– In those cases it is probably good to also
include an example, generally a visual example of the rule being implemented.
• Visual examples are recommended any time when implementing the rule could get confused or mixed up in some way
Jason Withrow ([email protected])
Providing a Caption• Examples/illustrations should always have a
caption, which is centered below the image.• Insert the image in the flow of the
document, ideally just after the pertinent rule(s).
Jason Withrow ([email protected])
Sample Illustrations
Jason Withrow ([email protected])
Multiple Rules Per Item• For a given item (e.g., ‘Required Fields’)
there can be as many rules as are necessary. Don’t limit yourself.– It is better to chunk rules realistically and try to
ensure thorough coverage of the domain• Rules are not prioritized; they are
considered to be equally important• There will be cases where some aspect of
the website is detailed under multiple categories, using a wide variety of rules
Jason Withrow ([email protected])
Rules for Interface/Interaction Design• Top-Level Categories:
– Layout– Navigation– Text– Form Interaction
Jason Withrow ([email protected])
Layout Sub-Categories• Page Layout
– Header– Body– Footer
• Form Layout– Chunking– Starting the Form (e.g., introductory text)– Alignment– Grouping– Required Input
Jason Withrow ([email protected])
Navigation Sub-Categories• Global Navigation• Local Navigation• Technology• Graphics (e.g., use of alt text, using text
links or a graphical navigation bar)• Linking (e.g., unlinking/boldfacing the link or
button for the current page)
Jason Withrow ([email protected])
Text Sub-Categories• Fonts• Technology• Sizing
– Page Headings– Section Headings– Body Text– Secondary Text
• Capitalization• Color
Jason Withrow ([email protected])
Text Sub-Categories (cont.)• Emphasis
– Boldface– Italics– Underlining
• Graphical Text• Link Text
– Link Phrasing– Length
Jason Withrow ([email protected])
Text Sub-Categories (cont.)• Alternative Text• Introductory Text• Examples
Jason Withrow ([email protected])
Form Interaction Sub-Categories• Technology• Tab Ordering• Buttons (e.g., submit, reset, radio)• Checkboxes• Text Input Fields• Menus• Required Input• Input Validation• Action Confirmation
Jason Withrow ([email protected])
Rules for Form Design• Top-Level Categories:
– Form Planning– Layout– Text Appearance– Fields– Submission– Multi-Page Forms
Jason Withrow ([email protected])
Form Planning Sub-Categories• Content Chunking• Technology Considerations• Providing Examples
Jason Withrow ([email protected])
Layout Sub-Categories• Starting the Form• Field Labels and Input Fields• Buttons• Providing Examples
Jason Withrow ([email protected])
Text Appearance Sub-Categories• Fonts• Technology• Sizing• Capitalization• Emphasis• Examples
Jason Withrow ([email protected])
Fields Sub-Categories• Required Fields• Types of Input Fields• Standard Elements• Tab Ordering
Jason Withrow ([email protected])
Submission Sub-Categories• Submitting the Form• Validation• Confirmation
Jason Withrow ([email protected])
Multi-Page Forms Sub-Categories• Displaying Prior Information• Modifying Prior Information• Submit Button Labeling