Libby Hemphill research and posts on social media, collaboration, and related technologies

30Nov/070

Solving the service provider problem

During the CDI Workshop at Rennselaer in September, one of the computer scientists complained that when he collaborates with social scientists, he feels like they view him as a service provider rather than a collaborator. It sounded like he had some experience with a social scientist who's approach was to say, "Go build this thing so I can deploy it and study the deployment." In my short talk, I mentioned that social scientists in interdisciplinary collaborations are not service providers either. I've worked with computer scientists before who approach our work with the attitude that I will "fix the social stuff", whatever that means. So it seems that we have a problem. Computer scientists and social scientists recognize that if we worked together, we might find answers to interesting problems. Here I'm thinking about expertise finding, knowledge sharing, and distributed collaboration as problems that might benefit from such a collaboration. How can we work together without having either side feel like the other side is using them for a service rather than as a colleague?

Man, I wish I had an answer. Why is this bothering me today? Well, I'm trying to set up CoSign so that the new version of the KNOW SI wiki will allow UM users to login using their existing UM login credentials. This means I need to dig into the innards of the Apache server we're running. That sounds almost CS-y to me. Probably not to a CS person though. Anyway, CoSign and the resulting permissions options represent one of the socio-technical problems that I think could benefit from both computer science and social science. What's the best way to set up permissions on our school wiki? What technical infrastructure (e.g. .htaccess, CoSign, MediaWiki extensions) is necessary to supporting the kind of social behavior (e.g. TBD, which makes the technical questions that much harder) in which people want to engage on this wiki? Those are the questions I'll be wrestling with this weekend and probably for a while.

26Nov/070

Explaining myself to technology product groups

I have a meeting tomorrow with a leader of a product group at a Silicon Valley-based household name. On the itinerary, I'm described as "a PhD student who has worked on use of social media and etc. by science and engineering research groups". I've been asked to come up with a 3-5 minute introduction for myself. Here's my rough draft:

Your itinerary shows that I’ve worked on social media use by science and engineering communities. Another way to think about what I do is to call it social computing for existing (or emerging) social systems. My work is with distributed teams, and it’s different from much of the existing ecommunity work because the teams I study know each other. They may not be close socially or geographically, but they are familiar with each other and have almost always met face-to-face. They’re working together toward some goal that requires them to collaborate (e.g. getting a new building technology to market) or benefits greatly from collaboration (e.g. getting through grad school). They span a variety of distributions – whether their offices are states or continents apart, whether their disciplines seem distant, and how they span the spectrum from novice to expert.

Two of the projects I work with now that explore the use of social computing by existing communities are the CI TEAM grant and KNOW SI. In the CI TEAM grant we explore how engineers developing and testing a new building material work together across institutional and national boundaries to establish standards for testing the material and for training new users of the material. The CI TEAM group uses a content management system with features somewhat like Yahoo! Groups to share their data and discuss it. CI TEAM builds on earlier large-scale scientific collaborations that used the same tools but had very different motivations and goals for collaboration. What I’ve found most interesting in these scientific research collaboration projects is how unlikely users are to adopt a technology specifically for their projects. Users love email and Excel but ignore wikis, archived email lists, and file repositories.

KNOW SI is a PhD student-led project with many goals. Mine is to use KNOW SI as a way to understand how people in organizations, such as schools, use available technologies to share information with one another. In KNOW SI, I helped set up an iterative series of wikis for use by the community, and we’re analyzing that use and preparing the next generation wiki. What’s surprised me here is how willing various groups are to use the same underlying technology. For example, doctoral students are all over the wiki. We’re our own audience though. The Research and Career Services offices have different audiences – master’s students and the public for two – but are exploring the same technology.

Together these projects provide a variety of settings for me to explore information and technology use in different kinds of collaborations.

26Nov/070

New (to me) and Useful: Remember the Milk

I, like many of you, have a lot to do. Not all of it needs to be done right now, and not every item on the list is mission-critical. I often find that I have a small amount of time to work - maybe an hour or two - before something like a meeting comes up. I try to keep a To Do list up to date so that I can make the most of those short bits of time - I'll know what I need to work on and can probably find something on the list that takes the amount of time I have available. The trouble is, I haven't found a good way to keep track of that To Do list. I've tried iCal, my email Inbox, a couple of To Do widgets for Google Homepage, paper, and Jott. None of them allowed me to keep track of the relative importance and order of tasks - at least not at the granularity I'd like.

As I was reminded this weekend when Naomi was working on something I promised long ago to streamline for her, those tasks that aren't mission-critical often get lost. That same incident reminded me that leaving things to do in my Inbox wasn't all that effective; that thing is pretty crowded, so tasks get lost easily (mission-critical or not). Today's surprise reminder that iConference reviews are due was more evidence that my current task management process is just not working. So, a number of problems are happening here - I don't have one place to look for things to do when I need to maximize my efficiency, and I lose track of tasks that aren't mission-critical or that are due far in the future.

