Hall of Bright Carvings

Most websites nowadays incorporate some kind of community aspect that allows users to provide feedback to the site’s owners and to each other. In fact, ‘building community’ is one of the most important aspects of any modern website. Websites that focus on their community or group nature are described as being social sites, an umbrella term that can cover a great number of disparate services. This article will describe how Developers can utilise social design patterns on a site in order to promote or dull certain behaviours in an online community.

So What is Social Media?

Social Media is a fancy term to describe how people have been using the internet since its inception. Before the web, social media was BBS (Bulletin Board Systems) and multiplayer text based games. More recently the rise of site aggregators such as digg, reddit and metafilter or social aggregators such as facebook, linkedin or myspace are more well known, the social principles behind these sites however, are as old as networked computers. Social Media is community – it’s individuals coming together to share their interests and to engage as people.

So What are Design Patterns?

Design Patterns are common principles that developers use as shorthand to describe a technique they intend to use to solve a given problem. They are a shared terminology that describe an optimal solution to a commonly encountered problem.

How do they fit together?

When developing a site that is supposed to encourage a sense of community it is important to recognise what kind of community you’re trying to encourage. People using your site will end up doing things that you never expected so using design patterns will allow you to nudge your users towards certain types of behaviour that you wish to promote.

This is best illustrated by an example.
Consider a forum designed for people who are interested in talking about carpentry. The topic itself isn’t really important; it could be anyone of the millions of social forums or systems that are designed to encourage community interaction over a specific topic. When the forum is first created it may quickly fill with people who are excited and enthused to find likeminded people, many conversations start covering thousands of aspects of carpentry and related topics. Time progresses and posts grow more detailed, broad topics are narrowed into specific subjects. People begin to recognise distinct individuals; personalities emerge and direct conversations in their own ways. Topics that previously had created debate and interest have now been discussed over and over, people begin to grow disillusioned with the cyclical nature of the conversations they are having, conversations that have little or nothing to do with carpentry become the predominant topics. New users feel lost and confused at the lack of carpentry discussions and when they try to start new topics about dovetails and joins are shouted down by older users who are tired of the same conversation happening again and again, pointing to various past discussions the new user can find the information they want. The community begins to disintegrate into factions of users, splintering between old and new, carpentry purists and people more interested in maintaining the personable conversations between people, and often, between administrators and users. People begin to leave and a once vibrant online community fades away, not with a bang, but with a whimper, a few remaining souls lingering until the system administrator finally turns the power off on the servers.

The number of online communities that have experienced that life-death cycle is beyond counting. It has occurred since the internet’s inception, it’s been occurring for so long and so often that it’s possible to see the similarities inherent in every one of them – to map the patterns and to track the changes that work to make sure that the self-destruction doesn’t occur. Navigating this user-cycle can be a delicate game, but it is possible to implement patterns that give a social site the best possible chance to survive.

How do we implement Patterns that work?

The first step to implementing patterns that work, and through them, a community that will survive long term use, is to determine what kind of community you wish to encourage. Certain kinds of patterns will help promote certain kinds of behaviour. Patterns such as ‘Reputation’ can help foster a sense of competition between users, which can be beneficial, but can also be detrimental if you’re not attempting to cultivate a competitive spirit. Likewise, providing users with a advanced options to create unique and personalised identities with a ‘Profile’ pattern can result in improved user engagement and personal investment, but can also lead to users being more concerned with their personal identities on the site than producing content for consumption. Being aware of how different patterns influence behaviour allows developers to implement the right solution to reach the right result for you and your users.

This is kind of where the ARIA stuff gets a bit more confusing. Landscape and widget roles are kind of common sense for the most part. The states and properties however can be pretty damn specific and it’s actually quite difficult to gat clear information on how best to use them. The W3 best practices does its best, but personally I find W3 documentation incredibly boring to wade through.

Until the spec moves beyond work draft however, it’s probably not in anyones best interests to try and capture massive amounts of information that’s liable to change dramatically. The W3 Supported States and Properties is probably the best source for information at the moment.

Basically there are two ‘types’ of roles. ‘Landmark’ which allow assistive technology to provide context to a user, and what can generally be thought of as ‘widget’ roles, which help users of Assistive Technology (AT) navigate and utilise more specialised parts of a web page such as menu listings, tab navigation or alert popups.

