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

[David Goodrum-2]

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@...> 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@...> 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@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to
pedagogy-unsubscribe@... with a subject of
"unsubscribe"

--
 Robin Hill, Ph.D.       hill@...       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@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"



     
_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

[Clay Fenlason-3]

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@...> 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@...> 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@...> 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@...
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to
> pedagogy-unsubscribe@... with a subject of
> "unsubscribe"
>
> --
>  Robin Hill, Ph.D.       hill@...       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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>
>
>
>
>

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

+1 (I agree)

Thanks Robin

On 4 Nov 2009, at 23:11, David Goodrum 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@...> 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@...> 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@...
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to
> pedagogy-unsubscribe@... with a subject of
> "unsubscribe"
>
> --
> Robin Hill, Ph.D.       hill@...       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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"
>
>
>
>
> _______________________________________________
> pedagogy mailing list
> pedagogy@...
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

[jrnorman]

I think this is a promising line of thought in organising our  
thinking. It would be important however, to confirm that such an  
organisation of information resonates with Faculty (as I imagine it  
would).

John

On 4 Nov 2009, at 23:44, Clay Fenlason wrote:

> 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@...> 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@...> 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@...> 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@...
>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>
>> TO UNSUBSCRIBE: send email to
>> pedagogy-unsubscribe@... with a subject of
>> "unsubscribe"
>>
>> --
>>  Robin Hill, Ph.D.       hill@...       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@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>>  with a subject of "unsubscribe"
>>
>>
>>
>>
>>
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@...
>  with a subject of "unsubscribe"

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

[David Goodrum-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...>
To: David Goodrum <davidgoodrum@...>
Cc: Robin Hill <hill@...>; pedagogy Learning <pedagogy@...>; Sakai UX <sakai-ux@...>
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@...> 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@...> 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@...> 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@...

> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to
> pedagogy-unsubscribe@... with a subject of
> "unsubscribe"
>
> --
>  Robin Hill, Ph.D.       hill@...       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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>
>
>
>
>

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

[Daphnedmdp6]

Another thing we might want to keep in mind as we create themes, is at this point (at least I think) the themes are a way to help us make sense of the large amount of information we are creating.  The categories themselves will of course shape the way we think about these goals (which I think does mean we don't want to get stuck in old assumptions) but I don't think they say anything about how they end up in the application.  The activity flows on the other hand, might be quite insightful around which activities are closely related, happen together, need to talk to each other, etc.

As far as whether the categories make sense to faculty, I think it would be interesting to see if our categorizations make sense to them but I'm not sure it's critical since this is really a tool for the development team at this point.  But  it does seem more critical that the activity flows make sense to faculty, particularly if they help structure the design/framework of the application.

Just kind of talking out loud...

-Daphne

On Nov 5, 2009, at 9:18 AM, David Goodrum wrote:

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@...>
To: David Goodrum <davidgoodrum@...>
Cc: Robin Hill <hill@...>; pedagogy Learning <pedagogy@...>; Sakai UX <sakai-ux@...>
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@...> 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@...> 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@...> 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@...

> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to
> pedagogy-unsubscribe@... with a subject of
> "unsubscribe"
>
> --
>  Robin Hill, Ph.D.       hill@...       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@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>
>
>
>
>

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

Daphne Ogle

Senior Interaction Designer

University of California, Berkeley

Educational Technology Services

daphne@...

cell [phone]

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

[Clay Fenlason-3]

I suppose I was thinking of a couple different ways in which themes
might be useful:

- remind us of things we left off, as we realize that certain themes
haven't been adequately fleshed out
- coloring in the backdrop of our users' worlds, for the benefit of
designers (e.g. it seems instructive to keep in mind how the first two
weeks of term often have different pressures and expectations than the
rest of the course lifecycle, and likewise the last couple weeks)
- provide cross-cutting insight into similarities between goals and capabilities

So I'd agree that the themes needn't always be resolved to user
expressions or frames of mind, and that they are ways to help us
organize and make sense of things.

At bottom, I'm taking this spreadsheet primarily as a way for those
with expertise and insight into our user population and its activities
- people on the functional side - to codify and communicate their
acquired wisdom to a design process, and to do so in a way that will
make the most difference to that design process. It is in my mind a
supplement to the user research underway, qualitatively different but
with complementary strengths. Though in some respects this expression
of practical wisdom is less pure in its methodology than user
research, it can also be more shrewd and incisive.

I have this picture in my head:

Functional experts & User Researchers  -->  Designers  -->  UI
Developers  -->  Back End Developers

At each gap along the way there is a bridging document which serves as
two-way communication or contract.  Between back-end development and
UI development there is an API specification. Between UI Developers
and Designers there is this budding pattern/component library. And
between pedagogists, user researchers and the designers there are
personas, contextual inquiries, user journeys ... and this spreadsheet
linking basic user needs to a rich array of capabilities.

~Clay

PS David is also gently nudging us to stop just talking and help with
the doing. I'm on it, though it's sometimes hard to do without feeling
disruptive.

On Thu, Nov 5, 2009 at 5:52 PM, Daphne Ogle <daphne@...> wrote:

> Another thing we might want to keep in mind as we create themes, is at this
> point (at least I think) the themes are a way to help us make sense of the
> large amount of information we are creating.  The categories themselves will
> of course shape the way we think about these goals (which I think does mean
> we don't want to get stuck in old assumptions) but I don't think they say
> anything about how they end up in the application.  The activity flows on
> the other hand, might be quite insightful around which activities are
> closely related, happen together, need to talk to each other, etc.
> As far as whether the categories make sense to faculty, I think it would be
> interesting to see if our categorizations make sense to them but I'm not
> sure it's critical since this is really a tool for the development team at
> this point.  But  it does seem more critical that the activity flows make
> sense to faculty, particularly if they help structure the design/framework
> of the application.
> Just kind of talking out loud...
> -Daphne
>
> On Nov 5, 2009, at 9:18 AM, David Goodrum wrote:
>
> 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@...>
> To: David Goodrum <davidgoodrum@...>
> Cc: Robin Hill <hill@...>; pedagogy Learning
> <pedagogy@...>; Sakai UX
> <sakai-ux@...>
> 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@...> 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@...> 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@...> 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@...
>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>
>> TO UNSUBSCRIBE: send email to
>> pedagogy-unsubscribe@... with a subject of
>> "unsubscribe"
>>
>> --
>>  Robin Hill, Ph.D.       hill@...       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@...
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>>
>> TO UNSUBSCRIBE: send email
>> to sakai-ux-unsubscribe@... with a subject of
>> "unsubscribe"
>>
>>
>>
>>
>>
>
> _______________________________________________
> pedagogy mailing list
> pedagogy@...
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email
> to pedagogy-unsubscribe@... with a subject of
> "unsubscribe"
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> daphne@...
> cell [phone]
>
>
>
>

_______________________________________________
pedagogy mailing list
pedagogy@...
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"