You’ve likely seen postings already about how iOS device sales over the holiday influences app sales and related services, so I thought I’d share what happened with WOD since Xmas. In short, it’s good for me. The average over the past three days has been 50% greater than the average over the rest of December.
And, a pretty little graphic showing this:
Working on something. I like it a lot.
Link: Opera Mini Countup
Opera is taking an interesting position with regard to the submission of Opera Mini for iPhone: making the waiting period very public.
Link: Final Fantasy for iPhone
It’s still downloading, but I still haven’t picked my jaw up off the floor. This will probably beat working, oh yes it will.
I noticed that another CrossFit iPhone app appeared on the App Store, which, automatically, made them my competition and therefore mortal enemies.
Just kidding.
But I still think my app is better, and I want to tell you why it is, not only because I want people to purchase my app instead of theirs, but more because I think apps like this don’t do much for the mobile application marketplace: they aren’t of any quality, don’t have any sense of design, and otherwise basically command the very cheap price attached to them. The problem is that it’s difficult to make a decent application that can survive, if it’s swimming in an ocean of mediocrity.
But to the app, which I did purchase, so I could try to give a fair review for it.
The thing I like the best about this app is its apparent focus on a core function: starting a workout. The first screen after the app loads is a big wheel with workout names, a button that lets you select that workout, and a button that selects a random workout. Selecting a workout brings you to another screen that describes the workout, and has a big green button that starts the workout (e.g., it starts a timer, or opens a “score card” kind of interface). This is one thing the app does right:
The most common function should be the most obvious one in the interface.
At the description screen, you can also look at the workout, broken down into the various movements. Now, the first time I played with it, I chose “CrossFit Total,” and saw that the third lift (Deadlift) in the list (that is, in a UITableView) had a bug: the disclosure indicator was the wrong one. Instead of the expected plain gray chevron, it was the white chevron in a circle — the former means “tap this entry to bring up detail on this item,” while the latter means “tap this circle to edit or view detail about this item, aside from the function that tapping the item itself does.” And, when I tried tapping the “Deadlift” item, the app crashed.
This should be rule number one about developing a mobile app, or if not #1, at least damned near the top of the list:
You cannot have bugs in basic navigation in an app, ever.
A bug like this indicates one thing: a novice programmer. Learning while shipping is OK, for indie developers with limited resources. I’m in the same boat, since I’m learning a lot while shipping an app. But if you’ve clearly just started learning how to develop for the iPhone, and ship a product with bugs as fundamental as this, it is seriously difficult to think how you can demand a price to be paid for that app, even if it is only 99¢.
Tapping on a movement — when it works — brings up an sequence of photographs that show an athlete performing the movement. This is a decent way of illustrating a movement, and it was something that I originally conceived of having in WOD: photographs, illustrations, or videos/animations of each movement. It would have taken a ridiculously long time to produce these, however; it even took too long to write up a brief paragraph that explained the movements in WOD, and I don’t think I did that great of a job.
But the thing I realize now is that:
An application on your phone is not a replacement for a coach.
You likely fall into one of two categories, as far as CrossFit goes:
You have never worked out at a CrossFit gym, and may only be familiar with some of the movements or lifts used, or
You have been doing CrossFit for at least a short while, and have learned the movements and lifts involved.
If you are in group 2, I find it unlikely that you will need a reminder about how to perform a clean and jerk. A description or illustration of the movement is hardly of any use.
If you are in group 1, an application on your phone will not teach the movement to you. You will not learn how to properly snatch, clean, jerk, press, deadlift, or do anything else by looking at photographs. You need a coach, or at least, a partner, to watch what you do and point out to you what you are missing, or what you are doing wrong.
A brief description of a workout is fine, and is useful — I may forget what Annie is — but an illustration of a lift is not useful. It seems like a useful thing to have in an application, since it adds richer media and provides a reference, but it fails in providing any useful function.
The application is ugly, and poorly designed. That’s subjective and an opinion, but I did put a lot of time into some of the details you probably barely notice in WOD. Some examples:
When you update something in one screen, other screens are affected. Like if you add a workout, special care is taken to make sure that the log list is properly updated, so when you go back to that view it looks consistent with what you expect.
When you tap the notes field while editing a workout or record, the notes field slides upward, pushing the other fields “off the screen” so the field you are editing takes up all the real estate on the screen, and — most importantly — so the keyboard doesn’t obscure what you are doing.
And, more on that point, special care is taken on the size of the text areas when the keyboard is present and when it isn’t: when it’s not present, the text area takes up all the vertical space on the screen; when it is present, the text area’s vertical size matches the vertical space not obscured by the keyboard. It’s a simple thing, but you might miss it: the keyboard, since it’s another layer above your view, can obscure things.
When a “wheel” selector is shown in landscape mode, a special background image is used, so the UI element takes up the entire horizontal screen space. This makes it look like the wheel element takes up the entire horizontal space, instead of leaving the sides of the element “blank” and showing the view beneath it.
I doubt anyone ever noticed any of these things, even though they took the bulk of the time to get right. That’s exactly the point: you have to work very hard to make sure people don’t notice things, because if they do notice something, it’s likely that it’s unpleasant to them.
iCrossFit has the feature over WOD where you can time a workout in the app itself, but here’s the problem: when you finish a workout, it isn’t listed in your log! You apparently have to quit the app and relaunch it for new log entries to show up. This is fundamental when programming with UITableView — you have to reload the data when needed, so it shows up properly. But yes, it violates what’s expected to happen when you move through the application’s flow.
You have to meet the expectations of people using your app.
This goes for visual style, as well as expectations of how things flow. For an app on the iPhone, this means that unless it is an app where a unique visual style makes sense — games, obviously, and these small, single-function apps that use a unique and beautifully-designed visual style — then you should follow the form and style of Apple’s apps. iCrossFit Lite flaunts this convention a little, not egregiously; mostly it just uses the standard widgets in the wrong contexts, or overloads them so they’re too dense and hard to look at. Garish colors are used too much, as in, are used at all.
You should never format a time as “min: 03 sec: 41”.
Overall, iCrossFit Lite is an attempt at a grander, richer feature set than WOD’s deliberately modest attempt, and it’s embarrassingly amateurish and buggy.
Link: Made, Is Making, or Will Make?
Nice piece about the pitfalls of selling iPhone apps, and of predicting in any reasonable fashion what future revenue an app will bring.
And, I can confirm myself the strange “good sales until they drop by 50% for no explicable reason” behavior of the App Store. Now, competition is one obvious reason, but I’m not sure if it explains it completely.
I found this statement baffling (article):
Developing applications for the iPhone and iPad is expensive, he said, because iPhone OS uses the Objective C language rather than Microsoft’s more pervasive .NET platform.
What I think this means is that, for a company that wants to develop applications for a mobile device, it’s cheaper to hire developers who are experienced in the namby-pamby world of .NET instead of a language that makes you deal with memory and asynchronous programming, and actually have to be good at programming to use. Go ahead and develop in .NET. Sure it’ll be unusably slow and will drain my battery, and buggy as hell because the people developing it don’t know how to program, but it’ll be cheap. That’s the Microsoft way, right?
Anyway, for independent developers, developing for the iPhone isn’t terribly expensive at all. In fact, for independent developers and small companies, iPhone development is very cheap, given the revenue an app can generate. It basically costs you time, the idea, equipment, and an enrollment fee. Yeah, Apple takes a lot of control over the system, but because of that you get distribution, advertising, and sales management. That’s a huge amount of stuff that you just plain don’t have to worry about, and spend the time or money on. Apple has policies and practices that don’t always work in your favor? Tough tits; it’s their game, but they’re letting you play.
So I’ve noticed yet more noise recently on the whole iPhone app settings location. Apple recommends that settings go into the global “Settings” application, but just about everyone else seems to think that that’s wrong and confusing, which I mostly agree with. Usually, I never think to go digging in Settings to find out if an application I’m using has any kind of settings I’m interested in changing (it’s also a pretty good testament to the usability of a lot of the apps I have, since they just work, as installed, without me dicking around with knobs).
There is a simple, elegant solution, though:
If you have settings at all, you probably are using NSUserDefaults to store user settings, and so you can control these yourself inside your app, and can add a settings bundle so they are available in the Settings app.
If your settings are complicated, and need custom controls that a settings bundle won’t support (however, you shouldn’t have complicated settings in the first place), you can pare down what goes into the settings bundle to things it supports well.
This should work fine, and it manages conflicting user expectations: users are told that settings are in the settings app, so they should find them there; but it makes sense to have settings available in the app itself, so they should find them there too.
(I did just add two settings for the 1.1 release of WOD, and I only put them in the settings bundle for that release, because it was easy. 1.2 will have settings controllable in both the settings app and the app itself.)
Link: Flatland
Very thorough and well-thought-out piece on navigating data, and navigating data on an iPhone.
OK, so we’re pretty sure that showing an absolute percentage in a table view is the right approach instead of adjusting things so they fit the data — it’s simple and looks good. Now we have another issue: how do we indicate that an error condition is being triggered for that entry? This might not be a disk full question, like the previous screens were tailored for, but rather a progress indicator: each cell in the table is conveying how “complete” something is in doing some task, so if the bar is halfway across, the task is halfway done.
But there might be error conditions, where one system completed 72.8% of its task, then encountered a fatal error, so it won’t progress any more. Another system might have had a minor hiccup, so it won’t be able to complete the entire task as it should, but it still running with the remaining parts of the task. There’s two obvious ways to do it.
The most obvious one is to use color to indicate the status. Blue could mean everything is OK (the standard here tends to be green, but green is out of place in the iPhone UI, so we’ll use blue for our primary color besides white, black and grays), yellow is a caution condition, and red is an error condition. Of course, these colors in their primary form are way too harsh, so we go the “pastel” route — sky blue, lemonade, and pink. The big drawback, up front, is that it doesn’t work for colorblind people (that might be too specific a concern, but it’s still not ideal).
The other idea is to just “tag” the error entries with an obvious icon that says “this one has an error.” iTunes uses this convention when something goes wrong with an entry in your library, like if a song file disappeared from the file system, or if a podcast couldn’t be updated. Iconography is useful, especially if there is a limited vocabulary. No icon, everything’s good. A caution or error icon, things went wrong. Choosing the right vocabulary is key here; it should be easy to distinguish all the states, maybe having a “yield” style sign (a triangle) means “warning,” while a “stop” style sign (an octagon) means “error.”
Also, we might just do away with a warning state completely. Everything’s either great, or something’s fucked up.
Anyway, here is an A/B comparison of the two:
In my opinion, using color looks hideously garish. An icon flagging the ones that need to be flagged seems to convey the idea more immediately, and looks better.