Category Archives: Web Design

Academic Papers Artwork baby names Blog blogging democracy Design ethics Facebook firefox Flickr folksonomies Google Google Docs Google Spreadsheets how-to information-architecture information-retrieval information design internet iphone journalism listserv mailing list maps mass media Online News Papers Photography plugin poll social-bookmarking social networking social software spam tagging trust Twitter Usability web-development Web2.0 webspam web standards WordPress Writing

The Top Ten Best Things About HTML 5

html-source The Word Wide Web has grown at an astounding pace and is pretty ingrained in a lot of our daily lives – you’re reading it right now. Part of the reason it has been so successful has been the flexibility and ease of use of the basic language of web pages, HTML.

Most web sites are developed in HTML 4 (first released in 1997) or XHTML (from 2000). Considering the rapid change all around the web, why hasn’t there been a new version, and what’s next for the Web? One reason we haven’t seen new versions is the aforementioned flexibility. There have been plenty of developments, from blogging software and other content management systems on the server side to CSS, AJAX, and embedded Flash video on the front end.

Microformats are a part of this and will be a big part of the future too. But all the web developers in the house should get up to speed on HTML 5, which looks to be the future of the Web.

I’ve been watching what the Web Hypertext Application Technology Working Group (WHATWG) has been doing with HTML 5 ever since I took a gander at the W3C’s XHTML 2 spec and figured out that they were mostly adding annoyance and removing backwards compatibility. Guys I respect, like Eric Meyer, seemed to agree. The WHATWG decided to work on their own ideas and came up with HTML, which was eventually adopted by the W3C as well.

I haven’t taken a look in a while but Marcia Zeng mentioned the HTML 5 spec in an email recently and it got me interested in checking back in. I have to say, for the most part, it’s looking very interesting.

So I decided to put together a quick list of my top 10 new things in HTML 5:

  1. The <nav> element. This will be great for the billions of navbars we web developers have been coding up for the past 10 years. Things like this will help reduce the problem of div soup and make structure more apparent.
  2. The <header> and <footer> elements. See the last entry and add in the billions of page headers and footers we’ve produced as well. Semantically meaningful tags like these can only help browser plugin writers, search engine programmers, and other hackers to come up with cool new features.
  3. The death of the dreaded <font> tag. This should have been banished as soon as CSS was widely supported. It was a pain in the rear to use back in the 1990s when coding by hand, and was even worse when inserted by GUI tools like FrontPage.
  4. The continued usefulness of the <img> element. You may be wondering how we could make web pages without the image element, but XHTML2 only included it grudgingly, recommending everyone use <object> instead. The problem is that just about anything could be an object, the tag is almost meaningless. Why not replace all tags with <thing>?
  5. The <audio> and <video> elements. There’s been some controversy about this, because the W3C originally recommended use of the open source Ogg formats but later recanted. Still, it will be nice to embed audio and video as easily and consistently as images are used now.
  6. New <input> types for dates, urls, etc. When you have a form that requires a user input a date or some other specialized data, you choices have been to present a plain text input or jazz things up with JavaScript to make it a bit more usable. HTML 5 adds specific types for these cases.
  7. The conenteditable API. This will be really interesting if it’s fully supported. In Tim Berners-Lee’s original vision for the web, documents would be easily editable. Wikis get us almost there, but a standard editing API would be even better.
  8. A required attribute for form inputs. This won’t mean we can stop checking incoming data on the server side (users can still POST arbitrary data with the right tools) but it should remove the need for millions of little field-checking JavaScripts.
  9. The <figure> and <legend> elements. This will make it a little easier to associate captions and other text to images. Look for CMSs and image search engines to take advantage of these tags.
  10. An open development process. Want to keep an eye on development? Got an idea or concern about the spec? Hop on one of the mailing lists. Open standards are great for promoting compatibility and competition, so open development of the standards just makes sense.

The power of microformats

Considering a Descent A few months ago I attended a really interesting talk by Eric Meyer where he touched on the use of microformats.  You might know Eric from his excellent O’Reilly Press CSS books.

What are microformats?  Before giving an example, I’ll give a little context.  When Tim Berners-Lee created the web, he tried to make HTML simple, flexible, and meaningful.  He succeeded on the first two counts but the third was quickly left by the wayside – many designers didn’t care what a particular tag meant, so long as it could be used for page layout.  The use of tables to arrange graphic elements instead of holding tabular data is a perfect example.

So Berners-Lee has been talking for years about the next step – the semantic web.  In the semantic web, tags are used to say what a particular piece of content is, with all styling done with stylesheets.  There is, of course, more to the semantic web than just separating content and presentation, after all you can work that way with HTML and CSS now.  One other key component is the web of trust, where people and web sites are able to describe relationships to each other so that search engines can help you find trustworthy content automatically.

Unfortunately, the semantic web has not really taken off.  There have been lots of meetings and XML schemas but it’s all too complicated, the process is too bureaucratic, and everything is being designed from the top down.

This is where microformats come in.  Let’s say you have a blog and you’ve tagged all your articles.  You’d like to let search engines and aggregators like Technorati know what your tags are.  But HTML doesn’t have anything like this:

<tag>semantic web<tag>

So what do you do?  Simple, use the rel-tag microformat:

<a href=”” rel=”tag”>semantic web</a>

The microformat makes use of existing html tags and attributes and just follows simple conventions.  But now that this little bit of meaning can be interpreted by spiders and other programs, we’ve actually added a pretty powerful bit of functionality to the web.

Most blog software, including WordPress, includes does microformatting for you.  If install my tag cloud plugin Altocumulous, and view source, you can see for yourself.

For intranet purposes, the hCard and hCalendar microformats look promising.  Take a look at to see why I think so.  I’ll write more on it later.

The importance of design – Can you read this at 60 MPH?

The New York Times had a great article a few months ago about redesigning the font used on highway signs.  You’ve probably seen the current font, Highway Gothic, a million times without ever thinking about it – it’s been in use for more than 50 years.

Granphic from the New York TimesWorrying about the font on the signs seems pretty silly compared to all the engineering and resources that go into a single bridge, let alone the entire highway system.  Why does this merit an article in the Times and what does this have to do with programing, web development, social software, or any of the topics many visitors to this blog are interested in?

Programmers and analysts sometimes doubt the value of design.  It’s hard work gathering all the requirements and writing all the code – we don’t have time to worry about how pretty it looks.  A lot of projects we work on, though, involve creating user interfaces, often web applications.  That means that, when it comes down to it, your job is to support the user’s tasks.

Now if someone wanted to add 10% to your hours to pick just the right shade of chartruse, you would be justifiably miffed.  But good interface designers will have good, empirically-tested reasons for their work and the guidelines they live by.  Highway signs are a great example of this kind of empirical benefit:

Intrigued by the early positive results, the researchers took the prototype out onto the test track. Drivers recruited from the nearby town of State College drove around the mock highway. From the back seat, Pietrucha and Garvey recorded at what distance the subjects could read a pair of highway signs, one printed in Highway Gothic and the other in Clearview. Researchers from 3M came up with the text, made-up names like Dorset and Conyer ? words that were easy to read. In nighttime tests, Clearview showed a 16 percent improvement in recognition over Highway Gothic, meaning drivers traveling at 60 miles per hour would have an extra one to two seconds to make a decision.

A one or two second gain in legibility matters a lot when your life depends on it.  Few web applications present the same kind of physical danger, but multiply a small gain over an application with 10,000 users, operating 24 hours a day for a year, and you can see how this can impact the business.  Good design is part of the larger concept of usability.  As anyone who’s done any usability testing can tell you, most applications have many small, easy-to-change pitfalls that can quickly add up to huge wastes of time and effort.