[DG: Teaching & Learning] Teaching & Learning] Sakai Teaching and Learning Call > NEWINITIATIVE DISCUSSION
John Norman
john at caret.cam.ac.uk
Wed Jul 22 09:13:08 PDT 2009
Hi Ken
I think this is a great post with some good insights, but I want to
push back. The OSP group has been trying to invent a means by which we
can talk about faculty and student needs independent from an
implementation model, by focussing on verbs like create, grade, review
(I probably have these wrong). David Goodrum has started talking about
very simple goal statements from a faculty members perspective "I need
to know who my students are" "I need to tell them what is in the
course".
While these are not enough to answer your questions on how to build
it, I think it brings a healthy focus on user goals to the high-level
discussion.
I think we will end up talking about components, possibly with a
matrix of front end and back end implementations (e.g. a single
component that integrates two services or a single service that
supports multiple components), but I prefer we articulate the user
goals clearly before diving into specifics on implementation.
Nevertheless, you are right to point out that there is a lot of work
to be done before this will become a well understood process for the
community.
HTH
John
On 22 Jul 2009, at 08: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"
More information about the pedagogy
mailing list