Obstacles to getting real feedback are now mainly cultural, not technological; any business that isn’t learning from their users doesn’t want to learn from their users.
February 15, 2010
Usability Problems are Cultural
February 9, 2010
January 13, 2010
Splash Screens Are Evil
Splash screens are evil. While branding is important, the proper place for it is in the iconography, optional “About” or “Info” screens, and App Store profiles. The most common interaction pattern with iPhone applications is to launch them frequently, close them quickly, and treat them as part of a set of tools that interact to comprise a single user experience. Splash screens break the perception of seamlessness.
The HIG offers a very useful suggestion for managing launch states, which may be quite slow, depending on the needs of your application. The suggestion is to provide a PNG image file in your application bundle that acts as a visual stand-in for the initial screen of your application. For example, if the main screen for your application is a table full of data, provide an image of a table without data to act as a stand-in. When your data is ready to be displayed, the image will be flushed from the screen, and the user experience will feel more responsive.
In this book, we will explore extensions of this, including a pattern for loading application state lazily
–Toby Boudreaux, iPhone User Experience, page 15; emphasis mine.
I’ve always hated splash screens, from the first time I turned on a computer. They get in the way of what I want to do. I want to write, or draw, or play — but if I launch Word, or Photoshop, or any game, I have to sit through a splash screen before I can get to it.
Branding a splashscreen is putting your name on a purely negative experience. Nobody wants to wait for their computer. Splashscreens, by definition, force you to wait. It’s hard for me to imagine why anyone wants to associate their brand with a computer not doing what customers want.
December 7, 2009
Dot Syntax Solution
Surprisingly, the addition of dot syntax to Objective-C 2.0 has been a major source of controversy. I wonder if there’s some kind of Bike Shed effect at work here: the problem dot-syntax causes is trivial1; while the clarity it brings to code is minor. So it essentially boils down to aesthetics. (For the record, I like the dot, even with it’s current flaws, but I don’t believe it’s worth fighting for).
The Actual Problem
The problem is that when you see a.b = c; you don’t know if it’s:
- Assigning the
bfield of astructtoc. This basically compiles down to onemoveinstruction. - Invoking the
-setB:method on an Objective-C object. By convention-setB:should update thebproperty of the object to hold the valuec, and nothing else. But it might have side effects, or be really slow.
A Solution
Using a different symbol to access Objective-C properties would remove all ambiguity. Nobody would mistake a@b = c; as assigning to a C-struct. It’s clearly an Objective-C construct.
But personally, I’m not a big fan of the @ character. It’s ugly; it’s noisy; there’re just too many lines in it. I think U+25B8 ‘BLACK RIGHT-POINTING SMALL TRIANGLE’ would make a better choice,
obj▸property = value;
And since ‘▸’ can’t be part of a valid C identifier, you can basically preprocess your code with s/▸/./, then compile it with existing tools.
Of course, it doesn’t matter what character(s) is picked, so long as it’s clearly different from existing C syntax; and you have a way of replacing it with a . before building it.
1 I’ve heard experienced developers complain that dot-syntax = a steeper learning curve for newbies, and that it can be confusing, but I haven’t actually seen one come out and say ‘I spent X hours debugging a problem that I couldn’t see because of it’. The fact is, any situation that dot-syntax would obscure is already pathological. In the end I just can’t see dot-syntax mattering much.
November 14, 2009
You Can’t Please Everyone
I did a project years ago called the “Dollar Dudes”, where we got on the subway with a bucket of dollar bills and announced that we were in the lucky “Dollar Train” and that everyone gets a dollar. Most everyone was delighted (at both the dollar and the ridiculousness of it all) but one guy refused to take the money and snapped at me. I was bummed out to get that reaction, but at the end of the day I didn’t feel that one guy getting irritated made the whole project a failure. The other 40 people had fun. I imagine the type of person who gets mad when offered a dollar by a stranger probably gets mad quite a bit throughout his day. I’m not trying or pretending to please every single person we encounter.
–Charlie Todd (of Improv Everywhere fame)
Yes, handing out a bucket of money really does upset someone. You have no chance of pleasing everyone. Make tradeoffs accordingly.
October 26, 2009
Threading is Wrong
I’m taking the following as an axiom: Exposing real pre-emptive threading with shared mutable data structures to application programmers is wrong. …It gets very hard to find humans who can actually reason about threads well enough to be usefully productive.
When I give talks about this stuff, I assert that threads are a recipe for deadlocks, race conditions, horrible non-reproducible bugs that take endless pain to find, and hard-to-diagnose performance problems. Nobody ever pushes back.
October 23, 2009
GUI is Dead, Long Live UI
The term GUI, Graphical User Interface, pronounced “Gooey” is laughably anachronistic. All interfaces meant for people on modern computers are graphical. The right abbreviation to use today is simply UI, for User Interface, pronounced “You I”.
Believe me, I understand that a command line interface is still useful today. I use them. I’m a programmer. I get the whole UNIX thing. Even without a pipe, a command-line is the highest-bandwidth input mechanism we have today.
But all command lines live inside a graphical OS. That’s how computers work in the 21st century.
Whenever I see “GUI” written I can’t help but wonder if the author is dangerously out of touch. Do they still think graphical interfaces are a novelty that needs to be called out?
October 22, 2009
iPhone Shows the Irrelevance of the Programmer User
There’s a lot of discord over Apple’s draconian “closed” handling of the iPhone and App store. And rightly so. But there are a few interesting lessons in the current situation. The one I want to discuss now is that,
Being able to program your own computer isn’t enough to make it open
As things stand today, Apple can’t stop you from installing any damn iPhone app if you build yourself.
To do that you have to join the iPhone developer program of course. And there’s a $99/year fee. That’s inconvenient, but it’s just using a subscription-based way of selling iPhone OS: Developer Edition.
That’s the kind of dirty money-grabbing scheme I’d expect from Microsoft. It’s a bit shady, because it’s not how most OSes are sold. But it’s not without precedent. And unless you are against ever charging money for software, I don’t think there’s an argument that it’s actually depriving people of freedom.
Yes, it’s an unaffordably high price for many. But the iPhone is a premium good that costs real money to build — it’s inherently beyond many people’s means, even when subsidized.
Observation: Only Binaries Matter
If you have a great iPhone app that Apple won’t allow into the store, you can still give it to me in source code form, and since I have iPhone OS: Developer Edition, I can run it on my iPhone.
But clearly that’s not good enough.
In fact, I’m not aware of any substantive iPhone App that’s distributed as source. By “substantive” I mean an app with a lot of users — say as many as the 100th most downloaded App Store app — or an app that does something that makes people jealous, like tethering (See update!), which we know is possible using the SDK. I realize this is a wishy-washy definition — what I’m trying to say is that distributed-as-source iPhone Apps seem to be totally irrelevant.
“It’s not open until I can put Linux on it”
I believe it’s technically possible to run Linux on an iPhone without jail-breaking it. (Although it’s not terribly practical.) Just build Linux (or an emulator that runs Linux) as an iPhone app, and leave it running all the time to get around the limitations on background processes.
Apple won’t allow such a thing into the App Store of course –but how does that stop you from distributing the source for it? As best I can tell, it doesn’t.
So as things stand today, yes you can distribute source code that lets any iPhone OS: Developer Edition user run Linux. It’s technically challenging, but it’s doable.
Conclusion
It’s possible to build open systems on top of closed systems. We’ve done it before when we built the internet on Ma Bell’s back.
But the iPhone remains a closed device. User-compiled applications have 0 momentum. And I think that clearly shows the irrelevance of the rare “programmer user”, who is comfortable dealing with the source code for the programs he uses.
UPDATE 2010-01-21: iProxy is an open-source project to enable tethering! Maybe the programmer-user will have their day after-all.
October 20, 2009
JavaScript Nailed ||
One thing about JavaScript I really like is that its ||, the Logical Or operator, is really a more general ‘Eval Until True‘ operation. (If you have a better name for this operation, please leave a comment!) It’s the same kind of or operator used in Lisp. And I believe it’s the best choice for a language to use.
In C/C++, a || b is equivalent to,
if a evaluates to a non-zero value:
return true;
if b evaluates to a non-zero value:
return true;
otherwise:
return false;
Note that if a can be converted to true, then b is not evaluated. Importantly, in C/C++ || always returns a bool.
But the JavaScript || returns the value of the first variable that can be converted to true, or the last variable if both variables can’t be interpreted as true,
if a evaluates to a non-zero value:
return a;
otherwise:
return b;
Concise
JavaScript’s || is some sweet syntactic sugar.
We can write,
return playerName || "Player 1";
instead of,
return playerName ? playerName : "Player 1";
And simplify assert-like code in a perl-esq way,
x || throw "x was unexpectedly null!";
It’s interesting that a more concise definition of || allows more concise code, even though intuitively we’d expect a more complex || to “do more work for us”.
General
Defining || to return values, not true/false, is much more useful for functional programming.
The short-circuit-evaluation is powerful enough to replace if-statements. For example, the familiar factorial function,
function factorial(n){
if(n == 0) return 1;
return n*factorial(n-1);
}
can be written in JavaScript using && and || expressions,
function factorial2(n){ return n * (n && factorial2(n-1)) || 1;}
Yes, I know this isn’t the clearest way to write a factorial, and it would still be an expression if it used ?:, but hopefully this gives you a sense of what short-circuiting operations can do.
Unlike ?:, the two-argument || intuitively generalizes to n arguments, equivalent to a1 || a2 || ... || an. This makes it even more useful for dealing with abstractions.
Logical operators that return values, instead of simply booleans, are more expressive and powerful, although at first they may not seem useful — especially coming from a language without them.
October 19, 2009
Less is More
Fundamentally, a computer is a tool. People don’t use computers to use the computer, they use a computer to get something done. An interface helps people control the computer, but it also gets in their way. Inevitably, any on-screen widget is displacing some part of the thing the user is trying to manipulate.
As an infamous example, expanding Microsoft Word’s toolbars leaves no room for actually writing something,
(Screenshot by Jeff Atwood)
Users don’t want to admire the scrollbars. Truth be told, they don’t even want scrollbars as such, they just want to access content and have the interface get out of the way.
Show The Data
I highly recommend Edward Tufte’s The Visual Display of Quantitative Information
Tufte’s teachings are rooted in static print. But many of the principles are just as valuable in interactive media. (And static graphics are still very useful in analysis and presentation. Learning how to graph better isn’t a waste of time.)
Tufte’s first rule of statistical graphic design is, “Show the data” , and it’s an excellent starting point for interface design as well.
Cathy Shive has an excellent post expanding on Tufte’s term Computer Administrative Debris.
The Chartjunk blog showcases a few real-world examples of Tuftian redrawings.
Get Out of My Mind
Learning happens when attention is focused. … If you don’t have a good theory of learning, then you can still get it to happen by helping the person focus. One of the ways you can help a person focus is by removing interference.
–Alan Kay, Doing With Images Makes Symbols.
Paradoxically then, the better the design, the less it will be noticed. We should strive to write our interfaces in invisible ink.