What's my solution? Today it's Remember the Milk. RTM is one of many (see this guy's blog for more) To Do list software apps out there, and I started using it yesterday. I like that it lets me assign tasks all kinds of metadata (including tags, due dates, estimated completion times) and to group tasks into various lists. I have lists for my dissertation, the KNOW SI project, other research, and personal stuff. RTM lets you email in (or Jott) new tasks, has Google Homepage and Mac widgets, and is generally a friendly application. I downloaded Google Gears too, but I haven't had to use RTM offline yet.

Hopefully Remember the Milk will help me stay productive and keep better track of those low priority (but necessary) and future tasks.

16Nov/070

Creative Commons and Flickr hit paydirt again

This time, someone wanted to accompany a news story with a picture I took. Have you heard of this NowPublic thing? Apparently it's citizen-written news. My picture is of 3 very tasty desserts from an apparently sketchy restaurant. Read all about it.

This reminds me of that time in high school that my whole German trip flew on an airline that was closed about 2 days after we got home for violating several FAA safety regulations. I'm pretty sure that airline never flew again, but I'd have to check with Bess.

8Nov/070

365 Beers

I've been somewhat hesitant to share my 365 Beers in 365 Days mission on my blog, but I've gotten tremendous support from my colleagues in this endeavor. So, I decided I could start reporting progress occasionally here.

A group of friends and I started on this quest in spring 2007 (my start date was April 16). Our goal is to drink at least 4 ounces of 365 different beers in less than one year. I felt like I was in a beer rut, and I like to try new things, so I joined the quest. We made the 4 oz rule for two reasons - 1) 365 pints isn't advisable, and 2) some beers are so bad that drinking more than 4 oz is just dumb. I keep track of my beer list in a Google spreadsheet that has information on brewery, beer title, beer style, date consumed, place consumed, and notes. Well, actually, I put the beer information in the Memo Pad on my Blackberry while drinking and then move the data later. It doesn't look like I'll make the 365 day deadline, but I may keep tracking my beer consumption. I've really enjoyed finding new tastes and getting to know local breweries.

I haven't been very diligent in my note-taking, but I have learned a few things since this mission started. One is that I like very bitter beer - double-hopped IPAs have been some of my favorites. Another is that the Stone Brewery is apparently incapable of making a bad beer. I'm looking forward to a trip to Escondido with Matt to see Stone first hand.

Here are some summary statistics about my progress:
Total beer count: 112
Beer drinking rate: 0.544 beers/day
Number of watery domestics consumed: 5
Number of different breweries: 73
Number of beer styles (e.g. pilsner, IPA): 16
Brewery with most beers on list: Brown's (Troy, NY; thanks, Ann, Lisa-Joy, and Dan for your help!)
Favorite brewery: Stone

Filed under: Beer, Technology No Comments
8Nov/070

So what did we say? Our talk notes from GROUP 2007

Ask and you shall receive. Here is the text from which Jude and I spoke during our talk at GROUP this year. We said more than is here, but you get the gist. Thanks to everyone who stayed off the beach long enough to see our presentation!

Slide 1: Title
Welcome to Twiki and WetPaint: 2 wikis in academic environments. If you've read the paper, you'll know some of what we'll talk about today, but most of our discussion will center around analysis we've done since the Note deadline. We'll describe the process through which Twiki became KNOW SI and then tell you a bit about what happens (or happened) on each wiki, and we'll end with a group of questions we're planning to explore. What we're presenting today is some history about those two wikis and some information about our theoretical work.

Slide 2: diagram of projects
TWiki and KNOW SI are part of a larger research project on organizational knowledge and the use of wikis. We're not building just theory or just building wikis.

Slide 3: screenshots of lots of wikis
We chose to study these wikis because they're likely places for users to find and share information about and relevant to their communities.

