This decision wasn’t difficult because YTS is my biggest and oldest site or because I’m particularly attached to it, but rather because of all the kind words I’ve received from so many people who like it. All I can really say is to trust me. This decision will lead to much better things.

What this Means

It’s time to get started on an open-source application that most everyone in the community can use and benefit from. It’s probably a couple of months away, but hopefully, when it’s done, it will be more valuable to the community than YTS ever was. I’ll still be doing my thing over at my personal site, but YTS will be shutting its doors in a week or two.

Summary

At the end of the day, you have to choose where you spend your time. YTS was a good start for me, but it’s time to move on to something else. I’ve learned a lot in the last year through both my sites and my day job, and it’s time to apply that experience to building some open source applications. Thanks to everybody who discussed this with and helped me figure out the right path.

Before the Fact

Preventing problems or confusion before they occur can help improve the overall experience. Just like an experience at a store, would you rather recover from a problem gracefully or prevent it all together?

Explanations

There are often times where changing one setting will affect the system behavior in ways that aren’t obvious. Include help text that explains any consequences or effects of performing a particular action. Use clear labeling on radio buttons and descriptions to make sure that users feel comfortable making changes.

The most common mistake I see here is poorly labeled checkboxes. Engineers will use terms and phrases that they understand but that have confusing or no meaning to the actual users of the system.

Example Text

If you’re using free text fields for dates, phone numbers, credit cards, social security numbers, or other values that are generally associated with formatting, make sure to provide examples of the expected formats. Of course, you ultimately want your fields to be as flexible as possible at accepting different formats, but it doesn’t hurt to guide users in a certain direction to avoid any confusion or questions.

Labeling Buttons

Make sure that your buttons are clearly labeled. This means using explicit verbs. For instance, say “Send E-mail” or “Save Changes” instead of “Submit”. Let people know what they are about to do or what even they are about to cause. This is your last chance to make them aware of the action they are performing.

After the Fact

Tell Them What’s Happening Behind the Scenes

If an e-mail is automatically generated, let your user know that in the confirmation message. If something unusual will happen, let them know that. If there is a complex business logic error that cannot be validated with JavaScript, give a detailed explanation of what failed and how to correct it.

Errors

Highlight the field with an error. Clearly explain the error. Provide a summary of the errors. If possible, hide the fields that don’t contain errors. Make sure that the error messages are friendly and don’t sound like a computer.

If the context is right, use words like “Oops” or “We’re sorry.” Nobody likes getting a computer generated and unfriendly error. Lastly, if your system automatically generates error e-mails, let the user know that someone has been notified automatically.

Visual Effects

With the prevalence of AJAX, new visual effects provided by Scriptaculous, when used judiciously, can help users understand what’s happening when an explicit message is not necessary. One of the most well-known examples of this is 37signal’s Yellow-Fade Technique.

Summary

By helping people understand what will happen or what did happen, they feel more comfortable with the system. You never want to leave your users asking, “What happens if I press this?” or “What just happened?” With the former, you introduce hesitation and confusion. With the latter, they might try to repeat the action, thus creating a duplicate entry or additional confusion. Keep the lines of communication clear, and everybody will be happier.

It works out pretty well really. When you come across a design you appreciate, instead of bookmarking the site, look at the details and save a small portion of a screenshot for later. When it does influence your next design, it will only influence a small part, and you won’t “accidentally” gain too much inspiration from one particular site.

As a disclaimer, I’m not advocating outright copying of different details from different sites and merging them all together. These should still be used as inspiration only.

<label for="name">Name</label><input type="text" id="name" />

That’s what I’m talking about. Good, clean, semantic code that takes little to no effort to use. The good thing is that it seems the mistake here is a lack of awareness rather than a lack of concern. What are you waiting for? If you or someone you know is building forms and not using the label tag, please make sure to educate them on the availability and benefits of using the label tag and make the web a better place.

