Forum .LRN Q&A: Re: .LRN releases
Before I begin that thread, I'd like to hear from others on the question of how we might best go about it. I think one way to that that is to ask people what kinds of contributions they might like to make and might actually make and why they think this might be helpful.
For example, it is the begining of our semester and I'm involved in implementing both Dotlrn and Blackboard. I've got a bunch of people organizing short case studies based on some "over the shoulder" observation and interviews and the preparation of one-page reports. I'm doing everything they are doing, and so this week I'm scheduled to observe in-class training of students by their instructurs and teaching assistants in one Dotlrn class and one Blackboard class.
I'm hoping my notes and photographs will help me better understand how new users figure out how to use the stuff, and since these are being done in class, how come, for example, they are apparently not using the written documentation I and others have prepared for them. I hope to hear some telling comments, as I have heard recently, like how warm and fuzzy people feel when they join Dotlrn groups (and how exposed and uncertain they feel when using Blackboard) and based on these comments come up with little bits of advice.
For instance, the warm and fuzzy comment led me to appreciate the soft, rounded corners and neatly stacked containers I find in the Dotlrn interface as well as the alternative to the "security violation, this incident has been logged" I penned this week in response to an even more hateful and confusing logon error message in Blackboard, something like: "Ooops! I think I recognize your email address, but I don't recognize what you just typed into that password box! Try typing it again carefully, and if that doesn't work, you'll need to get yourself a new password by ...." This is a bit wordy, but unlike the "authentication failure" message it would replace, most normal people would understand it and finish reading it knowing what to do next. It is also a concrete suggestion that I could deliver to a developer, and part of my case study will be the difference between what happens when one makes such suggestions in Dotlrn and what will happen this week I follow my suggestion's fate through my own institution and, as we can't mess with Blackboard, how it is handled by Blackboard.
I fully understand that there are many ways to skin a cat, so I'm hoping that others will suggest other ways. I do hope we might establish some underlying criteria or standards or goals for this enterprise.
First, I'd like to be sure we have someone contributing from each of the major implementations. Second, I'm hoping that the contributions will be based not only on the good advice we developers and administrators might offer from our valuable experience, but also, on some interviews with non-professionals so we might see and hear things we might not have heard and discover some new uses and trends.
Finally, I would propose that we go to all this trouble only when we identify one or more developers who might actually put whatever we might have to say to good use. This is why, in my earlier post in this thread, I used the figure of the "sounding board" rather than "steering development" -- I get uncomfortable whenever I feel like I am making suggestions other people don't want to hear, or that no one is hearing, but I feel just wonderfully useful when I can give a simple account of what I have seen or heard to a developer who has gotten to the point where he is about to make some decisions based on presumptions that he is not sure have been fully tested and so might appreciate what someone outside of his immediate craft might have to say. Also, I like it when I can speak not simply from my own experiences, but also, as if I were a sociologist or anthropologist (thank you, John Seely Brown) offering an even-handed survey of social life.
OK, that's my starting point. I'm hoping some others will discuss what they think the protocols might include, and then maybe we can move on to listing and scheduling topics and functionality, and then how we might start, intensify, extend, and then conclude some discussion threads.
I'm here to go! How about you?
Its important to notice, that not always coincide the available time to talk about usability stuff and to develop that suggestions, so everybody should be flexible, and after some amount of discussion about UI come with specific to-do's (then no need to talk again about the same stuff). At least at Galileo the intial plan is that from december/04 dedicate about 3-4 months to work periodically on UI.