Nabble - Sakai - User Experience

Re: [DG: User Experience] Sneak Preview: Sakai 2+3 Hybrid pre-alpha

2009-12-04T13:01:40Z

Lance,

Huge thanks for the effort you and others have been putting into this critical initiative!

Although I recognize your stressing that this is a "pre-alpha" sneak peak it is GREAT to see something tangible like this already...very encouraging stuff! Many thanks as well for taking the time to communicate this out to the community.

Josh

-----------------------------
Joshua Baron
Director, Academic Technology and eLearning
Marist College
Poughkeepsie, New York 12601
(845) 575-3623 (work)
Twitter: JoshBaron

From:	"Speelmon, Lance Day" <lance@...>
To:	Sakai-Dev Developers <sakai-dev@...>, "sakai-kernel@... sakai-kernel@..." <sakai-kernel@...>, UX Sakai <sakai-ux@...>
Date:	12/04/2009 02:48 PM
Subject:	[DG: User Experience] Sneak Preview: Sakai 2+3 Hybrid pre-alpha
Sent by:	sakai-ux-bounces@...

This video gives you the first glimpse of the hybrid integration between Sakai 2 and Sakai 3. This is a very early look and is not showing finished product, but instead enough of the user interface to begin real discussion and refinement. Many thanks to: Ian Boston, Paul Bristow, Oszkar Nagy, Christian Vuerings.

http://vimeo.com/7986913

Lance Speelmon
Scholarly Technologist
_______________________________________________ sakai-ux mailing list sakai-ux@...http://collab.sakaiproject.org/mailman/listinfo/sakai-uxTO 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"

[DG: User Experience] Sneak Preview: Sakai 2+3 Hybrid pre-alpha

2009-12-04T11:46:47Z

Lance Speelmon

Scholarly Technologist

_______________________________________________
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] Leading Design

2009-12-03T11:23:09Z

It's good to hear about all this, Keli. It might have been ideal if we'd had your work in hand when Sam started, but there's plenty of room for it to still be helpful. The target of the current phase is not to produce robust support for a wide variety of learning activities, but rather to distill an essential and fundamental interaction pattern that can be built upon. In other words, a core activity that can flex to eventually satisfy more complex cases.

So it seems to me one helpful way to use your work over the near term would be to use it to exercise what has been produced thus far: take the themes and activities gleaned from your interviews - the ones dealing with submission-feedback loops of all sorts - and work through some wireframes or paper prototypes with them. Look for points where their simple interactions could branch, or where they might look too brittle to accommodate the need. You might also point out themes you've identified that don't seem to be included, assuming they belong in that scope.

Which of course means we need to get these wireframes/prototypes into your hands. I'm hopeful they will have settled down well enough in the next week, and maybe a few of us could get together and go over them.

~Clay

On Thu, Dec 3, 2009 at 1:49 PM, <kamann@...> wrote:

Hi Clay,
As you know, this fall, Stanford embarked on the learning activities investigation with 8 other schools it was because we were concerned about two things—1) how learning activities, especially problem sets and tests, were created, taken and evaluated 2) identifying commonalities between how various types of activities (including papers, projects, and posts) were assigned by instructors and how activities and feedback was received by students. Part 2 was important because we wanted to insure that instructors and students no longer had to go to 2-3 different pages depending on the type of activity they were working with.

Thus our scope was widened to all "learning activities"--It was not clear who would build that framework or when, such as a unified dashboard view for instructors and students, but we wanted to help inform such a united framework that cut across "tool silos" before we designed and developed problem sets and tests.

In the meantime, Georgia Tech and Cambridge, along with the Sakai Foundation, hired Sam to design a simple course template in preparation for their adoption of Sakai 3 next summer. I knew this included syllabus building and viewing, but I'll admit, that until Clay mentioned the PDF posted on his blog at the t&l call yesterday, I was not aware that it would also include electronic submission and evaluation of assignments, specifically file uploads of papers (had not followed the link from his email before thanksgiving to http://sakaipm.wordpress.com/2009/11/19/leading-design/).

Yesterday, I reviewed Sam's work with much interest. As we are nearing the end of the learning activities interviews, I am happy to see that these sketches already address some major things we've been hearing.

I am hoping that our findings will be useful, both in giving supporting to design decisions as well as in suggesting adjustments. It will certainly be useful helping to map out future elaboration that might be required for assigning other types of activities. After our check in yesterday, we know we have 21 interviews from 7 schools (Texas, Berkeley, Michigan, Indiana, Virginia Tech, Wyoming, and Stanford) and I believe there will be more if Mt. Holyoke and Marist decide to proceed. Two of the schools provided 6 interviews about instructors who had their students turning in written work. We have 13 interviews about problem sets or quizzes. We also have 7 instructors who described at least 4 additional types of activities. The four student interviews we have give some additional insight.

Our original plan was to produce a write up, including personas and major themes, by the end of January. However, I did want to check in to see if there were other things we might do in light of Sam's work. Many have been asking if we were contributing to the spreadsheet and if this is continuing to drive his work, it might be worth it, but perhaps direct feedback on the design would be more useful at this stage.

Best,

Keli Amann
User Experience Specialist
Academic Computing, Stanford University

----- Original Message -----

From: "David Goodrum" <davidgoodrum@...>
To: adevans@..., "Sakai UX" <sakai-ux@...>, "pedagogy Learning" <pedagogy@...>, portfolio@...
Sent: Tuesday, December 1, 2009 7:13:17 AM GMT -08:00 US/Canada Pacific
Subject: Re: [DG: User Experience] [DG: Teaching & Learning] Leading Design

Hi Amber,

I'm encouraged to hear that some of what you have found in your contextual inquiry is already hinted at in the Learning Capabilities spreadsheet. It makes me more optimistic that these different kinds of efforts will dovetail and build on each other as the community pushes forward towards a deep understanding of how Sakai 3 needs to support teaching and learning. Any of the themes and activity flows emerging in the spreadsheet would benefit from the kind of deeper understanding that comes from contextual inquiry. I'm anxiously looking forward to the sharing that Keli Amann in a recent message said would happen by the end of January. Recently, Janice Smith has added concepts to the spreadsheet that reflect work the Portfolio community has done. There were hints in the spreadsheet already about portfolio-like capabilities, but the spreadsheet is much improved by the thorough treatment of these ideas directly from the Portfolio community. I think the rewards for finding and maintaining these broad connections between various teaching and learning concepts will be a rich set of Sakai 3 services available anywhere in the system and not just tied to specific tools or views.

Regards - David Goodrum

Director, Academic and Faculty Services
Learning Technologies
University Information Technology Services
Indiana University

From: Amber D. Evans <adevans@...>
To: Sakai UX <sakai-ux@...>
Sent: Mon, November 30, 2009 3:11:22 PM
Subject: Re: [DG: User Experience] [DG: Teaching & Learning] Leading Design

Clay,

(I'm reposting this to the larger Sakai community at your request.)

I hope that I and my group are not tragically late to this game, as we've been working with Stanford on collecting interviews as part of their Assignments and Test & Quizzes Contextual Inquiry/Fluid research design. My 3 person team and I will be spending much of today and Tuesday compiling our user persona notes form those interviews. I know that many other schools are also contributing to the Stanford UX project and may have similar questions or capability to contribute to the larger T&L Sakai 3.0 capabilities. Once done, my team and I would like to share resulting composite persona info with your group (and we have already started adding a little bit to the Google document ).

We just wanted to make sure that we didn't entirely miss the boat on this one, since the timeline is not entirely clear as to when this kind of user data will no longer be needed ... as your blog posting indicates , it's a constant on-going project, but I also recognize that at some point things have to be settled in order to move forward. We have noticed that much of what we could contribute has already been identified in the list, and only a few more ideas of value may be added (from us). If you could let me know how my colleagues and I can best make learning capabilities contributions (or other things) at this stage, it would be appreciated. Thanks!

Sincerely,
Amber D. Evans

Training and Documentation Coordinator, Online Course Systems (OCS)
= = =
Learning Technologies, Virginia Tech, 1220B Torgersen Hall (0292), Blacksburg, VA 24061
540.231.8053 | adevans@... | http://amsdiane.blogspot.com/
= = =
"Non scholae sed vitae discimus" ("We learn not for school but for life") -Seneca

On Mon, Nov 23, 2009 at 7:03 PM, David Goodrum < davidgoodrum@... > wrote:

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration.

According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

The spreadsheet is certainly not exhaustive nor complete, nor is that the intent for this phase. It currently does not necessarily reflect the best capabilities of Sakai 2.x; it does not reflect what all is missing or frustrating about Sakai 2.x; it does not reflect all of what Sakai 3 should aspire to; it doesn't even fully represent what teaching and learning goals should be supported in Sakai 3. So what's the point?

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

And it attempts to show how different levels of complexity and functional capabilities both link together and link back to a basic teaching and learning goal, hopefully expressed in everyday language.

Perhaps a bad analogy for the document would be the recent cell coverage maps... Ideally, our teaching and learning map would look like Verizon's 3G map... with nearly the whole map filled in. This brainstorming document today is more like the AT&T 3G coverage map: a lot of white space still to be filled in, but there is coverage of many core areas and outlines of many others.

For now it's a place to play out some ideas.

Got a teaching and learning idea? Something instructors want their students to do? Something students wish instructors would do? Something that develops collaboration and cooperation among students, encourages active learning, gives prompt feedback, emphasizes time on task, communicates high expectations, or respects diverse talents and ways of learning? Then add it to the brainstorm.

- David

From: Clay Fenlason < clay.fenlason@... >
To: Sakai UX < sakai-ux@... >; pedagogy Learning < pedagogy@... >
Sent: Wed, November 18, 2009 7:28:43 PM
Subject: [DG: User Experience] Leading Design

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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"

_______________________________________________
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] Leading Design

2009-12-03T10:49:12Z

Hi Clay,
As you know, this fall, Stanford embarked on the learning activities investigation with 8 other schools it was because we were concerned about two things—1) how learning activities, especially problem sets and tests, were created, taken and evaluated 2) identifying commonalities between how various types of activities (including papers, projects, and posts) were assigned by instructors and how activities and feedback was received by students. Part 2 was important because we wanted to insure that instructors and students no longer had to go to 2-3 different pages depending on the type of activity they were working with.

Thus our scope was widened to all "learning activities"--It was not clear who would build that framework or when, such as a unified dashboard view for instructors and students, but we wanted to help inform such a united framework that cut across "tool silos" before we designed and developed problem sets and tests.

In the meantime, Georgia Tech and Cambridge, along with the Sakai Foundation, hired Sam to design a simple course template in preparation for their adoption of Sakai 3 next summer. I knew this included syllabus building and viewing, but I'll admit, that until Clay mentioned the PDF posted on his blog at the t&l call yesterday, I was not aware that it would also include electronic submission and evaluation of assignments, specifically file uploads of papers (had not followed the link from his email before thanksgiving to http://sakaipm.wordpress.com/2009/11/19/leading-design/).

Yesterday, I reviewed Sam's work with much interest. As we are nearing the end of the learning activities interviews, I am happy to see that these sketches already address some major things we've been hearing.

I am hoping that our findings will be useful, both in giving supporting to design decisions as well as in suggesting adjustments. It will certainly be useful helping to map out future elaboration that might be required for assigning other types of activities. After our check in yesterday, we know we have 21 interviews from 7 schools (Texas, Berkeley, Michigan, Indiana, Virginia Tech, Wyoming, and Stanford) and I believe there will be more if Mt. Holyoke and Marist decide to proceed. Two of the schools provided 6 interviews about instructors who had their students turning in written work. We have 13 interviews about problem sets or quizzes. We also have 7 instructors who described at least 4 additional types of activities. The four student interviews we have give some additional insight.

Our original plan was to produce a write up, including personas and major themes, by the end of January. However, I did want to check in to see if there were other things we might do in light of Sam's work. Many have been asking if we were contributing to the spreadsheet and if this is continuing to drive his work, it might be worth it, but perhaps direct feedback on the design would be more useful at this stage.

Best,
Keli Amann
User Experience Specialist
Academic Computing, Stanford University

----- Original Message -----
From: "David Goodrum" <davidgoodrum@...>
To: adevans@..., "Sakai UX" <sakai-ux@...>, "pedagogy Learning" <pedagogy@...>, portfolio@...
Sent: Tuesday, December 1, 2009 7:13:17 AM GMT -08:00 US/Canada Pacific
Subject: Re: [DG: User Experience] [DG: Teaching & Learning] Leading Design

Hi Amber,

I'm encouraged to hear that some of what you have found in your contextual inquiry is already hinted at in the Learning Capabilities spreadsheet. It makes me more optimistic that these different kinds of efforts will dovetail and build on each other as the community pushes forward towards a deep understanding of how Sakai 3 needs to support teaching and learning. Any of the themes and activity flows emerging in the spreadsheet would benefit from the kind of deeper understanding that comes from contextual inquiry. I'm anxiously looking forward to the sharing that Keli Amann in a recent message said would happen by the end of January. Recently, Janice Smith has added concepts to the spreadsheet that reflect work the Portfolio community has done. There were hints in the spreadsheet already about portfolio-like capabilities, but the spreadsheet is much improved by the thorough treatment of these ideas directly from the Portfolio community. I think the rewards for finding and maintaining these broad connections between various teaching and learning concepts will be a rich set of Sakai 3 services available anywhere in the system and not just tied to specific tools or views.

Regards - David Goodrum

Director, Academic and Faculty Services
Learning Technologies
University Information Technology Services
Indiana University

From: Amber D. Evans <adevans@...>
To: Sakai UX <sakai-ux@...>
Sent: Mon, November 30, 2009 3:11:22 PM
Subject: Re: [DG: User Experience] [DG: Teaching & Learning] Leading Design

Clay,

(I'm reposting this to the larger Sakai community at your request.)

I hope that I and my group are not tragically late to this game, as we've been working with Stanford on collecting interviews as part of their Assignments and Test & Quizzes Contextual Inquiry/Fluid research design. My 3 person team and I will be spending much of today and Tuesday compiling our user persona notes form those interviews. I know that many other schools are also contributing to the Stanford UX project and may have similar questions or capability to contribute to the larger T&L Sakai 3.0 capabilities. Once done, my team and I would like to share resulting composite persona info with your group (and we have already started adding a little bit to the Google document ).

We just wanted to make sure that we didn't entirely miss the boat on this one, since the timeline is not entirely clear as to when this kind of user data will no longer be needed ... as your blog posting indicates , it's a constant on-going project, but I also recognize that at some point things have to be settled in order to move forward. We have noticed that much of what we could contribute has already been identified in the list, and only a few more ideas of value may be added (from us). If you could let me know how my colleagues and I can best make learning capabilities contributions (or other things) at this stage, it would be appreciated. Thanks!

Sincerely,
Amber D. Evans

Training and Documentation Coordinator, Online Course Systems (OCS)
= = =
Learning Technologies, Virginia Tech, 1220B Torgersen Hall (0292), Blacksburg, VA 24061
540.231.8053 | adevans@... | http://amsdiane.blogspot.com/
= = =
"Non scholae sed vitae discimus" ("We learn not for school but for life") -Seneca

On Mon, Nov 23, 2009 at 7:03 PM, David Goodrum < davidgoodrum@... > wrote:

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration.

According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

The spreadsheet is certainly not exhaustive nor complete, nor is that the intent for this phase. It currently does not necessarily reflect the best capabilities of Sakai 2.x; it does not reflect what all is missing or frustrating about Sakai 2.x; it does not reflect all of what Sakai 3 should aspire to; it doesn't even fully represent what teaching and learning goals should be supported in Sakai 3. So what's the point?

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

And it attempts to show how different levels of complexity and functional capabilities both link together and link back to a basic teaching and learning goal, hopefully expressed in everyday language.

Perhaps a bad analogy for the document would be the recent cell coverage maps... Ideally, our teaching and learning map would look like Verizon's 3G map... with nearly the whole map filled in. This brainstorming document today is more like the AT&T 3G coverage map: a lot of white space still to be filled in, but there is coverage of many core areas and outlines of many others.

For now it's a place to play out some ideas.

Got a teaching and learning idea? Something instructors want their students to do? Something students wish instructors would do? Something that develops collaboration and cooperation among students, encourages active learning, gives prompt feedback, emphasizes time on task, communicates high expectations, or respects diverse talents and ways of learning? Then add it to the brainstorm.

- David

From: Clay Fenlason < clay.fenlason@... >
To: Sakai UX < sakai-ux@... >; pedagogy Learning < pedagogy@... >
Sent: Wed, November 18, 2009 7:28:43 PM
Subject: [DG: User Experience] Leading Design

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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"

_______________________________________________
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] Leading Design

2009-12-01T07:13:17Z

Hi Amber,

I'm encouraged to hear that some of what you have found in your contextual inquiry is already hinted at in the Learning Capabilities spreadsheet. It makes me more optimistic that these different kinds of efforts will dovetail and build on each other as the community pushes forward towards a deep understanding of how Sakai 3 needs to support teaching and learning. Any of the themes and activity flows emerging in the spreadsheet would benefit from the kind of deeper understanding that comes from contextual inquiry. I'm anxiously looking forward to the sharing that Keli Amann in a recent message said would happen by the end of January. Recently, Janice Smith has added concepts to the spreadsheet that reflect work the Portfolio community has done. There were hints in the spreadsheet already about portfolio-like capabilities, but the spreadsheet is much improved by the thorough treatment of these ideas directly from the Portfolio community. I think the rewards for finding and maintaining these broad connections between various teaching and learning concepts will be a rich set of Sakai 3 services available anywhere in the system and not just tied to specific tools or views.

Regards - David Goodrum

Director, Academic and Faculty Services

Learning Technologies

University Information Technology Services

Indiana University

From: Amber D. Evans <adevans@...>
To: Sakai UX <sakai-ux@...>
Sent: Mon, November 30, 2009 3:11:22 PM
Subject: Re: [DG: User Experience] [DG: Teaching & Learning] Leading Design

Clay,

(I'm reposting this to the larger Sakai community at your request.)

I hope that I and my group are not tragically late to this game, as we've been working with Stanford on collecting interviews as part of their Assignments and Test & Quizzes Contextual Inquiry/Fluid research design. My 3 person team and I will be spending much of today and Tuesday compiling our user persona notes form those interviews. I know that many other schools are also contributing to the Stanford UX project and may have similar questions or capability to contribute to the larger T&L Sakai 3.0 capabilities. Once done, my team and I would like to share resulting composite persona info with your group (and we have already started adding a little bit to the Google document).

We just wanted to make sure that we didn't entirely miss the boat on this one, since the timeline is not entirely clear as to when this kind of user data will no longer be needed ... as your blog posting indicates, it's a constant on-going project, but I also recognize that at some point things have to be settled in order to move forward. We have noticed that much of what we could contribute has already been identified in the list, and only a few more ideas of value may be added (from us). If you could let me know how my colleagues and I can best make learning capabilities contributions (or other things) at this stage, it would be appreciated. Thanks!

Sincerely,
Amber D. Evans

Training and Documentation Coordinator, Online Course Systems (OCS)
= = =
Learning Technologies, Virginia Tech, 1220B Torgersen Hall (0292), Blacksburg, VA 24061
540.231.8053 | adevans@... | http://amsdiane.blogspot.com/
= = =
"Non scholae sed vitae discimus" ("We learn not for school but for life") -Seneca

On Mon, Nov 23, 2009 at 7:03 PM, David Goodrum <davidgoodrum@...> wrote:

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration.

According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

The spreadsheet is certainly not exhaustive nor complete, nor is that the intent for this phase. It currently does not necessarily reflect the best capabilities of Sakai 2.x; it does not reflect what all is missing or frustrating about Sakai 2.x; it does not reflect all of what Sakai 3 should aspire to; it doesn't even fully represent what teaching and learning goals should be supported in Sakai 3. So what's the point?

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

And it attempts to show how different levels of complexity and functional capabilities both link together and link back to a basic teaching and learning goal, hopefully expressed in everyday language.

Perhaps a bad analogy for the document would be the recent cell coverage maps... Ideally, our teaching and learning map would look like Verizon's 3G map... with nearly the whole map filled in. This brainstorming document today is more like the AT&T 3G coverage map: a lot of white space still to be filled in, but there is coverage of many core areas and outlines of many others.

For now it's a place to play out some ideas.

Got a teaching and learning idea? Something instructors want their students to do? Something students wish instructors would do? Something that develops collaboration and cooperation among students, encourages active learning, gives prompt feedback, emphasizes time on task, communicates high expectations, or respects diverse talents and ways of learning? Then add it to the brainstorm.

- David

From: Clay Fenlason <clay.fenlason@...>
To: Sakai UX <sakai-ux@...>; pedagogy Learning <pedagogy@...>
Sent: Wed, November 18, 2009 7:28:43 PM
Subject: [DG: User Experience] Leading Design

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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"

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

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

Re: [DG: User Experience] [DG: Teaching & Learning] Leading Design

2009-11-30T16:36:08Z

Hello
Regarding the Contextual Inquiry work (aka interviews) for Learning Activities that Amber alludes to, I wanted to give an update to the community.

The following schools responded to Stanford's initial call in September for participants: Berkeley, Indiana, Marist, Michigan, Mount Holyoke, Texas State (San Marcos), Virginia Tech, and Wyoming. There were a few other schools who were interested but were unable to participate actively.

So far, we have conducted 11 interviews among 4 schools and expect at least 3 of the remaining 5 schools to be sharing their findings in the next two weeks. We've had a few group meetings with interviewers to discuss individual findings and my colleague Jackie and I are in the process of analyzing the interview notes for themes and differences. This analysis will be used as the basis of a writeup, which will include descriptions of personas, or fictional archetypical users.

Even with only half of the schools reporting, themes and characteristics are emerging. However, before committing disembodied, half-formed statements to a spreadsheet, we want to stick to our original plan devote time to fleshing this out. We hope to finish this write up and share it with the Sakai community by the end of January. I missed one or two T&L calls, but I believe the spreadsheet is not necessarily tied to a time frame or driving immediate production, so I hope that's fine.

As it is, there are some teams on this project that have had delays that may worry that we won't take their findings into account. I strongly suspect that we'll have your user types mostly covered even if we were to start writing today, if not the detail of your workflows. However since the Stanford UX team is analyzing over the next 3 weeks before winter break, then doing writeups in January, we'll have ample time to course correct if your interviewees notes arrive in 3 week and are radically different. Workflow details will become more important starting in February, by which time you will probably be done.

We are having our final meeting tomorrow for interviewers to share results. We plan to schedule a meeting in 7-8 weeks to share our analysis with the wider community. We're hoping that even schools that didn't participate in interviews will recognize the user types we describe, even if the person you know is slightly different (teaching French rather than Spanish), but will add user types if necessary.

Keli Amann
User Experience Specialist
Academic Computing, Stanford University

----- Original Message -----
From: "Amber D. Evans" <adevans@...>
To: "Clay Fenlason" <clay.fenlason@...>
Cc: "Sakai UX" <sakai-ux@...>, "pedagogy Learning" <pedagogy@...>, "Samantha Blevins" <sjblevin@...>, "Teggin Summers" <techambe@...>, "keli amann" <keli.amann@...>, "Jacqueline Mai" <jamai@...>
Sent: Monday, November 30, 2009 8:39:01 AM GMT -08:00 US/Canada Pacific
Subject: Re: [DG: Teaching & Learning] [DG: User Experience] Leading Design

Clay,

(I'm reposting this to the larger Sakai community at your request.)

I hope that I and my group are not tragically late to this game, as we've been working with Stanford on collecting interviews as part of their Assignments and Test & Quizzes Contextual Inquiry/Fluid research design. My 3 person team and I will be spending much of today and Tuesday compiling our user persona notes form those interviews. I know that many other schools are also contributing to the Stanford UX project and may have similar questions or capability to contribute to the larger T&L Sakai 3.0 capabilities. Once done, my team and I would like to share resulting composite persona info with your group (and we have already started adding a little bit to the Google document ).

We just wanted to make sure that we didn't entirely miss the boat on this one, since the timeline is not entirely clear as to when this kind of user data will no longer be needed ... as your blog posting indicates , it's a constant on-going project, but I also recognize that at some point things have to be settled in order to move forward. We have noticed that much of what we could contribute has already been identified in the list, and only a few more ideas of value may be added (from us). If you could let me know how my colleagues and I can best make learning capabilities contributions (or other things) at this stage, it would be appreciated. Thanks!

Sincerely,
Amber D. Evans

Training and Documentation Coordinator, Online Course Systems (OCS)
= = =
Learning Technologies, Virginia Tech, 1220B Torgersen Hall (0292), Blacksburg, VA 24061
540.231.8053 | adevans@... | http://amsdiane.blogspot.com/
= = =
"Non scholae sed vitae discimus" ("We learn not for school but for life") -Seneca

On Mon, Nov 23, 2009 at 7:03 PM, David Goodrum < davidgoodrum@... > wrote:

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration.

According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

The spreadsheet is certainly not exhaustive nor complete, nor is that the intent for this phase. It currently does not necessarily reflect the best capabilities of Sakai 2.x; it does not reflect what all is missing or frustrating about Sakai 2.x; it does not reflect all of what Sakai 3 should aspire to; it doesn't even fully represent what teaching and learning goals should be supported in Sakai 3. So what's the point?

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

And it attempts to show how different levels of complexity and functional capabilities both link together and link back to a basic teaching and learning goal, hopefully expressed in everyday language.

Perhaps a bad analogy for the document would be the recent cell coverage maps... Ideally, our teaching and learning map would look like Verizon's 3G map... with nearly the whole map filled in. This brainstorming document today is more like the AT&T 3G coverage map: a lot of white space still to be filled in, but there is coverage of many core areas and outlines of many others.

For now it's a place to play out some ideas.

Got a teaching and learning idea? Something instructors want their students to do? Something students wish instructors would do? Something that develops collaboration and cooperation among students, encourages active learning, gives prompt feedback, emphasizes time on task, communicates high expectations, or respects diverse talents and ways of learning? Then add it to the brainstorm.

- David

From: Clay Fenlason < clay.fenlason@... >
To: Sakai UX < sakai-ux@... >; pedagogy Learning < pedagogy@... >
Sent: Wed, November 18, 2009 7:28:43 PM
Subject: [DG: User Experience] Leading Design

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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"

_______________________________________________
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] Leading Design

2009-11-30T12:11:22Z

On Mon, Nov 23, 2009 at 7:03 PM, David Goodrum <davidgoodrum@...> wrote:

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration.

According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

The spreadsheet is certainly not exhaustive nor complete, nor is that the intent for this phase. It currently does not necessarily reflect the best capabilities of Sakai 2.x; it does not reflect what all is missing or frustrating about Sakai 2.x; it does not reflect all of what Sakai 3 should aspire to; it doesn't even fully represent what teaching and learning goals should be supported in Sakai 3. So what's the point?

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

And it attempts to show how different levels of complexity and functional capabilities both link together and link back to a basic teaching and learning goal, hopefully expressed in everyday language.

Perhaps a bad analogy for the document would be the recent cell coverage maps... Ideally, our teaching and learning map would look like Verizon's 3G map... with nearly the whole map filled in. This brainstorming document today is more like the AT&T 3G coverage map: a lot of white space still to be filled in, but there is coverage of many core areas and outlines of many others.

For now it's a place to play out some ideas.

Got a teaching and learning idea? Something instructors want their students to do? Something students wish instructors would do? Something that develops collaboration and cooperation among students, encourages active learning, gives prompt feedback, emphasizes time on task, communicates high expectations, or respects diverse talents and ways of learning? Then add it to the brainstorm.

- David

From: Clay Fenlason <clay.fenlason@...>
To: Sakai UX <sakai-ux@...>; pedagogy Learning <pedagogy@...>
Sent: Wed, November 18, 2009 7:28:43 PM
Subject: [DG: User Experience] Leading Design

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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"

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

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

Re: [DG: User Experience] Discussion Widget Question

2009-11-26T06:16:39Z

Hi Adrian,

There is some code who should fill up that settings view. (around line
790 in discussion.js)
If it isn't doing that right now, then that is a bug.

If it should work this way is a question I leave up to the list to
answer. :)

