[DG: Teaching & Learning] Teaching & Learning] Sakai Teaching and Learning Call > NEWINITIATIVE DISCUSSION
Michael Korcuska
mkorcuska at sakaifoundation.org
Wed Jul 22 09:42:01 PDT 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/pedagogy/attachments/20090722/fadd0dbf/attachment.html
More information about the pedagogy
mailing list