A collection of warning signs. Some are quite funny; my favorite so far.
There’s also a book (unrelated to the flickr group), but disappointingly it does not give bibliographical information on where the signs came from.
Here’s a blog of safety graphics.
So if you take Wikipedia as a kind of unit, all of Wikipedia, the whole project–every page, every edit, every talk page, every line of code, in every language that Wikipedia exists in–that represents something like the cumulation of 100 million hours of human thought. I worked this out with Martin Wattenberg at IBM; it’s a back-of-the-envelope calculation, but it’s the right order of magnitude, about 100 million hours of thought.
And television watching? Two hundred billion hours, in the U.S. alone, every year. Put another way, now that we have a unit, that’s 2,000 Wikipedia projects a year spent watching television. Or put still another way, in the U.S., we spend 100 million hours every weekend, just watching the ads.
…it’s easy for software to commoditize hardware (you just write a little hardware abstraction layer, like Windows NT’s HAL, which is a tiny piece of code), but it’s incredibly hard for hardware to commoditize software. Software is not interchangeable, as the StarOffice marketing team is learning. Even when the price is zero, the cost of switching from Microsoft Office is non-zero. Until the switching cost becomes zero, desktop office software is not truly a commodity. And even the smallest differences can make two software packages a pain to switch between. Despite the fact that Mozilla has all the features I want and I’d love to use it if only to avoid the whack-a-mole pop-up-ad game, I’m too used to hitting Alt+D to go to the address bar. So sue me. One tiny difference and you lose your commodity status. But I’ve pulled hard drives out of IBM computers and slammed them into Dell computers and, boom, the system comes up perfectly and runs as if it were still in the old computer.
Here’s Jakob Nielsen’s economic justification for giving employees large screens,
Big monitors are the easiest way to increase white-collar productivity, and anyone who makes at least $50,000 per year ought to have at least 1600×1200 screen resolution. A flat-panel display with this resolution currently costs less than $500. So, as long as the bigger display increases productivity by at least 0.5%, you’ll recover the investment in less than a year. (The typical corporate overhead doubles the company’s per-employee cost; always remember to use loaded cost, not take-home salary, in any productivity calculation.)
Jeff Atwood has written a “one-stop-shop for research data supporting the idea that, yes, having more display space would in fact make you more productive”. But he warns us that “Having all that space can make you less productive due to all the window manipulation excise you have to deal with to make effective use of it.”He calls this the Large Display Paradox. But, there are solutions to this problem. Using software to divide the large single-display into a “grid” of virtual “monitors” is the one he proposes.
A recent and widely publicized University of Utah study concluded that people were less productive on a 26″ screen then an 18″ screen. (Unfortunately I haven’t found a better link to their actual data then this crappy PDF brochure.) However, they also found that people were more productive with two 20″ screens. Their 26″ monitor was 1920×1200 pixels = 2.3 MP, their 20″ was 1600×1200 pixels = 1.92MP, so two 20″ screens = 3.84 MP, quite a bit bigger then the 26″ screen, and with greater productivity. This supports the theory with the right windowing system, productivity increases as the number of usable pixels increases.
I’ve only found one exception to the “bigger is better” rule of workspaces. Portability (Availability) can be worth more then pure productivity. There’s an old gunslinger saying that “The best gun in the world is the the one I’ve got in my hand right now”. Similarly, having a “big iron” on your office isn’t much use if you are flying somewhere over the atlantic. There’s no substitute for having a computer in-hand. Even if you would be more productive using a 17″ laptop, it’s better to get a 13″ ultra-portable, if it means you are more likely to actually have it around when you need it.
Business travelers, and creative professionals who work better in eclectic settings, are examples of people who are better served by the smallest sufficiently-powerful laptop they can find. But for most people bigger is better. Fortunately, small laptops can be connected to large displays.
…Judy Olson and Erik Nilsen wrote a classic paper comparing two user interfaces for large data tables. One interface offered many more features for table manipulation and each feature decreased task-performance time in specific circumstances. The other design lacked these optimized features and was thus slower to operate under the specific conditions addressed by the first design’s special features.
So, which of these two designs was faster to use? The one with the fewest features. For each operation, the planning time was 2.9 seconds in the stripped-down design and 4.6 seconds in the feature-rich design. With more choices, it takes more time to make a decision on which one to use. The extra 1.7 seconds required to consider the richer feature set consumed more time than users saved by executing faster operations.
—Jakob Nielsen, the day before my birthday, 2006.
A lot of Macintosh APIs take or return a 32-bit value that is supposed to be interpreted as a four character long string. (Anything using one of the types FourCharCode, OSStatus, OSType, ResType, ScriptCode, UInt32, CodecType probably does this.) The idea is that the value 1952999795 tells you less, and is harder to remember, then 'this'.
It’s a good idea, unfortunately there isn’t a simple way to print integers as character strings. So you have to write your own code to print them out correctly, and since it has to print correctly on both big endian and little endian machines this is tricker then it should be. I’ve done it incorrectly before, but more importantly so has Apple’s own sample code!
Here are the best solutions I’ve found. Please let me know if you have a better way, or if you find any bugs. (The code is public-domain, so use it any way you please.)
FourCharCode to NSString:
use NSString *NSFileTypeForHFSTypeCode(OSType code);
Results are developer-readable and look like: @"'this'", but Apple says “The format of the string is a private implementation detail”, so don’t write code that depends on the format.
FourCharCode to a C-string (char*):
use the C-macro
#define FourCC2Str(code) (char[5]){(code >> 24) & 0xFF, (code >> 16) & 0xFF, (code >> 8) & 0xFF, code & 0xFF, 0}
(requires -std=c99; credit to Joachim Bengtsson). Note that the resulting C-string is statically allocated on the stack, not dynamically allocated on the heap; do not return it from a function.
If you want a value on the heap, try:
void fourByteCodeString (UInt32 code, char* str){
sprintf(str, "'%c%c%c%c'",
(code >> 24) & 0xFF, (code >> 16) & 0xFF,
(code >> 8) & 0xFF, code & 0xFF);
}
In GDB, you can print a number as characters like so:
(gdb) print/T 1936746868
$4 = 'spit'
(via Borkware’s GDB tips)
If you do end up rolling your own FourCharCode printer (and I don’t recommend it!), then be sure to use arithmetic/shifting to extract character values from the integer. You can not rely on the layout of the integer in memory, because it will change on different machines. Even if you are certain that you’re code will only run on an x86 machine, it’s still a bad idea. It limits the robustness and reusability of your code. It sets you up for an unexpected bug if you ever do port your code. And things change unexpectedly in this business.
Printing a FourCharCode is harder then it should be. Experienced developers who should know better have been bitten by it (and so have I). The best solution is probably a %format for printf/NSLog that prints integers as character strings. Unfortunately, it doesn’t look like we’ll be seeing that anytime soon.
To show that nonuniform distributions occur in real life, consider Americans with the uncommon last name of Shifflett. The 1997 Manhattan telephone directory, with over one million names, contains exactly five Shiffletts. So how many Shiffletts should there be in a small city of 50,000 people? Figure 2-4 shows a small portion of the two and a half pages of Shiffletts in Charlottesville, Virginia telephone book.
—The Algorithm Design Manual, page 39.
I’ve recently moved, and that means meeting new people and making new friends. And that means getting instant-messages (IM) from people for the first time. Unfortunately, no IM clients handle that initial contact as well as it should. The basic problem is that they don’t give you enough information to figure out who the person is, making for awkward situations where you know you already know the person, but you don’t have the foggiest idea who the hell they are. And if that wasn’t bad enough — you are interacting with them for the first time in a different social medium, and you know what they say about first impressions…
For example, iChat only shows you the screen-name of someone when they message you for the first time. (This isn’t necessarily a bad trade-off for people who are easily offended). Unfortunately screen-names are (often) totally incomprehensible. Even when you can see what they are saying, it’s often something unrevealing like “hey, what’s up?” In general, there isn’t a quick way to get meaningful information about a person before you start chatting to them — unless you do your own legwork.
Fortunately computers can do that legwork for you. The moment an unknown screen-name says something to you, your client should start researching them, presenting you with any relevant information it finds.
In my experience, just searching
In college I modified some dashboard widget to do facebook+google searches for me. It wasn’t as good as having the functionality baked into the chat-client, but it was pretty fast (hit F12 + click + type one thing in one place + enter), and that made it worlds better then doing the legwork through a browser. It was sometimes useful when a new semester started (unfortunately I haven’t needed it for long enough to lose it).
Instant Messaging clients could do a lot more to make first-contact easier by presenting more information about who’s talking to you. It’s just a matter of connecting parts that exist today.
-[NSWindow setResizable:(BOOL)] does not exist. But, here is a way to get that effect as long as the window was resizable when created. (I don’t know of a way to make a window resizeable if it was first created unresizeable).
The basic idea is to show/hide the resizing controls, and implement delegate functions that prevent the window from being resized when the resizing controls are hidden.
//show or hide hide the window's resizing controls: [[window standardWindowButton:NSWindowZoomButton] setHidden:!resizable]; [window setShowsResizeIndicator:resizable];
Note that setShowsResizeIndicator: only shows/hides the resize-indicator in the lower-right of the window. It will not make the window non-resizeable.
To keep the window from being resized when showsResizeIndicator is false, implement the delegate methods:
- (NSSize)windowWillResize:(NSWindow *) window toSize:(NSSize)newSize
{
if([window showsResizeIndicator])
return newSize; //resize happens
else
return [window frame].size; //no change
}
- (BOOL)windowShouldZoom:(NSWindow *)window toFrame:(NSRect)newFrame
{
//let the zoom happen iff showsResizeIndicator is YES
return [window showsResizeIndicator];
}
Finally, there is a hack that avoids using delegate methods, although I don’t recommend it.
[[window standardWindowButton:NSWindowZoomButton] setHidden:!resizable]; [window setShowsResizeIndicator:resizable]; CGFloat resizeIncrements = resizable ? 1 : MAXFLOAT; [window setResizeIncrements:NSMakeSize(resizeIncrements, resizeIncrements)];
setResizeIncrements “Restricts the user’s ability to resize the receiver so the width and height change by multiples of width and height increments.” So setting it to MAXFLOAT x MAXFLOAT means that the user can’t resize the window, because they won’t have a big enough screen. Note that this won’t disable the “zoom” function, although the user probably couldn’t use it with the zoom button hidden.
This approach uses slightly fewer lines of code, but it is more brittle and indirect, since it depends on the screen-size, not if the window is (visibly) resizeable. I wouldn’t use it over delegates. But here it is.
Powered by WordPress