How do I design a simple web application?

Question

I have basic knowledge of PHP and had done a few small personal projects before. Since my programs were small and usually consisted of less than five classes, I jumped into coding right away -- thinking of my database tables and user interface design as I went along. The problem was that I often found myself lost in my own ideas at the middle of my project. Hence, I thought that some form of formal planning would be practical to begin with.

I have been reading several software engineering books lately. One book said that, in web engineering, agile processes such as extreme programming and scrum should be used. I was introduced to tools such as use cases, CRC cards, and UML -- all I believe are too complicated and impractical for the simple projects I have in mind.

On the other hand, a web article I read simply suggested a rough sketch of the UI, a sitemap, and a simple workflow diagram. They seemed practical but too rudimentary and informal.

What would be a practical but formal approach to building a simple web application?

Answer 1

You have to ask yourself a few simple questions first:

1) Do I want to re-use and extend this code later? If so, it may be a good idea to use some basic pattern such as MVC (Model-View-Controller) or use one of the many PHP frameworks available. The already established frameworks are more format in their design and how you use it. You could always use them as a basis to design your own as well.

2) Is the site you are making going to grow or change frequently? If the site isn't going to change much you could probably make something very simple and not worry too much about good design principles.

3) Do you want to learn and apply some of the techniques you mentioned? If so, then go to town and try the different techniques and see which ones appeal to you.

These kinds of questions will help you decide how you want to decide you build your website.

Answer 2

Start small, mock up a few simple screens, their database structure, etc. Use whatever method works for you - if that is UML diagrams, then fine. Get something finished, evaluate, and iterate from there.

This may not be quite what you are looking for, but also do yourself a favor and choose a framework such as CodeIgniter to make your life easier writing your server-side code. And similarly, consider using a client-side framework such as jQuery. This will make it easier for you when you are ready to actually sit down and write the code.

Answer 3

Don't be so quick to discard use cases, or some similar concept, e.g. 'user stories'. The benefit these tools bring is to make you think about what the site needs to do. That can guide all the further technical work, and help you focus on what's important instead of getting lost in interesting but low-value work.

Think about the top n things the site needs to do, and for each of these list out:

• the ultimate goal for the user in this particular case
• the kinds of people and other systems involved (actors, in use-case terminology)
• what needs to be in place before starting this activity (the preconditions)
• the basic steps the primary actor needs to perform to successfully achieve the goal
• what should happen if one of those steps can't be completed
• what the system looks like if the case is successfully completed (the postconditions)
• what the system should look like if there were errors along the way

With a handful of these use cases, you can get an overall feel for what needs to be built to fulfill the goals. If it starts to look like too much work, you can look at which goals are of greater or lesser importance, and cut or defer those that provide less value. And if you think of new things the site should do, the existing use cases either:

• provide a home for that feature, so modify the appropriate use case to incorporate the feature,
• don't provide a home, indicating you missed a use case or discovered a new one, so you should elaborate on it as described above, or
• don't provide a home, and therefore indicate the isn't necessary and so you shouldn't spend time on it.

The trick is to pick the proper level of abstraction and formality. Work at a high level, write informally, and you can knock these out quickly. When they're no longer useful (you have most of the application sketched out and are now heads-down working on details), put them aside. When you think of new things, see if they fit. Lather, rinse, repeat.

Answer 4

The Bare Essentials

I find there is a (roughly) four-step process that make application development a lot easier, and helps me avoid getting lost along the way. I make no pretense about using agile development methods. This is just the way I work.

1. Decide what the application needs to do. By "need", I mean, absolutely must do and nothing else. If it's a "nice to have" feature, write it down and come back to it later.
2. Figure out what data you need to keep track of to make everything work. Slugs, titles, datetimes, etc. Design the database. (I use MySQL Workbench for this.)
3. With your feature shortlist, prototype a user-interface with Balsamiq. Remember to add only the features you need right now.
   • You might consider doing HTML / CSS templates in this step.
4. Now that you have the data model and the UI, connect them. Business logic should focus on two things:
   1. Abstract away from the data model so you can easily retrieve and store information from step 2.
   2. Make the UI work exactly as you designed in step 3. Don't get fancy.

Focus on Small Goals

There are two keys to the process. The first is to to separate the design of various components. You don't want to be thinking about implementation details when designing the UI, etc. The second key is to iterate. Focus on exactly what you need to add right now and ignore everything else.

Once you're done, you can iterate and tweak, repeat steps 1-4, etc. But don't get stuck in any step for too long. You can always iterate again later if things don't turn out exactly as you like. (I think agile calls the iteration "sprints", but I'm not up on the theory.)

Practical Considerations

It helps if you have a light framework (at minimum) to assist with 4.1 (ORM, like Propel) and 4.2 (JQuery, etc.). You want to keep both the UI and data access as modular and compartmentalized as possible so it's easy to change later.

If you mix everything into one chunk of code, then you'll have to change every part of the program just to (for instance) add a new column to the database or add a new button to your app. You've had some experience, so you should have an idea of pitfalls to avoid.