ECHO Blogging Central

Prof. Hacker’s Jason Jones and Ayelet Waldman’s Michael Chabon on faking it as a productivity tip.

The afternoon of September 24 was hectic. I called in to participate in a radio show in Seattle, then zoomed downtown for meetings, after which I headed home to cook for a dinner party. I had everything timed to the minute, and was just getting into the chopping zone when my partner yelled that I had a call. I ran in and picked up the phone, fully intending to quickly dispatch whoever was on the line and get back to my tight cooking schedule.

What followed, instead, was a 20 minute phone call that changed my day and has had a powerful impression on me since. The call was from Mercedes Martinez and Zachary Kent, the people behind an internet radio show called Dial-A-Stranger.

Dial-A-Stranger is what it sounds like. People sign up to be called by submitting a phone number to be added to a database. Other people submit questions they'd like to have answered by strangers. Mercedes and Zachary pick people randomly out of the database, call them, and ask a contributed question. They edit the conversations into radio shows, which are then made available as a podcast (you can listen to episode featuring me, #89: Museum Secrets, here).

But it's more complicated than that. I've known about Dial-A-Stranger for awhile, but I haven't written about it before because as a listener I don't find the show that compelling. The conversations are often long--20 minutes or more--and Mercedes and Zachary only get to the question at the end of a meandering conversation with the guest. As a listener, I get frustrated that the show isn't more tightly edited, and I wonder who really cares to hear the conversations Mercedes and Zachary have with perfect strangers.

Now that I have been a Dial-A-Stranger, my perspective on this has changed. I still get fidgety listening to the podcast, but now I see it as an artifact of a supremely conducted participatory project rather the sole product of the process. Dial-A-Stranger was one of the best participant experiences I've ever had. It improved my immediate mood and made me feel special in a lasting way. Mercedes and Zachary did all the work with no apparent effort, carrying the conversation in a friendly, positive, interested and interesting way. And they made me appreciate them as superb facilitators as a particular kind of participatory experience: conversation with strangers.

What made Mercedes and Zach such great conversationalists?

They really cared about me. I've written before about how, when designing questions for use with visitors, staff should make sure they genuinely care to hear the answer. Mercedes and Zachary don't even ask their own questions, and yet they demonstrated unbelievable interest in me and my experiences during our conversation. I even made some gaffes--for example, confusing the University of Texas natural history museum with the Utah natural history museum (the "UT" slipped me up)--but they took it in stride, continuing the conversation without embarrassing me. They made me feel comfortable enough to make some dumb jokes and brag a bit--things I'd probably be reticent to do with strangers in most situations.

They started with a good question. Mercedes and Zachary have a formula to the beginning of their calls. They call in the evening, announce themselves, and then ask, "how was your day?" This is a great question because it is comfortable and open-ended. Everyone has answer to this question, and in the context of a show like Dial-A-Stranger, few people give a one-word answer like "fine." They want to explain themselves, to assert some aspect of their identity (consciously or unconsciously) that then drives the conversation. When I answered their question with a response about work, we spent the rest of the call talking museums, but I suspect if I had talked about moving the woodpile, we would have just as easily continued on that vein.

They listened, responded, and shared. Mercedes and Zach aren't just interrogators; they also shared their own reflections and stories throughout our conversation. We never would have talked about taxidermy (and the basement I shared with dead animals at the Boston Museum of Science) if they hadn't started talking about their local natural history museum. They never steered the conversation in a direction that was jarring or expressed a disinterest in what I was saying; instead, they kept building on a shared experience, validating and querying and scheming, which made me feel like we were in cahoots together rather than having a typical interviewer/interviewee relationship. By the time they got to the actual question at the end of the conversation, I was ready to share personal stories with them and did so enthusiastically.


Of course, all of this greatness is still coupled by the problematic feeling that the product of the conversation--the podcast--is not (for me) a great audience experience. But now I wonder if I was too literal in seeing the only product as the stranger's stories. I've learned to listen in a more nuanced way and to appreciate the skill with which Mercedes and Zachary draw out their guests, who are after all perfect strangers. And there are other products as well: the database, the conversations, the questions and the people behind them. The podcast is take it or leave it, and there are probably people out there who love hearing the relationships Mercedes and Zach build with strangers in a short time over a phone line. I know I hear them differently now that I engaged in one, sort of like how you see art differently if you make it.

When I asked Zachary why they don't edit the shows more tightly to focus on the questions and answers, he explained that they sometimes do edited shows, or shows borne from conversations at live events, or shows that focus on voicemails received on their line. I listened to a couple of voicemail shows and found them more quirky but less satisfying in terms of their depth, and I can see why from Mercedes and Zachary's perspective it might be most valuable to engage in longer conversations with people. He commented that, "When we started this it was an experiment to see what would happen so we thought up a lot of ways that Dial A Stranger might work and we've been trying them. As the show grows and changes we grow and change how we do it and make different kinds of shows along the way."

And so I wonder--in which direction can and should Dial-A-Stranger grow? Should Mercedes and Zachary train others as hosts, to support more conversations and provide more people with transformative experiences as participants? Should they experiment audially with ways to produce an audience-facing podcast that better conveys that transformation? What would you do with this kind of project?

And even if you don't have an answer to that question, I encourage you to sign up with Mercedes and Zachary, be a stranger, and let us know what you think.

I’m delighted to announce the beginning of what I hope will be an exciting (and useful!) mini-project.

Museuminaday is a concept which Dan Zambonini and I have come up with to support our workshop “The Lightweight Museum” at the DISH conference in December.

Hopefully the name should do most of the work in explaining what museuminaday is about: we intend to build a museum website in 12 hours, start to finish, documenting the techniques we use and the things we discover along the way.

Most of the work will happen during a single day (2nd November 2009 – and we’ll be filming and live-blogging on that day) but we’re also documenting everything we do before then and taking time off our 12 hour deadline as we go. You can see our public Google Spreadsheet which outlines everything we’ve spent time and money on to-date.

We hope we’re going to succeed, but we’re more than ready to fail, too – either way we hope that we’ll bring something useful to the table.

You can read more about the project on the about page – or just follow us on Twitter at @museuminaday. Comments, suggestions, ideas – more than welcome!

Posted in museum Tagged: DISH, dish09, dish2009, miad, museuminaday, rapid development

This weekend I was at a workshop on Application Programming Interfaces for the Digital Humanities. See the philosophi.ca wiki conference report.

The workshop looked at the possibilities and issues around APIs for digital humanities resources. I think it is fair to say that lots of projects have been exposing APIs but they aren’t being used much. We need to encourage projects to develop mashups that take advantage of the APIs.

