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

Wed Jul 22 10:20:39 PDT 2009

Since you mention the OSP pages...
http://confluence.sakaiproject.org/display/UX/Portfolio-related+vignettes

I attended the T&L call today and recognized that some of the verbs
the OSP group has described already are likely to resonate with
faculty and "classroom" scenarios. From that call, I wondered if the
OSP group is unique in its additional focus on "cross-classroom" and
departmental problems such as accreditation, advising and program
assessment. Some of those verbs certainly speak to these "other
audiences" (deans, program chairs, adviser) of the system.

I wonder about the effort needed to accommodate these other "big
picture" use cases and how funneling resources towards them will
occur. My hope is that these uses will be considered and be baked into
Sakai from the start (Contrast that to Sakai3 be primarily designed to
do an excellent job at supporting teacher/student interaction with a
second phase attempt to "bolt on" other functionality to support what
many schools may at this point consider an "edge case".)

Sean

On Wed, Jul 22, 2009 at 12:42 PM, Michael
Korcuska<mkorcuska at sakaifoundation.org> wrote:
> 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"
>