Game-day: your clutter is not my clutter

37Signals' Ryan Singer joined the controversy over the TripLog/1040 iPhone app's UI. Critics have faulted it as cluttered and, not to put too fine a point on it, ugly. Ryan points out that the designer made a concious tradeoff in order to meet user requirements for fast access to the two most common actions.

TripLog/1040 is a model of concision compared to real-time game trackers now common on professional sports Web sites such as the NFL Game Centers, the PGA shot tracker, and MLB Gameday. These applications provide a dynamic dashboard that gives direct access to scores, lineups, play-by-play in text and graphics, individual and team stats, and all manner of other information depending on the sport. Although they aren't mobile apps like TripLog/1040, they do illustrate that sometimes a UI needs to have a lot going on if it's going to meet users' expectations.

These applications are targeted at the needs of serious (read motivated and engaged) fans, whether of a team or a sport. They assume the viewer has a certain minimum of domain knowledge, enough to expect certain kinds of information. Furthermore, sports have long-standing conventions for representing game data with which they viewer may be assumed to be familiar. Event viewers are accustomed to processing several streams of information as they watch a game or event - at minimum the action and the scoreboard, with additional information that varies with venue or medium. Many also have their own collection of facts, stats, and other contextual information at the ready, either in their own memories or their co-viewers'. Some watch multiple events at the same time, through premium broadcast packages or using picture-in-picture, or simply timeslicing their attention to various broadcasts.

Game-tracking applications reproduce this rich information context on the Web. As a standalone experience, the applications re-create the suspense, anticipation, and armchair analysis parts of the sports-watching experience. They can also supplement individual or shared viewing experiences as information resources. Because the user doesn't have to navigate a page stack, the user can enjoy the experience rather than hunt - or wait - for hidden information. On the other hand, supplemental information is available on demand. Fans can explore it at will, for example, during breaks in the action, to get context for the next action, or to try to anticipate a team's next strategic moves.

If these applications were less "cluttered" they would also be less useful, possibly to the point of failing utterly to achieve their purpose. Game-day applications intentionally create a rich information context that match the needs and characteristics of the audience, and masterfully leverage the existing cultural context in which sports are played and experienced.

Read more...

The road is paved with good intentions

There's an interesting discussion going on at Chad Meyers' blog about quality in both design and execution. Chad argues there is such a thing as Good Design, that knowledgeable observers can reliably discern its presence, and that "but it works!" is not a defense or justification for bad design choices.

The bad design characteristics Chad spotlights prevent teams from responding effectively to demands on the application. With each release the team is less and less able to respond until they are locked in to long projects that deliver little incremental value. How do teams start down the path that leads there?

Chad's post hinted at an important consideration that doesn't seem to get enough attention. Too often people make fast delivery of finished features the top priority, then define everything else as speeding up or slowing down delivery. The problem is that driving to "finished features" (where finished = fully realized) prevents the team from engaging in "fast fail, fast feedback" cycles. If there is also a stated desire to work in an "agile" fashion the team might try to marry the "finished feature" driver with a short-timebox approach with disastrous results. On a large project few fully-realized features can be started and delivered in a single 2-4 week period.

The Agile team will look for a way to decompose the desired end feature into meaningful chunks and distribute the work across the team such that each 2-4 week period delivers a coherent, complete piece of functionality. The wish-we-were-agile team calls on the team to keep the feature "simple," not to "gold-plate" it. Once headed down this path all kinds of things become gold-plating - error handling, usability, even the goal of working software can be set aside under the banner of producing "good enough" software quickly.

Of course there is nothing wrong with "simple," "good enough," or "rapid delivery." Problems arise when the team identifies "simple" feature realization and "simple" process with undesigned, untested and incomplete. The team might find itself choosing to hack up a feature, not because it's a justifiable approach given the business needs but because their inability to decompose the feature and plan across iterations has created an artificial pressure to cross the feature off the project plan. That team can report that features are "done" but pays the price later when the customer doesn't accept the feature or the market demands more.

Read more...