Web 2.0 teaches us to think in terms of remixable web services that can join people together on the fly to create collective intelligences. Such groups can readily solve problems that are well beyond the scope or capabilities of any particular individual, and thus will have important ramifications for future research. One of the key opportunities for digital humanists is to find ways to harness this power in our collaborative work.
Here I will lay out a few principles and ideas for such an infrastructure; as always, I'd be grateful for any feedback.
1. Open access and open source. The principle of open access is to make research results freely available to everyone. Open access research reaches a greater audience than gated research and has more impact. Errors are more readily caught. Copies are more likely to be archived. Social inequities are lessened. The principle of open source is to make software and code freely available. New tools can be built on the work of others, code is maintained indefinitely, and, again, errors are more readily caught.
2. APIs. At a low-level, the creation of application program interfaces allows content providers to share information in such a way that it can easily be reused. It also becomes much easier for tool makers to integrate different sources of information as necessary, or as they become available. For example, once Google provides a web service that maps things, and OCLC provides a web service that gives the location of library books, it is quite easy to create a "mashup" that plots the location of books on a map. Any serious infrastructure for the digital humanities will require the low-level cooperation of researchers and repositories of cultural heritage. One mechanism by which this may be accomplished is the creation and distribution of open source APIs for catalog software. Then, when a library, archive or museum makes their catalog available online to human searchers, they will also be making it available to mashup developers.
3. Information dashboards. Individual researchers will need an interface that shows them the state of the field at a glance and facilitates communication with colleagues. Presumably they will have an account with a customizable homepage that supports RSS feed remixing, collections of shared and private documents, access to text, audio and video communications channels, and other tools. The system will flag information that they haven't seen yet. New widgets can be added to support tasks like information trapping, customized search, data mining, and visualization.
4. Browser-based tools. For work with online sources, researchers will also make use of tools that are built into the browser, like Zotero. At the moment, Zotero allows you to automatically scrape bibliographic information from a webpage that you are viewing into a citation database. Future releases will allow you to do things like synchronize your own database with a server, share citations with colleagues, or provide an RSS feed of your recently tagged items. By making the server-side infrastructure compatible with Zotero, both tools will become more powerful.
Tags: application program interface | browser | computer supported collaborative work | data mining | digital history | information dashboard | mashups | open access | open source | zotero
Friday, March 30, 2007
Sunday, March 18, 2007
Phidgets: Introduction
Around 2001, University of Calgary computer scientists Saul Greenberg and his student Chester Fitchett found that their efforts to create new interactive media spaces were impeded by a "quagmire of tediousness." Rather than spending their time designing the kinds of interactions that they were interested in, they had to focus on the disparate elements that made up their demonstrations, things like electrical circuits, components, low-level programming, wiring, and so on. Graphical user interfaces already had software components called "widgets." These are reusable elements like windows, radio buttons, pull-down menus and check boxes. Once one person has figured out how to implement a widget, other people can add that widget to their interface with much less effort. Wouldn't it be great, Greenberg and Fitchett asked, if there were such a thing as physical widgets? Thus phidgets were born.
You can now buy reusable physical components to measure light, sound, temperature, pH, vibration, force, human touch and motion and a host of other things in the real world. You can drive servo motors and interact with radio frequency ID chips (RFIDs). There are two- and three-axis accelerometers (the same kind of device used in the remote of the new Nintendo Wii). These phidgets are easily combined and recombined because, in the words of Greenberg and Fitchett, "they hide implementation and construction details while exposing functionality through a well-defined API." In other words, you don't have to know how the magnetic sensor works at a physical or electrical level, you just need to know that if you plug it in, it will return a value that represents the strength of nearby magnetic fields.
I've recently gotten a large collection of phidgets to use for both research (more about that later) and for public and digital history student projects. Eventually our students will be able to design and implement things like interactive exhibits and history appliances. In the meantime, however, I have to make sure that I know how they work and that the lower-level scaffolding is in place. Phidgets don't come with Python support right now, so I've had to use ctypes to dig into the dynamically linked C libraries. I know I'm not the only pythonista who wants to hack phidgets right now, so for the benefit of others, here are some partially implemented wrappers for the 8/8/8 interface kit and the servo 4-motor kit. Comments and improvements are always welcome, of course.
Tags: hacking | interaction design | phidgets | python
You can now buy reusable physical components to measure light, sound, temperature, pH, vibration, force, human touch and motion and a host of other things in the real world. You can drive servo motors and interact with radio frequency ID chips (RFIDs). There are two- and three-axis accelerometers (the same kind of device used in the remote of the new Nintendo Wii). These phidgets are easily combined and recombined because, in the words of Greenberg and Fitchett, "they hide implementation and construction details while exposing functionality through a well-defined API." In other words, you don't have to know how the magnetic sensor works at a physical or electrical level, you just need to know that if you plug it in, it will return a value that represents the strength of nearby magnetic fields.
I've recently gotten a large collection of phidgets to use for both research (more about that later) and for public and digital history student projects. Eventually our students will be able to design and implement things like interactive exhibits and history appliances. In the meantime, however, I have to make sure that I know how they work and that the lower-level scaffolding is in place. Phidgets don't come with Python support right now, so I've had to use ctypes to dig into the dynamically linked C libraries. I know I'm not the only pythonista who wants to hack phidgets right now, so for the benefit of others, here are some partially implemented wrappers for the 8/8/8 interface kit and the servo 4-motor kit. Comments and improvements are always welcome, of course.
Tags: hacking | interaction design | phidgets | python
Saturday, March 17, 2007
Idioms
Part of learning how to program is learning a set of idioms, conventional ways of solving recurring problems. At first you have to think about these explicitly, but over time they become second nature, part of the way you see the world and act in it.
For example, suppose you want to create a toggle, a switch that goes to its opposite value when you press it. If it is on, it should turn off, and if it is off, it should turn on. (And by convention, let's assume On = True = 1 and Off = False = 0.) Many beginning programmers write something like this: IF SWITCH IS 1 THEN SET SWITCH TO 0 ELSE SET SWITCH TO 1. There is nothing wrong with this code; it is easy to understand and works fine. More experienced programmers have learned (or discovered for themselves) that they can say SET SWITCH TO 1-SWITCH instead. So if the value of the switch is 0, then 1-0=1 and if the value of the switch is 1, then 1-1=0. Same behavior, different idiom.
In fact, the idea of a toggle is fundamental enough that it recurs across domains. In electronics, for example, there is a well-known circuit called the flip-flop. It can be implemented in different ways (i.e., with different idioms) but all flip-flops can store a single bit, a single On or Off value. Miniaturized and in bulk, these tiny toggles serve as memory for computers.
In graphical user interfaces, the well-known check box is a toggle. If you take apart retractable ballpoint pens, you will find a number of different mechanical idioms for implementing two states for the nib: In and Out. Although we don't often think about retractable pens in these terms, each has at least a single bit of memory. If you dance the foxtrot, a series of left turns can make you and your partner toggle forwards and back. The same effect can be achieved in other styles of dance with other idioms.
The idea of a toggle becomes part of a designer's toolkit, regardless of the expressive medium he or she is working in: circuitry, software, human interaction, mechanics, dance. As computing becomes pervasive, digital historians will need to find and master the idioms that best help them convey a sense of the past to their different audiences.
Tags: bits | interaction design | pedagogy | programming | public history
For example, suppose you want to create a toggle, a switch that goes to its opposite value when you press it. If it is on, it should turn off, and if it is off, it should turn on. (And by convention, let's assume On = True = 1 and Off = False = 0.) Many beginning programmers write something like this: IF SWITCH IS 1 THEN SET SWITCH TO 0 ELSE SET SWITCH TO 1. There is nothing wrong with this code; it is easy to understand and works fine. More experienced programmers have learned (or discovered for themselves) that they can say SET SWITCH TO 1-SWITCH instead. So if the value of the switch is 0, then 1-0=1 and if the value of the switch is 1, then 1-1=0. Same behavior, different idiom.
In fact, the idea of a toggle is fundamental enough that it recurs across domains. In electronics, for example, there is a well-known circuit called the flip-flop. It can be implemented in different ways (i.e., with different idioms) but all flip-flops can store a single bit, a single On or Off value. Miniaturized and in bulk, these tiny toggles serve as memory for computers.
In graphical user interfaces, the well-known check box is a toggle. If you take apart retractable ballpoint pens, you will find a number of different mechanical idioms for implementing two states for the nib: In and Out. Although we don't often think about retractable pens in these terms, each has at least a single bit of memory. If you dance the foxtrot, a series of left turns can make you and your partner toggle forwards and back. The same effect can be achieved in other styles of dance with other idioms.
The idea of a toggle becomes part of a designer's toolkit, regardless of the expressive medium he or she is working in: circuitry, software, human interaction, mechanics, dance. As computing becomes pervasive, digital historians will need to find and master the idioms that best help them convey a sense of the past to their different audiences.
Tags: bits | interaction design | pedagogy | programming | public history
Thursday, March 15, 2007
How To: Do Simple Visualizations
One of the hats that I wear requires me to think strategically about the ways that Western's history department and public history program are positioned on the web. I spend a certain amount of time studying other departments and programs: who have they hired recently? what grants did they apply for and receive? where and what are they publishing? where do their students end up? what kind of web traffic do they have? which parts of their website are most dynamic? how are they positioned in search engine results?
On a larger scale, the efforts of any particular department or program are made against the overall output of their university. In Life Style, Bruce Mau writes that "The exercise of producing identity is all about giving environmental noise a defined pattern." So if we think of a departmental identity as a pattern, we can think of the university as providing the environmental noise (or the carrier wave, if you prefer) that is being modulated.
The point of visualization is to use your eyes to find interesting patterns in data that you might otherwise miss. IBM's Many Eyes web service makes it easy to do simple visualizations without any programming. For example, in order to assess the relative positioning of Canadian universities, I started by gathering reputation data from Macleans magazine. Universities, like other institutions, tend to be circumspect about providing data that their competitors could use against them. Nevertheless, I was able to collect information about unique US visitors to Canadian university websites using Compete's Snapshot tool. Uploaded to Many Eyes, these data are easily plotted against one another as a scatterplot. You can hover over a particular datum with the mouse cursor to learn more about that point.
Overall, the graph suggests that the universities that have a higher reputation (at least according to Macleans) also tend to receive more US visitors to their websites. The graph also shows that highly ranked Francophone universities like Sherbrooke tend to generate very low US traffic. (As we say in English, "quel surprise!" Dan Cohen recently argued that it's pretty silly to use visualization to discover that Jesus is a big deal in the New Testament.)
We would expect big universities like Toronto or York to generate a much larger web presence than tiny ones like Cape Breton. So we really should try to take the size of the institution into account somehow. I added 2005 enrollment data from the Association of Universities and Colleges of Canada, and divided the number of website visitors by the number of students.
This lets us see that something interesting is happening in a few places, notably at the University of Victoria and Acadia. Both schools have far more US website visitors than we would expect given the size of the institution. UVic is home to the wonderful Great Unsolved Mysteries in Canadian History site, and to a vibrant humanities computing group. Web-savvy may run in the blood there. Acadia's front page provides access to school news via YouTube.
Tags: visualization
On a larger scale, the efforts of any particular department or program are made against the overall output of their university. In Life Style, Bruce Mau writes that "The exercise of producing identity is all about giving environmental noise a defined pattern." So if we think of a departmental identity as a pattern, we can think of the university as providing the environmental noise (or the carrier wave, if you prefer) that is being modulated.
The point of visualization is to use your eyes to find interesting patterns in data that you might otherwise miss. IBM's Many Eyes web service makes it easy to do simple visualizations without any programming. For example, in order to assess the relative positioning of Canadian universities, I started by gathering reputation data from Macleans magazine. Universities, like other institutions, tend to be circumspect about providing data that their competitors could use against them. Nevertheless, I was able to collect information about unique US visitors to Canadian university websites using Compete's Snapshot tool. Uploaded to Many Eyes, these data are easily plotted against one another as a scatterplot. You can hover over a particular datum with the mouse cursor to learn more about that point.
Overall, the graph suggests that the universities that have a higher reputation (at least according to Macleans) also tend to receive more US visitors to their websites. The graph also shows that highly ranked Francophone universities like Sherbrooke tend to generate very low US traffic. (As we say in English, "quel surprise!" Dan Cohen recently argued that it's pretty silly to use visualization to discover that Jesus is a big deal in the New Testament.)
We would expect big universities like Toronto or York to generate a much larger web presence than tiny ones like Cape Breton. So we really should try to take the size of the institution into account somehow. I added 2005 enrollment data from the Association of Universities and Colleges of Canada, and divided the number of website visitors by the number of students.
This lets us see that something interesting is happening in a few places, notably at the University of Victoria and Acadia. Both schools have far more US website visitors than we would expect given the size of the institution. UVic is home to the wonderful Great Unsolved Mysteries in Canadian History site, and to a vibrant humanities computing group. Web-savvy may run in the blood there. Acadia's front page provides access to school news via YouTube.
Tags: visualization
Monday, March 12, 2007
Coming Soon: History Appliances
Imagine wandering into your living room after a day of work. You sit down in your chair and turn a dial to 1973. The stereo adjusts automatically, streaming Bob Marley, Elton John, Stevie Wonder and Jim Croce. LCD panels hanging on the wall switch to display Roberto Matta's Jazz Bande and Elizabeth Murray's Wave Painting. If you check your TV listings, you'll find Mean Streets, Paper Moon, American Graffiti, The Sting, Last Tango in Paris ... even Are You Being Served? In your newspaper you find stories about the cease-fire in Vietnam, about Watergate, about Skylab, about worldwide recession and OPEC and hostilities in the Middle East. If you want to read a novel instead, you might try Gravity's Rainbow or Breakfast of Champions.
With a little hacking, most of this scenario could be easily accomplished today. The dial, for example, could be implemented with a Phidgets circular touch sensor. Once you set the date, your computer could respond by switching your media player to a particular playlist, sending images to the picture frames, and feeding a stream of news from the Google News Archive to your E Ink reader. Both the Pynchon and Vonnegut novels already exist in digital form. It's only a matter of time until you can download them for a fee or print them on demand. As TV moves online, it will also become easy to filter offerings according to user-determined criteria. In short, access to the infinite archive makes it easy to immerse yourself in sources from a particular milieu.
Public historians will be able to find new roles designing historically accurate and interesting experiences for consumers, selecting from the welter of sources across media, combining and interpreting them. We tend to think of historical production in terms of writing books, but there will be many more "machines to think with." The most subtle will shape our historical consciousness by working in the periphery.
Tags: ambience | historical consciousness | interaction design | pervasive computing | phidgets
With a little hacking, most of this scenario could be easily accomplished today. The dial, for example, could be implemented with a Phidgets circular touch sensor. Once you set the date, your computer could respond by switching your media player to a particular playlist, sending images to the picture frames, and feeding a stream of news from the Google News Archive to your E Ink reader. Both the Pynchon and Vonnegut novels already exist in digital form. It's only a matter of time until you can download them for a fee or print them on demand. As TV moves online, it will also become easy to filter offerings according to user-determined criteria. In short, access to the infinite archive makes it easy to immerse yourself in sources from a particular milieu.
Public historians will be able to find new roles designing historically accurate and interesting experiences for consumers, selecting from the welter of sources across media, combining and interpreting them. We tend to think of historical production in terms of writing books, but there will be many more "machines to think with." The most subtle will shape our historical consciousness by working in the periphery.
Tags: ambience | historical consciousness | interaction design | pervasive computing | phidgets
Tuesday, March 06, 2007
Design for a Kiosk in a Cabinet
Last year the Western Social Science building was renovated to include shallow glass-fronted display cabinets for each department. A small group of my colleagues gathered in front of ours to discuss how best to portray the department to students and visitors. Some thought that using the cabinet to display a collection of faculty-authored monographs would be boring ... which is funny, because writing such monographs is crucial for promotion and tenure in our department. Anyway, the general consensus was that it would be nice to have something fun, something animated, maybe even interactive.
The cabinet poses two main design constraints. The first is that it is shallow, so there is room to fit a tablet computer, but not a laptop or desktop. It would also be difficult to fit in an LCD projector unless you wanted to do something catoptric. The second constraint is that there is an air gap between the user and the display. So they can't touch anything, unlike a regular kiosk. Interactions have to be mediated by photons, or radio waves, or sound. The cabinet is in a busy hallway near people's offices, so sound could get really irritating.
I recently read Analog In, Digital Out by the interaction designer Brendan Dawes. He's a big fan of using webcams in his designs, and I got to thinking that a camera would be one way to bridge the gap. It would also mean that the user's own image has to become part of the design, but we can use that. Since this will be a public history project, one idea that we might try to convey is situating the user in the flow of time. By themselves, glass display cases superimpose a ghostly image of the viewer onto the contents of the case, so we will really be doubling this effect. (For more on display cases, see Martin Roberts, "Mutations of the Spectacle: Vitrines, Arcades, Mannequins," French Cultural Studies 2 (1991): 211-249.)
I also like the idea of working with flows, something I've been thinking a lot about lately, whether in the form of RSS feeds, perceptual experiences of place, or lines of flight. So we're aiming for a kiosk design that incorporates the user's image, uses a webcam for interaction, and conveys historical flow in some way.
Here's what I came up with. In the cabinet there's a tablet computer with a webcam facing the user. A series of historical images flows past in chronological order, partially transparent and projected over the user's image. When they reach up to "touch" one of the images, the flow stops and that image is displayed in detail. They're not really touching anything, of course. The camera detects the motion of their hand in the air, and they see themselves touching something on the screen. Here are some screen shots from my demo:
You can download the Python source here. For my demo I used a lovely series of lantern slides from the McCord Museum. Although the webcam motion detector interface works, I didn't implement the flow part because in an actual installation I would want to use the wireless capabilities of the tablet to tap into an RSS feed of images. That would require a little more programming.
About this post. A couple of months ago I was tagged with a meme and passed it on to Brett Holman, among others, who responded by tagging me with a different meme: the Thinking Blogger award. Under the original terms of the award, I'm supposed to nominate five blogs which make me think. Instead, I decided to use five blog posts / webpages to inspire a design and teach myself how to do something new.
Tags: flows | hacking | historical photographs | interaction design | public history | Python | webcams
The cabinet poses two main design constraints. The first is that it is shallow, so there is room to fit a tablet computer, but not a laptop or desktop. It would also be difficult to fit in an LCD projector unless you wanted to do something catoptric. The second constraint is that there is an air gap between the user and the display. So they can't touch anything, unlike a regular kiosk. Interactions have to be mediated by photons, or radio waves, or sound. The cabinet is in a busy hallway near people's offices, so sound could get really irritating.
I recently read Analog In, Digital Out by the interaction designer Brendan Dawes. He's a big fan of using webcams in his designs, and I got to thinking that a camera would be one way to bridge the gap. It would also mean that the user's own image has to become part of the design, but we can use that. Since this will be a public history project, one idea that we might try to convey is situating the user in the flow of time. By themselves, glass display cases superimpose a ghostly image of the viewer onto the contents of the case, so we will really be doubling this effect. (For more on display cases, see Martin Roberts, "Mutations of the Spectacle: Vitrines, Arcades, Mannequins," French Cultural Studies 2 (1991): 211-249.)
I also like the idea of working with flows, something I've been thinking a lot about lately, whether in the form of RSS feeds, perceptual experiences of place, or lines of flight. So we're aiming for a kiosk design that incorporates the user's image, uses a webcam for interaction, and conveys historical flow in some way.
Here's what I came up with. In the cabinet there's a tablet computer with a webcam facing the user. A series of historical images flows past in chronological order, partially transparent and projected over the user's image. When they reach up to "touch" one of the images, the flow stops and that image is displayed in detail. They're not really touching anything, of course. The camera detects the motion of their hand in the air, and they see themselves touching something on the screen. Here are some screen shots from my demo:
You can download the Python source here. For my demo I used a lovely series of lantern slides from the McCord Museum. Although the webcam motion detector interface works, I didn't implement the flow part because in an actual installation I would want to use the wireless capabilities of the tablet to tap into an RSS feed of images. That would require a little more programming.
About this post. A couple of months ago I was tagged with a meme and passed it on to Brett Holman, among others, who responded by tagging me with a different meme: the Thinking Blogger award. Under the original terms of the award, I'm supposed to nominate five blogs which make me think. Instead, I decided to use five blog posts / webpages to inspire a design and teach myself how to do something new.
- My former digital history student and all-around humble guy Jeremy Sandor suggested that public history should be play.
- Brendan Dawes showed me how to use Play-Doh as an interface.
- Guyon Moree put the pieces together in Python.
- Paula Petrik and Jeremy Boggs continue to emphasize the role of design in digital history.
- And the ThirdView Rephotographs suggest a future direction for designs like this one.
Tags: flows | hacking | historical photographs | interaction design | public history | Python | webcams
Subscribe to:
Posts (Atom)