Regards,

Simon

(Forgot to include the list)

On 26 Nov 2009, at 11:56, Adrian Fish wrote:

> Hi All,
>
> I have a query about the settings panel for the discussions widget.
> When you click on the settings option on a discussions widget
> placement, would you expect to see the subject and body of the
> actual discussion represented by the widget just clicked? Currently
> it doesn't seem to do this, in fact the settings panel is what I'd
> expect to see in a 'Create a new discussion scenario'.
>
> Cheers,
>
> Adrian.
>
> --
> ==================================
> Adrian Fish
> Software Engineer
> Centre for e-Science
> Bowland Tower South C Floor
> Lancaster University
> Lancaster
> LA1 4YW
> email: a.fish@...
>
> http://confluence.sakaiproject.org/display/YAFT/Yaft
> http://confluence.sakaiproject.org/display/BLOG/Home
> http://confluence.sakaiproject.org/display/AGORA/Home
>
> <a_fish.vcf>_______________________________________________
> 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] Discussion Widget Question

2009-11-26T03:56:20Z

Hi All,

I have a query about the settings panel for the discussions widget. When
you click on the settings option on a discussions widget placement,
would you expect to see the subject and body of the actual discussion
represented by the widget just clicked? Currently it doesn't seem to do
this, in fact the settings panel is what I'd expect to see in a 'Create
a new discussion scenario'.

Cheers,

Adrian.

--
==================================
Adrian Fish
Software Engineer
Centre for e-Science
Bowland Tower South C Floor
Lancaster University
Lancaster
LA1 4YW
email: a.fish@...

http://confluence.sakaiproject.org/display/YAFT/Yaft
http://confluence.sakaiproject.org/display/BLOG/Home
http://confluence.sakaiproject.org/display/AGORA/Home

[a_fish.vcf]

begin:vcard fn:Adrian Fish n:Fish;Adrian org:Lancaster University;Centre for e-Science adr:Lancaster University;;Bowland Tower South C Floor;Lancaster;;LA1 4YT;United Kingdom email;internet:a.fish@... title:Software Engineer url:http://agora.lancs.ac.uk version:2.1 end:vcard

[DG: User Experience] Saving parameters on register.

2009-11-25T02:38:08Z

I've created a patch that makes sure that single valued parameters (like firstName, lastName, email) who are sent when a user registers end up as
single valued properties on the authprofile node. See [1]

Since the UI saves the firstName and lastName in the edit profile as a single valued property
anyway, it makes more sense to do it on register as well.

I'm not entirely sure how much work it would be to get this properly working in the UI.
Sometimes checks are done to see if it is an Array or a String, but not always (I think?)

If we have one way of storing these properties, sorting of users would be much easier as well.

wdyt?

Simon

[1] http://jira.sakaiproject.org/browse/KERN-430

_______________________________________________
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] [Portfolio] OSP Community contribution to the Learning Capabilities Google document

2009-11-24T13:31:18Z

Hi Janice,

It's great to see the OSP ideas being clearly articulated in the Learning Capabilities page. It's a great addition!

- David

From: janice.smith <janice.smith@...>
To: portfolio@...
Sent: Tue, November 24, 2009 1:22:53 PM
Subject: [Portfolio] OSP Community contribution to the Learning Capabilities Google document

Hi David

At our Monday meeting, I was asked by the OSP Community to translate our Confluence page on Portfolio-related Vignettes for addition to the Learning Capabilities page. Given that the categories across our two pages are very different, I am rewriting and reorganizing and will transfer the results all at one time today or tomorrow. We recognize that the many portfolio-like items you list below are already in the document and that some of what we suggest will be somewhat redundant, but choose to add our approximately twenty items rather than edit what is already there. Thank you for encouraging us to contribute!

Janice

Janice A. Smith, Ph.D.
2009 Sakai Foundation Fellow
Three Canoes
1204 Laurel Avenue
Saint Paul, Minnesota 55104, USA
651-642-9069, 207-841-6262 (cell)
janice.smith@...
jasmith@...

Subject: [Portfolio] Learning Capabilities spreadsheet
From: David Goodrum <davidgoodrum@...>
Date: Tue, 24 Nov 2009 07:40:37 -0800 (PST)
To: portfolio@...

------------------------- Contents -------------------------

There's been an increasing awareness of the brainstorming activity reflected in the Learning Capabilities spreadsheet:

http://spreadsheets.google.com/ccc?key=0AlfbHxo2qpHEdHRuSnowVGMwWE9HY1MtVjFpY1dtS0E&hl=en

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration. According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

The spreadsheet is certainly not exhaustive nor complete, nor is that the intent for this phase. It currently does not necessarily reflect the best capabilities of Sakai 2.x; it does not reflect what all is missing or frustrating about Sakai 2.x; it does not reflect all of what Sakai 3 should aspire to; it doesn't even fully represent what teaching and learning goals should be supported in Sakai 3. So what's the point?

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

And it attempts to show how different levels of complexity and functional capabilities both link together and link back to a basic teaching and learning goal, hopefully expressed in everyday language.

Perhaps a bad analogy for the document would be the recent cell coverage maps... Ideally, our teaching and learning map would look like Verizon's 3G map... with nearly the whole map filled in. This brainstorming document today is more like the AT&T 3G coverage map: a lot of white space still to be filled in, but there is coverage of many core areas and outlines of many others.

For now it's a place to play out some ideas.

Got a teaching and learning idea? Something instructors want their students to do? Something students wish instructors would do? Something that develops collaboration and cooperation among students, encourages active learning, gives prompt feedback, emphasizes time on task, communicates high expectations, or respects diverse talents and ways of learning? Then add it to the brainstorm.

And here are some ideas/language already in the document that seem related to Portfolio concepts (including an explicit reference/link in the last item to the important vignette development the OSP group has been refining):

Current row 9 "I need to track student learning"

I need to track student learning

Show details of expectations and levels of accomplishment Provide guidance, examples, rubrics. Link to portfolios of previous students of this course (with permission)

Publish and subscribe to goals; map heirarchical relationships between goals
Organize and track lifelong learning for the individual and the institution; track student progress over their entire academic career

Current row 19 "I want to give my students grades"

I want to provide feedback on submitted work; I want students to review and critique each other's work as well.

Feedback / comment with rich-text formatting and attachments for any object
Any object can receive a comment or grade; Grouping of objects (e.g., portfolio) that receive feedback; both open and structured feedback

Grades are a special case of feedback and non-numerical assessment should be supported; Instructor feedback; self feedback; peer feedback; external to class review; external to system review; multitude of permissions for who can see what

Current row 41 "I want to represent specific campus/school/program learning goals (and associated grading/assessment rubrics) as a framework for a large set of courses."

Goals and rubrics can be a way for an institution to differentiate itself through standards for excellence from other institutions and for showing that program X complies with Association Y's expectations.

Some goals and rubrics are rather specific must be approved by an "assessment coordinator" for educational QA purposes as part of a larger assessment system strategy. Changing the assessment/rubric in this case involves more than just an individual instructor.

Goals created by others (the individual student or instructor or a particular program) can be mapped to larger campus/school goals. Some rubrics may be general purpose rubrics that are NOT tied to an assessment, but the dissemination of these approved rubrics may be a strategy of an institution to push forward an agenda of best practice for assessment by providing a handy reference library of general purpose writing, mathematics and science rubrics (for example). While the choice whether or not to use one of these "off the shelf" rubrics (and which one) is left to the teacher, providing some information to the teacher about the schools expectations of its students at different stages (and perhaps suggesting an appropriate rubric for this grade level/stage of development) would make this service more valuable.

Some items in the library of "off the shelf" goals and rubrics are merely starting points. There is not a priority to ensure that everyone is doing assessment the exact same way. When a teacher uses one of these rubrics, they can easily edit the performance indicators to suit their needs and create a new rubric, just for their new assignment. Goals and rubrics can be shared with others. This is a bottom up approach to establishing "best practice". As the teachers create their own rubrics against goals, they have the opportunity to publish them as part of the "reusable" library so other teachers can use/edit/republish them.

[note that this was largely copied and paste from a posting Sean Keesler made to one of the lists]

Current line 43 "I want to encourage and at times require students to reflect on the task I have them doing.

I want to add a guided metacognitive aspect to tasks I give students.

This might be an open ended reflection. But this might be also a structured reflection, for example ask them to rate their confidence in a task (or even for an individual question I've asked them), or to classify their contribution to a task or discussion (e.g., claim, reason, evidence, warrant, or acknowledgement/response).

Current line 52 "I want to create an analytic rubric or holistic, share it with my students, and use it to grade and/or evaluate an open-ended assignment"

Tool for generating analytic and holstic rubrics. Instructor enters criteria, rating scale, and characterisics of work associated with each point on the scale. Rubric can be attached to any example of student work and isntructor can opt to display to students before submission. To grade or evaluate, instructor clicks or selects the rating for each criterion. Students see a read only version of the rubric with the instructions rating selections.

Instructors can easily classify and share rubrics with specific colleagues, their department, program, campus , and/or the public. Rubrics can be associated with learning outcomes/goals.

Current line 56 "I want my students to keep a log or journal on their experience in this course."

Current line 70 "I want to continue to have access to all of my work products after the class and even after I graduate."

Current line 72 "Support for wide range of portfolio related activities: Guide, Collect, Reflect, Tag, Associate, Evaluate, Share, Report, Flow, Assess, Present, Customize, Preserve, Document, Collaborate, Own, Empower, Re-purpose, Port, Express, Migrate"

See Portfolio vignettes:
http://confluence.sakaiproject.org/display/UX/Portfolio-related+vignettes

So please feel free to add to or expand something already there. Or at least take a look and see how this brainstorming exercise is evolving. This activity may help to identify functions that various Sakai groups are exploring.

Regards - David

Re: [DG: User Experience] Leading Design

2009-11-23T16:03:51Z

It's been interesting to see the level of collaboration the document has seen and how it has evolved because of that collaboration.

According to Google docs, there's been at least 15 collaborators on the document... likely more, since no login is required to edit it -- it is a totally open brainstorming document right now.

With 60+ rows right now, it begins to represent a fair cross section of many ambitions Sakai 3 perhaps ought to have in the teaching and learning space.

For now it's a place to play out some ideas.

- David

From: Clay Fenlason <clay.fenlason@...>
To: Sakai UX <sakai-ux@...>; pedagogy Learning <pedagogy@...>
Sent: Wed, November 18, 2009 7:28:43 PM
Subject: [DG: User Experience] Leading Design

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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] Exploited ignorance

2009-11-23T08:13:26Z

Just saw, just before hitting the send button, that Oszkar posted
something on the list so there could be some overlapping in my notes:

Last week I did some work on the prototype templates [1]. I completely
reorganised the pages so it is possible that some links are broken on
[2].

> The bulk of the activity right now seems to be focussed on the
> introduction of "Prototype templates," though many of them still seem
> to just be screenshots so far, like patterns without descriptive
> information.

Currently only the discussion & messaging section should have
screenshots. The main reason for this is that Oszkar was still making
some
design modifications to the "compact view templates" from Adrian [3].
So I
didn't want to do the conversion yet. All the other prototypes (16 out
of 18)
should have appropriate HTML and CSS. I can agree that some look like
screenshots but they are iframes.

> Where are the prototype templates coming from? By a reasoned
> deconstruction of what sits on 3akai.sakaiproject.org?

I do get most of my HTML and CSS from http://3akai.sakaiproject.org.
This process also gives me a view of which CSS needs to be
re-factored in the near future.

As a last note I would also like to mention some things that are
currently
spinning in my head:

1) To make the prototype library more useful for other I was thinking of
providing the user with a zip file that would contain the latest
prototypes with their appropriate CSS/HTML and images.

