Instead, I'm going to roll my own, and show you how I did it. Before I get started though, I'd like to take a moment to talk about user experience design.
User Experience DesignUser experience is, at it's core, concerned with one thing: how do users feel about your product? Is it intuitive? Cohesive? A delight to use? Or is using your product the pain point of a person's day? User experience designers, therefore, are engaged in the process of creating a positive user experience. This is accomplished by researching user needs, designing a solution to meet those needs, and validating the proffered solution with user testing. Before user-centred design became the standard approach to designing software, designers approached projects with only a superficial understanding of it's intended users. The design was based on what the designers thought the client wanted, as opposed to what they actually needed. The result was often disappointing.
If your app is clunky and frustrating to use, you can be sure that users won't stick with it for long. Creating a product that no one wants to use is a futile gesture, and a sure-fire way to bankrupt yourself in the process. This is why UX is so important! Customer loyalty? Employee productivity? User satisfaction? All are affected by UX, and all directly affect your bottom line.Okay, you're convinced. UXD is great. So where do you start? User Surveys? Personas? Wireframes? Usability Testing? Unfortunately, there is no right answer, no magical combination of UXD techniques that, applied to a project, will always guarantee a perfect outcome. But you can be assured that any effort you make to learn more about your users can only yield positive results. Less uncertainty means less time spent in fruitless debate, a smoother build process, and a better end product.
Now that I've highlighted just how important UX is, I'm going to dive straight in at the deep end with some user stories. As a developer, I find that this is the best way to nail down a feature set, because each story represents a feature, and each feature is an actionable, measurable, and (most importantly) testable step to getting a product shipped.
Planning Features using User StoriesThe template for a user story is as follows: As a user role I want feature so I can benefit. Using this template, we can describe all of the features we want the app to have. Let's create the first user story for our book catalogue.
As a user, I want to be able to create a book record and save it to a list so that I can see which books I'm currently reading.This one is pretty straightforward. In fact, this story represents the functionality of the app at it's most basic level. It's safe to say that similar stories will exist for the rest of the CRUD (create, read, update, delete) paradigm, so lets skip over them for now. (As we're creating a single-role application, I'm going to forgo writing 'as a user…' for the remaining stories.)
… I want to be able to pre-populate a book record by searching for the book online, so that I don't have enter a record manually.Straightforward at first glance, but how should you be able to search specifically?
… I should be able to search by title, author, or barcode, to make it easy to enter a book record.So, this feature confers a time-saving benefit. Imagine, though, that this were a commercial project. What if the project planner just assumed that the user should be able to search by title and nothing else? It's not a great example, but you see the point I'm trying to make - loose ends can be a disaster for your project, so it's best to keep asking questions until there are no more questions to ask. I'll probably use the Amazon or Google Books API here, and there's an open source PhoneGap plugin I can use to read barcodes with a phone's camera, so I have this part covered.
… I want to be able to view books by category, so I can see the different genres of books I'm reading.This is a utility benefit. I read technical books for work, and sci-fi books for fun. It would be useful for me to be able to differentiate between the two at a glance.
… I want to be able to archive books that I've read, so that I only see books that I'm currently reading.If we don't separate 'current' books from 'completed' books, we're going to end up with one long, not very useful list. Perhaps we could create a separate view for archived books?
… I want to be able to export data from the app, so that I can import it into other applications.A user's data belongs to the user, not to your app. They should be able to use it elsewhere (Goodreads, for example) if they choose to. I'll export the book list to CSV and JSON, saving each as a document with the help of PhoneGap's FileWriter API. Also, backups are always useful. I lost a portion of my ReadMore reading list when I upgraded to iOS 7 beta, and I was incredibly annoyed about it. So, I'll enable Document File Sharing in iTunes - any files exported will be accessible in here (it's just a simple case of drag and drop to the desktop), and they'll also automatically be saved with everything else when the user initiates a device backup. These user stories describe the entire feature set of our application. In part two I'll show you how to translate these stories into actionable steps with Behaviour Driven Design (BDD), but right now I'd like to talk about the UX challenges creating a hybrid app presents.
UX SketchingOn to sketching. I'm terrible at drawing, but sketching is always a useful exercise. The real value of sketching lies in how quickly you can spot obvious problems - a textual description of a feature can mask problems that will leap out at you when you put pencil to paper.
My all time favourite post on UX sketching is by Peiter Buick over on Smashing Magazine. In his article, The Messy Art of UX Sketching, Peiter delves into the power of UX sketching, and discusses the tools and techniques behind it. He explains it much better than I could, so it's well worth a read.