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

Christopher D. Coppola chris.coppola at rsmart.com
Thu Nov 5 05:36:20 PST 2009


That's a great idea Michael. The practice of making important software  
decisions based solely on written responses to questions and passive  
demonstrations simply doesn't leverage modern possibilities. Providing  
tools like the ones your suggesting to help schools take advantage of  
*using* software in the evaluation process could be very helpful.

/chris
--
rSmart
Chris Coppola | 480-463-4280
blog: coppola.rsmart.com

On Nov 5, 2009, at 5:56 AM, michael feldstein wrote:

> An interesting turn in an interesting conversation.
>
> I've been advising my local community college to take an approach to  
> platform evaluation that actually looks a little bit like usability  
> testing (though far less formal, in their case). Basically, I have  
> suggested that they pick a couple of personas (or real people that  
> fit the personas, since they don't have the staff to put in the time  
> required to construct and test against actual personas). The idea is  
> you get, say, a faculty member who just wants to do basic web  
> enhancement of a course, a faculty member who wants to teach a full  
> distance learning course using materials developed previously for  
> another platform, a non-traditional, non-tech-savvy student, and so  
> on. You don't want too many of these personas (though it is  
> preferable to have multiple examples of them if you're using real  
> people as proxies); maybe three to five. Then you work through with  
> them the tasks that they need to perform in the LMS in their roles.  
> (Again, in a resource strapped institution, the best way to do this  
> sometimes is just to pilot with these folks and elicit the right  
> feedback from them as they go.) This wouldn't cover everything, but  
> it could cover the important tasks that the critical mass of users  
> will need to perform regularly. You supplement the list by figuring  
> out which long tail tasks are important to your particular  
> institution. For example, maybe you're an engineering school, so  
> there are particular types of assignments (involving drawing,  
> solving equations, etc.) that you need to make sure a system supports.
>
> I think it would be a great service if the community (or  
> communities--we could collaborate with Moodle or ALT or Sloan-C or  
> WCET or whoever) if some kind of protocol could be created as a  
> starting point for schools who are evaluating platforms. It would  
> also be an interesting frame of reference for interrogating the  
> value of a proposed feature in a platform. Does it fulfill the needs  
> of one or more of our personas? Does it provide a new affordance  
> that would be useful to them, effectively causing us to suggest  
> expanding the evaluation protocol?
>
> I'm guessing that we could get the raw materials to construct such a  
> protocol pretty effectively by doing exit interviews with a handful  
> of schools who have piloted Sakai (or any other LMS, for that  
> matter). What were the teachers and students trying to do, and why?  
> What was important to them in terms of just being able to get  
> through the semester productively and effectively?
>
> - m
>
>
> On 11/5/2009 6:51 AM, John Norman wrote:
>>
>> The EduTools approach to purchasing decisions is widely used because
>> it gives the appearance of objectivity and is relatively easy and  
>> low-
>> cost to operate.
>>
>> In my personal opinion, this is a naive approach to purchasing that
>> explains a great deal of the subsequent unhappiness in large IT
>> deployments. Much information is lost in mapping to the 'feature
>> boxes' and the boxes themselves are often defined from a base of a
>> particular implementation.
>>
>> Given the cost of adoption, and the later costs of switching if the
>> wrong choice is made (or the cost of trying to justify the decision
>> that _was_ made), the value of investing in the process of selection
>> cannot be under-estimated.
>>
>> I genuinely believe that there is tremendous value in identifying
>> these technology-neutral faculty (and student) goals and then
>> dispassionately (and ideally with users) assessing how readily the
>> product facilitates those goals, and that this is the right approach
>> to making a choice. Unfortunately, the process can take time and
>> investment and can be challenged as open to subjective analysis. The
>> good news is that the subjective analysis may be the way in which
>> institutional culture is allowing into the decision and much of the
>> investment in investigation will be valuable and reusable when you
>> come to deploying the chosen system.
>>
>> HTH
>> John
>>
>> On 4 Nov 2009, at 18:15, Luke Fernandez wrote:
>>
>>
>>> Although the virtues of reading and writing as a means of
>>> communication have been challenged as far back as Plato I’m not sure
>>> that it’s always my bailiwick as a technologist to do that.  I guess
>>> the question is whether there is a point where we should take the
>>> technological needs which our faculty articulate at face value.   
>>> We’re
>>> trying to puzzle this out here at Weber as we try to develop a  
>>> rubric
>>> for choosing our next LMS.   More concretely, can we do it using  
>>> some
>>> derivative of the needs that are being enumerated on Clay’s
>>> spreadsheet?  Or do we resort to the more
>>> traditional/conventional/functional edutools rubric which many  
>>> schools
>>> use and which our LMS selection committee seems (perhaps at our own
>>> peril) to be gravitating towards?
>>>
>>> Cheers,
>>>
>>> Luke
>>>
>>> On Wed, Nov 4, 2009 at 10:42 AM, John Norman <john at caret.cam.ac.uk>
>>> wrote:
>>>
>>>> Well, don't I just love the academic discourse :-)
>>>>
>>>> Go gently with me because I am not a professional - but can't we
>>>> apply
>>>> the same thinking to your reading and writing example Luke? We may
>>>> talk in terms of "the goal is to read this article", but that is
>>>> vaguely absurd as a goal. The goal is to discover, absorb (and
>>>> perhaps
>>>> later critique) the _work of the author_, most conveniently done by
>>>> reading the paper. A secondary goal might be to familiarise  
>>>> yourself
>>>> with the craft of writing an academic paper so that you can become
>>>> proficient as an academic (or potential academic), but that is  
>>>> rarely
>>>> the primary goal.
>>>>
>>>> Similarly with writing. The task is to express yourself,  
>>>> demonstrate
>>>> mastery of something, communicate ideas. Imaginative instructors  
>>>> may
>>>> accept all sorts of channels/media for such expression/ 
>>>> communication,
>>>> but currently writing is one of the most common. Again a secondary
>>>> goal _may_ be proficiency in an important academic skill, but a
>>>> choice
>>>> of medium does not make use of the medium the goal.
>>>>
>>>> Can't wait to see where we go with that one :-)
>>>>
>>>> John
>>>>
>>>> On 4 Nov 2009, at 17:29, Luke Fernandez wrote:
>>>>
>>>>
>>>>> An interesting exercise....which begs the question (which I think
>>>>> Clay
>>>>> alludes to at the end of his post) as to whether pedagogical goals
>>>>> can, in all instances, be articulated in ways that are abstracted
>>>>> from
>>>>> the technologies we use for teaching and learning.
>>>>>
>>>>> A case in point is that many instructors (especially in the
>>>>> humanities) view reading and writing as fundamental skills that  
>>>>> they
>>>>> seek to impart to their students.  But reading and writing are
>>>>> themselves techniques and presume the use of the written word
>>>>> which is
>>>>> itself a technology.  In the first monday article that Michael
>>>>> circulated Lane seems to be lamenting as Thoreau did that we are
>>>>> becoming tools of our tools.  But technology is so embedded in the
>>>>> teaching of some disciplines that it would be difficult to get  
>>>>> away
>>>>> from this circularity.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Luke
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 4, 2009 at 9:55 AM, Robin Hill <hill at uwyo.edu> wrote:
>>>>>
>>>>>> I agree completely.  Articulating the pedagogical goals rather  
>>>>>> than
>>>>>> the
>>>>>> mechanics is a worthy exercise; in fact, it's the whole point.   
>>>>>> And
>>>>>> more
>>>>>> difficult than it seems, so I invite others to point out the  
>>>>>> hidden
>>>>>> assumptions in my stated objectives, as well.
>>>>>>
>>>>>>
>>>>>> Clay Fenlason wrote:
>>>>>>
>>>>>>>  I was looking at the "Learning Capabilities" spreadsheet [1]
>>>>>>> again
>>>>>>>  this morning, and was glad to see it being fleshed out. I did
>>>>>>> however
>>>>>>>  note a tendency for the "user goals" to creep into feature
>>>>>>> requests
>>>>>>>  and implementation assumptions as the list grows longer, which
>>>>>>> starts
>>>>>>>  to dilute its effectiveness. Since I warned on the T&L call a  
>>>>>>> few
>>>>>>>  weeks ago that I would be pushing back on this kind of thing, I
>>>>>>> now
>>>>>>>  feel free ;) I know it's hard to avoid the sort of language  
>>>>>>> that
>>>>>>>  assumes common web tools, since we all live and breathe in this
>>>>>>>  space, but let me urge the effort once again, and offer a few
>>>>>>>  examples to illustrate the point.
>>>>>>>
>>>>>>>  Near the top of the sheet the user goals take the form of "I  
>>>>>>> need
>>>>>>> to
>>>>>>>  see who's in my class" and "I want to learn the names of all my
>>>>>>>  students/peers." Simple and universal needs with no  
>>>>>>> technological
>>>>>>> or
>>>>>>>  functional assumptions.
>>>>>>>
>>>>>>>  Near the bottom there are now user goals like "Allow me to use
>>>>>>> common
>>>>>>>  keyboard shortcuts" and "Allow me to listen to class readings
>>>>>>> with a
>>>>>>>  screen reader." For such things it would be better to place  
>>>>>>> them
>>>>>>>  among the "capabilities" columns and try to trace them back to
>>>>>>> the
>>>>>>>  essential, non-technical need. Maybe that's going to be the  
>>>>>>> right
>>>>>>>  exercise for most of us who take these technical tools as  
>>>>>>> second
>>>>>>>  nature: first lay out what seem to us the capabilities in the
>>>>>>> middle
>>>>>>>  of the sheet, and then try to work back to the left what the
>>>>>>>  underlying, non-technical user goal is. If that can't be done
>>>>>>> that
>>>>>>>  may be a sign of something.
>>>>>>>
>>>>>>>  ~Clay
>>>>>>>
>>>>>>>  [1]
>>>>>>>
>>>>>>>
>>>>>> https://spreadsheets.google.com/ccc?key=0AlfbHxo2qpHEdHRuSnowVGMwWE9HY1MtVjFpY1dtS0E&hl=en
>>>>>>
>>>>>>>  _______________________________________________ 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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"
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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"
>>>>>
>>>> _______________________________________________
>>>> 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"
>>>>
>>>>
>>
>> _______________________________________________
>> 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"
>>
>
> -- 
>
>
> <oracle_sig_logo.gif>
> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229
> _______________________________________________
> 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"

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


More information about the pedagogy mailing list