Though I started in web design early in 1994, and had some early successes with a Webby nomination in 1999 and an article published at A List Apart, babies and hurricanes had frozen me in 1.0-land.

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.

This Slate.com article has a nice history of the concept of the “poverty line” and references a new unofficial poverty line proposed by the Joseph Rowntree Foundation, which set the standard “by focus groups working out what was and was not necessary ‘to participate in society.’ The results are frugal—there is a budget of £40 ($80) every two years to buy a suit, for instance—but they were always bound to be controversial. The list of essentials includes a self-catering vacation, a cell phone, and enough booze to get drunk twice a month.”

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/

Back in 2003 we adapted techniques used in formal, lab-based usability testing to the “field” — where we’d watch users accomplish tasks on their own computers wherever they normally do their work (See Usability testing of Community Data & Mapping Systems).

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!

It’s that time of year for writing grant proposals, so we’ve been getting lots of requests to know who’s offering “similar services in the same target area.” That’s sort of a tough question to answer right now — our region’s 2-1-1 database is in the process of being liberated to an easy-to-use database software that will soon allow access to the searchable database of community resources. But, that won’t be ready for a month or two. And, resource data designed for information & referral (like a 2-1-1 database) is comprehensive but not complete, so, though its a good starting place, you can’t count on it to capture all of the players in a given field and whether there’s a gap in services. If you want to get completeness in a field (say, have a listing of all the nursing home) that’s beyond the current best practices in maintaining a 2-1-1 community resource database.

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.

We spent the first part of the week with mapping sherpa James Fee, who filled our brains with much to ponder. One a-ha that emerged for me out of our discussions was that the days of the web-based “Mapping Portal” are numbered.

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

I’m writing a paper on evaluating state government web-based data query systems and am beginning to wonder if a single web site designed for “the general public” ranging from scientists to curious lay-citizens can ever really be user-centered.

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.