http://gcn.com/Articles/2010/10/18/Daconta-power-and-perils-of-dashboards.aspx

Finally, and most importantly, the population strategy for your dashboard should be automated and trusted. Do not bother creating fancy graphics for fake, manually input data that crumbles under its first critique. The source of your data should be as automated as possible and come directly from an authoritative data source.

For the enterprise architecture dashboard, a critical part of the population strategy is direct feeds from various existing development tools and repositories. To build trust in the dashboard, your population strategy must include lineage and data quality. Lineage is the traceability from source to resulting product and all intermediate repositories in between. In a nutshell, lineage is the roots of the data, so you can answer the question, “Where did you get that data from?”

In addition to lineage, the rest of the trust equation involves the assurance of the accuracy, completeness and timeliness of the data. Such characteristics, in addition to a few others, are delivered via a managed data quality program or initiative. Nothing will kill a dashboard faster than poor quality data.

Those clever Googlers.

Can Entrepreneurs Lower Our Taxes by Rebuilding Legacy Government Systems?
http://www.pfhyper.com/weblog/2010/02/can-entrepreneurs-lower-our-taxes-by.html

“Perhaps what is needed is to let the dinosaurs become extinct and be replaced by swift birds and mammals.”

The thaw began at the recent KMWorld conference in San Jose. My big take home was that making information findable on our web site is no longer enough… it needs to be findable by the many paths that users will take, including Google, blogs, and social networking sites. And that even if we aren’t using “web 2.0,” many others are, and they are the ones shaping our presence in that space.

One highlight of the conference was a presentation by Peter Morville (author of Ambient Findability). It hadn’t really hit me until his presentation how much wayfinding occurs outside of our webspace. Duh. Only 1/3 of our traffic comes through our home page according to our web stats, and an increasing amount of our traffic is coming not from standard web page links, but from blogs and discussion postings.

So, me learn web 2.0. Ugg.

Here’s the link:

“But My Neighbor Has a Cell Phone …Finally, a sensible way to measure poverty.” by Time Harford
http://www.slate.com/id/2195897/

This spring, we took this a step further in testing our our new Google-map based Repopulation Mapping System, but let the users define their own tasks. I had a twinge of guilt about not having formal tasks written down on index cards, but felt that we needed to let the neighborhood leaders who were testing the system show us what they’d do with the site. The information we gathered during testing resulted in several critical, concrete design improvements (though I still felt like we’d fallen short of a formal usability testing methodology).

I was relieved to find a label applied to this departure from structured tasks in the article by Mark Hurst, Asking customers for what you don’t already know. He talks about a “listening lab” where “the facilitator’s job is to invite the customer to demonstrate their own actual customer experience with the site. Rather than concocting an arbitrary set of tasks, the listening lab allows customers to use the site “for real,” as they would at home or work.”

We found that this listening lab approach combined with testing in the field, was a perfect fit for testing our new interactive map of New Orleans. It was perfect because every New Orleans neighborhood is different and has its own unique issues — ones we’d be hard pressed to create canned tasks for.

One neighborhood association president in NO East talked about a subdivision that had some subsidence issues, and she saw in the newspaper a lot of properties being sold to the Louisiana Land Trust (homeowners choosing options 2 and 3 in the Road Home program). She created her own task of zooming in to Oak Island to view how many Road Home applicants have chosen to sell to the state vs stay and rebuild. Her understanding of local conditions created a much better task than we would have ever created… and I loved hearing the story behind the statistics.

And as always, the “field” component of our testing was crucial in informing our design. And humbling. For example, our web stats show that only 5% of our visitors have 800 x 600 screen resolution, but 3 of our 5 testers were using that resolution and our map was only an inch and a half tall on their machines! These users are our core audience, and if they can’t use the system, then we’ve failed. Had they come into a lab to do the testing, we would have never been able to observe the way that they navigate the map and compensate for the small window size.

Next time we do usability testing, we’ll formalize this idea of “listening in the field” and not feel guilty about leaving the tasks on note cards behind!

