Facebook Cookbook - Jay Goldman [43]
Frame the problem
It might be my human-factors background talking, but I never start writing code on a project until I have a full set of complete user experience sketches. A lot of the problems you’ll run into writing code will become apparent as you design the user interface (UI), but the opposite doesn’t tend to be true, and you end up with a so-called “implementation design”: a user interface that exposes the underlying implementation, which is often irrelevant for your users.
I start this process by doing wireframes for every page and dialog so that I know what’s going to be in them, what content I need to write for instructions, buttons, etc., and which graphics I’m going to need to produce (or get produced). There are about as many formats and techniques for doing wireframes as there are minutes in the day, so I suggest that you just experiment until you find something that works for you. Some people prefer to do wireframes in static HTML (and then use it as the basis for implementation), others prefer tools such as Visio or OmniGraffle, and others really dig old-school paper and pencil. The important thing at this point is to sketch out a UI and spend time thinking about how the different parts interact, rather than shading every button and getting the colors exactly right. Don’t get hung up on how it looks just yet, but instead focus on where the big pieces are on the page and how they interact with each other. Think of this step as creating the architectural blueprints that will define your application rather than the interior design or construction technique you’ll use to build it. The main page of the Photos app might look like Figure 4-7.
Figure 4-7. Photos app wireframe
Once you’ve laid out a page, go back through and make sure you know where each link and button goes. Plan out the interaction for any dynamic interactions (e.g., Ajax), and identify where you’re going to use a standard Facebook control or roll your own.
If you went through the persona process in the earlier step, you can now use your personas to evaluate your wireframes as you go through this step. If you didn’t use personas, or to supplement them, you can use wireframes as ultra-low-fidelity prototypes to run actual users or potential users through quick sanity checks. Sit them down and ask them to accomplish some of the goals from the previous step, using your wireframes as though they were real software, and see where they get stuck or confused.
Making a mockery
Now that you have your blueprint done, it’s time to get creative! If you’re not the designing type, find someone who is and pay them to do this step for you. User engagement increases dramatically when software looks good, and the tiniest details will make a huge difference to the overall impression of your app. Take a break from reading this recipe and have an honest moment with your ego over in the corner. Are you the right person to do this? Most developers aren’t, so don’t be afraid to admit that you might need some help here.
If your wireframes share a lot of similarities, there’s no need to mock up all of them. Just concentrate on the differences between them, and you’ll produce enough artwork to cover the development phase. If you have the time and resources to do so, it’s well worth running your designs past some potential users to see what they think, but remember that everyone gets really emotional about design, so some of the feedback you get here will be very specific to the individual giving it and not particularly representative of your users at large. If you do this step properly, your mockup and your final build will end up being virtually identical. Based on the Photos app wireframe outlined in the previous step, the mockup might look like Figure 4-8.
Figure 4-8. Photos app mockup
Build it!
That’s it! If you’ve made it