Mac OS X can run on systems with a screen size as small as 800 x 600 … Unless you know that your users will be using a specific display size, it is best to optimize your applications for display at 1024 x 768 pixels. … Design your user interface for a resolution of at least 800 x 600.
According to Apple’s Human Interface Guidelines (retrieved 2010-04-21).
…
Also, in every color combination surveyed, the darker text on a lighter background was rated more readable than its inverse (e.g. blue text on white background ranked higher then white text on blue background).
I wish Columbia Blue and Red were tested in the survey. They were my high school’s colors; and they were terrible. The worst permutation was blue text on a red background.
Question for all you who prefer light source-code on a dark background: why do you like it?
..the eBay design model. My theory is that eBay was a success due to its crappy design because it gave it that flea market feel and when you went there you felt like you getting a deal. Go to Tiffany & Co. and you don’t get the feeling that you are getting a bargain because you shouldn’t.
Bruce Schneier has a new essay, How to Sell Security. As usual, it’s well worth reading.
The most interesting tidbit, to me, is that people have a bias to choose a small certain gain over an uncertain but possibly larger gain. But with loss, it’s the opposite. People avoid certain losses; preferring to “play double or nothing” — risking a larger loss for the chance of not sustaining a loss.
Here’s an experiment that illustrates Prospect Theory. Take a roomful of subjects and divide them into two groups. Ask one group to choose between these two alternatives: a sure gain of $500 and 50 percent chance of gaining $1,000. Ask the other group to choose between these two alternatives: a sure loss of $500 and a 50 percent chance of losing $1,000.
These two trade-offs are very similar, and traditional economics predicts that the whether you’re contemplating a gain or a loss doesn’t make a difference: People make trade-offs based on a straightforward calculation of the relative outcome. Some people prefer sure things and others prefer to take chances. Whether the outcome is a gain or a loss doesn’t affect the mathematics and therefore shouldn’t affect the results. This is traditional economics, and it’s called Utility Theory.
But Kahneman’s and Tversky’s experiments contradicted Utility Theory. When faced with a gain, about 85 percent of people chose the sure smaller gain over the risky larger gain. But when faced with a loss, about 70 percent chose the risky larger loss over the sure smaller loss.
This experiment, repeated again and again by many researchers, across ages, genders, cultures and even species, rocked economics, yielded the same result. Directly contradicting the traditional idea of “economic man,” Prospect Theory recognizes that people have subjective values for gains and losses. We have evolved a cognitive bias: a pair of heuristics. One, a sure gain is better than a chance at a greater gain, or “A bird in the hand is worth two in the bush.” And two, a sure loss is worse than a chance at a greater loss, or “Run away and live to fight another day.” Of course, these are not rigid rules. Only a fool would take a sure $100 over a 50 percent chance at $1,000,000. But all things being equal, we tend to be risk-adverse when it comes to gains and risk-seeking when it comes to losses.
This cognitive bias is so powerful that it can lead to logically inconsistent results. Google the “Asian Disease Experiment” for an almost surreal example. Describing the same policy choice in different ways–either as “200 lives saved out of 600” or “400 lives lost out of 600”– yields wildly different risk reactions.
Evolutionarily, the bias makes sense. It’s a better survival strategy to accept small gains rather than risk them for larger ones, and to risk larger losses rather than accept smaller losses. Lions, for example, chase young or wounded wildebeests because the investment needed to kill them is lower. Mature and healthy prey would probably be more nutritious, but there’s a risk of missing lunch entirely if it gets away. And a small meal will tide the lion over until another day. Getting through today is more important than the possibility of having food tomorrow. Similarly, it is better to risk a larger loss than to accept a smaller loss. Because animals tend to live on the razor’s edge between starvation and reproduction, any loss of food — whether small or large — can be equally bad. Because both can result in death, and the best option is to risk everything for the chance at no loss at all.
NOTE: Although this specific Bug Bite is about NSTextView, and the “hidden” property, the same underlying issue applies to other interface-objects (NSTableView, etc.), and different properties, like size.
Problem
If you send a setHidden:YES message to an NSTextView, and it’s text disappears, but the view itself (white box) stays visible here’s the problem, and the solution.
It turns out that if you created the NSTextView by dragging it off the pallet in Interface Builder, then it’s not an NSTextView. It’s an NSTextView wrapped inside an NSClipView inside an NSScrollView. The NSScrollView is what puts up the scroll-bars if the NSTextView gets really big; the NSClipView helps make the scrolling work.
So if text is your IBOutlet to your NSTextView, then when you say [text setHidden:YES];, the NSTextView is hidden, but the the total package won’t disappear, unless you hide the NSScrollView as well.
Solutions
You can send the message to NSScrollView containing text, like so:
[[text enclosingScrollView] setHidden:YES];.
This will hide everything inside the NSScrollView, including text.
Another solution is to create just an NSTextView in Interface Builder. To do this, put an NSView in your interface (it’s called a “Custom View”,in the Interface Builder objects pallet). Then select it, bring up the object inspector (cmd-shift-i), choose the “custom class” from the category menu at the top, and select NSTextView from the list of subclasses. This puts an NSTextView in your interface, without the surrounding clip and scroll views. Unfortunately, it also means you can’t configure it in Interface Builder, beyond resizing it. That’s why I’m not partial to this approach, although I have used it.
Thanks to ZachR for suggesting enclosingScrollView.
“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”
–Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.
If you’ve programmed in C, you’ve seen memcpy (pronounced “mem-copy”). It’s the preferred way to copy a block of memory somewhere. There is a safer and equally easy to use alternative, memmove. But it has never gained traction, in spite of it’s advantages. As we will see, this is unfortunate, and may be an example of a programming culture that values (superficial) speed over safety.
The Difference
The difference between memcpy and memmove is simple: when the source and destination blocks of memory overlap (for example, if they are the same), memmove works, but memcpy‘s behavior is undefined. It might work. It might crash. It might corrupt data. It might behave differently during debugging.
memmove is safer.
memcpy can be faster, and usually is. There are less restrictions on it’s implementation, so more can be done to optimize it. But not necessarily a lot more — in fact, it could even be slower then memmove, and sometimes this is the case. On some systems, memcpy may just be memmove.
Faster
So how much faster can memcpy be then memmove? They both take O(N) time to copy N bytes of data. So in some computer-science circles, memcpy wouldn’t be considered faster then memmove.
Algorithmically, memmove needs one extra if-statement before it starts to copy; to determine if it needs to copy front-to-back, or back-to-front. (See this reference implementation for an example.) The only other advantage memcpy may have are esoteric processor-specific instructions that assume restricted pointers. So unless there is a “memcpy instruction”, we can expect the difference in speed to be pretty small.
But the real proof is in the pudding and … memmove is faster then memcpy! At least on my laptop, with this test; basically copying 4MB of memory 100 times. See for yourself:
$ gcc -O0 memcpy_memove_lab.c && ./a.out
Surprise!
memmove is 1.404409 times faster then memcpy
gcc -O3 memcpy_memove_lab.c && ./a.out
Surprise!
memmove is 1.054571 times faster then memcpy
“This must be an unfair test!”, you’re probably thinking. Yes, it is. Or at least it’s a dangerously narrow test. But it is also an honest and simple test. By that I mean, it is the first code I hammered out to just get some numbers for this article. Proper benchmarking is very difficult. I’m not going to attempt it.
The real lesson from this naive benchmark is that you must measure your code before concluding that an optimization is really faster. I would never have guessed that memmove would be up to 40% faster, at copying 4MB. But it was — in this particular instance.
On a related note, a significantly faster memcpy (say 2x) won’t have an appreciable impact on an application’s performance, unless the application spends a surprisingly large portion of it’s time copying memory (Amdahl’s law). For example, let’s say that 1 out of every 20 seconds is spent copying memory with memmove. (That’s a lot of time just moving bits around! Programs should do something with bits, not just move them.) So we replace memmove with memcpy, and this memcpy is a full 2x faster then memmove (which is optimistic). Surprisingly, we only get a 2.5% speedup! Remember that 1 in 20 is only 5% of the program’s total time. Cutting this time in half eliminates 2.5% of the program’s total execution time. If we can find an optimization that speeds up the other 95% of the program by just 2.7%, we get better performance overall.
So memcpy is unlikely to make a large difference to program performance, in general. Switching memcpy implementations is a “local optimization”, that has much less value then changing the algorithm that’s requiring all that duplication. It may even suddenly become slower when hardware is upgraded.
Safer
How much safer is memmove? This is a hard dimension to quantify, and I don’t have a satisfying answer. My instinct tells me that it isn’t dramatically safer. I don’t have any data to support this, but I believe it’s very rare to be copying memory into itself; compared to other memory-management errors, like a double-free().
But the bottom line is that, there are less ways your program can fail if you use memmove over memcpy. Period. Since memcpy‘s behavior is undefined when the source and destination overlap, it can be a vicious bitch to debug.
Speed over Safety
memcpy is preferred by a significant majority of C programmers. I don’t know exactly how many. But a google fight shows that memcpy is almost 6x more talked about then memmove (as of 2008-04-11). Anecdotally, memmove is mostly unheard of in my experience. It seems like the call of “faster” really is a siren’s-song for developers; luring them into dangerous code.
I think this is very unfortunate. Especially, because the performance advantage of memcpy just isn’t that big in general! (Sometimes it’s even harmful). Given the unreliability of software, anything that elements bugs is a Very Good Thing.
I wish I knew the full story of memcpy winning the popularity contest with memmove. By accident or design, it has left us with a programming culture that values superficial speed over safety.
For Further Reading:
Optimizing memcpy — includes some graphs showing the tradeoffs between optimizing for large chunks of memory (say copying pictures), and small data structures.
Why aren’t my optimizations optimizing? — “Optimizing code is a tricky business.”
memcpy_memove_lab.c — The naive benchmark from this article, plus a reference implementation of memcpy and memmove.
Most people make the mistake of thinking design is what it looks like. People think it’s this veneer — that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.
–Steve Jobs, CEO, chairman and co-founder of Apple Inc. in a 2003 New York Times magazine interview.
TIOBE Programming Community Index
The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, and YouTube are used to calculate the ratings. Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.
If TIOBE is to be belived, then (as of May 2008), plain-jain C is the second-most popular language around, and Objective-C has an insignificant 0.083% share; less then Lisp, Haskell, and Smalltalk (the irony).
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable.
–George Bernard Shaw
intuition
noun
the ability to understand something immediately, without the need for conscious reasoning.
“Intuitive” sounds like a great property for an interface to have, but in The Humane Interface
Many interface requirements specify that the resulting product be intuitive, or natural. However, there is no human faculty of intuition…When an expert uses what we commonly call his intuition to make a judgment … we find that he has based his judgment on his experience and knowledge. Often, experts have learned to use methods and techniques that non-experts do not know… Expertise, unlike intuition, is real.
When users say that in interface is intuitive, they mean that it operates just like some other software or method with which they are familiar.…
Another word that I try to avoid in discussing interfaces is ‘natural’. Like ‘intuitive’, it is usually not defined. An interface feature is natural, in common parlance, if it operates in such a way that a human needs no instruction. This typically means that there is some common human activity that is similar to the way the feature works. However, it is difficult to pin down what is meant by ‘similar’. … the term ‘natural’ (can also equate) to ‘very easily learned’. Although it may be impossible to quantify naturalness, it is not to difficult to quantify learning time.
…
The belief that interfaces can be intuitive and natural is often detrimental to improved interface design. As a consultant, I am frequently asked to design a “better” interface to a product. Usually, an interface can be designed such that, in terms of learning time, eventual speed of operation (productivity), decreased error rates, and ease of implementation, it is superior to both the client’s existing products and competing products. Nonetheless, even when my proposals are seen as significant improvements, they are often rejected on the grounds that they are not intuitive. It is a classic Catch-22: The client wants something that is sigificantly superior to the competition. But if it is to be superior, it must be different. (Typically, the greater the improvement, the greater the difference.) Therefore, it cannot be intuitive, that is, familiar. What the client wants is an interface with at most marginal differences from current practice — which almost inevitably is Microsoft Windows — that, somehow, makes a major improvement.
There are situations where familiarity is the most important concern, but they are rare. One example is a kiosk at a tourist attraction. Millions of people will use it only once, and they must be able to use it as soon as they touch it (because they will walk away rather then spend their vacation reading a manual). And in such cases, mimicking the most promiscuously used interface you can find, warts and all, makes sense — if that means more people will already know how to use it.
Outside of rare exceptions, software that people use enough to justify buying is used repeatedly. The value of the product is what people make with it, not what they can do with it the moment they open the box. Designing for the illusion of “intuitiveness” is clearly the wrong choice when it harms the long-term usefulness of the product.
This is not an excuse for a crappy first-run experience! The first impression is still the most important impression. By definition, the less familiar something is, the more exceptional it is. And an exceptionally good first impression is what you are after — so unfamiliarity can work to your advantage here. It is more work to design an exceptional first-run experience, but good design is always more work.
This is not a rational for being different just to be different. It is a rational for being different, when different is measurably better. For something to be measurably better, it first needs to be measurable. That means using precise terms, like “familiar” instead of “intuitive”, and “quick to learn” not “natural”.
Powered by WordPress