Wednesday, November 30, 2005

TiVo Conference call follow up

Notes from the latest TiVo quarterly conference call.

Some discussion of the Comcast deal, of the impact of advertising spots, HD issues...

Saturday, November 26, 2005

Showering penguin at the Aquarium.
Penguin at the New England Aquarium

Thursday, November 24, 2005

Number Factoids

Another break in the Thanksgiving cooking. Check out tingilinde: take a number .... I'm far from a mathematician (and was even when I dated one), but I find this list of number facts magical and opaque. These are my favorite of the inscrutable, OCD, and sometimes just silly observations:
  • 4 is the smallest number of colors sufficient to color all planar maps.
  • 11 is the largest known multiplicative persistence.
  • 17 is the number of wallpaper groups.
  • 36 is the smallest number (besides 1) which is both square and triangular.
  • 38 is the last Roman numeral when written lexicographically.
  • 92 is the number of different arrangements of 8 non-attacking queens on an 8x8 chessboard.
  • 136 is the sum of the cubes of the digits of the sum of the cubes of its digits.
  • 405 is a pentagonal pyramidal number.
  • 570 is the product of all the prime palindromic Roman numerals.
  • 1005 is the smallest number whose English name contains all five vowels exactly once.
  • 1084 is the smallest number whose English name contains all five vowels in order.
  • 1435 is a vampire number.
  • 1650 has exactly the same digits in 3 different bases.
  • 1666 is the sum of the Roman numerals.

Anyone know what a vampire number is? An amicable number? And can anyone help him fill in the ???'s? (Huh, looking at the list, I'm reminded that I kind of liked geometry.)

Paris seen from a Ferrari's bumper

I got this one off Steve's tingilinde which I'm catching up on after a couple week's of distraction with a new job...

I used to love late night taxi rides home from dinner or bars in Paris-- being a bit tipsy made the lights and the curves in the road and the people on the pavement cafes flow together in a very scenic and exciting blur. (I fantasize about going back with a camera and trying to recreate that sensation.) Well, some nut has made a film of an early morning high-speed drive through Paris, shot bumper-level, from a sports car.

I counted about 22 red lights he ran. I could be off by as many as 5. I got lost in the northern Paris roads, but wasn't surprised where he ended up. (The most entertaining and hair-raising section is in the middle, where he has to get through the center of town around the Louvre and just north of it. The last scene is really nice and very French. I read her expression as "Wow, you didn't get caught or killed!") Note, the starting text says it hasn't been accelerated or cut in any way.

Tuesday, November 22, 2005

Fairies Stop Building Plans

Yes, this happened recently in Scotland. I'm sadder about the plan to move the stone and carve the development name into it than I am about the fairies who live under it being disturbed, but then I don't live near them.

And an award winning last paragraph, a good start for a B fantasy novel: "The new estate will now centre on a small park, in the middle of which stands a curious rock. Work begins next month, if the fairies allow."

Thursday, November 17, 2005

MATLAB Programming Contest

The MATLAB programming contest just gets bigger and better. Here are Matt Simoneau's charts and graphs of the evolution of the submissions and scores over time. What could be cooler than this contest??

Tuesday, November 15, 2005

Bird head, Sanibel, Florida.

Reasons ease of use doesn't happen

Martha Stewart has her 10 Rules for running a business, and Scott Berkun has 14 reasons Why Ease of Use Doesn't Happen on Engineering Projects. I wanted to cheer out loud as I reread this. Maybe it's just because I've lived through so many of them and some so recently.

Take 2, "ease of use is not an actionable goal." If there's no criteria for success, it's easy to stop paying attention to this, even if you thought it was an objective rather than lip service to "doing the right thing." "When stressed, most humans prefer to focus on things that are tangible and well defined, rather than vague and poorly defined. So even if ease of use is an explicit goal of a project, if it is not broken down into discrete and measurable pieces, or tasks and work items for someone to do, it will remain an abstract idea that no one feels pressure to fulfill."

Item 3, "decision makers don't see the tradeoffs," is probably one of the most important but most difficult to manage. Because it requires management to be bought in and innovative in software processes. "To get an easy to use product, a different kind of thinking and planning is required.... Team leaders have to recognize how ease of use effects other engineering decisions, and must modify their decision making process to account for it." This is echoed in #7, "Technical focus dominates the view of the project," wherein team leaders get obsessed by brilliant architecture and leave the UI to last or second place. Hey, your customers don't care how brilliantly it's architected, even if it saves you time later. "Wise engineers understand when they don't have the right sensibilities for certain kinds of decisions, and know to yield them to someone more appropriate. An arrogant engineer will tend to assume that what they do not understand must be trivial, or worse, doesn’t exist at all, and will proceed to apply their hammer to things that are definitely not nails."

"Confusion over who the customer is" vs. client vs. user is a good reminder issue. Often the person buying it isn't the person using it, and more often, the person building it isn't really representative of all users, even if they think they are or have some domain expertise.

