Bad Astronomy's Top Ten
Check out Bad Astronomy blogger Phil Plait's picks for The Top Ten Astronomy Images of 2006.
« November 2006 | Main | January 2007 »
December 29, 2006
December 22, 2006
December 15, 2006
Confused capitalists
Jim Buckmaster of Craigslist recently spoke to Wall Street in a language they could not comprehend.
UBS analyst Ben Schachter wanted to know how Craigslist plans to maximize revenue. It doesn’t, Mr. Buckmaster replied.... “That definitely is not part of the equation.... It’s not part of the goal.” How about running AdSense ads from Google? Craigslist has considered that, Mr. Buckmaster said. They even crunched the numbers, which were “quite staggering.” But users haven’t expressed an interest in seeing ads, so it is not going to happen.... Larry Dignan at ZDNet described the audience as “confused capitalists wondering how a company can exist without the urge to maximize profits.”
John Scalzi comments:
Craigslist was not initially designed to make tons and tons of money for Craig Newmark, as I understand it. He wanted to help people find things.... Presumably it's doing well enough. Unless Newmark and Buckmaster suddenly decide that what they both really need is a 300-foot yacht stocked with cocaine and supermodels, how much more do they need?
How can you not love these guys?
December 11, 2006
Google Videos
Peter Norvig's Google Research Picks for Videos of the Year. The Graphing Calculator Story Hour came in at #2!
December 10, 2006
VerizonMath
Verizon's telephone support folks remind us just how bad innumeracy can be.
The number one post on YouTube yesterday is twenty minutes of converation with multiple levels of Verizon management who do not know the difference between 0.002 cents per kilobyte and 0.002 dollars per kilobyte. The conversation is a series of failed attempts at basic math education over a seventy dollar bill. Verizon not only falsely advertised a price then billed one hundred times the promised rate, but when confronted with this fact, several representatives confirmed the promised rate, then did "the math" in such a wrong way to defend the error. I listened to the whole thing out of sympathy for math teachers everywhere.As Mark Chu-Carroll says: The fustrating thing about this whole ordeal is that obviously none of these people would have been hired if they didn't know how to read and write.
The one bright spot this incident illustrates is the notion that consumers have a new tool against the forces of corporate incompetence. When sites like YouTube are able to air grievences to hundreds of thousands of sympathetic listeners, public relations should demand that this level of abuse not be tolerated. One hopes.
Listen on YouTube
Read the transcript on http://verizonmath.blogspot.com
December 06, 2006
The Problem with Programming
Tech Review asks Bjarne Stroustrup Why is most software so bad?
I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.
Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable.
Read the rest of the interview to discover Kierkegaard's influence on the design of C++.
December 04, 2006
DRM
Why it pays to be a world-famous author with a widely read blog when deadlines loom and buggy DRM goes awry:
At 3:01 am Neil Gaiman writes:
Bloody Final Draft
You know, if I was ever going to write a screenwriting program, I would make sure that the bloody thing didn't hiccup, randomly "lose authorisation," and stop working when an author was on deadline. And if it did suddenly decide it wasn't authorised, I'd at least have some way to fix it if it happened late at night, when the nice support people are home in bed and authors are on deadline.
Sorry. Just wanted to grumble. Final Draft isn't cheap. I really think it ought to work.
At 11:32 am Neil Gaiman writes:
Not quite so bloody really
The phone just rang and it was Brendan from Final Draft, who reactivated my authorisation and was baffled at why or how it happened ("There are lots of reasons for losing authorisation. Yours just doesn't fit any of them.") So I can open the script again, and am reminded of why I stick with them. Lots of people wrote in suggesting different screenwriting programs, and I'm grateful, but for now I'm more or less happy.
I wonder how many e-mails and phone calls from fans Final Draft got today? I wonder if all their customers receive as prompt attention? I'm actually quite sympathetic to the difficulty of their position. Pacific Tech originally used no DRM and suffered from that decision. Graphing Calculator now uses a fairly complicated registration system, and that creates difficulties too.
Feel free to complain about Pacific Tech's DRM in the comments.
December 01, 2006
Lessons from our Usability Study: Part I
The most educational part of the original Graphing Calculator 1.0 development process was sitting behind a two-way mirror for five days watching first-time users, students and teachers, trying to use our software. It was a humbling and enlightening experience. Anyone doing any aspect of software development: engineering, design, support, documentation, as well as user interface folks, should be subjected to the experience. Though the our study was done with version 1.0 way back in 1993 many of the lessons we learned were timeless.
Two recent blog posts bring one particular lesson to mind. Coding Horror warns This Is What Happens When You Let Developers Create UI and Arno Gourdol discusses The Design of the Mac OS X Shutdown Feature:
It is the job of the software designer to make choices on behalf of the user. That's what designing is all about.
I worked with Arno on the belated PenMac. He contributed many ideas to the original Graphing Calculator design. (To give you a notion of the extreme attention to detail we paid on version 1.0: in the French translation of the credits page in the online help, the French translators localized his name to Arnaud Gourdol.)
I am in violent agreement with Arno's quote. As I expressed here, giving the user choices often represents our failure as designers. It is often easier to implement a choice than it is to program doing the right thing automatically. Complex dialogs, as parodied in the Coding Horror represent a cop-out.
We found something remarkable while sitting behind the two-way mirror watching users working in teams and talking aloud trying to figure out how to use the software to get their job done. Every group, nearly every time they faced a new question, would explore the software by linearly searching the menus, starting at the upper left with the Apple menu, reading each menu item, then proceeding to File and Edit and the rest. This linear search repeated many times by each group drove home the cost of each menu item. Each extra item was a distraction slowing them down each time they searched the menus.
Though the menus show you a selection of commands that the software can do, they do not tell you when something is impossible. We watched a lot of people read each and every menu item aloud wondering how to create two equations (which we did not have time to implement for 1.0.) Eventually, they sought the online help. At the time, with Mac OS 7.1.2 in 1993, the official Apple User Interface Guidelines directed that application help be brought up using the System Help menu, which was a ? icon on the far right of the menu bar away from the application menus. Most of user study participants did not know this, did not recognize the icon as a menu, and never looked in that menu. The one group which did find the menu, selected the first item in it, which enabled balloon help. Graphing Calculator 1.0 did support balloon help, but most of the messages were innocuous things identifying scroll bars and windows. That group was so distracted and frustrated by the balloons that their first comment was "How do we turn this off?" and they did not notice the "Graphing Calculator Help" menu item at the bottom of that menu.
Eventually, the person running the user study had to show each group how to bring up the online help. This was the only occasion where he had to step in. One thing we noticed while folks were searching the menu items linearly looking for the help is that some stopped at the bottom of the Equation menu saying 'The help should be here." So for the next build, we added a Graphing Calculator Help menu item at the bottom of the Equation menu as well as in the System Help menu as directed by the UI guidelines.
A later version of Mac OS moved the system Help menu to the end of the Application menus and changed its title from the icon to the word "Help", and later versions eliminated Balloon Help.