Beautiful Interfaces

Now that I know roughly what I want to build in my app, it’s time to pick a UI framework.

Evaluating the libraries

I looked at 3 javascript frameworks that are geared toward mobile/touch development: YUI 3.2, Sencha Touch, and jQuery Mobile.

YUI 3.2

Pros: I use YUI 3 a lot at my day job, and in general I like it a lot. It’s a mature, capable library with some very smart folks working on it. They haven’t historically focused on mobile/touch, but in this recent release they added touch event support, gesture support, and support for css3 transitions. Also, the library is very modular, so it would be easy to keep the filesize small.

Cons: Has only one mobile UI widget – the ScrollView. And when I loaded up the ScrollView on my Droid Incredible (running Froyo), it didn’t work. I found this very disappointing, since Android would be a major target for my app.

They have no publicly available browser support policy for mobile devices, although I’ve been told they’re working on one.

Conclusion: It’s not ready yet, but has the potential to become a really good mobile library.

Sencha Touch

Pros: They’ve taken all of the visual elements of an iPhone app, and recreated them in javascript.

Cons: They’ve taken all of the visual elements of an iPhone app, and recreated them in javascript.

Ok, but seriously – Sencha is a very slick-looking framework. They have a full complement of UI widgets, and they look great, if a bit iPhone-specific for my tastes. All of the demos worked beautifully on my iPod Touch running iOS4.

But their stated browser support is pretty narrow: just iOS and Android, and some of their demos were buggy to non-functional on my Droid. Furthermore, there’s no possibility of progressive enhancement – the page is assembled completely from javascript, so it’s all or nothing. Either the user is on a device that Sencha supports, or they’re out of luck.

Conclusion: It’s not ready yet. Furthermore, it doesn’t really provide the breadth of support that I’m looking for. But iPhone developers will love it because it provides a familiar model, and it doubles the number of platforms they can target.

jQuery Mobile

Pros: Because it’s jQuery, there’s a huge developer community built in. Claims to support a huge variety of different browsers and devices. Full set of proposed UI widgets that look great.

Cons: Not actually released yet, so who knows if it will live up to the claims. Plus, jQuery is less modular than YUI, so I’m concerned about the size.

Conclusion: It’s not ready yet, but has the potential to become a really good mobile library.

After looking at these three, I’ve come to the conclusion that there’s no javascript library in existence right now that does exactly what I want. A lot of smart people are working on a lot of great stuff, and it’s all really early in development, and it’s just not ready.

Having come to this conclusion, I started to ask myself whether I really need a javascript library at all. On a desktop app it doesn’t matter as much – a few wasted kilobytes are no big deal over a high-speed connection, especially when the most popular libraries are likely to be cached. And the niceties that they provide make development a lot more fun.

But I think when you get to mobile the equation changes, for two reasons: browsers are more similar, and waste is much less tolerable.

A big part of the value that javascript libraries provide is normalizing between IE and everyone else. But there’s no IE in the mobile realm. (Well, there is, but it’s small enough that I can happily ignore its existence, and plan to continue doing so.) So it becomes a lot less annoying to work in plain javascript. There are still a lot of browser differences, but at least you don’t have to write everything twice.

But even more importantly: when you’re on a slow, spotty connection and every download drains your battery, any amount of waste becomes intolerable. And there’s waste when you use any javascript library – even with a modular one like YUI3, you’re never using every single line of code that you pull down.

If you want people to keep using your app, speed is the second most important thing you must have. (The most important thing, of course, is that it does something useful or entertaining.)

So, my conclusion is: none of the above. I’m going to develop BrewTracker (our working name) without relying on any javascript library or UI framework. (If I really get annoyed by this I might turn to a very bare-bones library like XUI, but I’m hoping I won’t need to at all.)

I’m going to attempt to be minimal and efficient in my javascript, and truly follow a strategy of progressive enhancement. I’m going to avoid making heroic efforts – like recreating momentum scrolling in javascript – for small design wins, like the ability to have a fixed-position bottom nav. And I’m prioritizing broad accessibility and usability over flash and flair. After all, everyone likes beer – even people who dare to use a Palm or a Blackberry!

Coming up next: I try to persuade Andrew and Dom to guest-blog about BrewTracker’s design.