As Mark Boulton and Khoi Vinh have so wonderfully pointed out recently, good designs start with a good grid. Naturally, the first thing I did in Visio was setup a grid. I’m not going to go into details here because they do a much better job than I ever could, but rest assured, the grid is your friend. I’ve included links to their articles at the end.

Page Description Diagrams

This is actually the first time I’ve ever used page description diagrams, and I love them. I wanted to present more than just wireframes for this article, so PDD’s were the obvious choice. The benefit to page description diagrams is that you completely separate your content from your presentation, and it forces you to focus on the chunks and hierarchy.

With Page Description Diagrams you simply organize your page elements, or descriptions of your page elements, into high, medium, and low importance. This lets you do a better job of worrying about the content details and provides the designer with more flexibility when it comes to design time.

Wireframes

A more common approach to information architecture is to create wireframes. These extend the concept of page description diagrams, but also focus on layout. Some designers like the structure provided by wireframes, and others feel crippled and strangled by the layout. In our case, since I created both page description diagrams and wireframes, everybody has a choice of what suits them best. Your decision would most likely be based on the preferences of your designers and your level of comfort with layout.

Another benefit of focusing on the IA before working on the visual design is that you enable the designer to focus on designing without having to think up content ideas or relationships. Of course, if a designer comes up with a great idea in the process, the wireframes shouldn’t be set in stone. You should always plan on changing and adjusting as needed. The wireframes should serve as more of a guideline than a concrete tablet of instructions.

Visual Design

I tend to do a little bit of light “design” in my wireframes. However, in the final implementation, it shouldn’t matter if the global navigation actually ends up being tabs or if certain areas end up having backgrounds or not. Nonetheless, these elements help make the wireframes easier to interpret. Without visual design to properly organize and accentuate information, wireframes can get extremely busy, making it esay to overlook or misunderstand a piece of information.

Summary

The Page Description Diagram and Wireframe PDF - 700k

By creating wireframes or page description diagrams, you force yourself to really analyze the content and organization of that content. By jumping straight into visual design, it’s easy to get lost in the whirlwind and miss out on some great ideas for content. With a little bit of planning and IA, you’re laying a much stronger foundation to build the rest of your site upon.

Related Links

If you’re interested in this, make sure to check out the following links.

• Free Visio Stencils and Wireframes Templates
• Khoi Vinh’s Grid Computing… and Design
• Khoi Vinh’s The Funniest Grid You Ever Saw
• Mark Boulton’s 5 Simple Steps to Designing Grid Systems
• Dan Brown’s article about Page Description Diagrams
• Keith Robinson’s writeup on Page Description Diagrams

In fact, the growth almost caught me completely off guard. I’m now collaborating with several extremely talented people, and have had the opportunity to work with many more. I suppose it’s not the biggest news in the world, but it’s been a great experience.

The Redesign

After a brief lull in postings here while I was moving, getting settled in, working entirely too much at my day job, and trying to get outdoors on the weekends, the redesign is still going on, but had to take a brief backseat to my day to day life.

The IA should be coming down the pipeline soon with the visual stuff happening sometime later this month. After that it’s just a matter of getting a week off from to put it all together.

The Growth

This year has definitely been a good start, and I’m really looking forward to what we have planned for the next year. The growth has been great, and we’re all really excited.

Thanks

Naturally, I want to say thanks to the contributors. Even though they are just getting rolling, they make this much more fun and rewarding. So thanks to Jonathan Snook, Paul Jarvis, and Joseph Wain.

I’d also like to think, in no particular order, the following people for helping to get YTS off the ground, or just helping to keep me motivated whether they realised it or not. Ryan Carson, Jeremy Keith, Andy Budd, Nick Finck, Cameron Moll, Michael Moncur, Keith Robinson, Roger Johansson, Mike Papageorge, Scrivs, Ryan Latham, Jon Hicks, David Hellsing, and Amber MacArthur

Lastly, there’s too many to list, but I’d like to also thank everybody who takes the time to send brief e-mails just to say thanks. It’s greatly appreciated, and really one of the few tangible rewards I get from the site.

Semantic markup is readable markup. It’s that simple. It’s more readable for people and, more importantly, provides a sort of metadata to machines. Different tags imply different meanings, and if there’s a tag appropriate to your content, you should make every effort to use it.

For instance, it’s fairly common knowledge that as long as you’re not stuffing keywords, Google will weight the content of your h1 tags more than the content of a p tag. That’s semantics at work.

Overlooked Tags

I posted a while back on table semantics and the use of the semantically valuable table tags. Not surprisingly, there are numerous other tags that you may be forgetting about. Definition lists are great in many circumstances. fieldset, label, cite, code, samp, pre, and blockquote are all great tags as well that provide valuable benefits, but aren’t used as much as they could be.

Check out W3Schools XHTML 1.0 Reference to find out more about some of the tags you could be using to expand your arsenal.

Labels

If there’s one tag that I would like to see more of, it’s the label tag. Not only does it add clickable text that provides focus to the target form field, but it is required for accessibility purposes. It’s not difficult to use, and it makes for much better markup, but I still find major sites all of the time that don’t use it.

Microformats

For those of you not yet familiar with Microformats, I strongly suggest you stay abreast of what’s going on. Microformats are, at their core, semantic best practices. They are being proposed, refined, and created by an open group of people who really care about and understand the value of semantics and open standards. They range from formatting resumes to how to best display a post on a blog. If nothing else, you can gain a great amount of insight into the value of semantics by simply reading about a handful of Microformats.

Summary

I could try and cover all of the tags I don’t see enough, but instead, I just want to encourage you to go and familiarize yourself with tags and attributes you may not be using. They’re out there, and they can make your code that much prettier. One you know how to use CSS to style and manipulate your XHTML, the next step is to make sure you’re using the right HTML for the job. Understanding semantics is a huge part of that.

Not being one to offer criticism without suggestions, I mocked up the following to show what it could look like so that it would be easier to tell what the status was when you save your entry. By moving the statuses closer to the save button, it’s much more natural to know exactly what I’m doing.

Naturally, it’s never that simple. Texpattern uses different text for that save button depending on whether or not it’s the first time it’s been published or whether it’s being updated after it’s live. I really like this idea because it lets me know if I’m creating a new entry instead of editing an old entry. It sounds silly, but the way I work with Textpattern, it’s very easy for me to make this mistake and overwrite an entry accidentally.

So now, instead of “Publish” which implies that the entry will show up on the site, the button says “Create” which tells me that it is a brand new entry that has never existed in the system before.

Summary

It’s a very minor and subtle change, but it’s a good example of being careful when labeling buttons. Different words can have very subtle implications that could cause confusion or hesitation. Usability is about making sure that your application does what your users expect it to do. When your button tells them exactly what’s going on, it helps set that expectation clearly and succinctly.

They were so busy worrying about whether or not they could, they didn’t stop to think if they should.

We’re all very familiar with the bane that is flash. Inaccessible navigation, pages that couldn’t be bookmarked, fancy effects, noises, and transitions for no reason whatsoever. Flash was just that. All style and no substance.

While I believe that there are many situations where AJAX is the best tool for the job, I feel like there are many more situations where it’s being used for the wrong reasons.

Using JavaScript Visual Effects for the Wrong Reason

Even worse, the JavaScript effects that are becoming more popular to help solve interface problems created by AJAX are now being used in situations where they aren’t even remotely appropriate. I’ve seen many sites using JavaScript transitions to change between pages or reveal sections of content.

Having elements disappear, or fade in and out is beneficial when using AJAX because there isn’t a page reload. You need something to provide feedback to the user to let them know that something has happened. It’s not necessary to use it to let a user know they are going to a different page. That’s what anchor tags are for.

Using the Wrong JavaScript Visual Effects

Another problem that worries me is using the wrong effects. For instance, visually minimizing something when it is deleted could leave some confused. In most OS’s, minimizing windows and closing them are two completely different tasks. When I click “delete” and something gets minimized into oblivion, I’m left with some concerns. Did I delete it or just remove it from the screen? What really happened?

There’s no clear cut answer, but when using these effects, it’s important to understand why you’re using it. For that matter, you should always be questioning whether you should use it at all. If the answer is yes, then carefully consider which effect to use. Don’t just use the one you think looks prettiest.

Another way to solve this is to give serious consideration to the labeling. Words like delete, hide, and remove are often used with the wrong meaning. Take Basecamp for instance, people are “removed” from projects. This does not mean they are deleted, this means they are just not associated with that project. I have, however, seen applications where similar situations are labeled as “delete”.

Summary

I love the Scriptaculous library and everything it has provided for us. It is truly an amazing piece of work as are the other libraries that are bringing advanced scripting effects to the masses. However, when using these libraries, we need to ask whether we’re using it because there is a good reason, or are we using it because we can?

Normal Image Map (i.e. the old way)

<img src="joshua.jpg" width="400" height="400" border="0" 
    usemap="#map" />
<map name="map" id="map">
  <area shape="rect" coords="0,0,150,150" href="#" 
    alt="item01" />
  <area shape="rect" coords="150,160,250,260" href="#" 
    alt="item02" />
  <area shape="rect" coords="290,280,390,380" href="#" 
    alt="item03" />
</map>

With the above method, if CSS is disabled, you wouldn't see any text or any links. so, how about doing the same thing with a little tweak to an old image replacement method? Although there are caveats with all image replacement techniques, it is a great improvement to an image map for accessibility and separating structure from design. So here's how you do it:

IR Map (i.e. the new way)

You start with a normal unordered list, like you would for any menu.

<ul id="menu">
  <li id="item01"><a href="#" title="item01">item01</a></li>
  <li id="item02"><a href="#" title="item02">item02</a></li>
  <li id="item03"><a href="#" title="item03">item03</a></li>
</ul>

Then you create a background for the list, with it’s position relative:

#menu {
  position: relative;
  width: 400px; 
  height: 400px;
  background: url("joshua.jpg");
}

Then you create the global styles for the links, which in this case each of the links is absolute so they're absolutely positioned inside the relatively positioned UL tag.

#menu a {
  text-indent: -9999px;
  text-decoration: none;
  position: absolute;
  /* this next line is just to show where each box is */
  border: 1px solid #FFF; 
}

And now the only thing left to do is create the specific positions of each links, as well as their hover states, which, like most image replacement techniques, is the same image shifted down, so it doesn't require a new image loading on the mouseover.

#item01 a { top: 0; left: 0; width: 150px; height: 150px; }                                           
#item02 a { top: 150px; left: 160px; width: 100px; 
  height: 100px; }
#item03 a { top: 290px; left: 280px; width: 100px; 
  height: 100px;}
#item01 a:hover 
  { background: transparent url("joshua.jpg") 0 -400px no-repeat; }                                         
#item02 a:hover 
  { background: transparent url("joshua.jpg") -160px -550px no-repeat; }
#item03 a:hover 
  { background: transparent url("joshua.jpg") -280px -690px no-repeat; }

See the example for the above code in action.

Using the principles of absolutely positioning elements inside relatively positioned parent elements, you now how have an image (map) replacement technique that works if you have a menu or image map that has both different X and Y co-ordinates. The menus for www.latitudeband.com and www.2pt3.com both use this technique.

YTS isn't my own personal site any longer. There's now a large audience of wonderful visitors who have expectations. The first, and what is beginning to look like the most important, step was to gather feedback from the visitors. Yes, we could have taken a guess at what everyone wants, but it would have been just that, a guess.

The results of the survey have actually been quite eye-opening. Many features we thought were unimportant or not valuable, were actually very important to the visitors. Conversely, some of our new ideas would have been a complete waste of effort if we decided to implement them.

While I wouldn't suggest doing a survey for a redesign of a personal site, this was well worth the time and effort for our redesign. If you're planning on doing a survey before redesigning a client's site, make sure to plan for at least one extra week in the timelin to wait for responses.

In the case of building sites for clients, survey results enable you to show your client what their audience truly wants instead of basing everything on what your client thinks they want. How many times have you had a client request something that you knew was a bad idea, but didn't have the data to convince them it was bad? Bear in mind that survey results can just as easily prove your ideas and assumptions were wrong as well.

Questionaire

Had this been a project for a client, this would have been a good place to do a questionaire or sit down with them and interview them for their goals and desires. We've got it easy, we're the judge, jury, and executioner client and consultant.

Brainstorming

This part has been going on for a while in the background. We've been throwing around ideas in Basecamp for quite some time, but when it came time to do the official brainstorming, I fell back to the best brainstorming application ever--Pen and paper. I simply took a piece of paper and filled it up with every word that came to mind.

From features, to marketing ideas, to colors, to logistics, nothing was off limits. Even if I thought something might be a bad idea, I wrote it down. At this point, anything should be considered. I kept jotting down ideas until the piece of paper was full.

In this case, I had actually done my brainstorming before the survey, and that worked out great. After the results of the survey were in, I went back and added all of the new suggestions and ideas from the survey. Some of the ideas contradicted earlier ideas, but that still doesn't matter until the next step.

Prioritizing

Once we had a set of features and ideas, we had to choose our battles. It would be ridiculous for us to try and accomplish everything on the list, so we had to start making tough decisions. We started simply by weighing the value of each idea against the level of effort to implement that idea. Remember, just because you can do something, doesn't mean that you should.

Once we had the list prioritized, it was simple to know which features were in and which were out. During this, we had to keep in mind that we would be up against some rough challenges with the very strong possibility of completely changing platforms and blogging software.

Risks / Logistics

Speaking of changing platforms, next we had to pull together a list of risks and logistical issues so that we could accomodate for some of the unknowns. It's always easy to overlook the DNS switch or exporting and importing data. Anybody who plans a site without taking serious account of logistics is just asking for trouble.

For us, the risks and logistics came down to a simple list that we could account for with an extra week or two in our timeline. This list is pretty easy to come up with if you simply think about the following potential pain points:

• Domain (DNS Switching or Setup)
• Hosting (Payment, Setup Time, etc.)
• Statistics (Setup Time)
• E-mail
• 3rd Party Involvement
• Legacy Support (Old URL's, importing and exportind data, etc.)
• Major Decisions (Package Evaluation, Vendor Selection, etc.)
• Touchpoints (Anywhere there's integration, there's room for pain.)

These things take time and will change the timeline of your project whether you like it or not. I suggest planning for them upfront so that it's a pleasant surprise when one of them goes exceedingly smoothly.

Planning

Once we had a good idea of what we wanted to achieve, it was time for the plan. Everybody has their own take on planning. Some prefer easyily achievable goals to stay motivated and feel successful. Others choose ridiculously crazy goals so there's pressure to take care of business. I'm the latter, and so I planned a week for each major phase.

1. Week 1: Planning, Logistics, and Strategy
2. Week 2: Information Architecture
3. Week 3: Identity, Color, and Typography
4. Week 4: Visual Design
5. Week 5 & 6: Site Development, Implementation, and Testing
6. Week 7: Cutover and Adjustments

All of the cushion for the logistics has been rolled into week 6. Keep in mind, this is a very aggressive schedule, and had this been for anybody other than myself, I would have made it much more realistic.

Summary

Beginning a project without covering all of your bases can be dangerous, or worse, unprofitable. It's best to think through a project at the beginning and at least give yourself some guidelines and goals. Remember, it's not the end of the world if you have to make a change later. A good plan or project needs to be flexible.

If you commit some time upfront to planning for all of these factors, you'll be a laying a solid foundation on which to base your future decisions. However, if you're idea of redesigning is to just open Photoshop and start designing without any regard for logistics, you'll be selling yourself short.

There are a handful of issues with multi-select lists. From accessibility to being generally difficult to use, they can usually be safely replaced by a list of checkboxes.

Accessibility

The first problem is that the user must hold down an additional button to select the options. This can obviously be a problem for users with decreased mobility in their hands such as those with arthritis, but it can also be challenging even for perfectly capable users to make those selections.

Accidents

Similarly, using a multi-select list means that your users will invariably need to scroll. Being that the scoll bar for multi-select lists is right next to the options, it is incredibly easy for someone to accidentally click an option without holding control, thereby deselecting all of their choices. With checkboxes, you wouldn't have this problem. If you accidentally uncheck one of the boxes, you don't lose all of your other selections.

Not Intuitive

Additionally, not everybody knows to hold down control, or command for the Apple folks out there, to select multiple choices. And of course, if you have to explain your interface, there could be a problem there. With a list of checkboxes though, you can be guaranteed that nobody will be confused about what they should do.

Option Visibility

The final major weakness of multi-select lists is also the only major strength. They are compact. If you don't have a lot of screen real estate, this is rather useful. However, it is their size that makes them so difficult to use. As you can see by the example below, several of the options in the checklist are not displayed. This not only makes it difficult to tell which options you have selected, but it also requires you to make extra effort to view all of the options. This leads to scrolling and accidental clicks which leads to frustration.

Summary

In general, multi-select lists are bad news. They require many extra clicks, additional scrolling, are prone to accidental mistakes, and difficult to use when selecting multiple options. However, if screen real estate is important, and you have a small userbase that would be comfortable with them, they might be the tool you need. Use with caution though, a list of checkboxes can usually do a much better job.

Anytime you have 2 options where one selection implies that the other is not selected, a checkbox should be your first choice in order to consolidate and simplify. For instance, radio buttons with "Yes" and "No" as options are generally redundant and a waste of space when it can be replaced by a simple statement accompanied by a checkbox.

The exceptions to this guideline are when you have good reason to explicitly state the options or it is more natural in the context of the page or application to offer explicit "Yes" and "No" choices.

Radio Buttons

Radio buttons are ideal for situations where you have 3-5 options. Any more than 5 options and your decision will most likely depend on the amount of available screen real estate. If you have less than 3 options, a checkbox is probably more appropriate.

Radio buttons are also beneficial when you need to provide additional contextual help for each choice. For instance if you have a choice for a "Gold", "Silver", or "Bronze" plan, you might want to provide a couple of sentences about each to help users make informed decisions.

Drop Downs

Drop downs should be a last resort. They can slow people down because you must click on them before you see your options. Then you need to click again to select that option which may or may not have moved if you had to scroll within the drop down.

With radio buttons or checkboxes, your options are always visible and only require one click or press of the space bar. This convenience can quickly add up to save time and reduce keystrokes.

The value in drop downs is saving screen real estate when there are multiple options. I generally classify multiple options as being more than 5, but this is a grey area and can vary depending on the value of your screen real estate.

Summary

There are appropriate uses for each of these input fields, and understanding the benefits and drawbacks of each can help you build better applications and forms. Naturally, with any adjustment in the type of field you use, label adjustments will be necessary and can go a long way in making your forms easier to use. These aren't definitive rules by any means. They are simply guidelines to help make your decisions regarding input types a little more informed.

If it found one of the words but no attachment, it could warn you of your possible mistake. The logic is simple and a little out of the ordinary for a typical feature, but I think it could work.