Crisis averted

Over the last couple of months I've had a bit of a crisis looming. Some academics and students had been discussing setting up a Wiki (or something similar) for general sharing of resources between students. In one sense, it was great - it demonstrates a clear demand for these things among students and staff, and a willingness to put work in. On the other hand, despite knowing about my project, they were kind of shutting me out of the discussion. From my point of view, this stood a chance of undermining my PhD project completely - if students were presented with two resource sharing systems, one seeded with content and supported by academics, and another (my project), they would naturally choose the supported, seeded system. Leaving me with no data, and no project.

Fortunately, in the last few weeks the folks in that project have started talking to me - some of them didn't want to undermine my project, and understood the risks of having two competing projects in the same space. I think they also started to realize the amount of time, energy, and money they would need to put in to build and support the system they were talking about. Last week and this week I've had a few meetings with the team, and we've all agreed to work together - they'll proceed with their plan to seed some shared resources for students, and I'll make some modifications to my system to support what the students are wanting to do, and everyone wins :)   I'm very lucky to have supportive colleagues who are willing to work with me in this way, and I owe James a beer next time I'm at the pub with him.

This is nicely in line with my research plans anyway - I'm exploring ways to kick start and sustain a social learning network. If this seeding works, it will hopefully start a snowball effect, where students see the value of contributing, and start to use the network; and once that happens, I start to have enough data to work out how students are using the system, and how it can be improved.

On being a PhD student

Some days I am a PhD student, and some days I am a person who is enrolled in a PhD. They are two very different things, in my experience. Similarly, sometimes I am an IT manager, and at other times I happen to work at a university managing IT folks. Or a Parent, or a person with kids. I guess technically, I'm all of those things at once, but in reality, I move between those roles and identities. Of course, the raw external facts always apply - I'm enrolled in a PhD, I work at the Uni, I have kids, I have hobbies. But it's difficult to be a PhD student, a Manager, and a Parent all at the same time. Each of those people has different priorities, different needs, different ways of thinking about the world.

This has been on my mind lately a bit - towards the end of last year work got hectic and stressful, and left me with no energy for study. As time went on, that PhD student identity dissolved a bit, and the idea of spending my evenings reading, coding, thinking and writing seemed less important, and less like something I wanted to do. I would see other PhD students as "them", not as an "us". December was basically nonexistent, study-wise. January wasn't much better, but improved as the month progressed. A holiday last week seems to have restored me, and now I'm back to full strength (I hope).

It's all made me realize that doing a PhD involves being a PhD student. It's a whole identity - more than just an external fact about you're life, it has to become part of who you are. When that identity isn't in place, there's no stable source of motivation for spending all those hours tinkering away, to keep eating that elephant. Those other identities coexist, and of course they take precedence at times, but it's important to hold on to my student identity - letting go of that is the first step towards not completing this PhD.

Small efficiencies

One of the rules for a good life is to look after yourself, to spend a little time making your world better, so you can enjoy life better. The same applies to work: it's worth looking at the unnecessary little inefficiencies in your workflows, and removing them, in order to make things run more smoothly.

When I'm developing code for my PhD project, I upload it to a server in the University for testing. I'll do this repeatedly as I code, testing each bit of code as I write it. For a typical feature, I would do this at least 10-20 times. Each time, I save my file, switch across to my terminal, and run an rsync command. It prompts for a password, I type it in, and then it spends about 20 seconds uploading all the code. In total, probably at least an extra 30 seconds each time I want to test a bit of code. I quick look at my terminal history shows I've done this 281 times. That's a conservative estimate; the system only keeps 500 lines in my history file, but just that is over two hours of my time transferring content - a whole evening's work. I've known for ages that I should streamline this, but each evening, it's a case of (a) spend 5-10 minutes figuring out ssh and rsync magic, or (b) spend 30 seconds uploading my code and get on with the evening's work. I've chosen the lazy, 30 second, option so far.

I finally bit the bullet this evening, and did the streamlining - I set up the authorized_keys file on the testing server for ssh, and added a "-u" to the rsync command. My code upload now takes 1.2 seconds, and I don't have to type in any passwords at all (and these improvements don't need to be re-done - they stay in place permanently). Took me 5 minutes reading through the documentation to get it going. Life is better. Sometimes, playing around with  productivity improvements can be a time waster, but the little things like this add up, and really are time savers in the long run.

Spatial considerations

One of the issues that drove my choice of a PhD topic, and steered the way I thought about how social interactions work, was the way existing online learning systems tend to create social spaces. It's starting to change, but for a long time online learning systems kept the social aspects separate from the rest of students' learning. Even the innovative tools that linked social interaction with interactive learning tools and materials were still small systems, separate from the vast bulk of a student's online learning. Normally, students would be given a discussion forum attached to each unit of study, and it was hoped that they would use them constructively. There was minimal integration between these spaces and the other online spaces students engaged in. You end up with a space that looks like this:

And what's worse, each unit of study is a separate little mirror of this - so not only are the social spaces separate from the course material and other activities, they are also separate from each other - a conversation in one Unit of Study cannot be linked to a conversation in another unit; and when the semester ends, the units end, and the conversations are archived or deleted. It's little wonder motivation has to be drummed up by teachers, and the common solution is to make the forums compulsory.

My approach will be a bit different. Rather than creating stand-alone social tools, the goal is to embed them throughout the curriculum, so that wherever students are, there are social tools available for collaboration and interaction with peers. The above diagram becomes a little more like this:

-- each page has a little bit of interactivity attached; students socialize where the content is, not in specially constructed separate spaces. Furthermore, those slices of interaction can be linked up in other places as well - a student's profile page will contain an activity stream of their interactions across the curriculum; and student group pages can also contain activity streams of members.

The thought behind this is that by reducing the barriers to participation - if collaboration is only a matter of clicking or typing on a page the student is already visiting, there is hardly any effort at all to join in - students will be more likely to collaborate of their own accord.

Presenting my research

I presented my work to a range of folks at the weekly CoCo seminar last Wednesday, and was very happy with how it went. I received some great feedback from the folks present, and felt very encouraged. The recording should be online soon, here.

Some of the issues raised were:

• timing: it was mentioned that it was still early days, and I shouldn't be surprised at the lack of uptake. Also, that I should take into account how my releases interact with existing timetables (are students on break, or busy with exams? Will starting afresh with a new batch of first years next year mean I have a new cohort with a fresh perspective?)
• finding a champion: rather than promoting the system myself, would it be possible to find a student (or students) who might promote the project among their peers? Could the students' society perform this function?
• other studies: Karen mentioned a range of other studies she has read about that deal with similar situations - using social networking tools in medical education.

It was a very friendly, positive session, and I was very grateful for the constructive and helpful attitudes of all present.I've got a good amount of food for thought - I'll have to listen to the recording myself, and make notes on what followup actions I need to take.

Thoughts on Design Research

I had a very interesting discussion with my supervisor about Design Research today. He pointed out what should have been a bit more obvious to me than it was; that the problems I'm facing are kind of inherent in my methodology, Design Research.

Design Research is one of the various flavours of Design-Based-Research (a good taxonomy of the various kinds of DBR is given in Wang & Hannafin (2005)). What I'm doing seems to be a bit unusual, in that most DBR seems to be conducted in a setting where the participants have to participate - it's in their classroom, or they have been signed up to participate for some other reason. Not participating in the research has to be done actively - the participants don't just have the option of ignoring the research, they actually need to refuse. In my study, I'm providing tools in a system the students are using, but they don't have to use my tools.  I haven't found anything in the literature about Design Based Research under these conditions. I'll need to conduct a more exhaustive study, to see how other researchers have tackled this problem. Another difference from traditional DBR is that the teachers aren't pushing it; the teachers don't even see my system, and aren't out there in lectures encouraging students to use it, so I'm missing the Teaching Presence component of the Community of Inquiry framework (a model that attempts to explain the success of failure of online learning communities, introduced by  Garrison, Anderson, & Archer (1999)). Part of what I was hoping to do was show that these systems can work well without the Teaching Presence component, if designed well enough, and if the barriers to usage were low enough.

My study is meant to be based around analyzing the usage of the system in order to improve it. My current situation, however, is that I'm getting very little data (and what there is seems to be indicative of students exploring a system to see what they can get out of it). This means I have nothing on which to base judgements about useful functionality. So, it seems I have two choices (I was loosely aware of this, but today's discussion clarified it):

1. Keep trying to improve the design, until it gets good enough that students want to use it.
2. Promote it to students (perhaps with bulletins, or a visit to the lecture, where I can give a ten minute intro to the system, and encourage them to use it). 

Option 1 is risky - I run the risk of the students just not choosing to use the system. Option 2 means injecting some Teaching Presence into the experiment, which I'm not sure I'm ready to do yet.

Social networks (rather obviously) are built around network effects. In other words, the usage of a social networking tool depends more on whether other people you know are using the system, than on the qualities of the system itself. I don't use Facebook because it's the social network with the best set of features (it probably isn't); I use it because my friends and family are using it. The reason I almost never use Google+ because pretty much no-one I know uses it (I visit it once a month or so for my good friend Evelyn's excellent rants). To kick-start the use of my network, I need to get some initial usage going, and then not only will I be able to improve it based on analysis of that usage, but that initial set of users will draw others in. Of course, I'll have problems separating out the two effects - the snowball vs. the improved interface - but that's the kind of problem it would be good to have.

One last possibility is that the current cohorts see this as something that isn't much use to them; they survived perfectly well before it was introduced, and therefore don't have any real drive to explore it. There's the potential that next year's incoming first years might take it up to a greater extent, since as far as they're concerned, it's just another part of the system, and it has always been there.

So, where to from here. Firstly, some more thinking about this situation - even without much usage, I might be able to pull together a perfectly decent thesis about the methodological issues of DBR in this unusual context. Certainly, I need to delve more deeply into the literature to see who has tried DBR in similar contexts, and how they handled it. Perhaps even into literature around software development, and how usage of software takes off - what is more effective: having the best software, or having the best publicity?

References:
Garrison, DR, Anderson, T & Archer, W 1999, ‘Critical Inquiry in a Text-Based Environment: Computer Conferencing in Higher Education’, The Internet and Higher Education, vol. 2, no. 2-3, pp. 87–105.
Wang, F & Hannafin, MJ 2005, ‘Design-based research and technology-enhanced learning environments’, Educational Technology Research and Development, vol. 53, no. 4, pp. 5–23.

Presenting my work

I'm learning that actual research is only half the job of being a researcher. The other half is explaining what you've found to others - in publications, conferences, seminars, and so on. Research doesn't magically disseminate; it's the researcher's job to push it out into the world, and make people take notice. The most successful researchers aren't necessarily those with the best ideas - you need to be able to convince others of the ideas as well.

As part of my PhD, I have to present my work. I have to present it at least twice at conference-type settings (including the research student conferences within the Faculty). I'm also expected to present once or twice in the CoCo seminar series, which is the seminars being given within the research group I'm studying in.

I presented this year in June at the research student conference. It was good - I wasn't yet in The Rut, and it was good to talk about my work to other students (and a couple of staff). I had my usual public speaking nerves, but nothing too much. My next presentation is at the CoCo seminar, and I'm wondering how I'll approach it. I don't want to give the same presentation, since the audience is different. These folks are all very smart, and are experts in the areas around my subject area. I'll need to present some of my data (what little there is), and what I'm doing, but apart from that I've got a lot of options:

• Focus on social networking
• Focus on Design Research
• Focus on design
• Focus on my data
• Give a broad overview, and skip details

It's a tricky set of choices. I should be approaching it as a way of getting good feedback, and therefore exposing all my weaknesses; but as a PhD student, I've got a reasonably strong dose of Imposter Syndrome (heh, I just had a quick read of that wikipedia entry, and it actually says "It is commonly associated with academics and is widely found among graduate students"), and in the annoying recesses at the back of my brain, I'm worried they'll tar and feather me and run me out on a rail. I know it won't be that bad, and folks there will be supportive, so in a way I'm also looking forward to it.

Oh well, I'd better start working on my slides...