2) Hosting: currently we upload the prototype pages & files to [4].
The main problem with this solution is that as soon as we redeploy
Sakai3 on that server, I'll need to re-upload all the files. Maybe
we could use one of servers hosted by the foundation for this purpose?

[1] http://confluence.sakaiproject.org/display/UX/Prototype+Templates
[2] http://confluence.sakaiproject.org/display/UX/Patterns+and+templates
[3] http://github.com/oszkarnagy/3akai-ux/commit/87f3f80f089140a2e2f23012de2f04a275e0ebd7
[4] http://3akai.sakaiproject.org/dev/_patterns/

On 23 Nov 2009, at 15:49, Oszkar Nagy wrote:

> Hi Clay,
>
> Probably the best person to answer the questions about the Pattern
> Library is Sam, but nevertheless I'll go ahead and try to explain a
> bit,
> to the best of my knowledge and interpretation, based on Sam's brief.
>
>
> Categories:
> I am still not sure about what Sam wants the final categories to be,
> but
> there are 2 candidates as far as I know:
>
> 1
> Primary user groups (as it is now, Students, Instructors,
> Educators/Researchers ) which is based on a distinction that there are
> basic UI elements (Buttons, Layouts, Tabs etc...) which will build
> up a
> higher level pattern, aimed to solve a certain UI problem to a certain
> group (Sites widget for example)
>
> 2
> Another approach which he sent us was a more general categorization,
> which structure can be found here:
> http://confluence.sakaiproject.org/display/UX/Prototype+Templates
> which
> is based upon his design master file categories.
>
> Not sure which will be the final one though.
>
>
>
> Patterns:
> A source for a pattern as far as I understand should be coming from
> Sam
> and Flow Interactive. Not sure though whether the the data would come
> from a current UI taken from the latest UX version, or would be
> re-thinked and we would perfect some of the examples which are there.
> Also you are right that, we only have worked a little bit on this
> from a
> technical point of view (ripping out some standalone HTML and CSS) and
> creating a start to illustrate Sam's vision, but no real content is
> placed in it so far. My personal view is that we should only have
> discussed and locked down designs in the pattern library, which
> could be
> used as a base for technical CSS cleanup and organization as well.
>
>
>
> HTML - CSS examples (prototypes):
> These would serve as a basis for rapid prototyping in HTML. Sam thinks
> we could do faster prototyping straight in HTML. The idea would be to
> take lower level elements and build higher level constructs by cutting
> and pasting together HTML and CSS from the patterns: Grab a layout,
> grab
> tabs, grab buttons, etc.. to create a page design and almost a
> prototype
> as well at the same time. As far as I know the prototype would reflect
> faithfully a certain pattern, and wouldn't drift from the design. One
> question about this is how we share prototypes for wider discussion,
> and
> stakeholder feedback as implied in the proposed design cycle. Another
> one would be the state of current UI elements, ie do we take those as
> base level or do we need to re-visit them? Not sure how this would
> work
> in practice, especially with a lot of dependency CSS.
>
>
>
> Sitemap:
> This ultimately would be an interactive site-map highlighting the
> pages
> within Sakai which uses a certain pattern. We have code for this, but
> still no final hosting for it (also links will need updating from the
> pattern pages).
>
>
>
> I am pretty sure there are opportunities for other people to be
> involved, but again Sam would probably be a better person to ask as he
> has a clearer view of the process I am pretty sure.
>
> Hope this helps a bit,
> Oszkar
>
>
>
>
>
> On 23/11/2009 13:56, Clay Fenlason wrote:
>> I've been wanting to highlight the component/pattern library starting
>> to emerge in the UX wiki space [1] for Sakai 3, but as I was
>> reviewing
>> it again this morning I was reminded that it's not clear to me what's
>> happening or how it will be used. Happy coincidence! I can now ask my
>> embarrassed questions (to Oszkar and Christian) behind a mask of
>> feigned naivety for the benefit of others. Selfishness that serves.
>>
>> There is a FAQ [2], but it seems to just be a placeholder for the
>> moment. This might be something I can help with.
>>
>> The first section of what seems to be the introductory page [1] is
>> broken down by user, and that looks like a good start. Within those
>> regions it looks like components are identified particular to them,
>> from three different angles: a) pattern, b) prototype, and c)
>> sitemap.
>> The latter (c) looks like it will eventually be a way to locate
>> these
>> components within the application hierarchy, but it looks like it's
>> set up in such a way that I'd have to discover them serendipitously
>> by
>> clicking around - but it may just be too soon to assess what the
>> sitemap will do. The pattern (a) looks like a wireframe with some
>> description of how it's used and the problem it's trying to solve.
>> The
>> prototype (b) includes actual HTML and CSS for reuse, which seems
>> very
>> helpful to UI developers.
>>
>> Then beneath the breakdown by users there are "basic components,"
>> presumably generic in how they are not tailored to solving problems
>> for particular personas.
>>
>> The bulk of the activity right now seems to be focussed on the
>> introduction of "Prototype templates," though many of them still seem
>> to just be screenshots so far, like patterns without descriptive
>> information. I'm assuming they'll progressively have their HTML and
>> CSS filled in as well - have I got that right? Also, the focus on the
>> prototypes seems to suggest that the work is mostly technical for the
>> moment, or that's the overall impression - components are seeing more
>> attention than the design justification of their patterns.
>>
>> Where are the prototype templates coming from? By a reasoned
>> deconstruction of what sits on 3akai.sakaiproject.org?
>>
>> What is the connection between a pattern and a prototype? Is a
>> prototype a faithful implementation of a pattern, in which case why
>> separate them - does that risk having the implementation drift from
>> the design? Or is it rather a distinction of process, whereby the
>> pattern needs to be reviewed and tested up until a point where it
>> makes sense to do the work to turn it into a prototype?
>>
>> Is there an opportunity here for others to get involved, say, by
>> fleshing out the 'pattern' side of the library?
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/bQUAB
>> [2] http://confluence.sakaiproject.org//x/owYAB
>> _______________________________________________
>> 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] Exploited ignorance

2009-11-23T07:49:41Z

Hi Clay,

Probably the best person to answer the questions about the Pattern
Library is Sam, but nevertheless I'll go ahead and try to explain a bit,
to the best of my knowledge and interpretation, based on Sam's brief.

Categories:
I am still not sure about what Sam wants the final categories to be, but
there are 2 candidates as far as I know:

1
Primary user groups (as it is now, Students, Instructors,
Educators/Researchers ) which is based on a distinction that there are
basic UI elements (Buttons, Layouts, Tabs etc...) which will build up a
higher level pattern, aimed to solve a certain UI problem to a certain
group (Sites widget for example)

2
Another approach which he sent us was a more general categorization,
which structure can be found here:
http://confluence.sakaiproject.org/display/UX/Prototype+Templates which
is based upon his design master file categories.

Not sure which will be the final one though.

Patterns:
A source for a pattern as far as I understand should be coming from Sam
and Flow Interactive. Not sure though whether the the data would come
from a current UI taken from the latest UX version, or would be
re-thinked and we would perfect some of the examples which are there.
Also you are right that, we only have worked a little bit on this from a
technical point of view (ripping out some standalone HTML and CSS) and
creating a start to illustrate Sam's vision, but no real content is
placed in it so far. My personal view is that we should only have
discussed and locked down designs in the pattern library, which could be
used as a base for technical CSS cleanup and organization as well.

HTML - CSS examples (prototypes):
These would serve as a basis for rapid prototyping in HTML. Sam thinks
we could do faster prototyping straight in HTML. The idea would be to
take lower level elements and build higher level constructs by cutting
and pasting together HTML and CSS from the patterns: Grab a layout, grab
tabs, grab buttons, etc.. to create a page design and almost a prototype
as well at the same time. As far as I know the prototype would reflect
faithfully a certain pattern, and wouldn't drift from the design. One
question about this is how we share prototypes for wider discussion, and
stakeholder feedback as implied in the proposed design cycle. Another
one would be the state of current UI elements, ie do we take those as
base level or do we need to re-visit them? Not sure how this would work
in practice, especially with a lot of dependency CSS.

Sitemap:
This ultimately would be an interactive site-map highlighting the pages
within Sakai which uses a certain pattern. We have code for this, but
still no final hosting for it (also links will need updating from the
pattern pages).

I am pretty sure there are opportunities for other people to be
involved, but again Sam would probably be a better person to ask as he
has a clearer view of the process I am pretty sure.

Hope this helps a bit,
Oszkar

On 23/11/2009 13:56, Clay Fenlason wrote:

> I've been wanting to highlight the component/pattern library starting
> to emerge in the UX wiki space [1] for Sakai 3, but as I was reviewing
> it again this morning I was reminded that it's not clear to me what's
> happening or how it will be used. Happy coincidence! I can now ask my
> embarrassed questions (to Oszkar and Christian) behind a mask of
> feigned naivety for the benefit of others. Selfishness that serves.
>
> There is a FAQ [2], but it seems to just be a placeholder for the
> moment. This might be something I can help with.
>
> The first section of what seems to be the introductory page [1] is
> broken down by user, and that looks like a good start. Within those
> regions it looks like components are identified particular to them,
> from three different angles: a) pattern, b) prototype, and c) sitemap.
> The latter (c) looks like it will eventually be a way to locate these
> components within the application hierarchy, but it looks like it's
> set up in such a way that I'd have to discover them serendipitously by
> clicking around - but it may just be too soon to assess what the
> sitemap will do. The pattern (a) looks like a wireframe with some
> description of how it's used and the problem it's trying to solve. The
> prototype (b) includes actual HTML and CSS for reuse, which seems very
> helpful to UI developers.
>
> Then beneath the breakdown by users there are "basic components,"
> presumably generic in how they are not tailored to solving problems
> for particular personas.
>
> The bulk of the activity right now seems to be focussed on the
> introduction of "Prototype templates," though many of them still seem
> to just be screenshots so far, like patterns without descriptive
> information. I'm assuming they'll progressively have their HTML and
> CSS filled in as well - have I got that right? Also, the focus on the
> prototypes seems to suggest that the work is mostly technical for the
> moment, or that's the overall impression - components are seeing more
> attention than the design justification of their patterns.
>
> Where are the prototype templates coming from? By a reasoned
> deconstruction of what sits on 3akai.sakaiproject.org?
>
> What is the connection between a pattern and a prototype? Is a
> prototype a faithful implementation of a pattern, in which case why
> separate them - does that risk having the implementation drift from
> the design? Or is it rather a distinction of process, whereby the
> pattern needs to be reviewed and tested up until a point where it
> makes sense to do the work to turn it into a prototype?
>
> Is there an opportunity here for others to get involved, say, by
> fleshing out the 'pattern' side of the library?
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/bQUAB
> [2] http://confluence.sakaiproject.org//x/owYAB
> _______________________________________________
> 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] Exploited ignorance

2009-11-23T05:56:07Z

I've been wanting to highlight the component/pattern library starting
to emerge in the UX wiki space [1] for Sakai 3, but as I was reviewing
it again this morning I was reminded that it's not clear to me what's
happening or how it will be used. Happy coincidence! I can now ask my
embarrassed questions (to Oszkar and Christian) behind a mask of
feigned naivety for the benefit of others. Selfishness that serves.

There is a FAQ [2], but it seems to just be a placeholder for the
moment. This might be something I can help with.

The first section of what seems to be the introductory page [1] is
broken down by user, and that looks like a good start. Within those
regions it looks like components are identified particular to them,
from three different angles: a) pattern, b) prototype, and c) sitemap.
The latter (c) looks like it will eventually be a way to locate these
components within the application hierarchy, but it looks like it's
set up in such a way that I'd have to discover them serendipitously by
clicking around - but it may just be too soon to assess what the
sitemap will do. The pattern (a) looks like a wireframe with some
description of how it's used and the problem it's trying to solve. The
prototype (b) includes actual HTML and CSS for reuse, which seems very
helpful to UI developers.

Then beneath the breakdown by users there are "basic components,"
presumably generic in how they are not tailored to solving problems
for particular personas.

The bulk of the activity right now seems to be focussed on the
introduction of "Prototype templates," though many of them still seem
to just be screenshots so far, like patterns without descriptive
information. I'm assuming they'll progressively have their HTML and
CSS filled in as well - have I got that right? Also, the focus on the
prototypes seems to suggest that the work is mostly technical for the
moment, or that's the overall impression - components are seeing more
attention than the design justification of their patterns.

Where are the prototype templates coming from? By a reasoned
deconstruction of what sits on 3akai.sakaiproject.org?

What is the connection between a pattern and a prototype? Is a
prototype a faithful implementation of a pattern, in which case why
separate them - does that risk having the implementation drift from
the design? Or is it rather a distinction of process, whereby the
pattern needs to be reviewed and tested up until a point where it
makes sense to do the work to turn it into a prototype?

Is there an opportunity here for others to get involved, say, by
fleshing out the 'pattern' side of the library?

~Clay

[1] http://confluence.sakaiproject.org//x/bQUAB
[2] http://confluence.sakaiproject.org//x/owYAB
_______________________________________________
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] JavaScript event based development (Sakai 3)

2009-11-22T06:47:58Z

An open question to which I don't have an answer, would be whether to address such questions to the Fluid list? We might start by asking if such issues are welcome there and report back on this list the status of any developing thoughts...