Slide 4: Meet the Twiki
Started in June of 2005 and first used by a single research group and a few master's level classes, meet the Twiki. Twiki is still operational, but it's only remaining active users are the research group that who adopted it. Not surprisingly, the sysadmin is in that research group. Libby got to know Twiki as a GSI (Michigan's fancy term for TAs) for a course that used the Twiki.

Slide 5: 504 Twiki
That class kept discussion section notes and shared links and extra information on the Twiki. The most common complaint about the class as a whole was that the Twiki was "impossible to use" and "too confusing to be helpful." That so many students felt strongly about something peripheral to their class clued us in more acutely to the twiki's usability issues.

Slide 6: Special markup
required by the Twiki was at worst an insurmountable barrier and at best a mild nuisance for users. That class was during fall semester 2005.

Slide 7: Foosball (sept 2005)
Doctoral students, in general, were the most frequent editors of both wikis, and their wiki use started with the Twiki in September 2005 with the all-important Foosball Ladder information. We have a foosball table in our building, and we started tracking foosball competitions the same summer the Twiki was born. Other pages on the Twiki that started early include

Slide 8: Doctoral Resources (sept 2005)
Doctoral resources; a long page of resources for writing, getting funding, analyzing data, other stuff important to doctoral students' work.

Slide 9: Conferences (nov 2005)
Another long page, this one about conferences that people from SI have attended. Each paragraph contains information about the conference including when it was last held, who's gone, and what it's about.

Slide 10: Field prelims (summer 2006)
A small group of students working on their prelims used the Twiki to keep each other up to date on progress, to share time lines.

Slide 11: Fishing for info
Doctoral students were frequent Twiki editors; most Master's students disappeared after their classes ended. PhD students used the Twiki to tell each other about their work, to share info about conferences, and to archive community information like foosball prowess. A little over a year later, some students

Slide 12: Eating food
were eating food and talking about wikis. Discussions for a new, more usable, easier to find wiki began. Isn't that the way many interesting projects start? Anyway, it was time for a new wiki platform.

Slide 13: WetPaint
we chose WetPaint as the 2.0 platform because it promised to be ridiculously easy to use and sported a WYSIWYG editor reminiscent of our favorite (or not so favorite) word processor. The WetPaint wiki also got a new nick name - KNOW SI - Knowledge Networked on a Wiki for SI.

Slide 14: KNOW SI
KNOW SI started with seeds - content grabbed from the TWiki's active, public, whole community pages such as

Slide 15: Conferences (KNOW SI)
Conferences, and

Slide 16: Doctoral Resources (KNOW SI)
Doctoral resources. This page has grown

Slide 17: Doctoral resources navigation
into a large section that now has 14 pages including

Slide 18: What I Learned
What I learned - a page started by a doctoral student who had defended and accepted a tenure-track job. He enlisted other recent grads to make an interesting page of advice.

Slide 19: Papers by SI Students
Papers by SI Doctoral Students - a one-stop shop for finding papers we've written; skimming it gives you a sense of the breadth of work we do at SI. The papers page is an example of a kind of behavior that's been used a few times to generate wiki content - a student sent out

Slide 20: Emilee's email
an email letting people know the page existed and offered to post others' papers.

Slide 21: Papers original version
That email generated this first version - 1486 words.

Slide 22: papers history
Then, the page grew as more students added their own papers. Other KNOW SI pages such as a blog list and auto mechanic recommendations started similarly; one person got a bunch of information from many people, created a page, and then let it lose for the community to update. We'd seen the same thing with the original doctoral resources page on the Twiki; this one just gets a lot more action.

Slide 23: question marks
So that whirlwind tour shows you some of what we see on both wikis. What does any of this tell us? People are using the wiki, or at least trying, to do a number of things including

Slide 24: What I learned; Conferences for SI Types
Give advice

Slide 25: Foosball, basketball, grilling
Store, or point to, information about activities in the community

Slide 26: Good Mechanics
Aggregate and store information

Slide 27: making sense of wiki use
A couple theories help us analyze those behaviors - one of them is transactive memory.

Slide 28: Transactive memory
In this project we look at transactive memory as part of organizational knowledge

transactive memory - a theory of organizational memory, by Wegner (1986) that suggests knowledge within an organization/group is distributed among the group and that individual members can serve as memory aids to each other. One key to transactive memory is being able to build a shared understanding of "who knows what". For instance, if I wanted to get baseball tickets in Michigan, chances are likely that I will turn to Libby for help because I know that she is a major baseball fan.

Slide 29: Newcomers and knowledge sharing
Such anecdotes and informal knowledge sharing are essential for newcomers to academic communities. Academic communities are highly dynamic environments with a high turnover of members every year or even semester. By knowing "who knows what", newcomers know who to approach for particular pieces of needed information.

Slide 30: Who knows what
One example of how the wiki supports this kind of "who knows what" investigation is that it keeps track of the authors of its content. For newcomers looking to learn about student organizations, the history of that particular page can tell them something about who might know about a particular organization.

Slide 31: Takeaways
We have two important findings from this first part of our study - people will use a wiki to share information relevant to transactive memory; they're more likely to use it if it's easy to use and you give them time.

Slide 31: What's next?
We've been careful to this point not to generalize from the use within SI, a bounded academic environment, to organizations in general or public wikis broadly. At this point, we're not prepared to make broad claims about wiki use in organizations. Rather, we're using the data we and theory we've generated and used thus far to move us along to another iteration and more chances to study organizations.

Slide 32: Questions?

2Nov/070

ECC Trivia: slump test

I spent about 3 hours with the students in the ACE-MRL lab this morning while they mixed and poured some engineered cementitious composite. I learned lots of things, but right now, I'm offering you this linguistic tidbit: slump.

In this case, slump refers not to the Hawkeye football season or some other sudden, severe decline in value but to a kind of test performed on concrete. In the slump test, fresh concrete is poured into an almost-cone, someone pulls the cone up, and then someone measures how far from the center of the cone the concrete ends up. Basically, you make a pancake of concrete and measure its radius. The results of a slump test tell you something about how "workable" the concrete is - how easily you can "place" it in a structure or form of some kind. It also tells you how cohesive that mix is.

So there you go. Today's bit of flexible concrete trivia is "slump." Pictures to come!