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...

Showering penguin at the Aquarium.

Penguin at the New England Aquarium

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.

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."

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??

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.

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.)

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.

Birds in Ding Darling Preserve, Sanibel Florida

Bird ballet...
Ballet 2:

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:

Shropshire, Tree Art.

[Note for RSS readers: This is an old post, on which the comment spam had gotten out of control. I've removed and republished disallowing comments.] This was surprisingly eye-catching and disturbing as I was tooling down the road in Shropshire last month:
To be honest, I found it pretty horrifying. I went out of my way to drive past it and take more closeups, when I came back from a couple nights in Wales.
I asked in a local pub, and it's some kind of strange art project, of which I can find nothing on Google in a quick search ("red tree art painted Wales Shropshire what the hell were they thinking I almost drove off the road it looks like a pagan devil worship site").

Why Free Software usability tends to suck

Matt Thomas, a Mozilla contributor, has some interesting observations about design on free software projects. If you're a fan of evolutionary design by accretion and multitudes, you might want to check out his concerns in Why Free Software usability tends to suck. (It was picked up by a number of people including Joel back in the day.)

One of his points will be controversial to some people, I think: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

I don't think this is necessarily true in a non-opensource environment; and, to be more concrete, in a software environment where people aren't argumentative prima donnas, communicate regularly, and reach consensus before implementation of the crucial features. But when there's frequent handoff of work, a tendency towards grandstanding or power plays in the design phase, or poor communication, it will be true.

Updated to add: He has a sequel article based on comments he got on the original, at Why Free Software usability tends to suck even more. His points continue to be good, including the inspiring last comment, which I think is also is true in any organization: As with previous critiques of Free Software, each of these weaknesses will become less of an issue proportionally to the number of contributors who read about them, and learn to recognize and combat them.

In software companies, this is known as "risk management." Doing that well in a design process requires recognizing the failure modes, worrying about them, and making yourself immune to them.

Beyond Salmon

A friend of mine, Helen Rennie, once entertained me and several work colleagues on the subject of fish for a good half hour. We were on a work trip (to Disney, but that's another story) and we were sitting beside a fake pond; she told us an awful lot about different kinds of fish with suspicious enthusiasm. I hadn't known her very long, and I thought, "Wow, this is almost weird."

Later it all came clear: she's a fish cooking expert! She's been writing a fish cookbook, which involves interviewing fishermen and fish dock storage warehouse people (or whatever they are), teaching popular fish cooking classes at Cambridge Adult Ed, eating at and reviewing excellent restaurants online, and now has a fish blog: Beyond Salmon. Go read about fish. She's smart about it.

Ohio Ghosts Like Golf

An unusual article: a detailed look at Ohio golf course ghost stories. Read about them at GolfStyles : Ohio.

Scott Berkun on Train Wrecks

A week or so ago, I went with a couple colleagues to hear Scott Berkun talk on software project train wrecks. It was entertaining, albeit rather painful, for people who have been victims or occasionally contributors to such disasters.

Like any UI guy worth his paycheck, Scott notes that the crux of the software design matter is often team management and project management. I find it not the least surprising that he and Joel Spolsky, also noted for his UI and design observations, are both so sensible on the topic of project management. Scott's new book, The Art of Project Management, is getting raves on Amazon, and I'm cheering as I read it. (I'm not sure you'll recognize the insights for what they're worth if you haven't lived through the kinds of process issues he describes, but I find him right on.)

Scott's slides are here. His diagnostics for train wreck projects are these:

• We know we won’t meet goals
• No one is happy / Everyone is frustrated
• Things keep changing, but there is little progress
• We don’t know if we’ll be able to solve them
• We don’t agree on the existence of problems
• We don’t know whose job it is to solve them

Sound familiar? For some people, this might describe entire companies! He has more specific criteria for design disasters, which may be even more familiar, since design is so hard to do well (depending as it does on more factors than simple project management):

• Disconnect between the “design” and what’s being built
• No one knows what the “design” is
• No one knows what the goals are
• There are competing designs being built simultaneously, and unintentionally, by different people
• The design has no possibility of satisfying goals: Customer / Technology / Business;
• Note: People with different goals will define disasters differently.

And finally, he hit my favorite subject, good teamwork. Good teams:

• Avoid many problems and rat holes
• Are good at recognizing/communicating issues
• Are good at using each other to help solve its problems
• Teach each other how to find and resolve problems
• Make mistakes, but are encouraged to learn (not hide)
• NOTE: One team’s train wreck is another team’s good day.

I was surprised not to find my favorite study of effective teamwork (Teamwork: What Must Go Right, What Can Go Wrong) in his bibliography.

Update: Here's another good review of Scott's book.

Networked Governance: Network & Teams

Harvard University has a Program on Networked Governance, on whose site I found some nice links on networks and teams. I thoroughly enjoyed the literature review in their first article link, Building Effective Intra-Organizational Networks: The Role of Teams (pdf). The starting observation is that there hasn't been a lot of research cross-over between people studying social network analysis (SNA) and effective teamwork in organizations.

As a tourist in both fields, I found the literature review and the points of contrast and comparison very interesting. It's a good intro to both fields.

• Bavelas and his colleagues at MIT conducted experimental analyses of how communication patterns among teammates influenced team effectiveness ... When the information was simple, centralized communication was optimal. When the information was complex, centralized communication was dysfunctional.[Me: For decentralized communication to work, the network must be highly functional.]
• The paradigmatic focus of team research is on the task performance of a small group with a clear and well-defined boundary (Alderfer, 1977) “Clear and well-defined” means that team members and outsiders know who is on and who is off the team (Hackman, 1990). This is a critical element of the very definition of a team. [Me: This is also the in-group/out-group issue I found in the community studies literature in my dissertation research. Individuals who are shared across multiple teams may have a harder time identifying with any one team, and this may impact productivity or team relationships.]
• For teams with little autonomy or with overloaded team members, communication initiated by the external environment negatively affected team performance. [I guess this includes management wrenches thrown in the game very late...]
• Do team members know each other before the team exists? Jehn & Shah (1997) found differences in intra-team communication when they compared teams composed of friends to teams composed of acquaintances. [Not surprising. Check who has lunch with each other!]
• We know that a team’s success or failure can influence subsequent feelings of cohesiveness among teammates (Turner, Hogg, & Smith, 1984). One possibility is that misery (lack of success) breeds company (connectedness). Another possibility is that successful collaborations result in increased communication. Lack of success may lead to a vicious cycle of failure, leading to disconnectedness, leading to more failure, and so on. [As a manager I would think hard about retaining the same team members in a context where their first product was seen as having been a failure... or where they thought it was.]
• While knowledge networks describe who knows what, each individual in the organization also has his/her own perception of who knows what, or a “cognitive knowledge network” (Contractor, Zink, & Chan, 1998). Cognitive knowledge networks are a combination of knowing who knows who, and who knows what – i.e. who knows who knows what. Cognitive knowledge networks vary in their accuracy and completeness (Contractor et al.), where higher levels of accuracy can be expected to result in greater access to the knowledge in the network. [An environment where people don't know what other people know, or who knows what is a risky environment for the success of a teams and individuals.]
• Another mechanism social systems have that regulates individual tendencies toward noncooperative behavior is the possibility of continued relationships, because the fruits of future collaboration are at stake (Axelrod, 1981). ... We would expect teams made up of relationships with a greater expected duration will suffer from less free riding. When one free-riding team member can “crash” the entire team, and free riding is thus a dangerous risk, a desirable network will feature high levels of embeddedness, strong ties within the team, and expectations for future interaction. [Free riding, of course, is slacking off, in a work context. So, if the team hasn't felt it has been a failure, the existence of the group over time encourages individual performance and communication.]
• When a manager assigns people to teams, he/she is molding the social capital of the organization. .. There are two overarching points here: (1) when assigning people to teams, managers should consider the impact of a team on the organization’s long term social capital; and (2) managers should consider viewing social capital the same way they view other types of capital: it may need to be amortized over time. Under certain conditions, it may even be worth sacrificing some short-run team performance for the sake of fostering long-run organizational performance.

I really enjoyed this article, but then I'm a great tourist.

TextArc's text displays

TextArc is a rather stunning thing -- I can't tell how useful it is, but it sure is pretty to play with. To encourage you, here's the view of "Alice in Wonderland" as it's being crunched and cruised by me.