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

[Kenneth Romeo]

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+Req
uirements+Gathering>
http://confluence.sakaiproject.org/display/USER/A+Community+Process+for+Requ
irements+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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20090722/fdfcf088/attachment.html