[DG: Teaching & Learning] Teaching & Learning] Sakai Teaching and Learning Call > NEWINITIATIVE DISCUSSION

Wed Jul 22 11:28:32 PDT 2009

Michael, 
I agree with your idea about "20 universities get 20 users to describe 5 situations." The difficulty I've noticed has been gathering these people within the narrow timeframe for agile development. For instance I saw a note from Lance at Indiana going to UX list about what "users" want a mobile app to do. I worry if they get no feedback (UX list is not heavily trafficed) that they will proceed without it (but see note below to see why the users they already have in mind might be fine, even if it's just one example*) 

 In contrast, Cambridge spent a few concentrated weeks recruiting 24 people to interview, Gaurav at Indiana wants to get people at various campuses to interview local users for his Sakaibrary project, and when we start up on Samigo in earnest, we'll probably try to do something similar.

My thought is that it would be fantastic if we had a bank of "typical" users in the community, with leads at different schools who could recruit them at a moment's notice. It would be like a virtual phone tree that could be instantly activated when a project leader says "I want to know how users think about X and the activities they do." The branches of that tree could be folks on T&L, or the leads in the Multi-Institutional Survey. We would want a variety of schools and a variety of people at those schools (not just power users) and the more the merrier, since we might be calling for input several times a year for different projects.

This bank could be used in two ways
1) to put out a general call  for use cases and scenarios
2) a more targeted search for people who meet particular criteria for more detailed research and to insure we are getting proper diversity

In anticipation of such an effort, during our spring survey, we asked if people would be willing to do follow up interviews and got a few (we have proxies in different departments but they don't often have specific names). 

So the campus rep could get the bank, but the person seeking the information might also need to solicit information in a structured way. I'm just starting to think through this, but here are some early, rough thoughts
1) when a project lead is looking for use cases and scenarios, they put out a call to campus reps and point them to a page containing a description of what the project is and what information the user should supply. For instance, the CARET project studying social networking for academic use had users keep a journal of every time they communicated with someone, and researcher followed up to tease out what the goal was behind each task, and what frustrations users experienced. It might be possible to do an online, asynchronous approximation of this with an online form, either directly by users or with assistance.

2) when a project lead is looking to interview users directly, they could put up a questionnaire to screen them that could be passed to others. For instance, we are just starting to think through what kind of diversity we want represented should we interview people who either use or might use SAMigo (distance learning, discipline, small vs large, etc.)

Keli Amann
User Experience Specialist
Stanford University

*Someone filled me in about where the mobile project is coming from. One of the chief proponents is in South Africa, where students don't have computers and can't easily travel to campus--if they could at least get announcements, that would save them from having to get to campus. This is an example of where, by serving the one, you serve the many. Mobile access was not a first priority for Stanford students or instructors, but it would certainly be nice--designing it for a South African student is probably just fine for any student in any country.

----- Original Message -----
From: "Michael Korcuska" <mkorcuska at sakaifoundation.org>
To: "Kenneth Romeo" <kenro at stanford.edu>
Cc: "Josh Baron" <Josh.Baron at marist.edu>, pedagogy at collab.sakaiproject.org
Sent: Wednesday, July 22, 2009 9:42:01 AM GMT -08:00 US/Canada Pacific
Subject: Re: [DG: Teaching & Learning] Teaching & Learning] Sakai Teaching and Learning Call > NEWINITIATIVE DISCUSSION

We have a lot of work to do here, Ken, and you point at some of it. I do think we need to build the framework you're talking about. We have a decent start at a piece of that with the K2/3akai work but it needs to move beyond that use case. During the conference a group of folks began working on the idea of what I'll call the "Extremely Simple Course Site" as the next organizing principle. I think we'll be able to pull together a design team to start tackling that task quite soon. 

[just saw John Norman's email come in but will keep going here although he makes similar points] 

There are a variety of levels of participation in the design process and the OSP pages contain a variety of different levels so they may need some explanation. We would love to get folks involved in creating detailed functional requirements and wireframe design, of course, but we recognized that faculty and instructional designers may not have either the time or the skills to do that work. Still, we want their voices in the design process. 

So *I think* what we're hoping for is plain "English" [French,Spanish] descriptions of what happens in the classroom. I still use your post from last year as a great example ( http://www.stanford.edu/~kenro/essays/Sakai3ProposalComments.html under "Concepts of facilitating instruction"). This is more a use case or, in language I think Daphne Ogle provided some clarity on, a User Scenario (I think there was talk of a glossary for these terms but I couldn't find it). In any case, if we can get a collection of this kind of content we can use it to both inform the detailed design work (from formal requirements to wireframes) and to test the design against ("how would the user do this with what we've built?"). I think this is exactly what you mean when you say "functional vision" below but I'm not sure. 

The quantum/atomic object discussion is, in my mind, the work of detailed design. We'd love to have functional experts (like yourself) participate in that process. But Josh's message (I think) is targeted at those who may not have the time/inclination/skills to participate at that level. And I do think that detailed design work will be more fruitful if we have the User Scenarios straight from instructors (and researchers and students!). 

I'll also get on my soapbox here to say that this is a great opportunity to leverage our distributed nature. If 20 universities get 20 users to describe 5 situations where they are (or would like to be) leveraging technology we can quickly generate 2000 user scenarios. A little tagging on those scenarios could create a great resource for design/development efforts. 

Cheers, 

Michael 

On Jul 22, 2009, at 00:17, Kenneth Romeo wrote: 

Hello everyone, 
I am a newbie to this and was really looking forward to joining the call tomorrow, but I have run into a situation that I need to take care of at that particular hour. So I am sending my comments here, in the hope that somehow they might contribute to tomorrow’s discussion. 

First, I am very grateful to Josh for bringing the requirements process up, and for posting the very useful distinctions that he did. That page on confluence has given me some terminology to work with. 

However, I’m still not clear what these as yet unspecified requirements should be requirements *of*. We aren’t doing tools anymore, right? But there is a bit of confusing language around tools (“…how users want/need to use particular tools or workflows that would cut across tools/capabilities”). 

However, I think this uncertainty actually reveals something valuable: we still need some sort of quantum thing that schools can work on and that Sakai can bind together. The developers can address the infrastructure in a different way with the kernel, webservices, json, etc. And we can’t think in terms of tools anymore because “everything is much more integrated.” But the reality is that the user-facing part of Sakai needs to be divided into build-able pieces *somehow*. 

First, I am not very clear on the overall vision for what this is going to be and how it is going to be built. OK, so the community needs to decide that, but if we leave everything up to the community without deciding a framework, then schools will be developing products willy-nilly on top of the beautiful foundation that the developers have built, and we will have another mish-mash of un-usability. BTW, I would argue that the portfolio project might be what it is because it has an overall vision: to facilitate the creation of portfolios. 

Second, does that framework have quantum objects that individual developers / schools / groups of developers across schools can work on? Maybe those objects are not atomic, but they are not at the tool level. Maybe it is more at the component level: atoms (json level code?) make components, which can then be combined into a user experience with a purpose (previously known as tools). Maybe this is already being proposed, but I would hesitate to call them “widgets” because that implies that it is sort of self-contained – the whole point is that components are * combined * in interesting ways. For example, the vignette that seems to be offered up frequently is the discussion thread that gets embedded into an assignment so that students can comment for a grade. So the discussion thread is a component, the comments on the free-standing thread are a component, the grades on the comments are a component, and book where the grades are stored is a component – has this already been defined clearly? Each of these components can be independently developed *as long as they can work together in some overall plan*. If we can define the level of product that faces the users as these “components” then some group (us?) can start to decide what requirements look like, and what they should be, and then other folks can get to work on building them. Maybe some specific examples will help. One distinct advantage to the smaller size (they are much smaller than the tools we know now) is that they will hopefully be easier to build, by smaller teams of people. 

So, to summarize, thinking about what requirements are is a good thing, but also thinking about the level of object they apply to is also important. Also, imagining an overall framework(s) in which they work might be important. I am just afraid that without some direction here, the larger schools with developers (including Stanford) will just start reproducing the tool model. 

I have a bunch of functional visions / use cases that I will start to send out soon. 

Hope to be on the call next week. 

Thanks, 
Ken Romeo 
[ http://kenro.web.stanford.edu ] 
Academic Technology Specialist [ http://ats.stanford.edu ] 
Stanford Language Center [ http://language.stanford.edu ] 

-----Original Message----- 
From: pedagogy-bounces at collab.sakaiproject.org [ mailto:pedagogy-bounces at collab.sakaiproject.org ] On Behalf Of Josh Baron 
Sent: Tuesday, July 21, 2009 8:32 AM 
To: pedagogy at collab.sakaiproject.org ; portfolio at collab.sakaiproject.org 
Subject: [DG: Teaching & Learning] Sakai Teaching and Learning Call > NEWINITIATIVE DISCUSSION 

Folks, 

As some of you are aware, one of the issues that was discussed at the Sakai conference in Boston was the need to reinvent the "requirements gathering" process and find news ways to gather user input.. There appears to be a desire, over time, to have community-based user functionality needs become a target at which development work is aimed rather than the more common approach today of having development work start and then have user input feed into that work. 

A small group of interested community members have been continuing this discussion following the conference and I would like to take some time on this week's call to review/discuss some of the ideas that have surfaced. I'm hoping that those in the community who have an interest in teaching and learning issues might want to become actively involved in helping to lead and drive some new initiatives in this area. 

Some very "raw" and early thoughts are now up on Confluence at: 

http://confluence.sakaiproject.org/display/USER/A+Community+Process+for+Requirements+Gathering 

At the end of that page are links to some of the work the OSP community is doing which I and others see as a model that may work well for other projects. 

Sorry for the long e-mail but I wanted to provide some background before we head into the call tomorrow. The call and discussion are open to all so please don't hesitate to jump in even if you don't regularly participate in these calls. 

CALL IN INFORMATION: 

Calls are currently taking place on Wednesdays at 11:30 AM EST (New York, USA) each week. 

* The Conference Bridges support both Internet (e.g., Polycom, XMeeting (for MacOS), Ekiga (Linux, Windows)) and telephone connections: 
o Telephone: +1 812 856 7060 
o Internet: 156.56.240.9 

Sakai003 

* Conference Code: 386# 
* PIN: 72524# 

----------------------------- 
Joshua Baron 
Director, Academic Technology and eLearning 
Marist College 
Poughkeepsie, New York 12601 
(845) 575-3623 (work) 
Twitter: JoshBaron _______________________________________________ 
pedagogy mailing list 
pedagogy at collab.sakaiproject.org 
http://collab.sakaiproject.org/mailman/listinfo/pedagogy 

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe" 

-- 
Michael Korcuska 
Executive Director, Sakai Foundation 
mkorcuska at sakaifoundation.org 
phone: +1 510-931-6559 
mobile (US): +1 510-599-2586 
skype: mkorcuska 

_______________________________________________
pedagogy mailing list
pedagogy at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"