Just a suggestion, but potentially it would aid with convergence and create an opportunity to air Sakai issues with a wider set of expertise.

John

On 18 Nov 2009, at 19:28, Eli Cochran wrote:

> Oszkar,
> You've hit on something that was itching the back of my brain while I was writing my rant on events.
>
> One of the challenges with multiple binding to the same event is having control, or the sense of control, over the order that each listener will be triggered and what to do in those situations where components really are intertwined.
>
> I like your solution of chaining to solve this problem. Although it's worth asking first if there are ways to reduce the dependences before chaining becomes necessary.
>
> Another tricky area is when listeners need to respond to each other or prevent or modify the action of the firer.
>
> Fluid got around this in their library with a concept of "preventable" events. (I put this forward as an example of a concept, and not to push "the Fluid way"). This allows Fluid events to behave like browser events with the ability to stopPropogation and return a boolean to the caller to stop the action.
>
> (Aside: To help keep our heads clear, Fluid uses a naming convention separating our events into "before events" (onPageLoad) and "after events" (afterPageLoad). I highly recommend this convention.)
>
> - Eli
>
>
>
>
> On Nov 18, 2009, at 10:53 AM, Oszkar Nagy wrote:
>
>> 2. Chaining:
>>
>> LoadControl was a result of a site.js cleanup iteration, where I wanted
>> to formulate a clear(er) view of what is happening when, and make the
>> code more readable by seeing the chain of events. The proper way to do
>> this kind of thing is through events IMHO, but we haven't reached that
>> stage yet. But even with events I think it's important to always
>> organise the code in such way that everybody has an instant
>> understanding of the order of events, which perhaps raises questions
>> about the need of a "chainer" where you could simply chain things up and
>> wouldn't need to add callbacks within callbacks within callbacks (as in
>> site_admin.js), but use something like this:
>>
>> sakai.lib.util.chainer.init();
>>
>> sakai.lib.util.chainer.add(load_site_data, param1, param2);
>> sakai.lib.util.chainer.add(load_profile_data, param1);
>> sakai.lib.util.chainer.add(display_profile_data);
>> sakai.lib.util.chainer.add(render_widgets);
>>
>> sakai.lib.util.chainer.execute();
>>
>> which would execute all the added functions, sequentially one after
>> another. Not sure all of the details around the implementation of such a
>> system, but I could imagine something based on dynamically created
>> events for each function chained (basically a dynamically set up event
>> chain).
>>
>> Having access to an easy event based pattern and also to an easy
>> sequential pattern would make life considerably easier for a front-end
>> developer staging page functionality.
>
> . . . . . . . . . . . . . . . . . . .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
> _______________________________________________
> 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] [3akai] Fluid Framework

2009-11-22T06:42:59Z

The expressed and realised goal of the UX developers at Cambridge is to use as much of the Fluid work as we reasonably can. However, with very limited resource and time, I have asked that we rely on Fluid's own designation of production readiness in choosing which components and parts of the framework we can use. We do the Fluid project no favours if we take something that is not finished and run into trouble that we then blame the trouble on Fluid.

The key expectation that I have of "production ready" Fluid components is that they should work in all our supported browsers (which suggests convergence with the set Fluid support) AND that any bugs are fixed in a few days. This last issue is not trivial, because Fluid (like Sakai) is pushing forward on a lot of new stuff and (AFAIK) does not have dedicated maintenance resource (again like Sakai, but unlike Sakai the Fluid team is not running production systems that depend on Fluid code).

I want to emphasise that we are fully engaged in using Fluid wherever possible and we are completely aligned with the goals. However, responsible use of their code means waiting until things are baked *unless we plan to get involved in fixing things*. I'd like to be getting involved more, but as I said - we are very resource constrained at present. A desirable consequence of greater UX development engagement may well be the ability to contribute more than adoption and bug reports, but as a community we need to increase our Javascript skills and resource in order to do that alongside our own development.

John

On 18 Nov 2009, at 17:43, Eli Cochran wrote:

During the Sakai 3 UX Developers meeting on Friday, I suggested that we use the Fluid Framework for Sakai 3. A concern was voiced that the Fluid Framework is not "production ready". I've had a little time to think about that characterization and to discuss it with Colin Clark, the Fluid technical lead.

First, I really must purge the term Fluid Framework from my brain since the Fluid Project now refers to it as the Infusion Framework.

The Infusion Framework is a collection of many different framework capabilities which should be considered both as a whole and individually -- one can pick and choose which capabilities one takes advantage of.

By using Fluid Infusion components, one is using the Framework. Every component is built on top of Fluid.js, and Fluid.js is the framework*. The framework provides many things: component and sub-component support, glue to bind model and view, a very robust event system, accessibility support, a client-side renderer, etc, etc.

*The Infusion Framework also contains the Fluid Skinning System which is not a part of Fluid.js.

The Infusion Framework is evolving and growing and perhaps that is cause for concern. Then again, if the code were not not changing that would be cause for concern as well. Colin reiterated Fluid's commitment to support the many current users of Fluid, both by supporting the current code and by evolving the code carefully and respectfully.

In future discussions I will be sure to be more specific when talking about which capabilities we should take advantage of. (On Friday, I was thinking primarily about the Fluid event system.) But let's not dismiss the framework out of hand. We're already loading the library so lets use what we can from it -- the Infusion Framework is full of wonderful functionality. http://wiki.fluidproject.org/display/fluid/Infusion+Framework

Thanks,
Eli

. . . . . . . . . . . . . . . . . . .

Eli Cochran
user interaction developer
ETS, UC Berkeley

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Sakai 3 Design" group.
To post to this group, send email to 3akai@...
To unsubscribe from this group, send email to 3akai+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/3akai?hl=en-GB

-~----------~----~----~----~------~----~------~--~---

[DG: User Experience] [libsakai] Nov 19 Library & Sakai 3 Integration Meeting Notes

2009-11-19T11:17:45Z

Thanks to everyone who was able to make it to the meeting! We heard
updates from nine institutions, covering 16 completed, diverse user
interviews and a few more that are planned. With an email update from
Mount Holyoke, we have a total of 19 interviews complete, surpassing
our goal of 18.

Find more meeting notes and next steps toward the bottom of our
meeting's wiki page:
http://confluence.sakaiproject.org//x/ggoAB

Thanks,
Gaurav
_______________________________________________
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] [libsakai] Nov 19: Library & Sakai 3 Integration Web Meeting

2009-11-19T06:45:18Z

Friendly reminder - we'll be meeting today at 11:30am EST. Agenda and call details in message below. If you are an interviewer that will not be able to attend, please send me a brief update I may share at the call.

Thanks very much!

See you soon,
Gaurav

On Tue, Nov 17, 2009 at 8:56 AM, Gaurav Bhatnagar <gbhatnag@...> wrote:

Hello!

The Library & Sakai 3 Integration Project has completed a number of user interviews with various instructors at multiple different campuses to learn why and how they use scholarly resources in preparing and conducting their courses. In our Nov 19 web meeting, hear who we've been talking to and what we've learned. We will also discuss the process for getting this interview data organized and analyzed and share an updated project timeline.

An agenda for the meeting can be found at:
http://confluence.sakaiproject.org//x/ggoAB

The meeting is Thursday, Nov 19, from 11:30am to 1pm, Eastern using the Sakai002 Conference Bridge:
- Telephone: +1 812 856 7060
- Internet: 156.56.240.9 (via Polycom, XMeeting (Mac), Ekiga (Linux))
- Conference Code: 350#
- PIN: 72524#

Thanks,
Gaurav

[DG: User Experience] Leading Design

2009-11-18T16:28:43Z

In recent weeks I've been trying to promote the maturation of the
learning capabilities spreadsheet [1] that David Goodrum has
championed. At the same time I've heard concerns that it might come to
naught or not be listened to. Just a couple days ago Josh Baron was
asking me when and how I thought the spreadsheet might actually be
used to inform the design. I told him, "It's happening right now." I'm
not sure he believed me, so I made a blog post with evidence:
http://sakaipm.wordpress.com

~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 Experience] Interesting blog post on CMS user interfaces

2009-11-18T15:49:56Z

Re: [DG: User Experience] [DG: Teaching & Learning] User Experience] Interesting blog post on CMS user interfaces Hello John,

To the best of my knowledge – Tomorrow’s Professor does have some institutional backing. Feel free to add your comments to the posts or to ping the admins for more details. Thank you also for the student blog link. We don’t have a Planet Sakai equivalent (calling it “Planet Stellar” would be somewhat — anticlimactic) but we do keep an internal list of relevant and fascinating links to blogs, articles and the like: http://www.technologyreview.com/business/20872/

In a pinch, I’ve found that the Education section of MITWorld also delivers great food for thought: http://mitworld.mit.edu/browse/topic/6

Best,
joanna

On 11/15/09 6:59 PM, "John Norman" <john@...> wrote:

Thanks for these links Joanna. I am curious to know more about the Tomorrow's Professor collaboration. It looks like a grass-roots thing, but it could have institutional support... Also, the second link took me to a very interesting student blog "Carolyn Blogs" (http://blog.carolynworks.com). Do you have any coordinated collection of such blogs? It might be interesting to collect them in a fashion similar to Planet Sakai.

Best, John

On 12 Nov 2009, at 22:39, Joanna Proulx wrote:

> Hi Daphne et al,
>
> As we focus, here at MIT, on the mental models of faculty with respect to their online teaching, there’s a constant effort to remember that any LMS has to be a two-way street. The students are partners in this process and their mental models matter equally to those of the faculty. If they are ignored, true learning is likely to be hampered if not arrested entirely. I have two examples to share by way of inveighling on behalf of the student perspective:
>
> http://tomprofblog.mit.edu/2009/10/13/974-online-learning-more-than-technical-savvy/
>
> We posit that readiness for online learning has less to do with students’ knowledge of technology and digital dexterity and more to do with their knowledge of how to learn and their motivation to engage fully in the process.
>
> The teacher in the learner-centered class is a designer of learning opportunities, one who sets the stage and then steps aside while the students engage in knowledge constructing activities.
>
> http://news.slashdot.org/story/09/11/09/2347215/Attack-of-the-PowerPoint-Wielding-Professors
>
> Cheers,
> joanna
>
>
> ::::::::::::::::::::::::::::::::::::::::::::::::::
> Joanna Proulx : Team Lead
> Interaction Development
> Content & Collaboration Services
> ..................................................
> MIT : IS&T : ISDA : CCS : ID
>
>
>
> On 11/3/09 1:16 PM, "Daphne Ogle" <daphne@...> wrote:
>
> Yes, thanks for sharing Michael. Mathieu's post makes me wonder if we have a good understanding of the multiple types of course/activity structures we need to support in Sakai 3? It seems Moodle handles the syllabus/time-based and topic-based structures which make sense. Are there others? Understanding these will be key to creating the right context, cues, flows to help faculty build there course space in ways that match their mental models and then represent the course in ways that make sense to students.
>
> -Daphne
>
> On Nov 3, 2009, at 6:21 AM, Plourde, Mathieu wrote:
>
> Funny that this thing has come to a full circle… Anyone remember VirtualU? The default course was a long table organized as a list of event with links to discussions and resources.
>
> I think the goal of that article was not to say that organizing your content in a calendar was the best way to think, but that the defaults are what most faculty will select.
>
> If Sakai 3’s default is to present multiple options in terms of course/activity structure, and can support faculty in choosing an appropriate one to start with, half the battle will be won.
>
> Best Regards,
>
> =================================
>
> Mathieu Plourde, MBA
> Project Leader, LMS/Instructional Designer
> IT-Client Support & Services
> mathieu@...
>
> =================================
>
> TOP LINKS:
>
> Technology Troubleshooting: http://www.udel.edu/help
> Sakai@UD Support and Training: http://www.udel.edu/sakai/training
>
> =================================
>
> From: sakai-ux-bounces@... [sakai-ux-bounces@...] On Behalf Of Jacques Raynauld
> Sent: Tuesday, November 03, 2009 8:51 AM
> To: Sakai UX
> Cc: Michael Korcuska; pedagogy@... Learning
> Subject: Re: User Experience] Interesting blog post on CMS user interfaces
>
> I also agree. It is a very interesting article. I have always been struck by the Moodle first page template that naturally leads to a week or theme interpretation by users. I think it is one of the important factor that explains Moodle popularity. This is the kind of need we wanted to adress in Sakai/Open Syllabus ... but in a more semantic way than Moodle.
>
> Jacques Raynauld
> HEC Montréal
>
> -------- Message original --------
> Sujet : Re: [DG: User Experience] Interesting blog post on CMS user    interfaces
> De : harriet@...
> Pour : Michael Korcuska <mkorcuska@...> <mkorcuska@...>
> Copie à : "pedagogy@... Learning" <pedagogy@...> <pedagogy@...> <pedagogy@...> , Sakai UX <sakai-ux@...> <sakai-ux@...>
> Date : 2009-11-03 04:58
>
> Very interesting - thanks Michael!
>
> There were a couple of paras that struck me particularly as relating to the
> possibilities for the new Sakai 3:
>
> "The buttons link to pages that simply provide a place to upload a document,
> which is exactly what most instructors do: upload word–processed files of their
> classroom materials. They are encouraged to “plug in” their content under the
> appropriate category instead of envisioning a translation of their individual
> pedagogical style into an online environment. Blackboard “tends to encourage a
> linear pathway through the content” [3], and its default is to support easy
> uploading and text entry to achieve that goal.
> The construction of the course syllabus is a familiar beginning point for most
> instructors, yet few CMSs consider this. It would be natural and useful for
> novice instructors to see a blank schedule into which they could create each
> week’s or unit’s activities, rather than a selection of pre–set buttons or
> links. Most professors think in terms of the semester, and how their
> pedagogical goals can be achieved within the context of time, rather than
> space. Some think in terms of topics they want to cover. Blackboard/WebCT’s
> default organization accepts neither of these approaches in its initial
> interface. It forces the instructor to think in terms of content types instead,
> breaking the natural structure of the semester, or of a list of topics. Again,
> we know that the setup can be customized with relative ease, by going to the
> Control Panel and selecting Manage Course Menu, then using Modify buttons. You
> could change all the course menu buttons into “Week 1”, “Week 2”, or organize
> by topic instead of content type. But few professors try that, or they assume
> that they can’t do it. Blackboard can be highly intimidating to learn, and may
> “seriously hinder” choices the faculty member makes while using the tool [4].
> Faculty are led by the interface of a CMS not only because they do not
> immediately see an alternative, but because the familiar signposts (the
> Syllabus button) imply a single way of completing the task (upload a document).
> Only the Moodle system provides a default setup that looks like a calendar-style
> syllabus ..."
>
> I'd agree very strongly with this statement about pedagogies, and the initial
> presentation of potential course structures, rather than tools, to the
> lecturer, seems to be something that Sakai 3 has the potential to support
>
>
> "Although it is an oversimplification, it is useful to separate course
> management systems into two types: Opt–In and Opt–Out. In an Opt–Out system
> (such as Blackboard) all the features are available by default and must be
> excluded to avoid confusing students. Opt–Out systems are most likely to
> overwhelm Web novices, because they present an array of tools, and the tendency
> is to reduce cognitive load by using the defaults. In an Opt–In system (such as
> Moodle), the instructor selects each activity and presentation factor from a
> menu list, effectively designing much of the interface for students. Fewer
> defaults are pre–set, forcing the instructor to think holistically about the
> class structure. Features such as chat, polls, and interactive lessons as
> options presented with the same weight as more traditional text–based
> resources. Thus there is less of an implication that presentation is key, and
> more of an implication that interactivity is important. In an Opt–In
> environment, the instructor makes choices about context on a macro level, and
> choices about features and tools on a micro level. This makes it possible to
> explore pedagogical options more freely"
>
> Again, perhaps a future strength of Sakai 3?
>
> Harriet
>
>
>
> Quoting Michael Korcuska <mkorcuska@...> <mkorcuska@...> :
>
>
> It's worth a read....
>
>
>
> http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/2530/2303
>
>
> --
> Michael Korcuska
> Executive Director, Sakai Foundation
> mkorcuska@...
> phone: +1 510-859-4247 (google voice)
> skype: mkorcuska
>
>
>
>
> _______________________________________________
> 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"
>
>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> 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"

