I wanted to offer my own opinions on a couple of talking points I’ve heard about this world cup:

“It was a bad”
I think this is said about every world cup. I’m not sure if I’ve actually heard it said or just heard people saying that it was said (which probably means no one has actually said it). Regardless, it’s a little bit of bunk and a little bit of unrealistic expectations. There seem to be three main arguments:

1. Boring matches
   World cup matches are often more tentative than club matches for various reasons (it’s an elimination tournament and the guys don’t normally play together), especially at the beginning. But I don’t think, percentage-wise, you have any lower ratio of exciting games to boring ones. You just only remember the exciting ones from last time so when you come crashing into a boring one, you think there’s more of them (that’s the availability heuristic, if your keeping track).
2. Bad refs
   The officiating seemed to be bad, but there will always be a ref or two to complain about. This tournament was no different than others. It made for some frustrating moments, but bad reffing didn’t really change the outcome of any match. You could argue with me about Frank Lampard’s truant goal - that it would have completely changed the momentum of the game - but, really, do you think England deserved to go farther in that tournament?
3. Bad Dutch
   Did the Dutch turn the final match into brawl? Kind of. I kind of went the opposite way with my opinion of that match (see below).

“The Spanish style is not fun to watch”
This one twists my corn, and I have actually heard people say this one - that tiki-taka, as it’s derisively known, is frustrating or boring to watch. This is wrong. I’m not going to be diplomatic about this - it’s wrong. One thing that became fairly obvious quickly after starting to watch the top teams on a regular basis is that soccer is about possession. If you own the ball, you own the game. If you make the ball available for interception, then you no longer own the game. So long balls down the middle to your target man (otherwise known as the English style) are, by and large, foolish. There are many arguments against this kind of possession soccer, but that it’s ineffective shouldn’t be one of them.

The other main argument is that it’s slow and frustrating (they’re just dicking around with the ball). If you think that, stop watching soccer. Seriously. If you don’t like to watch crisp passing and playmaking ingenuity, why the hell do you watch the game? Sure, sometimes the long ball to the forward on the break works and is great to watch. But that success is not balanced by the frothing frustration of the 95% of times that ball winds up with your opponent.

And another argument I’ve heard is that it’s too hard to do; that you need a team with the payroll of Barcelona to be able to pull it off; that the players with the necessary passing skill are too few and too expensive. I can’t argue that with data, but I suspect it’s crap. I suspect that there are lots of players with the necessary skill. Superb control and passing ability should be table stakes for a soccer player in the top income bracket. Anyone know a team with a lesser payroll that plays like Barcelona? There’s gotta me some.

“Howard Webb should have tossed the Dutch out willy-nilly”
Most will tell you that the ref in the final was not hard enough on the Dutch; that at least two of them should have been red-carded. Possibly more; that he should have taken tighter control of the game and doled out the cards earlier on in order to shut down the Dutch strategy of attempting to hobble the Spanish at any opportunity.

While I can see the reasoning behind this, I actually though the opposite while watching the game. Yes, de Jong should probably have been thrown out, but for most of the fouling going on, I though Webb should have let them play. There were a number of advantage opportunities that weren’t allowed and a lot of little fouls that just could have been ignored. It may be that I have too much confidence in the Spanish players’ ability to shrug off the odd foul and continue to run circles around their opponents, but that’s they way I saw the game. Had the ref allowed them to play more, perhaps the Dutch would have amped up the physicality, resulting in an even uglier game. Or perhaps the amping up would have resulted in some earlier ejections of Dutch players. I see what Webb was trying to do, and I think he did a decent job of it, I just think there was a chance that this could have been a more entertaining game, but that chance was missed.

That’s my wrap up. I am by no means a professional (and I’ve never actually played organized soccer), so take it for what it’s worth.

This is the one I mentioned in the earlier post, from a study at the University of Bristol. (You can visit that site and download a nice, big PDF of it, too.) It shows all dinosaur species and phylogenetic relationships (which ones are related to which other ones by having common ancestors). The outer rings group them into orders and then further into sub-groups. Then all the individual dino names are listed radially with the lines connecting them toward the center.

You often see cladograms rendered as linear trees - left to right or top to bottom. Since species do, in fact, evolve from a center out (last common ancestor out to most recent), those can’t capture the relationships between the left- and right-most groups on the tree. But the radial chart can. And this one helpfully renders the text so that you don’t have to read names upside down (methinks a designer had a look at it at some point…)

This next one comes from a paper in PLoS One from 2008 called Tree of Life Based on Genome Context Networks. It shows the relationships between - well - everything. They attempted to show the whole tree of life (an abridged version of it) by showing the relationships between a selection of species that were representative of different kingdoms or phyla (i.e. fungi, plants, animals, and a bazillion different kinds of bacteria). In this case, however, they did not bother to correct for the readability of the species names like the one above.

One of the challenges is that users usually perform very different tasks requiring specialized tools with complex data requirements. For example, researching a stock requires consuming research, news, technical information, market information, mathematical models, portfolio risk metrics, etc. Trying to put all of that in one application is usually chaos.

One of the advantages is that users are typically operating with multiple monitors. Two generous monitors at least; four is common; I’ve heard tell of eight.

So for several projects now we have advocated applying the latter to the former to create an independent windowing framework for complex application suites.

Most legacy applications we find at our clients are traditional windows SDI apps. More recently, we often find clients using an rich framework such as RCP or a .Net equivalent when they build new enterprise applications. This offers some advantages over the traditional SDI or MDI. Most notably the addition of modules (views) for supporting (or sometimes unrelated) data. For lack of a term to describe the UI model of RCP, I’ll borrow from the engineering model and, for the time being, call it a Component-Based Application (CBA) UI model. If anyone knows of a real term for this, let me know.

CBA apps typically separate activity units into different perspectives (in RCP land) or tabs (in .Net land). This differs from a traditional tabbed document interface in that for the typical TDI all the documents are functionally identical. Not so the tabs in a CBA app.

Perspectives or tabs exist to separate the high-level conceptual units of the application (in the financial examples, this could be “portfolio”, with positions and metrics and “trading” with performance and pricing data). But this distinction is typically not clear to users, leaving them unsure in which tab to find certain information. Add to that the ability to “tear off” content modules - create a free-floating copy of it that may or may not respond to events in the main window depending on implementation - and you have a pretty confusing interface.

The solution we’ve recommended several times now is to contain the high-level conceptual units in their own windows, each independently accessible via a persistent launch panel. And each capable of multiple instances.

Our original concepts did away with the TDI model (perspectives in RCP). Essentially, each tab would be it’s own application. This solved a couple of problems:

First was the confusing navigation problem. Each app is design for a specific purpose and the content in it is designed expressly for that purpose (as opposed to the mix and match of modules often seen in CBA apps). And there’s a dedicated launch panel that provides a navigation anchor for the user.

The second problem concerns task-interrupt scenarios. In a typical single workspace, the user must switch tabs to pursue a different task, hiding what they were doing in the process. They then must re-acquire the original task and can not view both simultaneously. With the independent widowing model, both problems are minimized.

Seen from a distance, what I’m describing sounds a lot like a collection of standalone apps, no different than the legacy tool set we are supposed to be supplanting. But there are some critical distinctions that enable this model to work:

1) The independent applications are all built on the same foundation (we’ve used both RCP and .Net as the underlying platform). It is not even necessary that the applications be applications - they can simply be windows slaved to a single application (akin to Adobe’s UI approach), as long as they are independently accessible and can be instantiated multiple times.

2) They also share a single interface design framework - same UI constructs, look and feel.

3) And the independent launch panel is key. It can take many forms, but it must provide the ability to launch multiple instances of any of the tools and track open instances to allow the users to relocate them.

Currently, we have a few systems still in development that use this model, so it’s still a theory. There are some known issues that we’re hoping to work out through the course of these implementations. The first concerns the launch panel, which duplicates some of the functionality of the Windows task bar, leading to questions about its utility. But if you think of it as a more richly featured custom desktop toolbar, some of those concerns go away.

The second concerns general client guidance. In one case, fear has crept in and we’re finding that our client wants to keep the tabs/perspectives and perhaps combine some content into only a few multi-function windows. I feel that this is a mistake and will result in an interface that is more confusing than either the independent model or the CBA model alone.

So time will tell if we can adequately coax this vision of usability for complex tools into its full potential.

First, a little background. There are numerous broad domains in information architecture / UI design. You got your consumer web sites, ecommerce, application UI, etc. Another way to slice domains is by the dev/user ratio. For most consumer-facing sites or apps, your looking at a small pool of developers supporting thousands or millions of users. On the flip side are internal enterprise applications where the ratio is inverted. That’s where I’ve been working lately. Specifically for companies in the financial services industry. The organizations I’ve been working for have a hundred or so development and support staff maintaining apps for 10 to 100 users. These are core, mission-critical applications (can I sneak more business jargon in there? Let’s see… “strategic” - how about that?).

In particular, the applications I work on are intended for core activities like stock trading, portfolio management, research, etc. They are a number of desktop applications that are intended to serve individual tasks. The data can be complex and are almost always time-sensitive. The applications communicate with one another to comprise a broad set of enterprise supported tools.

I mention this because it’s entirely likely that what I’m about to talk about does not apply to the other domain with lots more users. I work directly with a sizable fraction of the entire end user community and our processes reflect that.

That said, the issue that came up was “how do we design for modularity and re-use of components?”. This was a response to a design that we put together for a complex display of data in a tree grid. Because our grid design combined many different data sources as well as different data types, developers asked if we could take our complex display and break it into smaller, discrete chunks on the theory that we might want to re-use some of those chunks in other tools that we have not yet developed.

This sounds like a great opportunity and an intelligent way to go about your design. Modular is good, right?

Those familiar with agile will have already recognized that the idea is at odds with a fundamental tenet of the approach: work on today’s task and get it out the door, don’t spend time analyzing what-ifs.

And as I discussed in an earlier post, that approach is valuable for UI design as well. But since the idea of modular design for re-use is a valid one, it’s worth explaining why I think it’s not generally a good idea and how it might better be addressed in an agile environment.

It will be valuable first to briefly explain how UI design typically works in agile. Normally, the UI team spends six to ten weeks to design an overall concept (or vision) of the application or set of applications before estimation and planning of the development effort. This is all before anyone even thinks about writing code. The goal of this phase is not to design everything to the last detail, only enough to estimate the effort to identify and design for all the actual requirements. That means that we expect to have gaps in the concept that will be uncovered when we identify the low-level requirements during iterative design and development. Sometimes the actual UI can diverge from the concept substantially (though not usually).

So the initial concept is not comprehensive and will usually not call out all the opportunities to re-use content around the tool set. You could spend more time to get the concept more accurate, but you’ll face rapidly diminishing returns (in my opinion) on that. So planning for re-use of content falls into the iterative design process, where the problems arise.

The first problemis fairly obvious: it will take longer to design for re-use. You have consider how to chunk your information for the flexibility to apply it to different situations. The value of that exercise might outweigh the effort, so it’s not a show-stopper. But agile is all about getting functional product out the door, so extra time is usually not good.

Second, and perhaps most important, is the fact that you’re trying to solve a particular problem. UI design is about identifying triggers, goals, outcomes - in other words, activities. Your primary objective should be to design an interface that satisfies that activity. By planning for other uses, you run the risk of designing something that might be useful for multiple applications but is not optimal for the one you should be focused on.

Lastly, unless you have a darn comprehensive design framework in place (not usually something you have in agile projects), you won’t know that those other uses for the chunks actually exist. And why spend time designing for things that may or may not exist?

That is why you generally shouldn’t do it. But that last reason raises some interesting questions about the potential value of designing for re-use. Those questions stem from the fundamental ambiguity of designing within an agile process - you don’t know what you’ll come up against next. You can potentially save some design and development time by targeting modularity and then mixing and matching your modules later on.

So, how? Well, that’s complicated. And this is where the domain difference comes in to play. If you’re designing an app for a handful of users and it’s critical to the business that it support specific activities of those specific users, then you had better have something that nails those activities. So the idea of assembling prefab parts and expecting it to fit the need is troubling. But perhaps not impossible.

It is entirely likely that those users will want the same piece of content in different contexts - for instance when they’re researching a company stock and when they’re actually trading it. Designing for that can enable you to add value for the users with little effort.

As I mentioned in discussing process, when starting the detail design in the iterations, what we have to start with is a concept - a rough draft of the overall application set but not a lot of detail. You may identify some reusable components. Indeed, there should be many common constructs to effect interface consistency. But common content will not be typical as the tools are generally solving different problems requiring different content. We can, however, try to use a UI model that encourages modularity.

There are a couple of strategies for this. There’s a tile system, where everything is a separate module with equal weight (think iGoogle) and a parent-child system where a primary component drives detailed content in smaller surronding modules. RCP applications tend to be a bit of both.

As long as you define what kind of content goes in what kind of module (e.g a lists of things go in a primary and details on a specific thing goes in a child module) you can design to that framework. This is totally achievable as part of the design project. So that’s one way you can target re-use.

But that’s not always satisfactory. What if you need to see that list of stocks and details on five of them at the same time? That’s kind of constraint is not uncommon. You would have to consider alternate ways of arranging your content. So you’re back to spending time designing for needs that may not exist. Even if you have a modular framework designed, I would say that you’re better off designing for the known need than for the framework. Maintainability certainly suffers, but the users don’t.

So, bottom line. Designing for re-use is not a flatly bad idea, and it can be done, but you have to plan for it and probably spend some extra time up front. But the value of this is questionable and you may have to abandon it from time to time anyway.

While not technically human, the long-awaited Ardipithecus ramidus has been released to the world (yes this happened a while ago - I’m slow). Science has free online access to lots of articles on it. There’s also a pretty good initial take at Pharyngula.

A. ramidus has been the subject of some controversy for a while, since the discoverers of the fossils held them away from scrutiny for 15 years before publishing. It turns out (if you believe the story, and there’s no reason not to) that the fossils were in such a poor condition that it took them 15 years just to get all the little bits of bone out of the rock and piece them together.

Moving on, Ad Hominin has a number of interesting posts (none of which are terribly recent, I’ll admit):

A little human with very big feet is about Homo floresiensis. Seems the idea that they are pathological Homo sapiens doesn’t hold water these days. Still not sure where they came from, but researchers are inching closer.

Finger points to new human is about a finger bone found in Siberia. Mitochondrial DNA analysis indicates it’s an unknown species of human that lived in the area of 40,000 years ago. So if you’re keeping score, that means we had four different species of human alive at the same time (Neandertal, Floresiensis, us, and the new guy).

The incredible shrinking human brain - very not new, but I didn’t now that human brains have been getting smaller.

We moved
House, yard, picket fence - the works.

My son started kindergarten
Yikes.

I started commuting to New Hampshire
About as boring as it sounds.

We moved to a hotel for two weeks so our house could get de-leaded
Four people. Two rooms. No TiVo.

Now. On to more interesting things…

One guess what’s in the attachment.

I haven’t seen anything like this in years. Since I started using Gmail, actually. Every now and then Gmail just blitzes and crap gets through for a while. They have raised my expectations to unfulfillable heights, apparently.

There is a “safety net” that is supposed to help low income residence pay their out-of-pocket expenses. To do that, it reimburses the providers for copays, deductibles, etc. Apparently, the payouts from the state have gone down recently. That’s probably part of the larger budget shortfall, but it points to a bigger problem with the system paying for itself (which it certainly isnt).

All in all, I’m glad that Massachusetts tried something. But I’m not sure it’s a good model for the rest of the country. And I certainly don’t think we have enough data to make a judgement yet.

Firstly, about 97% of Massachusetts residents now have health insurance. That’s the highest in the nation. Of course, that’s because if you don’t get insurance, you pay a penalty. The amount depends on your income, but I’m pretty sure that everyone who might read this makes more than 300% of the federal poverty level and so we’d all be paying about $900 if we had no insurance for the whole year (tax year 2008).

Second, it’s wound up costing the state a lot of money. We had hoped that the cost of subsidizing insurance for the non-wealthy would be recouped by not having to pay for their emergency room visits. However, a recent survey suggests that use of the emergency room has declined only marginally since 2006. A recent report says that use has actually gone up, but that included only data from 2005-2007 (the law went into effect at the beginning of 2007 and the penalties were not as high then).

There is some suggestion that this might be due in part to long waits to see doctors in Boston. What I don’t entirely understand about this, though, is if the people going to the emergency room have insurance, how is that costing the state money (apart from the state subsidizing their premiums)? I can’t find an answer to that one.

Thirdly, Massachusetts is in a financial pickle, like a lot of other states, I imagine. We have big budget problems across the board. As a result, the state has had to cut $115 million from the organization that subsidizes health insurance, CommonwealthCare. The cuts come from a number of areas, none of them good (eliminating dental for the poorest, not automatically enrolling those eligible for complete subsidy, etc.), but since CommonWealth care is a program for people who can’t already afford health insurance, it’s them that’s going to suffer. I reiterate, however, that this is due to a general budget shortfall. Governor Patrick’s budget had cuts pretty much everywhere. CommonwealthCare may have fared a little worse than some, but the budget cuts do not appear to reflect a systemic problem with the health insurance law.

Lastly, the Massachusetts law doesn’t seem to have done anything about curbing the cost of health care. Here’s a study that says that lots of MA residence spend more than 10% of their income on health care (personally, I left 10% in the dust a while ago). And an article about people struggling to pay copays.

The health care reform was supposed to help a bit with the cost of insurance - by factoring in total out of pocket expenses when calculating the minimum level of insurance that someone must have. But for some reason, costs for prescription drugs are not included.

Bottom line: Almost everyone has insurance. That’s good. Not everyone is using it properly, but that’s due in large part to availability of care. And it hasn’t saved anyone much money. That’s not good, but it’s also not really what the law was for. And any budget shortfall that the Connector Authority (the state agency in question) has is intertwined with a larger shortfall due to the crappy economy.

Bottom line on the bottom line: the only thing we can say for certain is that more people have health insurance. The rest is muddy.

How Many Scientists Fabricate and Falsify Research? A Systematic Review and Meta-Analysis of Survey Data
Fanelli D, 2009 How Many Scientists Fabricate and Falsify Research? A Systematic Review and Meta-Analysis of Survey Data. PLoS ONE 4(5): e5738. doi:10.1371/journal.pone.0005738

The study found that around 2% of scientists admitted to falsifying data while around 30% admitted to less serious misconduct.

There are lots of problems with studies like this - lots of confounding factors in self-reporting - that the author acknowledges, but it might be a conservative estimate.

The study doesn’t get into what percentage of studies have some misconduct associated with them (as opposed to how many researches have done it at least once) nor how it might effect the research, but it’s still a problem. I should point out that no one has ever said scientists don’t succumb to this sort of behavior - just that the peer-review system is supposed to catch it. Peer review doesn’t seem to be quite as effective as one would hope (but it’s better than a free-for-all).

The paper also mentions the “Muhammed Ali Effect”, of which I had never heard. It describes the tendency of people to think they are more honest - but not more intelligent - than others. And it’s been the subject of numerous academic papers in various discplines. I had no idea Ali’s reach was so great…