[DG: Teaching & Learning] [DG: User Experience] User Goals

Thu Nov 5 09:18:25 PST 2009

Hi Clay,

I agree this idea of activity flows would be a very fertile ground to pursue.  I would suggest this be in addition to, not in place of, themese that emerged among participants so far.  

I've gone ahead and added an Activity Flow column next to the major themes column so that everyone can start exploring the idea further.

I think some of these will be alternate ways of expressing the current ones you described as more traditional, and other activity flows will involve new orientations that is important for us to uncover. I think it will remind us to make sure we get to a mental escape velocity from a tool orientation.  

This probably goes without saying, but I'll state it just to be transparent: Our and our users frustration with current tools like gradebook, forums, syllabus, resources, tests, surveys, activities, etc. is not because those ideas or even these terms are in themselves limiting (in fact instructors and students recognize these as common collections of activities); but we've come to realize that Sakai's implementation of them was too narrow.  From day one we've had faculty and students who wanted to do exactly those kinds of activities, but be able to do them more broadly and more synthetically; so they asked all the time, why can't I link my students directly from here to there? why can't I grade and give feedback to everything? why can't I put some of this in the middle of that? and so on.

Your feedback along the way has been very insightful and helpful.  And feel as free as anyone to contribute directly to the spreadsheet.

Regards - David

________________________________
From: Clay Fenlason <clay.fenlason at et.gatech.edu>
To: David Goodrum <davidgoodrum at rocketmail.com>
Cc: Robin Hill <hill at uwyo.edu>; pedagogy Learning <pedagogy at collab.sakaiproject.org>; Sakai UX <sakai-ux at collab.sakaiproject.org>
Sent: Wed, November 4, 2009 6:44:14 PM
Subject: Re: [DG: User Experience] [DG: Teaching & Learning] User Goals

I was having another thought about the themes that are emerging.
Again, they seem to be mainly functional clumpings along traditional
lines, but what if instead they wrapped around activity flows that
tend to have related patterns, pressures and frames of mind, e.g.
here's one that's (partially) temporal:

- Start of term: all the setup, syllabussy, "need to learn my
student's names" kind of things you deal with in the first few weeks
of term.
- Assigning and completing work, providing feedback: the activity
workflows that form the main body of coursework, whether as projects
in teams, or papers and assignments submitted individually
- Assessment, exams, grading and other administrivia

I can think of other functionally-oriented sets which are however less
tool-centric, e.g.

- Tracking learning and engagement
- Content authoring and publishing
- Mentoring, peer review and feedback
- Researching a topic, finding references and resources

Are there other thematic structures that might help relate goals
better? I think notions like 'content management' don't really wind
themselves organically around course activities in ways that are
especially instructive for designing for users in our settings.

~Clay

On Wed, Nov 4, 2009 at 6:11 PM, David Goodrum
<davidgoodrum at rocketmail.com> wrote:
> Hi Robin,
>
> I think that is a really fine example and I appreciate you sharing and can relate to the struggle it can take to evolve to the right level and kind of description.
>
> Of course, a goal doesn't have to be that perfect to get a row started on the document; and others can then help by putting suggested wording or alternate wording in the same cell in the matrix.
>
> This early on in trying to build this document up, it's most important to get the ideas out. A structured brainstorming exercise, one might say.
>
> We can revise and refine, sift and sort, clump and cluster, and summarize and synthesize in the next phase.
>
> Best Regards - David
>
> On Nov 4, 2009, at 2:47 PM, Robin Hill <hill at uwyo.edu> wrote:
>
> Since I take this seriously, having spent years teaching computer
> science students to separate design from implementaion, maybe I can
> illustrate the process and the difficulty with a spreadsheet entry of my
> own.
>
> ========
> From the point of view of an instructor (of a logic course):
>
> 1.  I want an Example Bank.
> Bad-- no functional description.
>
> 2.  I want a set of tagged text records in an associative array.
> Bad-- assumes a particular mechanism.
>
> 3.  I want to maintain my examples in a personal blog that allows labels
> on postings.
> Bad-- assumes a particular tool.
>
> 4.  I want examples that I can look up and use.
> Bad-- too general and vague.
>
> 5.  I want to save example of statements and reasoning when encountered
> in daily life, and I want to retrieve them based on their properties
> when composing course materials.
> Good!
> ========
>
> Clay is welcome to comment, especially if this is NOT what he has in mind.
>
>
> Clay Fenlason wrote:
> On Wed, Nov 4, 2009 at 1:15 PM, Luke Fernandez
> <luke.fernandez at gmail.com> wrote:
> I guess the question is whether there is a point where we should
> take the technological needs which our faculty articulate at face
> value.
>
> My experience is that this is most often counterproductive. I think
> this is why UCD starts with user *research* as opposed to simply
> asking the users what they want. The important considerations are
> very often the ones we are not conscious of, let alone those we're
> able to articulate well, not to mention articulate a solution that
> will also work for other people and fit well with other technical
> solutions in the same space, and so forth. It takes talent to
> synthesize sets of needs and come up with good answers, and that
> talent is not aided by leaping into implementation details too
> quickly.
>
> My underlying aim is to see us build something helpful and useful,
> not do a product comparison (and maybe that's why you are coming at
> this from a different angle). We've got designers ready to do work,
> and they're the ones with the sort of talent I indicated above. We
> need to help them cut through to what's essential, not get distracted
> by incidental detail.
>
> I think we're all familiar with conversations where someone confronts
> us with their issue, we start to raise possibilities or workarounds
> and press on details of what they're asking for, until they finally
> throw up their hands and say, "Look, I just want something that will
> <insert simple thing here> and not be a PITA, and if you can give me
> that I'll be happy." When they get to the point of putting it that
> way, then I think we're getting somewhere.
>
> ~Clay _______________________________________________ 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"
>
> --
>  Robin Hill, Ph.D.       hill at uwyo.edu       307-766-5499
>  Instructional Computing Services            http://www.uwyo.edu/ctl
>  Ellbogen Center for Teaching and Learning   University of Wyoming
>
>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
>
>

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