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.
iPhone 4 Update
Fast App Switching, introduced in iOS 4, makes splash screens a much worse idea. They won’t consistently display, because sometimes the app will really be resuming, not starting for the first time, when the user “launches” it. Forcing a splash-screen to appear on a resume as well means breaking the “multitasking” experience.
December 25, 2009
A C &Puzzler[]
Here’s a C-puzzler for you!
given this function,
void foo(char* s){
printf("s is at: %p\n s is: '%s'\n", s, s);
}
and that
char s[] = "Joy!"; foo(s);
prints out
s is at:
0xbffff46b
s is: ‘Joy!’
what will this next line print?
foo(&s); //WHAT WILL THIS DO?
Pick all that apply:
- Print “Joy!”
- Print garbage
- Print the same address for
s - Print the a different address for
s - Crash
- Go into an Infinite loop
Answer
Answer: one and three
Yeah, it’s not what I expected either, especially since:
@encode(__typeof__(s)) = [5c] @encode(__typeof__(&s)) = ^[5c]
In fact, all of these are equvalent (modulo type warnings):
foo(s); foo(&s[0]); foo(&(*s)); foo(&s);
December 10, 2009
Being a Lisp is a Handicap
Being a Lisp Is a Handicap
There are a large number of people who find Lisp code hard to read. I’m one of them. I’m fully prepared to admit that this is a shortcoming in myself not Lisp, but I think the shortcoming is widely shared.
Perhaps if I’d learned Lisp before plunging into the procedural mainstream, I wouldn’t have this problem — but it’s not clear the results of MIT’s decades-long experiment in doing so would support that hypothesis.
I think it’s worse than that. In school, we all learn
3 + 4 = 7and then
sin(?/2) = 1
and then many of us speak languages with infix verbs. So Lisp is fighting uphill.It also may be the case that there’s something about some human minds that has trouble with thinking about data list-at-a-time rather than item-at-a-time …
…I think I really totally understand the value of being homoiconic, and the awesome power of macros, and the notion of the reader. I want to like Lisp; but I think readability is an insanely important characteristic in programming systems.
Practically speaking, this means that it’d be hard for me to go out there on Sun’s (or Oracle’s) behalf and tell them that the way to take the best advantage of modern many-core hardware is to start with S-Expressions before breakfast.
—Tim Bray (emphasis mine)
I’m afraid he’s on to something. We have an amazing ability to parse language. But people aren’t terribly good at building the kinds of stacks needed to parse LISP with their short term memory.
This is the cheese that the rat that the cat that the dog that the neighbor owned bothered chased ate.
Say what?!
(This is the cheese (that the rat (that the cat (that the dog (that the neighbor owned) bothered) chased) ate)).
See the LISP connection?
All functional languages are fighting an uphill battle to be understood. The world we evolved in is stateful (modal) and imperative. We navigate it in a me-at-a-time way. Unfortunately, LISP’s prefix syntax is another, unnecessary, barrier.
The bottom line is that every word of code spends more time being read than written — so writing in a syntax that most people have a hard time reading is one of the worst programming choices imaginable. I believe functional programming languages are well worth learning; but I don’t believe it’s worth suffering a poor syntax.
December 9, 2009
Compile Safer
Peter Hosey explains what warnings he uses and why. It’s good, but long. Fortunately, you can just grab a script, and enable those warnings in your Xcode projects.
Warnings = Errors
If I could force just one compiler flag on everyone who’s code I use, it would be TREAT_WARNINGS_AS_ERRORS. As a rule, things don’t get improved if they aren’t broken. (How many times have you said “I’ll come back and fix this code later”? Yeah.) Warnings fester and grow on each other, until they cause a real breakage. It’s an inescapable evil of building software with finite resources.
If a warning isn’t worth stopping the build over — it’s not worth checking for in the first place.
Use the Latest Tools
Specifically, if you aren’t using Snow Leopard and Xcode 3.2 to build your Objective-C code, you are crazy. Trust me, painless static analysis is worth upgrading for. It catches maddening memory leaks, not just trivial type errors, like adding an int to an NSArray, that you would catch immediately.
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.
November 11, 2009
Just Look at it, Man!
You’re looking at Anscombe’s quartet: 4 datasets with identical simple statistical properties (mean, variance, correlation, linear regression); but obvious differences when graphed.
(via Best of Wikipedia)
Graphs aren’t a substitute for numerical analysis. Graphs are not a panacea. But they’re excellent for discovering patterns, outliers, and getting intuition about a dataset. If you never graph your data, then you’ve never really looked at it.
War Story
I was working on optimizing color correction, using SSE (high performance x86 instructions). One operation required division — an expensive operation for a computer. The hardware had a divide instruction, but sometimes using the Newton-Raphson method to do the division in software is faster. You never know until you measure.
While doing the measurement, I somehow got the crazy idea to try both: I’d already unrolled the inner loop so instead of repeating the divide or Newton’s Method twice, I’d do a divide and then use Newton’s Method for the next value. Strangely enough, this was faster on the hardware I was benchmarking than either method individually. Modern hardware is a complex and scary beast.
I was fortunate enough to have a suite of very good unit tests to run against my optimized code. But there was a caveat to testing correctness. Because computers don’t have infinitely precise arithmetic, two correct algorithms might give different answers — but if the numbers they gave were close enough to the infinitely precise answer (say a couple ulps apart) it was good enough. (We can only be exact within some Tolerance!) The tests cleared my hybrid divide/Newton-Raphson function: but we couldn’t use it, because it was fundamentally broken.
Even though the error was acceptably small, it had a nasty distribution. Using divide gave color values that were a bit too light. Doing a divide in software gave values that were a bit too dark. Individually these errors were fine. Randomly spread over the image they would have been fine. But processing every other pixel differently had the effect of adding alternating light/dark stripes! We see contrast, not absolute color, so the numerically insignificant error was quite visible. Worse still, bands of 1 pixel stripes combined to form a shimmering Moiré pattern. It was totally busted. Unusable.
This was all immediately obvious when the results of the color correction were “graphed”. Actually looking at the answer caught a subtle error that our suite of unit tests missed.
To be clear, more subjective graphical analysis is not a substitute for numerical analysis and data mining. But I believe in actually looking at your data at least once. A graph is a kind of end-to-end visualization of everything, and that has value. Graphs are a cheap sanity check — does everything look right? And sometimes, they can give you real insight into a problem.
November 9, 2009
Spurious
What’s a spurious relationship?
Here’s one: People who eat ice cream are more likely to drown. Both incidence of ice cream eating and rates of drowning are related to summertime. The relationship between ice cream and drowning is spurious. That is, there is no relationship. Yet they appear related because they are both related to a third variable.
(Image via the amazing Superdickery)