Why

At the moment, OnePage isn’t perfect. During initial development of a web application, you’re in a big hurry to get your ideas down and working. I didn’t even turn up with my lofty ideas til around beta launch anyway. Whilst Joel and Dan had done a great job with a lot of the points I’m going to touch on in this post, we’ve decided to go for a fresh start for our next big release for a few reasons:

1. It’ll make it much quicker to add new functions in the future (or rapid development, if you will.) The markup and code will be clean, we just need to slot in our extra functions, any extra styles if necessary, and we’ll be good to go. Right now, we have a CSS style sheet that’s got more repetition and class names than anything I’ve ever seen, any changes requires wading through CSS soup.
2. It’ll make the application much faster. It’s not bad now, but if we can trim our code into modular blocks, our CSS into a neat, non-repetitive sheet, and minimise on the images, let alone all the clever server and PHP stuff I don’t understand, we’re going to have a quick little app rather than a Facebookesque lurching monster.
3. It’ll be easier to test and fix bugs. If we’re not battling the monster every time we have an issue, pinpointing the layout glitch or typo will be simple.

Internet Explorer 6

We’re going to support Internet Explorer 6, which makes us akin to the nerdy prefects of the web development world. Everybody wants to give up IE6. It’s old and doesn’t behave in a reliable or predictable way. It’s a total pain to make designs and funky functions work in IE6. But loads of people use it. And we don’t think it’s their fault.

Why should these users suffer just because they don’t know any better? There’s many different reasons why you might use IE6, but I don’t think “to spite web developers” is one of them, so why should we spite them in return? It’s as simple as that!

Unobtrusive Javascript and Progressively-enhanced CSS

In a similar way, we’ll be using unobtrusive Javascript and progress-enhancement methods for applying our CSS. We don’t want to leave some browsers and users out in the cold, so we’re making sure that our application works without javascript enabled, which is a real biggy for mobile access. We want to use fancy CSS, who wouldn’t want the latest trendy rounded corners and transparency?! Instead of making something that wouldn’t work, and as a result look ugly, in the older browsers, we’ll only use those techniques in the browsers that can do it, and keep it clean and simple for the rest.

Clean, semantically-juicy HTML

We’re also going to have mega-clean, handwritten, semantically-juicy HTML, from the beginning. It’s a terrible shame that so many web applications out there has badly-written HTML. HTML is the foundation that screenreaders use to understand web sites and applications and if it’s not clear and well-structured, somebody using a screenreader is going to leave the app pretty sharpish.

This is a really high percentage of users, one we definitely can’t ignore, and not just those that are blind. Twice this year I’ve been lucky enough to experience a talk by Robin Christopherson of AbilityNet where he’s shown what it’s like to experience a site using a screenreader. It’s pretty shocking stuff and if that doesn’t convince you of the importance of clean HTML, nothing will.

Not only that, but mobile devices will have an easier time of using OnePage. If we’ve written awesome xHTML that doesn’t rely on CSS or Javascript to make sense, then the simplest of the mobile browser should be able to have a stab at understanding the pages. And mobile is only going to get bigger!

Semantic HTML, using all the optimum and most-descriptive HTML elements when we’re writing our markup, helps in many different ways. For a start, it helps other systems understand our web pages:

It helps users understand and read our content more easily if we use lists when we’ve got a list of items, quotes when we’re quoting somebody else and headings to describe our content. You wouldn’t put <div> tags around a link and expect a user to copy and paste it into their address bar, so why wouldn’t you use the other appropriate HTML tags?

It helps Google understand what the focus of our page is about when we use appropriate and descriptive headings.

It makes writing CSS a hell of a lot easier. If everything is made of <div> tags, then we’re going to have to give every <div> a unique and descriptive id name. If we have well-structured HTML with a variety of tags, we might even be able to do away with id and classes altogether, and wouldn’t that make it easier to trace the cause of that CSS bug?!

We can even make our pages *even more* semantic using super-juicy awesomeness like Microformats. We already use microformats for vCards, so that another application (either desktop or web-based) can pick out our users’ contact details easily from OnePage without any copy-and-pasting effort on a user’s behalf. This will make OnePage tastier for Google, as it can use microformats to find even more relevant search results for its users, and other applications can use them to share the data from OnePage, potentially promoting a wider awareness of our app.

So

I hope that’s an interesting little insight. I’ve tried to touch on everything without going into mad detail. I hope it hasn’t left anyone screaming and running away or thinking I’m a masochistic individual. If anybody wants to discuss any of this stuff further Joel and me (Laura) are always up for talking about this kind of stuff. Any recommendations or warnings are also appreciated. We’d love to hear if anybody else has put this much effort into their web app!