This workshop, more than any other I’ve been at was heavily twittered (#apiworkshop) which was interesting and annoying. At times people seemed to space out and not participate as they rushed to document what was happening or contribute some bon mot. I should admit that I am part of the problem – I posted a few and was writing my conference report live which was just as distracting. I guess we all have develop an etiquette for situations where you are not just part of an audience, but are expected to participate.

It’s difficult now to imagine how once, in a culture long ago, there were no cells or tissues, no molecules or receptors, no hormones, proteins or DNA. Just a body, with organs, sinuses, cavities, limbs, and fluids of different kinds.

This pre-cellular, pre-molecular body will be the object of discussion at a symposium titled ‘The Body on Display, from Renaissance to Enlightenment’ at Durham University, 6-7 July 2010:

At once an organ system, disciplinary target, metaphor, creation of God, cultural construction, ’self’ and receptacle for the soul, it is not surprising that the body has fallen under the attention of historians of art, gender, thought, medicine, theatre and costume, and of literary scholars, archaeologists and historical sociologists and philosophers. This symposium will look at the human and human-like body on, and as, display, between c.1400 and c.1800. We will explore the notion, and reality, of the exposure of the inner and outer human form, and the representational, visual and material cultures of the body. This was a formative (and even transformative) period for the visual and representational culture of human corporeality, witnessing the watersheds of Renaissance and Enlightenment, challenges to long-held understandings of the body and, allegedly, both the creation of the modern ’self’ and the eventual secularization of Western society.

And topics might include, e.g.:
-Dissection, the medical ‘gaze’ and medical illustration
-Corporeality and the flesh in the visual, written and performing arts
-The body in religious iconography, hagiography and religious
performance
-Gesture, kinesics and the expression of emotions
-Corporal punishment and bodily shaming
-Clothing, garments and cosmetics and their significance

300 word abstract to body.ondisplay@durham.ac.uk before 30 January 2010. Read more here: www.bodyondisplay.org.uk.

USING an inventive new method in which mice run through a virtual reality environment based on the video game Quake, researchers from Princeton University have made the first direct measurements of the cellular activity associated with spatial navigation. The method will allow for investigations of the neural circuitry underlying navigation, and  to a better understanding of how spatial information is encoded at the cellular level.

Read the rest of this post... | Read the comments on this post...

With great interest I have read this article published on HNN.us by Christine Kelly. Writing about the potential of Twitter in the context of history she describes three spheres of social engagement in the past: the two spheres of professional historians and institutions, where Twitter is used in collaboration and ...

Walne zebranie czołówki polskich historyków, które miało miejsce w dniach 16-19 września 2009 roku w Olsztynie w ramach XVIII Powszechnego Zjazdu historyków Polskich, stwarzało możliwość wszczęcia ważnych dyskusji. Moim zdaniem zdecydowanie znaleźć się wśród poruszanych tematów powinna ogólna debata nad kierunkami w których powinna podążać w najbliższych pięciu latach nauka ...

I am very pleased to be attending the Workshop on Application Programming Interfaces for the Digital Humanities sponsored by SSHRC and hosted by the amazing Bill Turkel in his role as a member of NiCHE.

Here are a few things I’m thinking about going into Day 2:

1. In talking about APIs, we’re necessarily talking about access and the political and cultural issues that surround access to cultural heritage materials. It’s one thing for a library (say) to make some data collection available and to allow you to browse, search, and display it in various ways. It’s another thing to allow other people to come along and create their own ways of browsing, searching, viewing (which is what API access is really about). I think we need to insist on the necessity of this form of access as essential to the future of digital work in the humanities and social sciences. At the same time, we need to be respectful of those who are understandably nervous about it. How do we articulate the benefits of this kind of access? How do we persuade content providers that this kind of access is good for the institutions that provide it, and not just for the people who take advantage of the new entry point?
2. There’s a movable wall when it comes to APIs. I heard a lot of people yesterday describing elaborate ideas about data mining with textual resources (or something similarly ambitious), but in every case, I noticed that the idea was predicated not on access to a series of data points, but on access to the entire dataset. This raises a fundamental question (for designers) on where you put the “wall” between the resource and the user. You could imagine an API that had a single function called “get_all()” Call that, and you can mirror the entire dataset and do what you like. You could also have an API with dozens of highly granular hooks that return nicely formatted data structures, and so forth. The former is undoubtedly the most flexible, but it’s also the hardest to work with (particularly if you’re a novice programmer). But again, it’s a kind of shifting wall. If it’s data mining you’re after, you could do all that mining back on the archive side and make the results available through the (highly granular) API. These aren’t mutually exclusive, of course; Flickr, for example, offers both kinds. Still, I think thinking about this helps to highlight some of the design challenges one encounters with APIs in general.
3. I think we need to think more carefully about “impedance mismatches” between data sources. There was a lot of talk yesterday about mashing this humanities resource to that humanities resource, but I think there were also some hand-waving assumptions (I was guilty as much as anyone) about the degree to which that data is tractable from an interoperability standpoint. Some of the most successful web service APIs are successful, I think, because the data is simple and easy to work with (lat/longs, METAR data, stats arranged as key-value pairs, etc.). Humanities resources are often quite a bit more complicated, and there’s far less agreement about how that data should be formatted. It’s true that the TEI (for example) provides a degree of metadata standardization, but it’s mostly silent about how the content itself should be formatted. That is, when you actually look at the content of the “tags” (whether it’s XML or something else entirely), you find that people are defining things at radically different levels of granularity and with different ordering schemes. I don’t want to declare that the sky is falling; I just want to point out that some of this might be quite a bit more difficult than it sounds. And it’s a tough problem, because defining complicated interoperability standards in this space really does, in my opinion, run against the spirit of the thing.

I’ve had a wonderful time at this gathering, which includes so many talented librarians, scholars, and hackers (many of whom manage to combine all three skill sets). I can’t help but think that great things will come of this.

Od 1 sierpnia w serwisie społecznościowym Facebook funkcjonowało dwóch niezwykłych użytkowników: Kostek Dwadzieściatrzy i Sosna Dwadzieściacztery. Co jakiś czas w ich profilach pojawiały się wpisy, układające się w ciągłą relację z... przebiegu Powstania Warszawskiego. Nie był to naukowy, beznamiętny przekaz, ale bardzo emocjonalna narracja, opisująca Powstanie z bardzo osobistej perspektywy. ...

The Great Museum WC — Maybe not the most important room in the museum, but among the most essential: Okay, you have GOT to check out that bathroom.

THINKING of and saying a word is something that most of us do effortlessly many times a day. This involves a number of steps - we must select the appropriate word, decide on the proper tense, and also pronounce it correctly. The neural computations underlying these tasks are highly complex, and whether the brain performs them all at the same time, or one after the other, has been a subject of debate.

This debate has now apparently been settled, by a team of American researchers who had the rare opportunity to investigate language processing in conscious epileptic patients undergoing surgery. In today's issue of the journal Science, the researchers report that the brain processes lexical, grammatical and phonological information in a well defined sequence that lasts less than half a second, and that a single language centre known as Broca's Area is involved in all these tasks.

Read the rest of this post... | Read the comments on this post...

Here’s a list of three questions one might overhear in a peer review panel for digital humanities funding, each of which can kill a project in its tracks:

• Haven’t X, Y, and Z already done this? We shouldn’t be supporting duplication of effort.
• Are all of the stakeholders on board? (Hat tip to @patrickgmj for this gem.)
• What about sustainability?

In their right place, each of these are valid criticisms. But they shouldn’t be levied reflexively. Sometimes X, Y, and Z’s project stinks, or nobody uses it, or their code is lousy. Sometimes stakeholders can’t see through the fog of current practice and imagine the possible fruits of innovation. Sometimes experimental projects can’t be sustained. Sometimes they fail altogether.

If we are going to advance a field as young as digital humanities, if we are going to encourage innovation, if we are going to lift the bar, we sometimes have to be ready to accept “I don’t know, this is an experiment” as a valid answer to the sustainability question in our grant guidelines. We are sometimes going to have to accept duplication of effort (aren’t we glad someone kept experimenting with email and the 1997 version of Hotmail wasn’t the first and last word in webmail?) And true innovation won’t always garner broad support among stakeholders, especially at the outset.

Duplication of effort, stakeholder buy in, and sustainability are all important issues, but they’re not all important. Innovation requires flexibility, an acceptance of risk, and a measure of trust. As Dorthea Salo said on Twitter, when considering sustainability, for example, we should be asking “‘how do we make this sustainable?’ rather than ‘kill it ‘cos we don’t know that it is.’” As Rachel Frick said in the same thread, in the case of experimental work we must accept that sustainability can “mean many things,” for example “document[ing] the risky action and results in an enduring way so that others may learn.”

Innovation makes some scary demands. Dorthea and Rachel present some thoughts on how to manage those demands with the other, legitimate demands of grant funding. We’re going to need some more creative thinking if we’re going to push the field forward.

Late update (10/16/09): Hugh Cayless at Scriptio Continua makes the very good, very practical point that “if you’re writing a proposal, assume these objections will be thrown at it, and do some prior thinking so you can spike them before they kill your innovative idea.” An ounce of prevention is worth a pound of cure … or something like that.

I performed my fist knee operation today. Not in real life though but on my pc. Videogames inspired by medical practises or diseases has been discussed on this blog before but I don’t think that this particular game has been mentioned. In the game one takes on the role of a surgeon (or a surgeon’s assistant, I’m a bit in the dark on that one) and I must admit that I found the game to be surprisingly unpleasant.

I guess that working at a place like Medical Museion one gets hardened by telling stories of how the medieval surgeons performed their work or how the cholera epidemic infected people in the middle of the 19th century. Nevertheless this game, where one gets to perform surgery on a knee, really struck me. One thing is the images of the opened knee but I believe that it’s really the sound on the game that gets to me. Especially the sound of the saw going through the knee is really disturbing. Urg!

I must admit that I found it rather educational and apparently my patient survived. To be quite honest I’m not sure that it’s possible to actually ever fail. The game also reminded me of an article I read recently (”Inscribing surgery in digital culture” by Jan Eric Olsén) in which he links computer gaming and virtual surgery:

“Future surgery may not require knowledge in handling the scalpel but rather familiarity with computers. It has also been suggested that surgeons who often play computer games sharpen their ability to coordinate the senses of vision and touch, when performing keyhole surgery (Satava ed 1998: 143-144)”  (in Årsskrift for Medicinsk Museion, vol. 3, 2006: 49)

That might be right, but I’m quite sure that the above-mentioned game does not train the necessary skills :) (For an online article about the link between surgery and computer gaming click here)