The following is a list of WAI-ARIA landmark roles.

• application A region declared as a web application, as opposed to a web document. On a practical level this tells AT to stay in ‘focus’ mode which works a little differently to its standard mode.
• banner A region that contains the primary heading or web site title.
• complementary A supporting section of the document that remains meaningful even when separated from the main content.
• contentinfo Metadata that applies to the parent document.
• main The main content of a document.
• navigation A collection of navigational elements (usually links) for navigating the document or related documents.
• search The search tool of a web document.

There’s a bit of overlap between some of the landmark roles and HTML5, but don’t worry about it. The Assistive Tech guys apparently haven’t even come to the table to discuss HTML5 yet but they are actively implementing landmark roles and providing users ways of navigating them so even if you’re using HTML5 now it’s probably a good idea to add the ARIA roles to them as well.

Landmark roles can be added straight to the HTML markup without any problems, in fact in a lot of cases the browser doesn’t even need to understand them (IE6-7 for example don’t have a clue about ARIA) as several AT readers are capable of using them anyway. (JAWS10 for example will provide landscape navigation in IE6 if the roles are available).

Widget roles are different though and should really only be added by javascript:

node.setAttribute("role", "value");

This is because you’re usually adding widget roles because you want to perform some kind of extra functionality and it would be confusing to an AT user if they encountered a block of markup assigned a certain role that didn’t function as expected because they had javascript off.

The following is a list of WAI-ARIA widget roles.

• alert A message with important, and usually time-sensitive, information. Also see alertdialog and status.
• alertdialog A type of dialog that contains an alert message, where initial focus goes to the dialog or an element within it. Also see alert and dialog.
• article A section of a page consisting of an independent part of a document, page, or site.
• button An input that allows for user-triggered actions when clicked or pressed.
• checkbox An checkable input that has three possible values: true, false, or mixed.
• columnheader A cell containing header information for a column.
• combobox A presentation of a select; usually similar to a textbox where users can type ahead to select an option, or type to enter arbitrary text as a new item in the list.
• composite (abstract role) A widget that may contain navigable descendants or owned children.
• definition A definition of a term or concept.
• dialog A dialog is an application window that is designed to interrupt the current processing of an application in order to prompt the user to enter information or require a response. Also see alertdialog.
• directory A list of references to members of a group, such as a static table of contents.
• document A region containing related information that is declared as document content, as opposed to a web application.
• grid A grid contains cells of tabular data arranged in rows and columns, like a table.
• gridcell A cell in a grid or treegrid.
• group A set of user interface objects which would not be included in a page summary or table of contents by an assistive technology.
• heading A heading for a section of the page.
• img A container for a collection of elements that form an image.
• input (abstract role) A generic type of widget that allows user input.
• landmark (abstract role) A region of the page intended as a navigational landmark.
• link An interactive reference to an internal or external resource.
• list A group of non-interactive list items.
• listbox A widget that allows the user to select one or more items from a list of choices.
• listitem A single item in a list, listbox, or directory.
• log A type of live region where new information is added in meaningful order and old information may disappear. Also see marquee.
• marquee A type of live region where non-essential information changes frequently. Also see log.
• math An element that represents a mathematical expression.
• menu A type of widget that offers a list of choices to the user.
• menubar A presentation of menu that usually remains visible and is usually presented horizontally.
• menuitem An option in a group of choices contained by a menu or menubar.
• menuitemcheckbox A checkable menuitem that has three possible values: true, false, or mixed.
• menuitemradio A checkable menuitem in a group of menuitemradio roles, only one of which can be checked at a time.
• note A section whose content is parenthetic or ancillary to the main content of the resource.
• option A selectable item in a select list.
• presentation An element whose role is presentational and does not need to be mapped to the accessibility API.
• progressbar An element that displays the progress status for tasks that take a long time.
• radio A checkable input in a group of radio roles, only one of which can be checked at a time.
• radiogroup A group of radio buttons.
• range (abstract role) An input representing a range of values that can be set by the user.
• region A large perceivable section of a web page or document, that the author feels should be included in a summary of page features.
• roletype (abstract role) The base role from which all other roles in this taxonomy inherit.
• row A row of cells in a grid.
• rowheader A cell containing header information for a row in a grid.
• section (abstract role) A renderable structural containment unit in a document or application.
• sectionhead (abstract role) A structure that labels or summarizes the topic of its related section.
• select (abstract role) A form widget that allows the user to make selections from a set of choices.
• separator A divider that separates and distinguishes sections of content or groups of menuitems.
• slider A user input where the user selects a value from within a given range.
• spinbutton A form of range that expects a user to select from amongst discrete choices.
• status A container whose content is advisory information for the user but is not important enough to justify an alert. Also see alert.
• structure (abstract role) A document structural element.
• tab A header for a tabpanel.
• tablist A list of tab elements, which are references to tabpanel elements.
• tabpanel A container for the resources associated with a tab.
• textbox Input that allows free-form text as their value.
• timer A numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point.
• toolbar A collection of commonly used function buttons represented in compact visual form.
• tooltip A contextual popup that displays a description for an element in a mouse hover or keyboard focused state. Supplement to the normal tooltip processing of the user agent.
• tree A type of list that may contain sub-level nested groups that can be collapsed and expanded.
• treegrid A grid whose rows can be expanded and collapsed in the same manner as for a tree.
• treeitem An option item of a tree. This is an element within a tree that may be expanded or collapsed if it contains a sub-level group of treeitems.
• widget (abstract role) An interactive component of a graphical user interface (GUI).
• window (abstract role) A browser or application window.

