[DG: User Experience] User Goals

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:

	[DG: User Experience] User Goals by Clay Fenlason-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Luke Fernandez-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@... >> 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 > > > _______________________________________________ > pedagogy mailing list > pedagogy@... > http://collab.sakaiproject.org/mailman/listinfo/pedagogy > > TO UNSUBSCRIBE: send email to pedagogy-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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by jrnorman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@... >>> 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 >> >> >> _______________________________________________ >> pedagogy mailing list >> pedagogy@... >> http://collab.sakaiproject.org/mailman/listinfo/pedagogy >> >> TO UNSUBSCRIBE: send email to pedagogy-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" _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Luke Fernandez-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> 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@...> 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@... >>>> 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 >>> >>> >>> _______________________________________________ >>> pedagogy mailing list >>> pedagogy@... >>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy >>> >>> TO UNSUBSCRIBE: send email to pedagogy-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" > _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Clay Fenlason-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Robin Hill-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by David Goodrum-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Clay Fenlason-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by nato :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Luke: What concerns me about the whole endeavor of a functional comparison of learning systems is all the major players meet some of the criteria, none of them perfectly. In other words, you won't be able to make a clear decision on a purely functional basis. What I don't see so often is institutions making decisions driven by their mission and values. If I were add to your rubric, it would include entries like: I need my online learning system design and development to be driven primarily by pedagogical needs. I need my online learning system to be around for the long haul. I need my online learning system to increase my collaboration and sharing with my peer/neighbor institutions. I need my online learning system to cost less and deliver more over time. I need my online learning system to demonstrate how it supports student learning. I need my online learning system to directly support my institutional values. I need my online learning system to reflect and augment current practices in teaching and learning. I need my online learning system to directly support local educational practices. I need the maintenance and support of my online learning system to directly enhance teaching and learning at my institution. I need my online learning system to quickly and easily reflect my local teaching and learning needs and priorities. I need my online learning system to integrate with technologies that haven't been invented yet. And so on. Given how often each institution will change learning platforms, questions like these will matter more over time than purely functional comparisons. -- Nate On Nov 4, 2009, at 11:15 AM, 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@...> > 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@...> 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@... >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> pedagogy mailing list >>>> pedagogy@... >>>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy >>>> >>>> TO UNSUBSCRIBE: send email to pedagogy-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" >> > _______________________________________________ > pedagogy mailing list > pedagogy@... > http://collab.sakaiproject.org/mailman/listinfo/pedagogy > > TO UNSUBSCRIBE: send email to pedagogy-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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by jrnorman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@...> > 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@...> 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@... >>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> pedagogy mailing list >>>> pedagogy@... >>>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy >>>> >>>> TO UNSUBSCRIBE: send email to pedagogy-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" >> _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by jrnorman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message +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" _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by jrnorman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Michael Feldstein-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@... 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@... 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@... 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 _______________________________________________ pedagogy mailing list pedagogy@... http://collab.sakaiproject.org/mailman/listinfo/pedagogy TO UNSUBSCRIBE: send email to pedagogy-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" _______________________________________________ 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" -- Michael Feldstein \| Principal Product Manager \| +1.818.817.2925 Oracle Academic Enterprise Solutions Group 23A Glendale Road, Glendale, MA 01229 _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by cdcoppola :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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@... 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@... 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@... 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 _______________________________________________ pedagogy mailing list pedagogy@... http://collab.sakaiproject.org/mailman/listinfo/pedagogy TO UNSUBSCRIBE: send email to pedagogy-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" _______________________________________________ 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" -- <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@... http://collab.sakaiproject.org/mailman/listinfo/pedagogy TO UNSUBSCRIBE: send email to pedagogy-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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Luke Fernandez-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Thanks for these insights (and my apologies for fracturing a discussion with was initiated around development concerns). I hope that (after our school’s made our next LMS decision) my present worries will prove unfounded. But currently I’m concerned that on our campus the strategic and community concerns that Nate enumerates will be eclipsed by the Edutools functional discussion which John very reasonably calls into question. On these listservs it’s easy for us to see the problem. But when one is attempting to host these conversations on campus and make them as inclusive as possible it’s a constant challenge to frame the discussion in a balanced fashion much less engage in the far more ambitious (and interesting) process of uncovering and clarifying the less conscious user desires that Clay and Michael F. make mention of. I hope that at Weber we can carry this off with at least some consideration of the great suggestions you've all raised here. Cheers, Luke On Thu, Nov 5, 2009 at 6:36 AM, Christopher D. Coppola <chris.coppola@...> wrote: > 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@...> > 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@...> 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@... > 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 > > > _______________________________________________ > pedagogy mailing list > pedagogy@... > http://collab.sakaiproject.org/mailman/listinfo/pedagogy > > TO UNSUBSCRIBE: send email to pedagogy-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" > > > > _______________________________________________ > 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" > > > -- > > > <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@... > 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" > _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by David Goodrum-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" > > > > > _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Daphnedmdp6 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 (925)348-4372 _______________________________________________ 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"
	Re: [DG: User Experience] [DG: Teaching & Learning] User Goals by Clay Fenlason-3 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 (925)348-4372 > > > > _______________________________________________ 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"

[DG: User Experience] User Goals

[DG: User Experience] User Goals

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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