In my last post, I introduced the mobile app project that I’m going to undertake. Today I took the first step and sketched out the UI of my app. From this, I can get an idea of the number of different screens (don’t call them pages!) and how they connect, as well as the different UI elements that I will need to either get from a library or create on my own.

The home screen

This is what you will see when you open the app or visit the site, and are already logged in. (The whole login/account system is something that I haven’t looked at yet. I just know that I want it to be super-simple.)

It presents the four main things that you can do: browse your beer notes, add a new note, search for a beer, or look at a random beer from the database.

(Note that the title is wrong in these sketches. I was going to call the app Beer.Me until I realized that’s already taken.)

Adding a new beer

This needs to be super-simple, because when you’re hanging out with people or conversing, you don’t want to spend a ton of time typing into your phone. Key design principle: Don’t make your user look lame!

Because of that, the ability to grab a snapshot of the label using your camera phone is key. I could envision myself doing that to remember a beer that I liked, and then filling in the rest of the details later. (This implies that we need a way to remind the user of incomplete notes, and prompt her to complete them. This may or may not be another screen.)

I avoided the typical 5-point star rating scale, because I think it’s often overkill. I’m not sure that my opinions on beer are fine-grained enough to support five separate divisions of feeling; I tend to think of things as liked or disliked, with a few standouts that I particularly love. I threw in a “hate” button too, mainly for symmetry’s sake, or to remind yourself of something terrible that you never want to try again.

Browsing your notes

Just as important as adding a new note, is the ability to go back and easily look over the notes that you’ve created.

The browse screen is fairly simple: it offers a segmented control with 4 different ways of organizing your notes, and below that a simple list. Touching a beer on the list will slide over to that beer’s note, in the standard iPhone-ish way.

Here’s a sketch of the screen organized by name:

And here’s an example organized by the name of the brewery:

The two other views would look similar to this one, with subheadings on the list for category or for the date the note was entered, and entries alphabetically within that.

Viewing your own notes

From the browse list or from search, you would have the ability to view a note that you had previously made. This would include your information, of course, and also some global stats about that beer, if anyone else had noted it as well.

The global stats bar would double as a filter of the other people’s notes below it. You could tap on any particular rating and the section would filter to only show notes by people who had assigned that rating.

Viewing other beers

Of course, you might want to get information about a beer that you yourself haven’t tried yet. This part would only work if lots of people were actually using the app, which is why I see it as secondary. Nonetheless, by searching for a particular beer or by hitting the “Random Beer” button, you should be able to review the notes for any beer in the database.

This is what that screen would look like: it’s basically the same as the previous one, without the whole “your notes” section and with the addition of an info thingy telling who first noted this beer. (The hope is that including this would motivate people to note more beers, in the hope of being the first person to do so.)

And there you have it. As noted, there are a few things missing, like a search results screen and any kind of account/profile management stuff. But I think that these are the core items that give me enough information to start planning out the app.

Coming up next: Picking a UI framework, or not.

Given the way I keep falling into mobile work, I’m apparently destined to be a mobile web developer. (If you know me, you know why this is funny — I hate talking on the phone, and avoid it at every opportunity.)

Because of this, I’ve decided that I need more practice at creating cross-platform, web-based apps. I have some experience with the iPhone SDK from a project earlier this year, but I’ve come to believe that web-based and cross-platform is the ideal way to go.

I’ve decided to start a project to create a mobile web app from start to finish, and I’m going to blog about it each step of the way. I’ll talk about the various decisions that I face, like choosing (or not choosing) a javascript framework, and the challenges that I will no doubt run into.

The app that I’m going to make is based on something that I actually want for myself, which makes it easy to design. It’ll be an app basically geared toward beer snobs (or connoisseurs, if you’re being polite), that lets you keep track of beers that you’ve tried, take notes on them, rate them, and see notes and ratings from other people. There may be apps around like this already; I don’t really care. I’m not in it to make money, just to gain experience with mobile app development and create something that I personally like.

I’m tentatively calling the app BeerNotes. Over the next week or two, I’ll be working on the design of the app and making the various technical choices required to get started. After that, I’ll move into talking about implementation. So, come back to see how it goes!