As a user-centric strategist, I’m always on the lookout for business practices that improve on a standard experience. So I took note the last time I went to Uncle Moe’s, a Mexican restaurant near the Ai office.
Uncle Moe’s has a typical sandwich-shop production line, like Subway for Tex-Mex food. I ordered my sandwich and answered the requisite questions down the line: guacamole, please; no sour cream, etc. My sandwich passed from the welcome guy to the component guy to the cashier, who announced, “Seven thirty-two.”
All normal–except none of the employees said anything to each other. No calling down the burrito’s name, no questioning from the cashier to the team. My meal was wrapped in foil without any notes attached to it.
Confused, I asked the cashier how the heck he knew what I had ordered. He smiled and showed me this card.
Uncle Moe’s has a code and a visual for each of its sandwiches. The greeter uses a China Pencil to mark each order that comes in, and the card moves down the production line with the sandwich. The cashier can ring up an order at a glance. The card is then erased and used again.
This system is subtle and ingenious. Uncle Moe’s is small, and the card reduces unnecessary noise. With a rapid-fire production system, the card ensures orders are filled and charged properly. And the dry-erase card eliminates the need for paper, reducing waste.
UX folks in Manhattan would enjoy checking out Uncle Moe’s. I recommend the Watsonville, hold the sour cream.
Tom is Ai’s front-end tech lead.
The following is a developmental check-list I religiously adhere to and find extremely essential in ensuring semantic-rich, accessible and valid (x)HTML.

Da Basics
- Specify a
DOCTYPE and namespace
- Specify the document’s language
- Write your markup before writing any CSS to ensure your HTML is semantic and well-formed
- Document your HTML with start and end comments for clear separation of layout blocks within your markup
-
Make sure the page validates (x)HTML
- 1.0 Strict for all new development
- Transitional for legacy applications using HTML flavors from the past
- Make sure the page
title is set
- Include all necessary
meta tags
- Use block and inline elements appropriately
- X-browser/X-Platform the page
- Separate blocks of content with a
div
- KEEP ALL ATTRIBUTES AND THEIR VALUES LOWERCASE…KICKIN’ IT OLD SKOOL IS COOL, BUT NOT THIS WAY
Presentation and Content — Keep ‘em Separate
-
Make sure your markup is semantic in that proper elements are used in which their purpose was intended
- Layout =>
div
- Headings =>
h1 through h6
- Paragraphs =>
p
- List of items =>
ul, ol
- Content emphasis =>
em, strong
- Tabular/grid data =>
table
- The presentation of content should be consistently applied regardless of CSS
Name Your Children With Some Structure
-
Name your ID’s and classes based upon the structure of its content, not presentation
content_head
content_main
sidebar
navigation_main
navigation_secondary
logo
header
footer
- This will prevent renaming if the content’s look and feel changes
Headings Schmedings
- One
h1 per page
- Maintain the hierarchy,
h1 -> h2 -> h3 … h6 regardless of how cosmetically they may appear in design
Pretty Pictures
- Every image must contain a non-empty alt tag
- Dimensions on every image
- Keep images used for photographical purposes inline, not as background images
I Call ‘em Links, Anchors are for Boats
- Include title attributes on important links and/or graphical links containing no text in the image itself that describes the destination of the link
- Make sure there is always text present within the anchor even if it is a graphic
- The text should be informative, ie – use ‘close’ rather than just ‘x’ for a close button
Fontography
- Try to avoid all caps within markup and allow CSS or emphasizing elements to properly transform text so you have the option of reverting if needed
- Don’t abuse the
br tag, using multiple consecutively isn’t necessary, just begin a new block level element
Set the Table, Anthony, and Don’t Forget the…
caption element to let users know what your table is about (look at it as short headline)
- summary attribute to further describe your table’s contents in more detail
colgroup‘s for multi-column tables
th‘s for column headings
thead for table heading content, tfoot for table’s footer content and tbody for the main body of the table’s grid content
tfoot comes before the tbody in the markup…don’t ask me why
- And for pete’s sake, don’t use tables for layout, that’s so 1999
Forms (Don’t Have Anything Cute for this One, Sorry)
- Don’t forget the action and method attributes (leave em blank if you don’t know, leave that mush to the back-end dude)
- Have a
legend to set the title of the form
- Use
fieldset‘s to group related fields
- Use
div‘s for further content separation within fieldset‘s
tabindex on each input for easy keyboard accessibility
- The corresponding text for each input should be a
label with the for attribute set to the input‘s ID
maxchar set on inputs where necessary to assist with validation