Let’s ask this: Just what do museum website users want?

Actually, before we do that, the biggest question is “who is our audience?”.

Wait. Before we do that, let’s assume that – what – 70-80% of museum website users want to find out some logistical stuff: “what’s on? how do I get there? how much is it?”. Let’s assume that this bit is solved with a page or two of dull but useful information. Let’s ignore the 70-80%. They’re boring. There’s only so much you can do with a map and some opening times, right?

Now let’s consider the other stuff – the content – the collections, the exhibition stories, the richness. Just who are these people, what do they want, and where do they come from?

Determining audiences for museum websites is a slippery game which generally involves phrases like “lifelong learners” (everyone) or “educators” (teachers, parents, children – oh wait, everyone) or just “everyone”.

I’m being slightly mean, and actually the definitions are a little bit better than that, but still there is an underlying tension which is something to do with deeper questions about success, publicity, depth of resources, marketing, integrity – and that horrible, horrible phrase which frequently does the rounds: dumbing down.

When a curator oversees a website, for instance, he or she often fights the dumbing down thing tooth and nail. Curators are about depth, about academic rigour and cleverness. Curators aren’t (often) about publicity, traffic, sound-bites and volume. This is fine, and museums should be about quality and richness and integrity. If it wasn’t for this, they wouldn’t be the respected institutions that they have become.

The problem is that museums online want (and increasingly need) to be mainstream, too. We see Flickr and Facebook and Google and viral marketing and Twitter and….[etc] and, frankly, we want some ‘o’ that. And the tension there becomes more intense. Can you build traffic and volume and virality online and still manage to “not be dumb”? Can these deep, rich, academically sound experiences also be mainstream? Is – getting to the crux of the question – a mainstream user shallow or deep?

One of the big, enduring discussions, for example, is about how Google provides search into museum collections. Museum people tend to twitch if you suggest they should focus on exposing their collections sites to SEO best principles and forget the in-house search (or even just stick their stuff on Wikipedia and forget the whole in-house piece altogether), because they say that Google doesn’t provide the granularity that is required. For some researchers – those who want to find out the year an object was invented or the country of origin, for example – this lack of granularity is indeed a problem. For many others – those who just want a picture of any old steam engine for their desktop or wherever – it isn’t.

Balancing this requirement / audience / success equation is in itself a game. The best solution (do both) is clearly the answer, but many institutions fail to realise this, tending to focus on arcane in-house terms and interfaces rather than trying to find ways of building SEO via common content entrance points like Google. It becomes a user interface question, yes, but it is also about much bigger-picture strategic issues about success.

What each museum needs to decide is what this success looks like. And if – as is usually the case – success is about museums becoming more used, more embedded in people’s lives, more human – then success is, frankly, about Google. There, I said it. Where else does anyone begin a search for – well, anything? Do we really think that people come to museums to begin their search? Really?

So success – in the case of Europeana, for example – seems to me to be about asking the question: “can I find Europeana stuff on Google?”, not “can I find Europeana stuff on Europeana?”. When I’m looking for information on Leopold Mozart, I’m not – ever – going to start my search on one of our individual museum sites or any of the aggregators, federators or whotsitators that have been developed, including Europeana. I’m going to Google. Firstly, because I clearly don’t know who knows stuff on Mozart’s father and I can’t go there if I don’t have that specialised bit of information yet (and Google (currently) provides the single best starting point for my query); but secondly, because Google is there as my homepage, a hook in my Chrome browser search bar and as a known entity in my consciousness. Why would I start my search looking at detail in a single book when I’ve got access to general information about the whole library?

This is grandmother / eggs for many people working in museums, but I’m not sure it is as obvious to the big projects we’ve seen emerging from the museum sector. For some of these projects, specialised audiences are their success, in which case local approaches do work better. But for the majority, success is increasingly about making enough SEO noise for more general audiences.

And is this “dumbing down”? Yes, I suspect it probably is.

Posted in museum Tagged: collections, europeana, google, search, success, viral, web2.0

"Odra" to ukazujący się od 1961 roku miesięcznik wydawany przez Bibliotekę Narodową i Ośrodek Kultury i Sztuki we Wrocławiu. W najnowszym (wrześniowym) numerze tego pisma znaleźć można kilka interesujących artykułów poświęconych pamięci II wojny światowej oraz roli historyków w budowaniu społecznej świadomości przeszłości. W rozmowie z historykiem prof. Włodzimierzem Suleją ...

Dan Brown Gets Smithsonian History Right and Wrong in "The Lost Symbol" — Smithsonian Magazine’s Around the Mall blog has a nice “fact or fiction” run down of claims made about the Institution by Dan Brown in his latest thriller, The Lost Symbol, which is set in Washington, DC.

Curator Now Online — Via @NancyProctor comes news that Curator: The Museum Journal has launched a new website. Unfortunately, it looks like only subscribers can access full text articles, but I love that the journal is using WordPress to manage the content.

The Tweeting University Administration: How Much is Too Much? — Inside Higher Ed is reporting that George Washington University administrators use Twitter more heavily than colleagues at other universities, with an average of 57.7 tweets per day. The entire study by UniversitiesAndColleges.org contains some potentially more interesting and more useful data, including rankings by number of followers and number of offical accounts. From a quick scan, my own university, George Mason, doesn’t seem to appear on any of the lists. I’m trying to decide whether that’s a good thing or not.

Harvard-Yenching to be Digitized — The Harvard College Library and the National Library of China have launched a project to digitize all 51,000 volumes in Harvard-Yenching Library’s rare book collection. The project will take six years, and apparently the results will be made available under open access terms.

Google Books Settlement: Sergey, Smoke — I’m a week or so late on this, but anyone who hasn’t done so already should read Sergey Brin’s response to critics of the Google Books settlement in the New York Times. Brin makes a good case for benefits the settlement will bring, but doesn’t directly address many of the more subtle criticisms of the deal, a point made effectively, if a little snarkily, in a Slate article entitled “Sergey Brin Blows Smoke Up Your Ass.”

I thought about titling this post, “Getting Seasick,” but I think the Dramamine is starting to kick in. But be forewarned – getting involved with Google Wave at this stage is not for the faint of heart. If you’re concerned about all of your familiar actions and methodologies being turned on their heads, might be wise to hang out at the shoreline for a bit, especially until some of the expected navigation tools have been sorted out. On the flip side, the fun thing about playing with alpha or beta software is to see how’s it broken and what can be done with it.

I received a Wave invite this morning and have promptly spent the morning and afternoon trying to wrap my head around it. Thankfully, because everyone is in the same boat (disclaimer: I’m sorry about the oceanic puns. I can’t help it), a search for help yields a lot of blog chatter, including listings for how-to waves and other tips and tricks. But right now, because Wave is sort of in hurricane mode, it’s chaotic and it’s not at all simple to figure out.

Just to back up a step, a Wave is essentially a live-action discussion group, not dissimilar to an IRC group. But unlike IRC, Waves are collaborative discussions, with the ability to reply to comments above and below, all comments being editable after the fact, and you can embed other content (videos, plugins, other discussions, images, etc) into the thread of the Wave. Think of a Wave as a hybrid of IRC, a wiki, a listserv, and a forum. In Waves with a lot of collaborators, there may be a number of people commenting and replying to threads, editing the body content, pulling in links to other waves, and embedding extensions for additional functionality. Oh, and when someone is typing, you can see that in real-time, typos and all. So be careful what you say; someone might be watching!

I know that a lot of folks use Google Docs for collaborative work on spreadsheets and documents, and, strangely enough, those tools were not brought into Wave from the outset. I wouldn’t be surprised if that is added soon, especially since they seem to dovetail rather nicely. But I could see a lot of benefits to “wrapping” a spreadsheet or other document with discussion threads. Oh, the discussion history can also be retrieved and viewed, which is helpful if someone changes a comment and affects the direction or meaning of the discussion.

As far as the implications for cultural heritage institutions go, I’m pretty excited. Here at Magnes, we’ve started using Google Docs and our wiki fairly extensively. Sure, we only have a staff of eleven, but using those tools for ongoing modification and discussion has been invaluable. Once people remember to use them and they become part of the workflow, they’re time-savers, and historical records of processes and methodologies. So to extrapolate from that, if we can use something like Wave to add real-time discussion to the equation, we can get a richer record of the conversation and more opportunities for issues to be addressed.

Something I’m envisioning is a Wave for material culture research. Say I post a picture of a piece of ceremonial art with some Malayalam inscription and invite scholars to opine on the work. The institution doesn’t necessarily have the experts on-hand to translate the inscription, and there might be some feature that is unusual that we can’t identify, but this may be a very proactive way to uncover historical details we might otherwise have never known about. Granted, posting a photo to a listserv or a forum might achieve the same intended result, but I think that because Waves are so very tightly-knit, one might have a better chance of those scholars finding your query.

That might also be a downside as well. Once you’ve made your Wave public, anyone can add to the discussion. There isn’t any privacy, and as it stands now, the opportunities for spammers are ripe. I’m not yet convinced of the pie-in-the-sky optimism Google has that its users won’t use the tool for evil. Most of my other criticisms I’m reserving for now, since I think many of them will be ironed out in subsequent updates.

If any of you readers are Wave users, I’ve set up a Wave specifically for cultural heritage institutions to discuss how we might use the software to further our goals: Museums, Archives, and Libraries. Please pop on by!

• Frequently Asked Questions – Very handy list of shortcuts, since nothing is really intuitive in Wave yet
• Google Wave Add-on for Firefox – Alerts you when a Wave you’re following has a new edit or reply.
• Wave Guide: Wave’s Greatest Hits – the best Wave I’ve found to date for learning some of the little nitpicky tricks.
• Figuring out your Wave’s ID – Sometimes when you’re editing a Wave, you’d like to embed the ID of another Wave into the body. This post shows you how to find the ID to input.
• How to Build a Public Wave – Yes, trying to make your Wave publicly available is a major PITA right now. Here’s how to do it.
• In a busy Wave, there may be a whole lot of new comments you want to read, but scrolling down isn’t the most effective way to locate the new replies (identified with a vertical green bar to the left of the user icon). Simply hit the space bar to get to the next reply.
• Embedding a Wave in your Wordpress blog – This is pretty cool. You can use Wordpress to display Waves in real-time. Note that the embedded Waves can only be seen by current users.
• To reply to a comment in a wave, Ctrl-doubleclick and hit Reply. Or look for the blue box underneath it when you mouse over the area, and click.
• OH GOD HOW DID THIS GET IN HERE I AM NOT GOOD WITH COMPUTERS – LOLWaves. It was bound to happen…

Share:

Over the past year, I've noticed a strange trend in the calls I receive about upcoming participatory museum projects: the majority of them are being planned for teen audiences. A large number of the collaborative projects of which I'm aware (in which staff partner with community members to co-develop exhibits or programs) are initiated with teens. Even the most traditional museums often manage educational programs in which teens develop their own exhibits, produce youth-focused museum events, or provide educational experiences for younger visitors. And while I enjoy working with youth and consuming their creations as a museum visitor, I'd like to call into question the idea that they are or should be the primary audience for participatory experiences.

Why are teens over-represented in participatory projects? I see four main reasons:

1. Most participatory experimentation in museums starts in educational departments, and many educators primarily engage (and are funded to work with) students. Teens are a known (and somewhat controllable) entity.
   
2. Teens are developmentally focused on social identity-building and may feel more compelled to share their voices and express themselves than others than other visitors.
   
3. Teens are perceived as more interested in technology-mediated experiences and more familiar with social technologies in particular than their adult counterparts.
   
4. Teens are perceived as an audience that is particularly disaffected and hard to reach, and institutions are continually seeking new techniques that might connect them to core content experiences.
   

The first of these reasons is practical. The other three are cultural, and I'm not sure how accurate they are. Teens are certainly not the only people who like to express themselves and engage socially through technology. There are plenty of people who don't feel compelled to visit museums, but teens' disinterest may be more immediately evident because droves of students are forced to visit museums on field trips (whereas adult non-visitors are invisible). The challenge of engaging disaffected visitors is not teen-specific, and the potential for participatory techniques to address this challenge need not be limited to this audience.

Here are four reasons I think that cultural institutions should look more broadly at potential audiences for participatory experiences:

1. While teens are heavy social media users, they may not be the right audience for content-focused social experiences. Teens more commonly use the Web to stay in touch with their pre-existing social groups than to join new communities based on content affinities or interests. As researcher Danah Boyd has pointed out, teens spend time on Facebook, MySpace, and other social networks because that's where their friends are. This means that teens are not necessarily more savvy or more interested than other groups in engaging in communities of practice around content experiences. Users active in online social environments based on social objects like Flickr (photography), Ravelry (knitting), and Wikipedia (information) often trend older. Presumably, cultural institutions are more interested in providing opportunities for people to participate with and around content than providing venues for pre-existing friend groups to hang out, and this suggests reaching out to a broader audience.
2. If your activity is compelling because it involves gimmicky new technology, it's not a good activity. In several instances, I've heard about new gadgets and handhelds that are targeted at teens because of their novelty. While some youth (and adults) may be seduced by sexy technology, is that really the reason you want people to engage with your content experiences? I'm working on one cellphone-based game project that was originally conceived as being focused towards teens because, the thinking goes, teens like using their cellphones. In the end, we've developed a program that uses phones in such a simple way that the client is now talking excitedly about how much fun seniors are going to have playing the game. Complex technology integration may appeal more to some audiences than others, but it's denigrating to suggest that teens will engage just because an experience involves something shiny that beeps.
   
3. Teens are already frequently engaged as active participants in museums, and while they are a good starting point, focusing on them may have less significant institutional returns than expanding to other audiences. I suspect that one reason teens are often a core audience is that museums are already comfortable providing participatory experiences to youth in the form of camps, internships, and classes. It's potentially easier and more in-line with standard institutional practice to add a new special kind of internship or camp that focuses on teens contributing or collaborating on production of new content under the guise of youth outreach. For example, the National Building Museum offers an excellent summer program called Investigating Where We Live (IWWL), in which thirty local teens work with museum staff for four weeks to create a temporary exhibition of photographs and creative writing about a neighborhood of D.C. The program is coordinated and directed by staff, who select the neighborhood for the season, provide photography and writing instruction, and generally shepherd the project to completion. The program operates like a camp that is co-led by the teens involved. While this program is wonderful, it's very enclosed within the "youth education outreach" activities of the museum, and doesn't necessarily push other staff members in design or curatorial to consider integrating community members into their exhibit development processes. Also, from the teen perspective, while IWWL is a unique and valuable experience, participants may not differentiate it from any other ways they engage with the museum. This means that it may have less impact on their perception of and relationship to the institution overall, as compared to the potential impact on audiences with whom there are no pre-existing collaborative relationships. Imagine if instead of working with teens at the museum, IWWL was conducted as a collaborative project with mixed-age residents of the neighborhoods to be exhibited. IWWL would undoubtably get more complicated (and potentially harder to fund), but it might connect the National Building Museum with a much broader community of locals who care deeply about their neighborhoods and have more varied prior relationships with the museum.
   
4. Teens are not the only people with stories to tell. Teens may be particularly drawn to self-expression, but that doesn't mean that their contributions are any better than those of others. Because of their comfort with expressive technologies, teens are low-hanging fruit when it comes to participatory projects, but again, the impact of participatory experiences on them (and on other museum audiences) may be lower than that on participants with less access or ability to share their stories, skills, and memories. I'd like to see more multi-generational participatory projects in which young people are employed as staff or volunteers to help older audiences contribute their own content. Museums are not in the business of giving anyone who wants one a soapbox. Cultural institutions should be deliberate about setting up opportunities for communities of interest to participate, whether those be artists or amateur astronomers, veterans or housekeepers, gardeners or genealogists. The more thoughtfully we design participatory platforms, the broader our opportunities to use them to work with the visitors and audiences who matter most to us.
   

What do you think? Is it a problem or a great starting point to focus on participatory experiences with teens?

In preparation for the upcoming API workshop, organized by Bill Turkel, I thought I’d try to assemble a few thoughts on APIs. This is the fruit of work on several text analysis projects, including TAPoR, HyperPo, Voyeur, BonPatron and MONK (I hesitate to associate ideas with specific people without their consent, but of course this is also the fruit of working with several talented people in digital humanities).

1. Use REST and keep it simple. The universal KISS principle is certainly valid for APIs: the simpler things are the more likely they’ll be properly understood and adopted. The TAPoR Portal supports both SOAP tools and REST tools, but REST tools have been far less of a headache (some of the problems related specificially to Ruby’s “SOAP”: library, but even beyond that, for our purposes REST tools provide everything we need with less hassle). Part of keeping the syntax of the API simple is to plan for a wide range of calls; this doesn’t mean that all the calls should be implemented and documented, but listing them at the beginning helps to define the purpose and scope of the tool and helps prevent overly complex syntax that’s usually the product of afterthought.
2. Document the APIs (preferably automatically). Documentation goes without saying (sometimes it even goes without doing). When tools get compared and evaluated, one of the main criteria is always the extent and quality of the documentation. Besides, good documentation usually avoids more support questions. Of course there may be cases where you want to keep some aspects of the API undocumented if they’re too much in flux: a documented API should be respected by both developer and user, even as the tool evolves. One of the best ways to ensure up-to-date documentation is to find a way of having tools document themselves (like JavaDocs). This is one reason why HyperPo used Cocoon and XForms in order to have self-documenting tools.
3. Provide XML and JSON output. Providing two forms of output is a bit contradictory to the KISS principle, but there are good reasons for providing both: 1) XML because it’s still a powerful interchange language and can be infinitely transformed with XSL; 2) JSON because results are usually easier and faster to work with for client-side Javascript libraries (not to mention less bandwidth because results are more compact). Part of a well-documented API is of course explaining the results format.
4. Provide paging functionality. It’s a pain when you really want 5 results but the tool gives you 5,000: it’s an unnecessary performance burden in terms of bandwidth, memory, and computation. There are rare exceptions, but most tools should provide paging funcionality to ensure they’re scalable (even if the paging doesn’t seem immediately useful). Things get trickier when you need to combine pageing and sorting or grouping, but that’s where clear API documentation helps.
5. Create a proxy to channel traffic. For many client-side web applications, having a proxy channel requests to other tools can help avoid some constraints imposed by cross-domain Javascript security. But even beyond that, proxies can serve a useful purpose as a centralized broker of communication with other tools – there are good chances that parts of proxy code can be reusable for different types of tool requests, even when direct requests to the tools are possible (for instance, caching results or handling connection errors). One of the main benefits that we’ve found from having a proxy layer goes beyond APIs: it decouples development schedules of the interface (client-side) group and the backend (server-side) group. For instance, it’s possible for the proxy to provide fake data to the interface until the backend is ready to provide real data – but the interface code is oblivious to the difference.
6. For rich client-side tools, create embeddable objects. We usually think of APIs as providing data-centric content that is transformed and presented to the user in a different format. However, there are some tools where the server-side and client-side components work together and it’s actually the bundled combination that’s desired. These are often called widgets or badges, and they provide stand-alone functionality (like an embedded YouTube video or a Twitter timeline). A text-analysis example of this is Voyeur panels, like on the Day of Digital Humanities. Again, because of cross-domain security constraints, it can be easiest to embed these panels in an IFRAME (though of course they won’t be allowed to interact with the rest of the page).
7. Coordinated redundancy of services would be nice. I’m talking here primarily about academic projects, not commercial services: our servers and services go down for a variety of reasons and there’s rarely staff available 24/7 to make sure things are restored immediately. Furthermore, we’re more likely in an academic context to deploy an experimental version of something that could inadvertantly break functionality required elsewhere. The problem is that if Project 1 depends on services from Project 2 but _Project 2 _ is unavailable for some time, Project 1 may be partly or completely compromised. Projects that want to do the right thing and integrate existing remote services instead of re-inventing every wheel or having local installations of every service (that individually need to be maintained) face a network challenge. One possibility (again that’s fairly specific to the academic context) is to have a mechanism for coordinating fail-over sites for certain services. This isn’t quite as easy as it sounds since you need to maintain and distribute (presumably again through an API) a list of current installations with versioning information included. One benefit, if really there’s collaboration between sites, is that you get a form of mirroring that can provide load-balancing as well as improve network latency by calling services that are closer to you. I don’t think we have any good examples of tools that are widely used by several digital humanities projects, but that’s not entirely the fault of the existing tools, it’s that we haven’t focused enough on APIs and distributed services….

Although HyperPo has many faults (not very scalable, not to mention the fact that its development has been superceded by Voyeur), it does provide a decent API. To see it in action, you can view the list of modular tools in the HyperPoets Gallery, click on one of the tools, scroll down to near the bottom of the page and click the API link, and submit some values (please don’t be a bully – use shorter texts:-). Some tools provide alternate output formats – you’ll find those in the options section if applicable. For instance:

• http://hyperpo.org/Document/?style=frequencies&uri=http://www.un.org/Overview/rights.html (show document in regular interface styling of frequencies)
• http://hyperpo.org/Document/xml/?tagMorph=true&uri=http://www.un.org/Overview/rights.html (show document as XML with part of speech tagging)
• http://hyperpo.org/Frequencies/csv/?uri=http://www.un.org/Overview/rights.html (show word frequencies as CSV)

Some similar calls are currently possible with Voyeur (http://voyeur.hermeneuti.ca/?input=http://www.un.org/Overview/rights.html), but there’s a long way to go yet…