::::::::::::::::::::::::::::::::::::::::::::::::::
Joanna Proulx : Team Lead
Interaction Development
Content & Collaboration Services
..................................................
MIT : IS&T : ISDA : CCS : ID

_______________________________________________
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] [3akai] Fluid Framework

2009-11-18T14:08:47Z

I, too, share the desire to embrace as much of Fluid as we can.

Let me ask this:

* "Production-ready" could mean a lot of things. Was this based on
particular evidence (or lack thereof)? Is is a quality or performance
or feature-set concern?
* Can we help address any of the above concerns to make it satisfy any
real or perceived issues?
* What is the alternative?

On Nov 18, 2009, at 11:43, Eli Cochran wrote:

> During the Sakai 3 UX Developers meeting on Friday, I suggested that
> we use the Fluid Framework for Sakai 3. A concern was voiced that
> the Fluid Framework is not "production ready". I've had a little
> time to think about that characterization and to discuss it with
> Colin Clark, the Fluid technical lead.
>

--
Michael Korcuska
Executive Director, Sakai Foundation
mkorcuska@...
phone: +1 510-859-4247 (google voice)
skype: mkorcuska

_______________________________________________
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] Fluid Framework

2009-11-18T13:19:41Z

Hi all,

Only you guys can decide if Fluid Infusion is the right choice for
Sakai 3, so I will avoid weighing in on that particular subject.

I do want to make it clear that using Infusion's framework isn't an
all-or-nothing prospect. It's built in an extremely loosely-coupled
way. You can use one small feature of it, such as the event system,
without requiring any dependencies on other parts of the framework,
such as the Renderer.

The Infusion framework is indeed fully production-ready, and is used
in other shipping, stable applications such as uPortal. Fluid
components themselves use a broad range of features provided by the
framework. And the Fluid community is building applications with
Infusion, including our CollectionSpace, Decapod, and Fluid Engage
projects. Infusion is stable, reliable, and production-ready. And
while we've got lots of great new features planned for the next few
releases, we're still committed to ensuring backwards-compatibility
and API stability as well.

Hope this helps,

Colin

On 18-Nov-09, at 2:50 PM, Eli Cochran wrote:

> Nate,
> Thanks for the vote of confidence. But in case anyone is missing the
> distinction, there is a difference between using a component (which
> uses the framework) and using the underlying framework directly.
>
> I don't want to suggest that anyone has said that we shouldn't
> "production ready" Infusion components. Fluid components have been
> fully embraced.
>
> I would like to see the Framework embraced with the same gusto, as
> it provides functionality that we need and we already have at hand.
>
> Thanks,
> Eli
>
> On Nov 18, 2009, at 10:34 AM, Nate Angell wrote:
>
>> I'm far from qualified from assessing the technical pros/cons of
>> Sakai 3 embracing the Fluid Project's Infusion Framework, however,
>> that won't keep me from weighing in ;)
>>
>> Frankly, I think we'd be crazy not to.
>>
>> The Fluid Project was initiated specifically to meet UX needs for
>> projects like Sakai and some of the best technical minds in our
>> community and beyond have been working on it. The Fluid Project
>> also focuses specifically to meet needs historically undermet in
>> Sakai, including user-centered design and accessibility.
>>
>> If there are doubts about the readiness of the Infusion Framework:
>> by fully embracing it, the Sakai community would add additional
>> energy to help expand and extend it.
>>
>> And last: given all the issues brought up by the multiple
>> presentation technologies used heretofore in Sakai, would we not do
>> well to coalesce around at least one primary framework that is
>> built by education, for education, like Sakai itself?
>>
>> I welcome counterarguments, especially those based on a deeper
>> understanding of the technical issues than I can provide.
>>
>> --
>> Nate Angell
>> Client Evangelist
>> http://twitter.com/xolotl
>> http://xolotl.org
>> http://www.rsmart.com
>>
>> On Nov 18, 2009, at 9:43 AM, Eli Cochran wrote:
>>
>>> During the Sakai 3 UX Developers meeting on Friday, I suggested
>>> that we use the Fluid Framework for Sakai 3. A concern was voiced
>>> that the Fluid Framework is not "production ready". I've had a
>>> little time to think about that characterization and to discuss it
>>> with Colin Clark, the Fluid technical lead.
>>>
>>> First, I really must purge the term Fluid Framework from my brain
>>> since the Fluid Project now refers to it as the Infusion Framework.
>>>
>>> The Infusion Framework is a collection of many different framework
>>> capabilities which should be considered both as a whole and
>>> individually -- one can pick and choose which capabilities one
>>> takes advantage of.
>>>
>>> By using Fluid Infusion components, one is using the Framework.
>>> Every component is built on top of Fluid.js, and Fluid.js is the
>>> framework*. The framework provides many things: component and sub-
>>> component support, glue to bind model and view, a very robust
>>> event system, accessibility support, a client-side renderer, etc,
>>> etc.
>>>
>>> *The Infusion Framework also contains the Fluid Skinning System
>>> which is not a part of Fluid.js.
>>>
>>> The Infusion Framework is evolving and growing and perhaps that is
>>> cause for concern. Then again, if the code were not not changing
>>> that would be cause for concern as well. Colin reiterated Fluid's
>>> commitment to support the many current users of Fluid, both by
>>> supporting the current code and by evolving the code carefully and
>>> respectfully.
>>>
>>> In future discussions I will be sure to be more specific when
>>> talking about which capabilities we should take advantage of. (On
>>> Friday, I was thinking primarily about the Fluid event system.)
>>> But let's not dismiss the framework out of hand. We're already
>>> loading the library so lets use what we can from it -- the
>>> Infusion Framework is full of wonderful functionality. http://wiki.fluidproject.org/display/fluid/Infusion+Framework
>>>
>>> Thanks,
>>> Eli
>>>
>>>
>>> . . . . . . . . . . . . . . . . . . .
>>>
>>> Eli Cochran
>>> user interaction developer
>>> ETS, UC Berkeley
>>>
>>>
>>> _______________________________________________
>>> 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"
>>
>
> . . . . . . . . . . . . . . . . . . .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
> _______________________________________________
> 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"

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org

_______________________________________________
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] Fluid Framework

2009-11-18T11:50:55Z

Nate,

Thanks for the vote of confidence. But in case anyone is missing the distinction, there is a difference between using a component (which uses the framework) and using the underlying framework directly.

I don't want to suggest that anyone has said that we shouldn't "production ready" Infusion components. Fluid components have been fully embraced.

I would like to see the Framework embraced with the same gusto, as it provides functionality that we need and we already have at hand.

Thanks,

Eli

On Nov 18, 2009, at 10:34 AM, Nate Angell wrote:

I'm far from qualified from assessing the technical pros/cons of Sakai 3 embracing the Fluid Project's Infusion Framework, however, that won't keep me from weighing in ;)

Frankly, I think we'd be crazy not to.

The Fluid Project was initiated specifically to meet UX needs for projects like Sakai and some of the best technical minds in our community and beyond have been working on it. The Fluid Project also focuses specifically to meet needs historically undermet in Sakai, including user-centered design and accessibility.

If there are doubts about the readiness of the Infusion Framework: by fully embracing it, the Sakai community would add additional energy to help expand and extend it.

And last: given all the issues brought up by the multiple presentation technologies used heretofore in Sakai, would we not do well to coalesce around at least one primary framework that is built by education, for education, like Sakai itself?

I welcome counterarguments, especially those based on a deeper understanding of the technical issues than I can provide.

--
Nate Angell
Client Evangelist
http://twitter.com/xolotl
http://xolotl.org
http://www.rsmart.com

On Nov 18, 2009, at 9:43 AM, Eli Cochran wrote:

During the Sakai 3 UX Developers meeting on Friday, I suggested that we use the Fluid Framework for Sakai 3. A concern was voiced that the Fluid Framework is not "production ready". I've had a little time to think about that characterization and to discuss it with Colin Clark, the Fluid technical lead.

First, I really must purge the term Fluid Framework from my brain since the Fluid Project now refers to it as the Infusion Framework.

The Infusion Framework is a collection of many different framework capabilities which should be considered both as a whole and individually -- one can pick and choose which capabilities one takes advantage of.

By using Fluid Infusion components, one is using the Framework. Every component is built on top of Fluid.js, and Fluid.js is the framework*. The framework provides many things: component and sub-component support, glue to bind model and view, a very robust event system, accessibility support, a client-side renderer, etc, etc.

*The Infusion Framework also contains the Fluid Skinning System which is not a part of Fluid.js.

The Infusion Framework is evolving and growing and perhaps that is cause for concern. Then again, if the code were not not changing that would be cause for concern as well. Colin reiterated Fluid's commitment to support the many current users of Fluid, both by supporting the current code and by evolving the code carefully and respectfully.

In future discussions I will be sure to be more specific when talking about which capabilities we should take advantage of. (On Friday, I was thinking primarily about the Fluid event system.) But let's not dismiss the framework out of hand. We're already loading the library so lets use what we can from it -- the Infusion Framework is full of wonderful functionality. http://wiki.fluidproject.org/display/fluid/Infusion+Framework

Thanks,
Eli

. . . . . . . . . . . . . . . . . . .

Eli Cochran
user interaction developer
ETS, UC Berkeley

_______________________________________________
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"

. . . . . . . . . . . . . . . . . . .

Eli Cochran

user interaction developer

ETS, UC Berkeley

Re: [DG: User Experience] JavaScript event based development (Sakai 3)

2009-11-18T11:28:40Z

Oszkar,
You've hit on something that was itching the back of my brain while I was writing my rant on events.

One of the challenges with multiple binding to the same event is having control, or the sense of control, over the order that each listener will be triggered and what to do in those situations where components really are intertwined.

I like your solution of chaining to solve this problem. Although it's worth asking first if there are ways to reduce the dependences before chaining becomes necessary.

Another tricky area is when listeners need to respond to each other or prevent or modify the action of the firer.

Fluid got around this in their library with a concept of "preventable" events. (I put this forward as an example of a concept, and not to push "the Fluid way"). This allows Fluid events to behave like browser events with the ability to stopPropogation and return a boolean to the caller to stop the action.

(Aside: To help keep our heads clear, Fluid uses a naming convention separating our events into "before events" (onPageLoad) and "after events" (afterPageLoad). I highly recommend this convention.)

- Eli

On Nov 18, 2009, at 10:53 AM, Oszkar Nagy wrote:

> 2. Chaining:
>
> LoadControl was a result of a site.js cleanup iteration, where I wanted
> to formulate a clear(er) view of what is happening when, and make the
> code more readable by seeing the chain of events. The proper way to do
> this kind of thing is through events IMHO, but we haven't reached that
> stage yet. But even with events I think it's important to always
> organise the code in such way that everybody has an instant
> understanding of the order of events, which perhaps raises questions
> about the need of a "chainer" where you could simply chain things up and
> wouldn't need to add callbacks within callbacks within callbacks (as in
> site_admin.js), but use something like this:
>
> sakai.lib.util.chainer.init();
>
> sakai.lib.util.chainer.add(load_site_data, param1, param2);
> sakai.lib.util.chainer.add(load_profile_data, param1);
> sakai.lib.util.chainer.add(display_profile_data);
> sakai.lib.util.chainer.add(render_widgets);
>
> sakai.lib.util.chainer.execute();
>
> which would execute all the added functions, sequentially one after
> another. Not sure all of the details around the implementation of such a
> system, but I could imagine something based on dynamically created
> events for each function chained (basically a dynamically set up event
> chain).
>
> Having access to an easy event based pattern and also to an easy
> sequential pattern would make life considerably easier for a front-end
> developer staging page functionality.

. . . . . . . . . . . . . . . . . . .

Eli Cochran
user interaction developer
ETS, UC Berkeley

_______________________________________________
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] JavaScript event based development (Sakai 3)

2009-11-18T10:53:55Z

Just a couple of thoughts on this:

Two separate things struck my mind regarding this, both of them which I
could easily imagine in a nice, easy to use general Sakai JS library (
thinking something like sakai.lib.util.events.add_listener() for example )

1. Event based programming:
I fully agree with Eli here that the ideal state would be to standardise
this within Sakai 3 UX, probably leveraging existing technologies and
libraries we already use, and which normalize the event object across
different browsers:

The fluid event system as Eli mentioned:
http://wiki.fluidproject.org/display/fluid/Infusion+Event+System

the jQuery way through .bind() and .trigger():
http://jamazon.co.uk/web/2008/06/17/publish-subscribe-with-jquery/
http://trulyevil.com/2009/05/07/custom-events-in-jquery/

and another way through jQuery:
http://brandonaaron.net/blog/2009/03/26/special-events

but I think these would need to be wrapped into a simpler form to be useful.

Actually under the hood all proper JS event systems use a hybrid of
callbacks and real DOM events to get around different browser's way of
handling events (IE fireEvent for example) [1]

2. Chaining:

LoadControl was a result of a site.js cleanup iteration, where I wanted
to formulate a clear(er) view of what is happening when, and make the
code more readable by seeing the chain of events. The proper way to do
this kind of thing is through events IMHO, but we haven't reached that
stage yet. But even with events I think it's important to always
organise the code in such way that everybody has an instant
understanding of the order of events, which perhaps raises questions
about the need of a "chainer" where you could simply chain things up and
wouldn't need to add callbacks within callbacks within callbacks (as in
site_admin.js), but use something like this:

sakai.lib.util.chainer.init();

sakai.lib.util.chainer.add(load_site_data, param1, param2);
sakai.lib.util.chainer.add(load_profile_data, param1);
sakai.lib.util.chainer.add(display_profile_data);
sakai.lib.util.chainer.add(render_widgets);

sakai.lib.util.chainer.execute();

which would execute all the added functions, sequentially one after
another. Not sure all of the details around the implementation of such a
system, but I could imagine something based on dynamically created
events for each function chained (basically a dynamically set up event
chain).

Having access to an easy event based pattern and also to an easy
sequential pattern would make life considerably easier for a front-end
developer staging page functionality.

Again, thanks Eli for bringing attention to this,

Oszkar

[1] http://dean.edwards.name/weblog/2009/03/callbacks-vs-events/

On 17/11/2009 23:18, Christian Vuerings wrote:

> Eli,
>
>
> Thanks for your answer.
> I was already a bit familiar with event driven JavaScript and I think
> your explanation about events will definitely help a lot of other
> JavaScript developers.
>
> My question was how we could improve our current code to make it even
> better for others to add their own functions.
> Your example about adding events to loadControl is definitely an answer
> to that.
>
> I am currently looking deeper into how Fluid actually does the
> event-driven bit and how we could use this inside Sakai.
> If you have any further suggestions or remarks, please let us know.
>
>
> Regards,
> Christian
>
>
> On 17 Nov 2009, at 19:32, Eli Cochran wrote:
>
>> Christian,
>> Sorry to take so long to get back to you.
>>
>> You asked about event-driven code which I brought up on the call on
>> Friday. I'll share my explanation with the list in case there are
>> folks who are not familiar with events.
>>
>> First, I should clarify that it really wasn't difficult to add my code
>> to the existing 3akai code. I just added a call to my init function to
>> the end of /loadControl() in /Site.js.../ very easy. And if someone
>> else wanted to add some functionality to the end of /loadControl()
>> they could easily do so as well. But since so much Ajax code needs to
>> know when the load is complete, that file can become a point of
>> contention, with many different areas of functionality hard-coded into
>> it.//
>>
>> Event-driven code takes a different approach to adding functionality.
>> Everyone doing Javascript is very familiar with DOM events, they are
>> at the heart of what makes Javascript so powerful. "Event-driven code"
>> simply means applying the same kind of power and light coupling
>> between elements to communication between and within components.
>>
>> To illustrate what I mean by light coupling, let us take a moment to
>> look at the power of DOM events.
>>
>> We want something to happen when someone clicks a button:
>>
>> * $("buttonFoo").click(function () {doSomething()});*
>>
>> /buttonFoo/ knows nothing about /doSomething()/. And doSomething()
>> doesn't really need to know anything about buttonFoo (although there
>> is lots of nice information available if I look at the /event/
>> object.) Additionally you could attach doSomethingElse() to the
>> button's /click/ event completely independently from doSomething() and
>> it too would get called when the button is clicked.
>> *
>> *
>> *
>> To get back to my case where I wanted to initialize my groups code
>> when loadControl() was completed... it would be great to have a formal
>> way to attach my code to loadControl() where loadControl() didn't need
>> to be modified at all.
>> *
>>
>> One way to do this is to use a callback, a very useful and familiar
>> pattern in jQuery and the basis for all jQuery AJAX calls. In the case
>> of a callback we could have a way for other functions to register with
>> loadControl() that they want to be called back at the end of
>> loadControl(). In this case the glue would know both about
>> loadControl() and the functions dependent on loadControl().
>>
>> The event-driven way would be to define a custom event,
>> /*afterNavigationLoad for example, that loadControl() would fire when
>> loading was complete, and other components could listen for to know
>> when to act. In this way, loadControl() would not need to know
>> anything about the other components, just as the button knows nothing
>> about doSomething()above.*/
>>
>> There are many advantages to coding like this. The /event/ is the
>> contract between components. The components can be very lightly
>> coupled. Instead of one component explicitly calling another component
>> thus having to know about the callee, the component just sends the
>> event... it doesn't care who gets the event, in fact many different
>> components may listen and act or respond.
>>
>> Also you can also test a component independent of how and where it
>> will be used.
>>
>> jQuery has support for this kind of event-driven code style, but the
>> support is very minimal. If we go with event-driven functionality, we
>> will probably want to build some "framework" code to make it easier
>> and more robust. I'm used to to doing this with Fluid but we could
>> come up with our own "event system".
>>
>> Here are the docs on the Infusion Event System in Fluid:
>> http://wiki.fluidproject.org/display/fluid/Infusion+Event+System
>>
>> I welcome your comments, questions and additions.
>>
>> Thanks,
>> Eli
>>
>> On Nov 15, 2009, at 4:54 PM, Christian Vuerings wrote:
>>
>>> Hi Eli,
>>>
>>> The main thing that kept hanging in my head was the fact that you
>>> talked about JavaScript event based development. I didn't really
>>> wanted to go into too much technical details during call (since
>>> non-code people like Clay & John where on it), but could you explain
>>> this a bit more?
>>>
>>> Since IMHOP we are already doing this inside most of our current
>>> JavaScript code. You mentioned something about adding your code to
>>> the current Sakai 3 code was hard because it wasn't... Can you be a
>>> bit more specific about where you think our current flaws in our
>>> JavaScipt code are? What do you think needs to be changed to make
>>> further development easier, faster and better?
>>>
>>>
>>> Regards,
>>> Christian
>>
>> . . . . . . . . . . . . . . . . . . .
>>
>> Eli Cochran
>> user interaction developer
>> ETS, UC Berkeley
>>
>>
>
>
>
> _______________________________________________
> 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] Fluid Framework

2009-11-18T10:34:44Z

I'm far from qualified from assessing the technical pros/cons of Sakai 3 embracing the Fluid Project's Infusion Framework, however, that won't keep me from weighing in ;)

Frankly, I think we'd be crazy not to.

The Fluid Project was initiated specifically to meet UX needs for projects like Sakai and some of the best technical minds in our community and beyond have been working on it. The Fluid Project also focuses specifically to meet needs historically undermet in Sakai, including user-centered design and accessibility.

If there are doubts about the readiness of the Infusion Framework: by fully embracing it, the Sakai community would add additional energy to help expand and extend it.

And last: given all the issues brought up by the multiple presentation technologies used heretofore in Sakai, would we not do well to coalesce around at least one primary framework that is built by education, for education, like Sakai itself?

I welcome counterarguments, especially those based on a deeper understanding of the technical issues than I can provide.

Nate Angell

Client Evangelist

http://twitter.com/xolotl

http://xolotl.org

http://www.rsmart.com

On Nov 18, 2009, at 9:43 AM, Eli Cochran wrote:

During the Sakai 3 UX Developers meeting on Friday, I suggested that we use the Fluid Framework for Sakai 3. A concern was voiced that the Fluid Framework is not "production ready". I've had a little time to think about that characterization and to discuss it with Colin Clark, the Fluid technical lead.

First, I really must purge the term Fluid Framework from my brain since the Fluid Project now refers to it as the Infusion Framework.

The Infusion Framework is a collection of many different framework capabilities which should be considered both as a whole and individually -- one can pick and choose which capabilities one takes advantage of.

By using Fluid Infusion components, one is using the Framework. Every component is built on top of Fluid.js, and Fluid.js is the framework*. The framework provides many things: component and sub-component support, glue to bind model and view, a very robust event system, accessibility support, a client-side renderer, etc, etc.

*The Infusion Framework also contains the Fluid Skinning System which is not a part of Fluid.js.

The Infusion Framework is evolving and growing and perhaps that is cause for concern. Then again, if the code were not not changing that would be cause for concern as well. Colin reiterated Fluid's commitment to support the many current users of Fluid, both by supporting the current code and by evolving the code carefully and respectfully.

In future discussions I will be sure to be more specific when talking about which capabilities we should take advantage of. (On Friday, I was thinking primarily about the Fluid event system.) But let's not dismiss the framework out of hand. We're already loading the library so lets use what we can from it -- the Infusion Framework is full of wonderful functionality. http://wiki.fluidproject.org/display/fluid/Infusion+Framework

Thanks,
Eli

. . . . . . . . . . . . . . . . . . .

Eli Cochran
user interaction developer
ETS, UC Berkeley

_______________________________________________
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] Fluid Framework

2009-11-18T09:43:48Z

During the Sakai 3 UX Developers meeting on Friday, I suggested that we use the Fluid Framework for Sakai 3. A concern was voiced that the Fluid Framework is not "production ready". I've had a little time to think about that characterization and to discuss it with Colin Clark, the Fluid technical lead.

First, I really must purge the term Fluid Framework from my brain since the Fluid Project now refers to it as the Infusion Framework.

The Infusion Framework is a collection of many different framework capabilities which should be considered both as a whole and individually -- one can pick and choose which capabilities one takes advantage of.

By using Fluid Infusion components, one is using the Framework. Every component is built on top of Fluid.js, and Fluid.js is the framework*. The framework provides many things: component and sub-component support, glue to bind model and view, a very robust event system, accessibility support, a client-side renderer, etc, etc.

*The Infusion Framework also contains the Fluid Skinning System which is not a part of Fluid.js.

The Infusion Framework is evolving and growing and perhaps that is cause for concern. Then again, if the code were not not changing that would be cause for concern as well. Colin reiterated Fluid's commitment to support the many current users of Fluid, both by supporting the current code and by evolving the code carefully and respectfully.

In future discussions I will be sure to be more specific when talking about which capabilities we should take advantage of. (On Friday, I was thinking primarily about the Fluid event system.) But let's not dismiss the framework out of hand. We're already loading the library so lets use what we can from it -- the Infusion Framework is full of wonderful functionality. http://wiki.fluidproject.org/display/fluid/Infusion+Framework

Thanks,

Eli

. . . . . . . . . . . . . . . . . . .

Eli Cochran

user interaction developer

ETS, UC Berkeley

Re: [DG: User Experience] [DG: Teaching & Learning] [libsakai] Nov 19: Library & Sakai 3 Integration Web Meeting

2009-11-18T07:52:49Z

Hi Laura,

Thanks for your message. We are not specifically defining "scholarly resources" but letting our users do so. We want to learn about how they think about scholarly resources and uncover resources they use regularly that are not traditionally perceived as scholarly. What we are finding is that many instructors are using more emerging technologies and web resources (i.e. Wikipedia, YouTube, Google Images) for their teaching than ever before. Although scholarly resources may remain to be seen as peer-reviewed journal articles and the like, we want to be sure that what we design fits their broader and evolving teaching needs.

