Designing a web 2.0 application
by Naneau
In this post I would like to write a little about application development for the modern web. There are a lot of tutorials out there that deal with specific implementations of (parts of) applications. But I want to go a little further. Instead of looking at how to implement things, I would like to start at the absolute beginning.
I have found that most tutorials and articles only cover the basics of application design. They assume there’s some kind of general plan, and they start from there. This is fine, if you want to speak about how get things done with a specific framework, but sometimes it’s better to just start… From scratch. Like Jamie Hyneman always says: “Think before doing.” Of course web applications will not explode if made improperly, but their users might.
Before you start planning anything, you have to ask yourself why you should do that in the first place. This sounds trivial, but it’s really not. Ask yourself what you’re going to develop and why. Who has a need for it and how big is that need. Think about your application in the broadest way you can, write a description in a few words, and figure out whether there’s a real need for it.
Depending on how serious you are, you may want to involve other people in this step. Or the other way around, depending on how serious other people are, you may get involved. If you get asked by some hip company to develop something for them, it’s still a good idea to take a moment to ask them “Why do you want this? What do you want from it?” Don’t be afraid, if you ask for it politely, they will probably appreciate it as it shows you’re serious about what you do.
If you have found there is a serious need for a new application with that very broad definition, it’s time to narrow it down. It’s time to start designing. It’s probably the most important that you stay informal during this step. For programmers, who want to see things from a ’solution’ perspective, this is often incredibly difficult. But remember that the end users probably aren’t programmers, and you’re making something for them.
During this step you’ll be a “requirements engineer“. That sounds nice, doesn’t it? Basically what you’re going to do is ask around and find out what people want from the application. Please try to remember that this is not about programming, this is about discovering what people would like you to make. If you are developing something for yourself, you’re going to have a little chat with yourself.
Write down what you discover. Write everything down. Depending on how large your application is, and how many users will use it, you’ll end up with a lot of paper on your desk. If you are good, you will also design a few use cases. Only when you can honestly say that you have asked everybody who will come in touch with the application, you can start making the actual design.
If you did things properly, it took quite a bit of time before you got here. Designing can be a time consuming process as well. Start from your informal requirements and work towards a formal model. You will probably need quite a few steps. I often begin with finding all the entities and drawing lines between them. Like a very simple ER-diagram. Then I start scribbling fanatically next to those lines, writing down everything that’s important. I mix data design, constraints and other requirements into one inky mess.
I then end up with a very messy piece of paper containing a lot of thoughts. While it’s messy, it’s a good start. It’s the first time you get a good global look at what you’re designing. If you’re working in a team, it’s nice to see other people’s perspective. Hold a meeting, compare messy papers. If you have a large application, divide it. Start grouping, now! Work towards some kind of a general design, a global model.
That was the last of the informal steps. From now on you’ll be doing serious design work. Turn back into your normal programming self. Think solutions. Think classes, methods and properties. Want to do Ajax? Sure! Go for it. Now you can turn to those tutorials and find out how to do things. Just remember, analyzing what you want to do and why, and creating good models for your application, will save you time and frustrations.
Comments
Thanks for this approach. Itsa the kind of information I’ve been looking for. After years of procedural php programing I have only just started to get to grips with OOP, Design Patterns etc. Its good to see that there’s someone out there who is afraid to discuss “the obvious things”.
Thanks for this approach. Itsa the kind of information I’ve been looking for. After years of procedural php programing I have only just started to get to grips with OOP, Design Patterns etc. Its good to see that there’s someone out there who is NOT afraid to discuss “the obvious things”.
[...] Naneau » Designing a web 2.0 application – Also a good article on web2.0 apps [...]