Museums and online logins pt.2: making a better “how”

(or "It's a universal tribulation")
In Part 1, I posited that one reason for museums not to integrate registration and login with their sites must be the hassle for both parties (museum and user). So, what if it wasn't a hassle to give your users a registration facility and a bunch of tools that depend on it? What if it was easy technically and yielded lots of value because it was popular? In short, what if the business case was good (which is incidentally the essence of my perspective on sustainability: sustaining appropriate levels of resources by identifying and sustaining value). If the users liked it because the value to them was higher: the benefits of logged-in actions extended beyond a single museum and let you bring together all your "stuff" from countless museums and galleries? In Part 2 I’ll look at lowering the barrier, before moving on to boosting the rewards in Part 3. First, though, let’s quickly off-road to look at the context within which museums operate online.

A digression: the Modalities of Regulation (from The Digital Sustainability Foundation Course)
I find it difficult these days to think about investment without thinking about sustainability. This isn't just because sustainability should be on your mind when you build something new (doh!), but because the things that make something worth building are the same as those that make it worth your while to keep it going. Or they can be, but that's another blog post.

An organisation’s internal drivers are vital in the question of whether and how they go about "building" and "operating", but these values and imperatives are in constant negotiation with the environment within which they operate. Larry Lessig talks about this in terms of the regulation of behaviour i.e. external factors that affect decisions, amongst them the law, the market, social norms and "architecture", which amounts to the stuff you just have to live with (whether that be the law of gravity, the presence of a mountain in your path, or your inability to see through walls).

An interesting constraint in this discussion is the market, which relates both to the users we have in mind and the ecosystem of competitors, peers and solution providers we operate within (often enough a "competitor" is also a provider of a solution, according to how you come at them c.f. Google, Wikipedia, Flickr, and many more). It's immediately apparent that the market has enabled museums to achieve a lot of social stuff without having to do the tricky stuff themselves, and as importantly tap into a much larger audience as a result. Several brilliant examples of using Flickr make it the most notable case, for me. On the architectural side, OpenID (http://openid.net) is a liberating “constraint” with market-y aspects, being a technical framework that relies on the market for OpenID providers. OpenID hasn't yet seen a lot of museum usage, perhaps because it's a bit technical or again simply because the use case is still too weak for offering logged in sections at all. The Brooklyn Museum lets people use their Google IDs to login (they use this for their famous Posse, which is clearly a compelling use case) but it's not exactly a widespread practice.

Whenever thinking about a solving problem it makes sense to look at the environment, especially the market, and examine what solutions already exist, how they fail, and perhaps how they could be adopted or adapted. For now I'll just say that with Delicious, Google's SideWiki, Zotero and many other relatively generalist, site-agnostic, "wrap-around" tools we have some great foundations to build upon. They form an important aspect of “the market”, and in some cases also the architecture. Before trying to reproduce what they do we should ask the question of whether they fall short in significant ways. I would suggest that they do because, whilst their success is based upon their not requiring anything particular of the web resources they are used upon, there is not much scope for pushing crowd-sourced knowledge back to those resources.

Lower the barrier or De-hassle the users, de-hassle the techs
As a developer, if I were asked to create some functionality that needed people to register I know various ways I could go about it, but it’s not trivial and if you had to deploy it over multiple web apps it could be a bit of a nightmare for a hack like me. Most other museums are even more thinly resourced than my own in terms of developer capacity.

As a user, I’ve got enough logins, thank you, and I’d pause for thought before registering with the Louvre or the BM, let alone Colchester Castle Museum. Another password? Another profile to build and manage? And although I’m going to do much of the same stuff as on all the other museum websites I visit, no connection between them? How useful is a Facebook widget for a my favourite objects from single museum? How many such widgets will I add to my profile? (probably none because I don’t know of any right now, but perhaps that’s due to exactly this barrier: it’s not worthwhile for users nor for single museums to make single museum apps of this sort)

So I’m proposing a UK museum passport – let’s call it a MuPPort for now, so that we remember to change it – a universal(ish) digital login service, although perhaps with an off-line dimension. This would help to lower the barrier for both sides. It would probably be built around OpenID and, to make museum coders' lives easier, would come with a bunch of widgets and code snippets. There would be access level control for those parts of a museum’s site that needed to be restricted to a particular group. Users would benefit from feature profile management tools and from various value-added stuff we’ll look at in Part 3, much of which might not even need the museum to implement MuPPort on their site because it’s not about access control, it’s just about identifying the user and keeping their stuff tied to their identity.

Imagine a scenario where, as a user, you can go to a museum site that you've never visited before and log in using your Google ID, or whatever OpenID identity you have attached to your MuPPort. Before going any further, you decide to visit the MuPPort site and check out your passport master account, where you see individual accounts for three museums you had logged into on previously, together with the stub of an account for the one you just went to. You customise your profile for the new museum, then when you go and contribute to their thimble-lovers’ forum MuPPort will ensure that the right avatar and username show up and are linked through to your Facebook page and blog.

So logging in could be made easier for everyone, but how about the more compelling case for users? Well that's where the fun starts, because whilst it could simply be a central sign-in system that then relies on individual museum websites to take care of all of the real action, for many functions it would make a lot more sense to run them centrally and gain from the pooled content as a result.

Other posts in this series:

• Museums and online logins: the preamble
• Museums and online logins pt.1: who’s doing what, where and why
• Museums and online logins pt.3: making a better “why” (with a bit of how)