UX working session update

classic Classic list List threaded Threaded
44 messages Options
123
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

UX working session update


Today's UX working session reviewed a few tweaks to the header area of the
site screen, plus a review of the "create page" screen.  Both can be found
here:

http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png

We also dove into the meatier topic of widgets/entities, which we've begun
calling vignettes (sorry to introduce more terminology, but we're hoping
this will be better choice of words in the long run).

As we see it, there are two major interaction themes within Sakai sites.
The first consists of pages that contain a smattering of content types;
ranging from text to functional bits called vignettes.  The second consists
of something called aggregate views (more on this later).

To illustrate the vignette idea a bit more clearly, we discussed the
following story:

An instructor creates a page titled "week 1" and in that pages provides a
short summary and informs students to read chapters 3 & 4.  Below this block
of text, she inserts a discussion vignette and adds a brief header to it
that reads "When you're done with chapter 3, discuss the following concept:
xyz".  The instructor then adds more text related to chapter 4, then addes a
series of multiple choice questions -- which appear by inserting survey
vignettes.  Below these questions, she continues to add more text that tells
her students to prepare a 5 page write-up on both chapters and submit it in
the bottom of the page, or into the drop box vignette.

A vignette would have a user-facing view as well as an edit/admin view.  The
latter would likely be presented during the edit page mode and the former
during the view page mode.  However there may be some carry over from one to
the other, as in the case of a preview option while in the edit mode.

As for aggregate views, they can be thought of as a central place that
consolidates a collection of all the vignettes that happen to be peppered
through a site.  Another way to think of it, which may or may not be
helpful, is as a conventional tool view.  To illustrate, one might imagine
the following story:

Before the start of a semester, the instructor has composed a bunch of pages
to teach his hybrid class.  Several of those pages include one or more
discussion vignettes.  As the semester gets under way, students begin
posting replies across a variety of pages, resulting in simultaneous
threaded discussion sprouting up throughout the site.  Rather than sifting
through all the pages in the site in order to keep up, the instructor simply
goes to the aggregate discussion view where he is presented with a UI that
is similar to a traditional discussion forum; with the exception that the
discussion topics and threads consist of the same stuff found in the
vignettes that are scattered throughout the site.

A few interesting points about this aggregate page view:  Similar to the
vignettes, this view would have a user-facing side and an admin control
panel of some sort.  Also, the aggregate view may be available only to the
site maintainer (or instructor in the above story) or to everyone (including
his students).  If the latter is true, than in theory, a student can engage
a particular discussion either inline on a page where a vignette is
presented, or by going into the aggregate "discussion forum" view.

Another side note to all of this is that when a new discussion vignette is
added to a page, it is then automatically pushed to the aggregate view and
collected there.  However, if a discussion post is added while in the
aggregate view, it is NOT automatically pushed to some site page.  This
implies that the aggregate view can contain more discussion posts than might
appear in the regular site pages.  However, probably any such post in the
aggregate view can be pulled into a page while the page is being composed.

We then briefly discussed the UX question of "how might a user locate one of
these aggregate views"?  We touched on a few ideas, but nothing worth
mentioning until we put a bit more thought into them.

Also, we focused on "threaded discussion" functionality to keep the model
manageable for now.  None of this has been tested on other functional
domains (i.e. calendar, survey, etc.) so it's hard to know if all of this
will hold water once we get there.

Cheers,
Nathan

--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


Sorry I couldn't make today's discussion, and particularly sorry since
I'm going to indulge a bit of grousing about the create page bits, but
I trust my stammering about the point yesterday may have prepared you
for this line of attack, and that you understand the appreciative
place it comes from ... so I can let my hair down.  I'm going to put
myself into the mind of an imagined, petulant user just to make a
point.

My gut instinct for the page creation suggested here is that there is
too much complexity.  Too many new words and ideas, too many
possibilities on the screen, too many pictures, etc.  Yes, it's done
in the guise of helping people make good decisions at the outset, but
I think it risks bewilderment by being overhelpful at the wrong time,
and emphasizing the wrong things.

There is a really simple concept at the core of the new page authoring
metaphor which seems to me both powerful and elegant.  You have a
page, and you can start typing and/or drop things into the page that
might be small (like a single assignment) or large (like a table of
all assignments).  But we bring little advantage to this simple
concept by trying to define new kinds of pages or laying out the full
spread of tools during the process of page creation.

By the same token, we're not helping people by presenting the default
option as a "blank page."  Of *course* I don't want a blank page: I'm
not going to choose that.  I want a page that will have stuff in it.
But rather than present me with a simple emphasis on how to quickly
start authoring a page you appear to be putting your effort into
front-loading my decision-making with a "page type," which
instinctively strikes me as an odd notion: unnecessary and unhelpful.

It's not about the *page*.  It's about what goes *in* the page.  I'm
trying to create my content and you keep trying to get me to look at
the margins or declare my full intent ahead of time.

In other words I think the design simply has the wrong focus at this
stage.  What if we instead focused design energies on making the
editing easy and flexible, and left the mere creation of the page
virtually transparent?  What if, instead of some dialogue asking about
what kind of page this will be, when I click on "create a new page"
I'm immediately there, or I'm immediately at a place that asks, "OK,
ta-da, you have your page: now what are you going to put in it?" (e.g.
with an interface that immediately leads me into either typing or
plugging in "vignettes")  Instead of emphasizing the page, emphasize
what I'm going to put in it by leading with *that* kind of choice
instead.

Stepping back for a moment from my frothy remarks (which, again, I
mean a bit playfully, but to make a point):  I don't mean to insist
that I really know what people want, but I do mean to suggest that I
think this really needs testing.

~Clay

On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]> wrote:

> Today's UX working session reviewed a few tweaks to the header area of the
> site screen, plus a review of the "create page" screen.  Both can be found
> here:
>
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>
> We also dove into the meatier topic of widgets/entities, which we've begun
> calling vignettes (sorry to introduce more terminology, but we're hoping
> this will be better choice of words in the long run).
>
> As we see it, there are two major interaction themes within Sakai sites.
> The first consists of pages that contain a smattering of content types;
> ranging from text to functional bits called vignettes.  The second consists
> of something called aggregate views (more on this later).
>
> To illustrate the vignette idea a bit more clearly, we discussed the
> following story:
>
> An instructor creates a page titled "week 1" and in that pages provides a
> short summary and informs students to read chapters 3 & 4.  Below this block
> of text, she inserts a discussion vignette and adds a brief header to it
> that reads "When you're done with chapter 3, discuss the following concept:
> xyz".  The instructor then adds more text related to chapter 4, then addes a
> series of multiple choice questions -- which appear by inserting survey
> vignettes.  Below these questions, she continues to add more text that tells
> her students to prepare a 5 page write-up on both chapters and submit it in
> the bottom of the page, or into the drop box vignette.
>
> A vignette would have a user-facing view as well as an edit/admin view.  The
> latter would likely be presented during the edit page mode and the former
> during the view page mode.  However there may be some carry over from one to
> the other, as in the case of a preview option while in the edit mode.
>
> As for aggregate views, they can be thought of as a central place that
> consolidates a collection of all the vignettes that happen to be peppered
> through a site.  Another way to think of it, which may or may not be
> helpful, is as a conventional tool view.  To illustrate, one might imagine
> the following story:
>
> Before the start of a semester, the instructor has composed a bunch of pages
> to teach his hybrid class.  Several of those pages include one or more
> discussion vignettes.  As the semester gets under way, students begin
> posting replies across a variety of pages, resulting in simultaneous
> threaded discussion sprouting up throughout the site.  Rather than sifting
> through all the pages in the site in order to keep up, the instructor simply
> goes to the aggregate discussion view where he is presented with a UI that
> is similar to a traditional discussion forum; with the exception that the
> discussion topics and threads consist of the same stuff found in the
> vignettes that are scattered throughout the site.
>
> A few interesting points about this aggregate page view:  Similar to the
> vignettes, this view would have a user-facing side and an admin control
> panel of some sort.  Also, the aggregate view may be available only to the
> site maintainer (or instructor in the above story) or to everyone (including
> his students).  If the latter is true, than in theory, a student can engage
> a particular discussion either inline on a page where a vignette is
> presented, or by going into the aggregate "discussion forum" view.
>
> Another side note to all of this is that when a new discussion vignette is
> added to a page, it is then automatically pushed to the aggregate view and
> collected there.  However, if a discussion post is added while in the
> aggregate view, it is NOT automatically pushed to some site page.  This
> implies that the aggregate view can contain more discussion posts than might
> appear in the regular site pages.  However, probably any such post in the
> aggregate view can be pulled into a page while the page is being composed.
>
> We then briefly discussed the UX question of "how might a user locate one of
> these aggregate views"?  We touched on a few ideas, but nothing worth
> mentioning until we put a bit more thought into them.
>
> Also, we focused on "threaded discussion" functionality to keep the model
> manageable for now.  None of this has been tested on other functional
> domains (i.e. calendar, survey, etc.) so it's hard to know if all of this
> will hold water once we get there.
>
> Cheers,
> Nathan
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace > Preferences.
>



--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


You're probably right.  There's still the issue of applying a page template
-- which should come before the edit page view.  Confluence does it in a bit
of a quirky way IMO where they drop you into the edit view, and if you
happen to see the subtle link to invoke a template, you can take a step back
to take two forward in applying a template.  I find this pattern to be a bit
clumsy.

Maybe the way to get the best of both worlds is to use a drop down when
clicking the Create New Page button that presents the options: Blank Page or
From Template.

Nathan

On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
<[hidden email]>wrote:

> Sorry I couldn't make today's discussion, and particularly sorry since
> I'm going to indulge a bit of grousing about the create page bits, but
> I trust my stammering about the point yesterday may have prepared you
> for this line of attack, and that you understand the appreciative
> place it comes from ... so I can let my hair down. I'm going to put
> myself into the mind of an imagined, petulant user just to make a
> point.
>
> My gut instinct for the page creation suggested here is that there is
> too much complexity. Too many new words and ideas, too many
> possibilities on the screen, too many pictures, etc. Yes, it's done
> in the guise of helping people make good decisions at the outset, but
> I think it risks bewilderment by being overhelpful at the wrong time,
> and emphasizing the wrong things.
>
> There is a really simple concept at the core of the new page authoring
> metaphor which seems to me both powerful and elegant. You have a
> page, and you can start typing and/or drop things into the page that
> might be small (like a single assignment) or large (like a table of
> all assignments). But we bring little advantage to this simple
> concept by trying to define new kinds of pages or laying out the full
> spread of tools during the process of page creation.
>
> By the same token, we're not helping people by presenting the default
> option as a "blank page." Of *course* I don't want a blank page: I'm
> not going to choose that. I want a page that will have stuff in it.
> But rather than present me with a simple emphasis on how to quickly
> start authoring a page you appear to be putting your effort into
> front-loading my decision-making with a "page type," which
> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>
> It's not about the *page*. It's about what goes *in* the page. I'm
> trying to create my content and you keep trying to get me to look at
> the margins or declare my full intent ahead of time.
>
> In other words I think the design simply has the wrong focus at this
> stage. What if we instead focused design energies on making the
> editing easy and flexible, and left the mere creation of the page
> virtually transparent? What if, instead of some dialogue asking about
> what kind of page this will be, when I click on "create a new page"
> I'm immediately there, or I'm immediately at a place that asks, "OK,
> ta-da, you have your page: now what are you going to put in it?" (e.g.
> with an interface that immediately leads me into either typing or
> plugging in "vignettes") Instead of emphasizing the page, emphasize
> what I'm going to put in it by leading with *that* kind of choice
> instead.
>
> Stepping back for a moment from my frothy remarks (which, again, I
> mean a bit playfully, but to make a point): I don't mean to insist
> that I really know what people want, but I do mean to suggest that I
> think this really needs testing.
>
> ~Clay
>
> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]>
> wrote:
> > Today's UX working session reviewed a few tweaks to the header area of
> the
> > site screen, plus a review of the "create page" screen. Both can be found
>
> > here:
> >
> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
> >
> > We also dove into the meatier topic of widgets/entities, which we've
> begun
> > calling vignettes (sorry to introduce more terminology, but we're hoping
> > this will be better choice of words in the long run).
> >
> > As we see it, there are two major interaction themes within Sakai sites.
> > The first consists of pages that contain a smattering of content types;
> > ranging from text to functional bits called vignettes. The second
> consists
> > of something called aggregate views (more on this later).
> >
> > To illustrate the vignette idea a bit more clearly, we discussed the
> > following story:
> >
> > An instructor creates a page titled "week 1" and in that pages provides a
>
> > short summary and informs students to read chapters 3 & 4. Below this
> block
> > of text, she inserts a discussion vignette and adds a brief header to it
> > that reads "When you're done with chapter 3, discuss the following
> concept:
> > xyz". The instructor then adds more text related to chapter 4, then addes
> a
> > series of multiple choice questions -- which appear by inserting survey
> > vignettes. Below these questions, she continues to add more text that
> tells
> > her students to prepare a 5 page write-up on both chapters and submit it
> in
> > the bottom of the page, or into the drop box vignette.
> >
> > A vignette would have a user-facing view as well as an edit/admin view.
> The
> > latter would likely be presented during the edit page mode and the former
>
> > during the view page mode. However there may be some carry over from one
> to
> > the other, as in the case of a preview option while in the edit mode.
> >
> > As for aggregate views, they can be thought of as a central place that
> > consolidates a collection of all the vignettes that happen to be peppered
>
> > through a site. Another way to think of it, which may or may not be
> > helpful, is as a conventional tool view. To illustrate, one might imagine
>
> > the following story:
> >
> > Before the start of a semester, the instructor has composed a bunch of
> pages
> > to teach his hybrid class. Several of those pages include one or more
> > discussion vignettes. As the semester gets under way, students begin
> > posting replies across a variety of pages, resulting in simultaneous
> > threaded discussion sprouting up throughout the site. Rather than sifting
>
> > through all the pages in the site in order to keep up, the instructor
> simply
> > goes to the aggregate discussion view where he is presented with a UI
> that
> > is similar to a traditional discussion forum; with the exception that the
>
> > discussion topics and threads consist of the same stuff found in the
> > vignettes that are scattered throughout the site.
> >
> > A few interesting points about this aggregate page view: Similar to the
> > vignettes, this view would have a user-facing side and an admin control
> > panel of some sort. Also, the aggregate view may be available only to the
>
> > site maintainer (or instructor in the above story) or to everyone
> (including
> > his students). If the latter is true, than in theory, a student can
> engage
> > a particular discussion either inline on a page where a vignette is
> > presented, or by going into the aggregate "discussion forum" view.
> >
> > Another side note to all of this is that when a new discussion vignette
> is
> > added to a page, it is then automatically pushed to the aggregate view
> and
> > collected there. However, if a discussion post is added while in the
> > aggregate view, it is NOT automatically pushed to some site page. This
> > implies that the aggregate view can contain more discussion posts than
> might
> > appear in the regular site pages. However, probably any such post in the
> > aggregate view can be pulled into a page while the page is being
> composed.
> >
> > We then briefly discussed the UX question of "how might a user locate one
> of
> > these aggregate views"? We touched on a few ideas, but nothing worth
> > mentioning until we put a bit more thought into them.
> >
> > Also, we focused on "threaded discussion" functionality to keep the model
>
> > manageable for now. None of this has been tested on other functional
> > domains (i.e. calendar, survey, etc.) so it's hard to know if all of this
>
> > will hold water once we get there.
> >
> > Cheers,
> > Nathan
> >
> > --
> > Nathan Pearson | UX Lead | Sakai Foundation
> >
> > E. [hidden email]
> > M. 602.418.5092
> > Y. npearson99 (Yahoo)
> > S. npearson99 (Skype)
> >
> >
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> > You can modify how you receive notifications at My Workspace >
> Preferences.
> >
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (
> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace > Preferences.
>



--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Korcuska Michael Korcuska
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


  A separate action for "new blank page" and "new page from template"?


Sent from my iPhone.

Le 16 janv. 09 à 04:09, "Nathan Pearson" <[hidden email]> a  
écrit :

> You're probably right.  There's still the issue of applying a page  
> template -- which should come before the edit page view.  Confluence  
> does it in a bit of a quirky way IMO where they drop you into the  
> edit view, and if you happen to see the subtle link to invoke a  
> template, you can take a step back to take two forward in applying a  
> template.  I find this pattern to be a bit clumsy.
>
> Maybe the way to get the best of both worlds is to use a drop down  
> when clicking the Create New Page button that presents the options:  
> Blank Page or From Template.
>
> Nathan
>
> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <[hidden email]
> > wrote:
> Sorry I couldn't make today's discussion, and particularly sorry since
> I'm going to indulge a bit of grousing about the create page bits, but
> I trust my stammering about the point yesterday may have prepared you
> for this line of attack, and that you understand the appreciative
> place it comes from ... so I can let my hair down. I'm going to put
> myself into the mind of an imagined, petulant user just to make a
> point.
>
> My gut instinct for the page creation suggested here is that there is
> too much complexity. Too many new words and ideas, too many
> possibilities on the screen, too many pictures, etc. Yes, it's done
> in the guise of helping people make good decisions at the outset, but
> I think it risks bewilderment by being overhelpful at the wrong time,
> and emphasizing the wrong things.
>
> There is a really simple concept at the core of the new page authoring
> metaphor which seems to me both powerful and elegant. You have a
> page, and you can start typing and/or drop things into the page that
> might be small (like a single assignment) or large (like a table of
> all assignments). But we bring little advantage to this simple
> concept by trying to define new kinds of pages or laying out the full
> spread of tools during the process of page creation.
>
> By the same token, we're not helping people by presenting the default
> option as a "blank page." Of *course* I don't want a blank page: I'm
> not going to choose that. I want a page that will have stuff in it.
> But rather than present me with a simple emphasis on how to quickly
> start authoring a page you appear to be putting your effort into
> front-loading my decision-making with a "page type," which
> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>
> It's not about the *page*. It's about what goes *in* the page. I'm
> trying to create my content and you keep trying to get me to look at
> the margins or declare my full intent ahead of time.
>
> In other words I think the design simply has the wrong focus at this
> stage. What if we instead focused design energies on making the
> editing easy and flexible, and left the mere creation of the page
> virtually transparent? What if, instead of some dialogue asking about
> what kind of page this will be, when I click on "create a new page"
> I'm immediately there, or I'm immediately at a place that asks, "OK,
> ta-da, you have your page: now what are you going to put in it?" (e.g.
> with an interface that immediately leads me into either typing or
> plugging in "vignettes") Instead of emphasizing the page, emphasize
> what I'm going to put in it by leading with *that* kind of choice
> instead.
>
> Stepping back for a moment from my frothy remarks (which, again, I
> mean a bit playfully, but to make a point): I don't mean to insist
> that I really know what people want, but I do mean to suggest that I
> think this really needs testing.
>
> ~Clay
>
> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson  
> <[hidden email]> wrote:
> > Today's UX working session reviewed a few tweaks to the header  
> area of the
> > site screen, plus a review of the "create page" screen. Both can  
> be found
> > here:
> >
> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
> >
> > We also dove into the meatier topic of widgets/entities, which  
> we've begun
> > calling vignettes (sorry to introduce more terminology, but we're  
> hoping
> > this will be better choice of words in the long run).
> >
> > As we see it, there are two major interaction themes within Sakai  
> sites.
> > The first consists of pages that contain a smattering of content  
> types;
> > ranging from text to functional bits called vignettes. The second  
> consists
> > of something called aggregate views (more on this later).
> >
> > To illustrate the vignette idea a bit more clearly, we discussed the
> > following story:
> >
> > An instructor creates a page titled "week 1" and in that pages  
> provides a
> > short summary and informs students to read chapters 3 & 4. Below  
> this block
> > of text, she inserts a discussion vignette and adds a brief header  
> to it
> > that reads "When you're done with chapter 3, discuss the following  
> concept:
> > xyz". The instructor then adds more text related to chapter 4,  
> then addes a
> > series of multiple choice questions -- which appear by inserting  
> survey
> > vignettes. Below these questions, she continues to add more text  
> that tells
> > her students to prepare a 5 page write-up on both chapters and  
> submit it in
> > the bottom of the page, or into the drop box vignette.
> >
> > A vignette would have a user-facing view as well as an edit/admin  
> view. The
> > latter would likely be presented during the edit page mode and the  
> former
> > during the view page mode. However there may be some carry over  
> from one to
> > the other, as in the case of a preview option while in the edit  
> mode.
> >
> > As for aggregate views, they can be thought of as a central place  
> that
> > consolidates a collection of all the vignettes that happen to be  
> peppered
> > through a site. Another way to think of it, which may or may not be
> > helpful, is as a conventional tool view. To illustrate, one might  
> imagine
> > the following story:
> >
> > Before the start of a semester, the instructor has composed a  
> bunch of pages
> > to teach his hybrid class. Several of those pages include one or  
> more
> > discussion vignettes. As the semester gets under way, students begin
> > posting replies across a variety of pages, resulting in simultaneous
> > threaded discussion sprouting up throughout the site. Rather than  
> sifting
> > through all the pages in the site in order to keep up, the  
> instructor simply
> > goes to the aggregate discussion view where he is presented with a  
> UI that
> > is similar to a traditional discussion forum; with the exception  
> that the
> > discussion topics and threads consist of the same stuff found in the
> > vignettes that are scattered throughout the site.
> >
> > A few interesting points about this aggregate page view: Similar  
> to the
> > vignettes, this view would have a user-facing side and an admin  
> control
> > panel of some sort. Also, the aggregate view may be available only  
> to the
> > site maintainer (or instructor in the above story) or to everyone  
> (including
> > his students). If the latter is true, than in theory, a student  
> can engage
> > a particular discussion either inline on a page where a vignette is
> > presented, or by going into the aggregate "discussion forum" view.
> >
> > Another side note to all of this is that when a new discussion  
> vignette is
> > added to a page, it is then automatically pushed to the aggregate  
> view and
> > collected there. However, if a discussion post is added while in the
> > aggregate view, it is NOT automatically pushed to some site page.  
> This
> > implies that the aggregate view can contain more discussion posts  
> than might
> > appear in the regular site pages.  However, probably any such post  
> in the
> > aggregate view can be pulled into a page while the page is being  
> composed.
> >
> > We then briefly discussed the UX question of "how might a user  
> locate one of
> > these aggregate views"? We touched on a few ideas, but nothing worth
> > mentioning until we put a bit more thought into them.
> >
> > Also, we focused on "threaded discussion" functionality to keep  
> the model
> > manageable for now. None of this has been tested on other functional
> > domains (i.e. calendar, survey, etc.) so it's hard to know if all  
> of this
> > will hold water once we get there.
> >
> > Cheers,
> > Nathan
> >
> > --
> > Nathan Pearson | UX Lead | Sakai Foundation
> >
> > E. [hidden email]
> > M. 602.418.5092
> > Y. npearson99 (Yahoo)
> > S. npearson99 (Skype)
> >
> > http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the WG: Authoring  
> site.
> > You can modify how you receive notifications at My Workspace >  
> Preferences.
> >
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


Yes, more or less.  The end result would be the same.. a page edit view.

On Thu, Jan 15, 2009 at 11:47 PM, Michael Korcuska <[hidden email]>wrote:

>  A separate action for "new blank page" and "new page from template"?
>
>
> Sent from my iPhone.
>
> Le 16 janv. 09 à 04:09, "Nathan Pearson" <[hidden email]> a écrit :
>
> You're probably right.  There's still the issue of applying a page template
> -- which should come before the edit page view.  Confluence does it in a bit
> of a quirky way IMO where they drop you into the edit view, and if you
> happen to see the subtle link to invoke a template, you can take a step back
> to take two forward in applying a template.  I find this pattern to be a bit
> clumsy.
>
> Maybe the way to get the best of both worlds is to use a drop down when
> clicking the Create New Page button that presents the options: Blank Page or
> From Template.
>
> Nathan
>
> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <<[hidden email]>
> [hidden email]> wrote:
>
>> Sorry I couldn't make today's discussion, and particularly sorry since
>> I'm going to indulge a bit of grousing about the create page bits, but
>> I trust my stammering about the point yesterday may have prepared you
>> for this line of attack, and that you understand the appreciative
>> place it comes from ... so I can let my hair down. I'm going to put
>> myself into the mind of an imagined, petulant user just to make a
>> point.
>>
>> My gut instinct for the page creation suggested here is that there is
>> too much complexity. Too many new words and ideas, too many
>> possibilities on the screen, too many pictures, etc. Yes, it's done
>> in the guise of helping people make good decisions at the outset, but
>> I think it risks bewilderment by being overhelpful at the wrong time,
>> and emphasizing the wrong things.
>>
>> There is a really simple concept at the core of the new page authoring
>> metaphor which seems to me both powerful and elegant. You have a
>> page, and you can start typing and/or drop things into the page that
>> might be small (like a single assignment) or large (like a table of
>> all assignments). But we bring little advantage to this simple
>> concept by trying to define new kinds of pages or laying out the full
>> spread of tools during the process of page creation.
>>
>> By the same token, we're not helping people by presenting the default
>> option as a "blank page." Of *course* I don't want a blank page: I'm
>> not going to choose that. I want a page that will have stuff in it.
>> But rather than present me with a simple emphasis on how to quickly
>> start authoring a page you appear to be putting your effort into
>> front-loading my decision-making with a "page type," which
>> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>>
>> It's not about the *page*. It's about what goes *in* the page. I'm
>> trying to create my content and you keep trying to get me to look at
>> the margins or declare my full intent ahead of time.
>>
>> In other words I think the design simply has the wrong focus at this
>> stage. What if we instead focused design energies on making the
>> editing easy and flexible, and left the mere creation of the page
>> virtually transparent? What if, instead of some dialogue asking about
>> what kind of page this will be, when I click on "create a new page"
>> I'm immediately there, or I'm immediately at a place that asks, "OK,
>> ta-da, you have your page: now what are you going to put in it?" (e.g.
>> with an interface that immediately leads me into either typing or
>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>> what I'm going to put in it by leading with *that* kind of choice
>> instead.
>>
>> Stepping back for a moment from my frothy remarks (which, again, I
>> mean a bit playfully, but to make a point): I don't mean to insist
>> that I really know what people want, but I do mean to suggest that I
>> think this really needs testing.
>>
>> ~Clay
>>
>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson < <[hidden email]>
>> [hidden email]> wrote:
>> > Today's UX working session reviewed a few tweaks to the header area of
>> the
>> > site screen, plus a review of the "create page" screen. Both can be
>> found
>> > here:
>> >
>> >
>> <http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png>
>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>> >
>> <http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png>
>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>> >
>> > We also dove into the meatier topic of widgets/entities, which we've
>> begun
>> > calling vignettes (sorry to introduce more terminology, but we're hoping
>>
>> > this will be better choice of words in the long run).
>> >
>> > As we see it, there are two major interaction themes within Sakai sites.
>>
>> > The first consists of pages that contain a smattering of content types;
>> > ranging from text to functional bits called vignettes. The second
>> consists
>> > of something called aggregate views (more on this later).
>> >
>> > To illustrate the vignette idea a bit more clearly, we discussed the
>> > following story:
>> >
>> > An instructor creates a page titled "week 1" and in that pages provides
>> a
>> > short summary and informs students to read chapters 3 & 4. Below this
>> block
>> > of text, she inserts a discussion vignette and adds a brief header to it
>>
>> > that reads "When you're done with chapter 3, discuss the following
>> concept:
>> > xyz". The instructor then adds more text related to chapter 4, then
>> addes a
>> > series of multiple choice questions -- which appear by inserting survey
>> > vignettes. Below these questions, she continues to add more text that
>> tells
>> > her students to prepare a 5 page write-up on both chapters and submit it
>> in
>> > the bottom of the page, or into the drop box vignette.
>> >
>> > A vignette would have a user-facing view as well as an edit/admin view.
>> The
>> > latter would likely be presented during the edit page mode and the
>> former
>> > during the view page mode. However there may be some carry over from one
>> to
>> > the other, as in the case of a preview option while in the edit mode.
>> >
>> > As for aggregate views, they can be thought of as a central place that
>> > consolidates a collection of all the vignettes that happen to be
>> peppered
>> > through a site. Another way to think of it, which may or may not be
>> > helpful, is as a conventional tool view. To illustrate, one might
>> imagine
>> > the following story:
>> >
>> > Before the start of a semester, the instructor has composed a bunch of
>> pages
>> > to teach his hybrid class. Several of those pages include one or more
>> > discussion vignettes. As the semester gets under way, students begin
>> > posting replies across a variety of pages, resulting in simultaneous
>> > threaded discussion sprouting up throughout the site. Rather than
>> sifting
>> > through all the pages in the site in order to keep up, the instructor
>> simply
>> > goes to the aggregate discussion view where he is presented with a UI
>> that
>> > is similar to a traditional discussion forum; with the exception that
>> the
>> > discussion topics and threads consist of the same stuff found in the
>> > vignettes that are scattered throughout the site.
>> >
>> > A few interesting points about this aggregate page view: Similar to the
>> > vignettes, this view would have a user-facing side and an admin control
>> > panel of some sort. Also, the aggregate view may be available only to
>> the
>> > site maintainer (or instructor in the above story) or to everyone
>> (including
>> > his students). If the latter is true, than in theory, a student can
>> engage
>> > a particular discussion either inline on a page where a vignette is
>> > presented, or by going into the aggregate "discussion forum" view.
>> >
>> > Another side note to all of this is that when a new discussion vignette
>> is
>> > added to a page, it is then automatically pushed to the aggregate view
>> and
>> > collected there. However, if a discussion post is added while in the
>> > aggregate view, it is NOT automatically pushed to some site page. This
>> > implies that the aggregate view can contain more discussion posts than
>> might
>> > appear in the regular site pages. However, probably any such post in the
>>
>> > aggregate view can be pulled into a page while the page is being
>> composed.
>> >
>> > We then briefly discussed the UX question of "how might a user locate
>> one of
>> > these aggregate views"? We touched on a few ideas, but nothing worth
>> > mentioning until we put a bit more thought into them.
>> >
>> > Also, we focused on "threaded discussion" functionality to keep the
>> model
>> > manageable for now. None of this has been tested on other functional
>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all of
>> this
>> > will hold water once we get there.
>> >
>> > Cheers,
>> > Nathan
>> >
>> > --
>> > Nathan Pearson | UX Lead | Sakai Foundation
>> >
>> > E. <[hidden email]>[hidden email]
>> > M. 602.418.5092
>> > Y. npearson99 (Yahoo)
>> > S. npearson99 (Skype)
>> >
>> >
>> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >
>> > ________________________________
>> > This automatic notification message was sent by Sakai Collab
>> > ( <https://collab.sakaiproject.org//portal>
>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> > You can modify how you receive notifications at My Workspace >
>> Preferences.
>> >
>>
>>
>>
>> --
>> Clay Fenlason
>> Director, Educational Technology
>> Georgia Institute of Technology
>> (404) 385-6644
>> ------------------------------
>>
>> This automatic notification message was sent by Sakai Collab (<https://collab.sakaiproject.org//portal>
>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. <[hidden email]>[hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
>
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (<https://collab.sakaiproject.org//portal>
> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
>


--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Daphne Ogle Daphne Ogle
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update

In reply to this post by Nathan Pearson

To add to the comparison with confluence, (being bad here with self  
referential design but I think it applies more broadly) I know the  
subtle "template" link is there but I ignore it because I'm almost  
always in a hurry when I create a page in confluence and "template"  
doesn't hold any value for me.  If I knew there were templates that  
would make my work easier perhaps I would use it.   So I think it's  
more than just making sure users see that there are templates.  When  
we ask them if they want to use a template, I think we should also  
allow them to discover the kinds of templates there are and they can  
help me in my work.  Some users will be curious and play around with  
options such as templates but what we find often in user research is  
that users are very busy and will go the most direct route they can.  
I guess what I'm contemplating is, "Is the word template enough  
information scent to allow users to know why they should choose it?"

-Daphne


On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:

> You're probably right.  There's still the issue of applying a page  
> template -- which should come before the edit page view.  Confluence  
> does it in a bit of a quirky way IMO where they drop you into the  
> edit view, and if you happen to see the subtle link to invoke a  
> template, you can take a step back to take two forward in applying a  
> template.  I find this pattern to be a bit clumsy.
>
> Maybe the way to get the best of both worlds is to use a drop down  
> when clicking the Create New Page button that presents the options:  
> Blank Page or From Template.
>
> Nathan
>
> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <[hidden email]
> > wrote:
> Sorry I couldn't make today's discussion, and particularly sorry since
> I'm going to indulge a bit of grousing about the create page bits, but
> I trust my stammering about the point yesterday may have prepared you
> for this line of attack, and that you understand the appreciative
> place it comes from ... so I can let my hair down. I'm going to put
> myself into the mind of an imagined, petulant user just to make a
> point.
>
> My gut instinct for the page creation suggested here is that there is
> too much complexity. Too many new words and ideas, too many
> possibilities on the screen, too many pictures, etc. Yes, it's done
> in the guise of helping people make good decisions at the outset, but
> I think it risks bewilderment by being overhelpful at the wrong time,
> and emphasizing the wrong things.
>
> There is a really simple concept at the core of the new page authoring
> metaphor which seems to me both powerful and elegant. You have a
> page, and you can start typing and/or drop things into the page that
> might be small (like a single assignment) or large (like a table of
> all assignments). But we bring little advantage to this simple
> concept by trying to define new kinds of pages or laying out the full
> spread of tools during the process of page creation.
>
> By the same token, we're not helping people by presenting the default
> option as a "blank page." Of *course* I don't want a blank page: I'm
> not going to choose that. I want a page that will have stuff in it.
> But rather than present me with a simple emphasis on how to quickly
> start authoring a page you appear to be putting your effort into
> front-loading my decision-making with a "page type," which
> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>
> It's not about the *page*. It's about what goes *in* the page. I'm
> trying to create my content and you keep trying to get me to look at
> the margins or declare my full intent ahead of time.
>
> In other words I think the design simply has the wrong focus at this
> stage. What if we instead focused design energies on making the
> editing easy and flexible, and left the mere creation of the page
> virtually transparent? What if, instead of some dialogue asking about
> what kind of page this will be, when I click on "create a new page"
> I'm immediately there, or I'm immediately at a place that asks, "OK,
> ta-da, you have your page: now what are you going to put in it?" (e.g.
> with an interface that immediately leads me into either typing or
> plugging in "vignettes") Instead of emphasizing the page, emphasize
> what I'm going to put in it by leading with *that* kind of choice
> instead.
>
> Stepping back for a moment from my frothy remarks (which, again, I
> mean a bit playfully, but to make a point): I don't mean to insist
> that I really know what people want, but I do mean to suggest that I
> think this really needs testing.
>
> ~Clay
>
> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson  
> <[hidden email]> wrote:
> > Today's UX working session reviewed a few tweaks to the header  
> area of the
> > site screen, plus a review of the "create page" screen. Both can  
> be found
> > here:
> >
> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
> >
> > We also dove into the meatier topic of widgets/entities, which  
> we've begun
> > calling vignettes (sorry to introduce more terminology, but we're  
> hoping
> > this will be better choice of words in the long run).
> >
> > As we see it, there are two major interaction themes within Sakai  
> sites.
> > The first consists of pages that contain a smattering of content  
> types;
> > ranging from text to functional bits called vignettes. The second  
> consists
> > of something called aggregate views (more on this later).
> >
> > To illustrate the vignette idea a bit more clearly, we discussed the
> > following story:
> >
> > An instructor creates a page titled "week 1" and in that pages  
> provides a
> > short summary and informs students to read chapters 3 & 4. Below  
> this block
> > of text, she inserts a discussion vignette and adds a brief header  
> to it
> > that reads "When you're done with chapter 3, discuss the following  
> concept:
> > xyz". The instructor then adds more text related to chapter 4,  
> then addes a
> > series of multiple choice questions -- which appear by inserting  
> survey
> > vignettes. Below these questions, she continues to add more text  
> that tells
> > her students to prepare a 5 page write-up on both chapters and  
> submit it in
> > the bottom of the page, or into the drop box vignette.
> >
> > A vignette would have a user-facing view as well as an edit/admin  
> view. The
> > latter would likely be presented during the edit page mode and the  
> former
> > during the view page mode. However there may be some carry over  
> from one to
> > the other, as in the case of a preview option while in the edit  
> mode.
> >
> > As for aggregate views, they can be thought of as a central place  
> that
> > consolidates a collection of all the vignettes that happen to be  
> peppered
> > through a site. Another way to think of it, which may or may not be
> > helpful, is as a conventional tool view. To illustrate, one might  
> imagine
> > the following story:
> >
> > Before the start of a semester, the instructor has composed a  
> bunch of pages
> > to teach his hybrid class. Several of those pages include one or  
> more
> > discussion vignettes. As the semester gets under way, students begin
> > posting replies across a variety of pages, resulting in simultaneous
> > threaded discussion sprouting up throughout the site. Rather than  
> sifting
> > through all the pages in the site in order to keep up, the  
> instructor simply
> > goes to the aggregate discussion view where he is presented with a  
> UI that
> > is similar to a traditional discussion forum; with the exception  
> that the
> > discussion topics and threads consist of the same stuff found in the
> > vignettes that are scattered throughout the site.
> >
> > A few interesting points about this aggregate page view: Similar  
> to the
> > vignettes, this view would have a user-facing side and an admin  
> control
> > panel of some sort. Also, the aggregate view may be available only  
> to the
> > site maintainer (or instructor in the above story) or to everyone  
> (including
> > his students). If the latter is true, than in theory, a student  
> can engage
> > a particular discussion either inline on a page where a vignette is
> > presented, or by going into the aggregate "discussion forum" view.
> >
> > Another side note to all of this is that when a new discussion  
> vignette is
> > added to a page, it is then automatically pushed to the aggregate  
> view and
> > collected there. However, if a discussion post is added while in the
> > aggregate view, it is NOT automatically pushed to some site page.  
> This
> > implies that the aggregate view can contain more discussion posts  
> than might
> > appear in the regular site pages. However, probably any such post  
> in the
> > aggregate view can be pulled into a page while the page is being  
> composed.
> >
> > We then briefly discussed the UX question of "how might a user  
> locate one of
> > these aggregate views"? We touched on a few ideas, but nothing worth
> > mentioning until we put a bit more thought into them.
> >
> > Also, we focused on "threaded discussion" functionality to keep  
> the model
> > manageable for now. None of this has been tested on other functional
> > domains (i.e. calendar, survey, etc.) so it's hard to know if all  
> of this
> > will hold water once we get there.
> >
> > Cheers,
> > Nathan
> >
> > --
> > Nathan Pearson | UX Lead | Sakai Foundation
> >
> > E. [hidden email]
> > M. 602.418.5092
> > Y. npearson99 (Yahoo)
> > S. npearson99 (Skype)
> >
> > http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the WG: Authoring  
> site.
> > You can modify how you receive notifications at My Workspace >  
> Preferences.
> >
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[hidden email]
cell (510)847-0308




----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


I think it will come down to the affordance of where the option is displayed
on the screen, the context, and the terminology.  This is what I had in mind
based on Clay's comments:

http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png

It still forces the user to make a choice, but the imposition isn't
significant and can easily be ignored.  If we push the idea too far out of
one's reach or periphery, then we risk making it too inefficient to get at.

Nathan


On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <[hidden email]>wrote:

> To add to the comparison with confluence, (being bad here with self
> referential design but I think it applies more broadly) I know the subtle
> "template" link is there but I ignore it because I'm almost always in a
> hurry when I create a page in confluence and "template" doesn't hold any
> value for me.  If I knew there were templates that would make my work easier
> perhaps I would use it.   So I think it's more than just making sure users
> see that there are templates.  When we ask them if they want to use a
> template, I think we should also allow them to discover the kinds of
> templates there are and they can help me in my work.  Some users will be
> curious and play around with options such as templates but what we find
> often in user research is that users are very busy and will go the most
> direct route they can.  I guess what I'm contemplating is, "Is the word
> template enough information scent to allow users to know why they should
> choose it?"
> -Daphne
>
>
> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>
> You're probably right.  There's still the issue of applying a page template
> -- which should come before the edit page view.  Confluence does it in a bit
> of a quirky way IMO where they drop you into the edit view, and if you
> happen to see the subtle link to invoke a template, you can take a step back
> to take two forward in applying a template.  I find this pattern to be a bit
> clumsy.
>
> Maybe the way to get the best of both worlds is to use a drop down when
> clicking the Create New Page button that presents the options: Blank Page or
> From Template.
>
> Nathan
>
> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <
> [hidden email]> wrote:
>
>> Sorry I couldn't make today's discussion, and particularly sorry since
>> I'm going to indulge a bit of grousing about the create page bits, but
>> I trust my stammering about the point yesterday may have prepared you
>> for this line of attack, and that you understand the appreciative
>> place it comes from ... so I can let my hair down. I'm going to put
>> myself into the mind of an imagined, petulant user just to make a
>> point.
>>
>> My gut instinct for the page creation suggested here is that there is
>> too much complexity. Too many new words and ideas, too many
>> possibilities on the screen, too many pictures, etc. Yes, it's done
>> in the guise of helping people make good decisions at the outset, but
>> I think it risks bewilderment by being overhelpful at the wrong time,
>> and emphasizing the wrong things.
>>
>> There is a really simple concept at the core of the new page authoring
>> metaphor which seems to me both powerful and elegant. You have a
>> page, and you can start typing and/or drop things into the page that
>> might be small (like a single assignment) or large (like a table of
>> all assignments). But we bring little advantage to this simple
>> concept by trying to define new kinds of pages or laying out the full
>> spread of tools during the process of page creation.
>>
>> By the same token, we're not helping people by presenting the default
>> option as a "blank page." Of *course* I don't want a blank page: I'm
>> not going to choose that. I want a page that will have stuff in it.
>> But rather than present me with a simple emphasis on how to quickly
>> start authoring a page you appear to be putting your effort into
>> front-loading my decision-making with a "page type," which
>> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>>
>> It's not about the *page*. It's about what goes *in* the page. I'm
>> trying to create my content and you keep trying to get me to look at
>> the margins or declare my full intent ahead of time.
>>
>> In other words I think the design simply has the wrong focus at this
>> stage. What if we instead focused design energies on making the
>> editing easy and flexible, and left the mere creation of the page
>> virtually transparent? What if, instead of some dialogue asking about
>> what kind of page this will be, when I click on "create a new page"
>> I'm immediately there, or I'm immediately at a place that asks, "OK,
>> ta-da, you have your page: now what are you going to put in it?" (e.g.
>> with an interface that immediately leads me into either typing or
>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>> what I'm going to put in it by leading with *that* kind of choice
>> instead.
>>
>> Stepping back for a moment from my frothy remarks (which, again, I
>> mean a bit playfully, but to make a point): I don't mean to insist
>> that I really know what people want, but I do mean to suggest that I
>> think this really needs testing.
>>
>> ~Clay
>>
>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]>
>> wrote:
>> > Today's UX working session reviewed a few tweaks to the header area of
>> the
>> > site screen, plus a review of the "create page" screen. Both can be
>> found
>> > here:
>> >
>> >
>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>> >
>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>> >
>> > We also dove into the meatier topic of widgets/entities, which we've
>> begun
>> > calling vignettes (sorry to introduce more terminology, but we're hoping
>>
>> > this will be better choice of words in the long run).
>> >
>> > As we see it, there are two major interaction themes within Sakai sites.
>>
>> > The first consists of pages that contain a smattering of content types;
>> > ranging from text to functional bits called vignettes. The second
>> consists
>> > of something called aggregate views (more on this later).
>> >
>> > To illustrate the vignette idea a bit more clearly, we discussed the
>> > following story:
>> >
>> > An instructor creates a page titled "week 1" and in that pages provides
>> a
>> > short summary and informs students to read chapters 3 & 4. Below this
>> block
>> > of text, she inserts a discussion vignette and adds a brief header to it
>>
>> > that reads "When you're done with chapter 3, discuss the following
>> concept:
>> > xyz". The instructor then adds more text related to chapter 4, then
>> addes a
>> > series of multiple choice questions -- which appear by inserting survey
>> > vignettes. Below these questions, she continues to add more text that
>> tells
>> > her students to prepare a 5 page write-up on both chapters and submit it
>> in
>> > the bottom of the page, or into the drop box vignette.
>> >
>> > A vignette would have a user-facing view as well as an edit/admin view.
>> The
>> > latter would likely be presented during the edit page mode and the
>> former
>> > during the view page mode. However there may be some carry over from one
>> to
>> > the other, as in the case of a preview option while in the edit mode.
>> >
>> > As for aggregate views, they can be thought of as a central place that
>> > consolidates a collection of all the vignettes that happen to be
>> peppered
>> > through a site. Another way to think of it, which may or may not be
>> > helpful, is as a conventional tool view. To illustrate, one might
>> imagine
>> > the following story:
>> >
>> > Before the start of a semester, the instructor has composed a bunch of
>> pages
>> > to teach his hybrid class. Several of those pages include one or more
>> > discussion vignettes. As the semester gets under way, students begin
>> > posting replies across a variety of pages, resulting in simultaneous
>> > threaded discussion sprouting up throughout the site. Rather than
>> sifting
>> > through all the pages in the site in order to keep up, the instructor
>> simply
>> > goes to the aggregate discussion view where he is presented with a UI
>> that
>> > is similar to a traditional discussion forum; with the exception that
>> the
>> > discussion topics and threads consist of the same stuff found in the
>> > vignettes that are scattered throughout the site.
>> >
>> > A few interesting points about this aggregate page view: Similar to the
>> > vignettes, this view would have a user-facing side and an admin control
>> > panel of some sort. Also, the aggregate view may be available only to
>> the
>> > site maintainer (or instructor in the above story) or to everyone
>> (including
>> > his students). If the latter is true, than in theory, a student can
>> engage
>> > a particular discussion either inline on a page where a vignette is
>> > presented, or by going into the aggregate "discussion forum" view.
>> >
>> > Another side note to all of this is that when a new discussion vignette
>> is
>> > added to a page, it is then automatically pushed to the aggregate view
>> and
>> > collected there. However, if a discussion post is added while in the
>> > aggregate view, it is NOT automatically pushed to some site page. This
>> > implies that the aggregate view can contain more discussion posts than
>> might
>> > appear in the regular site pages. However, probably any such post in the
>>
>> > aggregate view can be pulled into a page while the page is being
>> composed.
>> >
>> > We then briefly discussed the UX question of "how might a user locate
>> one of
>> > these aggregate views"? We touched on a few ideas, but nothing worth
>> > mentioning until we put a bit more thought into them.
>> >
>> > Also, we focused on "threaded discussion" functionality to keep the
>> model
>> > manageable for now. None of this has been tested on other functional
>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all of
>> this
>> > will hold water once we get there.
>> >
>> > Cheers,
>> > Nathan
>> >
>> > --
>> > Nathan Pearson | UX Lead | Sakai Foundation
>> >
>> > E. [hidden email]
>> > M. 602.418.5092
>> > Y. npearson99 (Yahoo)
>> > S. npearson99 (Skype)
>> >
>> >
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >
>> > ________________________________
>> > This automatic notification message was sent by Sakai Collab
>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> > You can modify how you receive notifications at My Workspace >
>> Preferences.
>> >
>>
>>
>>
>> --
>> Clay Fenlason
>> Director, Educational Technology
>> Georgia Institute of Technology
>> (404) 385-6644
>> ------------------------------
>>
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (
> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
>
> Daphne Ogle
> Senior Interaction Designer
> University of California, Berkeley
> Educational Technology Services
> [hidden email]
> cell (510)847-0308
>
>
>
>


--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Feldstein Michael Feldstein
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


Hmm.

I just was helping my wife wrestle with Blackboard CE8 today, and this
is mock-up is suddenly feeling a little familiar. And not in a good way.
My sense is that WebCT started off with the same idea that people should
just be able to assemble pages and put anything they want on them. The
execution was particularly clunky, probably in part because of the
technology base they were dealing with at the time they designed the
system. But beyond that, I'm not sure that the typical faculty member
thinks of putting together their course in terms of assembling pages
first and then putting functionality on the pages. Maybe it's possible
to execute the concept in a way that makes it more intuitive than it is
in CE (in fact, I'm sure of it), but I just don't know if "Create a New
Page" carries the semantic freight necessary.

- m


Nathan Pearson wrote:

> I think it will come down to the affordance of where the option is
> displayed on the screen, the context, and the terminology.  This is
> what I had in mind based on Clay's comments:
>
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>
> It still forces the user to make a choice, but the imposition isn't
> significant and can easily be ignored.  If we push the idea too far
> out of one's reach or periphery, then we risk making it too
> inefficient to get at.
>
> Nathan
>
>
> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     To add to the comparison with confluence, (being bad here with
>     self referential design but I think it applies more broadly) I
>     know the subtle "template" link is there but I ignore it because
>     I'm almost always in a hurry when I create a page in confluence
>     and "template" doesn't hold any value for me.  If I knew there
>     were templates that would make my work easier perhaps I would use
>     it.   So I think it's more than just making sure users see that
>     there are templates  When we ask them if they want to use a
>     template, I think we should also allow them to discover the kinds
>     of templates there are and they can help me in my work.  Some
>     users will be curious and play around with options such as
>     templates but what we find often in user research is that users
>     are very busy and will go the most direct route they can.  I guess
>     what I'm contemplating is, "Is the word template enough
>     information scent to allow users to know why they should choose it?"
>
>     -Daphne
>
>
>     On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>
>>     You're probably right.  There's still the issue of applying a
>>     page template -- which should come before the edit page view.
>>     Confluence does it in a bit of a quirky way IMO where they drop
>>     you into the edit view, and if you happen to see the subtle link
>>     to invoke a template, you can take a step back to take two
>>     forward in applying a template.  I find this pattern to be a bit
>>     clumsy.
>>
>>     Maybe the way to get the best of both worlds is to use a drop
>>     down when clicking the Create New Page button that presents the
>>     options: Blank Page or From Template.
>>
>>     Nathan
>>
>>     On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
>>     <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>         Sorry I couldn't make today's discussion, and particularly
>>         sorry since
>>         I'm going to indulge a bit of grousing about the create page
>>         bits, but
>>         I trust my stammering about the point yesterday may have
>>         prepared you
>>         for this line of attack, and that you understand the
>>         appreciative
>>         place it comes from ... so I can let my hair down. I'm going
>>         to put
>>         myself into the mind of an imagined, petulant user just to
>>         make a
>>         point.
>>
>>         My gut instinct for the page creation suggested here is that
>>         there is
>>         too much complexity. Too many new words and ideas, too many
>>         possibilities on the screen, too many pictures, etc. Yes,
>>         it's done
>>         in the guise of helping people make good decisions at the
>>         outset, but
>>         I think it risks bewilderment by being overhelpful at the
>>         wrong time,
>>         and emphasizing the wrong things.
>>
>>         There is a really simple concept at the core of the new page
>>         authoring
>>         metaphor which seems to me both powerful and elegant. You have a
>>         page, and you can start typing and/or drop things into the
>>         page that
>>         might be small (like a single assignment) or large (like a
>>         table of
>>         all assignments). But we bring little advantage to this simple
>>         concept by trying to define new kinds of pages or laying out
>>         the full
>>         spread of tools during the process of page creation.
>>
>>         By the same token, we're not helping people by presenting the
>>         default
>>         option as a "blank page." Of *course* I don't want a blank
>>         page: I'm
>>         not going to choose that. I want a page that will have stuff
>>         in it.
>>         But rather than present me with a simple emphasis on how to
>>         quickly
>>         start authoring a page you appear to be putting your effort into
>>         front-loading my decision-making with a "page type," which
>>         instinctively strikes me as an odd notion: unnecessary and
>>         unhelpful.
>>
>>         It's not about the *page*. It's about what goes *in* the
>>         page. I'm
>>         trying to create my content and you keep trying to get me to
>>         look at
>>         the margins or declare my full intent ahead of time.
>>
>>         In other words I think the design simply has the wrong focus
>>         at this
>>         stage. What if we instead focused design energies on making the
>>         editing easy and flexible, and left the mere creation of the
>>         page
>>         virtually transparent? What if, instead of some dialogue
>>         asking about
>>         what kind of page this will be, when I click on "create a new
>>         page"
>>         I'm immediately there, or I'm immediately at a place that
>>         asks, "OK,
>>         ta-da, you have your page: now what are you going to put in
>>         it?" (e.g.
>>         with an interface that immediately leads me into either
>>         typing or
>>         plugging in "vignettes") Instead of emphasizing the page,
>>         emphasize
>>         what I'm going to put in it by leading with *that* kind of
>>         choice
>>         instead.
>>
>>         Stepping back for a moment from my frothy remarks (which,
>>         again, I
>>         mean a bit playfully, but to make a point): I don't mean to
>>         insist
>>         that I really know what people want, but I do mean to suggest
>>         that I
>>         think this really needs testing.
>>
>>         ~Clay
>>
>>         On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
>>         <[hidden email] <mailto:[hidden email]>> wrote:
>>         > Today's UX working session reviewed a few tweaks to the
>>         header area of the
>>         > site screen, plus a review of the "create page" screen.
>>         Both can be found
>>         > here:
>>         >
>>         >
>>         http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>
>>         >
>>         http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>
>>         >
>>         > We also dove into the meatier topic of widgets/entities,
>>         which we've begun
>>         > calling vignettes (sorry to introduce more terminology, but
>>         we're hoping
>>         > this will be better choice of words in the long run).
>>         >
>>         > As we see it, there are two major interaction themes within
>>         Sakai sites.
>>         > The first consists of pages that contain a smattering of
>>         content types;
>>         > ranging from text to functional bits called vignettes. The
>>         second consists
>>         > of something called aggregate views (more on this later).
>>         >
>>         > To illustrate the vignette idea a bit more clearly, we
>>         discussed the
>>         > following story:
>>         >
>>         > An instructor creates a page titled "week 1" and in that
>>         pages provides a
>>         > short summary and informs students to read chapters 3 & 4.
>>         Below this block
>>         > of text, she inserts a discussion vignette and adds a brief
>>         header to it
>>         > that reads "When you're done with chapter 3, discuss the
>>         following concept:
>>         > xyz". The instructor then adds more text related to chapter
>>         4, then addes a
>>         > series of multiple choice questions -- which appear by
>>         inserting survey
>>         > vignettes. Below these questions, she continues to add more
>>         text that tells
>>         > her students to prepare a 5 page write-up on both chapters
>>         and submit it in
>>         > the bottom of the page, or into the drop box vignette.
>>         >
>>         > A vignette would have a user-facing view as well as an
>>         edit/admin view. The
>>         > latter would likely be presented during the edit page mode
>>         and the former
>>         > during the view page mode. However there may be some carry
>>         over from one to
>>         > the other, as in the case of a preview option while in the
>>         edit mode.
>>         >
>>         > As for aggregate views, they can be thought of as a central
>>         place that
>>         > consolidates a collection of all the vignettes that happen
>>         to be peppered
>>         > through a site. Another way to think of it, which may or
>>         may not be
>>         > helpful, is as a conventional tool view. To illustrate, one
>>         might imagine
>>         > the following story:
>>         >
>>         > Before the start of a semester, the instructor has composed
>>         a bunch of pages
>>         > to teach his hybrid class. Several of those pages include
>>         one or more
>>         > discussion vignettes. As the semester gets under way,
>>         students begin
>>         > posting replies across a variety of pages, resulting in
>>         simultaneous
>>         > threaded discussion sprouting up throughout the site.
>>         Rather than sifting
>>         > through all the pages in the site in order to keep up, the
>>         instructor simply
>>         > goes to the aggregate discussion view where he is presented
>>         with a UI that
>>         > is similar to a traditional discussion forum; with the
>>         exception that the
>>         > discussion topics and threads consist of the same stuff
>>         found in the
>>         > vignettes that are scattered throughout the site.
>>         >
>>         > A few interesting points about this aggregate page view:
>>         Similar to the
>>         > vignettes, this view would have a user-facing side and an
>>         admin control
>>         > panel of some sort. Also, the aggregate view may be
>>         available only to the
>>         > site maintainer (or instructor in the above story) or to
>>         everyone (including
>>         > his students). If the latter is true, than in theory, a
>>         student can engage
>>         > a particular discussion either inline on a page where a
>>         vignette is
>>         > presented, or by going into the aggregate "discussion
>>         forum" view.
>>         >
>>         > Another side note to all of this is that when a new
>>         discussion vignette is
>>         > added to a page, it is then automatically pushed to the
>>         aggregate view and
>>         > collected there. However, if a discussion post is added
>>         while in the
>>         > aggregate view, it is NOT automatically pushed to some site
>>         page. This
>>         > implies that the aggregate view can contain more discussion
>>         posts than might
>>         > appear in the regular site pages. However, probably any
>>         such post in the
>>         > aggregate view can be pulled into a page while the page is
>>         being composed.
>>         >
>>         > We then briefly discussed the UX question of "how might a
>>         user locate one of
>>         > these aggregate views"? We touched on a few ideas, but
>>         nothing worth
>>         > mentioning until we put a bit more thought into them.
>>         >
>>         > Also, we focused on "threaded discussion" functionality to
>>         keep the model
>>         > manageable for now. None of this has been tested on other
>>         functional
>>         > domains (i.e. calendar, survey, etc.) so it's hard to know
>>         if all of this
>>         > will hold water once we get there.
>>         >
>>         > Cheers,
>>         > Nathan
>>         >
>>         > --
>>         > Nathan Pearson | UX Lead | Sakai Foundation
>>         >
>>         > E. [hidden email] <mailto:[hidden email]>
>>         > M. 602.418.5092
>>         > Y. npearson99 (Yahoo)
>>         > S. npearson99 (Skype)
>>         >
>>         >
>>         http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>         <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40groupcalendar.google.com&ctz=America/Phoenix>
>>
>>         >
>>         > ________________________________
>>         > This automatic notification message was sent by Sakai Collab
>>         > (https://collab.sakaiproject.org//portal) from the WG:
>>         Authoring site.
>>         > You can modify how you receive notifications at My
>>         Workspace > Preferences.
>>         >
>>
>>
>>
>>         --
>>         Clay Fenlason
>>         Director, Educational Technology
>>         Georgia Institute of Technology
>>         (404) 385-6644
>>         ------------------------------------------------------------------------
>>
>>         This automatic notification message was sent by Sakai Collab
>>         (https://collab.sakaiproject.org//portal) from the WG:
>>         Authoring site.
>>         You can modify how you receive notifications at My Workspace
>>         > Preferences.
>>
>>
>>
>>
>>     --
>>     Nathan Pearson | UX Lead | Sakai Foundation
>>
>>     E. [hidden email] <mailto:[hidden email]>
>>     M. 602.418.5092
>>     Y npearson99 (Yahoo)
>>     S. npearson99 (Skype)
>>
>>     http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>     <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>>
>>     ------------------------------------------------------------------------
>>
>>     This automatic notification message was sent by Sakai Collab
>>     (https://collab.sakaiproject.org//portal) from the WG: Authoring
>>     site.
>>     You can modify how you receive notifications at My Workspace >
>>     Preferences.
>
>     Daphne Ogle
>     Senior Interaction Designer
>     University of California, Berkeley
>     Educational Technology Services
>     [hidden email] <mailto:[hidden email]>
>     cell (510)847-0308
>
>
>
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email] <mailto:[hidden email]>
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> ------------------------------------------------------------------------
>
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the DG: User Experience
> site.
> You can modify how you receive notifications at My Workspace >
> Preferences.

--


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
[see attachment: "oracle_sig_logo.gif", size: 658 bytes]



Attachments:

oracle_sig_logo.gif
https://collab.sakaiproject.org//access/content/attachment/cb772042-db42-4941-a754-04ecb9df020f/oracle_sig_logo.gif

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


I'm not sure I understand the feedback.  What do you have in mind as a
better way to do it?


On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein <
[hidden email]> wrote:

>  Hmm.
>
> I just was helping my wife wrestle with Blackboard CE8 today, and this is
> mock-up is suddenly feeling a little familiar. And not in a good way. My
> sense is that WebCT started off with the same idea that people should just
> be able to assemble pages and put anything they want on them. The execution
> was particularly clunky, probably in part because of the technology base
> they were dealing with at the time they designed the system. But beyond
> that, I'm not sure that the typical faculty member thinks of putting
> together their course in terms of assembling pages first and then putting
> functionality on the pages. Maybe it's possible to execute the concept in a
> way that makes it more intuitive than it is in CE (in fact, I'm sure of it),
> but I just don't know if "Create a New Page" carries the semantic freight
> necessary.
>
> - m
>
>
> Nathan Pearson wrote:
>
> I think it will come down to the affordance of where the option is
> displayed on the screen, the context, and the terminology.  This is what I
> had in mind based on Clay's comments:
>
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>
> It still forces the user to make a choice, but the imposition isn't
> significant and can easily be ignored.  If we push the idea too far out of
> one's reach or periphery, then we risk making it too inefficient to get at.
>
> Nathan
>
>
> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <[hidden email]>wrote:
>
>> To add to the comparison with confluence, (being bad here with self
>> referential design but I think it applies more broadly) I know the subtle
>> "template" link is there but I ignore it because I'm almost always in a
>> hurry when I create a page in confluence and "template" doesn't hold any
>> value for me.  If I knew there were templates that would make my work easier
>> perhaps I would use it.   So I think it's more than just making sure users
>> see that there are templates  When we ask them if they want to use a
>> template, I think we should also allow them to discover the kinds of
>> templates there are and they can help me in my work.  Some users will be
>> curious and play around with options such as templates but what we find
>> often in user research is that users are very busy and will go the most
>> direct route they can.  I guess what I'm contemplating is, "Is the word
>> template enough information scent to allow users to know why they should
>> choose it?"
>>  -Daphne
>>
>>
>>   On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>>
>>    You're probably right.  There's still the issue of applying a page
>> template -- which should come before the edit page view.  Confluence does it
>> in a bit of a quirky way IMO where they drop you into the edit view, and if
>> you happen to see the subtle link to invoke a template, you can take a step
>> back to take two forward in applying a template.  I find this pattern to be
>> a bit clumsy.
>>
>> Maybe the way to get the best of both worlds is to use a drop down when
>> clicking the Create New Page button that presents the options: Blank Page or
>> From Template.
>>
>> Nathan
>>
>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <
>> [hidden email]> wrote:
>>
>>> Sorry I couldn't make today's discussion, and particularly sorry since
>>> I'm going to indulge a bit of grousing about the create page bits, but
>>> I trust my stammering about the point yesterday may have prepared you
>>> for this line of attack, and that you understand the appreciative
>>> place it comes from ... so I can let my hair down. I'm going to put
>>> myself into the mind of an imagined, petulant user just to make a
>>> point.
>>>
>>> My gut instinct for the page creation suggested here is that there is
>>> too much complexity. Too many new words and ideas, too many
>>> possibilities on the screen, too many pictures, etc. Yes, it's done
>>> in the guise of helping people make good decisions at the outset, but
>>> I think it risks bewilderment by being overhelpful at the wrong time,
>>> and emphasizing the wrong things.
>>>
>>> There is a really simple concept at the core of the new page authoring
>>> metaphor which seems to me both powerful and elegant. You have a
>>> page, and you can start typing and/or drop things into the page that
>>> might be small (like a single assignment) or large (like a table of
>>> all assignments). But we bring little advantage to this simple
>>> concept by trying to define new kinds of pages or laying out the full
>>> spread of tools during the process of page creation.
>>>
>>> By the same token, we're not helping people by presenting the default
>>> option as a "blank page." Of *course* I don't want a blank page: I'm
>>> not going to choose that. I want a page that will have stuff in it.
>>> But rather than present me with a simple emphasis on how to quickly
>>> start authoring a page you appear to be putting your effort into
>>> front-loading my decision-making with a "page type," which
>>> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>>>
>>> It's not about the *page*. It's about what goes *in* the page. I'm
>>> trying to create my content and you keep trying to get me to look at
>>> the margins or declare my full intent ahead of time.
>>>
>>> In other words I think the design simply has the wrong focus at this
>>> stage. What if we instead focused design energies on making the
>>> editing easy and flexible, and left the mere creation of the page
>>> virtually transparent? What if, instead of some dialogue asking about
>>> what kind of page this will be, when I click on "create a new page"
>>> I'm immediately there, or I'm immediately at a place that asks, "OK,
>>> ta-da, you have your page: now what are you going to put in it?" (e.g.
>>> with an interface that immediately leads me into either typing or
>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>>> what I'm going to put in it by leading with *that* kind of choice
>>> instead.
>>>
>>> Stepping back for a moment from my frothy remarks (which, again, I
>>> mean a bit playfully, but to make a point): I don't mean to insist
>>> that I really know what people want, but I do mean to suggest that I
>>> think this really needs testing.
>>>
>>> ~Clay
>>>
>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]>
>>> wrote:
>>> > Today's UX working session reviewed a few tweaks to the header area of
>>> the
>>> > site screen, plus a review of the "create page" screen. Both can be
>>> found
>>> > here:
>>> >
>>> >
>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>> >
>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>> >
>>> > We also dove into the meatier topic of widgets/entities, which we've
>>> begun
>>> > calling vignettes (sorry to introduce more terminology, but we're
>>> hoping
>>> > this will be better choice of words in the long run).
>>> >
>>> > As we see it, there are two major interaction themes within Sakai
>>> sites.
>>> > The first consists of pages that contain a smattering of content types;
>>>
>>> > ranging from text to functional bits called vignettes. The second
>>> consists
>>> > of something called aggregate views (more on this later).
>>> >
>>> > To illustrate the vignette idea a bit more clearly, we discussed the
>>> > following story:
>>> >
>>> > An instructor creates a page titled "week 1" and in that pages provides
>>> a
>>> > short summary and informs students to read chapters 3 & 4. Below this
>>> block
>>> > of text, she inserts a discussion vignette and adds a brief header to
>>> it
>>> > that reads "When you're done with chapter 3, discuss the following
>>> concept:
>>> > xyz". The instructor then adds more text related to chapter 4, then
>>> addes a
>>> > series of multiple choice questions -- which appear by inserting survey
>>>
>>> > vignettes. Below these questions, she continues to add more text that
>>> tells
>>> > her students to prepare a 5 page write-up on both chapters and submit
>>> it in
>>> > the bottom of the page, or into the drop box vignette.
>>> >
>>> > A vignette would have a user-facing view as well as an edit/admin view.
>>> The
>>> > latter would likely be presented during the edit page mode and the
>>> former
>>> > during the view page mode. However there may be some carry over from
>>> one to
>>> > the other, as in the case of a preview option while in the edit mode.
>>> >
>>> > As for aggregate views, they can be thought of as a central place that
>>> > consolidates a collection of all the vignettes that happen to be
>>> peppered
>>> > through a site. Another way to think of it, which may or may not be
>>> > helpful, is as a conventional tool view. To illustrate, one might
>>> imagine
>>> > the following story:
>>> >
>>> > Before the start of a semester, the instructor has composed a bunch of
>>> pages
>>> > to teach his hybrid class. Several of those pages include one or more
>>> > discussion vignettes. As the semester gets under way, students begin
>>> > posting replies across a variety of pages, resulting in simultaneous
>>> > threaded discussion sprouting up throughout the site. Rather than
>>> sifting
>>> > through all the pages in the site in order to keep up, the instructor
>>> simply
>>> > goes to the aggregate discussion view where he is presented with a UI
>>> that
>>> > is similar to a traditional discussion forum; with the exception that
>>> the
>>> > discussion topics and threads consist of the same stuff found in the
>>> > vignettes that are scattered throughout the site.
>>> >
>>> > A few interesting points about this aggregate page view: Similar to the
>>>
>>> > vignettes, this view would have a user-facing side and an admin control
>>>
>>> > panel of some sort. Also, the aggregate view may be available only to
>>> the
>>> > site maintainer (or instructor in the above story) or to everyone
>>> (including
>>> > his students). If the latter is true, than in theory, a student can
>>> engage
>>> > a particular discussion either inline on a page where a vignette is
>>> > presented, or by going into the aggregate "discussion forum" view.
>>> >
>>> > Another side note to all of this is that when a new discussion vignette
>>> is
>>> > added to a page, it is then automatically pushed to the aggregate view
>>> and
>>> > collected there. However, if a discussion post is added while in the
>>> > aggregate view, it is NOT automatically pushed to some site page. This
>>> > implies that the aggregate view can contain more discussion posts than
>>> might
>>> > appear in the regular site pages. However, probably any such post in
>>> the
>>> > aggregate view can be pulled into a page while the page is being
>>> composed.
>>> >
>>> > We then briefly discussed the UX question of "how might a user locate
>>> one of
>>> > these aggregate views"? We touched on a few ideas, but nothing worth
>>> > mentioning until we put a bit more thought into them.
>>> >
>>> > Also, we focused on "threaded discussion" functionality to keep the
>>> model
>>> > manageable for now. None of this has been tested on other functional
>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all of
>>> this
>>> > will hold water once we get there.
>>> >
>>> > Cheers,
>>> > Nathan
>>> >
>>> > --
>>> > Nathan Pearson | UX Lead | Sakai Foundation
>>> >
>>> > E. [hidden email]
>>> > M. 602.418.5092
>>> > Y. npearson99 (Yahoo)
>>> > S. npearson99 (Skype)
>>> >
>>> >
>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix<http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40groupcalendar.google.com&ctz=America/Phoenix>
>>> >
>>>  > ________________________________
>>> > This automatic notification message was sent by Sakai Collab
>>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>>
>>> > You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>> >
>>>
>>>
>>>
>>> --
>>> Clay Fenlason
>>> Director, Educational Technology
>>> Georgia Institute of Technology
>>> (404) 385-6644
>>> ------------------------------
>>>
>>> This automatic notification message was sent by Sakai Collab (
>>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. [hidden email]
>> M. 602.418.5092
>> Y npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>
>>  ------------------------------
>>
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>>
>>   Daphne Ogle
>> Senior Interaction Designer
>> University of California, Berkeley
>> Educational Technology Services
>> [hidden email]
>> cell (510)847-0308
>>
>>
>>
>>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (
> https://collab.sakaiproject.org//portal) from the DG: User Experience
> site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
>
> --
>
>
> [image: Oracle] <http://www.oracle.com>
>  Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229
>



--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
[see attachment: "oracle_sig_logo.gif", size: 658 bytes]



Attachments:

oracle_sig_logo.gif
https://collab.sakaiproject.org//access/content/attachment/5022e973-04c4-44c2-a9ba-18d0d547f6e6/oracle_sig_logo.gif

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Feldstein Michael Feldstein
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


I'm afraid that I don't have a better idea. I'm just suggesting that
there should be some user testing of the notion that faculty will be
comfortable thinking about configuring their learning environment as:

   1. First creating new pages
   2. Then putting functionality on those pages

Does the blank slate work for them? Even with templates, the current
design suggests that faculty (particularly ones who are new to 3akai)
will have to intuit that, in order to add a discussion board (for
example), they must first create a new page. It may be that this is not
a big deal for faculty to get. But my experience with the execution of a
somewhat similar model in WebCT was bad enough to make me worry.

- m


Nathan Pearson wrote:

> I'm not sure I understand the feedback.  What do you have in mind as a
> better way to do it?
>
>
> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     Hmm.
>
>     I just was helping my wife wrestle with Blackboard CE8 today, and
>     this is mock-up is suddenly feeling a little familiar. And not in
>     a good way. My sense is that WebCT started off with the same idea
>     that people should just be able to assemble pages and put anything
>     they want on them. The execution was particularly clunky, probably
>     in part because of the technology base they were dealing with at
>     the time they designed the system. But beyond that, I'm not sure
>     that the typical faculty member thinks of putting together their
>     course in terms of assembling pages first and then putting
>     functionality on the pages. Maybe it's possible to execute the
>     concept in a way that makes it more intuitive than it is in CE (in
>     fact, I'm sure of it), but I just don't know if "Create a New
>     Page" carries the semantic freight necessary.
>
>     - m
>
>
>     Nathan Pearson wrote:
>>     I think it will come down to the affordance of where the option
>>     is displayed on the screen, the context, and the terminology.
>>     This is what I had in mind based on Clay's comments:
>>
>>     http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>>
>>     It still forces the user to make a choice, but the imposition
>>     isn't significant and can easily be ignored.  If we push the idea
>>     too far out of one's reach or periphery, then we risk making it
>>     too inefficient to get at.
>>
>>     Nathan
>>
>>
>>     On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>         To add to the comparison with confluence, (being bad here
>>         with self referential design but I think it applies more
>>         broadly) I know the subtle "template" link is there but I
>>         ignore it because I'm almost always in a hurry when I create
>>         a page in confluence and "template" doesn't hold any value
>>         for me.  If I knew there were templates that would make my
>>         work easier perhaps I would use it.   So I think it's more
>>         than just making sure users see that there are templates
>>          When we ask them if they want to use a template, I think we
>>         should also allow them to discover the kinds of templates
>>         there are and they can help me in my work.  Some users will
>>         be curious and play around with options such as templates but
>>         what we find often in user research is that users are very
>>         busy and will go the most direct route they can.  I guess
>>         what I'm contemplating is, "Is the word template enough
>>         information scent to allow users to know why they should
>>         choose it?"
>>
>>         -Daphne
>>
>>
>>         On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>>
>>>         You're probably right.  There's still the issue of applying
>>>         a page template -- which should come before the edit page
>>>         view.  Confluence does it in a bit of a quirky way IMO where
>>>         they drop you into the edit view, and if you happen to see
>>>         the subtle link to invoke a template, you can take a step
>>>         back to take two forward in applying a template.  I find
>>>         this pattern to be a bit clumsy.
>>>
>>>         Maybe the way to get the best of both worlds is to use a
>>>         drop down when clicking the Create New Page button that
>>>         presents the options: Blank Page or From Template.
>>>
>>>         Nathan
>>>
>>>         On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
>>>         <[hidden email]
>>>         <mailto:[hidden email]>> wrote:
>>>
>>>             Sorry I couldn't make today's discussion, and
>>>             particularly sorry since
>>>             I'm going to indulge a bit of grousing about the create
>>>             page bits, but
>>>             I trust my stammering about the point yesterday may have
>>>             prepared you
>>>             for this line of attack, and that you understand the
>>>             appreciative
>>>             place it comes from ... so I can let my hair down. I'm
>>>             going to put
>>>             myself into the mind of an imagined, petulant user just
>>>             to make a
>>>             point.
>>>
>>>             My gut instinct for the page creation suggested here is
>>>             that there is
>>>             too much complexity. Too many new words and ideas, too many
>>>             possibilities on the screen, too many pictures, etc.
>>>             Yes, it's done
>>>             in the guise of helping people make good decisions at
>>>             the outset, but
>>>             I think it risks bewilderment by being overhelpful at
>>>             the wrong time,
>>>             and emphasizing the wrong things.
>>>
>>>             There is a really simple concept at the core of the new
>>>             page authoring
>>>             metaphor which seems to me both powerful and elegant.
>>>             You have a
>>>             page, and you can start typing and/or drop things into
>>>             the page that
>>>             might be small (like a single assignment) or large (like
>>>             a table of
>>>             all assignments). But we bring little advantage to this
>>>             simple
>>>             concept by trying to define new kinds of pages or laying
>>>             out the full
>>>             spread of tools during the process of page creation.
>>>
>>>             By the same token, we're not helping people by
>>>             presenting the default
>>>             option as a "blank page." Of *course* I don't want a
>>>             blank page: I'm
>>>             not going to choose that. I want a page that will have
>>>             stuff in it.
>>>             But rather than present me with a simple emphasis on how
>>>             to quickly
>>>             start authoring a page you appear to be putting your
>>>             effort into
>>>             front-loading my decision-making with a "page type," which
>>>             instinctively strikes me as an odd notion: unnecessary
>>>             and unhelpful.
>>>
>>>             It's not about the *page*. It's about what goes *in* the
>>>             page. I'm
>>>             trying to create my content and you keep trying to get
>>>             me to look at
>>>             the margins or declare my full intent ahead of time.
>>>
>>>             In other words I think the design simply has the wrong
>>>             focus at this
>>>             stage. What if we instead focused design energies on
>>>             making the
>>>             editing easy and flexible, and left the mere creation of
>>>             the page
>>>             virtually transparent? What if, instead of some dialogue
>>>             asking about
>>>             what kind of page this will be, when I click on "create
>>>             a new page"
>>>             I'm immediately there, or I'm immediately at a place
>>>             that asks, "OK,
>>>             ta-da, you have your page: now what are you going to put
>>>             in it?" (e.g.
>>>             with an interface that immediately leads me into either
>>>             typing or
>>>             plugging in "vignettes") Instead of emphasizing the
>>>             page, emphasize
>>>             what I'm going to put in it by leading with *that* kind
>>>             of choice
>>>             instead.
>>>
>>>             Stepping back for a moment from my frothy remarks
>>>             (which, again, I
>>>             mean a bit playfully, but to make a point): I don't mean
>>>             to insist
>>>             that I really know what people want, but I do mean to
>>>             suggest that I
>>>             think this really needs testing.
>>>
>>>             ~Clay
>>>
>>>             On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
>>>             <[hidden email] <mailto:[hidden email]>> wrote:
>>>             > Today's UX working session reviewed a few tweaks to
>>>             the header area of the
>>>             > site screen, plus a review of the "create page"
>>>             screen. Both can be found
>>>             > here:
>>>             >
>>>             >
>>>             http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>>
>>>             >
>>>             http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>>
>>>             >
>>>             > We also dove into the meatier topic of
>>>             widgets/entities, which we've begun
>>>             > calling vignettes (sorry to introduce more
>>>             terminology, but we're hoping
>>>             > this will be better choice of words in the long run).
>>>             >
>>>             > As we see it, there are two major interaction themes
>>>             within Sakai sites.
>>>             > The first consists of pages that contain a smattering
>>>             of content types;
>>>             > ranging from text to functional bits called vignettes.
>>>             The second consists
>>>             > of something called aggregate views (more on this later).
>>>             >
>>>             > To illustrate the vignette idea a bit more clearly, we
>>>             discussed the
>>>             > following story:
>>>             >
>>>             > An instructor creates a page titled "week 1" and in
>>>             that pages provides a
>>>             > short summary and informs students to read chapters 3
>>>             & 4. Below this block
>>>             > of text, she inserts a discussion vignette and adds a
>>>             brief header to it
>>>             > that reads "When you're done with chapter 3, discuss
>>>             the following concept:
>>>             > xyz". The instructor then adds more text related to
>>>             chapter 4, then addes a
>>>             > series of multiple choice questions -- which appear by
>>>             inserting survey
>>>             > vignettes. Below these questions, she continues to add
>>>             more text that tells
>>>             > her students to prepare a 5 page write-up on both
>>>             chapters and submit it in
>>>             > the bottom of the page, or into the drop box vignette.
>>>             >
>>>             > A vignette would have a user-facing view as well as an
>>>             edit/admin view. The
>>>             > latter would likely be presented during the edit page
>>>             mode and the former
>>>             > during the view page mode. However there may be some
>>>             carry over from one to
>>>             > the other, as in the case of a preview option while in
>>>             the edit mode.
>>>             >
>>>             > As for aggregate views, they can be thought of as a
>>>             central place that
>>>             > consolidates a collection of all the vignettes that
>>>             happen to be peppered
>>>             > through a site. Another way to think of it, which may
>>>             or may not be
>>>             > helpful, is as a conventional tool view. To
>>>             illustrate, one might imagine
>>>             > the following story:
>>>             >
>>>             > Before the start of a semester, the instructor has
>>>             composed a bunch of pages
>>>             > to teach his hybrid class. Several of those pages
>>>             include one or more
>>>             > discussion vignettes. As the semester gets under way,
>>>             students begin
>>>             > posting replies across a variety of pages, resulting
>>>             in simultaneous
>>>             > threaded discussion sprouting up throughout the site.
>>>             Rather than sifting
>>>             > through all the pages in the site in order to keep up,
>>>             the instructor simply
>>>             > goes to the aggregate discussion view where he is
>>>             presented with a UI that
>>>             > is similar to a traditional discussion forum; with the
>>>             exception that the
>>>             > discussion topics and threads consist of the same
>>>             stuff found in the
>>>             > vignettes that are scattered throughout the site.
>>>             >
>>>             > A few interesting points about this aggregate page
>>>             view: Similar to the
>>>             > vignettes, this view would have a user-facing side and
>>>             an admin control
>>>             > panel of some sort. Also, the aggregate view may be
>>>             available only to the
>>>             > site maintainer (or instructor in the above story) or
>>>             to everyone (including
>>>             > his students). If the latter is true, than in theory,
>>>             a student can engage
>>>             > a particular discussion either inline on a page where
>>>             a vignette is
>>>             > presented, or by going into the aggregate "discussion
>>>             forum" view.
>>>             >
>>>             > Another side note to all of this is that when a new
>>>             discussion vignette is
>>>             > added to a page, it is then automatically pushed to
>>>             the aggregate view and
>>>             > collected there. However, if a discussion post is
>>>             added while in the
>>>             > aggregate view, it is NOT automatically pushed to some
>>>             site page. This
>>>             > implies that the aggregate view can contain more
>>>             discussion posts than might
>>>             > appear in the regular site pages. However, probably
>>>             any such post in the
>>>             > aggregate view can be pulled into a page while the
>>>             page is being composed.
>>>             >
>>>             > We then briefly discussed the UX question of "how
>>>             might a user locate one of
>>>             > these aggregate views"? We touched on a few ideas, but
>>>             nothing worth
>>>             > mentioning until we put a bit more thought into them.
>>>             >
>>>             > Also, we focused on "threaded discussion"
>>>             functionality to keep the model
>>>             > manageable for now. None of this has been tested on
>>>             other functional
>>>             > domains (i.e. calendar, survey, etc.) so it's hard to
>>>             know if all of this
>>>             > will hold water once we get there.
>>>             >
>>>             > Cheers,
>>>             > Nathan
>>>             >
>>>             > --
>>>             > Nathan Pearson | UX Lead | Sakai Foundation
>>>             >
>>>             > E. [hidden email] <mailto:[hidden email]>
>>>             > M. 602.418.5092
>>>             > Y. npearson99 (Yahoo)
>>>             > S. npearson99 (Skype)
>>>             >
>>>             >
>>>             http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>             <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40groupcalendar.google.com&ctz=America/Phoenix>
>>>
>>>             >
>>>             > ________________________________
>>>             > This automatic notification message was sent by Sakai
>>>             Collab
>>>             > (https://collab.sakaiproject.org//portal) from the WG:
>>>             Authoring site.
>>>             > You can modify how you receive notifications at My
>>>             Workspace > Preferences.
>>>             >
>>>
>>>
>>>
>>>             --
>>>             Clay Fenlason
>>>             Director, Educational Technology
>>>             Georgia Institute of Technology
>>>             (404) 385-6644
>>>             ------------------------------------------------------------------------
>>>
>>>             This automatic notification message was sent by Sakai
>>>             Collab (https://collab.sakaiproject.org//portal) from
>>>             the WG: Authoring site.
>>>             You can modify how you receive notifications at My
>>>             Workspace > Preferences.
>>>
>>>
>>>
>>>
>>>         --
>>>         Nathan Pearson | UX Lead | Sakai Foundation
>>>
>>>         E. [hidden email] <mailto:[hidden email]>
>>>         M. 602.418.5092
>>>         Y npearson99 (Yahoo)
>>>         S. npearson99 (Skype)
>>>
>>>         http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>         <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>>>
>>>         ------------------------------------------------------------------------
>>>
>>>         This automatic notification message was sent by Sakai Collab
>>>         (https://collab.sakaiproject.org//portal) from the WG:
>>>         Authoring site.
>>>         You can modify how you receive notifications at My Workspace
>>>         > Preferences.
>>
>>         Daphne Ogle
>>         Senior Interaction Designer
>>         University of California, Berkeley
>>         Educational Technology Services
>>         [hidden email] <mailto:[hidden email]>
>>         cell (510)847-0308
>>
>>
>>
>>
>>
>>
>>     --
>>     Nathan Pearson | UX Lead | Sakai Foundation
>>
>>     E. [hidden email] <mailto:[hidden email]>
>>     M. 602.418.5092
>>     Y. npearson99 (Yahoo)
>>     S. npearson99 (Skype)
>>
>>     http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>     <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>>
>>     ------------------------------------------------------------------------
>>
>>     This automatic notification message was sent by Sakai Collab
>>     (https://collab.sakaiproject.org//portal) from the DG: User
>>     Experience site.
>>
>>     You can modify how you receive notifications at My Workspace >
>>     Preferences.
>
>     --
>
>
>     Oracle <http://www.oracle.com>
>     Michael Feldstein | Principal Product Manager | +1.818.817.2925
>     Oracle Academic Enterprise Solutions Group
>     23A Glendale Road, Glendale, MA 01229
>
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email] <mailto:[hidden email]>
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>

--


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
[see attachment: "unknown", size: 658 bytes]

[see attachment: "oracle_sig_logo.gif", size: 658 bytes]



Attachments:

unknown
https://collab.sakaiproject.org//access/content/attachment/378d1578-1ded-445b-b42c-a1d6f6244b10/unknown.gif

oracle_sig_logo.gif
https://collab.sakaiproject.org//access/content/attachment/4f232756-9409-4a25-b106-ab663880c6a7/oracle_sig_logo.gif

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
skeesler skeesler
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


That idea hits home. If I were designing a website (maybe for collaborative
editing/brainstorming with a group), then organizing the space may into
pages make a lot of sense.

If I am trying get my course syllabus up and running in Sakai, it might not.
Maybe a competing (rather traditional) train of thought would be.

   1. First designing the activities.
   2. Organizing and relating the activities to each other (by chronology,
   topic, type, etc).


Sean



On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein <
[hidden email]> wrote:

>  I'm afraid that I don't have a better idea. I'm just suggesting that
> there should be some user testing of the notion that faculty will be
> comfortable thinking about configuring their learning environment as:
>
>    1. First creating new pages
>    2. Then putting functionality on those pages
>
> Does the blank slate work for them? Even with templates, the current design
> suggests that faculty (particularly ones who are new to 3akai) will have to
> intuit that, in order to add a discussion board (for example), they must
> first create a new page. It may be that this is not a big deal for faculty
> to get. But my experience with the execution of a somewhat similar model in
> WebCT was bad enough to make me worry.
>
>
> - m
>
>
> Nathan Pearson wrote:
>
> I'm not sure I understand the feedback.  What do you have in mind as a
> better way to do it?
>
>
> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein <
> [hidden email]> wrote:
>
>>  Hmm.
>>
>> I just was helping my wife wrestle with Blackboard CE8 today, and this is
>> mock-up is suddenly feeling a little familiar. And not in a good way. My
>> sense is that WebCT started off with the same idea that people should just
>> be able to assemble pages and put anything they want on them. The execution
>> was particularly clunky, probably in part because of the technology base
>> they were dealing with at the time they designed the system. But beyond
>> that, I'm not sure that the typical faculty member thinks of putting
>> together their course in terms of assembling pages first and then putting
>> functionality on the pages. Maybe it's possible to execute the concept in a
>> way that makes it more intuitive than it is in CE (in fact, I'm sure of it),
>> but I just don't know if "Create a New Page" carries the semantic freight
>> necessary.
>>
>> - m
>>
>>
>> Nathan Pearson wrote:
>>
>>  I think it will come down to the affordance of where the option is
>> displayed on the screen, the context, and the terminology.  This is what I
>> had in mind based on Clay's comments:
>>
>>
>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>>
>> It still forces the user to make a choice, but the imposition isn't
>> significant and can easily be ignored.  If we push the idea too far out of
>> one's reach or periphery, then we risk making it too inefficient to get at.
>>
>> Nathan
>>
>>
>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <[hidden email]>wrote:
>>
>>> To add to the comparison with confluence, (being bad here with self
>>> referential design but I think it applies more broadly) I know the subtle
>>> "template" link is there but I ignore it because I'm almost always in a
>>> hurry when I create a page in confluence and "template" doesn't hold any
>>> value for me.  If I knew there were templates that would make my work easier
>>> perhaps I would use it.   So I think it's more than just making sure users
>>> see that there are templates  When we ask them if they want to use a
>>> template, I think we should also allow them to discover the kinds of
>>> templates there are and they can help me in my work.  Some users will be
>>> curious and play around with options such as templates but what we find
>>> often in user research is that users are very busy and will go the most
>>> direct route they can.  I guess what I'm contemplating is, "Is the word
>>> template enough information scent to allow users to know why they should
>>> choose it?"
>>>  -Daphne
>>>
>>>
>>>   On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>>>
>>>    You're probably right.  There's still the issue of applying a page
>>> template -- which should come before the edit page view.  Confluence does it
>>> in a bit of a quirky way IMO where they drop you into the edit view, and if
>>> you happen to see the subtle link to invoke a template, you can take a step
>>> back to take two forward in applying a template.  I find this pattern to be
>>> a bit clumsy.
>>>
>>> Maybe the way to get the best of both worlds is to use a drop down when
>>> clicking the Create New Page button that presents the options: Blank Page or
>>> From Template.
>>>
>>> Nathan
>>>
>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <
>>> [hidden email]> wrote:
>>>
>>>> Sorry I couldn't make today's discussion, and particularly sorry since
>>>> I'm going to indulge a bit of grousing about the create page bits, but
>>>> I trust my stammering about the point yesterday may have prepared you
>>>> for this line of attack, and that you understand the appreciative
>>>> place it comes from ... so I can let my hair down. I'm going to put
>>>> myself into the mind of an imagined, petulant user just to make a
>>>> point.
>>>>
>>>> My gut instinct for the page creation suggested here is that there is
>>>> too much complexity. Too many new words and ideas, too many
>>>> possibilities on the screen, too many pictures, etc. Yes, it's done
>>>> in the guise of helping people make good decisions at the outset, but
>>>> I think it risks bewilderment by being overhelpful at the wrong time,
>>>> and emphasizing the wrong things.
>>>>
>>>> There is a really simple concept at the core of the new page authoring
>>>> metaphor which seems to me both powerful and elegant. You have a
>>>> page, and you can start typing and/or drop things into the page that
>>>> might be small (like a single assignment) or large (like a table of
>>>> all assignments). But we bring little advantage to this simple
>>>> concept by trying to define new kinds of pages or laying out the full
>>>> spread of tools during the process of page creation.
>>>>
>>>> By the same token, we're not helping people by presenting the default
>>>> option as a "blank page." Of *course* I don't want a blank page: I'm
>>>> not going to choose that. I want a page that will have stuff in it.
>>>> But rather than present me with a simple emphasis on how to quickly
>>>> start authoring a page you appear to be putting your effort into
>>>> front-loading my decision-making with a "page type," which
>>>> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>>>>
>>>> It's not about the *page*. It's about what goes *in* the page. I'm
>>>> trying to create my content and you keep trying to get me to look at
>>>> the margins or declare my full intent ahead of time.
>>>>
>>>> In other words I think the design simply has the wrong focus at this
>>>> stage. What if we instead focused design energies on making the
>>>> editing easy and flexible, and left the mere creation of the page
>>>> virtually transparent? What if, instead of some dialogue asking about
>>>> what kind of page this will be, when I click on "create a new page"
>>>> I'm immediately there, or I'm immediately at a place that asks, "OK,
>>>> ta-da, you have your page: now what are you going to put in it?" (e.g.
>>>> with an interface that immediately leads me into either typing or
>>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>>>> what I'm going to put in it by leading with *that* kind of choice
>>>> instead.
>>>>
>>>> Stepping back for a moment from my frothy remarks (which, again, I
>>>> mean a bit playfully, but to make a point): I don't mean to insist
>>>> that I really know what people want, but I do mean to suggest that I
>>>> think this really needs testing.
>>>>
>>>> ~Clay
>>>>
>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]>
>>>> wrote:
>>>> > Today's UX working session reviewed a few tweaks to the header area of
>>>> the
>>>> > site screen, plus a review of the "create page" screen. Both can be
>>>> found
>>>> > here:
>>>> >
>>>> >
>>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>>> >
>>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>>> >
>>>> > We also dove into the meatier topic of widgets/entities, which we've
>>>> begun
>>>> > calling vignettes (sorry to introduce more terminology, but we're
>>>> hoping
>>>> > this will be better choice of words in the long run).
>>>> >
>>>> > As we see it, there are two major interaction themes within Sakai
>>>> sites.
>>>> > The first consists of pages that contain a smattering of content
>>>> types;
>>>> > ranging from text to functional bits called vignettes. The second
>>>> consists
>>>> > of something called aggregate views (more on this later).
>>>> >
>>>> > To illustrate the vignette idea a bit more clearly, we discussed the
>>>> > following story:
>>>> >
>>>> > An instructor creates a page titled "week 1" and in that pages
>>>> provides a
>>>> > short summary and informs students to read chapters 3 & 4. Below this
>>>> block
>>>> > of text, she inserts a discussion vignette and adds a brief header to
>>>> it
>>>> > that reads "When you're done with chapter 3, discuss the following
>>>> concept:
>>>> > xyz". The instructor then adds more text related to chapter 4, then
>>>> addes a
>>>> > series of multiple choice questions -- which appear by inserting
>>>> survey
>>>> > vignettes. Below these questions, she continues to add more text that
>>>> tells
>>>> > her students to prepare a 5 page write-up on both chapters and submit
>>>> it in
>>>> > the bottom of the page, or into the drop box vignette.
>>>> >
>>>> > A vignette would have a user-facing view as well as an edit/admin
>>>> view. The
>>>> > latter would likely be presented during the edit page mode and the
>>>> former
>>>> > during the view page mode. However there may be some carry over from
>>>> one to
>>>> > the other, as in the case of a preview option while in the edit mode.
>>>> >
>>>> > As for aggregate views, they can be thought of as a central place that
>>>>
>>>> > consolidates a collection of all the vignettes that happen to be
>>>> peppered
>>>> > through a site. Another way to think of it, which may or may not be
>>>> > helpful, is as a conventional tool view. To illustrate, one might
>>>> imagine
>>>> > the following story:
>>>> >
>>>> > Before the start of a semester, the instructor has composed a bunch of
>>>> pages
>>>> > to teach his hybrid class. Several of those pages include one or more
>>>> > discussion vignettes. As the semester gets under way, students begin
>>>> > posting replies across a variety of pages, resulting in simultaneous
>>>> > threaded discussion sprouting up throughout the site. Rather than
>>>> sifting
>>>> > through all the pages in the site in order to keep up, the instructor
>>>> simply
>>>> > goes to the aggregate discussion view where he is presented with a UI
>>>> that
>>>> > is similar to a traditional discussion forum; with the exception that
>>>> the
>>>> > discussion topics and threads consist of the same stuff found in the
>>>> > vignettes that are scattered throughout the site.
>>>> >
>>>> > A few interesting points about this aggregate page view: Similar to
>>>> the
>>>> > vignettes, this view would have a user-facing side and an admin
>>>> control
>>>> > panel of some sort. Also, the aggregate view may be available only to
>>>> the
>>>> > site maintainer (or instructor in the above story) or to everyone
>>>> (including
>>>> > his students). If the latter is true, than in theory, a student can
>>>> engage
>>>> > a particular discussion either inline on a page where a vignette is
>>>> > presented, or by going into the aggregate "discussion forum" view.
>>>> >
>>>> > Another side note to all of this is that when a new discussion
>>>> vignette is
>>>> > added to a page, it is then automatically pushed to the aggregate view
>>>> and
>>>> > collected there. However, if a discussion post is added while in the
>>>> > aggregate view, it is NOT automatically pushed to some site page. This
>>>>
>>>> > implies that the aggregate view can contain more discussion posts than
>>>> might
>>>> > appear in the regular site pages. However, probably any such post in
>>>> the
>>>> > aggregate view can be pulled into a page while the page is being
>>>> composed.
>>>> >
>>>> > We then briefly discussed the UX question of "how might a user locate
>>>> one of
>>>> > these aggregate views"? We touched on a few ideas, but nothing worth
>>>> > mentioning until we put a bit more thought into them.
>>>> >
>>>> > Also, we focused on "threaded discussion" functionality to keep the
>>>> model
>>>> > manageable for now. None of this has been tested on other functional
>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all of
>>>> this
>>>> > will hold water once we get there.
>>>> >
>>>> > Cheers,
>>>> > Nathan
>>>> >
>>>> > --
>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>>>> >
>>>> > E. [hidden email]
>>>> > M. 602.418.5092
>>>> > Y. npearson99 (Yahoo)
>>>> > S. npearson99 (Skype)
>>>> >
>>>> >
>>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix<http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40groupcalendar.google.com&ctz=America/Phoenix>
>>>> >
>>>>  > ________________________________
>>>> > This automatic notification message was sent by Sakai Collab
>>>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring
>>>> site.
>>>> > You can modify how you receive notifications at My Workspace >
>>>> Preferences.
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Clay Fenlason
>>>> Director, Educational Technology
>>>> Georgia Institute of Technology
>>>> (404) 385-6644
>>>> ------------------------------
>>>>
>>>> This automatic notification message was sent by Sakai Collab (
>>>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>>> You can modify how you receive notifications at My Workspace >
>>>> Preferences.
>>>>
>>>
>>>
>>>
>>> --
>>> Nathan Pearson | UX Lead | Sakai Foundation
>>>
>>> E. [hidden email]
>>> M. 602.418.5092
>>> Y npearson99 (Yahoo)
>>> S. npearson99 (Skype)
>>>
>>>
>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>
>>>  ------------------------------
>>>
>>> This automatic notification message was sent by Sakai Collab (
>>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>>   Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> [hidden email]
>>> cell (510)847-0308
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. [hidden email]
>> M. 602.418.5092
>> Y. npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>
>>  ------------------------------
>>
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org//portal) from the DG: User Experience
>> site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>>
>> --
>>
>>
>>  <http://www.oracle.com>
>>  Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> Oracle Academic Enterprise Solutions Group
>> 23A Glendale Road, Glendale, MA 01229
>>
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
>
> --
>
>
> [image: Oracle] <http://www.oracle.com>
>  Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229
>
> [see attachment: "unknown", size: 658 bytes]
>
> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>
> Attachments:
>
> unknown<https://collab.sakaiproject.org//access/content/attachment/378d1578-1ded-445b-b42c-a1d6f6244b10/unknown.gif>
>
> oracle_sig_logo.gif<https://collab.sakaiproject.org//access/content/attachment/4f232756-9409-4a25-b106-ab663880c6a7/oracle_sig_logo.gif>
>
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (
> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace > Preferences.
>



--
Sean Keesler
130 Academy Street
Manlius, NY 13104
315-663-7756

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


There may be a solution I've been toying with that would satisfy this
concern.  The sidebar (see mockup) can be edited, and therefor widgets can
be added into the sidebar.  It's conceivable that there could be a widget
called "Site Tools" that would mimic traditional Sakai by presenting links
to pages with tools on them.  No need to first add a page, then insert
tool-ish functionality.

These pages would be the aggregate views, or put another way, tool views --
not just vignettes.

Also, it's conceivable that we could have site templates (not just page
templates).  One such site template would present a legacy Sakai layout,
which would include this Site Tools sidebar widget already in place -- so
the user wouldn't need to add it to the sidebar first, they could just
select this site template and jump right in to using it.

How does that sound?



On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]> wrote:

> That idea hits home. If I were designing a website (maybe for collaborative
> editing/brainstorming with a group), then organizing the space may into
> pages make a lot of sense.
>
> If I am trying get my course syllabus up and running in Sakai, it might
> not. Maybe a competing (rather traditional) train of thought would be.
>
>    1. First designing the activities.
>    2. Organizing and relating the activities to each other (by chronology,
>    topic, type, etc).
>
>
> Sean
>
>
>
> On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein <
> [hidden email]> wrote:
>
>>  I'm afraid that I don't have a better idea. I'm just suggesting that
>> there should be some user testing of the notion that faculty will be
>> comfortable thinking about configuring their learning environment as:
>>
>>    1. First creating new pages
>>    2. Then putting functionality on those pages
>>
>> Does the blank slate work for them? Even with templates, the current
>> design suggests that faculty (particularly ones who are new to 3akai) will
>> have to intuit that, in order to add a discussion board (for example), they
>> must first create a new page. It may be that this is not a big deal for
>> faculty to get. But my experience with the execution of a somewhat similar
>> model in WebCT was bad enough to make me worry.
>>
>>
>> - m
>>
>>
>> Nathan Pearson wrote:
>>
>> I'm not sure I understand the feedback.  What do you have in mind as a
>> better way to do it?
>>
>>
>> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein <
>> [hidden email]> wrote:
>>
>>>  Hmm.
>>>
>>> I just was helping my wife wrestle with Blackboard CE8 today, and this is
>>> mock-up is suddenly feeling a little familiar. And not in a good way. My
>>> sense is that WebCT started off with the same idea that people should just
>>> be able to assemble pages and put anything they want on them. The execution
>>> was particularly clunky, probably in part because of the technology base
>>> they were dealing with at the time they designed the system. But beyond
>>> that, I'm not sure that the typical faculty member thinks of putting
>>> together their course in terms of assembling pages first and then putting
>>> functionality on the pages. Maybe it's possible to execute the concept in a
>>> way that makes it more intuitive than it is in CE (in fact, I'm sure of it),
>>> but I just don't know if "Create a New Page" carries the semantic freight
>>> necessary.
>>>
>>> - m
>>>
>>>
>>> Nathan Pearson wrote:
>>>
>>>  I think it will come down to the affordance of where the option is
>>> displayed on the screen, the context, and the terminology.  This is what I
>>> had in mind based on Clay's comments:
>>>
>>>
>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>>>
>>> It still forces the user to make a choice, but the imposition isn't
>>> significant and can easily be ignored.  If we push the idea too far out of
>>> one's reach or periphery, then we risk making it too inefficient to get at.
>>>
>>> Nathan
>>>
>>>
>>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <[hidden email]>wrote:
>>>
>>>> To add to the comparison with confluence, (being bad here with self
>>>> referential design but I think it applies more broadly) I know the subtle
>>>> "template" link is there but I ignore it because I'm almost always in a
>>>> hurry when I create a page in confluence and "template" doesn't hold any
>>>> value for me.  If I knew there were templates that would make my work easier
>>>> perhaps I would use it.   So I think it's more than just making sure users
>>>> see that there are templates  When we ask them if they want to use a
>>>> template, I think we should also allow them to discover the kinds of
>>>> templates there are and they can help me in my work.  Some users will be
>>>> curious and play around with options such as templates but what we find
>>>> often in user research is that users are very busy and will go the most
>>>> direct route they can.  I guess what I'm contemplating is, "Is the word
>>>> template enough information scent to allow users to know why they should
>>>> choose it?"
>>>>  -Daphne
>>>>
>>>>
>>>>   On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>>>>
>>>>    You're probably right.  There's still the issue of applying a page
>>>> template -- which should come before the edit page view.  Confluence does it
>>>> in a bit of a quirky way IMO where they drop you into the edit view, and if
>>>> you happen to see the subtle link to invoke a template, you can take a step
>>>> back to take two forward in applying a template.  I find this pattern to be
>>>> a bit clumsy.
>>>>
>>>> Maybe the way to get the best of both worlds is to use a drop down when
>>>> clicking the Create New Page button that presents the options: Blank Page or
>>>> From Template.
>>>>
>>>> Nathan
>>>>
>>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <
>>>> [hidden email]> wrote:
>>>>
>>>>> Sorry I couldn't make today's discussion, and particularly sorry since
>>>>> I'm going to indulge a bit of grousing about the create page bits, but
>>>>> I trust my stammering about the point yesterday may have prepared you
>>>>> for this line of attack, and that you understand the appreciative
>>>>> place it comes from ... so I can let my hair down. I'm going to put
>>>>> myself into the mind of an imagined, petulant user just to make a
>>>>> point.
>>>>>
>>>>> My gut instinct for the page creation suggested here is that there is
>>>>> too much complexity. Too many new words and ideas, too many
>>>>> possibilities on the screen, too many pictures, etc. Yes, it's done
>>>>> in the guise of helping people make good decisions at the outset, but
>>>>> I think it risks bewilderment by being overhelpful at the wrong time,
>>>>> and emphasizing the wrong things.
>>>>>
>>>>> There is a really simple concept at the core of the new page authoring
>>>>> metaphor which seems to me both powerful and elegant. You have a
>>>>> page, and you can start typing and/or drop things into the page that
>>>>> might be small (like a single assignment) or large (like a table of
>>>>> all assignments). But we bring little advantage to this simple
>>>>> concept by trying to define new kinds of pages or laying out the full
>>>>> spread of tools during the process of page creation.
>>>>>
>>>>> By the same token, we're not helping people by presenting the default
>>>>> option as a "blank page." Of *course* I don't want a blank page: I'm
>>>>> not going to choose that. I want a page that will have stuff in it.
>>>>> But rather than present me with a simple emphasis on how to quickly
>>>>> start authoring a page you appear to be putting your effort into
>>>>> front-loading my decision-making with a "page type," which
>>>>> instinctively strikes me as an odd notion: unnecessary and unhelpful.
>>>>>
>>>>> It's not about the *page*. It's about what goes *in* the page. I'm
>>>>> trying to create my content and you keep trying to get me to look at
>>>>> the margins or declare my full intent ahead of time.
>>>>>
>>>>> In other words I think the design simply has the wrong focus at this
>>>>> stage. What if we instead focused design energies on making the
>>>>> editing easy and flexible, and left the mere creation of the page
>>>>> virtually transparent? What if, instead of some dialogue asking about
>>>>> what kind of page this will be, when I click on "create a new page"
>>>>> I'm immediately there, or I'm immediately at a place that asks, "OK,
>>>>> ta-da, you have your page: now what are you going to put in it?" (e.g.
>>>>> with an interface that immediately leads me into either typing or
>>>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>>>>> what I'm going to put in it by leading with *that* kind of choice
>>>>> instead.
>>>>>
>>>>> Stepping back for a moment from my frothy remarks (which, again, I
>>>>> mean a bit playfully, but to make a point): I don't mean to insist
>>>>> that I really know what people want, but I do mean to suggest that I
>>>>> think this really needs testing.
>>>>>
>>>>> ~Clay
>>>>>
>>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]>
>>>>> wrote:
>>>>> > Today's UX working session reviewed a few tweaks to the header area
>>>>> of the
>>>>> > site screen, plus a review of the "create page" screen. Both can be
>>>>> found
>>>>> > here:
>>>>> >
>>>>> >
>>>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>>>> >
>>>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>>>> >
>>>>> > We also dove into the meatier topic of widgets/entities, which we've
>>>>> begun
>>>>> > calling vignettes (sorry to introduce more terminology, but we're
>>>>> hoping
>>>>> > this will be better choice of words in the long run).
>>>>> >
>>>>> > As we see it, there are two major interaction themes within Sakai
>>>>> sites.
>>>>> > The first consists of pages that contain a smattering of content
>>>>> types;
>>>>> > ranging from text to functional bits called vignettes. The second
>>>>> consists
>>>>> > of something called aggregate views (more on this later).
>>>>> >
>>>>> > To illustrate the vignette idea a bit more clearly, we discussed the
>>>>> > following story:
>>>>> >
>>>>> > An instructor creates a page titled "week 1" and in that pages
>>>>> provides a
>>>>> > short summary and informs students to read chapters 3 & 4. Below this
>>>>> block
>>>>> > of text, she inserts a discussion vignette and adds a brief header to
>>>>> it
>>>>> > that reads "When you're done with chapter 3, discuss the following
>>>>> concept:
>>>>> > xyz". The instructor then adds more text related to chapter 4, then
>>>>> addes a
>>>>> > series of multiple choice questions -- which appear by inserting
>>>>> survey
>>>>> > vignettes. Below these questions, she continues to add more text that
>>>>> tells
>>>>> > her students to prepare a 5 page write-up on both chapters and submit
>>>>> it in
>>>>> > the bottom of the page, or into the drop box vignette.
>>>>> >
>>>>> > A vignette would have a user-facing view as well as an edit/admin
>>>>> view. The
>>>>> > latter would likely be presented during the edit page mode and the
>>>>> former
>>>>> > during the view page mode. However there may be some carry over from
>>>>> one to
>>>>> > the other, as in the case of a preview option while in the edit mode.
>>>>>
>>>>> >
>>>>> > As for aggregate views, they can be thought of as a central place
>>>>> that
>>>>> > consolidates a collection of all the vignettes that happen to be
>>>>> peppered
>>>>> > through a site. Another way to think of it, which may or may not be
>>>>> > helpful, is as a conventional tool view. To illustrate, one might
>>>>> imagine
>>>>> > the following story:
>>>>> >
>>>>> > Before the start of a semester, the instructor has composed a bunch
>>>>> of pages
>>>>> > to teach his hybrid class. Several of those pages include one or more
>>>>>
>>>>> > discussion vignettes. As the semester gets under way, students begin
>>>>> > posting replies across a variety of pages, resulting in simultaneous
>>>>> > threaded discussion sprouting up throughout the site. Rather than
>>>>> sifting
>>>>> > through all the pages in the site in order to keep up, the instructor
>>>>> simply
>>>>> > goes to the aggregate discussion view where he is presented with a UI
>>>>> that
>>>>> > is similar to a traditional discussion forum; with the exception that
>>>>> the
>>>>> > discussion topics and threads consist of the same stuff found in the
>>>>> > vignettes that are scattered throughout the site.
>>>>> >
>>>>> > A few interesting points about this aggregate page view: Similar to
>>>>> the
>>>>> > vignettes, this view would have a user-facing side and an admin
>>>>> control
>>>>> > panel of some sort. Also, the aggregate view may be available only to
>>>>> the
>>>>> > site maintainer (or instructor in the above story) or to everyone
>>>>> (including
>>>>> > his students). If the latter is true, than in theory, a student can
>>>>> engage
>>>>> > a particular discussion either inline on a page where a vignette is
>>>>> > presented, or by going into the aggregate "discussion forum" view.
>>>>> >
>>>>> > Another side note to all of this is that when a new discussion
>>>>> vignette is
>>>>> > added to a page, it is then automatically pushed to the aggregate
>>>>> view and
>>>>> > collected there. However, if a discussion post is added while in the
>>>>> > aggregate view, it is NOT automatically pushed to some site page.
>>>>> This
>>>>> > implies that the aggregate view can contain more discussion posts
>>>>> than might
>>>>> > appear in the regular site pages. However, probably any such post in
>>>>> the
>>>>> > aggregate view can be pulled into a page while the page is being
>>>>> composed.
>>>>> >
>>>>> > We then briefly discussed the UX question of "how might a user locate
>>>>> one of
>>>>> > these aggregate views"? We touched on a few ideas, but nothing worth
>>>>> > mentioning until we put a bit more thought into them.
>>>>> >
>>>>> > Also, we focused on "threaded discussion" functionality to keep the
>>>>> model
>>>>> > manageable for now. None of this has been tested on other functional
>>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all of
>>>>> this
>>>>> > will hold water once we get there.
>>>>> >
>>>>> > Cheers,
>>>>> > Nathan
>>>>> >
>>>>> > --
>>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>>>>> >
>>>>> > E. [hidden email]
>>>>> > M. 602.418.5092
>>>>> > Y. npearson99 (Yahoo)
>>>>> > S. npearson99 (Skype)
>>>>> >
>>>>> >
>>>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix<http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40groupcalendar.google.com&ctz=America/Phoenix>
>>>>> >
>>>>>  > ________________________________
>>>>> > This automatic notification message was sent by Sakai Collab
>>>>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring
>>>>> site.
>>>>> > You can modify how you receive notifications at My Workspace >
>>>>> Preferences.
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Clay Fenlason
>>>>> Director, Educational Technology
>>>>> Georgia Institute of Technology
>>>>> (404) 385-6644
>>>>> ------------------------------
>>>>>
>>>>> This automatic notification message was sent by Sakai Collab (
>>>>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>>>> You can modify how you receive notifications at My Workspace >
>>>>> Preferences.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nathan Pearson | UX Lead | Sakai Foundation
>>>>
>>>> E. [hidden email]
>>>> M. 602.418.5092
>>>> Y npearson99 (Yahoo)
>>>> S. npearson99 (Skype)
>>>>
>>>>
>>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>>
>>>>  ------------------------------
>>>>
>>>> This automatic notification message was sent by Sakai Collab (
>>>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>>> You can modify how you receive notifications at My Workspace >
>>>> Preferences.
>>>>
>>>>
>>>>   Daphne Ogle
>>>> Senior Interaction Designer
>>>> University of California, Berkeley
>>>> Educational Technology Services
>>>> [hidden email]
>>>> cell (510)847-0308
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Nathan Pearson | UX Lead | Sakai Foundation
>>>
>>> E. [hidden email]
>>> M. 602.418.5092
>>> Y. npearson99 (Yahoo)
>>> S. npearson99 (Skype)
>>>
>>>
>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>
>>>  ------------------------------
>>>
>>> This automatic notification message was sent by Sakai Collab (
>>> https://collab.sakaiproject.org//portal) from the DG: User Experience
>>> site.
>>> You can modify how you receive notifications at My Workspace >
>>> Preferences.
>>>
>>>
>>> --
>>>
>>>
>>>  <http://www.oracle.com>
>>>  Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>> Oracle Academic Enterprise Solutions Group
>>> 23A Glendale Road, Glendale, MA 01229
>>>
>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. [hidden email]
>> M. 602.418.5092
>> Y. npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>
>>
>> --
>>
>>
>> [image: Oracle] <http://www.oracle.com>
>>  Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> Oracle Academic Enterprise Solutions Group
>> 23A Glendale Road, Glendale, MA 01229
>>
>> [see attachment: "unknown", size: 658 bytes]
>>
>> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>>
>> Attachments:
>>
>> unknown<https://collab.sakaiproject.org//access/content/attachment/378d1578-1ded-445b-b42c-a1d6f6244b10/unknown.gif>
>>
>> oracle_sig_logo.gif<https://collab.sakaiproject.org//access/content/attachment/4f232756-9409-4a25-b106-ab663880c6a7/oracle_sig_logo.gif>
>>
>> ------------------------------
>>
>> This automatic notification message was sent by Sakai Collab (
>> https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>
>
>
> --
> Sean Keesler
> 130 Academy Street
> Manlius, NY 13104
> 315-663-7756
>



--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Nathan Pearson Nathan Pearson
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update

In reply to this post by skeesler

Thanks for this Luke.  You've done a better job of describing what I had in
mind.  The Site Tool widget would enable the notion of "legacy Sakai" which
is somewhat analogous to the BB model (create content / activities and then
drop them into a page) vs. 3akai page authoring, which is somewhat analogous
to the Moodle model (create a page and generate content / activities
inline).

It's entirely possible for both models to exist at the same time in the same
site.


On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez
<[hidden email]>wrote:

> Advanced apologies: The following are some visceral reactions.  They
> aren't informed by expertise in design so much as by a mindset that
> has been molded by teaching in BB Vista and Moodle.
>
> The approach Sean describes is more or less the approach that BB Vista
> (e.g. WebCT) instructors are funneled into by default: The user
> creates activities (e.g. discussions, quizes etc.) or content (e.g.
> files or links to Web pages) and after having created some of these
> activities or content the instructor can arrange them into learning
> sequences.
>
> In contrast, the typical Moodle configuration more or less reverses
> this approach:  The overall learning sequence of the site have been
> predefined.  The instructor is presented with the predefined sequence
> and then they author/drop-in the content or activities of their
> choosing into this sequence.
>
> To say this in terms that don't refer to any product category: One
> authoring approach encourages instructors to author content and
> activities in a context that is abstracted from a sequence and then to
> create this learning sequence afterward.  The other authoring approach
> presents a predefined sequence and then prompts the instructor to
> author content/activities within the context of this sequence.
>
> In our own discussion with faculty at Weber we've seen merits in both
> approaches.
>
> Luke
>
> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]> wrote:
> > That idea hits home. If I were designing a website (maybe for
> collaborative
> > editing/brainstorming with a group), then organizing the space may into
> > pages make a lot of sense.
> >
> > If I am trying get my course syllabus up and running in Sakai, it might
> not.
> > Maybe a competing (rather traditional) train of thought would be.
> >
> > First designing the activities.
> > Organizing and relating the activities to each other (by chronology,
> topic,
> > type, etc).
> >
> > Sean
> >
> >
> >
> > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
> > <[hidden email]> wrote:
> >>
> >> I'm afraid that I don't have a better idea. I'm just suggesting that
> there
> >> should be some user testing of the notion that faculty will be
> comfortable
> >> thinking about configuring their learning environment as:
> >>
> >> First creating new pages
> >> Then putting functionality on those pages
> >>
> >> Does the blank slate work for them? Even with templates, the current
> >> design suggests that faculty (particularly ones who are new to 3akai)
> will
> >> have to intuit that, in order to add a discussion board (for example),
> they
> >> must first create a new page. It may be that this is not a big deal for
> >> faculty to get. But my experience with the execution of a somewhat
> similar
> >> model in WebCT was bad enough to make me worry.
> >>
> >> - m
> >>
> >>
> >> Nathan Pearson wrote:
> >>
> >> I'm not sure I understand the feedback.  What do you have in mind as a
> >> better way to do it?
> >>
> >>
> >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
> >> <[hidden email]> wrote:
> >>>
> >>> Hmm.
> >>>
> >>> I just was helping my wife wrestle with Blackboard CE8 today, and this
> is
> >>> mock-up is suddenly feeling a little familiar. And not in a good way.
> My
> >>> sense is that WebCT started off with the same idea that people should
> just
> >>> be able to assemble pages and put anything they want on them. The
> execution
> >>> was particularly clunky, probably in part because of the technology
> base
> >>> they were dealing with at the time they designed the system. But beyond
> >>> that, I'm not sure that the typical faculty member thinks of putting
> >>> together their course in terms of assembling pages first and then
> putting
> >>> functionality on the pages. Maybe it's possible to execute the concept
> in a
> >>> way that makes it more intuitive than it is in CE (in fact, I'm sure of
> it),
> >>> but I just don't know if "Create a New Page" carries the semantic
> freight
> >>> necessary.
> >>>
> >>> - m
> >>>
> >>>
> >>> Nathan Pearson wrote:
> >>>
> >>> I think it will come down to the affordance of where the option is
> >>> displayed on the screen, the context, and the terminology.  This is
> what I
> >>> had in mind based on Clay's comments:
> >>>
> >>>
> >>>
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
> >>>
> >>> It still forces the user to make a choice, but the imposition isn't
> >>> significant and can easily be ignored.  If we push the idea too far out
> of
> >>> one's reach or periphery, then we risk making it too inefficient to get
> at.
> >>>
> >>> Nathan
> >>>
> >>>
> >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <
> [hidden email]>
> >>> wrote:
> >>>>
> >>>> To add to the comparison with confluence, (being bad here with self
> >>>> referential design but I think it applies more broadly) I know the
> subtle
> >>>> "template" link is there but I ignore it because I'm almost always in
> a
> >>>> hurry when I create a page in confluence and "template" doesn't hold
> any
> >>>> value for me.  If I knew there were templates that would make my work
> easier
> >>>> perhaps I would use it.   So I think it's more than just making sure
> users
> >>>> see that there are templates  When we ask them if they want to use a
> >>>> template, I think we should also allow them to discover the kinds of
> >>>> templates there are and they can help me in my work.  Some users will
> be
> >>>> curious and play around with options such as templates but what we
> find
> >>>> often in user research is that users are very busy and will go the
> most
> >>>> direct route they can.  I guess what I'm contemplating is, "Is the
> word
> >>>> template enough information scent to allow users to know why they
> should
> >>>> choose it?"
> >>>> -Daphne
> >>>>
> >>>>
> >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
> >>>>
> >>>> You're probably right.  There's still the issue of applying a page
> >>>> template -- which should come before the edit page view.  Confluence
> does it
> >>>> in a bit of a quirky way IMO where they drop you into the edit view,
> and if
> >>>> you happen to see the subtle link to invoke a template, you can take a
> step
> >>>> back to take two forward in applying a template.  I find this pattern
> to be
> >>>> a bit clumsy.
> >>>>
> >>>> Maybe the way to get the best of both worlds is to use a drop down
> when
> >>>> clicking the Create New Page button that presents the options: Blank
> Page or
> >>>> From Template.
> >>>>
> >>>> Nathan
> >>>>
> >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
> >>>> <[hidden email]> wrote:
> >>>>>
> >>>>> Sorry I couldn't make today's discussion, and particularly sorry
> since
> >>>>> I'm going to indulge a bit of grousing about the create page bits,
> but
> >>>>> I trust my stammering about the point yesterday may have prepared you
> >>>>> for this line of attack, and that you understand the appreciative
> >>>>> place it comes from ... so I can let my hair down. I'm going to put
> >>>>> myself into the mind of an imagined, petulant user just to make a
> >>>>> point.
> >>>>>
> >>>>> My gut instinct for the page creation suggested here is that there is
> >>>>> too much complexity. Too many new words and ideas, too many
> >>>>> possibilities on the screen, too many pictures, etc. Yes, it's done
> >>>>> in the guise of helping people make good decisions at the outset, but
> >>>>> I think it risks bewilderment by being overhelpful at the wrong time,
> >>>>> and emphasizing the wrong things.
> >>>>>
> >>>>> There is a really simple concept at the core of the new page
> authoring
> >>>>> metaphor which seems to me both powerful and elegant. You have a
> >>>>> page, and you can start typing and/or drop things into the page that
> >>>>> might be small (like a single assignment) or large (like a table of
> >>>>> all assignments). But we bring little advantage to this simple
> >>>>> concept by trying to define new kinds of pages or laying out the full
> >>>>> spread of tools during the process of page creation.
> >>>>>
> >>>>> By the same token, we're not helping people by presenting the default
> >>>>> option as a "blank page." Of *course* I don't want a blank page: I'm
> >>>>> not going to choose that. I want a page that will have stuff in it.
> >>>>> But rather than present me with a simple emphasis on how to quickly
> >>>>> start authoring a page you appear to be putting your effort into
> >>>>> front-loading my decision-making with a "page type," which
> >>>>> instinctively strikes me as an odd notion: unnecessary and unhelpful.
> >>>>>
> >>>>> It's not about the *page*. It's about what goes *in* the page. I'm
> >>>>> trying to create my content and you keep trying to get me to look at
> >>>>> the margins or declare my full intent ahead of time.
> >>>>>
> >>>>> In other words I think the design simply has the wrong focus at this
> >>>>> stage. What if we instead focused design energies on making the
> >>>>> editing easy and flexible, and left the mere creation of the page
> >>>>> virtually transparent? What if, instead of some dialogue asking about
> >>>>> what kind of page this will be, when I click on "create a new page"
> >>>>> I'm immediately there, or I'm immediately at a place that asks, "OK,
> >>>>> ta-da, you have your page: now what are you going to put in it?"
> (e.g.
> >>>>> with an interface that immediately leads me into either typing or
> >>>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
> >>>>> what I'm going to put in it by leading with *that* kind of choice
> >>>>> instead.
> >>>>>
> >>>>> Stepping back for a moment from my frothy remarks (which, again, I
> >>>>> mean a bit playfully, but to make a point): I don't mean to insist
> >>>>> that I really know what people want, but I do mean to suggest that I
> >>>>> think this really needs testing.
> >>>>>
> >>>>> ~Clay
> >>>>>
> >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <
> [hidden email]>
> >>>>> wrote:
> >>>>> > Today's UX working session reviewed a few tweaks to the header area
> >>>>> > of the
> >>>>> > site screen, plus a review of the "create page" screen. Both can be
> >>>>> > found
> >>>>> > here:
> >>>>> >
> >>>>> >
> >>>>> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
> >>>>> >
> >>>>> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
> >>>>> >
> >>>>> > We also dove into the meatier topic of widgets/entities, which
> we've
> >>>>> > begun
> >>>>> > calling vignettes (sorry to introduce more terminology, but we're
> >>>>> > hoping
> >>>>> > this will be better choice of words in the long run).
> >>>>> >
> >>>>> > As we see it, there are two major interaction themes within Sakai
> >>>>> > sites.
> >>>>> > The first consists of pages that contain a smattering of content
> >>>>> > types;
> >>>>> > ranging from text to functional bits called vignettes. The second
> >>>>> > consists
> >>>>> > of something called aggregate views (more on this later).
> >>>>> >
> >>>>> > To illustrate the vignette idea a bit more clearly, we discussed
> the
> >>>>> > following story:
> >>>>> >
> >>>>> > An instructor creates a page titled "week 1" and in that pages
> >>>>> > provides a
> >>>>> > short summary and informs students to read chapters 3 & 4. Below
> this
> >>>>> > block
> >>>>> > of text, she inserts a discussion vignette and adds a brief header
> to
> >>>>> > it
> >>>>> > that reads "When you're done with chapter 3, discuss the following
> >>>>> > concept:
> >>>>> > xyz". The instructor then adds more text related to chapter 4, then
> >>>>> > addes a
> >>>>> > series of multiple choice questions -- which appear by inserting
> >>>>> > survey
> >>>>> > vignettes. Below these questions, she continues to add more text
> that
> >>>>> > tells
> >>>>> > her students to prepare a 5 page write-up on both chapters and
> submit
> >>>>> > it in
> >>>>> > the bottom of the page, or into the drop box vignette.
> >>>>> >
> >>>>> > A vignette would have a user-facing view as well as an edit/admin
> >>>>> > view. The
> >>>>> > latter would likely be presented during the edit page mode and the
> >>>>> > former
> >>>>> > during the view page mode. However there may be some carry over
> from
> >>>>> > one to
> >>>>> > the other, as in the case of a preview option while in the edit
> mode.
> >>>>> >
> >>>>> > As for aggregate views, they can be thought of as a central place
> >>>>> > that
> >>>>> > consolidates a collection of all the vignettes that happen to be
> >>>>> > peppered
> >>>>> > through a site. Another way to think of it, which may or may not be
> >>>>> > helpful, is as a conventional tool view. To illustrate, one might
> >>>>> > imagine
> >>>>> > the following story:
> >>>>> >
> >>>>> > Before the start of a semester, the instructor has composed a bunch
> >>>>> > of pages
> >>>>> > to teach his hybrid class. Several of those pages include one or
> more
> >>>>> > discussion vignettes. As the semester gets under way, students
> begin
> >>>>> > posting replies across a variety of pages, resulting in
> simultaneous
> >>>>> > threaded discussion sprouting up throughout the site. Rather than
> >>>>> > sifting
> >>>>> > through all the pages in the site in order to keep up, the
> instructor
> >>>>> > simply
> >>>>> > goes to the aggregate discussion view where he is presented with a
> UI
> >>>>> > that
> >>>>> > is similar to a traditional discussion forum; with the exception
> that
> >>>>> > the
> >>>>> > discussion topics and threads consist of the same stuff found in
> the
> >>>>> > vignettes that are scattered throughout the site.
> >>>>> >
> >>>>> > A few interesting points about this aggregate page view: Similar to
> >>>>> > the
> >>>>> > vignettes, this view would have a user-facing side and an admin
> >>>>> > control
> >>>>> > panel of some sort. Also, the aggregate view may be available only
> to
> >>>>> > the
> >>>>> > site maintainer (or instructor in the above story) or to everyone
> >>>>> > (including
> >>>>> > his students). If the latter is true, than in theory, a student can
> >>>>> > engage
> >>>>> > a particular discussion either inline on a page where a vignette is
> >>>>> > presented, or by going into the aggregate "discussion forum" view.
> >>>>> >
> >>>>> > Another side note to all of this is that when a new discussion
> >>>>> > vignette is
> >>>>> > added to a page, it is then automatically pushed to the aggregate
> >>>>> > view and
> >>>>> > collected there. However, if a discussion post is added while in
> the
> >>>>> > aggregate view, it is NOT automatically pushed to some site page.
> >>>>> > This
> >>>>> > implies that the aggregate view can contain more discussion posts
> >>>>> > than might
> >>>>> > appear in the regular site pages. However, probably any such post
> in
> >>>>> > the
> >>>>> > aggregate view can be pulled into a page while the page is being
> >>>>> > composed.
> >>>>> >
> >>>>> > We then briefly discussed the UX question of "how might a user
> locate
> >>>>> > one of
> >>>>> > these aggregate views"? We touched on a few ideas, but nothing
> worth
> >>>>> > mentioning until we put a bit more thought into them.
> >>>>> >
> >>>>> > Also, we focused on "threaded discussion" functionality to keep the
> >>>>> > model
> >>>>> > manageable for now. None of this has been tested on other
> functional
> >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all
> of
> >>>>> > this
> >>>>> > will hold water once we get there.
> >>>>> >
> >>>>> > Cheers,
> >>>>> > Nathan
> >>>>> >
> >>>>> > --
> >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
> >>>>> >
> >>>>> > E. [hidden email]
> >>>>> > M. 602.418.5092
> >>>>> > Y. npearson99 (Yahoo)
> >>>>> > S. npearson99 (Skype)
> >>>>> >
> >>>>> >
> >>>>> >
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >>>>> >
> >>>>> > ________________________________
> >>>>> > This automatic notification message was sent by Sakai Collab
> >>>>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring
> >>>>> > site.
> >>>>> > You can modify how you receive notifications at My Workspace >
> >>>>> > Preferences.
> >>>>> >
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Clay Fenlason
> >>>>> Director, Educational Technology
> >>>>> Georgia Institute of Technology
> >>>>> (404) 385-6644
> >>>>> ________________________________
> >>>>> This automatic notification message was sent by Sakai Collab
> >>>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
> site.
> >>>>> You can modify how you receive notifications at My Workspace >
> >>>>> Preferences.
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Nathan Pearson | UX Lead | Sakai Foundation
> >>>>
> >>>> E. [hidden email]
> >>>> M. 602.418.5092
> >>>> Y npearson99 (Yahoo)
> >>>> S. npearson99 (Skype)
> >>>>
> >>>>
> >>>>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >>>>
> >>>> ________________________________
> >>>> This automatic notification message was sent by Sakai Collab
> >>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
> site.
> >>>> You can modify how you receive notifications at My Workspace >
> >>>> Preferences.
> >>>>
> >>>> Daphne Ogle
> >>>> Senior Interaction Designer
> >>>> University of California, Berkeley
> >>>> Educational Technology Services
> >>>> [hidden email]
> >>>> cell (510)847-0308
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Nathan Pearson | UX Lead | Sakai Foundation
> >>>
> >>> E. [hidden email]
> >>> M. 602.418.5092
> >>> Y. npearson99 (Yahoo)
> >>> S. npearson99 (Skype)
> >>>
> >>>
> >>>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >>>
> >>> ________________________________
> >>> This automatic notification message was sent by Sakai Collab
> >>> (https://collab.sakaiproject.org//portal) from the DG: User Experience
> site.
> >>> You can modify how you receive notifications at My Workspace >
> >>> Preferences.
> >>>
> >>> --
> >>>
> >>>
> >>>
> >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >>> Oracle Academic Enterprise Solutions Group
> >>> 23A Glendale Road, Glendale, MA 01229
> >>
> >>
> >> --
> >> Nathan Pearson | UX Lead | Sakai Foundation
> >>
> >> E. [hidden email]
> >> M. 602.418.5092
> >> Y. npearson99 (Yahoo)
> >> S. npearson99 (Skype)
> >>
> >>
> >>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
> >>
> >> --
> >>
> >>
> >>
> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >> Oracle Academic Enterprise Solutions Group
> >> 23A Glendale Road, Glendale, MA 01229
> >>
> >> [see attachment: "unknown", size: 658 bytes]
> >>
> >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
> >>
> >> Attachments:
> >>
> >> unknown
> >>
> >> oracle_sig_logo.gif
> >>
> >> ________________________________
> >> This automatic notification message was sent by Sakai Collab
> >> (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> >> You can modify how you receive notifications at My Workspace >
> >> Preferences.
> >
> >
> >
> > --
> > Sean Keesler
> > 130 Academy Street
> > Manlius, NY 13104
> > 315-663-7756
> >
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the DG: User Experience
> site.
> > You can modify how you receive notifications at My Workspace >
> Preferences.
> >
>



--
Nathan Pearson | UX Lead | Sakai Foundation

E. [hidden email]
M. 602.418.5092
Y. npearson99 (Yahoo)
S. npearson99 (Skype)

http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Feldstein Michael Feldstein
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


Sorry, I got a bit behind on this thread.

The Moodle example is an instructive one, and I think it's important not
to miss the details. To begin with, when a user creates a new course
site in Moodle, she is prompted to choose a site format.

Moodle site format config

Moodle's lovely embedded help feature describes the "Format" options as
follows:

>
>   Moodle course formats
>
>
>     LAMS course format
>
> This format makes the Learning Activity Management System (LAMS)
> interface central to the course. LAMS requires setting up by an
> administrator in order to use this format.
>
>
>     SCORM format
>
> This format displays a SCORM package in the first section of the
> course home page. (The SCORM/AICC module provides an alternative
> method of displaying a SCORM package in a course.)
>
>
>     Social format
>
> This format is oriented around one main forum, the Social forum, which
> appears on the course home page. It is useful for situations that are
> more freeform. They may not even be courses. For example, it could be
> used as a departmental notice board.
>
>
>     Topics format
>
> The course is organised into topic sections. Each topic section
> consists of activities.
>
>
>     Weekly format
>
> The course is organised week by week, with a clear start date and a
> finish date. Each week consists of activities.
>
>
>     Weekly format - CSS/No tables
>
> The course is organised week by week without using tables for layout.
>
When Luke talks about the overall learning sequence of the site being
defined, that entails at least two things, both of which flow from that
initial site format choice. First, there is a home page for the site
that has boxes which essentially outline the course structure.

Moodle Course Home Page (weekly format)

Second, all content and activities are created and implicitly sequenced
within the context of that structure.

Course Home Page - Editing Mode

So, if I'm understanding the current proposal for the 3akai sidebar
correctly, then Moodle still provides considerably more scaffolding to
the faculty. I like the idea of having an "anything goes" course site
format, but I also think that Moodle's more structured options are also
good models that are worth emulating.

- m


Nathan Pearson wrote:

> Thanks for this Luke.  You've done a better job of describing what I
> had in mind.  The Site Tool widget would enable the notion of "legacy
> Sakai" which is somewhat analogous to the BB model (create content /
> activities and then drop them into a page) vs. 3akai page authoring,
> which is somewhat analogous to the Moodle model (create a page and
> generate content / activities inline).
>
> It's entirely possible for both models to exist at the same time in
> the same site.
>
>
> On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Advanced apologies: The following are some visceral reactions.  They
>     aren't informed by expertise in design so much as by a mindset that
>     has been molded by teaching in BB Vista and Moodle.
>
>     The approach Sean describes is more or less the approach that BB Vista
>     (e.g. WebCT) instructors are funneled into by default: The user
>     creates activities (e.g. discussions, quizes etc.) or content (e.g.
>     files or links to Web pages) and after having created some of these
>     activities or content the instructor can arrange them into learning
>     sequences.
>
>     In contrast, the typical Moodle configuration more or less reverses
>     this approach:  The overall learning sequence of the site have been
>     predefined.  The instructor is presented with the predefined sequence
>     and then they author/drop-in the content or activities of their
>     choosing into this sequence.
>
>     To say this in terms that don't refer to any product category: One
>     authoring approach encourages instructors to author content and
>     activities in a context that is abstracted from a sequence and then to
>     create this learning sequence afterward.  The other authoring approach
>     presents a predefined sequence and then prompts the instructor to
>     author content/activities within the context of this sequence.
>
>     In our own discussion with faculty at Weber we've seen merits in both
>     approaches.
>
>     Luke
>
>     On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     > That idea hits home. If I were designing a website (maybe for
>     collaborative
>     > editing/brainstorming with a group), then organizing the space
>     may into
>     > pages make a lot of sense.
>     >
>     > If I am trying get my course syllabus up and running in Sakai,
>     it might not.
>     > Maybe a competing (rather traditional) train of thought would be.
>     >
>     > First designing the activities.
>     > Organizing and relating the activities to each other (by
>     chronology, topic,
>     > type, etc).
>     >
>     > Sean
>     >
>     >
>     >
>     > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
>     > <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>
>     >> I'm afraid that I don't have a better idea. I'm just suggesting
>     that there
>     >> should be some user testing of the notion that faculty will be
>     comfortable
>     >> thinking about configuring their learning environment as:
>     >>
>     >> First creating new pages
>     >> Then putting functionality on those pages
>     >>
>     >> Does the blank slate work for them? Even with templates, the
>     current
>     >> design suggests that faculty (particularly ones who are new to
>     3akai) will
>     >> have to intuit that, in order to add a discussion board (for
>     example), they
>     >> must first create a new page. It may be that this is not a big
>     deal for
>     >> faculty to get. But my experience with the execution of a
>     somewhat similar
>     >> model in WebCT was bad enough to make me worry.
>     >>
>     >> - m
>     >>
>     >>
>     >> Nathan Pearson wrote:
>     >>
>     >> I'm not sure I understand the feedback.  What do you have in
>     mind as a
>     >> better way to do it?
>     >>
>     >>
>     >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
>     >> <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>>
>     >>> Hmm.
>     >>>
>     >>> I just was helping my wife wrestle with Blackboard CE8 today,
>     and this is
>     >>> mock-up is suddenly feeling a little familiar. And not in a
>     good way. My
>     >>> sense is that WebCT started off with the same idea that people
>     should just
>     >>> be able to assemble pages and put anything they want on them.
>     The execution
>     >>> was particularly clunky, probably in part because of the
>     technology base
>     >>> they were dealing with at the time they designed the system.
>     But beyond
>     >>> that, I'm not sure that the typical faculty member thinks of
>     putting
>     >>> together their course in terms of assembling pages first and
>     then putting
>     >>> functionality on the pages. Maybe it's possible to execute the
>     concept in a
>     >>> way that makes it more intuitive than it is in CE (in fact,
>     I'm sure of it),
>     >>> but I just don't know if "Create a New Page" carries the
>     semantic freight
>     >>> necessary.
>     >>>
>     >>> - m
>     >>>
>     >>>
>     >>> Nathan Pearson wrote:
>     >>>
>     >>> I think it will come down to the affordance of where the option is
>     >>> displayed on the screen, the context, and the terminology.
>      This is what I
>     >>> had in mind based on Clay's comments:
>     >>>
>     >>>
>     >>>
>     http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>     >>>
>     >>> It still forces the user to make a choice, but the imposition
>     isn't
>     >>> significant and can easily be ignored.  If we push the idea
>     too far out of
>     >>> one's reach or periphery, then we risk making it too
>     inefficient to get at.
>     >>>
>     >>> Nathan
>     >>>
>     >>>
>     >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
>     <[hidden email] <mailto:[hidden email]>>
>     >>> wrote:
>     >>>>
>     >>>> To add to the comparison with confluence, (being bad here
>     with self
>     >>>> referential design but I think it applies more broadly) I
>     know the subtle
>     >>>> "template" link is there but I ignore it because I'm almost
>     always in a
>     >>>> hurry when I create a page in confluence and "template"
>     doesn't hold any
>     >>>> value for me.  If I knew there were templates that would make
>     my work easier
>     >>>> perhaps I would use it.   So I think it's more than just
>     making sure users
>     >>>> see that there are templates  When we ask them if they want
>     to use a
>     >>>> template, I think we should also allow them to discover the
>     kinds of
>     >>>> templates there are and they can help me in my work.  Some
>     users will be
>     >>>> curious and play around with options such as templates but
>     what we find
>     >>>> often in user research is that users are very busy and will
>     go the most
>     >>>> direct route they can.  I guess what I'm contemplating is,
>     "Is the word
>     >>>> template enough information scent to allow users to know why
>     they should
>     >>>> choose it?"
>     >>>> -Daphne
>     >>>>
>     >>>>
>     >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>     >>>>
>     >>>> You're probably right.  There's still the issue of applying a
>     page
>     >>>> template -- which should come before the edit page view.
>      Confluence does it
>     >>>> in a bit of a quirky way IMO where they drop you into the
>     edit view, and if
>     >>>> you happen to see the subtle link to invoke a template, you
>     can take a step
>     >>>> back to take two forward in applying a template.  I find this
>     pattern to be
>     >>>> a bit clumsy.
>     >>>>
>     >>>> Maybe the way to get the best of both worlds is to use a drop
>     down when
>     >>>> clicking the Create New Page button that presents the
>     options: Blank Page or
>     >>>> From Template.
>     >>>>
>     >>>> Nathan
>     >>>>
>     >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
>     >>>> <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>>>>
>     >>>>> Sorry I couldn't make today's discussion, and particularly
>     sorry since
>     >>>>> I'm going to indulge a bit of grousing about the create page
>     bits, but
>     >>>>> I trust my stammering about the point yesterday may have
>     prepared you
>     >>>>> for this line of attack, and that you understand the
>     appreciative
>     >>>>> place it comes from ... so I can let my hair down. I'm going
>     to put
>     >>>>> myself into the mind of an imagined, petulant user just to
>     make a
>     >>>>> point.
>     >>>>>
>     >>>>> My gut instinct for the page creation suggested here is that
>     there is
>     >>>>> too much complexity. Too many new words and ideas, too many
>     >>>>> possibilities on the screen, too many pictures, etc. Yes,
>     it's done
>     >>>>> in the guise of helping people make good decisions at the
>     outset, but
>     >>>>> I think it risks bewilderment by being overhelpful at the
>     wrong time,
>     >>>>> and emphasizing the wrong things.
>     >>>>>
>     >>>>> There is a really simple concept at the core of the new page
>     authoring
>     >>>>> metaphor which seems to me both powerful and elegant. You have a
>     >>>>> page, and you can start typing and/or drop things into the
>     page that
>     >>>>> might be small (like a single assignment) or large (like a
>     table of
>     >>>>> all assignments). But we bring little advantage to this simple
>     >>>>> concept by trying to define new kinds of pages or laying out
>     the full
>     >>>>> spread of tools during the process of page creation.
>     >>>>>
>     >>>>> By the same token, we're not helping people by presenting
>     the default
>     >>>>> option as a "blank page." Of *course* I don't want a blank
>     page: I'm
>     >>>>> not going to choose that. I want a page that will have stuff
>     in it.
>     >>>>> But rather than present me with a simple emphasis on how to
>     quickly
>     >>>>> start authoring a page you appear to be putting your effort into
>     >>>>> front-loading my decision-making with a "page type," which
>     >>>>> instinctively strikes me as an odd notion: unnecessary and
>     unhelpful.
>     >>>>>
>     >>>>> It's not about the *page*. It's about what goes *in* the
>     page. I'm
>     >>>>> trying to create my content and you keep trying to get me to
>     look at
>     >>>>> the margins or declare my full intent ahead of time.
>     >>>>>
>     >>>>> In other words I think the design simply has the wrong focus
>     at this
>     >>>>> stage. What if we instead focused design energies on making the
>     >>>>> editing easy and flexible, and left the mere creation of the
>     page
>     >>>>> virtually transparent? What if, instead of some dialogue
>     asking about
>     >>>>> what kind of page this will be, when I click on "create a
>     new page"
>     >>>>> I'm immediately there, or I'm immediately at a place that
>     asks, "OK,
>     >>>>> ta-da, you have your page: now what are you going to put in
>     it?" (e.g.
>     >>>>> with an interface that immediately leads me into either
>     typing or
>     >>>>> plugging in "vignettes") Instead of emphasizing the page,
>     emphasize
>     >>>>> what I'm going to put in it by leading with *that* kind of
>     choice
>     >>>>> instead.
>     >>>>>
>     >>>>> Stepping back for a moment from my frothy remarks (which,
>     again, I
>     >>>>> mean a bit playfully, but to make a point): I don't mean to
>     insist
>     >>>>> that I really know what people want, but I do mean to
>     suggest that I
>     >>>>> think this really needs testing.
>     >>>>>
>     >>>>> ~Clay
>     >>>>>
>     >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
>     <[hidden email] <mailto:[hidden email]>>
>     >>>>> wrote:
>     >>>>> > Today's UX working session reviewed a few tweaks to the
>     header area
>     >>>>> > of the
>     >>>>> > site screen, plus a review of the "create page" screen.
>     Both can be
>     >>>>> > found
>     >>>>> > here:
>     >>>>> >
>     >>>>> >
>     >>>>> >
>     http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>     >>>>> >
>     >>>>> >
>     http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>     >>>>> >
>     >>>>> > We also dove into the meatier topic of widgets/entities,
>     which we've
>     >>>>> > begun
>     >>>>> > calling vignettes (sorry to introduce more terminology,
>     but we're
>     >>>>> > hoping
>     >>>>> > this will be better choice of words in the long run).
>     >>>>> >
>     >>>>> > As we see it, there are two major interaction themes
>     within Sakai
>     >>>>> > sites.
>     >>>>> > The first consists of pages that contain a smattering of
>     content
>     >>>>> > types;
>     >>>>> > ranging from text to functional bits called vignettes. The
>     second
>     >>>>> > consists
>     >>>>> > of something called aggregate views (more on this later).
>     >>>>> >
>     >>>>> > To illustrate the vignette idea a bit more clearly, we
>     discussed the
>     >>>>> > following story:
>     >>>>> >
>     >>>>> > An instructor creates a page titled "week 1" and in that pages
>     >>>>> > provides a
>     >>>>> > short summary and informs students to read chapters 3 & 4.
>     Below this
>     >>>>> > block
>     >>>>> > of text, she inserts a discussion vignette and adds a
>     brief header to
>     >>>>> > it
>     >>>>> > that reads "When you're done with chapter 3, discuss the
>     following
>     >>>>> > concept:
>     >>>>> > xyz". The instructor then adds more text related to
>     chapter 4, then
>     >>>>> > addes a
>     >>>>> > series of multiple choice questions -- which appear by
>     inserting
>     >>>>> > survey
>     >>>>> > vignettes. Below these questions, she continues to add
>     more text that
>     >>>>> > tells
>     >>>>> > her students to prepare a 5 page write-up on both chapters
>     and submit
>     >>>>> > it in
>     >>>>> > the bottom of the page, or into the drop box vignette.
>     >>>>> >
>     >>>>> > A vignette would have a user-facing view as well as an
>     edit/admin
>     >>>>> > view. The
>     >>>>> > latter would likely be presented during the edit page mode
>     and the
>     >>>>> > former
>     >>>>> > during the view page mode. However there may be some carry
>     over from
>     >>>>> > one to
>     >>>>> > the other, as in the case of a preview option while in the
>     edit mode.
>     >>>>> >
>     >>>>> > As for aggregate views, they can be thought of as a
>     central place
>     >>>>> > that
>     >>>>> > consolidates a collection of all the vignettes that happen
>     to be
>     >>>>> > peppered
>     >>>>> > through a site. Another way to think of it, which may or
>     may not be
>     >>>>> > helpful, is as a conventional tool view. To illustrate,
>     one might
>     >>>>> > imagine
>     >>>>> > the following story:
>     >>>>> >
>     >>>>> > Before the start of a semester, the instructor has
>     composed a bunch
>     >>>>> > of pages
>     >>>>> > to teach his hybrid class. Several of those pages include
>     one or more
>     >>>>> > discussion vignettes. As the semester gets under way,
>     students begin
>     >>>>> > posting replies across a variety of pages, resulting in
>     simultaneous
>     >>>>> > threaded discussion sprouting up throughout the site.
>     Rather than
>     >>>>> > sifting
>     >>>>> > through all the pages in the site in order to keep up, the
>     instructor
>     >>>>> > simply
>     >>>>> > goes to the aggregate discussion view where he is
>     presented with a UI
>     >>>>> > that
>     >>>>> > is similar to a traditional discussion forum; with the
>     exception that
>     >>>>> > the
>     >>>>> > discussion topics and threads consist of the same stuff
>     found in the
>     >>>>> > vignettes that are scattered throughout the site.
>     >>>>> >
>     >>>>> > A few interesting points about this aggregate page view:
>     Similar to
>     >>>>> > the
>     >>>>> > vignettes, this view would have a user-facing side and an
>     admin
>     >>>>> > control
>     >>>>> > panel of some sort. Also, the aggregate view may be
>     available only to
>     >>>>> > the
>     >>>>> > site maintainer (or instructor in the above story) or to
>     everyone
>     >>>>> > (including
>     >>>>> > his students). If the latter is true, than in theory, a
>     student can
>     >>>>> > engage
>     >>>>> > a particular discussion either inline on a page where a
>     vignette is
>     >>>>> > presented, or by going into the aggregate "discussion
>     forum" view.
>     >>>>> >
>     >>>>> > Another side note to all of this is that when a new discussion
>     >>>>> > vignette is
>     >>>>> > added to a page, it is then automatically pushed to the
>     aggregate
>     >>>>> > view and
>     >>>>> > collected there. However, if a discussion post is added
>     while in the
>     >>>>> > aggregate view, it is NOT automatically pushed to some
>     site page.
>     >>>>> > This
>     >>>>> > implies that the aggregate view can contain more
>     discussion posts
>     >>>>> > than might
>     >>>>> > appear in the regular site pages. However, probably any
>     such post in
>     >>>>> > the
>     >>>>> > aggregate view can be pulled into a page while the page is
>     being
>     >>>>> > composed.
>     >>>>> >
>     >>>>> > We then briefly discussed the UX question of "how might a
>     user locate
>     >>>>> > one of
>     >>>>> > these aggregate views"? We touched on a few ideas, but
>     nothing worth
>     >>>>> > mentioning until we put a bit more thought into them.
>     >>>>> >
>     >>>>> > Also, we focused on "threaded discussion" functionality to
>     keep the
>     >>>>> > model
>     >>>>> > manageable for now. None of this has been tested on other
>     functional
>     >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know
>     if all of
>     >>>>> > this
>     >>>>> > will hold water once we get there.
>     >>>>> >
>     >>>>> > Cheers,
>     >>>>> > Nathan
>     >>>>> >
>     >>>>> > --
>     >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>     >>>>> >
>     >>>>> > E. [hidden email] <mailto:[hidden email]>
>     >>>>> > M. 602.418.5092
>     >>>>> > Y. npearson99 (Yahoo)
>     >>>>> > S. npearson99 (Skype)
>     >>>>> >
>     >>>>> >
>     >>>>> >
>     http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>     <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>     >>>>> >
>     >>>>> > ________________________________
>     >>>>> > This automatic notification message was sent by Sakai Collab
>     >>>>> > (https://collab.sakaiproject.org//portal) from the WG:
>     Authoring
>     >>>>> > site.
>     >>>>> > You can modify how you receive notifications at My Workspace >
>     >>>>> > Preferences.
>     >>>>> >
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> --
>     >>>>> Clay Fenlason
>     >>>>> Director, Educational Technology
>     >>>>> Georgia Institute of Technology
>     >>>>> (404) 385-6644
>     >>>>> ________________________________
>     >>>>> This automatic notification message was sent by Sakai Collab
>     >>>>> (https://collab.sakaiproject.org//portal) from the WG:
>     Authoring site.
>     >>>>> You can modify how you receive notifications at My Workspace >
>     >>>>> Preferences.
>     >>>>
>     >>>>
>     >>>>
>     >>>> --
>     >>>> Nathan Pearson | UX Lead | Sakai Foundation
>     >>>>
>     >>>> E. [hidden email] <mailto:[hidden email]>
>     >>>> M. 602.418.5092
>     >>>> Y npearson99 (Yahoo)
>     >>>> S. npearson99 (Skype)
>     >>>>
>     >>>>
>     >>>>
>     http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>     <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>     >>>>
>     >>>> ________________________________
>     >>>> This automatic notification message was sent by Sakai Collab
>     >>>> (https://collab.sakaiproject.org//portal) from the WG:
>     Authoring site.
>     >>>> You can modify how you receive notifications at My Workspace >
>     >>>> Preferences.
>     >>>>
>     >>>> Daphne Ogle
>     >>>> Senior Interaction Designer
>     >>>> University of California, Berkeley
>     >>>> Educational Technology Services
>     >>>> [hidden email] <mailto:[hidden email]>
>     >>>> cell (510)847-0308
>     >>>>
>     >>>>
>     >>>
>     >>>
>     >>>
>     >>> --
>     >>> Nathan Pearson | UX Lead | Sakai Foundation
>     >>>
>     >>> E. [hidden email] <mailto:[hidden email]>
>     >>> M. 602.418.5092
>     >>> Y. npearson99 (Yahoo)
>     >>> S. npearson99 (Skype)
>     >>>
>     >>>
>     >>>
>     http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>     <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>     >>>
>     >>> ________________________________
>     >>> This automatic notification message was sent by Sakai Collab
>     >>> (https://collab.sakaiproject.org//portal) from the DG: User
>     Experience site.
>     >>> You can modify how you receive notifications at My Workspace >
>     >>> Preferences.
>     >>>
>     >>> --
>     >>>
>     >>>
>     >>>
>     >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>     >>> Oracle Academic Enterprise Solutions Group
>     >>> 23A Glendale Road, Glendale, MA 01229
>     >>
>     >>
>     >> --
>     >> Nathan Pearson | UX Lead | Sakai Foundation
>     >>
>     >> E. [hidden email] <mailto:[hidden email]>
>     >> M. 602.418.5092
>     >> Y. npearson99 (Yahoo)
>     >> S. npearson99 (Skype)
>     >>
>     >>
>     >>
>     http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>     <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>     >>
>     >> --
>     >>
>     >>
>     >>
>     >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>     >> Oracle Academic Enterprise Solutions Group
>     >> 23A Glendale Road, Glendale, MA 01229
>     >>
>     >> [see attachment: "unknown", size: 658 bytes]
>     >>
>     >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>     >>
>     >> Attachments:
>     >>
>     >> unknown
>     >>
>     >> oracle_sig_logo.gif
>     >>
>     >> ________________________________
>     >> This automatic notification message was sent by Sakai Collab
>     >> (https://collab.sakaiproject.org//portal) from the WG:
>     Authoring site.
>     >> You can modify how you receive notifications at My Workspace >
>     >> Preferences.
>     >
>     >
>     >
>     > --
>     > Sean Keesler
>     > 130 Academy Street
>     > Manlius, NY 13104
>     > 315-663-7756
>     >
>     > ________________________________
>     > This automatic notification message was sent by Sakai Collab
>     > (https://collab.sakaiproject.org//portal) from the DG: User
>     Experience site.
>     > You can modify how you receive notifications at My Workspace >
>     Preferences.
>     >
>
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email] <mailto:[hidden email]>
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>

--


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
[see attachment: "Moodle Course Format.jpg", size: 16456 bytes]

[see attachment: "Moodle Course Home Page.jpg", size: 113213 bytes]

[see attachment: "Course Home Page - Editing Mode.jpg", size: 82209 bytes]

[see attachment: "oracle_sig_logo.gif", size: 658 bytes]



Attachments:

Moodle Course Format.jpg
https://collab.sakaiproject.org//access/content/attachment/c1a12c07-6049-492c-867b-84840d5df138/Moodle%20Course%20Format.jpg

Moodle Course Home Page.jpg
https://collab.sakaiproject.org//access/content/attachment/2f97e3d4-4390-482a-a07a-ee8861536c60/Moodle%20Course%20Home%20Page.jpg

Course Home Page - Editing Mode.jpg
https://collab.sakaiproject.org//access/content/attachment/832ddc0d-747a-4bcb-bd8b-a1fd79334818/Course%20Home%20Page%20-%20Editing%20Mode.jpg

oracle_sig_logo.gif
https://collab.sakaiproject.org//access/content/attachment/5079dd28-1b8b-4db9-b69a-a6a71092ee3b/oracle_sig_logo.gif

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


I think these ideas are touched upon not in the sidebar of recent
design thinking, but rather in the "site template."  See the
(unfortunately narrow) discussion here, especially in the comments:

http://confluence.sakaiproject.org/confluence/x/iATWAg

The basic pattern would be "anything goes" for raw capability, with
templates (chosen during creation, I'm not sure if they could be
switched after) for scaffolding.

~Clay

On Mon, Jan 19, 2009 at 10:31 AM, Michael Feldstein
<[hidden email]> wrote:

> Sorry, I got a bit behind on this thread.
>
> The Moodle example is an instructive one, and I think it's important not to
> miss the details. To begin with, when a user creates a new course site in
> Moodle, she is prompted to choose a site format.
>
>
>
> Moodle's lovely embedded help feature describes the "Format" options as
> follows:
>
> Moodle course formats
>
> LAMS course format
>
> This format makes the Learning Activity Management System (LAMS) interface
> central to the course. LAMS requires setting up by an administrator in order
> to use this format.
>
> SCORM format
>
> This format displays a SCORM package in the first section of the course home
> page. (The SCORM/AICC module provides an alternative method of displaying a
> SCORM package in a course.)
>
> Social format
>
> This format is oriented around one main forum, the Social forum, which
> appears on the course home page. It is useful for situations that are more
> freeform. They may not even be courses. For example, it could be used as a
> departmental notice board.
>
> Topics format
>
> The course is organised into topic sections. Each topic section consists of
> activities.
>
> Weekly format
>
> The course is organised week by week, with a clear start date and a finish
> date. Each week consists of activities.
>
> Weekly format - CSS/No tables
>
> The course is organised week by week without using tables for layout.
>
> When Luke talks about the overall learning sequence of the site being
> defined, that entails at least two things, both of which flow from that
> initial site format choice. First, there is a home page for the site that
> has boxes which essentially outline the course structure.
>
>
>
> Second, all content and activities are created and implicitly sequenced
> within the context of that structure.
>
>
>
> So, if I'm understanding the current proposal for the 3akai sidebar
> correctly, then Moodle still provides considerably more scaffolding to the
> faculty. I like the idea of having an "anything goes" course site format,
> but I also think that Moodle's more structured options are also good models
> that are worth emulating.
>
> - m
>
>
> Nathan Pearson wrote:
>
> Thanks for this Luke.  You've done a better job of describing what I had in
> mind.  The Site Tool widget would enable the notion of "legacy Sakai" which
> is somewhat analogous to the BB model (create content / activities and then
> drop them into a page) vs. 3akai page authoring, which is somewhat analogous
> to the Moodle model (create a page and generate content / activities
> inline).
>
> It's entirely possible for both models to exist at the same time in the same
> site.
>
>
> On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez <[hidden email]>
> wrote:
>>
>> Advanced apologies: The following are some visceral reactions.  They
>> aren't informed by expertise in design so much as by a mindset that
>> has been molded by teaching in BB Vista and Moodle.
>>
>> The approach Sean describes is more or less the approach that BB Vista
>> (e.g. WebCT) instructors are funneled into by default: The user
>> creates activities (e.g. discussions, quizes etc.) or content (e.g.
>> files or links to Web pages) and after having created some of these
>> activities or content the instructor can arrange them into learning
>> sequences.
>>
>> In contrast, the typical Moodle configuration more or less reverses
>> this approach:  The overall learning sequence of the site have been
>> predefined.  The instructor is presented with the predefined sequence
>> and then they author/drop-in the content or activities of their
>> choosing into this sequence.
>>
>> To say this in terms that don't refer to any product category: One
>> authoring approach encourages instructors to author content and
>> activities in a context that is abstracted from a sequence and then to
>> create this learning sequence afterward.  The other authoring approach
>> presents a predefined sequence and then prompts the instructor to
>> author content/activities within the context of this sequence.
>>
>> In our own discussion with faculty at Weber we've seen merits in both
>> approaches.
>>
>> Luke
>>
>> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]> wrote:
>> > That idea hits home. If I were designing a website (maybe for
>> > collaborative
>> > editing/brainstorming with a group), then organizing the space may into
>> > pages make a lot of sense.
>> >
>> > If I am trying get my course syllabus up and running in Sakai, it might
>> > not.
>> > Maybe a competing (rather traditional) train of thought would be.
>> >
>> > First designing the activities.
>> > Organizing and relating the activities to each other (by chronology,
>> > topic,
>> > type, etc).
>> >
>> > Sean
>> >
>> >
>> >
>> > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
>> > <[hidden email]> wrote:
>> >>
>> >> I'm afraid that I don't have a better idea. I'm just suggesting that
>> >> there
>> >> should be some user testing of the notion that faculty will be
>> >> comfortable
>> >> thinking about configuring their learning environment as:
>> >>
>> >> First creating new pages
>> >> Then putting functionality on those pages
>> >>
>> >> Does the blank slate work for them? Even with templates, the current
>> >> design suggests that faculty (particularly ones who are new to 3akai)
>> >> will
>> >> have to intuit that, in order to add a discussion board (for example),
>> >> they
>> >> must first create a new page. It may be that this is not a big deal for
>> >> faculty to get. But my experience with the execution of a somewhat
>> >> similar
>> >> model in WebCT was bad enough to make me worry.
>> >>
>> >> - m
>> >>
>> >>
>> >> Nathan Pearson wrote:
>> >>
>> >> I'm not sure I understand the feedback.  What do you have in mind as a
>> >> better way to do it?
>> >>
>> >>
>> >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
>> >> <[hidden email]> wrote:
>> >>>
>> >>> Hmm.
>> >>>
>> >>> I just was helping my wife wrestle with Blackboard CE8 today, and this
>> >>> is
>> >>> mock-up is suddenly feeling a little familiar. And not in a good way.
>> >>> My
>> >>> sense is that WebCT started off with the same idea that people should
>> >>> just
>> >>> be able to assemble pages and put anything they want on them. The
>> >>> execution
>> >>> was particularly clunky, probably in part because of the technology
>> >>> base
>> >>> they were dealing with at the time they designed the system. But
>> >>> beyond
>> >>> that, I'm not sure that the typical faculty member thinks of putting
>> >>> together their course in terms of assembling pages first and then
>> >>> putting
>> >>> functionality on the pages. Maybe it's possible to execute the concept
>> >>> in a
>> >>> way that makes it more intuitive than it is in CE (in fact, I'm sure
>> >>> of it),
>> >>> but I just don't know if "Create a New Page" carries the semantic
>> >>> freight
>> >>> necessary.
>> >>>
>> >>> - m
>> >>>
>> >>>
>> >>> Nathan Pearson wrote:
>> >>>
>> >>> I think it will come down to the affordance of where the option is
>> >>> displayed on the screen, the context, and the terminology.  This is
>> >>> what I
>> >>> had in mind based on Clay's comments:
>> >>>
>> >>>
>> >>>
>> >>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>> >>>
>> >>> It still forces the user to make a choice, but the imposition isn't
>> >>> significant and can easily be ignored.  If we push the idea too far
>> >>> out of
>> >>> one's reach or periphery, then we risk making it too inefficient to
>> >>> get at.
>> >>>
>> >>> Nathan
>> >>>
>> >>>
>> >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
>> >>> <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> To add to the comparison with confluence, (being bad here with self
>> >>>> referential design but I think it applies more broadly) I know the
>> >>>> subtle
>> >>>> "template" link is there but I ignore it because I'm almost always in
>> >>>> a
>> >>>> hurry when I create a page in confluence and "template" doesn't hold
>> >>>> any
>> >>>> value for me.  If I knew there were templates that would make my work
>> >>>> easier
>> >>>> perhaps I would use it.   So I think it's more than just making sure
>> >>>> users
>> >>>> see that there are templates  When we ask them if they want to use a
>> >>>> template, I think we should also allow them to discover the kinds of
>> >>>> templates there are and they can help me in my work.  Some users will
>> >>>> be
>> >>>> curious and play around with options such as templates but what we
>> >>>> find
>> >>>> often in user research is that users are very busy and will go the
>> >>>> most
>> >>>> direct route they can.  I guess what I'm contemplating is, "Is the
>> >>>> word
>> >>>> template enough information scent to allow users to know why they
>> >>>> should
>> >>>> choose it?"
>> >>>> -Daphne
>> >>>>
>> >>>>
>> >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>> >>>>
>> >>>> You're probably right.  There's still the issue of applying a page
>> >>>> template -- which should come before the edit page view.  Confluence
>> >>>> does it
>> >>>> in a bit of a quirky way IMO where they drop you into the edit view,
>> >>>> and if
>> >>>> you happen to see the subtle link to invoke a template, you can take
>> >>>> a step
>> >>>> back to take two forward in applying a template.  I find this pattern
>> >>>> to be
>> >>>> a bit clumsy.
>> >>>>
>> >>>> Maybe the way to get the best of both worlds is to use a drop down
>> >>>> when
>> >>>> clicking the Create New Page button that presents the options: Blank
>> >>>> Page or
>> >>>> From Template.
>> >>>>
>> >>>> Nathan
>> >>>>
>> >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
>> >>>> <[hidden email]> wrote:
>> >>>>>
>> >>>>> Sorry I couldn't make today's discussion, and particularly sorry
>> >>>>> since
>> >>>>> I'm going to indulge a bit of grousing about the create page bits,
>> >>>>> but
>> >>>>> I trust my stammering about the point yesterday may have prepared
>> >>>>> you
>> >>>>> for this line of attack, and that you understand the appreciative
>> >>>>> place it comes from ... so I can let my hair down. I'm going to put
>> >>>>> myself into the mind of an imagined, petulant user just to make a
>> >>>>> point.
>> >>>>>
>> >>>>> My gut instinct for the page creation suggested here is that there
>> >>>>> is
>> >>>>> too much complexity. Too many new words and ideas, too many
>> >>>>> possibilities on the screen, too many pictures, etc. Yes, it's done
>> >>>>> in the guise of helping people make good decisions at the outset,
>> >>>>> but
>> >>>>> I think it risks bewilderment by being overhelpful at the wrong
>> >>>>> time,
>> >>>>> and emphasizing the wrong things.
>> >>>>>
>> >>>>> There is a really simple concept at the core of the new page
>> >>>>> authoring
>> >>>>> metaphor which seems to me both powerful and elegant. You have a
>> >>>>> page, and you can start typing and/or drop things into the page that
>> >>>>> might be small (like a single assignment) or large (like a table of
>> >>>>> all assignments). But we bring little advantage to this simple
>> >>>>> concept by trying to define new kinds of pages or laying out the
>> >>>>> full
>> >>>>> spread of tools during the process of page creation.
>> >>>>>
>> >>>>> By the same token, we're not helping people by presenting the
>> >>>>> default
>> >>>>> option as a "blank page." Of *course* I don't want a blank page: I'm
>> >>>>> not going to choose that. I want a page that will have stuff in it.
>> >>>>> But rather than present me with a simple emphasis on how to quickly
>> >>>>> start authoring a page you appear to be putting your effort into
>> >>>>> front-loading my decision-making with a "page type," which
>> >>>>> instinctively strikes me as an odd notion: unnecessary and
>> >>>>> unhelpful.
>> >>>>>
>> >>>>> It's not about the *page*. It's about what goes *in* the page. I'm
>> >>>>> trying to create my content and you keep trying to get me to look at
>> >>>>> the margins or declare my full intent ahead of time.
>> >>>>>
>> >>>>> In other words I think the design simply has the wrong focus at this
>> >>>>> stage. What if we instead focused design energies on making the
>> >>>>> editing easy and flexible, and left the mere creation of the page
>> >>>>> virtually transparent? What if, instead of some dialogue asking
>> >>>>> about
>> >>>>> what kind of page this will be, when I click on "create a new page"
>> >>>>> I'm immediately there, or I'm immediately at a place that asks, "OK,
>> >>>>> ta-da, you have your page: now what are you going to put in it?"
>> >>>>> (e.g.
>> >>>>> with an interface that immediately leads me into either typing or
>> >>>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>> >>>>> what I'm going to put in it by leading with *that* kind of choice
>> >>>>> instead.
>> >>>>>
>> >>>>> Stepping back for a moment from my frothy remarks (which, again, I
>> >>>>> mean a bit playfully, but to make a point): I don't mean to insist
>> >>>>> that I really know what people want, but I do mean to suggest that I
>> >>>>> think this really needs testing.
>> >>>>>
>> >>>>> ~Clay
>> >>>>>
>> >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
>> >>>>> <[hidden email]>
>> >>>>> wrote:
>> >>>>> > Today's UX working session reviewed a few tweaks to the header
>> >>>>> > area
>> >>>>> > of the
>> >>>>> > site screen, plus a review of the "create page" screen. Both can
>> >>>>> > be
>> >>>>> > found
>> >>>>> > here:
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>> >>>>> >
>> >>>>> >
>> >>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>> >>>>> >
>> >>>>> > We also dove into the meatier topic of widgets/entities, which
>> >>>>> > we've
>> >>>>> > begun
>> >>>>> > calling vignettes (sorry to introduce more terminology, but we're
>> >>>>> > hoping
>> >>>>> > this will be better choice of words in the long run).
>> >>>>> >
>> >>>>> > As we see it, there are two major interaction themes within Sakai
>> >>>>> > sites.
>> >>>>> > The first consists of pages that contain a smattering of content
>> >>>>> > types;
>> >>>>> > ranging from text to functional bits called vignettes. The second
>> >>>>> > consists
>> >>>>> > of something called aggregate views (more on this later).
>> >>>>> >
>> >>>>> > To illustrate the vignette idea a bit more clearly, we discussed
>> >>>>> > the
>> >>>>> > following story:
>> >>>>> >
>> >>>>> > An instructor creates a page titled "week 1" and in that pages
>> >>>>> > provides a
>> >>>>> > short summary and informs students to read chapters 3 & 4. Below
>> >>>>> > this
>> >>>>> > block
>> >>>>> > of text, she inserts a discussion vignette and adds a brief header
>> >>>>> > to
>> >>>>> > it
>> >>>>> > that reads "When you're done with chapter 3, discuss the following
>> >>>>> > concept:
>> >>>>> > xyz". The instructor then adds more text related to chapter 4,
>> >>>>> > then
>> >>>>> > addes a
>> >>>>> > series of multiple choice questions -- which appear by inserting
>> >>>>> > survey
>> >>>>> > vignettes. Below these questions, she continues to add more text
>> >>>>> > that
>> >>>>> > tells
>> >>>>> > her students to prepare a 5 page write-up on both chapters and
>> >>>>> > submit
>> >>>>> > it in
>> >>>>> > the bottom of the page, or into the drop box vignette.
>> >>>>> >
>> >>>>> > A vignette would have a user-facing view as well as an edit/admin
>> >>>>> > view. The
>> >>>>> > latter would likely be presented during the edit page mode and the
>> >>>>> > former
>> >>>>> > during the view page mode. However there may be some carry over
>> >>>>> > from
>> >>>>> > one to
>> >>>>> > the other, as in the case of a preview option while in the edit
>> >>>>> > mode.
>> >>>>> >
>> >>>>> > As for aggregate views, they can be thought of as a central place
>> >>>>> > that
>> >>>>> > consolidates a collection of all the vignettes that happen to be
>> >>>>> > peppered
>> >>>>> > through a site. Another way to think of it, which may or may not
>> >>>>> > be
>> >>>>> > helpful, is as a conventional tool view. To illustrate, one might
>> >>>>> > imagine
>> >>>>> > the following story:
>> >>>>> >
>> >>>>> > Before the start of a semester, the instructor has composed a
>> >>>>> > bunch
>> >>>>> > of pages
>> >>>>> > to teach his hybrid class. Several of those pages include one or
>> >>>>> > more
>> >>>>> > discussion vignettes. As the semester gets under way, students
>> >>>>> > begin
>> >>>>> > posting replies across a variety of pages, resulting in
>> >>>>> > simultaneous
>> >>>>> > threaded discussion sprouting up throughout the site. Rather than
>> >>>>> > sifting
>> >>>>> > through all the pages in the site in order to keep up, the
>> >>>>> > instructor
>> >>>>> > simply
>> >>>>> > goes to the aggregate discussion view where he is presented with a
>> >>>>> > UI
>> >>>>> > that
>> >>>>> > is similar to a traditional discussion forum; with the exception
>> >>>>> > that
>> >>>>> > the
>> >>>>> > discussion topics and threads consist of the same stuff found in
>> >>>>> > the
>> >>>>> > vignettes that are scattered throughout the site.
>> >>>>> >
>> >>>>> > A few interesting points about this aggregate page view: Similar
>> >>>>> > to
>> >>>>> > the
>> >>>>> > vignettes, this view would have a user-facing side and an admin
>> >>>>> > control
>> >>>>> > panel of some sort. Also, the aggregate view may be available only
>> >>>>> > to
>> >>>>> > the
>> >>>>> > site maintainer (or instructor in the above story) or to everyone
>> >>>>> > (including
>> >>>>> > his students). If the latter is true, than in theory, a student
>> >>>>> > can
>> >>>>> > engage
>> >>>>> > a particular discussion either inline on a page where a vignette
>> >>>>> > is
>> >>>>> > presented, or by going into the aggregate "discussion forum" view.
>> >>>>> >
>> >>>>> > Another side note to all of this is that when a new discussion
>> >>>>> > vignette is
>> >>>>> > added to a page, it is then automatically pushed to the aggregate
>> >>>>> > view and
>> >>>>> > collected there. However, if a discussion post is added while in
>> >>>>> > the
>> >>>>> > aggregate view, it is NOT automatically pushed to some site page.
>> >>>>> > This
>> >>>>> > implies that the aggregate view can contain more discussion posts
>> >>>>> > than might
>> >>>>> > appear in the regular site pages. However, probably any such post
>> >>>>> > in
>> >>>>> > the
>> >>>>> > aggregate view can be pulled into a page while the page is being
>> >>>>> > composed.
>> >>>>> >
>> >>>>> > We then briefly discussed the UX question of "how might a user
>> >>>>> > locate
>> >>>>> > one of
>> >>>>> > these aggregate views"? We touched on a few ideas, but nothing
>> >>>>> > worth
>> >>>>> > mentioning until we put a bit more thought into them.
>> >>>>> >
>> >>>>> > Also, we focused on "threaded discussion" functionality to keep
>> >>>>> > the
>> >>>>> > model
>> >>>>> > manageable for now. None of this has been tested on other
>> >>>>> > functional
>> >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all
>> >>>>> > of
>> >>>>> > this
>> >>>>> > will hold water once we get there.
>> >>>>> >
>> >>>>> > Cheers,
>> >>>>> > Nathan
>> >>>>> >
>> >>>>> > --
>> >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>> >>>>> >
>> >>>>> > E. [hidden email]
>> >>>>> > M. 602.418.5092
>> >>>>> > Y. npearson99 (Yahoo)
>> >>>>> > S. npearson99 (Skype)
>> >>>>> >
>> >>>>> >
>> >>>>> >
>> >>>>> > http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>>>> >
>> >>>>> > ________________________________
>> >>>>> > This automatic notification message was sent by Sakai Collab
>> >>>>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring
>> >>>>> > site.
>> >>>>> > You can modify how you receive notifications at My Workspace >
>> >>>>> > Preferences.
>> >>>>> >
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Clay Fenlason
>> >>>>> Director, Educational Technology
>> >>>>> Georgia Institute of Technology
>> >>>>> (404) 385-6644
>> >>>>> ________________________________
>> >>>>> This automatic notification message was sent by Sakai Collab
>> >>>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
>> >>>>> site.
>> >>>>> You can modify how you receive notifications at My Workspace >
>> >>>>> Preferences.
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Nathan Pearson | UX Lead | Sakai Foundation
>> >>>>
>> >>>> E. [hidden email]
>> >>>> M. 602.418.5092
>> >>>> Y npearson99 (Yahoo)
>> >>>> S. npearson99 (Skype)
>> >>>>
>> >>>>
>> >>>>
>> >>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>>>
>> >>>> ________________________________
>> >>>> This automatic notification message was sent by Sakai Collab
>> >>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
>> >>>> site.
>> >>>> You can modify how you receive notifications at My Workspace >
>> >>>> Preferences.
>> >>>>
>> >>>> Daphne Ogle
>> >>>> Senior Interaction Designer
>> >>>> University of California, Berkeley
>> >>>> Educational Technology Services
>> >>>> [hidden email]
>> >>>> cell (510)847-0308
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Nathan Pearson | UX Lead | Sakai Foundation
>> >>>
>> >>> E. [hidden email]
>> >>> M. 602.418.5092
>> >>> Y. npearson99 (Yahoo)
>> >>> S. npearson99 (Skype)
>> >>>
>> >>>
>> >>>
>> >>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>>
>> >>> ________________________________
>> >>> This automatic notification message was sent by Sakai Collab
>> >>> (https://collab.sakaiproject.org//portal) from the DG: User Experience
>> >>> site.
>> >>> You can modify how you receive notifications at My Workspace >
>> >>> Preferences.
>> >>>
>> >>> --
>> >>>
>> >>>
>> >>>
>> >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> >>> Oracle Academic Enterprise Solutions Group
>> >>> 23A Glendale Road, Glendale, MA 01229
>> >>
>> >>
>> >> --
>> >> Nathan Pearson | UX Lead | Sakai Foundation
>> >>
>> >> E. [hidden email]
>> >> M. 602.418.5092
>> >> Y. npearson99 (Yahoo)
>> >> S. npearson99 (Skype)
>> >>
>> >>
>> >>
>> >> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>
>> >> --
>> >>
>> >>
>> >>
>> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> >> Oracle Academic Enterprise Solutions Group
>> >> 23A Glendale Road, Glendale, MA 01229
>> >>
>> >> [see attachment: "unknown", size: 658 bytes]
>> >>
>> >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>> >>
>> >> Attachments:
>> >>
>> >> unknown
>> >>
>> >> oracle_sig_logo.gif
>> >>
>> >> ________________________________
>> >> This automatic notification message was sent by Sakai Collab
>> >> (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>> >> You can modify how you receive notifications at My Workspace >
>> >> Preferences.
>> >
>> >
>> >
>> > --
>> > Sean Keesler
>> > 130 Academy Street
>> > Manlius, NY 13104
>> > 315-663-7756
>> >
>> > ________________________________
>> > This automatic notification message was sent by Sakai Collab
>> > (https://collab.sakaiproject.org//portal) from the DG: User Experience
>> > site.
>> > You can modify how you receive notifications at My Workspace >
>> > Preferences.
>> >
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> --
>
>
>
> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229



--
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Korcuska Michael Korcuska
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


This is also touched on in the previous content authoring template &
structure requirements:

http://docs.google.com/View?docid=ddx8d6kd_14hkxrgsgm&pageview=1&hgd=1&hl=en

My personal view of "the right way" to do much of this is with a page
authoring capability that has explicit sections defined. A "section"
is a part of a page that has rules defining what kind of content it
can contain and can have default content. Sections could be added or
removed.  To make Moodle's "Weekly Course Format" you would define a
template with a section for each week of the term. For the "topic
format" a template with several generic sections (topic 1, topic 2)
that the user can customize and add to.

There are some mockups that might make this clearer:

http://confluence.sakaiproject.org/confluence/download/attachments/18186442/MJK+Authoring+2.pdf?version=1

And I can see this being handled with a site template as well,
although the particular use case feels to me like a page template.
Michael

>>
>> The Moodle example is an instructive one, and I think it's important not
>> to
>> miss the details. To begin with, when a user creates a new course site in
>> Moodle, she is prompted to choose a site format.
>>

On Mon, Jan 19, 2009 at 4:56 PM, Clay Fenlason
<[hidden email]> wrote:

> I think these ideas are touched upon not in the sidebar of recent
> design thinking, but rather in the "site template." See the
> (unfortunately narrow) discussion here, especially in the comments:
>
> http://confluence.sakaiproject.org/confluence/x/iATWAg
>
> The basic pattern would be "anything goes" for raw capability, with
> templates (chosen during creation, I'm not sure if they could be
> switched after) for scaffolding.
>
> ~Clay
>
> On Mon, Jan 19, 2009 at 10:31 AM, Michael Feldstein
> <[hidden email]> wrote:
>> Sorry, I got a bit behind on this thread.
>>
>> The Moodle example is an instructive one, and I think it's important not
>> to
>> miss the details. To begin with, when a user creates a new course site in
>> Moodle, she is prompted to choose a site format.
>>
>>
>>
>> Moodle's lovely embedded help feature describes the "Format" options as
>> follows:
>>
>> Moodle course formats
>>
>> LAMS course format
>>
>> This format makes the Learning Activity Management System (LAMS) interface
>> central to the course. LAMS requires setting up by an administrator in
>> order
>> to use this format.
>>
>> SCORM format
>>
>> This format displays a SCORM package in the first section of the course
>> home
>> page. (The SCORM/AICC module provides an alternative method of displaying
>> a
>> SCORM package in a course.)
>>
>> Social format
>>
>> This format is oriented around one main forum, the Social forum, which
>> appears on the course home page. It is useful for situations that are more
>> freeform. They may not even be courses. For example, it could be used as a
>> departmental notice board.
>>
>> Topics format
>>
>> The course is organised into topic sections. Each topic section consists
>> of
>> activities.
>>
>> Weekly format
>>
>> The course is organised week by week, with a clear start date and a finish
>> date. Each week consists of activities.
>>
>> Weekly format - CSS/No tables
>>
>> The course is organised week by week without using tables for layout.
>>
>> When Luke talks about the overall learning sequence of the site being
>> defined, that entails at least two things, both of which flow from that
>> initial site format choice. First, there is a home page for the site that
>> has boxes which essentially outline the course structure.
>>
>>
>>
>> Second, all content and activities are created and implicitly sequenced
>> within the context of that structure.
>>
>>
>>
>> So, if I'm understanding the current proposal for the 3akai sidebar
>> correctly, then Moodle still provides considerably more scaffolding to the
>> faculty. I like the idea of having an "anything goes" course site format,
>> but I also think that Moodle's more structured options are also good
>> models
>> that are worth emulating.
>>
>> - m
>>
>>
>> Nathan Pearson wrote:
>>
>> Thanks for this Luke. You've done a better job of describing what I had in
>> mind. The Site Tool widget would enable the notion of "legacy Sakai" which
>> is somewhat analogous to the BB model (create content / activities and
>> then
>> drop them into a page) vs. 3akai page authoring, which is somewhat
>> analogous
>> to the Moodle model (create a page and generate content / activities
>> inline).
>>
>> It's entirely possible for both models to exist at the same time in the
>> same
>> site.
>>
>>
>> On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez
>> <[hidden email]>
>> wrote:
>>>
>>> Advanced apologies: The following are some visceral reactions. They
>>> aren't informed by expertise in design so much as by a mindset that
>>> has been molded by teaching in BB Vista and Moodle.
>>>
>>> The approach Sean describes is more or less the approach that BB Vista
>>> (e.g. WebCT) instructors are funneled into by default: The user
>>> creates activities (e.g. discussions, quizes etc.) or content (e.g.
>>> files or links to Web pages) and after having created some of these
>>> activities or content the instructor can arrange them into learning
>>> sequences.
>>>
>>> In contrast, the typical Moodle configuration more or less reverses
>>> this approach: The overall learning sequence of the site have been
>>> predefined. The instructor is presented with the predefined sequence
>>> and then they author/drop-in the content or activities of their
>>> choosing into this sequence.
>>>
>>> To say this in terms that don't refer to any product category: One
>>> authoring approach encourages instructors to author content and
>>> activities in a context that is abstracted from a sequence and then to
>>> create this learning sequence afterward. The other authoring approach
>>> presents a predefined sequence and then prompts the instructor to
>>> author content/activities within the context of this sequence.
>>>
>>> In our own discussion with faculty at Weber we've seen merits in both
>>> approaches.
>>>
>>> Luke
>>>
>>> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]> wrote:
>>> > That idea hits home. If I were designing a website (maybe for
>>> > collaborative
>>> > editing/brainstorming with a group), then organizing the space may into
>>> > pages make a lot of sense.
>>> >
>>> > If I am trying get my course syllabus up and running in Sakai, it might
>>> > not.
>>> > Maybe a competing (rather traditional) train of thought would be.
>>> >
>>> > First designing the activities.
>>> > Organizing and relating the activities to each other (by chronology,
>>> > topic,
>>> > type, etc).
>>> >
>>> > Sean
>>> >
>>> >
>>> >
>>> > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
>>> > <[hidden email]> wrote:
>>> >>
>>> >> I'm afraid that I don't have a better idea. I'm just suggesting that
>>> >> there
>>> >> should be some user testing of the notion that faculty will be
>>> >> comfortable
>>> >> thinking about configuring their learning environment as:
>>> >>
>>> >> First creating new pages
>>> >> Then putting functionality on those pages
>>> >>
>>> >> Does the blank slate work for them? Even with templates, the current
>>> >> design suggests that faculty (particularly ones who are new to 3akai)
>>> >> will
>>> >> have to intuit that, in order to add a discussion board (for example),
>>> >> they
>>> >> must first create a new page. It may be that this is not a big deal
>>> >> for
>>> >> faculty to get. But my experience with the execution of a somewhat
>>> >> similar
>>> >> model in WebCT was bad enough to make me worry.
>>> >>
>>> >> - m
>>> >>
>>> >>
>>> >> Nathan Pearson wrote:
>>> >>
>>> >> I'm not sure I understand the feedback. What do you have in mind as a
>>> >> better way to do it?
>>> >>
>>> >>
>>> >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
>>> >> <[hidden email]> wrote:
>>> >>>
>>> >>> Hmm.
>>> >>>
>>> >>> I just was helping my wife wrestle with Blackboard CE8 today, and
>>> >>> this
>>> >>> is
>>> >>> mock-up is suddenly feeling a little familiar. And not in a good way.
>>> >>> My
>>> >>> sense is that WebCT started off with the same idea that people should
>>> >>> just
>>> >>> be able to assemble pages and put anything they want on them. The
>>> >>> execution
>>> >>> was particularly clunky, probably in part because of the technology
>>> >>> base
>>> >>> they were dealing with at the time they designed the system. But
>>> >>> beyond
>>> >>> that, I'm not sure that the typical faculty member thinks of putting
>>> >>> together their course in terms of assembling pages first and then
>>> >>> putting
>>> >>> functionality on the pages. Maybe it's possible to execute the
>>> >>> concept
>>> >>> in a
>>> >>> way that makes it more intuitive than it is in CE (in fact, I'm sure
>>> >>> of it),
>>> >>> but I just don't know if "Create a New Page" carries the semantic
>>> >>> freight
>>> >>> necessary.
>>> >>>
>>> >>> - m
>>> >>>
>>> >>>
>>> >>> Nathan Pearson wrote:
>>> >>>
>>> >>> I think it will come down to the affordance of where the option is
>>> >>> displayed on the screen, the context, and the terminology. This is
>>> >>> what I
>>> >>> had in mind based on Clay's comments:
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>>> >>>
>>> >>> It still forces the user to make a choice, but the imposition isn't
>>> >>> significant and can easily be ignored. If we push the idea too far
>>> >>> out of
>>> >>> one's reach or periphery, then we risk making it too inefficient to
>>> >>> get at.
>>> >>>
>>> >>> Nathan
>>> >>>
>>> >>>
>>> >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
>>> >>> <[hidden email]>
>>> >>> wrote:
>>> >>>>
>>> >>>> To add to the comparison with confluence, (being bad here with self
>>> >>>> referential design but I think it applies more broadly) I know the
>>> >>>> subtle
>>> >>>> "template" link is there but I ignore it because I'm almost always
>>> >>>> in
>>> >>>> a
>>> >>>> hurry when I create a page in confluence and "template" doesn't hold
>>> >>>> any
>>> >>>> value for me. If I knew there were templates that would make my work
>>> >>>> easier
>>> >>>> perhaps I would use it. So I think it's more than just making sure
>>> >>>> users
>>> >>>> see that there are templates When we ask them if they want to use a
>>> >>>> template, I think we should also allow them to discover the kinds of
>>> >>>> templates there are and they can help me in my work. Some users will
>>> >>>> be
>>> >>>> curious and play around with options such as templates but what we
>>> >>>> find
>>> >>>> often in user research is that users are very busy and will go the
>>> >>>> most
>>> >>>> direct route they can. I guess what I'm contemplating is, "Is the
>>> >>>> word
>>> >>>> template enough information scent to allow users to know why they
>>> >>>> should
>>> >>>> choose it?"
>>> >>>> -Daphne
>>> >>>>
>>> >>>>
>>> >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>>> >>>>
>>> >>>> You're probably right. There's still the issue of applying a page
>>> >>>> template -- which should come before the edit page view. Confluence
>>> >>>> does it
>>> >>>> in a bit of a quirky way IMO where they drop you into the edit view,
>>> >>>> and if
>>> >>>> you happen to see the subtle link to invoke a template, you can take
>>> >>>> a step
>>> >>>> back to take two forward in applying a template. I find this pattern
>>> >>>> to be
>>> >>>> a bit clumsy.
>>> >>>>
>>> >>>> Maybe the way to get the best of both worlds is to use a drop down
>>> >>>> when
>>> >>>> clicking the Create New Page button that presents the options: Blank
>>> >>>> Page or
>>> >>>> From Template.
>>> >>>>
>>> >>>> Nathan
>>> >>>>
>>> >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
>>> >>>> <[hidden email]> wrote:
>>> >>>>>
>>> >>>>> Sorry I couldn't make today's discussion, and particularly sorry
>>> >>>>> since
>>> >>>>> I'm going to indulge a bit of grousing about the create page bits,
>>> >>>>> but
>>> >>>>> I trust my stammering about the point yesterday may have prepared
>>> >>>>> you
>>> >>>>> for this line of attack, and that you understand the appreciative
>>> >>>>> place it comes from ... so I can let my hair down. I'm going to put
>>> >>>>> myself into the mind of an imagined, petulant user just to make a
>>> >>>>> point.
>>> >>>>>
>>> >>>>> My gut instinct for the page creation suggested here is that there
>>> >>>>> is
>>> >>>>> too much complexity. Too many new words and ideas, too many
>>> >>>>> possibilities on the screen, too many pictures, etc. Yes, it's done
>>> >>>>> in the guise of helping people make good decisions at the outset,
>>> >>>>> but
>>> >>>>> I think it risks bewilderment by being overhelpful at the wrong
>>> >>>>> time,
>>> >>>>> and emphasizing the wrong things.
>>> >>>>>
>>> >>>>> There is a really simple concept at the core of the new page
>>> >>>>> authoring
>>> >>>>> metaphor which seems to me both powerful and elegant. You have a
>>> >>>>> page, and you can start typing and/or drop things into the page
>>> >>>>> that
>>> >>>>> might be small (like a single assignment) or large (like a table of
>>> >>>>> all assignments). But we bring little advantage to this simple
>>> >>>>> concept by trying to define new kinds of pages or laying out the
>>> >>>>> full
>>> >>>>> spread of tools during the process of page creation.
>>> >>>>>
>>> >>>>> By the same token, we're not helping people by presenting the
>>> >>>>> default
>>> >>>>> option as a "blank page." Of *course* I don't want a blank page:
>>> >>>>> I'm
>>> >>>>> not going to choose that. I want a page that will have stuff in it.
>>> >>>>> But rather than present me with a simple emphasis on how to quickly
>>> >>>>> start authoring a page you appear to be putting your effort into
>>> >>>>> front-loading my decision-making with a "page type," which
>>> >>>>> instinctively strikes me as an odd notion: unnecessary and
>>> >>>>> unhelpful.
>>> >>>>>
>>> >>>>> It's not about the *page*. It's about what goes *in* the page. I'm
>>> >>>>> trying to create my content and you keep trying to get me to look
>>> >>>>> at
>>> >>>>> the margins or declare my full intent ahead of time.
>>> >>>>>
>>> >>>>> In other words I think the design simply has the wrong focus at
>>> >>>>> this
>>> >>>>> stage. What if we instead focused design energies on making the
>>> >>>>> editing easy and flexible, and left the mere creation of the page
>>> >>>>> virtually transparent? What if, instead of some dialogue asking
>>> >>>>> about
>>> >>>>> what kind of page this will be, when I click on "create a new page"
>>> >>>>> I'm immediately there, or I'm immediately at a place that asks,
>>> >>>>> "OK,
>>> >>>>> ta-da, you have your page: now what are you going to put in it?"
>>> >>>>> (e.g.
>>> >>>>> with an interface that immediately leads me into either typing or
>>> >>>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>>> >>>>> what I'm going to put in it by leading with *that* kind of choice
>>> >>>>> instead.
>>> >>>>>
>>> >>>>> Stepping back for a moment from my frothy remarks (which, again, I
>>> >>>>> mean a bit playfully, but to make a point): I don't mean to insist
>>> >>>>> that I really know what people want, but I do mean to suggest that
>>> >>>>> I
>>> >>>>> think this really needs testing.
>>> >>>>>
>>> >>>>> ~Clay
>>> >>>>>
>>> >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
>>> >>>>> <[hidden email]>
>>> >>>>> wrote:
>>> >>>>> > Today's UX working session reviewed a few tweaks to the header
>>> >>>>> > area
>>> >>>>> > of the
>>> >>>>> > site screen, plus a review of the "create page" screen. Both can
>>> >>>>> > be
>>> >>>>> > found
>>> >>>>> > here:
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>> >>>>> >
>>> >>>>> > We also dove into the meatier topic of widgets/entities, which
>>> >>>>> > we've
>>> >>>>> > begun
>>> >>>>> > calling vignettes (sorry to introduce more terminology, but we're
>>> >>>>> > hoping
>>> >>>>> > this will be better choice of words in the long run).
>>> >>>>> >
>>> >>>>> > As we see it, there are two major interaction themes within Sakai
>>> >>>>> > sites.
>>> >>>>> > The first consists of pages that contain a smattering of content
>>> >>>>> > types;
>>> >>>>> > ranging from text to functional bits called vignettes. The second
>>> >>>>> > consists
>>> >>>>> > of something called aggregate views (more on this later).
>>> >>>>> >
>>> >>>>> > To illustrate the vignette idea a bit more clearly, we discussed
>>> >>>>> > the
>>> >>>>> > following story:
>>> >>>>> >
>>> >>>>> > An instructor creates a page titled "week 1" and in that pages
>>> >>>>> > provides a
>>> >>>>> > short summary and informs students to read chapters 3 & 4. Below
>>> >>>>> > this
>>> >>>>> > block
>>> >>>>> > of text, she inserts a discussion vignette and adds a brief
>>> >>>>> > header
>>> >>>>> > to
>>> >>>>> > it
>>> >>>>> > that reads "When you're done with chapter 3, discuss the
>>> >>>>> > following
>>> >>>>> > concept:
>>> >>>>> > xyz". The instructor then adds more text related to chapter 4,
>>> >>>>> > then
>>> >>>>> > addes a
>>> >>>>> > series of multiple choice questions -- which appear by inserting
>>> >>>>> > survey
>>> >>>>> > vignettes. Below these questions, she continues to add more text
>>> >>>>> > that
>>> >>>>> > tells
>>> >>>>> > her students to prepare a 5 page write-up on both chapters and
>>> >>>>> > submit
>>> >>>>> > it in
>>> >>>>> > the bottom of the page, or into the drop box vignette.
>>> >>>>> >
>>> >>>>> > A vignette would have a user-facing view as well as an edit/admin
>>> >>>>> > view. The
>>> >>>>> > latter would likely be presented during the edit page mode and
>>> >>>>> > the
>>> >>>>> > former
>>> >>>>> > during the view page mode. However there may be some carry over
>>> >>>>> > from
>>> >>>>> > one to
>>> >>>>> > the other, as in the case of a preview option while in the edit
>>> >>>>> > mode.
>>> >>>>> >
>>> >>>>> > As for aggregate views, they can be thought of as a central place
>>> >>>>> > that
>>> >>>>> > consolidates a collection of all the vignettes that happen to be
>>> >>>>> > peppered
>>> >>>>> > through a site. Another way to think of it, which may or may not
>>> >>>>> > be
>>> >>>>> > helpful, is as a conventional tool view. To illustrate, one might
>>> >>>>> > imagine
>>> >>>>> > the following story:
>>> >>>>> >
>>> >>>>> > Before the start of a semester, the instructor has composed a
>>> >>>>> > bunch
>>> >>>>> > of pages
>>> >>>>> > to teach his hybrid class. Several of those pages include one or
>>> >>>>> > more
>>> >>>>> > discussion vignettes. As the semester gets under way, students
>>> >>>>> > begin
>>> >>>>> > posting replies across a variety of pages, resulting in
>>> >>>>> > simultaneous
>>> >>>>> > threaded discussion sprouting up throughout the site. Rather than
>>> >>>>> > sifting
>>> >>>>> > through all the pages in the site in order to keep up, the
>>> >>>>> > instructor
>>> >>>>> > simply
>>> >>>>> > goes to the aggregate discussion view where he is presented with
>>> >>>>> > a
>>> >>>>> > UI
>>> >>>>> > that
>>> >>>>> > is similar to a traditional discussion forum; with the exception
>>> >>>>> > that
>>> >>>>> > the
>>> >>>>> > discussion topics and threads consist of the same stuff found in
>>> >>>>> > the
>>> >>>>> > vignettes that are scattered throughout the site.
>>> >>>>> >
>>> >>>>> > A few interesting points about this aggregate page view: Similar
>>> >>>>> > to
>>> >>>>> > the
>>> >>>>> > vignettes, this view would have a user-facing side and an admin
>>> >>>>> > control
>>> >>>>> > panel of some sort. Also, the aggregate view may be available
>>> >>>>> > only
>>> >>>>> > to
>>> >>>>> > the
>>> >>>>> > site maintainer (or instructor in the above story) or to everyone
>>> >>>>> > (including
>>> >>>>> > his students). If the latter is true, than in theory, a student
>>> >>>>> > can
>>> >>>>> > engage
>>> >>>>> > a particular discussion either inline on a page where a vignette
>>> >>>>> > is
>>> >>>>> > presented, or by going into the aggregate "discussion forum"
>>> >>>>> > view.
>>> >>>>> >
>>> >>>>> > Another side note to all of this is that when a new discussion
>>> >>>>> > vignette is
>>> >>>>> > added to a page, it is then automatically pushed to the aggregate
>>> >>>>> > view and
>>> >>>>> > collected there. However, if a discussion post is added while in
>>> >>>>> > the
>>> >>>>> > aggregate view, it is NOT automatically pushed to some site page.
>>> >>>>> > This
>>> >>>>> > implies that the aggregate view can contain more discussion posts
>>> >>>>> > than might
>>> >>>>> > appear in the regular site pages. However, probably any such post
>>> >>>>> > in
>>> >>>>> > the
>>> >>>>> > aggregate view can be pulled into a page while the page is being
>>> >>>>> > composed.
>>> >>>>> >
>>> >>>>> > We then briefly discussed the UX question of "how might a user
>>> >>>>> > locate
>>> >>>>> > one of
>>> >>>>> > these aggregate views"? We touched on a few ideas, but nothing
>>> >>>>> > worth
>>> >>>>> > mentioning until we put a bit more thought into them.
>>> >>>>> >
>>> >>>>> > Also, we focused on "threaded discussion" functionality to keep
>>> >>>>> > the
>>> >>>>> > model
>>> >>>>> > manageable for now. None of this has been tested on other
>>> >>>>> > functional
>>> >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if all
>>> >>>>> > of
>>> >>>>> > this
>>> >>>>> > will hold water once we get there.
>>> >>>>> >
>>> >>>>> > Cheers,
>>> >>>>> > Nathan
>>> >>>>> >
>>> >>>>> > --
>>> >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>>> >>>>> >
>>> >>>>> > E. [hidden email]
>>> >>>>> > M. 602.418.5092
>>> >>>>> > Y. npearson99 (Yahoo)
>>> >>>>> > S. npearson99 (Skype)
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> >
>>> >>>>> > http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>> >>>>> >
>>> >>>>> > ________________________________
>>> >>>>> > This automatic notification message was sent by Sakai Collab
>>> >>>>> > (https://collab.sakaiproject.org//portal) from the WG: Authoring
>>> >>>>> > site.
>>> >>>>> > You can modify how you receive notifications at My Workspace >
>>> >>>>> > Preferences.
>>> >>>>> >
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Clay Fenlason
>>> >>>>> Director, Educational Technology
>>> >>>>> Georgia Institute of Technology
>>> >>>>> (404) 385-6644
>>> >>>>> ________________________________
>>> >>>>> This automatic notification message was sent by Sakai Collab
>>> >>>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
>>> >>>>> site.
>>> >>>>> You can modify how you receive notifications at My Workspace >
>>> >>>>> Preferences.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Nathan Pearson | UX Lead | Sakai Foundation
>>> >>>>
>>> >>>> E. [hidden email]
>>> >>>> M. 602.418.5092
>>> >>>> Y npearson99 (Yahoo)
>>> >>>> S. npearson99 (Skype)
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>> >>>>
>>> >>>> ________________________________
>>> >>>> This automatic notification message was sent by Sakai Collab
>>> >>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
>>> >>>> site.
>>> >>>> You can modify how you receive notifications at My Workspace >
>>> >>>> Preferences.
>>> >>>>
>>> >>>> Daphne Ogle
>>> >>>> Senior Interaction Designer
>>> >>>> University of California, Berkeley
>>> >>>> Educational Technology Services
>>> >>>> [hidden email]
>>> >>>> cell (510)847-0308
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Nathan Pearson | UX Lead | Sakai Foundation
>>> >>>
>>> >>> E. [hidden email]
>>> >>> M. 602.418.5092
>>> >>> Y. npearson99 (Yahoo)
>>> >>> S. npearson99 (Skype)
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>> >>>
>>> >>> ________________________________
>>> >>> This automatic notification message was sent by Sakai Collab
>>> >>> (https://collab.sakaiproject.org//portal) from the DG: User
>>> >>> Experience
>>> >>> site.
>>> >>> You can modify how you receive notifications at My Workspace >
>>> >>> Preferences.
>>> >>>
>>> >>> --
>>> >>>
>>> >>>
>>> >>>
>>> >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>> >>> Oracle Academic Enterprise Solutions Group
>>> >>> 23A Glendale Road, Glendale, MA 01229
>>> >>
>>> >>
>>> >> --
>>> >> Nathan Pearson | UX Lead | Sakai Foundation
>>> >>
>>> >> E. [hidden email]
>>> >> M. 602.418.5092
>>> >> Y. npearson99 (Yahoo)
>>> >> S. npearson99 (Skype)
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>> >>
>>> >> --
>>> >>
>>> >>
>>> >>
>>> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>> >> Oracle Academic Enterprise Solutions Group
>>> >> 23A Glendale Road, Glendale, MA 01229
>>> >>
>>> >> [see attachment: "unknown", size: 658 bytes]
>>> >>
>>> >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>>> >>
>>> >> Attachments:
>>> >>
>>> >> unknown
>>> >>
>>> >> oracle_sig_logo.gif
>>> >>
>>> >> ________________________________
>>> >> This automatic notification message was sent by Sakai Collab
>>> >> (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
>>> >> You can modify how you receive notifications at My Workspace >
>>> >> Preferences.
>>> >
>>> >
>>> >
>>> > --
>>> > Sean Keesler
>>> > 130 Academy Street
>>> > Manlius, NY 13104
>>> > 315-663-7756
>>> >
>>> > ________________________________
>>> > This automatic notification message was sent by Sakai Collab
>>> > (https://collab.sakaiproject.org//portal) from the DG: User Experience
>>> > site.
>>> > You can modify how you receive notifications at My Workspace >
>>> > Preferences.
>>> >
>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. [hidden email]
>> M. 602.418.5092
>> Y. npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>
>> --
>>
>>
>>
>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> Oracle Academic Enterprise Solutions Group
>> 23A Glendale Road, Glendale, MA 01229
>
>
>
> --
> Clay Fenlason
> Director, Educational Technology
> Georgia Institute of Technology
> (404) 385-6644
> ________________________________
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace > Preferences.
>
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Feldstein Michael Feldstein
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update


Thanks, I'm beginning to see how the page and/or site template
approaches could provide the scaffolding. One of the nuances of the
Moodle design that's worth keeping in mind when refining these
affordances is that it doesn't really conform to either the
tools-in-site or page-authoring metaphors, exactly. The home page, whose
structure is decided by picking the Moodle site format (which could be
the same as picking a 3akai site or page template), can be thought of
almost as a visual lesson plan. It structures both the class experience
itself /and the course authoring experience/. So really, the first
question that teachers in Moodle ask themselves is, "What kind of course
structure do I want to have?" The site structure then becomes a scaffold
that mimics the course structure and lets the faculty member hang
content and activities off of that structure.

If you buy into that approach (and I do, personally), then you might
want to outline several different types of course structures, possibly
by interviewing some real teachers across a range of schools and
subjects. You do this not by looking at how they have structured their
courses in current Sakai implementations but how they actually /teach/
the courses. What is the rhythm of activities? Once you have that rhythm
abstracted into a set of pedagogical patterns, imagine how those
patterns could be instantiated in the flexible site design capabilities
we are talking about, and walk through what it would take to create and
use the necessary structures based on the 3akai template model. Would
the affordances be obvious to the teachers? How easy is it to accomplish
the set-up in a reasonably small number of clicks?

Many of the teachers who like Moodle like it because it seems to
anticipate what they want to do in their teaching. This is a good
example of how Moodle design achieves that design sense.

- m


Michael Korcuska wrote:

> This is also touched on in the previous content authoring template &
> structure requirements:
>
> http://docs.google.com/View?docid=ddx8d6kd_14hkxrgsgm&pageview=1&hgd=1&hl=en 
> <http://docs.google.com/View?docid=ddx8d6kd_14hkxrgsgm&pageview=1&hgd=1&hl=en>
>
>
> My personal view of "the right way" to do much of this is with a page
> authoring capability that has explicit sections defined. A "section"
> is a part of a page that has rules defining what kind of content it
> can contain and can have default content. Sections could be added or
> removed. To make Moodle's "Weekly Course Format" you would define a
> template with a section for each week of the term. For the "topic
> format" a template with several generic sections (topic 1, topic 2)
> that the user can customize and add to.
>
> There are some mockups that might make this clearer:
>
> http://confluence.sakaiproject.org/confluence/download/attachments/18186442/MJK+Authoring+2.pdf?version=1 
>
>
> And I can see this being handled with a site template as well,
> although the particular use case feels to me like a page template.
> Michael
>
> >>
> >> The Moodle example is an instructive one, and I think it's
> important not
> >> to
> >> miss the details. To begin with, when a user creates a new course
> site in
> >> Moodle, she is prompted to choose a site format.
> >>
>
> On Mon, Jan 19, 2009 at 4:56 PM, Clay Fenlason
> <[hidden email]> wrote:
> > I think these ideas are touched upon not in the sidebar of recent
> > design thinking, but rather in the "site template." See the
> > (unfortunately narrow) discussion here, especially in the comments:
> >
> > http://confluence.sakaiproject.org/confluence/x/iATWAg
> >
> > The basic pattern would be "anything goes" for raw capability, with
> > templates (chosen during creation, I'm not sure if they could be
> > switched after) for scaffolding.
> >
> > ~Clay
> >
> > On Mon, Jan 19, 2009 at 10:31 AM, Michael Feldstein
> > <[hidden email]> wrote:
> >> Sorry, I got a bit behind on this thread.
> >>
> >> The Moodle example is an instructive one, and I think it's
> important not
> >> to
> >> miss the details. To begin with, when a user creates a new course
> site in
> >> Moodle, she is prompted to choose a site format.
> >>
> >>
> >>
> >> Moodle's lovely embedded help feature describes the "Format"
> options as
> >> follows:
> >>
> >> Moodle course formats
> >>
> >> LAMS course format
> >>
> >> This format makes the Learning Activity Management System (LAMS)
> interface
> >> central to the course. LAMS requires setting up by an administrator in
> >> order
> >> to use this format.
> >>
> >> SCORM format
> >>
> >> This format displays a SCORM package in the first section of the
> course
> >> home
> >> page. (The SCORM/AICC module provides an alternative method of
> displaying
> >> a
> >> SCORM package in a course.)
> >>
> >> Social format
> >>
> >> This format is oriented around one main forum, the Social forum, which
> >> appears on the course home page. It is useful for situations that
> are more
> >> freeform. They may not even be courses. For example, it could be
> used as a
> >> departmental notice board.
> >>
> >> Topics format
> >>
> >> The course is organised into topic sections. Each topic section
> consists
> >> of
> >> activities.
> >>
> >> Weekly format
> >>
> >> The course is organised week by week, with a clear start date and a
> finish
> >> date. Each week consists of activities.
> >>
> >> Weekly format - CSS/No tables
> >>
> >> The course is organised week by week without using tables for layout.
> >>
> >> When Luke talks about the overall learning sequence of the site being
> >> defined, that entails at least two things, both of which flow from
> that
> >> initial site format choice. First, there is a home page for the
> site that
> >> has boxes which essentially outline the course structure.
> >>
> >>
> >>
> >> Second, all content and activities are created and implicitly
> sequenced
> >> within the context of that structure.
> >>
> >>
> >>
> >> So, if I'm understanding the current proposal for the 3akai sidebar
> >> correctly, then Moodle still provides considerably more scaffolding
> to the
> >> faculty. I like the idea of having an "anything goes" course site
> format,
> >> but I also think that Moodle's more structured options are also good
> >> models
> >> that are worth emulating.
> >>
> >> - m
> >>
> >>
> >> Nathan Pearson wrote:
> >>
> >> Thanks for this Luke. You've done a better job of describing what I
> had in
> >> mind. The Site Tool widget would enable the notion of "legacy
> Sakai" which
> >> is somewhat analogous to the BB model (create content / activities and
> >> then
> >> drop them into a page) vs. 3akai page authoring, which is somewhat
> >> analogous
> >> to the Moodle model (create a page and generate content / activities
> >> inline).
> >>
> >> It's entirely possible for both models to exist at the same time in
> the
> >> same
> >> site.
> >>
> >>
> >> On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez
> >> <[hidden email]>
> >> wrote:
> >>>
> >>> Advanced apologies: The following are some visceral reactions. They
> >>> aren't informed by expertise in design so much as by a mindset that
> >>> has been molded by teaching in BB Vista and Moodle.
> >>>
> >>> The approach Sean describes is more or less the approach that BB
> Vista
> >>> (e.g. WebCT) instructors are funneled into by default: The user
> >>> creates activities (e.g. discussions, quizes etc.) or content (e.g.
> >>> files or links to Web pages) and after having created some of these
> >>> activities or content the instructor can arrange them into learning
> >>> sequences.
> >>>
> >>> In contrast, the typical Moodle configuration more or less reverses
> >>> this approach: The overall learning sequence of the site have been
> >>> predefined. The instructor is presented with the predefined sequence
> >>> and then they author/drop-in the content or activities of their
> >>> choosing into this sequence.
> >>>
> >>> To say this in terms that don't refer to any product category: One
> >>> authoring approach encourages instructors to author content and
> >>> activities in a context that is abstracted from a sequence and
> then to
> >>> create this learning sequence afterward. The other authoring approach
> >>> presents a predefined sequence and then prompts the instructor to
> >>> author content/activities within the context of this sequence.
> >>>
> >>> In our own discussion with faculty at Weber we've seen merits in both
> >>> approaches.
> >>>
> >>> Luke
> >>>
> >>> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]>
> wrote:
> >>> > That idea hits home. If I were designing a website (maybe for
> >>> > collaborative
> >>> > editing/brainstorming with a group), then organizing the space
> may into
> >>> > pages make a lot of sense.
> >>> >
> >>> > If I am trying get my course syllabus up and running in Sakai,
> it might
> >>> > not.
> >>> > Maybe a competing (rather traditional) train of thought would be.
> >>> >
> >>> > First designing the activities.
> >>> > Organizing and relating the activities to each other (by
> chronology,
> >>> > topic,
> >>> > type, etc).
> >>> >
> >>> > Sean
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
> >>> > <[hidden email]> wrote:
> >>> >>
> >>> >> I'm afraid that I don't have a better idea. I'm just suggesting
> that
> >>> >> there
> >>> >> should be some user testing of the notion that faculty will be
> >>> >> comfortable
> >>> >> thinking about configuring their learning environment as:
> >>> >>
> >>> >> First creating new pages
> >>> >> Then putting functionality on those pages
> >>> >>
> >>> >> Does the blank slate work for them? Even with templates, the
> current
> >>> >> design suggests that faculty (particularly ones who are new to
> 3akai)
> >>> >> will
> >>> >> have to intuit that, in order to add a discussion board (for
> example),
> >>> >> they
> >>> >> must first create a new page. It may be that this is not a big
> deal
> >>> >> for
> >>> >> faculty to get. But my experience with the execution of a somewhat
> >>> >> similar
> >>> >> model in WebCT was bad enough to make me worry.
> >>> >>
> >>> >> - m
> >>> >>
> >>> >>
> >>> >> Nathan Pearson wrote:
> >>> >>
> >>> >> I'm not sure I understand the feedback. What do you have in
> mind as a
> >>> >> better way to do it?
> >>> >>
> >>> >>
> >>> >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
> >>> >> <[hidden email]> wrote:
> >>> >>>
> >>> >>> Hmm.
> >>> >>>
> >>> >>> I just was helping my wife wrestle with Blackboard CE8 today, and
> >>> >>> this
> >>> >>> is
> >>> >>> mock-up is suddenly feeling a little familiar. And not in a
> good way.
> >>> >>> My
> >>> >>> sense is that WebCT started off with the same idea that people
> should
> >>> >>> just
> >>> >>> be able to assemble pages and put anything they want on them. The
> >>> >>> execution
> >>> >>> was particularly clunky, probably in part because of the
> technology
> >>> >>> base
> >>> >>> they were dealing with at the time they designed the system. But
> >>> >>> beyond
> >>> >>> that, I'm not sure that the typical faculty member thinks of
> putting
> >>> >>> together their course in terms of assembling pages first and then
> >>> >>> putting
> >>> >>> functionality on the pages. Maybe it's possible to execute the
> >>> >>> concept
> >>> >>> in a
> >>> >>> way that makes it more intuitive than it is in CE (in fact,
> I'm sure
> >>> >>> of it),
> >>> >>> but I just don't know if "Create a New Page" carries the semantic
> >>> >>> freight
> >>> >>> necessary.
> >>> >>>
> >>> >>> - m
> >>> >>>
> >>> >>>
> >>> >>> Nathan Pearson wrote:
> >>> >>>
> >>> >>> I think it will come down to the affordance of where the
> option is
> >>> >>> displayed on the screen, the context, and the terminology.
> This is
> >>> >>> what I
> >>> >>> had in mind based on Clay's comments:
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png 
>
> >>> >>>
> >>> >>> It still forces the user to make a choice, but the imposition
> isn't
> >>> >>> significant and can easily be ignored. If we push the idea too
> far
> >>> >>> out of
> >>> >>> one's reach or periphery, then we risk making it too
> inefficient to
> >>> >>> get at.
> >>> >>>
> >>> >>> Nathan
> >>> >>>
> >>> >>>
> >>> >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
> >>> >>> <[hidden email]>
> >>> >>> wrote:
> >>> >>>>
> >>> >>>> To add to the comparison with confluence, (being bad here
> with self
> >>> >>>> referential design but I think it applies more broadly) I
> know the
> >>> >>>> subtle
> >>> >>>> "template" link is there but I ignore it because I'm almost
> always
> >>> >>>> in
> >>> >>>> a
> >>> >>>> hurry when I create a page in confluence and "template"
> doesn't hold
> >>> >>>> any
> >>> >>>> value for me. If I knew there were templates that would make
> my work
> >>> >>>> easier
> >>> >>>> perhaps I would use it. So I think it's more than just making
> sure
> >>> >>>> users
> >>> >>>> see that there are templates When we ask them if they want to
> use a
> >>> >>>> template, I think we should also allow them to discover the
> kinds of
> >>> >>>> templates there are and they can help me in my work. Some
> users will
> >>> >>>> be
> >>> >>>> curious and play around with options such as templates but
> what we
> >>> >>>> find
> >>> >>>> often in user research is that users are very busy and will
> go the
> >>> >>>> most
> >>> >>>> direct route they can. I guess what I'm contemplating is, "Is
> the
> >>> >>>> word
> >>> >>>> template enough information scent to allow users to know why
> they
> >>> >>>> should
> >>> >>>> choose it?"
> >>> >>>> -Daphne
> >>> >>>>
> >>> >>>>
> >>> >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
> >>> >>>>
> >>> >>>> You're probably right. There's still the issue of applying a
> page
> >>> >>>> template -- which should come before the edit page view.
> Confluence
> >>> >>>> does it
> >>> >>>> in a bit of a quirky way IMO where they drop you into the
> edit view,
> >>> >>>> and if
> >>> >>>> you happen to see the subtle link to invoke a template, you
> can take
> >>> >>>> a step
> >>> >>>> back to take two forward in applying a template. I find this
> pattern
> >>> >>>> to be
> >>> >>>> a bit clumsy.
> >>> >>>>
> >>> >>>> Maybe the way to get the best of both worlds is to use a drop
> down
> >>> >>>> when
> >>> >>>> clicking the Create New Page button that presents the
> options: Blank
> >>> >>>> Page or
> >>> >>>> From Template.
> >>> >>>>
> >>> >>>> Nathan
> >>> >>>>
> >>> >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
> >>> >>>> <[hidden email]> wrote:
> >>> >>>>>
> >>> >>>>> Sorry I couldn't make today's discussion, and particularly
> sorry
> >>> >>>>> since
> >>> >>>>> I'm going to indulge a bit of grousing about the create page
> bits,
> >>> >>>>> but
> >>> >>>>> I trust my stammering about the point yesterday may have
> prepared
> >>> >>>>> you
> >>> >>>>> for this line of attack, and that you understand the
> appreciative
> >>> >>>>> place it comes from ... so I can let my hair down. I'm going
> to put
> >>> >>>>> myself into the mind of an imagined, petulant user just to
> make a
> >>> >>>>> point.
> >>> >>>>>
> >>> >>>>> My gut instinct for the page creation suggested here is that
> there
> >>> >>>>> is
> >>> >>>>> too much complexity. Too many new words and ideas, too many
> >>> >>>>> possibilities on the screen, too many pictures, etc. Yes,
> it's done
> >>> >>>>> in the guise of helping people make good decisions at the
> outset,
> >>> >>>>> but
> >>> >>>>> I think it risks bewilderment by being overhelpful at the wrong
> >>> >>>>> time,
> >>> >>>>> and emphasizing the wrong things.
> >>> >>>>>
> >>> >>>>> There is a really simple concept at the core of the new page
> >>> >>>>> authoring
> >>> >>>>> metaphor which seems to me both powerful and elegant. You
> have a
> >>> >>>>> page, and you can start typing and/or drop things into the page
> >>> >>>>> that
> >>> >>>>> might be small (like a single assignment) or large (like a
> table of
> >>> >>>>> all assignments). But we bring little advantage to this simple
> >>> >>>>> concept by trying to define new kinds of pages or laying out
> the
> >>> >>>>> full
> >>> >>>>> spread of tools during the process of page creation.
> >>> >>>>>
> >>> >>>>> By the same token, we're not helping people by presenting the
> >>> >>>>> default
> >>> >>>>> option as a "blank page." Of *course* I don't want a blank
> page:
> >>> >>>>> I'm
> >>> >>>>> not going to choose that. I want a page that will have stuff
> in it.
> >>> >>>>> But rather than present me with a simple emphasis on how to
> quickly
> >>> >>>>> start authoring a page you appear to be putting your effort
> into
> >>> >>>>> front-loading my decision-making with a "page type," which
> >>> >>>>> instinctively strikes me as an odd notion: unnecessary and
> >>> >>>>> unhelpful.
> >>> >>>>>
> >>> >>>>> It's not about the *page*. It's about what goes *in* the
> page. I'm
> >>> >>>>> trying to create my content and you keep trying to get me to
> look
> >>> >>>>> at
> >>> >>>>> the margins or declare my full intent ahead of time.
> >>> >>>>>
> >>> >>>>> In other words I think the design simply has the wrong focus at
> >>> >>>>> this
> >>> >>>>> stage. What if we instead focused design energies on making the
> >>> >>>>> editing easy and flexible, and left the mere creation of the
> page
> >>> >>>>> virtually transparent? What if, instead of some dialogue asking
> >>> >>>>> about
> >>> >>>>> what kind of page this will be, when I click on "create a
> new page"
> >>> >>>>> I'm immediately there, or I'm immediately at a place that asks,
> >>> >>>>> "OK,
> >>> >>>>> ta-da, you have your page: now what are you going to put in
> it?"
> >>> >>>>> (e.g.
> >>> >>>>> with an interface that immediately leads me into either
> typing or
> >>> >>>>> plugging in "vignettes") Instead of emphasizing the page,
> emphasize
> >>> >>>>> what I'm going to put in it by leading with *that* kind of
> choice
> >>> >>>>> instead.
> >>> >>>>>
> >>> >>>>> Stepping back for a moment from my frothy remarks (which,
> again, I
> >>> >>>>> mean a bit playfully, but to make a point): I don't mean to
> insist
> >>> >>>>> that I really know what people want, but I do mean to
> suggest that
> >>> >>>>> I
> >>> >>>>> think this really needs testing.
> >>> >>>>>
> >>> >>>>> ~Clay
> >>> >>>>>
> >>> >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
> >>> >>>>> <[hidden email]>
> >>> >>>>> wrote:
> >>> >>>>> > Today's UX working session reviewed a few tweaks to the
> header
> >>> >>>>> > area
> >>> >>>>> > of the
> >>> >>>>> > site screen, plus a review of the "create page" screen.
> Both can
> >>> >>>>> > be
> >>> >>>>> > found
> >>> >>>>> > here:
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png 
>
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png 
>
> >>> >>>>> >
> >>> >>>>> > We also dove into the meatier topic of widgets/entities,
> which
> >>> >>>>> > we've
> >>> >>>>> > begun
> >>> >>>>> > calling vignettes (sorry to introduce more terminology,
> but we're
> >>> >>>>> > hoping
> >>> >>>>> > this will be better choice of words in the long run).
> >>> >>>>> >
> >>> >>>>> > As we see it, there are two major interaction themes
> within Sakai
> >>> >>>>> > sites.
> >>> >>>>> > The first consists of pages that contain a smattering of
> content
> >>> >>>>> > types;
> >>> >>>>> > ranging from text to functional bits called vignettes. The
> second
> >>> >>>>> > consists
> >>> >>>>> > of something called aggregate views (more on this later).
> >>> >>>>> >
> >>> >>>>> > To illustrate the vignette idea a bit more clearly, we
> discussed
> >>> >>>>> > the
> >>> >>>>> > following story:
> >>> >>>>> >
> >>> >>>>> > An instructor creates a page titled "week 1" and in that
> pages
> >>> >>>>> > provides a
> >>> >>>>> > short summary and informs students to read chapters 3 & 4.
> Below
> >>> >>>>> > this
> >>> >>>>> > block
> >>> >>>>> > of text, she inserts a discussion vignette and adds a brief
> >>> >>>>> > header
> >>> >>>>> > to
> >>> >>>>> > it
> >>> >>>>> > that reads "When you're done with chapter 3, discuss the
> >>> >>>>> > following
> >>> >>>>> > concept:
> >>> >>>>> > xyz". The instructor then adds more text related to
> chapter 4,
> >>> >>>>> > then
> >>> >>>>> > addes a
> >>> >>>>> > series of multiple choice questions -- which appear by
> inserting
> >>> >>>>> > survey
> >>> >>>>> > vignettes. Below these questions, she continues to add
> more text
> >>> >>>>> > that
> >>> >>>>> > tells
> >>> >>>>> > her students to prepare a 5 page write-up on both chapters
> and
> >>> >>>>> > submit
> >>> >>>>> > it in
> >>> >>>>> > the bottom of the page, or into the drop box vignette.
> >>> >>>>> >
> >>> >>>>> > A vignette would have a user-facing view as well as an
> edit/admin
> >>> >>>>> > view. The
> >>> >>>>> > latter would likely be presented during the edit page mode
> and
> >>> >>>>> > the
> >>> >>>>> > former
> >>> >>>>> > during the view page mode. However there may be some carry
> over
> >>> >>>>> > from
> >>> >>>>> > one to
> >>> >>>>> > the other, as in the case of a preview option while in the
> edit
> >>> >>>>> > mode.
> >>> >>>>> >
> >>> >>>>> > As for aggregate views, they can be thought of as a
> central place
> >>> >>>>> > that
> >>> >>>>> > consolidates a collection of all the vignettes that happen
> to be
> >>> >>>>> > peppered
> >>> >>>>> > through a site. Another way to think of it, which may or
> may not
> >>> >>>>> > be
> >>> >>>>> > helpful, is as a conventional tool view. To illustrate,
> one might
> >>> >>>>> > imagine
> >>> >>>>> > the following story:
> >>> >>>>> >
> >>> >>>>> > Before the start of a semester, the instructor has composed a
> >>> >>>>> > bunch
> >>> >>>>> > of pages
> >>> >>>>> > to teach his hybrid class. Several of those pages include
> one or
> >>> >>>>> > more
> >>> >>>>> > discussion vignettes. As the semester gets under way,
> students
> >>> >>>>> > begin
> >>> >>>>> > posting replies across a variety of pages, resulting in
> >>> >>>>> > simultaneous
> >>> >>>>> > threaded discussion sprouting up throughout the site.
> Rather than
> >>> >>>>> > sifting
> >>> >>>>> > through all the pages in the site in order to keep up, the
> >>> >>>>> > instructor
> >>> >>>>> > simply
> >>> >>>>> > goes to the aggregate discussion view where he is
> presented with
> >>> >>>>> > a
> >>> >>>>> > UI
> >>> >>>>> > that
> >>> >>>>> > is similar to a traditional discussion forum; with the
> exception
> >>> >>>>> > that
> >>> >>>>> > the
> >>> >>>>> > discussion topics and threads consist of the same stuff
> found in
> >>> >>>>> > the
> >>> >>>>> > vignettes that are scattered throughout the site.
> >>> >>>>> >
> >>> >>>>> > A few interesting points about this aggregate page view:
> Similar
> >>> >>>>> > to
> >>> >>>>> > the
> >>> >>>>> > vignettes, this view would have a user-facing side and an
> admin
> >>> >>>>> > control
> >>> >>>>> > panel of some sort. Also, the aggregate view may be available
> >>> >>>>> > only
> >>> >>>>> > to
> >>> >>>>> > the
> >>> >>>>> > site maintainer (or instructor in the above story) or to
> everyone
> >>> >>>>> > (including
> >>> >>>>> > his students). If the latter is true, than in theory, a
> student
> >>> >>>>> > can
> >>> >>>>> > engage
> >>> >>>>> > a particular discussion either inline on a page where a
> vignette
> >>> >>>>> > is
> >>> >>>>> > presented, or by going into the aggregate "discussion forum"
> >>> >>>>> > view.
> >>> >>>>> >
> >>> >>>>> > Another side note to all of this is that when a new
> discussion
> >>> >>>>> > vignette is
> >>> >>>>> > added to a page, it is then automatically pushed to the
> aggregate
> >>> >>>>> > view and
> >>> >>>>> > collected there. However, if a discussion post is added
> while in
> >>> >>>>> > the
> >>> >>>>> > aggregate view, it is NOT automatically pushed to some
> site page.
> >>> >>>>> > This
> >>> >>>>> > implies that the aggregate view can contain more
> discussion posts
> >>> >>>>> > than might
> >>> >>>>> > appear in the regular site pages. However, probably any
> such post
> >>> >>>>> > in
> >>> >>>>> > the
> >>> >>>>> > aggregate view can be pulled into a page while the page is
> being
> >>> >>>>> > composed.
> >>> >>>>> >
> >>> >>>>> > We then briefly discussed the UX question of "how might a
> user
> >>> >>>>> > locate
> >>> >>>>> > one of
> >>> >>>>> > these aggregate views"? We touched on a few ideas, but
> nothing
> >>> >>>>> > worth
> >>> >>>>> > mentioning until we put a bit more thought into them.
> >>> >>>>> >
> >>> >>>>> > Also, we focused on "threaded discussion" functionality to
> keep
> >>> >>>>> > the
> >>> >>>>> > model
> >>> >>>>> > manageable for now. None of this has been tested on other
> >>> >>>>> > functional
> >>> >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know
> if all
> >>> >>>>> > of
> >>> >>>>> > this
> >>> >>>>> > will hold water once we get there.
> >>> >>>>> >
> >>> >>>>> > Cheers,
> >>> >>>>> > Nathan
> >>> >>>>> >
> >>> >>>>> > --
> >>> >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>>>> >
> >>> >>>>> > E. [hidden email]
> >>> >>>>> > M. 602.418.5092
> >>> >>>>> > Y. npearson99 (Yahoo)
> >>> >>>>> > S. npearson99 (Skype)
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>>>> >
> >>> >>>>> > ________________________________
> >>> >>>>> > This automatic notification message was sent by Sakai Collab
> >>> >>>>> > (https://collab.sakaiproject.org//portal) from the WG:
> Authoring
> >>> >>>>> > site.
> >>> >>>>> > You can modify how you receive notifications at My
> Workspace >
> >>> >>>>> > Preferences.
> >>> >>>>> >
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> --
> >>> >>>>> Clay Fenlason
> >>> >>>>> Director, Educational Technology
> >>> >>>>> Georgia Institute of Technology
> >>> >>>>> (404) 385-6644
> >>> >>>>> ________________________________
> >>> >>>>> This automatic notification message was sent by Sakai Collab
> >>> >>>>> (https://collab.sakaiproject.org//portal) from the WG:
> Authoring
> >>> >>>>> site.
> >>> >>>>> You can modify how you receive notifications at My Workspace >
> >>> >>>>> Preferences.
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> --
> >>> >>>> Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>>>
> >>> >>>> E. [hidden email]
> >>> >>>> M. 602.418.5092
> >>> >>>> Y npearson99 (Yahoo)
> >>> >>>> S. npearson99 (Skype)
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>>>
> >>> >>>> ________________________________
> >>> >>>> This automatic notification message was sent by Sakai Collab
> >>> >>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
> >>> >>>> site.
> >>> >>>> You can modify how you receive notifications at My Workspace >
> >>> >>>> Preferences.
> >>> >>>>
> >>> >>>> Daphne Ogle
> >>> >>>> Senior Interaction Designer
> >>> >>>> University of California, Berkeley
> >>> >>>> Educational Technology Services
> >>> >>>> [hidden email]
> >>> >>>> cell (510)847-0308
> >>> >>>>
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>>
> >>> >>> E. [hidden email]
> >>> >>> M. 602.418.5092
> >>> >>> Y. npearson99 (Yahoo)
> >>> >>> S. npearson99 (Skype)
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>>
> >>> >>> ________________________________
> >>> >>> This automatic notification message was sent by Sakai Collab
> >>> >>> (https://collab.sakaiproject.org//portal) from the DG: User
> >>> >>> Experience
> >>> >>> site.
> >>> >>> You can modify how you receive notifications at My Workspace >
> >>> >>> Preferences.
> >>> >>>
> >>> >>> --
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >>> >>> Oracle Academic Enterprise Solutions Group
> >>> >>> 23A Glendale Road, Glendale, MA 01229
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>
> >>> >> E. [hidden email]
> >>> >> M. 602.418.5092
> >>> >> Y. npearson99 (Yahoo)
> >>> >> S. npearson99 (Skype)
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>
> >>> >> --
> >>> >>
> >>> >>
> >>> >>
> >>> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >>> >> Oracle Academic Enterprise Solutions Group
> >>> >> 23A Glendale Road, Glendale, MA 01229
> >>> >>
> >>> >> [see attachment: "unknown", size: 658 bytes]
> >>> >>
> >>> >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
> >>> >>
> >>> >> Attachments:
> >>> >>
> >>> >> unknown
> >>> >>
> >>> >> oracle_sig_logo.gif
> >>> >>
> >>> >> ________________________________
> >>> >> This automatic notification message was sent by Sakai Collab
> >>> >> (https://collab.sakaiproject.org//portal) from the WG:
> Authoring site.
> >>> >> You can modify how you receive notifications at My Workspace >
> >>> >> Preferences.
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Sean Keesler
> >>> > 130 Academy Street
> >>> > Manlius, NY 13104
> >>> > 315-663-7756
> >>> >
> >>> > ________________________________
> >>> > This automatic notification message was sent by Sakai Collab
> >>> > (https://collab.sakaiproject.org//portal) from the DG: User
> Experience
> >>> > site.
> >>> > You can modify how you receive notifications at My Workspace >
> >>> > Preferences.
> >>> >
> >>
> >>
> >>
> >> --
> >> Nathan Pearson | UX Lead | Sakai Foundation
> >>
> >> E. [hidden email]
> >> M. 602.418.5092
> >> Y. npearson99 (Yahoo)
> >> S. npearson99 (Skype)
> >>
> >>
> >>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>
> >> --
> >>
> >>
> >>
> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >> Oracle Academic Enterprise Solutions Group
> >> 23A Glendale Road, Glendale, MA 01229
> >
> >
> >
> > --
> > Clay Fenlason
> > Director, Educational Technology
> > Georgia Institute of Technology
> > (404) 385-6644
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> > You can modify how you receive notifications at My Workspace >
> Preferences.
> >
> ------------------------------------------------------------------------
>
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the DG: User Experience
> site.
> You can modify how you receive notifications at My Workspace >
> Preferences.

--


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
[see attachment: "oracle_sig_logo.gif", size: 658 bytes]



Attachments:

oracle_sig_logo.gif
https://collab.sakaiproject.org//access/content/attachment/b3cddd99-a636-43f3-8388-4057d1ad1184/oracle_sig_logo.gif

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
John Norman John Norman
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update

In reply to this post by Michael Feldstein

The Moodle example illustrates where I want us to go with what I have  
called site templates - some scaffolded help to speed site  
configuration. Different scaffolds will be able to do different  
amounts of work for you, and a key one will be the "reuse last year's  
structure".

John

On 19 Jan 2009, at 15:31, Michael Feldstein wrote:

> Sorry, I got a bit behind on this thread.
>
> The Moodle example is an instructive one, and I think it's important  
> not to miss the details. To begin with, when a user creates a new  
> course site in Moodle, she is prompted to choose a site format.
>
>
>
> Moodle's lovely embedded help feature describes the "Format" options  
> as follows:
>
>> Moodle course formats LAMS course format
>> This format makes the Learning Activity Management System (LAMS)  
>> interface central to the course. LAMS requires setting up by an  
>> administrator in order to use this format.
>>
>> SCORM format
>> This format displays a SCORM package in the first section of the  
>> course home page. (The SCORM/AICC module provides an alternative  
>> method of displaying a SCORM package in a course.)
>>
>> Social format
>> This format is oriented around one main forum, the Social forum,  
>> which appears on the course home page. It is useful for situations  
>> that are more freeform. They may not even be courses. For example,  
>> it could be used as a departmental notice board.
>>
>> Topics format
>> The course is organised into topic sections. Each topic section  
>> consists of activities.
>>
>> Weekly format
>> The course is organised week by week, with a clear start date and a  
>> finish date. Each week consists of activities.
>>
>> Weekly format - CSS/No tables
>> The course is organised week by week without using tables for layout.
>>
> When Luke talks about the overall learning sequence of the site  
> being defined, that entails at least two things, both of which flow  
> from that initial site format choice. First, there is a home page  
> for the site that has boxes which essentially outline the course  
> structure.
>
>
>
> Second, all content and activities are created and implicitly  
> sequenced within the context of that structure.
>
>
>
> So, if I'm understanding the current proposal for the 3akai sidebar  
> correctly, then Moodle still provides considerably more scaffolding  
> to the faculty. I like the idea of having an "anything goes" course  
> site format, but I also think that Moodle's more structured options  
> are also good models that are worth emulating.
>
> - m
>
>
> Nathan Pearson wrote:
>>
>> Thanks for this Luke.  You've done a better job of describing what  
>> I had in mind.  The Site Tool widget would enable the notion of  
>> "legacy Sakai" which is somewhat analogous to the BB model (create  
>> content / activities and then drop them into a page) vs. 3akai page  
>> authoring, which is somewhat analogous to the Moodle model (create  
>> a page and generate content / activities inline).
>>
>> It's entirely possible for both models to exist at the same time in  
>> the same site.
>>
>>
>> On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez <[hidden email]
>> > wrote:
>> Advanced apologies: The following are some visceral reactions.  They
>> aren't informed by expertise in design so much as by a mindset that
>> has been molded by teaching in BB Vista and Moodle.
>>
>> The approach Sean describes is more or less the approach that BB  
>> Vista
>> (e.g. WebCT) instructors are funneled into by default: The user
>> creates activities (e.g. discussions, quizes etc.) or content (e.g.
>> files or links to Web pages) and after having created some of these
>> activities or content the instructor can arrange them into learning
>> sequences.
>>
>> In contrast, the typical Moodle configuration more or less reverses
>> this approach:  The overall learning sequence of the site have been
>> predefined.  The instructor is presented with the predefined sequence
>> and then they author/drop-in the content or activities of their
>> choosing into this sequence.
>>
>> To say this in terms that don't refer to any product category: One
>> authoring approach encourages instructors to author content and
>> activities in a context that is abstracted from a sequence and then  
>> to
>> create this learning sequence afterward.  The other authoring  
>> approach
>> presents a predefined sequence and then prompts the instructor to
>> author content/activities within the context of this sequence.
>>
>> In our own discussion with faculty at Weber we've seen merits in both
>> approaches.
>>
>> Luke
>>
>> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]>  
>> wrote:
>> > That idea hits home. If I were designing a website (maybe for  
>> collaborative
>> > editing/brainstorming with a group), then organizing the space  
>> may into
>> > pages make a lot of sense.
>> >
>> > If I am trying get my course syllabus up and running in Sakai, it  
>> might not.
>> > Maybe a competing (rather traditional) train of thought would be.
>> >
>> > First designing the activities.
>> > Organizing and relating the activities to each other (by  
>> chronology, topic,
>> > type, etc).
>> >
>> > Sean
>> >
>> >
>> >
>> > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
>> > <[hidden email]> wrote:
>> >>
>> >> I'm afraid that I don't have a better idea. I'm just suggesting  
>> that there
>> >> should be some user testing of the notion that faculty will be  
>> comfortable
>> >> thinking about configuring their learning environment as:
>> >>
>> >> First creating new pages
>> >> Then putting functionality on those pages
>> >>
>> >> Does the blank slate work for them? Even with templates, the  
>> current
>> >> design suggests that faculty (particularly ones who are new to  
>> 3akai) will
>> >> have to intuit that, in order to add a discussion board (for  
>> example), they
>> >> must first create a new page. It may be that this is not a big  
>> deal for
>> >> faculty to get. But my experience with the execution of a  
>> somewhat similar
>> >> model in WebCT was bad enough to make me worry.
>> >>
>> >> - m
>> >>
>> >>
>> >> Nathan Pearson wrote:
>> >>
>> >> I'm not sure I understand the feedback.  What do you have in  
>> mind as a
>> >> better way to do it?
>> >>
>> >>
>> >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
>> >> <[hidden email]> wrote:
>> >>>
>> >>> Hmm.
>> >>>
>> >>> I just was helping my wife wrestle with Blackboard CE8 today,  
>> and this is
>> >>> mock-up is suddenly feeling a little familiar. And not in a  
>> good way. My
>> >>> sense is that WebCT started off with the same idea that people  
>> should just
>> >>> be able to assemble pages and put anything they want on them.  
>> The execution
>> >>> was particularly clunky, probably in part because of the  
>> technology base
>> >>> they were dealing with at the time they designed the system.  
>> But beyond
>> >>> that, I'm not sure that the typical faculty member thinks of  
>> putting
>> >>> together their course in terms of assembling pages first and  
>> then putting
>> >>> functionality on the pages. Maybe it's possible to execute the  
>> concept in a
>> >>> way that makes it more intuitive than it is in CE (in fact, I'm  
>> sure of it),
>> >>> but I just don't know if "Create a New Page" carries the  
>> semantic freight
>> >>> necessary.
>> >>>
>> >>> - m
>> >>>
>> >>>
>> >>> Nathan Pearson wrote:
>> >>>
>> >>> I think it will come down to the affordance of where the option  
>> is
>> >>> displayed on the screen, the context, and the terminology.  
>> This is what I
>> >>> had in mind based on Clay's comments:
>> >>>
>> >>>
>> >>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>> >>>
>> >>> It still forces the user to make a choice, but the imposition  
>> isn't
>> >>> significant and can easily be ignored.  If we push the idea too  
>> far out of
>> >>> one's reach or periphery, then we risk making it too  
>> inefficient to get at.
>> >>>
>> >>> Nathan
>> >>>
>> >>>
>> >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <[hidden email]
>> >
>> >>> wrote:
>> >>>>
>> >>>> To add to the comparison with confluence, (being bad here with  
>> self
>> >>>> referential design but I think it applies more broadly) I know  
>> the subtle
>> >>>> "template" link is there but I ignore it because I'm almost  
>> always in a
>> >>>> hurry when I create a page in confluence and "template"  
>> doesn't hold any
>> >>>> value for me.  If I knew there were templates that would make  
>> my work easier
>> >>>> perhaps I would use it.   So I think it's more than just  
>> making sure users
>> >>>> see that there are templates  When we ask them if they want to  
>> use a
>> >>>> template, I think we should also allow them to discover the  
>> kinds of
>> >>>> templates there are and they can help me in my work.  Some  
>> users will be
>> >>>> curious and play around with options such as templates but  
>> what we find
>> >>>> often in user research is that users are very busy and will go  
>> the most
>> >>>> direct route they can.  I guess what I'm contemplating is, "Is  
>> the word
>> >>>> template enough information scent to allow users to know why  
>> they should
>> >>>> choose it?"
>> >>>> -Daphne
>> >>>>
>> >>>>
>> >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>> >>>>
>> >>>> You're probably right.  There's still the issue of applying a  
>> page
>> >>>> template -- which should come before the edit page view.  
>> Confluence does it
>> >>>> in a bit of a quirky way IMO where they drop you into the edit  
>> view, and if
>> >>>> you happen to see the subtle link to invoke a template, you  
>> can take a step
>> >>>> back to take two forward in applying a template.  I find this  
>> pattern to be
>> >>>> a bit clumsy.
>> >>>>
>> >>>> Maybe the way to get the best of both worlds is to use a drop  
>> down when
>> >>>> clicking the Create New Page button that presents the options:  
>> Blank Page or
>> >>>> From Template.
>> >>>>
>> >>>> Nathan
>> >>>>
>> >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
>> >>>> <[hidden email]> wrote:
>> >>>>>
>> >>>>> Sorry I couldn't make today's discussion, and particularly  
>> sorry since
>> >>>>> I'm going to indulge a bit of grousing about the create page  
>> bits, but
>> >>>>> I trust my stammering about the point yesterday may have  
>> prepared you
>> >>>>> for this line of attack, and that you understand the  
>> appreciative
>> >>>>> place it comes from ... so I can let my hair down. I'm going  
>> to put
>> >>>>> myself into the mind of an imagined, petulant user just to  
>> make a
>> >>>>> point.
>> >>>>>
>> >>>>> My gut instinct for the page creation suggested here is that  
>> there is
>> >>>>> too much complexity. Too many new words and ideas, too many
>> >>>>> possibilities on the screen, too many pictures, etc. Yes,  
>> it's done
>> >>>>> in the guise of helping people make good decisions at the  
>> outset, but
>> >>>>> I think it risks bewilderment by being overhelpful at the  
>> wrong time,
>> >>>>> and emphasizing the wrong things.
>> >>>>>
>> >>>>> There is a really simple concept at the core of the new page  
>> authoring
>> >>>>> metaphor which seems to me both powerful and elegant. You  
>> have a
>> >>>>> page, and you can start typing and/or drop things into the  
>> page that
>> >>>>> might be small (like a single assignment) or large (like a  
>> table of
>> >>>>> all assignments). But we bring little advantage to this simple
>> >>>>> concept by trying to define new kinds of pages or laying out  
>> the full
>> >>>>> spread of tools during the process of page creation.
>> >>>>>
>> >>>>> By the same token, we're not helping people by presenting the  
>> default
>> >>>>> option as a "blank page." Of *course* I don't want a blank  
>> page: I'm
>> >>>>> not going to choose that. I want a page that will have stuff  
>> in it.
>> >>>>> But rather than present me with a simple emphasis on how to  
>> quickly
>> >>>>> start authoring a page you appear to be putting your effort  
>> into
>> >>>>> front-loading my decision-making with a "page type," which
>> >>>>> instinctively strikes me as an odd notion: unnecessary and  
>> unhelpful.
>> >>>>>
>> >>>>> It's not about the *page*. It's about what goes *in* the  
>> page. I'm
>> >>>>> trying to create my content and you keep trying to get me to  
>> look at
>> >>>>> the margins or declare my full intent ahead of time.
>> >>>>>
>> >>>>> In other words I think the design simply has the wrong focus  
>> at this
>> >>>>> stage. What if we instead focused design energies on making the
>> >>>>> editing easy and flexible, and left the mere creation of the  
>> page
>> >>>>> virtually transparent? What if, instead of some dialogue  
>> asking about
>> >>>>> what kind of page this will be, when I click on "create a new  
>> page"
>> >>>>> I'm immediately there, or I'm immediately at a place that  
>> asks, "OK,
>> >>>>> ta-da, you have your page: now what are you going to put in  
>> it?" (e.g.
>> >>>>> with an interface that immediately leads me into either  
>> typing or
>> >>>>> plugging in "vignettes") Instead of emphasizing the page,  
>> emphasize
>> >>>>> what I'm going to put in it by leading with *that* kind of  
>> choice
>> >>>>> instead.
>> >>>>>
>> >>>>> Stepping back for a moment from my frothy remarks (which,  
>> again, I
>> >>>>> mean a bit playfully, but to make a point): I don't mean to  
>> insist
>> >>>>> that I really know what people want, but I do mean to suggest  
>> that I
>> >>>>> think this really needs testing.
>> >>>>>
>> >>>>> ~Clay
>> >>>>>
>> >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]
>> >
>> >>>>> wrote:
>> >>>>> > Today's UX working session reviewed a few tweaks to the  
>> header area
>> >>>>> > of the
>> >>>>> > site screen, plus a review of the "create page" screen.  
>> Both can be
>> >>>>> > found
>> >>>>> > here:
>> >>>>> >
>> >>>>> >
>> >>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>> >>>>> >
>> >>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>> >>>>> >
>> >>>>> > We also dove into the meatier topic of widgets/entities,  
>> which we've
>> >>>>> > begun
>> >>>>> > calling vignettes (sorry to introduce more terminology, but  
>> we're
>> >>>>> > hoping
>> >>>>> > this will be better choice of words in the long run).
>> >>>>> >
>> >>>>> > As we see it, there are two major interaction themes within  
>> Sakai
>> >>>>> > sites.
>> >>>>> > The first consists of pages that contain a smattering of  
>> content
>> >>>>> > types;
>> >>>>> > ranging from text to functional bits called vignettes. The  
>> second
>> >>>>> > consists
>> >>>>> > of something called aggregate views (more on this later).
>> >>>>> >
>> >>>>> > To illustrate the vignette idea a bit more clearly, we  
>> discussed the
>> >>>>> > following story:
>> >>>>> >
>> >>>>> > An instructor creates a page titled "week 1" and in that  
>> pages
>> >>>>> > provides a
>> >>>>> > short summary and informs students to read chapters 3 & 4.  
>> Below this
>> >>>>> > block
>> >>>>> > of text, she inserts a discussion vignette and adds a brief  
>> header to
>> >>>>> > it
>> >>>>> > that reads "When you're done with chapter 3, discuss the  
>> following
>> >>>>> > concept:
>> >>>>> > xyz". The instructor then adds more text related to chapter  
>> 4, then
>> >>>>> > addes a
>> >>>>> > series of multiple choice questions -- which appear by  
>> inserting
>> >>>>> > survey
>> >>>>> > vignettes. Below these questions, she continues to add more  
>> text that
>> >>>>> > tells
>> >>>>> > her students to prepare a 5 page write-up on both chapters  
>> and submit
>> >>>>> > it in
>> >>>>> > the bottom of the page, or into the drop box vignette.
>> >>>>> >
>> >>>>> > A vignette would have a user-facing view as well as an edit/
>> admin
>> >>>>> > view. The
>> >>>>> > latter would likely be presented during the edit page mode  
>> and the
>> >>>>> > former
>> >>>>> > during the view page mode. However there may be some carry  
>> over from
>> >>>>> > one to
>> >>>>> > the other, as in the case of a preview option while in the  
>> edit mode.
>> >>>>> >
>> >>>>> > As for aggregate views, they can be thought of as a central  
>> place
>> >>>>> > that
>> >>>>> > consolidates a collection of all the vignettes that happen  
>> to be
>> >>>>> > peppered
>> >>>>> > through a site. Another way to think of it, which may or  
>> may not be
>> >>>>> > helpful, is as a conventional tool view. To illustrate, one  
>> might
>> >>>>> > imagine
>> >>>>> > the following story:
>> >>>>> >
>> >>>>> > Before the start of a semester, the instructor has composed  
>> a bunch
>> >>>>> > of pages
>> >>>>> > to teach his hybrid class. Several of those pages include  
>> one or more
>> >>>>> > discussion vignettes. As the semester gets under way,  
>> students begin
>> >>>>> > posting replies across a variety of pages, resulting in  
>> simultaneous
>> >>>>> > threaded discussion sprouting up throughout the site.  
>> Rather than
>> >>>>> > sifting
>> >>>>> > through all the pages in the site in order to keep up, the  
>> instructor
>> >>>>> > simply
>> >>>>> > goes to the aggregate discussion view where he is presented  
>> with a UI
>> >>>>> > that
>> >>>>> > is similar to a traditional discussion forum; with the  
>> exception that
>> >>>>> > the
>> >>>>> > discussion topics and threads consist of the same stuff  
>> found in the
>> >>>>> > vignettes that are scattered throughout the site.
>> >>>>> >
>> >>>>> > A few interesting points about this aggregate page view:  
>> Similar to
>> >>>>> > the
>> >>>>> > vignettes, this view would have a user-facing side and an  
>> admin
>> >>>>> > control
>> >>>>> > panel of some sort. Also, the aggregate view may be  
>> available only to
>> >>>>> > the
>> >>>>> > site maintainer (or instructor in the above story) or to  
>> everyone
>> >>>>> > (including
>> >>>>> > his students). If the latter is true, than in theory, a  
>> student can
>> >>>>> > engage
>> >>>>> > a particular discussion either inline on a page where a  
>> vignette is
>> >>>>> > presented, or by going into the aggregate "discussion  
>> forum" view.
>> >>>>> >
>> >>>>> > Another side note to all of this is that when a new  
>> discussion
>> >>>>> > vignette is
>> >>>>> > added to a page, it is then automatically pushed to the  
>> aggregate
>> >>>>> > view and
>> >>>>> > collected there. However, if a discussion post is added  
>> while in the
>> >>>>> > aggregate view, it is NOT automatically pushed to some site  
>> page.
>> >>>>> > This
>> >>>>> > implies that the aggregate view can contain more discussion  
>> posts
>> >>>>> > than might
>> >>>>> > appear in the regular site pages. However, probably any  
>> such post in
>> >>>>> > the
>> >>>>> > aggregate view can be pulled into a page while the page is  
>> being
>> >>>>> > composed.
>> >>>>> >
>> >>>>> > We then briefly discussed the UX question of "how might a  
>> user locate
>> >>>>> > one of
>> >>>>> > these aggregate views"? We touched on a few ideas, but  
>> nothing worth
>> >>>>> > mentioning until we put a bit more thought into them.
>> >>>>> >
>> >>>>> > Also, we focused on "threaded discussion" functionality to  
>> keep the
>> >>>>> > model
>> >>>>> > manageable for now. None of this has been tested on other  
>> functional
>> >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know  
>> if all of
>> >>>>> > this
>> >>>>> > will hold water once we get there.
>> >>>>> >
>> >>>>> > Cheers,
>> >>>>> > Nathan
>> >>>>> >
>> >>>>> > --
>> >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>> >>>>> >
>> >>>>> > E. [hidden email]
>> >>>>> > M. 602.418.5092
>> >>>>> > Y. npearson99 (Yahoo)
>> >>>>> > S. npearson99 (Skype)
>> >>>>> >
>> >>>>> >
>> >>>>> > http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>>>> >
>> >>>>> > ________________________________
>> >>>>> > This automatic notification message was sent by Sakai Collab
>> >>>>> > (https://collab.sakaiproject.org//portal) from the WG:  
>> Authoring
>> >>>>> > site.
>> >>>>> > You can modify how you receive notifications at My  
>> Workspace >
>> >>>>> > Preferences.
>> >>>>> >
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Clay Fenlason
>> >>>>> Director, Educational Technology
>> >>>>> Georgia Institute of Technology
>> >>>>> (404) 385-6644
>> >>>>> ________________________________
>> >>>>> This automatic notification message was sent by Sakai Collab
>> >>>>> (https://collab.sakaiproject.org//portal) from the WG:  
>> Authoring site.
>> >>>>> You can modify how you receive notifications at My Workspace >
>> >>>>> Preferences.
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Nathan Pearson | UX Lead | Sakai Foundation
>> >>>>
>> >>>> E. [hidden email]
>> >>>> M. 602.418.5092
>> >>>> Y npearson99 (Yahoo)
>> >>>> S. npearson99 (Skype)
>> >>>>
>> >>>>
>> >>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>>>
>> >>>> ________________________________
>> >>>> This automatic notification message was sent by Sakai Collab
>> >>>> (https://collab.sakaiproject.org//portal) from the WG:  
>> Authoring site.
>> >>>> You can modify how you receive notifications at My Workspace >
>> >>>> Preferences.
>> >>>>
>> >>>> Daphne Ogle
>> >>>> Senior Interaction Designer
>> >>>> University of California, Berkeley
>> >>>> Educational Technology Services
>> >>>> [hidden email]
>> >>>> cell (510)847-0308
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Nathan Pearson | UX Lead | Sakai Foundation
>> >>>
>> >>> E. [hidden email]
>> >>> M. 602.418.5092
>> >>> Y. npearson99 (Yahoo)
>> >>> S. npearson99 (Skype)
>> >>>
>> >>>
>> >>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>>
>> >>> ________________________________
>> >>> This automatic notification message was sent by Sakai Collab
>> >>> (https://collab.sakaiproject.org//portal) from the DG: User  
>> Experience site.
>> >>> You can modify how you receive notifications at My Workspace >
>> >>> Preferences.
>> >>>
>> >>> --
>> >>>
>> >>>
>> >>>
>> >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> >>> Oracle Academic Enterprise Solutions Group
>> >>> 23A Glendale Road, Glendale, MA 01229
>> >>
>> >>
>> >> --
>> >> Nathan Pearson | UX Lead | Sakai Foundation
>> >>
>> >> E. [hidden email]
>> >> M. 602.418.5092
>> >> Y. npearson99 (Yahoo)
>> >> S. npearson99 (Skype)
>> >>
>> >>
>> >> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>> >>
>> >> --
>> >>
>> >>
>> >>
>> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> >> Oracle Academic Enterprise Solutions Group
>> >> 23A Glendale Road, Glendale, MA 01229
>> >>
>> >> [see attachment: "unknown", size: 658 bytes]
>> >>
>> >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>> >>
>> >> Attachments:
>> >>
>> >> unknown
>> >>
>> >> oracle_sig_logo.gif
>> >>
>> >> ________________________________
>> >> This automatic notification message was sent by Sakai Collab
>> >> (https://collab.sakaiproject.org//portal) from the WG: Authoring  
>> site.
>> >> You can modify how you receive notifications at My Workspace >
>> >> Preferences.
>> >
>> >
>> >
>> > --
>> > Sean Keesler
>> > 130 Academy Street
>> > Manlius, NY 13104
>> > 315-663-7756
>> >
>> > ________________________________
>> > This automatic notification message was sent by Sakai Collab
>> > (https://collab.sakaiproject.org//portal) from the DG: User  
>> Experience site.
>> > You can modify how you receive notifications at My Workspace >  
>> Preferences.
>> >
>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. [hidden email]
>> M. 602.418.5092
>> Y. npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> --
>
>
>
> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229
> [see attachment: "Moodle Course Format.jpg", size: 16456 bytes]
>
> [see attachment: "Moodle Course Home Page.jpg", size: 113213 bytes]
>
> [see attachment: "Course Home Page - Editing Mode.jpg", size: 82209  
> bytes]
>
> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>
>
> Attachments:
>
> Moodle Course Format.jpg
>
> Moodle Course Home Page.jpg
>
> Course Home Page - Editing Mode.jpg
>
> oracle_sig_logo.gif
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Michael Feldstein Michael Feldstein
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update

In reply to this post by Michael Korcuska

Thanks, I'm beginning to see how the page and/or site template
approaches could provide the scaffolding. One of the nuances of the
Moodle design that's worth keeping in mind when refining these
affordances is that it doesn't really conform to either the
tools-in-site or page-authoring metaphors, exactly. The home page, whose
structure is decided by picking the Moodle site format (which could be
the same as picking a 3akai site or page template), can be thought of
almost as a visual lesson plan. It structures both the class experience
itself /and the course authoring experience/. So really, the first
question that teachers in Moodle ask themselves is, "What kind of course
structure do I want to have?" The site structure then becomes a scaffold
that mimics the course structure and lets the faculty member hang
content and activities off of that structure.

If you buy into that approach (and I do, personally), then you might
want to outline several different types of course structures, possibly
by interviewing some real teachers across a range of schools and
subjects. You do this not by looking at how they have structured their
courses in current Sakai implementations but how they actually /teach/
the courses. What is the rhythm of activities? Once you have that rhythm
abstracted into a set of pedagogical patterns, imagine how those
patterns could be instantiated in the flexible site design capabilities
we are talking about, and walk through what it would take to create and
use the necessary structures based on the 3akai template model. Would
the affordances be obvious to the teachers? How easy is it to accomplish
the set-up in a reasonably small number of clicks?

Many of the teachers who like Moodle like it because it seems to
anticipate what they want to do in their teaching. This is a good
example of how Moodle design achieves that design sense.

- m


Michael Korcuska wrote:

> This is also touched on in the previous content authoring template &
> structure requirements:
>
> http://docs.google.com/View?docid=ddx8d6kd_14hkxrgsgm&pageview=1&hgd=1&hl=en 
> <http://docs.google.com/View?docid=ddx8d6kd_14hkxrgsgm&pageview=1&hgd=1&hl=en>
>
>
> My personal view of "the right way" to do much of this is with a page
> authoring capability that has explicit sections defined. A "section"
> is a part of a page that has rules defining what kind of content it
> can contain and can have default content. Sections could be added or
> removed. To make Moodle's "Weekly Course Format" you would define a
> template with a section for each week of the term. For the "topic
> format" a template with several generic sections (topic 1, topic 2)
> that the user can customize and add to.
>
> There are some mockups that might make this clearer:
>
> http://confluence.sakaiproject.org/confluence/download/attachments/18186442/MJK+Authoring+2.pdf?version=1 
>
>
> And I can see this being handled with a site template as well,
> although the particular use case feels to me like a page template.
> Michael
>
> >>
> >> The Moodle example is an instructive one, and I think it's
> important not
> >> to
> >> miss the details. To begin with, when a user creates a new course
> site in
> >> Moodle, she is prompted to choose a site format.
> >>
>
> On Mon, Jan 19, 2009 at 4:56 PM, Clay Fenlason
> <[hidden email]> wrote:
> > I think these ideas are touched upon not in the sidebar of recent
> > design thinking, but rather in the "site template." See the
> > (unfortunately narrow) discussion here, especially in the comments:
> >
> > http://confluence.sakaiproject.org/confluence/x/iATWAg
> >
> > The basic pattern would be "anything goes" for raw capability, with
> > templates (chosen during creation, I'm not sure if they could be
> > switched after) for scaffolding.
> >
> > ~Clay
> >
> > On Mon, Jan 19, 2009 at 10:31 AM, Michael Feldstein
> > <[hidden email]> wrote:
> >> Sorry, I got a bit behind on this thread.
> >>
> >> The Moodle example is an instructive one, and I think it's
> important not
> >> to
> >> miss the details. To begin with, when a user creates a new course
> site in
> >> Moodle, she is prompted to choose a site format.
> >>
> >>
> >>
> >> Moodle's lovely embedded help feature describes the "Format"
> options as
> >> follows:
> >>
> >> Moodle course formats
> >>
> >> LAMS course format
> >>
> >> This format makes the Learning Activity Management System (LAMS)
> interface
> >> central to the course. LAMS requires setting up by an administrator in
> >> order
> >> to use this format.
> >>
> >> SCORM format
> >>
> >> This format displays a SCORM package in the first section of the
> course
> >> home
> >> page. (The SCORM/AICC module provides an alternative method of
> displaying
> >> a
> >> SCORM package in a course.)
> >>
> >> Social format
> >>
> >> This format is oriented around one main forum, the Social forum, which
> >> appears on the course home page. It is useful for situations that
> are more
> >> freeform. They may not even be courses. For example, it could be
> used as a
> >> departmental notice board.
> >>
> >> Topics format
> >>
> >> The course is organised into topic sections. Each topic section
> consists
> >> of
> >> activities.
> >>
> >> Weekly format
> >>
> >> The course is organised week by week, with a clear start date and a
> finish
> >> date. Each week consists of activities.
> >>
> >> Weekly format - CSS/No tables
> >>
> >> The course is organised week by week without using tables for layout.
> >>
> >> When Luke talks about the overall learning sequence of the site being
> >> defined, that entails at least two things, both of which flow from
> that
> >> initial site format choice. First, there is a home page for the
> site that
> >> has boxes which essentially outline the course structure.
> >>
> >>
> >>
> >> Second, all content and activities are created and implicitly
> sequenced
> >> within the context of that structure.
> >>
> >>
> >>
> >> So, if I'm understanding the current proposal for the 3akai sidebar
> >> correctly, then Moodle still provides considerably more scaffolding
> to the
> >> faculty. I like the idea of having an "anything goes" course site
> format,
> >> but I also think that Moodle's more structured options are also good
> >> models
> >> that are worth emulating.
> >>
> >> - m
> >>
> >>
> >> Nathan Pearson wrote:
> >>
> >> Thanks for this Luke. You've done a better job of describing what I
> had in
> >> mind. The Site Tool widget would enable the notion of "legacy
> Sakai" which
> >> is somewhat analogous to the BB model (create content / activities and
> >> then
> >> drop them into a page) vs. 3akai page authoring, which is somewhat
> >> analogous
> >> to the Moodle model (create a page and generate content / activities
> >> inline).
> >>
> >> It's entirely possible for both models to exist at the same time in
> the
> >> same
> >> site.
> >>
> >>
> >> On Sat, Jan 17, 2009 at 11:26 AM, Luke Fernandez
> >> <[hidden email]>
> >> wrote:
> >>>
> >>> Advanced apologies: The following are some visceral reactions. They
> >>> aren't informed by expertise in design so much as by a mindset that
> >>> has been molded by teaching in BB Vista and Moodle.
> >>>
> >>> The approach Sean describes is more or less the approach that BB
> Vista
> >>> (e.g. WebCT) instructors are funneled into by default: The user
> >>> creates activities (e.g. discussions, quizes etc.) or content (e.g.
> >>> files or links to Web pages) and after having created some of these
> >>> activities or content the instructor can arrange them into learning
> >>> sequences.
> >>>
> >>> In contrast, the typical Moodle configuration more or less reverses
> >>> this approach: The overall learning sequence of the site have been
> >>> predefined. The instructor is presented with the predefined sequence
> >>> and then they author/drop-in the content or activities of their
> >>> choosing into this sequence.
> >>>
> >>> To say this in terms that don't refer to any product category: One
> >>> authoring approach encourages instructors to author content and
> >>> activities in a context that is abstracted from a sequence and
> then to
> >>> create this learning sequence afterward. The other authoring approach
> >>> presents a predefined sequence and then prompts the instructor to
> >>> author content/activities within the context of this sequence.
> >>>
> >>> In our own discussion with faculty at Weber we've seen merits in both
> >>> approaches.
> >>>
> >>> Luke
> >>>
> >>> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]>
> wrote:
> >>> > That idea hits home. If I were designing a website (maybe for
> >>> > collaborative
> >>> > editing/brainstorming with a group), then organizing the space
> may into
> >>> > pages make a lot of sense.
> >>> >
> >>> > If I am trying get my course syllabus up and running in Sakai,
> it might
> >>> > not.
> >>> > Maybe a competing (rather traditional) train of thought would be.
> >>> >
> >>> > First designing the activities.
> >>> > Organizing and relating the activities to each other (by
> chronology,
> >>> > topic,
> >>> > type, etc).
> >>> >
> >>> > Sean
> >>> >
> >>> >
> >>> >
> >>> > On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein
> >>> > <[hidden email]> wrote:
> >>> >>
> >>> >> I'm afraid that I don't have a better idea. I'm just suggesting
> that
> >>> >> there
> >>> >> should be some user testing of the notion that faculty will be
> >>> >> comfortable
> >>> >> thinking about configuring their learning environment as:
> >>> >>
> >>> >> First creating new pages
> >>> >> Then putting functionality on those pages
> >>> >>
> >>> >> Does the blank slate work for them? Even with templates, the
> current
> >>> >> design suggests that faculty (particularly ones who are new to
> 3akai)
> >>> >> will
> >>> >> have to intuit that, in order to add a discussion board (for
> example),
> >>> >> they
> >>> >> must first create a new page. It may be that this is not a big
> deal
> >>> >> for
> >>> >> faculty to get. But my experience with the execution of a somewhat
> >>> >> similar
> >>> >> model in WebCT was bad enough to make me worry.
> >>> >>
> >>> >> - m
> >>> >>
> >>> >>
> >>> >> Nathan Pearson wrote:
> >>> >>
> >>> >> I'm not sure I understand the feedback. What do you have in
> mind as a
> >>> >> better way to do it?
> >>> >>
> >>> >>
> >>> >> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein
> >>> >> <[hidden email]> wrote:
> >>> >>>
> >>> >>> Hmm.
> >>> >>>
> >>> >>> I just was helping my wife wrestle with Blackboard CE8 today, and
> >>> >>> this
> >>> >>> is
> >>> >>> mock-up is suddenly feeling a little familiar. And not in a
> good way.
> >>> >>> My
> >>> >>> sense is that WebCT started off with the same idea that people
> should
> >>> >>> just
> >>> >>> be able to assemble pages and put anything they want on them. The
> >>> >>> execution
> >>> >>> was particularly clunky, probably in part because of the
> technology
> >>> >>> base
> >>> >>> they were dealing with at the time they designed the system. But
> >>> >>> beyond
> >>> >>> that, I'm not sure that the typical faculty member thinks of
> putting
> >>> >>> together their course in terms of assembling pages first and then
> >>> >>> putting
> >>> >>> functionality on the pages. Maybe it's possible to execute the
> >>> >>> concept
> >>> >>> in a
> >>> >>> way that makes it more intuitive than it is in CE (in fact,
> I'm sure
> >>> >>> of it),
> >>> >>> but I just don't know if "Create a New Page" carries the semantic
> >>> >>> freight
> >>> >>> necessary.
> >>> >>>
> >>> >>> - m
> >>> >>>
> >>> >>>
> >>> >>> Nathan Pearson wrote:
> >>> >>>
> >>> >>> I think it will come down to the affordance of where the
> option is
> >>> >>> displayed on the screen, the context, and the terminology.
> This is
> >>> >>> what I
> >>> >>> had in mind based on Clay's comments:
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png 
>
> >>> >>>
> >>> >>> It still forces the user to make a choice, but the imposition
> isn't
> >>> >>> significant and can easily be ignored. If we push the idea too
> far
> >>> >>> out of
> >>> >>> one's reach or periphery, then we risk making it too
> inefficient to
> >>> >>> get at.
> >>> >>>
> >>> >>> Nathan
> >>> >>>
> >>> >>>
> >>> >>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle
> >>> >>> <[hidden email]>
> >>> >>> wrote:
> >>> >>>>
> >>> >>>> To add to the comparison with confluence, (being bad here
> with self
> >>> >>>> referential design but I think it applies more broadly) I
> know the
> >>> >>>> subtle
> >>> >>>> "template" link is there but I ignore it because I'm almost
> always
> >>> >>>> in
> >>> >>>> a
> >>> >>>> hurry when I create a page in confluence and "template"
> doesn't hold
> >>> >>>> any
> >>> >>>> value for me. If I knew there were templates that would make
> my work
> >>> >>>> easier
> >>> >>>> perhaps I would use it. So I think it's more than just making
> sure
> >>> >>>> users
> >>> >>>> see that there are templates When we ask them if they want to
> use a
> >>> >>>> template, I think we should also allow them to discover the
> kinds of
> >>> >>>> templates there are and they can help me in my work. Some
> users will
> >>> >>>> be
> >>> >>>> curious and play around with options such as templates but
> what we
> >>> >>>> find
> >>> >>>> often in user research is that users are very busy and will
> go the
> >>> >>>> most
> >>> >>>> direct route they can. I guess what I'm contemplating is, "Is
> the
> >>> >>>> word
> >>> >>>> template enough information scent to allow users to know why
> they
> >>> >>>> should
> >>> >>>> choose it?"
> >>> >>>> -Daphne
> >>> >>>>
> >>> >>>>
> >>> >>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
> >>> >>>>
> >>> >>>> You're probably right. There's still the issue of applying a
> page
> >>> >>>> template -- which should come before the edit page view.
> Confluence
> >>> >>>> does it
> >>> >>>> in a bit of a quirky way IMO where they drop you into the
> edit view,
> >>> >>>> and if
> >>> >>>> you happen to see the subtle link to invoke a template, you
> can take
> >>> >>>> a step
> >>> >>>> back to take two forward in applying a template. I find this
> pattern
> >>> >>>> to be
> >>> >>>> a bit clumsy.
> >>> >>>>
> >>> >>>> Maybe the way to get the best of both worlds is to use a drop
> down
> >>> >>>> when
> >>> >>>> clicking the Create New Page button that presents the
> options: Blank
> >>> >>>> Page or
> >>> >>>> From Template.
> >>> >>>>
> >>> >>>> Nathan
> >>> >>>>
> >>> >>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason
> >>> >>>> <[hidden email]> wrote:
> >>> >>>>>
> >>> >>>>> Sorry I couldn't make today's discussion, and particularly
> sorry
> >>> >>>>> since
> >>> >>>>> I'm going to indulge a bit of grousing about the create page
> bits,
> >>> >>>>> but
> >>> >>>>> I trust my stammering about the point yesterday may have
> prepared
> >>> >>>>> you
> >>> >>>>> for this line of attack, and that you understand the
> appreciative
> >>> >>>>> place it comes from ... so I can let my hair down. I'm going
> to put
> >>> >>>>> myself into the mind of an imagined, petulant user just to
> make a
> >>> >>>>> point.
> >>> >>>>>
> >>> >>>>> My gut instinct for the page creation suggested here is that
> there
> >>> >>>>> is
> >>> >>>>> too much complexity. Too many new words and ideas, too many
> >>> >>>>> possibilities on the screen, too many pictures, etc. Yes,
> it's done
> >>> >>>>> in the guise of helping people make good decisions at the
> outset,
> >>> >>>>> but
> >>> >>>>> I think it risks bewilderment by being overhelpful at the wrong
> >>> >>>>> time,
> >>> >>>>> and emphasizing the wrong things.
> >>> >>>>>
> >>> >>>>> There is a really simple concept at the core of the new page
> >>> >>>>> authoring
> >>> >>>>> metaphor which seems to me both powerful and elegant. You
> have a
> >>> >>>>> page, and you can start typing and/or drop things into the page
> >>> >>>>> that
> >>> >>>>> might be small (like a single assignment) or large (like a
> table of
> >>> >>>>> all assignments). But we bring little advantage to this simple
> >>> >>>>> concept by trying to define new kinds of pages or laying out
> the
> >>> >>>>> full
> >>> >>>>> spread of tools during the process of page creation.
> >>> >>>>>
> >>> >>>>> By the same token, we're not helping people by presenting the
> >>> >>>>> default
> >>> >>>>> option as a "blank page." Of *course* I don't want a blank
> page:
> >>> >>>>> I'm
> >>> >>>>> not going to choose that. I want a page that will have stuff
> in it.
> >>> >>>>> But rather than present me with a simple emphasis on how to
> quickly
> >>> >>>>> start authoring a page you appear to be putting your effort
> into
> >>> >>>>> front-loading my decision-making with a "page type," which
> >>> >>>>> instinctively strikes me as an odd notion: unnecessary and
> >>> >>>>> unhelpful.
> >>> >>>>>
> >>> >>>>> It's not about the *page*. It's about what goes *in* the
> page. I'm
> >>> >>>>> trying to create my content and you keep trying to get me to
> look
> >>> >>>>> at
> >>> >>>>> the margins or declare my full intent ahead of time.
> >>> >>>>>
> >>> >>>>> In other words I think the design simply has the wrong focus at
> >>> >>>>> this
> >>> >>>>> stage. What if we instead focused design energies on making the
> >>> >>>>> editing easy and flexible, and left the mere creation of the
> page
> >>> >>>>> virtually transparent? What if, instead of some dialogue asking
> >>> >>>>> about
> >>> >>>>> what kind of page this will be, when I click on "create a
> new page"
> >>> >>>>> I'm immediately there, or I'm immediately at a place that asks,
> >>> >>>>> "OK,
> >>> >>>>> ta-da, you have your page: now what are you going to put in
> it?"
> >>> >>>>> (e.g.
> >>> >>>>> with an interface that immediately leads me into either
> typing or
> >>> >>>>> plugging in "vignettes") Instead of emphasizing the page,
> emphasize
> >>> >>>>> what I'm going to put in it by leading with *that* kind of
> choice
> >>> >>>>> instead.
> >>> >>>>>
> >>> >>>>> Stepping back for a moment from my frothy remarks (which,
> again, I
> >>> >>>>> mean a bit playfully, but to make a point): I don't mean to
> insist
> >>> >>>>> that I really know what people want, but I do mean to
> suggest that
> >>> >>>>> I
> >>> >>>>> think this really needs testing.
> >>> >>>>>
> >>> >>>>> ~Clay
> >>> >>>>>
> >>> >>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson
> >>> >>>>> <[hidden email]>
> >>> >>>>> wrote:
> >>> >>>>> > Today's UX working session reviewed a few tweaks to the
> header
> >>> >>>>> > area
> >>> >>>>> > of the
> >>> >>>>> > site screen, plus a review of the "create page" screen.
> Both can
> >>> >>>>> > be
> >>> >>>>> > found
> >>> >>>>> > here:
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png 
>
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png 
>
> >>> >>>>> >
> >>> >>>>> > We also dove into the meatier topic of widgets/entities,
> which
> >>> >>>>> > we've
> >>> >>>>> > begun
> >>> >>>>> > calling vignettes (sorry to introduce more terminology,
> but we're
> >>> >>>>> > hoping
> >>> >>>>> > this will be better choice of words in the long run).
> >>> >>>>> >
> >>> >>>>> > As we see it, there are two major interaction themes
> within Sakai
> >>> >>>>> > sites.
> >>> >>>>> > The first consists of pages that contain a smattering of
> content
> >>> >>>>> > types;
> >>> >>>>> > ranging from text to functional bits called vignettes. The
> second
> >>> >>>>> > consists
> >>> >>>>> > of something called aggregate views (more on this later).
> >>> >>>>> >
> >>> >>>>> > To illustrate the vignette idea a bit more clearly, we
> discussed
> >>> >>>>> > the
> >>> >>>>> > following story:
> >>> >>>>> >
> >>> >>>>> > An instructor creates a page titled "week 1" and in that
> pages
> >>> >>>>> > provides a
> >>> >>>>> > short summary and informs students to read chapters 3 & 4.
> Below
> >>> >>>>> > this
> >>> >>>>> > block
> >>> >>>>> > of text, she inserts a discussion vignette and adds a brief
> >>> >>>>> > header
> >>> >>>>> > to
> >>> >>>>> > it
> >>> >>>>> > that reads "When you're done with chapter 3, discuss the
> >>> >>>>> > following
> >>> >>>>> > concept:
> >>> >>>>> > xyz". The instructor then adds more text related to
> chapter 4,
> >>> >>>>> > then
> >>> >>>>> > addes a
> >>> >>>>> > series of multiple choice questions -- which appear by
> inserting
> >>> >>>>> > survey
> >>> >>>>> > vignettes. Below these questions, she continues to add
> more text
> >>> >>>>> > that
> >>> >>>>> > tells
> >>> >>>>> > her students to prepare a 5 page write-up on both chapters
> and
> >>> >>>>> > submit
> >>> >>>>> > it in
> >>> >>>>> > the bottom of the page, or into the drop box vignette.
> >>> >>>>> >
> >>> >>>>> > A vignette would have a user-facing view as well as an
> edit/admin
> >>> >>>>> > view. The
> >>> >>>>> > latter would likely be presented during the edit page mode
> and
> >>> >>>>> > the
> >>> >>>>> > former
> >>> >>>>> > during the view page mode. However there may be some carry
> over
> >>> >>>>> > from
> >>> >>>>> > one to
> >>> >>>>> > the other, as in the case of a preview option while in the
> edit
> >>> >>>>> > mode.
> >>> >>>>> >
> >>> >>>>> > As for aggregate views, they can be thought of as a
> central place
> >>> >>>>> > that
> >>> >>>>> > consolidates a collection of all the vignettes that happen
> to be
> >>> >>>>> > peppered
> >>> >>>>> > through a site. Another way to think of it, which may or
> may not
> >>> >>>>> > be
> >>> >>>>> > helpful, is as a conventional tool view. To illustrate,
> one might
> >>> >>>>> > imagine
> >>> >>>>> > the following story:
> >>> >>>>> >
> >>> >>>>> > Before the start of a semester, the instructor has composed a
> >>> >>>>> > bunch
> >>> >>>>> > of pages
> >>> >>>>> > to teach his hybrid class. Several of those pages include
> one or
> >>> >>>>> > more
> >>> >>>>> > discussion vignettes. As the semester gets under way,
> students
> >>> >>>>> > begin
> >>> >>>>> > posting replies across a variety of pages, resulting in
> >>> >>>>> > simultaneous
> >>> >>>>> > threaded discussion sprouting up throughout the site.
> Rather than
> >>> >>>>> > sifting
> >>> >>>>> > through all the pages in the site in order to keep up, the
> >>> >>>>> > instructor
> >>> >>>>> > simply
> >>> >>>>> > goes to the aggregate discussion view where he is
> presented with
> >>> >>>>> > a
> >>> >>>>> > UI
> >>> >>>>> > that
> >>> >>>>> > is similar to a traditional discussion forum; with the
> exception
> >>> >>>>> > that
> >>> >>>>> > the
> >>> >>>>> > discussion topics and threads consist of the same stuff
> found in
> >>> >>>>> > the
> >>> >>>>> > vignettes that are scattered throughout the site.
> >>> >>>>> >
> >>> >>>>> > A few interesting points about this aggregate page view:
> Similar
> >>> >>>>> > to
> >>> >>>>> > the
> >>> >>>>> > vignettes, this view would have a user-facing side and an
> admin
> >>> >>>>> > control
> >>> >>>>> > panel of some sort. Also, the aggregate view may be available
> >>> >>>>> > only
> >>> >>>>> > to
> >>> >>>>> > the
> >>> >>>>> > site maintainer (or instructor in the above story) or to
> everyone
> >>> >>>>> > (including
> >>> >>>>> > his students). If the latter is true, than in theory, a
> student
> >>> >>>>> > can
> >>> >>>>> > engage
> >>> >>>>> > a particular discussion either inline on a page where a
> vignette
> >>> >>>>> > is
> >>> >>>>> > presented, or by going into the aggregate "discussion forum"
> >>> >>>>> > view.
> >>> >>>>> >
> >>> >>>>> > Another side note to all of this is that when a new
> discussion
> >>> >>>>> > vignette is
> >>> >>>>> > added to a page, it is then automatically pushed to the
> aggregate
> >>> >>>>> > view and
> >>> >>>>> > collected there. However, if a discussion post is added
> while in
> >>> >>>>> > the
> >>> >>>>> > aggregate view, it is NOT automatically pushed to some
> site page.
> >>> >>>>> > This
> >>> >>>>> > implies that the aggregate view can contain more
> discussion posts
> >>> >>>>> > than might
> >>> >>>>> > appear in the regular site pages. However, probably any
> such post
> >>> >>>>> > in
> >>> >>>>> > the
> >>> >>>>> > aggregate view can be pulled into a page while the page is
> being
> >>> >>>>> > composed.
> >>> >>>>> >
> >>> >>>>> > We then briefly discussed the UX question of "how might a
> user
> >>> >>>>> > locate
> >>> >>>>> > one of
> >>> >>>>> > these aggregate views"? We touched on a few ideas, but
> nothing
> >>> >>>>> > worth
> >>> >>>>> > mentioning until we put a bit more thought into them.
> >>> >>>>> >
> >>> >>>>> > Also, we focused on "threaded discussion" functionality to
> keep
> >>> >>>>> > the
> >>> >>>>> > model
> >>> >>>>> > manageable for now. None of this has been tested on other
> >>> >>>>> > functional
> >>> >>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know
> if all
> >>> >>>>> > of
> >>> >>>>> > this
> >>> >>>>> > will hold water once we get there.
> >>> >>>>> >
> >>> >>>>> > Cheers,
> >>> >>>>> > Nathan
> >>> >>>>> >
> >>> >>>>> > --
> >>> >>>>> > Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>>>> >
> >>> >>>>> > E. [hidden email]
> >>> >>>>> > M. 602.418.5092
> >>> >>>>> > Y. npearson99 (Yahoo)
> >>> >>>>> > S. npearson99 (Skype)
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> >>> >>>>> >
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>>>> >
> >>> >>>>> > ________________________________
> >>> >>>>> > This automatic notification message was sent by Sakai Collab
> >>> >>>>> > (https://collab.sakaiproject.org//portal) from the WG:
> Authoring
> >>> >>>>> > site.
> >>> >>>>> > You can modify how you receive notifications at My
> Workspace >
> >>> >>>>> > Preferences.
> >>> >>>>> >
> >>> >>>>>
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> --
> >>> >>>>> Clay Fenlason
> >>> >>>>> Director, Educational Technology
> >>> >>>>> Georgia Institute of Technology
> >>> >>>>> (404) 385-6644
> >>> >>>>> ________________________________
> >>> >>>>> This automatic notification message was sent by Sakai Collab
> >>> >>>>> (https://collab.sakaiproject.org//portal) from the WG:
> Authoring
> >>> >>>>> site.
> >>> >>>>> You can modify how you receive notifications at My Workspace >
> >>> >>>>> Preferences.
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> --
> >>> >>>> Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>>>
> >>> >>>> E. [hidden email]
> >>> >>>> M. 602.418.5092
> >>> >>>> Y npearson99 (Yahoo)
> >>> >>>> S. npearson99 (Skype)
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>>>
> >>> >>>> ________________________________
> >>> >>>> This automatic notification message was sent by Sakai Collab
> >>> >>>> (https://collab.sakaiproject.org//portal) from the WG: Authoring
> >>> >>>> site.
> >>> >>>> You can modify how you receive notifications at My Workspace >
> >>> >>>> Preferences.
> >>> >>>>
> >>> >>>> Daphne Ogle
> >>> >>>> Senior Interaction Designer
> >>> >>>> University of California, Berkeley
> >>> >>>> Educational Technology Services
> >>> >>>> [hidden email]
> >>> >>>> cell (510)847-0308
> >>> >>>>
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>>
> >>> >>> E. [hidden email]
> >>> >>> M. 602.418.5092
> >>> >>> Y. npearson99 (Yahoo)
> >>> >>> S. npearson99 (Skype)
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>>
> >>> >>> ________________________________
> >>> >>> This automatic notification message was sent by Sakai Collab
> >>> >>> (https://collab.sakaiproject.org//portal) from the DG: User
> >>> >>> Experience
> >>> >>> site.
> >>> >>> You can modify how you receive notifications at My Workspace >
> >>> >>> Preferences.
> >>> >>>
> >>> >>> --
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >>> >>> Oracle Academic Enterprise Solutions Group
> >>> >>> 23A Glendale Road, Glendale, MA 01229
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Nathan Pearson | UX Lead | Sakai Foundation
> >>> >>
> >>> >> E. [hidden email]
> >>> >> M. 602.418.5092
> >>> >> Y. npearson99 (Yahoo)
> >>> >> S. npearson99 (Skype)
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>> >>
> >>> >> --
> >>> >>
> >>> >>
> >>> >>
> >>> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >>> >> Oracle Academic Enterprise Solutions Group
> >>> >> 23A Glendale Road, Glendale, MA 01229
> >>> >>
> >>> >> [see attachment: "unknown", size: 658 bytes]
> >>> >>
> >>> >> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
> >>> >>
> >>> >> Attachments:
> >>> >>
> >>> >> unknown
> >>> >>
> >>> >> oracle_sig_logo.gif
> >>> >>
> >>> >> ________________________________
> >>> >> This automatic notification message was sent by Sakai Collab
> >>> >> (https://collab.sakaiproject.org//portal) from the WG:
> Authoring site.
> >>> >> You can modify how you receive notifications at My Workspace >
> >>> >> Preferences.
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Sean Keesler
> >>> > 130 Academy Street
> >>> > Manlius, NY 13104
> >>> > 315-663-7756
> >>> >
> >>> > ________________________________
> >>> > This automatic notification message was sent by Sakai Collab
> >>> > (https://collab.sakaiproject.org//portal) from the DG: User
> Experience
> >>> > site.
> >>> > You can modify how you receive notifications at My Workspace >
> >>> > Preferences.
> >>> >
> >>
> >>
> >>
> >> --
> >> Nathan Pearson | UX Lead | Sakai Foundation
> >>
> >> E. [hidden email]
> >> M. 602.418.5092
> >> Y. npearson99 (Yahoo)
> >> S. npearson99 (Skype)
> >>
> >>
> >>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix 
> <http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix>
>
> >>
> >> --
> >>
> >>
> >>
> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >> Oracle Academic Enterprise Solutions Group
> >> 23A Glendale Road, Glendale, MA 01229
> >
> >
> >
> > --
> > Clay Fenlason
> > Director, Educational Technology
> > Georgia Institute of Technology
> > (404) 385-6644
> > ________________________________
> > This automatic notification message was sent by Sakai Collab
> > (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
> > You can modify how you receive notifications at My Workspace >
> Preferences.
> >
> ------------------------------------------------------------------------
>
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org//portal) from the DG: User Experience
> site.
> You can modify how you receive notifications at My Workspace >
> Preferences.

--


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
[see attachment: "unknown", size: 658 bytes]



Attachments:

unknown
https://collab.sakaiproject.org//access/content/attachment/b03a5c2a-63e3-4db4-8dbc-6b0f82776bba/unknown.gif

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
Daphne Ogle Daphne Ogle
Reply | Threaded
Open this post in threaded view
|

Re: UX working session update

In reply to this post by Nathan Pearson

I think site templates could be helpful -- especially if we really  
understand the common patterns of course sites and use faculty's  
language in referring to them.

Another idea that Marc B. and I tried to push through with the course  
management work a few years ago was a to-do-like-list-widget that  
helped faculty know what to do next.  The idea was that a site would  
be created in one click and then the to do list, which was on the home  
page, was scaffolding for helping get the site populated and ready to  
go.   This design work assumed the old Sakai confines and I think  
could be even easier to do now.  I think there are patterns in the  
kinds of things many faculty want in their site so we could auto-
populate the list with things like "create (or add or something)  
syllabus" that would then also be a shortcut to doing just that.  The  
list would be customizable (with good out of the box defaults) and  
could even be smart and remember the kinds of things a certain  
instructor does in creating their course site.

-Daphne

On Jan 17, 2009, at 9:24 AM, Nathan Pearson wrote:

> There may be a solution I've been toying with that would satisfy  
> this concern.  The sidebar (see mockup) can be edited, and therefor  
> widgets can be added into the sidebar.  It's conceivable that there  
> could be a widget called "Site Tools" that would mimic traditional  
> Sakai by presenting links to pages with tools on them.  No need to  
> first add a page, then insert tool-ish functionality.
>
> These pages would be the aggregate views, or put another way, tool  
> views -- not just vignettes.
>
> Also, it's conceivable that we could have site templates (not just  
> page templates).  One such site template would present a legacy  
> Sakai layout, which would include this Site Tools sidebar widget  
> already in place -- so the user wouldn't need to add it to the  
> sidebar first, they could just select this site template and jump  
> right in to using it.
>
> How does that sound?
>
>
>
> On Sat, Jan 17, 2009 at 8:16 AM, Sean Keesler <[hidden email]>  
> wrote:
> That idea hits home. If I were designing a website (maybe for  
> collaborative editing/brainstorming with a group), then organizing  
> the space may into pages make a lot of sense.
>
> If I am trying get my course syllabus up and running in Sakai, it  
> might not. Maybe a competing (rather traditional) train of thought  
> would be.
> First designing the activities.
> Organizing and relating the activities to each other (by chronology,  
> topic, type, etc).
>
> Sean
>
>
>
> On Sat, Jan 17, 2009 at 8:05 AM, Michael Feldstein <[hidden email]
> > wrote:
> I'm afraid that I don't have a better idea. I'm just suggesting that  
> there should be some user testing of the notion that faculty will be  
> comfortable thinking about configuring their learning environment as:
> First creating new pages
> Then putting functionality on those pages
> Does the blank slate work for them? Even with templates, the current  
> design suggests that faculty (particularly ones who are new to  
> 3akai) will have to intuit that, in order to add a discussion board  
> (for example), they must first create a new page. It may be that  
> this is not a big deal for faculty to get. But my experience with  
> the execution of a somewhat similar model in WebCT was bad enough to  
> make me worry.
>
>
> - m
>
>
> Nathan Pearson wrote:
>>
>> I'm not sure I understand the feedback.  What do you have in mind  
>> as a better way to do it?
>>
>>
>> On Fri, Jan 16, 2009 at 9:17 PM, Michael Feldstein <[hidden email]
>> > wrote:
>> Hmm.
>>
>> I just was helping my wife wrestle with Blackboard CE8 today, and  
>> this is mock-up is suddenly feeling a little familiar. And not in a  
>> good way. My sense is that WebCT started off with the same idea  
>> that people should just be able to assemble pages and put anything  
>> they want on them. The execution was particularly clunky, probably  
>> in part because of the technology base they were dealing with at  
>> the time they designed the system. But beyond that, I'm not sure  
>> that the typical faculty member thinks of putting together their  
>> course in terms of assembling pages first and then putting  
>> functionality on the pages. Maybe it's possible to execute the  
>> concept in a way that makes it more intuitive than it is in CE (in  
>> fact, I'm sure of it), but I just don't know if "Create a New Page"  
>> carries the semantic freight necessary.
>>
>> - m
>>
>>
>> Nathan Pearson wrote:
>>>
>>> I think it will come down to the affordance of where the option is  
>>> displayed on the screen, the context, and the terminology.  This  
>>> is what I had in mind based on Clay's comments:
>>>
>>> http://bugs.sakaiproject.org/confluence/download/attachments/47580296/2.png
>>>
>>> It still forces the user to make a choice, but the imposition  
>>> isn't significant and can easily be ignored.  If we push the idea  
>>> too far out of one's reach or periphery, then we risk making it  
>>> too inefficient to get at.
>>>
>>> Nathan
>>>
>>>
>>> On Fri, Jan 16, 2009 at 5:52 PM, Daphne Ogle <[hidden email]
>>> > wrote:
>>> To add to the comparison with confluence, (being bad here with  
>>> self referential design but I think it applies more broadly) I  
>>> know the subtle "template" link is there but I ignore it because  
>>> I'm almost always in a hurry when I create a page in confluence  
>>> and "template" doesn't hold any value for me.  If I knew there  
>>> were templates that would make my work easier perhaps I would use  
>>> it.   So I think it's more than just making sure users see that  
>>> there are templates  When we ask them if they want to use a  
>>> template, I think we should also allow them to discover the kinds  
>>> of templates there are and they can help me in my work.  Some  
>>> users will be curious and play around with options such as  
>>> templates but what we find often in user research is that users  
>>> are very busy and will go the most direct route they can.  I guess  
>>> what I'm contemplating is, "Is the word template enough  
>>> information scent to allow users to know why they should choose it?"
>>>
>>> -Daphne
>>>
>>>
>>> On Jan 15, 2009, at 7:09 PM, Nathan Pearson wrote:
>>>
>>>> You're probably right.  There's still the issue of applying a  
>>>> page template -- which should come before the edit page view.  
>>>> Confluence does it in a bit of a quirky way IMO where they drop  
>>>> you into the edit view, and if you happen to see the subtle link  
>>>> to invoke a template, you can take a step back to take two  
>>>> forward in applying a template.  I find this pattern to be a bit  
>>>> clumsy.
>>>>
>>>> Maybe the way to get the best of both worlds is to use a drop  
>>>> down when clicking the Create New Page button that presents the  
>>>> options: Blank Page or From Template.
>>>>
>>>> Nathan
>>>>
>>>> On Thu, Jan 15, 2009 at 7:09 PM, Clay Fenlason <[hidden email]
>>>> > wrote:
>>>> Sorry I couldn't make today's discussion, and particularly sorry  
>>>> since
>>>> I'm going to indulge a bit of grousing about the create page  
>>>> bits, but
>>>> I trust my stammering about the point yesterday may have prepared  
>>>> you
>>>> for this line of attack, and that you understand the appreciative
>>>> place it comes from ... so I can let my hair down. I'm going to put
>>>> myself into the mind of an imagined, petulant user just to make a
>>>> point.
>>>>
>>>> My gut instinct for the page creation suggested here is that  
>>>> there is
>>>> too much complexity. Too many new words and ideas, too many
>>>> possibilities on the screen, too many pictures, etc. Yes, it's done
>>>> in the guise of helping people make good decisions at the outset,  
>>>> but
>>>> I think it risks bewilderment by being overhelpful at the wrong  
>>>> time,
>>>> and emphasizing the wrong things.
>>>>
>>>> There is a really simple concept at the core of the new page  
>>>> authoring
>>>> metaphor which seems to me both powerful and elegant. You have a
>>>> page, and you can start typing and/or drop things into the page  
>>>> that
>>>> might be small (like a single assignment) or large (like a table of
>>>> all assignments). But we bring little advantage to this simple
>>>> concept by trying to define new kinds of pages or laying out the  
>>>> full
>>>> spread of tools during the process of page creation.
>>>>
>>>> By the same token, we're not helping people by presenting the  
>>>> default
>>>> option as a "blank page." Of *course* I don't want a blank page:  
>>>> I'm
>>>> not going to choose that. I want a page that will have stuff in it.
>>>> But rather than present me with a simple emphasis on how to quickly
>>>> start authoring a page you appear to be putting your effort into
>>>> front-loading my decision-making with a "page type," which
>>>> instinctively strikes me as an odd notion: unnecessary and  
>>>> unhelpful.
>>>>
>>>> It's not about the *page*. It's about what goes *in* the page. I'm
>>>> trying to create my content and you keep trying to get me to look  
>>>> at
>>>> the margins or declare my full intent ahead of time.
>>>>
>>>> In other words I think the design simply has the wrong focus at  
>>>> this
>>>> stage. What if we instead focused design energies on making the
>>>> editing easy and flexible, and left the mere creation of the page
>>>> virtually transparent? What if, instead of some dialogue asking  
>>>> about
>>>> what kind of page this will be, when I click on "create a new page"
>>>> I'm immediately there, or I'm immediately at a place that asks,  
>>>> "OK,
>>>> ta-da, you have your page: now what are you going to put in  
>>>> it?" (e.g.
>>>> with an interface that immediately leads me into either typing or
>>>> plugging in "vignettes") Instead of emphasizing the page, emphasize
>>>> what I'm going to put in it by leading with *that* kind of choice
>>>> instead.
>>>>
>>>> Stepping back for a moment from my frothy remarks (which, again, I
>>>> mean a bit playfully, but to make a point): I don't mean to insist
>>>> that I really know what people want, but I do mean to suggest  
>>>> that I
>>>> think this really needs testing.
>>>>
>>>> ~Clay
>>>>
>>>> On Thu, Jan 15, 2009 at 3:41 PM, Nathan Pearson <[hidden email]
>>>> > wrote:
>>>> > Today's UX working session reviewed a few tweaks to the header  
>>>> area of the
>>>> > site screen, plus a review of the "create page" screen. Both  
>>>> can be found
>>>> > here:
>>>> >
>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/site1.png
>>>> > http://bugs.sakaiproject.org/confluence/download/attachments/47580296/create_page1.png
>>>> >
>>>> > We also dove into the meatier topic of widgets/entities, which  
>>>> we've begun
>>>> > calling vignettes (sorry to introduce more terminology, but  
>>>> we're hoping
>>>> > this will be better choice of words in the long run).
>>>> >
>>>> > As we see it, there are two major interaction themes within  
>>>> Sakai sites.
>>>> > The first consists of pages that contain a smattering of  
>>>> content types;
>>>> > ranging from text to functional bits called vignettes. The  
>>>> second consists
>>>> > of something called aggregate views (more on this later).
>>>> >
>>>> > To illustrate the vignette idea a bit more clearly, we  
>>>> discussed the
>>>> > following story:
>>>> >
>>>> > An instructor creates a page titled "week 1" and in that pages  
>>>> provides a
>>>> > short summary and informs students to read chapters 3 & 4.  
>>>> Below this block
>>>> > of text, she inserts a discussion vignette and adds a brief  
>>>> header to it
>>>> > that reads "When you're done with chapter 3, discuss the  
>>>> following concept:
>>>> > xyz". The instructor then adds more text related to chapter 4,  
>>>> then addes a
>>>> > series of multiple choice questions -- which appear by  
>>>> inserting survey
>>>> > vignettes. Below these questions, she continues to add more  
>>>> text that tells
>>>> > her students to prepare a 5 page write-up on both chapters and  
>>>> submit it in
>>>> > the bottom of the page, or into the drop box vignette.
>>>> >
>>>> > A vignette would have a user-facing view as well as an edit/
>>>> admin view. The
>>>> > latter would likely be presented during the edit page mode and  
>>>> the former
>>>> > during the view page mode. However there may be some carry over  
>>>> from one to
>>>> > the other, as in the case of a preview option while in the edit  
>>>> mode.
>>>> >
>>>> > As for aggregate views, they can be thought of as a central  
>>>> place that
>>>> > consolidates a collection of all the vignettes that happen to  
>>>> be peppered
>>>> > through a site. Another way to think of it, which may or may  
>>>> not be
>>>> > helpful, is as a conventional tool view. To illustrate, one  
>>>> might imagine
>>>> > the following story:
>>>> >
>>>> > Before the start of a semester, the instructor has composed a  
>>>> bunch of pages
>>>> > to teach his hybrid class. Several of those pages include one  
>>>> or more
>>>> > discussion vignettes. As the semester gets under way, students  
>>>> begin
>>>> > posting replies across a variety of pages, resulting in  
>>>> simultaneous
>>>> > threaded discussion sprouting up throughout the site. Rather  
>>>> than sifting
>>>> > through all the pages in the site in order to keep up, the  
>>>> instructor simply
>>>> > goes to the aggregate discussion view where he is presented  
>>>> with a UI that
>>>> > is similar to a traditional discussion forum; with the  
>>>> exception that the
>>>> > discussion topics and threads consist of the same stuff found  
>>>> in the
>>>> > vignettes that are scattered throughout the site.
>>>> >
>>>> > A few interesting points about this aggregate page view:  
>>>> Similar to the
>>>> > vignettes, this view would have a user-facing side and an admin  
>>>> control
>>>> > panel of some sort. Also, the aggregate view may be available  
>>>> only to the
>>>> > site maintainer (or instructor in the above story) or to  
>>>> everyone (including
>>>> > his students). If the latter is true, than in theory, a student  
>>>> can engage
>>>> > a particular discussion either inline on a page where a  
>>>> vignette is
>>>> > presented, or by going into the aggregate "discussion forum"  
>>>> view.
>>>> >
>>>> > Another side note to all of this is that when a new discussion  
>>>> vignette is
>>>> > added to a page, it is then automatically pushed to the  
>>>> aggregate view and
>>>> > collected there. However, if a discussion post is added while  
>>>> in the
>>>> > aggregate view, it is NOT automatically pushed to some site  
>>>> page. This
>>>> > implies that the aggregate view can contain more discussion  
>>>> posts than might
>>>> > appear in the regular site pages. However, probably any such  
>>>> post in the
>>>> > aggregate view can be pulled into a page while the page is  
>>>> being composed.
>>>> >
>>>> > We then briefly discussed the UX question of "how might a user  
>>>> locate one of
>>>> > these aggregate views"? We touched on a few ideas, but nothing  
>>>> worth
>>>> > mentioning until we put a bit more thought into them.
>>>> >
>>>> > Also, we focused on "threaded discussion" functionality to keep  
>>>> the model
>>>> > manageable for now. None of this has been tested on other  
>>>> functional
>>>> > domains (i.e. calendar, survey, etc.) so it's hard to know if  
>>>> all of this
>>>> > will hold water once we get there.
>>>> >
>>>> > Cheers,
>>>> > Nathan
>>>> >
>>>> > --
>>>> > Nathan Pearson | UX Lead | Sakai Foundation
>>>> >
>>>> > E. [hidden email]
>>>> > M. 602.418.5092
>>>> > Y. npearson99 (Yahoo)
>>>> > S. npearson99 (Skype)
>>>> >
>>>> > http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>> >
>>>> > ________________________________
>>>> > This automatic notification message was sent by Sakai Collab
>>>> > (https://collab.sakaiproject.org//portal) from the WG:  
>>>> Authoring site.
>>>> > You can modify how you receive notifications at My Workspace >  
>>>> Preferences.
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Clay Fenlason
>>>> Director, Educational Technology
>>>> Georgia Institute of Technology
>>>> (404) 385-6644
>>>>
>>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>>> ) from the WG: Authoring site.
>>>> You can modify how you receive notifications at My Workspace >  
>>>> Preferences.
>>>>
>>>>
>>>>
>>>> --
>>>> Nathan Pearson | UX Lead | Sakai Foundation
>>>>
>>>> E. [hidden email]
>>>> M. 602.418.5092
>>>> Y npearson99 (Yahoo)
>>>> S. npearson99 (Skype)
>>>>
>>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>>
>>>>
>>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>>> ) from the WG: Authoring site.
>>>> You can modify how you receive notifications at My Workspace >  
>>>> Preferences.
>>>
>>> Daphne Ogle
>>> Senior Interaction Designer
>>> University of California, Berkeley
>>> Educational Technology Services
>>> [hidden email]
>>> cell (510)847-0308
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Nathan Pearson | UX Lead | Sakai Foundation
>>>
>>> E. [hidden email]
>>> M. 602.418.5092
>>> Y. npearson99 (Yahoo)
>>> S. npearson99 (Skype)
>>>
>>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>>>
>>>
>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>> ) from the DG: User Experience site.
>>>
>>> You can modify how you receive notifications at My Workspace >  
>>> Preferences.
>>
>> --
>>
>>
>>
>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> Oracle Academic Enterprise Solutions Group
>> 23A Glendale Road, Glendale, MA 01229
>>
>>
>>
>> --
>> Nathan Pearson | UX Lead | Sakai Foundation
>>
>> E. [hidden email]
>> M. 602.418.5092
>> Y. npearson99 (Yahoo)
>> S. npearson99 (Skype)
>>
>> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix
>
> --
>
>
>
> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229
> [see attachment: "unknown", size: 658 bytes]
>
> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>
>
> Attachments:
>
> unknown
>
>
> oracle_sig_logo.gif
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the WG: Authoring site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>
>
>
> --
> Sean Keesler
> 130 Academy Street
> Manlius, NY 13104
> 315-663-7756
>
>
>
> --
> Nathan Pearson | UX Lead | Sakai Foundation
>
> E. [hidden email]
> M. 602.418.5092
> Y. npearson99 (Yahoo)
> S. npearson99 (Skype)
>
> http://www.google.com/calendar/embed?src=kfqdgv5itkg1kl08050cu45pb8%40group.calendar.google.com&ctz=America/Phoenix

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[hidden email]
cell (510)847-0308




----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the WG: Authoring site.
You can modify how you receive notifications at My Workspace > Preferences.
123