The ‘presentation’ role is a pretty interesting one as it basically allows for extra markup to be ignored by AT. For example consider the following markup:

<ul role="menu">
	<li>< a href="page1" role="menuitem">Home</li>
	<li>< a href="page2" role="menuitem">News</li>
	<li>< a href="page3" role="menuitem">About us</li>
	<li>< a href="page4" role="menuitem">Contact us</li>
</ul>

The li’s are between the menu container and its associated menu items which means AT wont know to group those items together. Changing the markup to:

<ul role="menu">
	<li role="presentation">< a href="page1" role="menuitem">Home</li>
	<li role="presentation">< a href="page2" role="menuitem">News</li>
	<li role="presentation">< a href="page3" role="menuitem">About us</li>
	<li role="presentation">< a href="page4" role="menuitem">Contact us</li>
</ul>

tells the AT to ignore the li’s which then allows the AT to find and group approriate menus and their items.

Wireframing and prototyping are increasingly important steps in the
development process, they allow you to clearly and definitively establish the requirements for a project before anyone has invested too much into it. They provide clients and developers with a clear and well defined road map of what the project will deliver and what a user can expect when it comes to using the resulting site. In this article we’ll take a look at some of the more common ways Information Architects create wireframes as well as a way for web developers to develop practical, effective and relevant wireframes and prototypes using the skills they use every day.

Traditionally, wireframing sits between gathering client requirements and design. It allows clients, developers and designers to all be clear as to the site structure, page structure and, to a certain extent, the functionality involved in developing the project. Wireframes can be anything from complex prototypes through to a few sketches on the back of  napkin.

Imagine a client who wants to develop a site called ‘Document World’. A place where authors and editors can upload  documents, share resources and collaborate with each other to edit their documents. The client wants the site to be  community driven and simple for non-technically minded people to use. We spend some time chatting with the client,  taking notes and gathering the various requirements and elements she would like to see on the site.

Once we’ve documented these requirements and different elements we can start producing wireframes that will help  the client confirm that we’ve understood what they want.

We can use any number of tools to produce those wireframes. Some popular choices, in increasing level of fidelity, are:

Pencil & Paper

There’s nothing wrong with simply sitting down with a notepad and a pencil and just sketching out a few basic ideas. It’s cheap, fast and incredibly productive.

In fact, whatever your eventual tools, your first step should always be some quick paper diagrams. They will help to get your thoughts into a coherent shape quickly and effectively.

Pencil

A firefox addon that allows for development of quick and easy wireframes that are a step up from pen and paper. For very simple sites this addon is an excellent tool.

Visio, Omnigraffle, InDesign, DIA

Traditional wireframing tools for windows or mac. These are excellent tools for developing standard wireframes, but tend to lack the features that allow for the development of functional prototypes.

Once an industry standard, there is a growing trend away from these tools as wireframes lose ground to prototypes and the need for increasing complexity to take into account user interactions and states.

Axure RP, iRise, Balsamiq Mockups

Prototyping tools that can replicate some very complex interactivity. As usability becomes more and more refined in web projects, it’s becoming increasingly important for develoeprs and clients to get a sense of how things will work  before committing to what may be an expensive and complex development process.

Other

There’s another option, one that more and more people are starting to turn to as they look for the best way of  wireframing and prototyping elements and interactions on a website: HTML, css and javascript. It makes sense that one of the best ways of modelling behaviour is to use the languages you will be using to develop the project itself.

Implementing an HTML wireframe

To begin with an HTML wireframe we need to start with a layout. You can either use any standard css template you have that is appropriate or find one from the plethora of css support sites that provide suitable templates.

An HTML wireframe is not a website, as such browser compatability is not a high priority. Pick a single browser your  client should view the wireframes in and build to that. The focus should be on speed, the time for progressive  enhancement, accessibility and compatability comes later; during development.

What will likely slow you down initially is establishing some standard rules and templates for laying out the various page elements but if you try a few practice wireframes and keep track of elements you find you use again and again you should very rapidly generate a library of classes and rules that allow for some very complex layouts and elements
to be assembled with startling ease. Once you’ve written a single login or registration form, for example, make sure that you store the markup for it somewhere easily accessible so you can use it again in your next wireframe.

At the very least you should be developing two wireframes for a client – a homepage and a standard content page. Make sure that the standard content page has examples of every HTML element that can be styled so that when the designer gets the wireframes they will know they need to produce designs for them all. A list of HTML elements
can be found at the W3 site.
Some of them you can ignore, but you should strongly consider including any that have a visual element.

An example HTML wireframe for this project can be seen here

Once you’ve produced the appropriate wireframes for the client you can bring in the client to show them because one of the first rules to wireframing is that clients never get to see wireframes on their own. Being there to walk them through the user journeys and explain the decisions regarding why certain elements need greater weight or a certain location is a very important part of the process which can easily get confused and muddy if the client isn’t kept focused on the main responsibilities of a wireframe. The client seems happy, then they turn and say ‘I really like these, but if I could just make one or two suggestions?’

The fine line between wireframe and prototype

Depending on the nature of the client’s suggestions you’re almost certainly going to have to make a choice at this point. If the suggestions relate simply to the issues wireframes are responsible for clarifying; that is, weight of elements, grouping of related components, or illustrations of paths of navigation then you should be able to deal with them with a few changes or annotations. More likely however the client will want to bring in either some design or interaction issues that are not the responsibility of a wireframe. At this point you either need to help the client understand the nature of the wireframe process and concentrate only on the issues it relates to, or you need to make the decision to progress the wireframes from being static wireframes and into interactive prototypes.

There’s a fine line between wireframes and prototypes and frankly, the line is getting thinner everyday and it’s made thinner again by the very nature of HTML wireframes, but it is important to understand that there is a line between them and that they serve different purposes. A wireframe is a static tool while a prototype is a much more open-ended and interactive exploration of how certain functionality and elements are supposed to work.

Let’s pretend that the changes the client is asking for consist of the following

• “In the right column it would be nice if the ‘Recent Editors Comments’
  was above ‘Your Recent Documents’ to give it more weight.”
• “Can we have the ‘Documents, Comments, Resources’ sections in the
  right column work like an accordion with the ‘Editors Recent Comments’
  open as default?”
• “How does the page look when the user is logged out?”

Part 2 of this HTML wireframing tutorial can be found here

I had a bit of an interesting lookup I was trying to do in Django the other day which was confusing me until I sat down and actually worked my way through what I was trying to do. Turns out, django makes even somewhat complex relationship lookups fairly easy, but I thought I’d post about it as it’s not blindingly obvious at first glance.

Imagine the following models:

class Document(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(User, blank=True)
    content = models.TextField(blank=True)
    private = models.BooleanField(default=False)
class UserProfile(models.Model):
    user = models.ForeignKey(User, unique=True)
    friends = models.ManyToManyField(User, symmetrical=False,
                 related_name='user_friends')
    ignored = models.ManyToManyField(User, symmetrical=False,
                 related_name='user_ignored')

Imaginging the following Users:

• Alice has 3 documents, 1 of which is private (meaning only friends can see it). She is friends with Bob, is ignoring Mallory and is apathetic towards Eve (meaning no stored relationship).
• Mallory has 2 documents, both public and is apathetic towards everyone.
• Bob has 1 document which is public and is also apathetic towards everyone.
• Eve is ignoring Alice and is apathetic to Mallory and Bob

Users searching for documents should produce the following:

• Bob searching for documents should see 6, as Alice has made him a friend and he can view her private documents.
• Alice searching for documents should see 4, Bobs 1 and her 3. She doesn’t see Mallory’s public documents as Alice is ignoring Mallory.
• Mallory searching for documents sees 5 – Alice’s public ones, her own 2 and Bobs 1. Alice ignoring her has no bearing on what Mallory can see, just that Alice doesn’t see Mallory’s docs.
• Eve searching for documents sees 3 – Mallory and Bob’s public documents as she has ignored Alice.

First off, we want to get a list of people who have friended me which is a reverse lookup through the Many to Many relationship:
friendly_authors=self.user.user_friends.all()
Get all the people I’ve ignored:
my_ignored=UserProfile.objects.get(user=self.user).ignored.all()

Get a list of docs I can view – docs which are viewable, mine, or written by people who have friended me but whom I haven’t ignored:

docs=Document.objects.filter(
(Q(viewable=True) | Q(author=self.user) | Q(author__in=friendly_authors))
& ~Q(author__in=my_ignored)
)

I didn’t really want to get caught up in the technical stuff about it, but I thought it was a good idea if I did my best to wrap my head around what is a really, really, really confusing issue.

Come with me, kids. We’re going on a trip.

If you open the developer toolbar in IE8 (which is under Tools), you’ll see near the top two possible selection choice: Browser Mode and Document Mode. Let’s build a table of what browser modes can display what document modes.

Now let’s breaks those combinations down. We’ll ignore Quirks Mode in our breakdown below, because we should all have a fairly decent idea of what quirks mode is/does and it should really have much bearing on the current issues.

• IE8 in IE8 Standards Mode is pretty self explanatory, this should be our browser in its happy little normal state.

• IE8 Compatibility View in IE8 Standards Mode – why would you do this? Why is this even possible? Why have they broken my brain already and we’re only on the second option? I mean seriously isn’t the whole point of Compatibility view that it can’t display the page in Standards Mode? Honestly, I have no idea what the results of this combination will be. I have no idea why they’ve even allowed it as a possible combination in the dev tool.

• IE8 Emulating IE7 in standards mode – can’t do it. Selecting IE7 emulation greys out the option for IE8 standards mode, which is kind of what you’d expect for IE8 Compatability Mode if IE7 emulation and IE8 compatibility mode where the same thing.

• IE7 as a standalone browser in IE8 standards mode – again, can’t do it, IE7 is a separate product and this part of the table is just here for consistency (although it does become important later on).

• IE8 in IE7 Standards Mode – surely this should be the same as IE8 Compatibility View? Maybe, maybe not.

• IE8 Compatibility Mode in IE7 standards mode – this is Compatibility Mode’s default, but, as noted above it’s then possible to change Compatibility Mode to render the document in IE8 Standards which seems awfully strange if IE8 Compatibility is identical to IE8 emulating IE7.

• IE8 emulating IE7 in IE7 Standards Mode – again this is the default when you select IE8 emulating IE7 and it becomes impossible to select IE8 standards mode, as you’d expect.

• IE7 Standalone browser in IE7 Standards Mode – this is just the standalone browser doing its thing as you’d expect it to. No big surprises here. Oh wait – yes there are. Turns out that IE8 emulating IE7 is actually slightly different to IE7 Standalone. It’s kind of hard to get a run down on the exact differences from anywhere but Microsoft have certainly said in the past that the IE8 browser has fundamental changes at its core that make it impossible to deliver an exact IE7 experience (which makes sense). On top of that, Microsoft have also released information on how IE8 Compatibility Mode is different to IE7 and that can be found here . What that lovely page doesn’t clarify is if those same differences exist between IE8 Compatibility View and IE8 emulating IE7 or IE8 emulating IE7 and IE7 Standalone.

IE8 Compatibility View does not equal IE7 Standalone Browser
IE8 emulating IE7 does not equal IE7 Standalone Browser
IE8 Compatibility View may equal IE8 emulating IE7 – it seems hard to get a definitive answer, my very strong hunch is currently that IE8 Compatibility View does not equal IE8 emulating IE7, but you’re welcome to disagree. It would help if we ran some tests I guess.

Well, I hope you’ve all had as much fun as I have. I’m now going shoot myself in the head.

You see the same questions being bandied about in every developer forum you vist. I figured it might be a decent idea to try and get a collection of answers to the more common queries in one place and combine it with a general introduction to web development.
If you’re just starting out in Web Development the first place you should be looking is the Opera Web Standards Curriculum at http://www.opera.com/company/education/curriculum/

Read every link they provide. If you don’t understand something they are talking about then go and research the topic until you do understand what they’re talking about. What Opera have provided is a fantastic resource that represents the minimum standards you should have to try and be a web developer.

I’ll say this again so there’s no misunderstanding:
These are the baseline by which developers should be measuring their knowledge.
If you do not understand the principles and ideas presented in the Opera Web Standards Curriculum then you are at a serious disadvantage in the world of web development and you should make the appropriate decisions regarding that deficiency. This means:

• Being aware you will more likely fail to match client requirements
• Being aware you will be less likely to budget project appropriately
• That you will need to spend a great deal of time educating yourself
• That you should be pushing for appropriate level projects (don’t accept clients with higher expectations than you know you can deliver)
• That you should be charging an appropriate market rate for your knowledge (if you don’t know a lot you shouldn’t be charging a lot)

Building yourself a development environment.
Your development environment is a local/controlled environment in which you can develop and tinker with your clients projects without impacting on live, production environments. It is also a place you can develop your own personal projects or just tinker with ideas that intrigue you at this particular time. Your environment should consist of a server (such as Apache or IIS), a backend language (such as PHP or python) and a database (such a mysql or sql server). For the rest of this post, where technology is specified, I will be discussing PHP, Mysql and Apache.

If you’re just starting out and you have a broad range of clients you can generally use whatever development environment you feel most comfortable with, for example XAMPP, EasyPHP or anything else that’s lets you run a controlled server that can host your development files. Some people feel comfortable installing apache, a scripting language and a database themselves, some people prefer to utilise a pre-packaged version such as XAMPP.

Once you start getting regular clients however the role of your development environment starts to change. You can still have your own environment for your projects, however you should also take the time required to set up a development environment as close to your main clients live environment as is possible. This means making sure that you use the same technologies, same versions and same add-ons/plugins that are part of the client environment. You do this so you can minimise the nasty surprises that occur when you move a project from development to their live server. This will mean you will likely have multiple build/test environments for different clients.

Starting a new project
When you start a new project you should determine the appropriate level of technology to use. When you’re first starting out, for example, it’s unlikely you’ll be dealing with projects that require utilizing the complexity and added educational overhead of a framework. However, due to the fact that using frameworks helps promote good code styles, you should be endeavouring to reach the point of being able to use a framework in your projects as quickly as possible.

For minor projects though, as I said, a framework may simply be unnecessary, in which case you should have a series of template files that allow you to start each new project as quickly and consistently as possible. I keep my template package on googlecode which means that at any time, on any internet ready computer, I can use SVN to download a fresh, new project ready for work.

My template package consists of the following files and folders (my css structure is taken from the ‘Boilerplate CSS’ framework):

• css/
  • print.css (My ‘print page’ css styles)
  • screen.css (Site specific css rules – also imports the lib/ css files)
  • ie.css (Css rules specific for IE)
  • lib/
    • forms.css (Css rules specific for forms)
    • plugins.css (Imports any currently required plugin css files)
    • reset.css (Browser reset file to give a consistent baseline)
    • typography.css (Css rules specific for typography)
    • plugins/
      • debug.css (Debug rules for adding when testing/developing)
      • notes.css (Production notes as detailed http://24ways.org/2006/css-production-notes)
      • utility.css (Css classes for site building utility such as ‘clearfix’ or the layout helpers from http://jqueryui.com/docs/Theming/API)

• js/ (Empty initially but likely to be needed).

• index.html (Blank page with basic semantic markup and doctype information, mine also includes the required code to import the css files as well as includes the jquery framework and UI from googlecode API)
• standard_content.html (A page that contains examples of every single available html element, from <a> and <ABBR> down to <ul> and <var>. This is the page that lets you know your design hasn’t missed something when you open it up and see how the CSS affects it).

You may find it useful to have templates done up with barebones markup and css for representing the more common layouts you use. What I’ve presented is just an example – you should add to yours whatever you feel makes your projects get started faster.

Your browser
For the most part you’ll do your development in Firefox as it provides the greatest add-on support for developers. You should test in all major browsers and you should mention in client contracts what they can expect from you in terms of browser support. I cannot stress enough how important it is to have this information in your client contracts. Try including Yahoo’s graded browser support table (http://developer.yahoo.com/yui/articles/gbs/) in your development process.

Testing in browsers
You should have few problems getting older versions of most browsers as required. The obvious a major exception is Internet Explorer 6. For most browser testing this site http://www.xenocode.com/browsers/ may be of use.

Add-ons for Firefox
The reason Firefox is the developers browser of choice is due to the extraordinary add-on that are available for it. As a developer here are a few that you may find useful and represent my first few minutes of downloading whenever I’m given a fresh computer.

• Firebug – You should know this one
• Web developer toolbar – Ditto
• Selenium – Allows recording of browser macros that make testing of web applications much easier
• Colourzilla – In browser colour picker
• Measureit – In browser measuring tool
• Diigo bookmarks – I find Diigo to be by far the best social bookmarking tool – use your own if you want
• Accessibility Extension – Hints and tips and useful extensions to make sure your web pages meet basic accessibility guidelines
• HTML validator – Shows you just how crappy your markup is
• Pencil – In browser wireframing
• Fangs – Screen reader emulator, again for help with accessibility
• Inline Code Finder – Highlights ugly inline code such as styles and javascript that should not be hidden within the markup but rather handled through progressive enhancement.

Other useful debugging tools

• Fiddler – Sniffs information sent to and from the browser, useful because it can be made to work with all browsers.
• IE Developer toolbar – IE8’s version is actually useful, but even adding it to 6 makes life just that little bit easier

Your Editor
Is a personal decision. Use what you feel comfortable with.

Resources
This section could easily grow out of control very quickly, I’ll include a few of the more practical links I’ve found that present the bare minimum you should be keeping track of.

• http://www.quirksmode.org/blog/ – Browser quirks (You must read every link on PPK’s site)
• http://www.positioniseverything.net/ – IE quirks, bugs and fixes (another must read)
• http://www.alistapart.com/- Excellent articles and examples of best practices
• http://www.dezwozhere.com/links.html – Excellent link resource
• http://dev.opera.com/ | https://developer.mozilla.org/En | http://blogs.msdn.com/ie/default.aspx | http://developer.apple.com/safari/ – You should be following the browser developments of the big 4 at the very least (chrome doesn’t offer much for developers – although it’s stunningly fast to use)

I was asked yesterday to provide a clear, simple explanation of tags; what they are and why we’re using them?

So what are they?

Tags are labels that categorise data and information.

And?

No, that’s it. There’s nothing confusing about them, you don’t have to overanalyse it, that’s literally all there is to them. They’re just a bunch of adjectives that can be attached to any noun.

So why do we use them?

So, we use tags because we’re lazy.

What?

Yeah, ‘fraid so. You’ve totally got the world’s largest pack of slackers working for you. We use tags because they’re the simplest solution for implementing the broadest range of functionality and features without locking developers into a single specific methodology.

That doesn’t sound very lazy, that just sounds like a bunch of confusing buzzwords.

Well, it’s going to sound pretty grey and confusing because we’re dealing with grey and confusing information. When I said that they’re a bunch of adjectives that can be attached to any noun I meant exactly that – they’re a system by which you can categorise anything with anything.
See, here’s the problem: tech people like clear and well defined concepts. The more clearly and well-defined a problem is the more specific and targeted solution we can provide, but the corollary to that is that the more targeted and specific a solution is the harder it is to come along at a later date and shoehorn that solution into fixing a separate problem it wasn’t initially designed to fix. When developing a CMS that’s supposed to appeal to as broad a range of clientele as possible you kind of want to avoid the targeted solution in favour of a broader brush.

Ok, that kind of makes sense, but what has that got to do with tags?

Tags are the broader brush. Tags are a developers first line of defence to a lot of problems. Some clients  just want a simple way of putting keywords into HTML metadata – we can just use the tags associated with a Page to do that. Some clients want a simple way of searching across a wide range of pages, events and news articles – again, tagging gives us the hooks needed for getting that data to the user. There’s no arbitrary number limitation on tags and they can be attached to just about everything with minimal effort. You can even use them to represent large amounts of information in new ways of navigation (see tag cloud).

But it’s so airy-fairy.  Tags don’t exist until the user adds them in, and they’re only as good as the client makes them? We’re not providing them a solution, we’re making them do more work.

Well, I did say we’re lazy. More to the point though, any system is only as good as the information put into it. Some clients may feel comfortable allowing content creators to tag their information any way they please, meaning that some tags get misspelt or duplicated as singular and plural. Some clients may feel more comfortable writing strict content guidelines for their content editors defining what tags may or may not be used. It’s important to recognise though that in this regard tags are in no way different to any other form of content; clients have to make the same decisions about page titles and page content and every other piece of information that gets added to their site.

Hmm, alright, I can understand that. Anything else you can tell me about tags?

That’s about it really. The important thing to realise is that they’re not the solution to every problem, nor are they a perfect solution, but they are a solution that doesn’t get in our way when we do want to implement a better solution for a specific client while at the same time giving every client a kind of base functionality that most of them will find useful.

Holy crap. Tags are bloody awesome.

Why yes, yes they are. I’m glad we had this conversation.

Useful javascript snippets to help make html wireframes a bit more like an actual prototype than a wireframe.

The guys and Clearleft and New Bamboo developed a very nifty plugin called Polypage which can be grabbed here or here

and some interesting writeups on using it here and here
Talk on its use from the South by Southwest Conference

Simpler jQuery script I threw together to just show and hide components on a page, just set up the key : value pairs in var config

$(document).ready(function() {
  revealer = function() {
    var config = {
      '#reveal' : '#match',
      '#related' : '.tabs'
    }
    var Attacher = function(key, val) {
      var jqKey = $(key);
      var jqVal = $(val);
      jqVal.hide();
      jqKey.bind("click", function(evt) {
        jqVal.toggle();
        return false;
      })
      return false;
    }
    for (var key in config) {
      attach = new Attacher(key, config[key]);
    }
  }
  reveal = new revealer();
});

All important information for forms, such as form instructions, must be
presented before the form itself. The submit button must be the last form element contained
within a form.

All form fields must be associated with their labels using the label HTML tag.
If a form cannot be labeled, it must include a title that explains in brief what the form
field is.

All forms should clearly indicate which form fields are manditory prior to the
actual form inputs. Avoid cryptic hints such as the use of the asterix or different colors as
the sole means of indicating manditory information requirements.

Form fields that are logically related should be grouped in a field set. If
appropriate, the field set should be labeled with a legend.

<p>Fields marked with an asterisk (*) are required.</p>
<form action="#" method="post">
<fieldset>
<legend>Personal Information</legend>
<div>
<label for="fname">First Name*</label>
<input id="fname" name="firstname" type="text" /></div>
<div>
<label for="lname">Last Name*</label>
<input id="lname" name="lastname" type="text" /></div>
<div>
<label for="street">Street Address*</label>
<input id="street" name="street" type="text" /></div>
<div>
<label for="city">City*</label>
<input id="city" name="city" type="text" /></div>
<div>
<label for="country">Country*</label>
<input id="country" name="country" type="text" /></div>
<div>
<label for="postcode">Postcode*</label>
<input id="postcode" name="postcode" type="text" /></div>
</fieldset>
Would you like to sign up for our newsletter?
<div>
<input id="letteryes" name="newsletter" type="radio" value="yes" />
<label for="letteryes">Yes</label></div>
<div>
<input id="letterno" name="newsletter" type="radio" value="no" />
<label for="letterno">No</label></div>
<div>
<input name="submit" type="submit" value="Submit" /></div>
</form>

<form action="#">
<fieldset>
<legend>Login</legend>
<div>
<label for="username">Username</label>
<input type="text" id="username" name="username" />
</div>
<div>
<label for="password">Password</label>
<input type="password" id="password" name="password"  />
</div>
<div>
<input id="Submit" name="Submit" value="Submit" type="submit">
</div>
</fieldset>
</form>

<form action="#">
<div>
<input type="text" name="term" title="Search term" />
<input id="search" name="search" value="Search" type="submit">
</div>
</form>