The good news is that for some questions, like “how many nursing homes are in the New Orleans region?” you should be able to get “completeness” from an administrative source such as the state Dept of Social Services, since they license those facilities. That link is:

http://www.dss.state.la.us/departments/os/licensing/default.asp

If you “Search by License Types” and choose “Adult Residential” and then click the submit button directly below that search field, it’ll bring up a list.

But if you search the yellow pages, or Medicare’s “Nursing Home Compare” database, you get a similar, but different list:

http://www.medicare.gov/NHCompare/

I am assuming there are some subtleties of service provision in which some nursing homes are licensed by an entity other than the state. Or maybe the state’s database has a lag or has some reporting errors. Or maybe there are a good handful of nursing homes operating without licenses.

Some technology vendors might argue that all you need to do is “fuse” these databases together — but that would trample on what are likely some significant issues in the field (like, should you be including non-licensed nursing homes in a referral database??). Integrating data can’t fix data problems, rather it masks them. Not good.

Anyway, looks like for now there’s at least three or four data ponds to go fishing in if you want to know where the nursing homes are.

Why have a portal for data that just happens to have a geospatial component? Some data belongs on a map, some in a table, some in a paragraph as part of an analysis. The format the data is in is less relevant than what the data is about. I don’t call my bookshelf a “paper portal” and the fact that some content happens to be in a book doesn’t matter — what matters is the content in the books.

There are two perverse side-effects of a GIS portal: it ends up mapping things that shouldn’t be mapped, and missing things that are important.

1. Mapping things that shouldn’t be mapped: A GIS Portal rapidly descends into being a repository for data that doesn’t really have a geographic relevance. For example, let’s say you want to map social services. Some might be geographically relevant (where the food pantries are located and clients pick up their food baskets) but some are not (like the locations of the Meals on Wheels kitchen, which is not relevant because the meals are delivered to clients’ homes).
2. Missing things that are important: When you’re trying to understand the resources available to the community, if you’re only looking at resources that are mappable (like the location of walk-in mental health crisis centers), then you’re missing a huge piece of the solution (phone-based mental health crisis counseling).

Irrational Exuberance

GIS Portals emerged when the technology itself was novel and merely having a GIS Portal was considered a sign of success. (This reminds me of the early nineties when web sites just had to exist and be cool, not necessarily fulfill a real function.) I think we’re moving on… the next evolutionary step is GIS that serves a purpose, with the focus on information products, with well-defined users and tasks they will accomplish with the data. This is a lot harder to design, though, than a GIS Portal where you throw in all the data you’ve got and the kitchen sink and satisfy yourself with the use case of letting users “explore the data.”

The typical approach to creating data systems for such a wide audience is to 1) inventory all the data sets the department wants to publish 2) specify functionality for the query system (often based on ideas gathered in focus groups, or staff meetings), 3) build the system, 4) design the interface and solicit feedback from users on what they think of the system. Sometimes, two interfaces are designed (“easy” and “expert”), and subsequent user challenges in using the system are addressed with training workshops and “read me first” instructions. This approach is technology-centered.

User-centered design, in contrast, has developers 1) begin with a thorough analysis of segments of the audience (i.e., researchers, nonprofit grantwriters, and local government health departments) and what tasks they need to accomplish on the system, 2) choose data sets and methods for displaying the data to support the tasks users need to accomplish, 3) build low-fidelity prototypes (such as paper printouts, or “scotch-taped” mockups of the proposed interface design), and test with prospective users, 4) build the system, incorporating feedback from iterative testing. The result of a user-centered approach is a data system that allows users to focus on the information within it, rather than struggling with how to use the system itself.

Problem is, that when gov’t entities focus on the final packaging of data for a broad public, they lock up their data in clumsy interfaces — typically not really meeting the needs of the general public, and preventing access to the raw data for more data-savvy folks who would know how to analyze the data.

If you’re audience is everyone, then you’re probably actually meeting the needs of no one.