Hello, and welcome! I’m going to show you how to create an iOS application – from start to finish – with HTML, CSS, JavaScript and PhoneGap.
In this first part, I’ll be planning the project. I’m going to start by discussing the importance of User Experience (UX) design, deciding upon features, and finishing off with some sketches. In part two, I’ll get down to prototyping the UI. In part three I’ll write failing tests with Jasmine. In part four, I’ll develop the application; and finally, in part five I’ll finish the app by wrapping it with PhoneGap, and deploying it to an iPhone with Xcode.
We’re going to create a really simple book cataloguing application, inspired by my personal experience with ReadMore (iOS).
ReadMore is an app I’ve used since 2010. It keeps track of the books you’re currently reading, books you’ve read, etc.; but it also logs how long it takes you to read each book. It’s a great little app, but the one big downside for me is that the time tracking functionality is tightly coupled with the archiving functionality. Time tracking is a feature I’m not interested in, but the app requires me to enter (fake) time data in order to save a book to the archive. I just want to be able to see, at a glance, the books I’m currently reading, and books I’ve read.
If I was being sensible, I’d simply browse the App Store for a suitable alternative; but that wouldn’t make a very interesting blog post.
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 Design
User 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 Stories
The 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.
Hybrid App UX
User needs are one rung on the ladder of user experience. Your choice of tech stack can present it’s own problems.
Using a hybrid app can sometimes feel like you’ve taken a trip to the Uncanny Valley. The app may be work perfectly, but it doesn’t feel the way you expect it to. This is the unavoidable consequence of using a WebView; instead of having native controls and components to work with, you have to create everything from scratch with HTML, CSS and JavaScript. Users, accustomed to a platform’s behaviour, expect your app to follow the same conventions. Often this expectation goes unmet, and users can become frustrated with your app as a result.
For example, a button, if bound with a standard click handler rather than a touch handler, can take 300ms to trigger it’s associated event when tapped. 300ms of latency will not go unnoticed.
So, why bother with hybrid apps at all, why not just go native? Developing a hybrid app is still the fastest, most cost-effective way to get an app built and deployed across multiple platforms. The issues cited above only tend to arise when a developer takes a one-size-fits-all approach to building the app. Hybrid apps are not a panacea; if you plonk the same codebase down on iOS and Android without any modification, you’re going to have a bad time. Care must be taken to meet the expectations of users on each platform you intend to deploy to.
UX Sketching
On 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.
Next Time…
In the next tutorial, I’ll be prototyping the user interface, and writing failing tests with Jasmine. Stay tuned!
Further Reading
Coding Horror – Avoiding the Uncanny Valley of User Interface
Smashing Magazine – Effectively Planning UX Projects