#8, "Diffusion of design authority (Too many cooks)," is reminiscent of the post I made recently about free software usability issues; "When authority over the design of a project is distributed across too many individuals, the likelihood of a high quality final design decreases. The worst approach is design by committee, where lots of people who don’t have shared goals or shared high level ideas, get in a room and torture each other with compromises until mediocre results that no one likes, but everyone can just barely manage to live with, are achieved." Good design requires good design leadership, unified vision ownership, not widgets built separately thrown together into a patchwork at the end of the day. Good design isn't just the sum of all the features you are adding to the latest release. "In either case, being an effective designer, or design authority, means the ability to: generate good ideas (creative), convince others of an idea (conviction and communication), and integrate the best ideas and feedback that others around them have (mature egos). Good design leaders are therefore quite rare." Of course, you have to know you need them and how to identify them, in order to hire them.

This is closely related to point #12, "The wrong people are involved," the case in which the wrong people own the design decisions. Even on teams with UI designers, I've watched this play out in team dynamic. And it's worse when there's no recognized UI design authority or the wrong person has it for the problem at hand. "The craft of designing interfaces is a unique skill. It requires an individual to have at least four personal attributes: compassion for other people, abstract problem solving skills, the ability to communicate or detail web/software design ideas, and experience crafting designs and watching people use them. Giving design authority to programmers or project managers without these traits is unlikely to work out well."

"Feature design vs. task design," #9, is the reminder that just because you have the bullet on the box doesn't mean anyone can achieve a work goal with it. Did your customer do something real with it? (This could be one of your actionable criteria for #2 above.)

#11, "General incompetence," is another good reminder -- teams might suck, and leaders might suck, despite all best intentions and well-produced documents. Check your team chemistry and ability to Get Things Done Well as a Group.

Well, they're all excellent points, and I think it's worthwhile using them as a diagnosis form for your organization if you think poor usability is a problem you suffer from. The Root Causes may be deeper and more diverse than you thought, but Scott has suggestions for almost all of the issues he lists. If you don't know if you suffer from poor usability, you're even one step behind the need to diagnose why you've got it -- and trust me, you're probably very sick.

Sunday, November 13, 2005

The Stone Balls of Costa Rica

While looking for information on a fellow UI designer at Autodesk whom I heard about at the Group05 conference, I tripped over this article: The Stone Balls of Costa Rica.

Apparently there are hundreds of these round carvings all over the country, ranging in size from centimeters to meters. They are now used as lawn ornaments by the rich! Also, according to this archealogy thread, as doorstops at a tourist cabana. Like all stone artifacts, they aren't reliably dated, and could have been "created" anywhere from AD 200 to 1500.

"For me, the spherical shape probably evolved in response to the need to move these objects. After all, spheres roll in all directions with minimum resistance. We find spheres weighing several tons atop 100 m high hills, so transport was an important consideration," says John Hoopes in the email thread. This argument seems, to me, a bit circular (not to mention spherical). I mean, primitive man moved monoliths to Salisbury plain, without having them spherical. (On the other hand, maybe the ancient English just weren't smart like the Costa Ricans?)

The photo of the stone ball is credited to Erin Bradner, who may or may not be the same one I was searching for at Autodesk. If she is, I think we'll get along just fine! (She also seems to have a respectable publication record in the field of computer-mediated communication, where my dissertation fit as well.)

Saturday, November 12, 2005

Review of the DirecTV TiVo "replacement"

As you probably know, DTV ended their deal with TiVo and their offer of a TiVo unit for their subscribers, and have now developed their own ripoff. I say "ripoff" because it sure looks like a close copy in the review and screenshots this guy has up here: A Review of the R15.

Admittedly, there are a couple of things in here that I consider improvements, things we got wrong that haven't yet (AFAIK) been fixed in the TiVo UI. And they do offer the often-requested disk usage measure :-) But they have outright copied much of the UI including a lot of the TiVo UI wordings, while losing the friendly look&feel and sound effects. I imagine there are grounds for lawsuit, especially if it's true that they copied the fast-forward autorewind correction, for which I am quite sure TiVo has a patent.

Wednesday, November 09, 2005

Stats on LiveJournal

Some friends helped me out with a short panel talk I gave on LiveJournal today at a conference, so I thought I'd share a couple pictures and stats. One person on LJ asked me about the demographics of LiveJournal usage. LJ admin posts regular automatically generated stats on their stats page. I collected some in March this year, and then again this month for this talk, and they showed this pattern.

Note that the number of accounts has increased, but the level of activity is flat. This suggests some disturbing things for the growth of LJ usage, at least in terms of persistent regular usage.

Also, it's been true for the lifetime of LJ as far as I know that the usage has always been 2/3 women, 1/3 men; with age frequency peaking at 18 (with a long tail down to 55 or so).

Finally, here's a picture of some community structure I generated, too far out to see any identifying people: