Top Down Development Approach

The “Top Down” development approach is something that I discuss a lot but don’t often get the opportunity to practice due to other restrictions. It is an effective way of implementing “User Centric” Development.

Essentially the concept is that you work from the user’s perspective down, rather than thinking through the requirements to come up with the domain model, class models and the like. The reason that this is beneficial is that you focus on what the user actually requires to do, not what the system expects them to do. And that is the first step towards building systems that employ best practices in usability. There are many methods and practices that are already used from a ‘technical’ perspective (such as Behavior Driven Development), but I try to look at this as a holistic development approach.

I have gone to some extent to try and formalize this approach and it is something that I am using in the development of the Its4aCause web site. I have broken this into essentially 9 (quite detailed) steps of the project. They are;

1. Concept

The concept is the start of the project. This is your elevator pitch, twit-pitch or the ‘back of napkin” concept that you capture. Do not omit this! It is actually the pure idea that you initially conceive and you should constantly come back and validate it. You will need to evolve this into some kind of 1-pager that you can use as your ‘brochure’ whilst working on the project.

I personally like writing a concept paper that is no longer than 2-3 pages with pretty pictures. This is something that you can share quite easily to make sure that anyone that reads it, gets your idea. It describes the concept, the user experience, the benefits for all involved and finally the business model. This document (and your concept in general) may change over time, but make sure you validate this as you go. Only change it if you feel it SHOULD change, not because something in your project has changed and you are ‘forced’ to change this. This should set off warning bells.

2. Brainstorming

Brainstorming is also an important step in the process. We all do it, and we do it at different levels of detail.  We work through our idea (“concept”) and start working through the details. When building software, there are two important qualities that you must identify in your brainstorming session;

a) Is there a Business Model? – Is there an actual model that is worthwhile doing? Start thinking through the detail of the execution, and if the idea is going to be valid and ‘doable’. Many a time, the whole thing will fall over when trying to work out how to do it, or how it will make money. You may find out that your idea may not be economical to execute, or the technology doesn’t exist or is too expensive. Brainstorming is the time to identify this.

b) Know what you don’t know – During brainstorming, you are trying to fill in the details. But its the gaps that are more important. And that is what you REALLY should take away from your brainstorming. That means identifying, that you “Know what you don’t know”. What is it? Well, by not identifying these items, you are entering the whole thing blindly. You handle these items by identifying what you don’t know, and how you will resolve it. For example; “We don’t know how this application is going to scale, we need to consult with someone that has worked on high transaction systems” or “We are unsure what the business structure is going to be, we need to discuss this with a lawyer or accountant.”

3. Paper Wireframes

See how we have jumped straight to our screens? We are not talking about the database design or the technology, we are talking about what the user will use. That is because we will be building the whole application from the Top-Down. Paper wireframes can be exactly that, where you start scribbling screens out onto paper or whiteboards, my preference is to prototype user interfaces using products such as the great OmniGraffle on the Mac. The important part of Paper wireframes is that you a) focus on the user experience, b) focus on what is important, c) determine the interactivity within the application & d) Test your application in the early stages. It is beneficial to do this with Paper wireframes so that you are not distracting the application with “Design”. That should come next.

One thing that I would like to add, is that I do practice a type of Agile methodology over the top of this. I am not strict with Agile (can’t exactly pair program on my own), but I definitely like to capture my User Stories in a tool. Sometimes that tool is an Excel document, but I recently purchased a copy of Jira and am using that. I generally build up my stories and think about a release schedule on what I need, but I find that my wireframes (and sometimes as early as my brainstorming session) I can start putting the stories together that I will need to deliver.

Additionally, you would have seen in a previous blog post that I like writing scenarios. Scenarios are creative writing pieces that describe the application. They are the commentary that accompany the wireframes. In many instances, I will build my wireframes to satisfy my scenario. The Scenario is usually something that is written during the brainstorming and wireframe process.

4. UI Design “look & feel”

In many ways there is no reason that you can’t work on this in parallel with the wireframe design. This is when you start focusing on the main screens of your application and the User Interface. Remember its a Top Down approach, so the UI is important in the early stages. Along with the Wireframes, this will communicate what the end application is going to be. At this stage, you need to focus on what the main pages in your application are – the ones that are going to be used the most. There shouldn’t be more than 2-5 of them in your initial pass. Aim to get these right.

After you have your wireframes and your main UI, its time to look back at your concept and make sure that you are still on track!! Have you lost the plot or are you still focused on your initial goals and is it all still valid?

5. HTML Screens

After you have the layout of your design and application wireframes, it is time to start working on the screens as they will be implemented. That means starting to decide on CSS frameworks you may use as well as Ajax frameworks as well. This may change, but it is certainly less work later if you can make a commitment now.

Try and build the whole web site in HTML, simulate as much of the Interaction and links as you can, but don’t start building stuff that you will throw away. A  good example, is don’t start building Ajax interactivity where lots of it will be generated by your App framework.

This is a great step in your project because you start seeing what the final result is going to look like.

6. UI/Controller Layer (Stubbed Actions)

Now we start REALLY building! After you have your HTML screens its time to start wiring it into your application framework. And this is another reason why I love the GRAILS framework so much. It is soooo easy to do this. The process I go through is to go ahead and create the application “grails create-app”, and then I think about the controllers I need. Usually, I will (at least) create one controller per main menu item (rule of thumb), and use Marc Palmer’s brilliant Navigation plugin to create my navigation menu. I will write a separate post on this whole process for Its4aCause, but the useful thing is by the time you get to this stage, you are actually creating the application that you can navigate.

7. Tests & Stubbed Service Layer

This is when I start adopting some TDD (Test Driven Development) practices. Nothing very different here, although I have a UI! In fact my UI is probably 90% complete now (minus anything specific that the App will generate – try to keep this to a minimum to help maintain your application). I start stepping through my application (the stubbed one that I created in earlier steps) and start writing the actual functional code. I do this first by writing my tests, ensure they fail, and then write the code that make them pass.

The tests should be driven by the User Interface that has been designed, the stories I wrote in Jira, as well as the Scenarios that were written during Steps 2&3. Remembering that your scenarios will never be the complete product, but the pre-alpha should demonstrate the scenario that ’should’ be discussing the most critical parts of the application.

I mention a “Stubbed Service Layer” in the title, because this ensures that I stick to the disciplines of passing business logic off to my Service layer rather than writing it within the Actions of my Controller layer. At this stage I decide what needs to be a Service, create that service and stub the expected behavior there. Remember to plaster //TODOs everywhere to make sure you don’t forget about any of these

8. Service Implementation & Data Layer

Wow, Step 8 of a 9 Step methodology and we haven’t written any functional actual code yet!!! WTF! Well, in reality, you should now be 80% there and the code you write should be straight forward. Now you start building up your data layer and create the domain objects and start implementing the Service layer. Don’t get me wrong, you are not going to write all the tests for your application and then the implementation in this step. Steps 7,8 & 9 are actually an iterative process that you would expect to do in a typical Agile fashion.

I do this by planning my current iteration in Jira, and map out the stories that I am going to work on. I then go ahead and write the tests for that first story, and then the services, I then stub the services, and finally write the code. OK, I just said something controversial “Stub  the services” Most people want their tests to fail, before actual code is written, and I do to. But I will also make sure that I know what has to happen to make the tests pass too.

9. Utility Classes

Finally, this is the cleanup. Time for some heavy refactoring. Although I am giving this phase the title of “Utility Classes” it is time for a general clean up. This happens as you go, but you start to find better ways of doing things, or ways to optimize your application, or remove repetitive code.

Conclusion

So what is the benefit of all this? Well, you would expect to have cleaner and more structured code, particularly in relation to how it interacts with your User Interface. Many of the methodologies that developers have available to them focus on the back end, particularly the data and business layers. But very little focus is spent on trying to make sense of the UI layer in the mix. This methodology fixes this. I have tried this methodology with great success in smaller projects, so lets see how it goes with Its4aCause!!!

1. 

   website design delhi says:

   November 16, 2011 at 1:53 am

   I happen to be writing to let you know what a nice encounter my girl had studying your web site. She realized some details, with the inclusion of how it is like to have an awesome giving nature to let most people quite simply completely grasp various hard to do things. You really exceeded our own expectations. Thank you for supplying those interesting, trustworthy, edifying and as well as cool tips about this topic to Jane.
2. 

   Roberto Kemme says:

   December 20, 2011 at 12:39 pm

   hi,good apple in your publish,I love thatelegantapple,I require to locate one particular for me