Others in the group may have ideas about this as well and are welcome to add to or correct what I've stated here!

Thanks,
Gaurav

On Wed, Nov 18, 2009 at 4:38 AM, Laura James <laura@...> wrote:

Hello,

I've been reading around the confluence pages and the project is fascinating and seems to be making good progress, which is super. One thing I couldn't find a definition for anywhere though is "scholarly resources" - is there a common understanding of what this means to the project?

Best,

Laura

On 17 Nov 2009, at 13:56, Gaurav Bhatnagar wrote:

> Hello!
>
> The Library & Sakai 3 Integration Project has completed a number of user interviews with various instructors at multiple different campuses to learn why and how they use scholarly resources in preparing and conducting their courses. In our Nov 19 web meeting, hear who we've been talking to and what we've learned. We will also discuss the process for getting this interview data organized and analyzed and share an updated project timeline.
>
> An agenda for the meeting can be found at:
> http://confluence.sakaiproject.org//x/ggoAB
>
> The meeting is Thursday, Nov 19, from 11:30am to 1pm, Eastern using the Sakai002 Conference Bridge:
> - Telephone: +1 812 856 7060
> - Internet: 156.56.240.9 (via Polycom, XMeeting (Mac), Ekiga (Linux))
> - Conference Code: 350#
> - PIN: 72524#
>
> Thanks,
> Gaurav

> _______________________________________________
> pedagogy mailing list
> pedagogy@...
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

Re: [DG: User Experience] [DG: Teaching & Learning] [libsakai] Nov 19: Library & Sakai 3 Integration Web Meeting

2009-11-18T01:38:32Z

Hello,

I've been reading around the confluence pages and the project is fascinating and seems to be making good progress, which is super. One thing I couldn't find a definition for anywhere though is "scholarly resources" - is there a common understanding of what this means to the project?

Best,

Laura

On 17 Nov 2009, at 13:56, Gaurav Bhatnagar wrote:

> Hello!
>
> The Library & Sakai 3 Integration Project has completed a number of user interviews with various instructors at multiple different campuses to learn why and how they use scholarly resources in preparing and conducting their courses. In our Nov 19 web meeting, hear who we've been talking to and what we've learned. We will also discuss the process for getting this interview data organized and analyzed and share an updated project timeline.
>
> An agenda for the meeting can be found at:
> http://confluence.sakaiproject.org//x/ggoAB
>
> The meeting is Thursday, Nov 19, from 11:30am to 1pm, Eastern using the Sakai002 Conference Bridge:
> - Telephone: +1 812 856 7060
> - Internet: 156.56.240.9 (via Polycom, XMeeting (Mac), Ekiga (Linux))
> - Conference Code: 350#
> - PIN: 72524#
>
> Thanks,
> Gaurav
> _______________________________________________
> pedagogy mailing list
> pedagogy@...
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe@... with a subject of "unsubscribe"

Re: [DG: User Experience] JavaScript event based development (Sakai 3)

2009-11-17T15:18:48Z

Eli,

Thanks for your answer.

I was already a bit familiar with event driven JavaScript and I think your explanation about events will definitely help a lot of other JavaScript developers.

My question was how we could improve our current code to make it even better for others to add their own functions.

Your example about adding events to loadControl is definitely an answer to that.

I am currently looking deeper into how Fluid actually does the event-driven bit and how we could use this inside Sakai.

If you have any further suggestions or remarks, please let us know.

Regards,

Christian

On 17 Nov 2009, at 19:32, Eli Cochran wrote:

Christian,
Sorry to take so long to get back to you.

You asked about event-driven code which I brought up on the call on Friday. I'll share my explanation with the list in case there are folks who are not familiar with events.

First, I should clarify that it really wasn't difficult to add my code to the existing 3akai code. I just added a call to my init function to the end of loadControl() in Site.js... very easy. And if someone else wanted to add some functionality to the end of loadControl() they could easily do so as well. But since so much Ajax code needs to know when the load is complete, that file can become a point of contention, with many different areas of functionality hard-coded into it.

Event-driven code takes a different approach to adding functionality. Everyone doing Javascript is very familiar with DOM events, they are at the heart of what makes Javascript so powerful. "Event-driven code" simply means applying the same kind of power and light coupling between elements to communication between and within components.

To illustrate what I mean by light coupling, let us take a moment to look at the power of DOM events.

We want something to happen when someone clicks a button:

$("buttonFoo").click(function () {doSomething()});

buttonFoo knows nothing about doSomething(). And doSomething() doesn't really need to know anything about buttonFoo (although there is lots of nice information available if I look at the event object.) Additionally you could attach doSomethingElse() to the button's click event completely independently from doSomething() and it too would get called when the button is clicked.

To get back to my case where I wanted to initialize my groups code when loadControl() was completed... it would be great to have a formal way to attach my code to loadControl() where loadControl() didn't need to be modified at all.

One way to do this is to use a callback, a very useful and familiar pattern in jQuery and the basis for all jQuery AJAX calls. In the case of a callback we could have a way for other functions to register with loadControl() that they want to be called back at the end of loadControl(). In this case the glue would know both about loadControl() and the functions dependent on loadControl().

The event-driven way would be to define a custom event, afterNavigationLoad for example, that loadControl() would fire when loading was complete, and other components could listen for to know when to act. In this way, loadControl() would not need to know anything about the other components, just as the button knows nothing about doSomething()above.

There are many advantages to coding like this. The event is the contract between components. The components can be very lightly coupled. Instead of one component explicitly calling another component thus having to know about the callee, the component just sends the event... it doesn't care who gets the event, in fact many different components may listen and act or respond.

Also you can also test a component independent of how and where it will be used.

jQuery has support for this kind of event-driven code style, but the support is very minimal. If we go with event-driven functionality, we will probably want to build some "framework" code to make it easier and more robust. I'm used to to doing this with Fluid but we could come up with our own "event system".

Here are the docs on the Infusion Event System in Fluid: http://wiki.fluidproject.org/display/fluid/Infusion+Event+System

I welcome your comments, questions and additions.

Thanks,
Eli

On Nov 15, 2009, at 4:54 PM, Christian Vuerings wrote:

Hi Eli,

The main thing that kept hanging in my head was the fact that you talked about JavaScript event based development. I didn't really wanted to go into too much technical details during call (since non-code people like Clay & John where on it), but could you explain this a bit more?

Since IMHOP we are already doing this inside most of our current JavaScript code. You mentioned something about adding your code to the current Sakai 3 code was hard because it wasn't... Can you be a bit more specific about where you think our current flaws in our JavaScipt code are? What do you think needs to be changed to make further development easier, faster and better?

Regards,
Christian

. . . . . . . . . . . . . . . . . . .

Eli Cochran
user interaction developer
ETS, UC Berkeley

Re: [DG: User Experience] JavaScript event based development (Sakai 3)

2009-11-17T11:32:10Z

Christian,

Sorry to take so long to get back to you.

You asked about event-driven code which I brought up on the call on Friday. I'll share my explanation with the list in case there are folks who are not familiar with events.

First, I should clarify that it really wasn't difficult to add my code to the existing 3akai code. I just added a call to my init function to the end of loadControl() in Site.js... very easy. And if someone else wanted to add some functionality to the end of loadControl() they could easily do so as well. But since so much Ajax code needs to know when the load is complete, that file can become a point of contention, with many different areas of functionality hard-coded into it.

Event-driven code takes a different approach to adding functionality. Everyone doing Javascript is very familiar with DOM events, they are at the heart of what makes Javascript so powerful. "Event-driven code" simply means applying the same kind of power and light coupling between elements to communication between and within components.

To illustrate what I mean by light coupling, let us take a moment to look at the power of DOM events.

We want something to happen when someone clicks a button:

$("buttonFoo").click(function () {doSomething()});

buttonFoo knows nothing about doSomething(). And doSomething() doesn't really need to know anything about buttonFoo (although there is lots of nice information available if I look at the event object.) Additionally you could attach doSomethingElse() to the button's click event completely independently from doSomething() and it too would get called when the button is clicked.

To get back to my case where I wanted to initialize my groups code when loadControl() was completed... it would be great to have a formal way to attach my code to loadControl() where loadControl() didn't need to be modified at all.

One way to do this is to use a callback, a very useful and familiar pattern in jQuery and the basis for all jQuery AJAX calls. In the case of a callback we could have a way for other functions to register with loadControl() that they want to be called back at the end of loadControl(). In this case the glue would know both about loadControl() and the functions dependent on loadControl().

The event-driven way would be to define a custom event, afterNavigationLoad for example, that loadControl() would fire when loading was complete, and other components could listen for to know when to act. In this way, loadControl() would not need to know anything about the other components, just as the button knows nothing about doSomething()above.

There are many advantages to coding like this. The event is the contract between components. The components can be very lightly coupled. Instead of one component explicitly calling another component thus having to know about the callee, the component just sends the event... it doesn't care who gets the event, in fact many different components may listen and act or respond.

Also you can also test a component independent of how and where it will be used.

jQuery has support for this kind of event-driven code style, but the support is very minimal. If we go with event-driven functionality, we will probably want to build some "framework" code to make it easier and more robust. I'm used to to doing this with Fluid but we could come up with our own "event system".

Here are the docs on the Infusion Event System in Fluid: http://wiki.fluidproject.org/display/fluid/Infusion+Event+System

I welcome your comments, questions and additions.

Thanks,

Eli

On Nov 15, 2009, at 4:54 PM, Christian Vuerings wrote:

Hi Eli,

The main thing that kept hanging in my head was the fact that you talked about JavaScript event based development. I didn't really wanted to go into too much technical details during call (since non-code people like Clay & John where on it), but could you explain this a bit more?

Since IMHOP we are already doing this inside most of our current JavaScript code. You mentioned something about adding your code to the current Sakai 3 code was hard because it wasn't... Can you be a bit more specific about where you think our current flaws in our JavaScipt code are? What do you think needs to be changed to make further development easier, faster and better?

Regards,
Christian

. . . . . . . . . . . . . . . . . . .

Eli Cochran
user interaction developer
ETS, UC Berkeley

[DG: User Experience] IMS Library Integration Survey

2009-11-17T11:13:37Z

I wanted to make sure Sakai library folks saw this call from the IMS:

Library Integration Survey

IMS Global Learning Consortium (IMS GLC) is currently exploring the
types and extent of integrations between Library Systems and Learning
Management Systems / Course Management Systems / Virtual Learning
Environments. We believe that the proliferation of e-learning tools
and learning management systems (LMS) provides an opportunity for
academic libraries to dramatically increase their relevance to
students and faculty by allowing them to integrate their resources and
their information literacy expertise.

In order to identify current areas of integration as well as
integration planning, the IMS GLC Libraries Special Interest Group has
compiled a survey to gather information about current library work in
this area and we would like to invite you to participate in our survey.

It will take approximately 10 minutes to complete the questionnaire
and the survey is located at:http://imslibraries.questionpro.com/

Details about the survey results and discussion of Library integration
will be available on the IMS public forum located at: http://www.imsglobal.org/community/forum/categories.cfm?catid=91&entercat=y
You are invited to participate in the discussion.

We appreciate your support.

IMS Global Learning Consortium.
_______________________________________________
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] [libsakai] Nov 19: Library & Sakai 3 Integration Web Meeting

2009-11-17T05:56:17Z

Hello!

The Library & Sakai 3 Integration Project has completed a number of user interviews with various instructors at multiple different campuses to learn why and how they use scholarly resources in preparing and conducting their courses. In our Nov 19 web meeting, hear who we've been talking to and what we've learned. We will also discuss the process for getting this interview data organized and analyzed and share an updated project timeline.

An agenda for the meeting can be found at:
http://confluence.sakaiproject.org//x/ggoAB

The meeting is Thursday, Nov 19, from 11:30am to 1pm, Eastern using the Sakai002 Conference Bridge:
- Telephone: +1 812 856 7060
- Internet: 156.56.240.9 (via Polycom, XMeeting (Mac), Ekiga (Linux))
- Conference Code: 350#
- PIN: 72524#

Thanks,
Gaurav

[DG: User Experience] QA testing season for 2.7 is open

2009-11-16T10:20:37Z

QA testing season for 2.7 is open

Hi potential QAérs,

It is QA season again for the 2.7 release and I am looking for people to actively help out. If you are interested you can sign up for the 2.7 cycle at: http://confluence.sakaiproject.org/display/QA/QA+Testers+Wall

Testing and coordination resources can be found under: http://confluence.sakaiproject.org/display/QA/2.7.0+Changes .
The 2.7.0-M1 milestone tag has been cut and deployment to QA servers is happening. A list of active QA server is mentioned at: http://confluence.sakaiproject.org/display/QA/QA+Servers+-+Sakai+2.7 These pages will be actively updated in the coming days.

If you want to help out with testing and this is the first time, you may think that the process is daunting. You are always welcome to contact me directly (on this email address) for a quiet chat. Your help is most welcome.

I will be making contact with the testers mentioned for the 2.6 cycle to drum up support and positive energy. I will also be contacting tomorrow the hard workers who are responsible for particular area's of Sakai to collect testplans to place in a viewable location on Confluence.

Rutgers will be donating some QA resources for December and January. On behalf of the Sakai Foundation I would like to thank them for their efforts.

Thank for your help, community. Any questions, I am open for conversations.

Regards

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg