This site is rarely updated. benbrophy.com is more up-to-date. - Ben
Listening to users
Here's a must read piece: "Listening to users considered harmful?" on Creating Passionate Users. The gist of it is that listening to users will help you make incremental improvements, but won't lead to revolutionary improvements. It's something I've been grappling with when we discuss setting priorities for Stellar development.
Other than the work we're doing right now, I believe the best major improvement we could make to Stellar is to restructure the materials, schedule and homework tools to be organized around class sessions. Instructors would come in, with slots to fill up for each time their class meets. My inspiration comes from looking at hundreds of syllabi, and looking at the way 100s of Stellar courses are organized now.
Nobody asks for this change, but I can see it buried in many suggestions and complaints, "It's hard to keep my materials organized" from an instructor or "It's hard to see what I need to do today" from a student. Yet my experience and instinct tells me this what's needed. I'm applying the general rule of listening for user goals when I hear feature requests, not listening for solutions.
By listening to users we'd add infinitely nested folders like in Sakai's resources tool, and an elaborate calendar tool like dotLRN (I love dotLRN's calendaring, btw). These could be improvements, but the problems would persist and ease of use would decline. It's not revolutionary, it just adding features to existing tools.
We're not in the position to make either of these kinds of changes to existing Stellar tools right now. Hopefully Sakai will give us that opportunity - but I'm afraid it's design goal of being generic enough to work for research teams as well as academic classes will make it difficult. If advocating for this kind of change is a hard sell at MIT, it becomes exponentially more difficult when there are so many other stake holders involved.
No solutions here, I'm just wondering how to keep a development team nimble enough to make revolutionary improvements on a project that is so big.