Not long after the phrase Web 2.0 emerged, also Web 2.0 design appeared. An unwritten set of guidelines that demanded that a decent webpage should have gradients, round corners, some mirror effects, a badge, and the important stuff should be in a font size of at least 48px came to existence.

I’m still not sure what they were thinking back then. Did the designers really think users where that stupid that they needed big letters screaming at them? Was it all about showing off Photoshop skills, or had it something to do with the idea that Web2.0 should be clearly recognizable as something different, something totally not Web 1.0.

Well let’s no longer talk about the past, and bad examples, let’s search for good ones that are available to us now. Because I have the feeling that we’re slowly moving to a new set of design guide lines. I’ll present you three websites, that – although they are different – have a lot in common too.

First:

Flickr.com probably one of the oldest Web 2.0 companies that didn’t go along with the bling hype. The interface is clear and simple, but still looks shiny cool.

Second:

Cnn.com, got a new fresh design last year, and is one of the finest examples of how to make a site without gradients and without drop-shadows behind each box.

Third:

Hulu.com, only around for a few months now, and a living proof about designing a good site that mainly exist out of white space. (It It is still in beta, but you can get a login within a day, check for some more screenshots here)

three ways to go beyond Web 2.0 design

So what is it that all these site have in common?

1. Grids and white space
Order your site with mathematical precision, create a grid where each column has a certain width, and stick to that format. Another thing is making things stand out not by making them really big, but by adding a lot of white space around it, some things on Hulu just needs to be clicked because there is noting else that catches the eye. Mark Boulton wrote a good tutorial about it, Khoi Vinh wrote a blog post accompanied with a pdf for it.

2. Typography.
There is a lot more into typography than only choosing which font you are going to use. Without even changing the font you can already differ two text blocks from each other in different line-height, different grey scales, and different sizes. Once again Mark Boulton wrote a wonderful series. Another good point to start with is Oliver Reichensteins article about typography.

3. Colors, and shades of grey
I already mentioned the use of different shades of grey to differ texts in importance, and especially sticking to one or two colors and grey can be easy tools to create an attractive yet clean site. Flickr especially manages the grey tones pallet very well. Veerle wrote a good article and ColorLovers and Adobe’s Kuler are worth visiting too

To sum it up: master your grey skills, keep your distance, and get some mathematical madness for order running through your blood. And you will be on your way to go beyond the drop-shadows and big starry things with text in it.

This is the second post in our series on how to run a startup and develop a product. In part one, How To Bootstrap Your Startup, we outlined the process of bootstrapping your company into existence. In this post, we show you how to go from idea to specified product. By the end of it, you’ll know how to build a mock-up of your business idea and write the most important document you’ll write for the company: your functional specification.

For a simple system the process outlined in this post should take you a month. For a complex build, there will be a lot more research and your mock-up and functional specification will be big – so budget 3 months of full-time work.

A Word on Strategy

Every good business begins with a solid understanding of the proposition and business plan – in short, your strategy. It’s worth reading Guy Kawasaki’s 10/20/30 Rule of Powerpoint; it’ll provide you with an idea of what should be included in your business plan and strategy. Your actual business plan should be in a lot more detail than Guy describes in his post – his rules relate only to how the results of your work should be presented, not how the content should be derived.

From Strategy to Development

Whether you are out-sourcing or developing in-house there are two ways to build a system:

1. Give your developers a rough idea of what to build and keep iterating the design as they build it;
2. Give your developers detailed documentation of what to build.

When out-sourcing, the second option is always cheaper, faster and lower risk. Not only that, but the end product will be better architected, more coherent and easier to maintain. Given this, it might surprise you to learn that the vast majority of out-sourced developments do option 1.

Don’t do it – option 2 is more work at the start but entirely worth it.

The basic premise of option 2 is simple: instead of relying on your developers to think through your business properly, you take responsibility yourself. You’ll do this in two ways – firstly by creating a mock-up and then by documenting that mock-up in a functional specification.

Your mock-up

The first thing you need to do is get yourself tooled up is to create your mock-up.

This requires a visual web-editor (assuming you’re building a web-application). Personally I use Visual Web-Developer from Microsoft – it’s free and powerful. However, it is also very complicated to use, as it’s a full web-development environment. If you don’t know how to code in C# then it is probably easier and faster to use Dreamweaver, Frontpage or the freeware KompoZer.

A mock-up is a run through of your site and the learning process you’ll go through as you create it will be exceptionally revealing. It sounds simple, but when you start to put pen to paper you’ll very quickly find that it isn’t. Your mock-up is the first stage of building a real understanding of what your system has to do.

The mock-up should contain no functionality and doesn’t need the final graphic design. Its objective is to help your developers understand what information the system should capture, when it should be displayed and what it should do when the user “does stuff” on your site.

To give you an idea of how it should look and feel, I’ve created a small mock-up of an email service for you to peruse. Granted it is a mock-up for a terrible email service, but it should serve the purpose of detailing what a mock-up should be. When you’re building the mock-up, remember to include an admin interface – believe it or not, it is easy to forget to include this. Make sure you think through how you will administer the system, handle customer queries, examine user accounts, run reports on user numbers and website traffic, etc.

Only when you’ve completed your mock-up and been through several iterations with any other business partners, are you ready to move onto the next stage – documenting it in a functional specification

The Functional Specification

This document is the most important document that you’ll write for your business. It will tell the developer exactly what your system should do. It will contain every page you’ve created in your mock-up; and for each screenshot it’ll explain what’s happening on the screen, what the user can do from there and what the system should be doing in the background. The document is called a “functional” specification because it should describe “what” your system does, rather than “how” it should be done.

The first thing you need to do is get tooled up. Write the document in Word (or an equivalent). You’ll need to include a lot of screenshots – for this I’ve always found the Firefox plug-in Pearl Crescent Page Saver invaluable, because it lets you take screenshots of a whole webpage (not just the part which is displayed).

Secondly you need some software to create flow charts in. I used WizFlow before we bought Visio from Microsoft. Wizflow is easy to use and does most of the stuff you’ll need.

When you set out to write your functional spec, you need to follow a clear structure so that your developers understand what you are saying. The structure which I always use is:

• Confidentiality notice – make it clear that this document is your property and you are serious about controlling your IP
• Introduction – you should describe your company, the structure of the document and a one paragraph overview of your system
• User scenarios – Include at least 5 clearly written accounts of what a user might do on your system. These serve to ensure that everyone who ends up on the development team knows what the system is for. Write them as a chronological story.
• Overview of the system –five page description of what you system should do; keep it very high-level and include a system overview diagram (see below).
• End-user functionality – a section for each system module (see below) in the system overview. Each section should include several sub-sections for each possible action within that module.
• Administrator functionality –section for each admin module and sub-sections for each possible action.
• Non-functional requirements – design integration, SEO, availability and uptime requirements, scalability requirements and load calculation, data validators, security and back-up and the development platform (if you have one).

Clearly in a blog post I cannot cover each of these in detail, but one element which is particularly important is your system overview diagram. Whilst the developers might not build the system in this way, it is useful for you to mentally split your system up into modules. I’ve done a simple example using the email system used in the mock-up:

In the above simple example, the four boxes are the four major sections within the “End-user functionality” section of the functional specification. Within each section you should cover, with precision, what all of the possible actions are and what the system should do in each case. From this it is easy to build out your document structure. So for “user access” we’d need a sub-section on “Create account”, “Log in”, “Forgot password”, etc.

Start by building out the document structure. Only when that is complete should you start filling out all the details. This way, you’ll slowly build up your document without feeling overwhelmed by it. When you are writing one section, you’ll get ideas for other sections – when this happens go to the relevant section and add the thought in square brackets so that you know what to cover when you get to it.

Trust me on this: only one person can author a functional specification. More than one person can review it, but only one person can author.

A Word on AJAX

You seemingly can’t launch a new web site these days without using a few dollops of AJAX here and there. However, you can’t incorporate AJAX into your mock-up, as there’s no functionality. Where there is a functional requirement for AJAX, you’ll need to use a new page in your mock-up (the complete opposite of what AJAX gives you). Therefore you need to explicitly include your AJAX requirements in your functional spec. Personally I insert my AJAX requirements in a box, so they are clear to the developers.

Container Documents

In parallel to writing your functional spec, start the following container documents:

• Future ideas for the development of the system;
• Legal points you want to make sure that are included in the terms and conditions;
• Any design thoughts (include here screenshots of website designs you like);
• Patent ideas;
• Marketing ideas.

As you are working through your functional spec, you’ll come up with lots of ideas in all of these categories (and possible more). Make sure you’ve got simple lists you can just drop them into – get them out of your head and into the computer as fast as you can, so you maintain a clear mental space free from idea clutter.

Conclusion

Creating a quality functional specification is a time-consuming – but essential – job. Take your time and do a quality job. Don’t be surprised if the document ends up being hundreds of pages long. But it vastly increases your chance of delivery.

In the next post I’ll be looking at how to build a long-list of developers, run an RFI to create a developer short-list, run an RFQ to select a vendor and a spare, and then what to look out for in the development contract.

[Ed: Thanks Matt for continuing this insightful series. To see how Matt puts all his theory into practice, check out his own start-up Aroxo. You can sign up for their beta trial using the code "readwriteweb2".]

Only three days after Apple killed it, the JesusPhone walks again, but it doesn’t talk again: By downgrading your firmware from 1.1.1 to 1.0.2 using the method below, all iPhones can get use of third party apps, but If you have an unlocked iPhone, there’s still no way to dial. [UPDATED 09/30 1:19AM EDT: Check our demo video.]

• Make sure you have a copy of the 1.0.2 firmware

iPhone1,1_1.0.2_1C28_Restore.ipsw

stored in:

youruser/library/iTunes/iPhone Software Updates

• Reboot iPhone holding the top button (power) and the home buttons.
• Release the top button 10 seconds after that, right after the screen goes dark. But keep the home (bottom) pressed for a while.
• The iPhone screen will appear to be off. Now start iTunes manually.
• iTunes will tell you it has found an iPhone in "restore mode."
• Press option key and then click the restore button.
• Select the 1.0.2 firmware .ipsw file from here:

youruser/library/iTunes/iPhone Software Updates

• The phone will restart and there will be an error out at the end. Don't worry. It was bound to happen (if the iPhone returns to Restore Mode instead of Activation Mode, then you may have to restore the 1.1.1 firmware, wipe all information in the iPhone and then repeat from above. But first, try to restart the iPhone.)
• Shutdown iTunes.
• Launch the latest iNDpendence (Mac-only for now.)
• Activate the phone using a expanded 1.0.2 file (to do that, make a copy of the 1.0.2 ipsw file, then select "Open with…" from the Finder's action menu and use BOMArchiveHelper.app (it will appear in the menu.) The ipsw are really .zip files.
• It will flash all sorts of errors, but don't worry.
• Activate the phone.
• It will show the SIM error but now the iPhone will work again with your Wi-Fi and your apps.

No, the unlock won’t work and you won’t be able to call, but all the rest will work again. [Hacint0sh]