Aperte.org

Collaborating in virtual worlds

Jeremy Handcock — Fri, 19 Feb 2010 06:17:05 +0000

I recently watched a Frontline episode on avatars and virtual worlds that summarized some really interesting research going on at Standord's Virtual Human Interaction Lab (VHIL). This short clip is a good overview: The projects underway at VHIL show a lot of really exciting potential for collaboration in virtual worlds. They have a number of studies that suggest real-world social phenomena transfer into virtual worlds and that what happens in virtual worlds seems to impact real-world behaviour. In other words, users don't seem to finely distinguish their experiences in the virtual world from those in the real world. IBM is already using Second Life for remote collaboration in a big way, as are many other organizations. Meetings, conferences, you name it: it's all being done in virtual worlds. When I first heard about this form of collaboration, I thought it was a little gimmicky. It couldn't possibly replace informal, ad hoc communication in the workplace and it couldn't be any better than picking up the phone. Glancing over this research has changed my viewpoint, though. Virtual worlds are clearly more than isolated, independent realities. I'm actually pretty keen to try out a virtual world meeting. Are you on Second Life? If so, let's make up an excuse to have a meeting! (As soon as I figure out how to get more stylish clothes on my avatar.) Share:

So you want an elected Senate? Think twice.

Jeremy Handcock — Tue, 16 Feb 2010 09:22:33 +0000

Senate reform in Canada has received newfound attention lately thanks to Stephen Harper's recent appointments that give the Conservative Party a plurality in Parliament's upper chamber. Conservative dominance in the Senate increases the likelihood that pending Senate reform legislation will be approved, notwithstanding any challenges to legislation's constitutionality by the provinces. According to recent polls, the majority of Canadians support reform and I think many consider the Senate to be a stodgy relic of the country's colonial days. The most popular option among reformists is to have an elected Senate, similar to how it works in the United States. At first glance, this seems like a good option: the more democratic the Senate is, the better, right? In my opinion, this view is short-sighted and I encourage Canadians to dig deeper as the reform debate is reopened.

Canadian Senate primer

For those of you not familiar with how the Senate works in Canada, the Governor General---the head of state and the Queen's representative in Canada---has the authority to appoint individuals to the Senate when seats become vacant. In reality, the Governor General only makes appointments on the advice of the Prime Minister, so the PM ultimately decides who sits in the upper chamber. Once appointed, a Senator holds his or her seat until the age of 75. The Senate was originally designed to provide representation balanced by each region of the country and sober second thought to legislation passed in the lower chamber of Parliament, the House of Commons. The Senate considers each bill passed by the House of Commons and may approve the bill, request amendments to the bill from the House of Commons, or reject the bill altogether. If the Senate approves a bill, the Governor General approves it and provides royal assent---a formality from colonial days---and then the bill becomes law. See the Wikipedia article on the Canadian Senate for more background.

Senate reform

Senate reformists in Canada generally support electing Senators rather than appointing them, or abolishing the Senate altogether. A recent survey conducted by Harris/Decima found that a majority of Canadians want Senators to be elected by the voters of the region they represent. The next most popular option was abolishing the Senate, while very few support the status quo. Advocates of an elected Senate believe that it should be a democratic institution and the actions of a Senator should reflect the will of the people that he or she represents. Moreover, the Senate should be responsible to the electorate. My issue with an elected Senate is just that: votes in the chamber would be highly influenced by the public opinion of the day. Facing re-election, Senators would pander to the latest polling numbers over the long-term interests of their region and the country. Raw partisanship in the House would bleed into the Senate as parties seek to differentiate and define themselves for the next election campaign. In this sense, more democratic isn't necessarily better. To me, the fundamental purpose of the Canadian Senate is to provide non-partisan review and sober second thought to legislation on balance with the will of the elected lower chamber. With this in mind, abolishing the Senate altogether is not an option. As broken as it may seem, the status quo or a variation thereof may best reflect this purpose.

How does the Senate currently behave?

Proponents of an elected Senate argue that Senators simply toe the party line along with their colleagues in the House, so the unelected Senate can block the will of elected House. If this theory is correct, the Senate behaves as follows:

If the Senate is dominated by members of the governing party, it will approve the bills passed by the House without amendments.
If the Senate is not dominated by the governing party, it will block bills passed by the House by requesting amendments or rejecting them.

Obviously, both of these behaviours are less than ideal, so I set out to see if there is actually any evidence of them. Using the LEGISInfo database from the Library of Parliament, I found all the occasions where the Senate amended or rejected bills introduced and passed by the House of Commons. I'd hoped to go all the way back to 1867, but LEGISinfo only has data from the 24th Parliament to the 40th Parliament (from 1962 to the end of 2009). For each amendment or rejection, I found out whether the governing party at the time had a plurality---the most seats of any party---in the Senate, which is a decent indicator of how easily the government could move bills through the Senate. Because the number of bills introduced and passed by the House can vary widely between Parliaments, I was really interested in the proportion of rejected or amended bills relative to the total number of bills that received royal assent in a given Parliament. As you can see, the proportion of House bills that were amended or rejected by the Senate doesn't seem to be directly related to whether the governing party had a plurality in the Senate at the time. In other words, the Senate does not behave in a purely party-disciplined fashion. Quite the contrary: there are many instances where the governing party had a plurality in the Senate but returned legislation to the House for amendment. You'll also notice that for most Parliaments, fewer than 10% of the bills were amended or rejected, meaning that the Senate has generally respected the will of the elected House. (By the way, the Senate rejects very few bills from the House. It has rejected only three bills in the past 50 years).

So, do you really want an elected Senate?

There is no evidence in these data to suggest that our current Senate system doesn't work according to the principle of providing non-partisan review. Also, there is no evidence to indicate that the Senate does not respect the will of the elected House. Without getting into the substance of each amendment, I'd say the Senate is not as broken as most people think. In fact, its current form is probably better than any of the alternatives. Given the behaviour shown above, I would much rather stick with the Senate we have instead of turning it into a poll-driven, elected body that is motivated to act out of short-term interest. There are as many opinions on senate reform as there are Canadians, although one thing is certain: there is a bumpy road ahead if the government decides to proceed with senate reform legislation. Keep these things in mind as you consider all the options. Share:

google wave and collaborative tools

Jeremy Handcock — Tue, 02 Jun 2009 06:40:05 +0000

My initial reaction to the Google Wave demo at I/O was luke warm. C'mon, it's just a nifty UI over publish/subscribe messaging! Along with pubsub, the federated aspect of Wave---the seamless integration of users across multiple domains---is just standing on top of vanilla XMPP. From a cynical point of view, Wave is much more of an engineering feat than a shining piece of technological innovation. It's not all about recycled technology, though. The exciting part of Wave is the collaborative abstraction of XMPP that is centered around conversations rather than individual messages. As someone interested in developer tools, I see a lot of potential in Wave. The presenters at I/O actually had a demo of a Google Code issue tracker extension that allows you to create, follow, and respond to conversations in a bug report using Wave (see around the 1:02:30 mark): Very, very nice. After watching the demo, I realized that Wave-based developer tools could share a lot in common with the ideas I wrote about a few weeks ago---integrating artifact streams with work streams in a microblogging tool: In both scenarios, I think the proposed value comes from: 1. aggregating and persisting conversations in one place; and 2. enabling easy ad-hoc communication between participants. In any case, it looks like Google Wave may provide a nice framework to play with my ideas, so I'm excited to see how it shapes up. Share:

microblogging at work: workstreams and artifact streams

Jeremy Handcock — Sat, 02 May 2009 18:06:41 +0000

One of the reasons that Twitter has become so popular is that it is a successful ambient awareness tool. With each tweet from a friend or person of interest, you get a subliminal sense of what he/she is up to. Each tweet also represents an opportunity for ad hoc, informal communication between Twitterers: In Wired Magazine and then more recently in the New York Times Magazine, Clive Thompson discusses social proprioception, his term to describe the social 'sixth sense' that comes with microblogging. Proprioception is a really wonderful metaphor for describing ambient awareness and I think it can extend beyond social settings into the workplace as well. Yammer, for example, is your Twitter at work. I've never seen Yammer in action, but I think it's a really interesting idea. Just as you publish your lifestream on Twitter, you publish your workstream on Yammer---micro-level updates about what you're working on. Say you only have a once-a-day standup meeting with your team in the morning. Wouldn't it be nice to get more fine-grained details of what everyone is up to throughout the day? I could also see microblogging at work as a great way to close some of the distance in a distributed team. You get regular updates from team members afar, potentially a greater feeling of social connectedness, and opportunities for ad hoc communication. Microblogging at work is a fine idea by itself, but what about combining workstreams with artifact streams inside a microblog? The developer awareness tool that I created for my research was the artifact stream part---Aufait feeds you discrete tidbits about how your project artifacts are changing. I focused on source code, bug reports, documents, and automated builds, although the artifact could really be anything. If I put these artifact streams alongside a team's workstream, I get something like this: To me this seems like a natural fit. It augments all of the nice things about microblogging with additional awareness information that is really important for software developers. You can use a hash (ie. #sprocketdev) to publish a conversation to your team's channel and of course you can poke around other channels and people just like on Twitter. The screenshot above is Jaiku on AppEngine. Jaiku is Google's freshly open-sourced microblogging platform and it works pretty much like Twitter. Getting the aritfact streams in there is just a matter of publishing events (ie. version control commits, bug report updates) into Jaiku via its API. From there, you can get your hybrid workstream/artifact stream from Jaiku's web interface, RSS, or even using its API. I'm going to take this up as a project so I'll let you know how things come along. If you have any feedback or are interested in collaborating, feel free to get in touch! Share:

new job!

Jeremy Handcock — Thu, 19 Mar 2009 00:43:59 +0000

Good news! I'll soon be starting a software engineering gig at the Institute for Systems Biology (ISB) in Seattle, a non-profit biomedical research organization. ISB is full of really great people and they're doing some exciting work in proteomics and computational biology. I'll be joining the Shmulevich Lab and I'll be starting with a project to bring human proteomic data onto the Cancer Biomedical Informatics Grid. Although computational biology wasn't the subject of my thesis research, I really enjoyed the coursework/research project that I did in this area and I'm looking forward to learning more. I'm also excited to get a first-hand account of how software engineering works in big science. Altogether it's a great opportunity and it will be fantastic to be back in Seattle. Yay! Share:

the ideal of authenticity: grad school?

Jeremy Handcock — Mon, 09 Mar 2009 18:23:08 +0000

I've been reading Michael Ignatieff's CBC Massey Lecture The Rights Revolution and I had to laugh a little when I came across this section regarding authenticity:

The central idea I absorbed then---chiefly, if not exclusively, from feminism---was that each of us has a right to choose the life we lead and that we must fight to exercise this right against all comers. This could be called the ideal of authenticity. In the name of this ideal, we all went off to find ourselves. This meant getting away from family, career, society, and going in search of the self's authentic impulses. Sometimes the results were laughable: the 1960s cult of authenticity produced dull conformity in no time. We all went in search of ourselves and ended up in graduate school.

Sounds about right! Ah well, at least grad school is more productive than bumming around a ski resort for two years. Beside that point, The Rights Revolution is a really excellent read about rights culture, civic and ethnic nationalism, and the balance between individual and collective rights in Canada. Ignatieff frames Canada as three distinct founding nations that coexist with a diverse and prominent immigrant population, and when you look at the country through that lens, it's pretty amazing that it still exists in one piece. It's even more amazing that the constitutional and legal framework has managed to satisfy---more or less---all of these different interests. There is still more to be done and although there have been bumps along the way and some very dark chapters, things could be much worse. Just read Ignatieff's Blood and Belonging. Share:

i am for hire!

Jeremy Handcock — Mon, 16 Feb 2009 06:25:24 +0000

Now that I have my master's degree wrapped up, I am officially for hire! I am primarily looking at opportunities in the Seattle area. If you are on the hunt for a creative, smart, and hard working Software Engineer, have a look over my resume and feel free to get in touch. I will be in the Seattle area in a few weeks if you want to grab a coffee and chat. Share:

visualizing mozilla lizardfeeder

Jeremy Handcock — Sun, 15 Feb 2009 23:51:06 +0000

I recently came across LizardFeeder, a "compilation of data feeds representing activity within the Mozilla community." I think it's a pretty nice tool. It shares some ideas in common with my awareness tool for developers, especially in that both tools aggregate discrete events in a software project. Obviously, the scale of our approaches is a little different; I was focused specifically on building a tool for a small team.

(LizardFeeder screenshot)

Dave Bottoms of Mozilla has published a call for designers to create "a visualization that attempts to demystify the collaborative process of making software, while celebrating [Mozilla] contributors." The goals are a little nebulous, but my take on it is they want to build on the ideas in LizardFeeder and come up with a visualization that is universally approachable, even to non-technical people. Software Engineering and Human Computer Interaction researchers have been trying to visualize software development communities for a few years. The archives of the Mining Software Repositories conference have some examples and one can also look to recent projects such as code_swarm. There have been some nice designs, for sure, and code_swarm is definitely fun to watch. At the same time, my pragmatic side is left looking for more. In practice, these are the kind of visualizations that you put up in the lobby of your building (in HiDef!) to impress visitors. Visual wow factor is a noble goal in itself---don't get me wrong---but I think we're still searching for ways to build meaningful tools in this area. The Mozilla proposal is especially welcome in that regard. I'm looking forward to seeing what comes out of it all, and given LizardFeeder's overlap with my research, some interesting ideas for awareness tools might emerge along the way. Share:

my awareness tool for developers: Aufait

Jeremy Handcock — Fri, 13 Feb 2009 21:27:20 +0000

I've put together a demo version of the tool (code name: Aufait) that I developed for my research. Feel free to try it out! If you haven't been following my work, I developed Aufait as an awareness tool for software developers. Specifically, it is designed to support awareness of peer activities and changes to shared artifacts (ie. code, bugs, documents) in a small team. From a design perspective, there are some things that I would change based on the results of my field study, but I'm interested in your off-the-cuff thoughts as well. Note that this demo is static in the sense that it won't automatically update with new data as Aufait normally would. The time interval selection features are also disabled. The demo is running on data from the Apache Derby project. I have no affiliation with Derby nor its developers; I just picked a small open source project with data that was relatively easy to obtain for the demo. If you're interested in seeing how developers use Aufait in the wild, check out my thesis paper. A quick summary of the UI follows.

The Event Timeline

The main view in Aufait is an event timeline. An event is any modification to a project artifact such as source code, a bug report, a project email, or a wiki document. The design has a lot in common with the SIMILE timeline. Each developer on the team---listed along with his/her photo on the right side of the screen---is associated with a colour. Events on the timeline are coloured according to the developer who initiated them. The idea here is to promote awareness of peer activity by clearly connecting events to individuals.

Revealing Event Content

As you can see, each event on the timeline has a short textual description. For example, an email from the project mailing list shows the subject line: You can click on nodes in the timeline to reveal more content for an event. Here you can see a bug report event that describes what the developer changed: Note that Aufait includes a link to the artifact that was modified (whenever possible). As shown above, a bug report event has a link to the bug report. The idea is that developers can get more information about a modified artifact or take responsive action by following the link.

The Details View

In addition to the event timeline, Aufait provides a more content-oriented view that is similar in design to an email or news reader. You can switch to this view by clicking on the 'Details' tab. It has a smaller version of the timeline that you can interact with in the same fashion as the larger one.

Filtering Events

You can filter events using three methods: by developer, by drag selection, and by keyword search. Clicking on any of the developer photos will filter the display to show events authored by him/her: You can also drag to select events in the timeline. The idea here is that you can select a bunch of events that might be of interest and then switch to the detail view to examine them further. Typing a keyword into the search box (and pressing enter) will filter events to show only those with content that matches. For all three filter types, you can remove a filter by activating a new filter or by clicking the 'clear filter' button.

Back-end Services

There are a few back-end services that support Aufait's UI by aggregating, storing, and publishing data from a software team's internal systems. The demo is running on static data files, but when it is running live, Aufait continuously updates itself with new events. Getting the data for the UI was a large chunk of the work in implementing this tool. I won't get into the details of it all here; have a look at my previous post Aggregating Project Events in the Wild if you're interested in how I did it. Share:

my thesis paper: how developers use an awareness tool

Jeremy Handcock — Sun, 08 Feb 2009 22:24:08 +0000

I've made my thesis paper available online for those who might be interested. It's entitled How Developers Use an Awareness Tool: Patterns and Scenarios and I've included an abstract below:

Software developers consult numerous sources of information in order to maintain awareness of what happens within their teams. They seek information about what their peers are doing and what project artifacts have changed. Although researchers have proposed many tools to facilitate developers in maintaining awareness, there is currently a lack of understanding about how developers might use them---if at all---in real software projects. We have designed and implemented a new awareness tool for software developers called Aufait. We conducted an exploratory study of developers using Aufait in two organizations over a three-week period and found that they adopted it and used it regularly. We identified a number of usage scenarios in each organization: most commonly, developers used Aufait to manage dependencies between team members and to determine how changes might affect them. We also found common usage patterns. Throughout the course of the study, developers were most interested in changes to source code relative to other artifact types and they were primarily interested in changes that occurred very recently. Together, these patterns and scenarios suggest necessary features as well as implications for the design of future tools. Our results also pose interesting areas of future research.

If you have any questions or feedback, let me know! Share: