[play.webdev] Re: Playground Web Development Standards
- From: "Paula Skaper" <pskaper@xxxxxxxxxxxxxxxx>
- To: <play.webdev@xxxxxxxxxxxxx>
- Date: Fri, 24 Oct 2003 16:53:43 -0700
Thanks Chris. P
-----Original Message-----
From: play.webdev-bounce@xxxxxxxxxxxxx
[mailto:play.webdev-bounce@xxxxxxxxxxxxx]On Behalf Of Chris McGrath
(PLAY)
Sent: October 24, 2003 4:34 PM
To: 'play.webdev@xxxxxxxxxxxxx'
Subject: [play.webdev] Playground Web Development Standards
Hey all,
Here's the Playground Web Development Standards with your changes
integrated. Please let me know if you'd like to see any other changes.
Unless something is described as a 'recommendation', we'd like you to adhere
to these standards unless you first discuss it with the Playground web team.
I really appreciate everyone's help and support on this. Look forward to
hearing any comments!
Chris McGrath
Internet Systems Analyst, Team Lead
Playground
Playground Web Development Standards
-------------------------------------------------------
100% usable means this:
Use proven navigation systems
Avoid confusing browser behavior
Use high visibility text
Write for scannability
Always use ALT tags
Code layouts that display and print well on all systems
-------------------------------------------------------
Zero wait time means this:
Design for low-bandwidth
Use images and tables judiciously
Use robust infrastructure
Program efficiently
-------------------------------------------------------
100% compatible means this:
Test, test, test
Avoid plug-ins
Use caution with CSS & client-side scripting
-------------------------------------------------------
Zero downtime means this:
Keep it simple
Carefully plan deployment
Use change management
Monitor servers
-------------------------------------------------------
100% well-coded means this:
Code by hand
Document and comment
Adhere to standard programming conventions
Use only Microsoft technologies for coding
-------------------------------------------------------
Standards for 100% Usability
-------------------------------------------------------
Usability testing. Conduct regular usability tests. Watch four or five users
perform tasks with the web site. Make changes based on observations, then
test again. Usability testing is a key component of all new web initiatives.
Search. Have a search function on every site. Search should be prominently
located on every page. The results should be easily readable-carefully
author page titles to maximize scannability. Exceptions: Sites under 50
pages.
Back button. Don't break the back button. The back button is a heavily used
feature of every browser. Don't break it with frames, plug-ins, or
client-pulls.
Navigation. Use proven navigation systems. Users spend the majority of their
time on other sites. Use the same navigation solutions used on major web
sites: tabs, like Amazon.com, categories in the middle, like Yahoo!, links
across the top, like intrawest.com, or left navigation rail, like cbc.ca.
We recommend avoiding dynamic pop-up menus. We recommend only one link to
each page--not multiple navigation paths to the same information. For
usability research on these two issues, see:
Reduce Redundancy - http://www.useit.com/alertbox/20020609.html
Drop-down Menus - http://www.useit.com/alertbox/20001112.html
Windows. Don't launch new windows. Users expect links to open in their
current browser window. Launching a new window breaks the back button and
confuses the user. Also avoid pop-up windows, which users find irritating,
often assuming they are advertisements. Exceptions: Help windows, and
windows where there will be no further navigation (video/ animation windows,
photo galleries, etc.). They must be launched at a reduced size so the user
recognizes that a new window is open.
Frames and iFrames. Don't use frames. They produce unexpected behavior with
the back button, they make bookmarking difficult, they reduce search
capabilities, and they cause printing problems. They also slow the site down
and create code maintenance headaches. Avoid using iFrames unless there is
really no other way to achieve the desired functionality.
Text. Use high-contrast text that is big enough to be read by the over-50
crowd. 16px is recommended, and 13px the minimum for body copy. 13px is
recommended for small print, and 10px the minimum. We recommend using
relative text sizing (i.e. 115%, 83%) so users can change text size in their
browser. Choose high-contrast colors (i.e. black on white) for maximum
readability. For graphic text, make it large enough to be readable by the
over-50 crowd.
Scannability. Make the text scannable. Use lists, bullets, bolding and
careful hyperlinking to make it easy to quickly scan the page and find the
important information.
ALT tags. Always use ALT tags for images. To aid users with visual
impairments, ALT tags should verbalize the meaning or role of the image in
the dialogue.
Meta tags, Title tags. Write a short, unique, descriptive TITLE tag for
every page in your web site for search engine ranking and bookmarking. Write
meta tags to improve search engine indexing.
Layout. We recommend a liquid layout. Liquid layouts resize to fit large or
small monitors, and they print equally well on Letter or A4 paper. Whatever
your layout, it must print properly without truncating text.
Link colours. Use a different colour for visited and unvisited links. The
unvisited colour should be "hotter" than the visited colour.
-------------------------------------------------------
Standards for Zero Wait Time
-------------------------------------------------------
Page size. Keep page size under 50K; under 30K if possible. Research shows
users lose interest after 10 seconds, and only response times under one
second are perceived as instant.
Number of images. Use 15 or fewer unique images per page. This includes
images for text or navigation. Every image requires another request to the
server, slowing response time.
Tables. Avoid nested tables. They can't be displayed until all parent tables
load. Avoid long tables. They can't be displayed until they completely load.
Break long tables into smaller, unnested tables. Avoid overly complex table
structures. Tables must be decipherable by follow-up coders.
-------------------------------------------------------
Standards for 100% Compatibility
-------------------------------------------------------
Browser compatibility. Build for backwards compatibility to IE 5 and
Navigator 6.
Flash compatibility. Build for backwards compatibility to Flash version 5.
Plug-ins. Avoid use of plug-ins. Only use plug-ins if there is no other
possible way to communicate the information-i.e. a video walk-through of a
home. If it is decided that a plug-in must be used, also make the
information available in an alternate format-i.e. a transcript of a video,
or a collection of photos from the interior of a home. Only use the most
common and widely supported plug-ins.
Testing. Test, test, test. Eliminate compatibility issues by testing every
new web site on a wide variety of browsers and operating systems, both PC
and Mac.
DHTML/ JavaScript. Use caution when using DHTML and JavaScript. They produce
compatibility problems on some browsers. Test thoroughly, and explore other
options first.
CSS. Restrict use of CSS to the most common elements like specification of
fonts. CSS implementation is inconsistent across browsers.
-------------------------------------------------------
Standards for Zero Downtime
-------------------------------------------------------
Simplicity. Keep web site simple. Avoid new technologies, new programming
languages and new plug-ins until they are proven, until they have gained
widespread acceptance and until there is a demonstrated business need.
Monitoring. Use an external monitoring service to confirm site availability.
Developer should be contacted immediately if a site fails to respond.
Development and Staging server. All development work should be done only on
the development box, and never on the staging or production server. The
staging server is a perfect mirror of the production environment, and is
used for final testing before moving into production. Exceptions: Atomz
Publish can update files directly to production. Changes to data in a
database can be made on production. Staging environment to be ready in
December.
Change management. Use change management process to move code into
production. Change management process includes a code review and back-out
plan, and ensures uninterrupted access to the web site. Exceptions: Atomz
Publish is exempt. Changes to data in a database are exempt. Change
management process to be implemented in January.
Contingency planning. Have a disaster plan. Have strategies for quickly
restoring full or at least partial access to web sites in the event of
natural disasters, hardware failure or application breakdown.
Playground web server. All web sites must be served by the Playground
Enterprise Hosting web environment.
-------------------------------------------------------
Standards for 100% Well-coded
-------------------------------------------------------
Server-side validation. Always perform server-side validation on forms,
whether or not you do client-side validation.
Hand-coding. HTML should be hand-coded. If using machine-generated code
(i.e. Dreamweaver/ Fireworks), it must be cleaned up by hand.
Use tables instead of layers. For core page layout, use tables and not
layers.
Documentation. Document and comment your code. All scripts and HTML files
should start with a description of their purpose, unless completely obvious.
Where possible, document what the script requires as input, what it does and
what it outputs. Also include this type of description at the beginning of
each function and subroutine. Comment liberally to explain portions of code
that are unclear.
Diagrams. Prepare diagrams for complex databases and architecture. Help
future coders and network architects to visualize complex structures.
Directories. Logically divide content into directories. Images, downloads,
includes, stylesheets and JavaScript should be kept separate from HTML and
ASP files. Keep files out of the root. Physical directory structure should
mirror what users see on your site. Exceptions: Physically structure of
sites under 20 pages does not necessarily need to mirror logical structure.
Naming conventions. Name directories, files, images, variables and
subroutines carefully. Names should be very descriptive. Names of
directories and files should be lowercase with no spaces or dashes
(underscores okay).
Back-end technology. Use Microsoft technology. Intrawest and Playground have
a heavy investment in Microsoft technologies and infrastructure. Our
development expertise is with Microsoft products. Web application
development must be in ASP or ASP.Net running on IIS with a SQL Server
database. Purchased applications must run on IIS and SQL Server.
Header, footer, navigation includes. Design your pages so that the header,
footer, navigation and any other common elements can be broken out into
separate, included files.
Atomz Publish. Construct sites from the ground up in Atomz Publish. All
pages should be based on Atomz templates, so global changes can be made
quickly and so the customer can maintain their own page.
Other related posts:
