Re: Big concept in Content Authoring

classic Classic list List threaded Threaded
11 messages Options
Jim Eng Jim Eng
Reply | Threaded
Open this post in threaded view
|

Re: Big concept in Content Authoring


I am having a hard time understanding what your point is, Michael.  Is  
it that there's something inherently wrong with the idea of trying to  
simplify page authoring in Sakai.  Or are we going about it in the  
wrong way?  If you think that what users want could be accomplished  
better or easier using some work that someone else has done, could you  
tell us more about that?  Should we suddenly have sees the light by  
looking at the ATOM pages you referenced?  Or will we need help to  
make the jump?

Jim




On Dec 15, 2008, at 1:19 PM, Michael Feldstein wrote:

> Um...I'm not sure.
>
> Are these superstrings of academic computing proven to exist in  
> sufficient quantity and variety that we are confident that the Grand  
> Unified Theory will work? In a way, what I hear you describing is  
> really sort of a REST bus. Anything that can be put at the end of a  
> URL can be put on the bus. The noun/verb distinction no longer  
> applies, as long as the whatever is URL-addressable. (It's a  
> particle! It's a wave! It's a dessert topping AND a floor wax!) But  
> are we confident that it really makes sense to mash this all into  
> one metadata format? And if so, has anyone else out in the universe  
> done any useful work on a REST bus that might be applicable?
>
> - m
>
>
> Michael Korcuska wrote:
>>
>> The talk about entities is confusing. Until it isn't.
>>
>> I think of it as something you want to refer to, or display, or  
>> manipulate (e.g. grade) in some way.  It could be a discussion post  
>> or a discussion thread. It could be an online test or an online  
>> test question or a response to an online test question. It could be  
>> an HTML page or a collection of HTML pages.   What we want is a  
>> simple way to be able to get at these things.  A nice, clean URL.  
>> A RESTful web service. The reason we've been calling them  
>> "entities" is because the Sakai service that allows you to do this  
>> in Sakai has been called the "entity broker" or the "entity service".
>>
>> And not enough of them exist yet. Sakai needs to be modified to  
>> allow more "things" to be referenced/displayed/manipulated in this  
>> way. The more of Sakai that is exposed in this fashion, the more  
>> flexibility we provide. And if we had more of Sakai exposed then  
>> the discussion would be less confusing because there would be more  
>> examples (which is what my first sentence meant).
>>
>> Did that help or hurt?
>>
>> Michael
>>
>>
>> On Dec 15, 2008, at 17:18, Michael Feldstein wrote:
>>
>>> It made a great deal of sense until I got to the sentence about  
>>> entities. Let me see if I can break out some of the pieces into  
>>> sufficient clarity that somebody can at least point to the parts  
>>> that I have wrong:
>>> We have this stuff that we colloquially refer to as "content".
>>> "Content" could be a discussion thread, a blog, a survey, a  
>>> calendar, etc.
>>> We want a mechanism access and re-use the content, regardless of  
>>> type.
>>> As part of this mechanism, we envision being able to pick  
>>> particular chunks of the content, e.g., a blog post, a survey  
>>> question, a calendar entry, etc.
>>> We speculate it may be possible to create universal packages for  
>>> content chunks. Michael K has proposed calling these (imaginary)  
>>> packages "items."
>>> We have this other stuff that we colloquially refer to as "tools".
>>> "Tools" represent bundles of related affordances for particular  
>>> types of actions, e.g., discussing, bloging, surveying,  
>>> coordinating dates and appointments, etc.
>>> We want a mechanism to access and re-use individual affordances  
>>> from the bundles, regardless of type.
>>> As part of this mechanism, we envision being able to pick  
>>> particular affordances, e.g., replying to a discussion, writing a  
>>> blog post, answering a survey question, creating a calendar entry,  
>>> etc.
>>> We speculate it may be possible to create universal packages for  
>>> action affordances. We call these packages "entities".
>>> We have still other stuff that we colloquially refer to as "web  
>>> pages".
>>> Web pages represent the user interface in which users interact  
>>> with content and affordances.
>>> We want a mechanism to access and re-use the user interface.
>>> As part of this mechanism, we envision being able to pick  
>>> particular chunks of user interface, e.g., a discussion thread  
>>> interface, a blog posting interface, a survey question interface,  
>>> a date picker interface, etc.
>>> We know it is possible to create universal packages for these UI  
>>> chunks. We call them gadgets or widgets.
>>> Items, entities, and gadgets serve analogous but very different  
>>> purposes by acting as...chunkifiers in their various domains. It  
>>> is important not to confuse them with each other. At the same  
>>> time, they can be complementary to each other. For example, one  
>>> might have a discussion thread widget calling a discussion thread  
>>> entity and displaying a particular discussion thread item at the  
>>> bottom of a page.
>>>
>>> Does that sound even remotely right?
>>>
>>> - m
>>>
>>>
>>> [hidden email] wrote:
>>>>
>>>> I'm only catching up on emails after having been on a holiday, so  
>>>> the
>>>> point I'll try to make might already have been said in emails  
>>>> which I still
>>>> need to read :).
>>>>
>>>> In my mind, the central content repository where all of the  
>>>> content is being
>>>> stored in, is completely separate from what we are trying to  
>>>> achieve in the
>>>> WYSIWYG editor. To me, there is a very big distinction between  
>>>> the content
>>>> itself (the data and its properties) and displaying active areas  
>>>> in the
>>>> WYSIWYG editor (display).
>>>>
>>>> For me it makes sense to have a central content repository where  
>>>> all of the
>>>> content is being stored as "what it is and what it contains" (I'm  
>>>> having
>>>> difficulty to explain). But I don't
>>>> necessarily want to place this piece of content in my WYSIWYG  
>>>> editor. I want
>>>> to have a view on that piece of content. One of those might be  
>>>> very close
>>>> to the content itself, but I might only want a small or  
>>>> particular part,
>>>> I might want to use it for mashup with other things, ... In other  
>>>> words,
>>>> I am very cautious for having the border between data and display  
>>>> blur
>>>> too much and end up in a too technically oriented world.
>>>>
>>>> As an example, a poll can be a piece of content, consisting out  
>>>> of the question,
>>>> the options, the answers (and the general properties as where  
>>>> being used, ...).
>>>> I might know a site with this poll, and it is really interesting  
>>>> for my
>>>> site too. I can mark this poll as being of interest to me, but  
>>>> when I come
>>>> to the point of embedding this into my site, I might not want to  
>>>> have the
>>>> entire poll in my site, as I would expect if we speak of  
>>>> embedding entities
>>>> in a site. I want to embed a view on this entity, being only the  
>>>> results for
>>>> example.
>>>>
>>>> Does that make any sense?
>>>>
>>>> Nicolaas
>>>>
>>>> > Quoting "Plourde, Mathieu" <[hidden email]>:
>>>> >
>>>> > Hi Sean,
>>>> >
>>>> > Yes, an entity should be able to contain another one. In my  
>>>> idea of what we
>>>> > are trying to achieve, anywhere a WYSIWYG editor can be use,  
>>>> and entity can
>>>> > be embedded. And if entities end up being in Resources, then  
>>>> editing that
>>>> > sub-entity shouldn't be an issue.
>>>> >
>>>> > Best Regards,
>>>> >
>>>> > =================================
>>>> >
>>>> > Mathieu Plourde, MBA
>>>> > Instructional Designer
>>>> > IT-User Services
>>>> > 021 Smith Hall
>>>> > 18 Amstel Avenue
>>>> > Newark, DE 19716
>>>> >
>>>> > Phone: 302-831-4060
>>>> > Fax: 302-831-4205
>>>> > [hidden email]<mailto:[hidden email]>
>>>> > http://copland.udel.edu/~mathieu/
>>>> >
>>>> > =================================
>>>> >
>>>> > From: Sean Keesler [mailto:[hidden email]]
>>>> > Sent: Thursday, December 11, 2008 12:59 PM
>>>> > To: Michael Korcuska
>>>> > Cc: John Norman; Content List; Sakai Developers; Nicolaas  
>>>> Matthijs; Tjhien
>>>> > Liao; Nathan Pearson
>>>> > Subject: Re: Big concept in Content Authoring
>>>> >
>>>> > Does any of the discussion include the idea that a resource/
>>>> entity would
>>>> > include one or more others?
>>>> > Sort of similar to the idea of a photo collection/album Michael
>>>> > mentions, but may also include items of different types...along  
>>>> the
>>>> > lines of a portfolio which consists of many different types of  
>>>> items
>>>> > wrapped with a set of instructions on how to display them.
>>>> >
>>>> > Sean
>>>> >
>>>> > -------------------
>>>> > Sean Keesler
>>>> > 130 Academy Street
>>>> > Manlius, NY 13104
>>>> > [hidden email]
>>>> > 315-682-0830
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > Michael Korcuska wrote:
>>>> > > I think this is what Ihave been imagining, John. A few  
>>>> comments below.
>>>> > >
>>>> > > "Resource" is a better word than entity, to be sure, but is  
>>>> loaded in
>>>> > > Sakai. I don't think I necessarily have a better one...I've  
>>>> been using
>>>> > > "item" along the way. For my money it is as generic as  
>>>> "entity" but
>>>> > > less technical sounding. But this is hardly your point.
>>>> > >
>>>> > > For browsing/finding "resources/items" I imagine one would  
>>>> want to be
>>>> > > able to filter the list of items on a variety of criteria  
>>>> including:
>>>> > >
>>>> > > * Who created it
>>>> > > * Individuals that have permission to [view/edit/delete/
>>>> whatever] it
>>>> > > * Groups that have permission to [view/edit/delete/whatever] it
>>>> > > * What content it contains (search)
>>>> > > * It's name
>>>> > > * It's tags
>>>> > > * When it was created/modified
>>>> > > * It's size
>>>> > > * The type of item/resource it is
>>>> > > * It's popularity (how often it has been accessed)
>>>> > > * Properties "unique" to the type of item (e.g. the number of  
>>>> posts in
>>>> > > a discussion thread!)
>>>> > > * What "collections" it belongs to. We haven't really talked  
>>>> about
>>>> > > the notion of a content collection but this is a common  
>>>> notion in many
>>>> > > sites that deal with lots of content (e.g. photo management  
>>>> sites)
>>>> > >
>>>> > > I'm not suggesting all these be presented to a user in a single
>>>> > > interface, but I the phrase "universal resources browser"  
>>>> suggest that
>>>> > > you intend to cast the net pretty wide. And I think an  
>>>> "advanced"
>>>> > > search or filter capability would want to include these (and  
>>>> I'm sure
>>>> > > other) criteria.
>>>> > >
>>>> > > I must admit I'm not sure what your driving at with  
>>>> Properties. Do
>>>> > > these govern how the object appears/behaves once you've found  
>>>> it and
>>>> > > put it somewhere? I can imagine finding a discussion thread,  
>>>> putting
>>>> > > it on a page I'm authoring and then setting
>>>> > > the property "DisplayFormat" to "Threaded" or "Flat". Or,  
>>>> after all, I
>>>> > > might want to simply refer to the object by URL and use the  
>>>> standard
>>>> > > href target attribute to determine how it opens. If that's  
>>>> what you
>>>> > > mean I think that's great.
>>>> > >
>>>> > > But since you raised this is in the context of a resource  
>>>> browser I
>>>> > > thought you might be imagining that these properties are used  
>>>> in the
>>>> > > process of finding the item/resource you want. If so, I'm not  
>>>> getting it.
>>>> > >
>>>> > > Michael
>>>> > >
>>>> > >
>>>> > > On Dec 11, 2008, at 16:08, John Norman wrote:
>>>> > >
>>>> > >> We have been discussing what a universal resources browser  
>>>> should look
>>>> > >> like and I have a thought that makes sense to me, but want  
>>>> to check
>>>> > >> out with a wider group.
>>>> > >>
>>>> > >> I think we should use "resource" to mean quite a wide range  
>>>> of things
>>>> > >> along the lines of Matthieu's "What should an Entity look  
>>>> like?" page
>>>> > >> ( http://confluence.sakaiproject.org/confluence/x/kQF1Ag).  
>>>> In order
>>>> > >> for this to work, I imagine we would need a number of  
>>>> resource-types,
>>>> > >> e.g. ResourceType=DiscussionThread with a defined set of  
>>>> properties
>>>> > >> (e.g. DisplayFormat=Threaded or DisplayFormat=Flat). I  
>>>> recognise that
>>>> > >> this is close to the Entity work, but I feel it is more  
>>>> accessible
>>>> > >> language. One ResourceType might be "File" with a property  
>>>> "Open in
>>>> > >> New Window". A resource browser for a site or for someone  
>>>> looking
>>>> > >> across a number of sites would then include ResourceType as an
>>>> > >> orderable or filterable field so you could ask for all the  
>>>> assignments
>>>> > >> in Physics101 or all the assignments in First Year  
>>>> Engineering Courses.
>>>> > >>
>>>> > >> I'd like to start modifying Matthieu's page along these  
>>>> lines, but
>>>> > >> wanted to make sure others think this makes sense before  
>>>> going too far.
>>>> > >>
>>>> > >> John
>>>> > >>  
>>>> ------------------------------------------------------------------------
>>>> > >>
>>>> > >> 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.
>>>> > >
>>>> > > --
>>>> > > Michael Korcuska
>>>> > > Executive Director, Sakai Foundation
>>>> > > [hidden email]
>>>> >
>>>> <mailto:[hidden email]><mailto:[hidden email]%3e
>>>> >
>>>> > > phone: +1 510-931-6559
>>>> > > mobile (US): +1 510-599-2586
>>>> > > mobile (FR): +33 (0)6 31 11 58 97
>>>> > > skype: mkorcuska
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >  
>>>> ------------------------------------------------------------------------
>>>> > >
>>>> > > 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.
>>>> > ________________________________
>>>> >
>>>> > 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.
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------
>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>
>>>>
>>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>>> ) from the DG: Development (a.k.a. sakai-dev) site.
>>>> You can modify how you receive notifications at My Workspace >  
>>>> Preferences.
>>>
>>> --
>>>
>>>
>>> <oracle_sig_logo.gif>
>>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>> Oracle Academic Enterprise Solutions Group
>>> 23A Glendale Road, Glendale, MA 01229
>>
>> --
>> Michael Korcuska
>> Executive Director, Sakai Foundation
>> [hidden email]
>> phone: +1 510-931-6559
>> mobile (US): +1 510-599-2586
>> mobile (FR): +33 (0)6 31 11 58 97
>> skype: mkorcuska
>>
>>
>>
>>
>>
>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>> ) from the DG: Development (a.k.a. sakai-dev) 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
> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>
>
> Attachments:
>
> oracle_sig_logo.gif
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Development (a.k.a. sakai-dev) 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: Big concept in Content Authoring


No, I am absolutely not claiming to have an answer. Rather, I'm trying
to understand what the question is. A lot of what's described in
Confluence doesn't (in my mind, anyway) /simplify/ page authoring. It
/enriches/ it in a way that we hope will seem simple to the users. But I
don't get how the plan is supposed to work. I'm just throwing Atom and
Atom Publishing out as straw men. They exist and are widely adopted. If
we can quantify the gap between these existing capabilities and what is
envisioned in Sakai, then we can know (a) if something that already
exists is fit to task, (b) if something that already exists is close but
needs to be extended, or (c) if the Sakai community really does need to
go its own way and invent something new.

I'm just looking to a gap analysis as one way to understand what you're
trying to accomplish.

- m


Jim Eng wrote:

> I am having a hard time understanding what your point is, Michael.  Is
> it that there's something inherently wrong with the idea of trying to
> simplify page authoring in Sakai.  Or are we going about it in the
> wrong way?  If you think that what users want could be accomplished
> better or easier using some work that someone else has done, could you
> tell us more about that?  Should we suddenly have sees the light by
> looking at the ATOM pages you referenced?  Or will we need help to
> make the jump?  
>
> Jim
>
>
>
>
> On Dec 15, 2008, at 1:19 PM, Michael Feldstein wrote:
>
>> Um...I'm not sure.
>>
>> Are these superstrings of academic computing proven to exist in
>> sufficient quantity and variety that we are confident that the Grand
>> Unified Theory will work? In a way, what I hear you describing is
>> really sort of a REST bus. Anything that can be put at the end of a
>> URL can be put on the bus. The noun/verb distinction no longer
>> applies, as long as the whatever is URL-addressable. (It's a
>> particle! It's a wave! It's a dessert topping AND a floor wax!) But
>> are we confident that it really makes sense to mash this all into one
>> metadata format? And if so, has anyone else out in the universe done
>> any useful work on a REST bus that might be applicable?
>>
>> - m
>>
>>
>> Michael Korcuska wrote:
>>> The talk about entities is confusing. Until it isn't.
>>>
>>> I think of it as something you want to refer to, or display, or
>>> manipulate (e.g. grade) in some way.  It could be a discussion post
>>> or a discussion thread. It could be an online test or an online test
>>> question or a response to an online test question. It could be an
>>> HTML page or a collection of HTML pages.   What we want is a simple
>>> way to be able to get at these things.  A nice, clean URL.  A
>>> RESTful web service. The reason we've been calling them "entities"
>>> is because the Sakai service that allows you to do this in Sakai has
>>> been called the "entity broker" or the "entity service".
>>>
>>> And not enough of them exist yet. Sakai needs to be modified to
>>> allow more "things" to be referenced/displayed/manipulated in this
>>> way. The more of Sakai that is exposed in this fashion, the more
>>> flexibility we provide. And if we had more of Sakai exposed then the
>>> discussion would be less confusing because there would be more
>>> examples (which is what my first sentence meant).
>>>
>>> Did that help or hurt?
>>>
>>> Michael
>>>
>>>
>>> On Dec 15, 2008, at 17:18, Michael Feldstein wrote:
>>>
>>>> It made a great deal of sense until I got to the sentence about
>>>> entities. Let me see if I can break out some of the pieces into
>>>> sufficient clarity that somebody can at least point to the parts
>>>> that I have wrong:
>>>>
>>>>     * We have this stuff that we colloquially refer to as "content".
>>>>           o "Content" could be a discussion thread, a blog, a
>>>>             survey, a calendar, etc.
>>>>           o We want a mechanism access and re-use the content,
>>>>             regardless of type.
>>>>           o As part of this mechanism, we envision being able to
>>>>             pick particular chunks of the content, e.g., a blog
>>>>             post, a survey question, a calendar entry, etc.
>>>>           o We speculate it may be possible to create universal
>>>>             packages for content chunks. Michael K has proposed
>>>>             calling these (imaginary) packages "items."
>>>>     * We have this other stuff that we colloquially refer to as
>>>>       "tools".
>>>>           o "Tools" represent bundles of related affordances for
>>>>             particular types of actions, e.g., discussing, bloging,
>>>>             surveying, coordinating dates and appointments, etc.
>>>>           o We want a mechanism to access and re-use individual
>>>>             affordances from the bundles, regardless of type.
>>>>           o As part of this mechanism, we envision being able to
>>>>             pick particular affordances, e.g., replying to a
>>>>             discussion, writing a blog post, answering a survey
>>>>             question, creating a calendar entry, etc.
>>>>           o We speculate it may be possible to create universal
>>>>             packages for action affordances. We call these packages
>>>>             "entities".
>>>>     * We have still other stuff that we colloquially refer to as
>>>>       "web pages".
>>>>           o Web pages represent the user interface in which users
>>>>             interact with content and affordances.
>>>>           o We want a mechanism to access and re-use the user
>>>>             interface.
>>>>           o As part of this mechanism, we envision being able to
>>>>             pick particular chunks of user interface, e.g., a
>>>>             discussion thread interface, a blog posting interface,
>>>>             a survey question interface, a date picker interface, etc.
>>>>           o We know it is possible to create universal packages for
>>>>             these UI chunks. We call them gadgets or widgets.
>>>>
>>>> Items, entities, and gadgets serve analogous but very different
>>>> purposes by acting as...chunkifiers in their various domains. It is
>>>> important not to confuse them with each other. At the same time,
>>>> they can be complementary to each other. For example, one might
>>>> have a discussion thread widget calling a discussion thread entity
>>>> and displaying a particular discussion thread item at the bottom of
>>>> a page.
>>>>
>>>> Does that sound even remotely right?
>>>>
>>>> - m
>>>>
>>>>
>>>> [hidden email] wrote:
>>>>> I'm only catching up on emails after having been on a holiday, so the
>>>>> point I'll try to make might already have been said in emails
>>>>> which I still
>>>>> need to read :).
>>>>>
>>>>> In my mind, the central content repository where all of the
>>>>> content is being
>>>>> stored in, is completely separate from what we are trying to
>>>>> achieve in the
>>>>> WYSIWYG editor. To me, there is a very big distinction between the
>>>>> content
>>>>> itself (the data and its properties) and displaying active areas
>>>>> in the
>>>>> WYSIWYG editor (display).
>>>>>
>>>>> For me it makes sense to have a central content repository where
>>>>> all of the
>>>>> content is being stored as "what it is and what it contains" (I'm
>>>>> having
>>>>> difficulty to explain). But I don't
>>>>> necessarily want to place this piece of content in my WYSIWYG
>>>>> editor. I want
>>>>> to have a view on that piece of content. One of those might be
>>>>> very close
>>>>> to the content itself, but I might only want a small or particular
>>>>> part,
>>>>> I might want to use it for mashup with other things, ... In other
>>>>> words,
>>>>> I am very cautious for having the border between data and display
>>>>> blur
>>>>> too much and end up in a too technically oriented world.
>>>>>
>>>>> As an example, a poll can be a piece of content, consisting out of
>>>>> the question,
>>>>> the options, the answers (and the general properties as where
>>>>> being used, ...).
>>>>> I might know a site with this poll, and it is really interesting
>>>>> for my
>>>>> site too. I can mark this poll as being of interest to me, but
>>>>> when I come
>>>>> to the point of embedding this into my site, I might not want to
>>>>> have the
>>>>> entire poll in my site, as I would expect if we speak of embedding
>>>>> entities
>>>>> in a site. I want to embed a view on this entity, being only the
>>>>> results for
>>>>> example.
>>>>>
>>>>> Does that make any sense?
>>>>>
>>>>> Nicolaas
>>>>>
>>>>> > Quoting "Plourde, Mathieu" <[hidden email]>:
>>>>> >
>>>>> > Hi Sean,
>>>>> >
>>>>> > Yes, an entity should be able to contain another one. In my idea
>>>>> of what we
>>>>> > are trying to achieve, anywhere a WYSIWYG editor can be use, and
>>>>> entity can
>>>>> > be embedded. And if entities end up being in Resources, then
>>>>> editing that
>>>>> > sub-entity shouldn't be an issue.
>>>>> >
>>>>> > Best Regards,
>>>>> >
>>>>> > =================================
>>>>> >
>>>>> > Mathieu Plourde, MBA
>>>>> > Instructional Designer
>>>>> > IT-User Services
>>>>> > 021 Smith Hall
>>>>> > 18 Amstel Avenue
>>>>> > Newark, DE 19716
>>>>> >
>>>>> > Phone: 302-831-4060
>>>>> > Fax: 302-831-4205
>>>>> > [hidden email]<mailto:[hidden email]>
>>>>> <mailto:[hidden email]%3E>
>>>>> > http://copland.udel.edu/~mathieu/ 
>>>>> <http://copland.udel.edu/%7Emathieu/>
>>>>> >
>>>>> > =================================
>>>>> >
>>>>> > From: Sean Keesler [mailto:[hidden email]]
>>>>> > Sent: Thursday, December 11, 2008 12:59 PM
>>>>> > To: Michael Korcuska
>>>>> > Cc: John Norman; Content List; Sakai Developers; Nicolaas
>>>>> Matthijs; Tjhien
>>>>> > Liao; Nathan Pearson
>>>>> > Subject: Re: Big concept in Content Authoring
>>>>> >
>>>>> > Does any of the discussion include the idea that a
>>>>> resource/entity would
>>>>> > include one or more others?
>>>>> > Sort of similar to the idea of a photo collection/album Michael
>>>>> > mentions, but may also include items of different types...along the
>>>>> > lines of a portfolio which consists of many different types of
>>>>> items
>>>>> > wrapped with a set of instructions on how to display them.
>>>>> >
>>>>> > Sean
>>>>> >
>>>>> > -------------------
>>>>> > Sean Keesler
>>>>> > 130 Academy Street
>>>>> > Manlius, NY 13104
>>>>> > [hidden email]
>>>>> > 315-682-0830
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > Michael Korcuska wrote:
>>>>> > > I think this is what Ihave been imagining, John. A few
>>>>> comments below.
>>>>> > >
>>>>> > > "Resource" is a better word than entity, to be sure, but is
>>>>> loaded in
>>>>> > > Sakai. I don't think I necessarily have a better one...I've
>>>>> been using
>>>>> > > "item" along the way. For my money it is as generic as
>>>>> "entity" but
>>>>> > > less technical sounding. But this is hardly your point.
>>>>> > >
>>>>> > > For browsing/finding "resources/items" I imagine one would
>>>>> want to be
>>>>> > > able to filter the list of items on a variety of criteria
>>>>> including:
>>>>> > >
>>>>> > > * Who created it
>>>>> > > * Individuals that have permission to
>>>>> [view/edit/delete/whatever] it
>>>>> > > * Groups that have permission to [view/edit/delete/whatever] it
>>>>> > > * What content it contains (search)
>>>>> > > * It's name
>>>>> > > * It's tags
>>>>> > > * When it was created/modified
>>>>> > > * It's size
>>>>> > > * The type of item/resource it is
>>>>> > > * It's popularity (how often it has been accessed)
>>>>> > > * Properties "unique" to the type of item (e.g. the number of
>>>>> posts in
>>>>> > > a discussion thread!)
>>>>> > > * What "collections" it belongs to. We haven't really talked
>>>>> about
>>>>> > > the notion of a content collection but this is a common notion
>>>>> in many
>>>>> > > sites that deal with lots of content (e.g. photo management
>>>>> sites)
>>>>> > >
>>>>> > > I'm not suggesting all these be presented to a user in a single
>>>>> > > interface, but I the phrase "universal resources browser"
>>>>> suggest that
>>>>> > > you intend to cast the net pretty wide. And I think an "advanced"
>>>>> > > search or filter capability would want to include these (and
>>>>> I'm sure
>>>>> > > other) criteria.
>>>>> > >
>>>>> > > I must admit I'm not sure what your driving at with
>>>>> Properties. Do
>>>>> > > these govern how the object appears/behaves once you've found
>>>>> it and
>>>>> > > put it somewhere? I can imagine finding a discussion thread,
>>>>> putting
>>>>> > > it on a page I'm authoring and then setting
>>>>> > > the property "DisplayFormat" to "Threaded" or "Flat". Or,
>>>>> after all, I
>>>>> > > might want to simply refer to the object by URL and use the
>>>>> standard
>>>>> > > href target attribute to determine how it opens. If that's
>>>>> what you
>>>>> > > mean I think that's great.
>>>>> > >
>>>>> > > But since you raised this is in the context of a resource
>>>>> browser I
>>>>> > > thought you might be imagining that these properties are used
>>>>> in the
>>>>> > > process of finding the item/resource you want. If so, I'm not
>>>>> getting it.
>>>>> > >
>>>>> > > Michael
>>>>> > >
>>>>> > >
>>>>> > > On Dec 11, 2008, at 16:08, John Norman wrote:
>>>>> > >
>>>>> > >> We have been discussing what a universal resources browser
>>>>> should look
>>>>> > >> like and I have a thought that makes sense to me, but want to
>>>>> check
>>>>> > >> out with a wider group.
>>>>> > >>
>>>>> > >> I think we should use "resource" to mean quite a wide range
>>>>> of things
>>>>> > >> along the lines of Matthieu's "What should an Entity look
>>>>> like?" page
>>>>> > >> ( http://confluence.sakaiproject.org/confluence/x/kQF1Ag). In
>>>>> order
>>>>> > >> for this to work, I imagine we would need a number of
>>>>> resource-types,
>>>>> > >> e.g. ResourceType=DiscussionThread with a defined set of
>>>>> properties
>>>>> > >> (e.g. DisplayFormat=Threaded or DisplayFormat=Flat). I
>>>>> recognise that
>>>>> > >> this is close to the Entity work, but I feel it is more
>>>>> accessible
>>>>> > >> language. One ResourceType might be "File" with a property
>>>>> "Open in
>>>>> > >> New Window". A resource browser for a site or for someone
>>>>> looking
>>>>> > >> across a number of sites would then include ResourceType as an
>>>>> > >> orderable or filterable field so you could ask for all the
>>>>> assignments
>>>>> > >> in Physics101 or all the assignments in First Year
>>>>> Engineering Courses.
>>>>> > >>
>>>>> > >> I'd like to start modifying Matthieu's page along these
>>>>> lines, but
>>>>> > >> wanted to make sure others think this makes sense before
>>>>> going too far.
>>>>> > >>
>>>>> > >> John
>>>>> > >>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> > >>
>>>>> > >> This automatic notification message was sent by Sakai Collab
>>>>> > >>
>>>>> >
>>>>> (https://collab.sakaiproject.org//portal<https://collab.sakaiproject.org/portal>
>>>>> <https://collab.sakaiproject.org//portal%3Chttps://collab.sakaiproject.org/portal%3E>)
>>>>>
>>>>> > from the WG: Authoring site.
>>>>> > >> You can modify how you receive notifications at My Workspace >
>>>>> > >> Preferences.
>>>>> > >
>>>>> > > --
>>>>> > > Michael Korcuska
>>>>> > > Executive Director, Sakai Foundation
>>>>> > > [hidden email]
>>>>> >
>>>>> <mailto:[hidden email]><mailto:[hidden email]%3e>
>>>>> <mailto:[hidden email]%3E%3Cmailto:[hidden email]%3e%3E>
>>>>>
>>>>> > > phone: +1 510-931-6559
>>>>> > > mobile (US): +1 510-599-2586
>>>>> > > mobile (FR): +33 (0)6 31 11 58 97
>>>>> > > skype: mkorcuska
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> > >
>>>>> > > This automatic notification message was sent by Sakai Collab
>>>>> > >
>>>>> >
>>>>> (https://collab.sakaiproject.org//portal<https://collab.sakaiproject.org/portal>
>>>>> <https://collab.sakaiproject.org//portal%3Chttps://collab.sakaiproject.org/portal%3E>)
>>>>>
>>>>> > 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<https://collab.sakaiproject.org/portal>
>>>>> <https://collab.sakaiproject.org//portal%3Chttps://collab.sakaiproject.org/portal%3E>)
>>>>>
>>>>> > from the WG: Authoring site.
>>>>> > You can modify how you receive notifications at My Workspace >
>>>>> Preferences.
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> This automatic notification message was sent by Sakai Collab
>>>>> (https://collab.sakaiproject.org//portal) from the DG: Development
>>>>> (a.k.a. sakai-dev) site.
>>>>> You can modify how you receive notifications at My Workspace >
>>>>> Preferences.
>>>>
>>>> --
>>>>
>>>>
>>>> <oracle_sig_logo.gif> <http://www.oracle.com>
>>>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>>> Oracle Academic Enterprise Solutions Group
>>>> 23A Glendale Road, Glendale, MA 01229
>>>
>>> --
>>> Michael Korcuska
>>> Executive Director, Sakai Foundation
>>> [hidden email] <mailto:[hidden email]>
>>> phone: +1 510-931-6559
>>> mobile (US): +1 510-599-2586
>>> mobile (FR): +33 (0)6 31 11 58 97
>>> skype: mkorcuska
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org//portal) from the DG: Development
>>> (a.k.a. sakai-dev) 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/a108f1b3-0840-4371-b11e-af0ca298271d/oracle_sig_logo.gif>
>>
>> ------------------------------------------------------------------------
>>
>> This automatic notification message was sent by Sakai Collab
>> (https://collab.sakaiproject.org//portal) from the DG: Development
>> (a.k.a. sakai-dev) 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/1f09e836-316e-4f14-8018-a0efe537e477/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: Big concept in Content Authoring

In reply to this post by Jim Eng

I'll add that John is absolutely right that we have some real confusion
about developer talk versus user talk. I'm sure I am contributing to it.
The reason I jumped into all of this in the first place is that I sensed
the conversation was beginning to define a model for the technical
implementation, and that really confused me. If I was wrong about that,
then this would turn out to be a very good opportunity to shut up now.

- m


Jim Eng wrote:

> I am having a hard time understanding what your point is, Michael.  Is
> it that there's something inherently wrong with the idea of trying to
> simplify page authoring in Sakai.  Or are we going about it in the
> wrong way?  If you think that what users want could be accomplished
> better or easier using some work that someone else has done, could you
> tell us more about that?  Should we suddenly have sees the light by
> looking at the ATOM pages you referenced?  Or will we need help to
> make the jump?  
>
> Jim
>
>
>
>
> On Dec 15, 2008, at 1:19 PM, Michael Feldstein wrote:
>
>> Um...I'm not sure.
>>
>> Are these superstrings of academic computing proven to exist in
>> sufficient quantity and variety that we are confident that the Grand
>> Unified Theory will work? In a way, what I hear you describing is
>> really sort of a REST bus. Anything that can be put at the end of a
>> URL can be put on the bus. The noun/verb distinction no longer
>> applies, as long as the whatever is URL-addressable. (It's a
>> particle! It's a wave! It's a dessert topping AND a floor wax!) But
>> are we confident that it really makes sense to mash this all into one
>> metadata format? And if so, has anyone else out in the universe done
>> any useful work on a REST bus that might be applicable?
>>
>> - m
>>
>>
>> Michael Korcuska wrote:
>>> The talk about entities is confusing. Until it isn't.
>>>
>>> I think of it as something you want to refer to, or display, or
>>> manipulate (e.g. grade) in some way.  It could be a discussion post
>>> or a discussion thread. It could be an online test or an online test
>>> question or a response to an online test question. It could be an
>>> HTML page or a collection of HTML pages.   What we want is a simple
>>> way to be able to get at these things.  A nice, clean URL.  A
>>> RESTful web service. The reason we've been calling them "entities"
>>> is because the Sakai service that allows you to do this in Sakai has
>>> been called the "entity broker" or the "entity service".
>>>
>>> And not enough of them exist yet. Sakai needs to be modified to
>>> allow more "things" to be referenced/displayed/manipulated in this
>>> way. The more of Sakai that is exposed in this fashion, the more
>>> flexibility we provide. And if we had more of Sakai exposed then the
>>> discussion would be less confusing because there would be more
>>> examples (which is what my first sentence meant).
>>>
>>> Did that help or hurt?
>>>
>>> Michael
>>>
>>>
>>> On Dec 15, 2008, at 17:18, Michael Feldstein wrote:
>>>
>>>> It made a great deal of sense until I got to the sentence about
>>>> entities. Let me see if I can break out some of the pieces into
>>>> sufficient clarity that somebody can at least point to the parts
>>>> that I have wrong:
>>>>
>>>>     * We have this stuff that we colloquially refer to as "content".
>>>>           o "Content" could be a discussion thread, a blog, a
>>>>             survey, a calendar, etc.
>>>>           o We want a mechanism access and re-use the content,
>>>>             regardless of type.
>>>>           o As part of this mechanism, we envision being able to
>>>>             pick particular chunks of the content, e.g., a blog
>>>>             post, a survey question, a calendar entry, etc.
>>>>           o We speculate it may be possible to create universal
>>>>             packages for content chunks. Michael K has proposed
>>>>             calling these (imaginary) packages "items."
>>>>     * We have this other stuff that we colloquially refer to as
>>>>       "tools".
>>>>           o "Tools" represent bundles of related affordances for
>>>>             particular types of actions, e.g., discussing, bloging,
>>>>             surveying, coordinating dates and appointments, etc.
>>>>           o We want a mechanism to access and re-use individual
>>>>             affordances from the bundles, regardless of type.
>>>>           o As part of this mechanism, we envision being able to
>>>>             pick particular affordances, e.g., replying to a
>>>>             discussion, writing a blog post, answering a survey
>>>>             question, creating a calendar entry, etc.
>>>>           o We speculate it may be possible to create universal
>>>>             packages for action affordances. We call these packages
>>>>             "entities".
>>>>     * We have still other stuff that we colloquially refer to as
>>>>       "web pages".
>>>>           o Web pages represent the user interface in which users
>>>>             interact with content and affordances.
>>>>           o We want a mechanism to access and re-use the user
>>>>             interface.
>>>>           o As part of this mechanism, we envision being able to
>>>>             pick particular chunks of user interface, e.g., a
>>>>             discussion thread interface, a blog posting interface,
>>>>             a survey question interface, a date picker interface, etc.
>>>>           o We know it is possible to create universal packages for
>>>>             these UI chunks. We call them gadgets or widgets.
>>>>
>>>> Items, entities, and gadgets serve analogous but very different
>>>> purposes by acting as...chunkifiers in their various domains. It is
>>>> important not to confuse them with each other. At the same time,
>>>> they can be complementary to each other. For example, one might
>>>> have a discussion thread widget calling a discussion thread entity
>>>> and displaying a particular discussion thread item at the bottom of
>>>> a page.
>>>>
>>>> Does that sound even remotely right?
>>>>
>>>> - m
>>>>
>>>>
>>>> [hidden email] wrote:
>>>>> I'm only catching up on emails after having been on a holiday, so the
>>>>> point I'll try to make might already have been said in emails
>>>>> which I still
>>>>> need to read :).
>>>>>
>>>>> In my mind, the central content repository where all of the
>>>>> content is being
>>>>> stored in, is completely separate from what we are trying to
>>>>> achieve in the
>>>>> WYSIWYG editor. To me, there is a very big distinction between the
>>>>> content
>>>>> itself (the data and its properties) and displaying active areas
>>>>> in the
>>>>> WYSIWYG editor (display).
>>>>>
>>>>> For me it makes sense to have a central content repository where
>>>>> all of the
>>>>> content is being stored as "what it is and what it contains" (I'm
>>>>> having
>>>>> difficulty to explain). But I don't
>>>>> necessarily want to place this piece of content in my WYSIWYG
>>>>> editor. I want
>>>>> to have a view on that piece of content. One of those might be
>>>>> very close
>>>>> to the content itself, but I might only want a small or particular
>>>>> part,
>>>>> I might want to use it for mashup with other things, ... In other
>>>>> words,
>>>>> I am very cautious for having the border between data and display
>>>>> blur
>>>>> too much and end up in a too technically oriented world.
>>>>>
>>>>> As an example, a poll can be a piece of content, consisting out of
>>>>> the question,
>>>>> the options, the answers (and the general properties as where
>>>>> being used, ..).
>>>>> I might know a site with this poll, and it is really interesting
>>>>> for my
>>>>> site too. I can mark this poll as being of interest to me, but
>>>>> when I come
>>>>> to the point of embedding this into my site, I might not want to
>>>>> have the
>>>>> entire poll in my site, as I would expect if we speak of embedding
>>>>> entities
>>>>> in a site. I want to embed a view on this entity, being only the
>>>>> results for
>>>>> example.
>>>>>
>>>>> Does that make any sense?
>>>>>
>>>>> Nicolaas
>>>>>
>>>>> > Quoting "Plourde, Mathieu" <[hidden email]>:
>>>>> >
>>>>> > Hi Sean,
>>>>> >
>>>>> > Yes, an entity should be able to contain another one. In my idea
>>>>> of what we
>>>>> > are trying to achieve, anywhere a WYSIWYG editor can be use, and
>>>>> entity can
>>>>> > be embedded. And if entities end up being in Resources, then
>>>>> editing that
>>>>> > sub-entity shouldn't be an issue.
>>>>> >
>>>>> > Best Regards,
>>>>> >
>>>>> > =================================
>>>>> >
>>>>> > Mathieu Plourde, MBA
>>>>> > Instructional Designer
>>>>> > IT-User Services
>>>>> > 021 Smith Hall
>>>>> > 18 Amstel Avenue
>>>>> > Newark, DE 19716
>>>>> >
>>>>> > Phone: 302-831-4060
>>>>> > Fax: 302-831-4205
>>>>> > [hidden email]<mailto:[hidden email]>
>>>>> <mailto:[hidden email]%3E>
>>>>> > http://copland.udel.edu/~mathieu/ 
>>>>> <http://copland.udel.edu/%7Emathieu/>
>>>>> >
>>>>> > =================================
>>>>> >
>>>>> > From: Sean Keesler [mailto:[hidden email]]
>>>>> > Sent: Thursday, December 11, 2008 12:59 PM
>>>>> > To: Michael Korcuska
>>>>> > Cc: John Norman; Content List; Sakai Developers; Nicolaas
>>>>> Matthijs; Tjhien
>>>>> > Liao; Nathan Pearson
>>>>> > Subject: Re: Big concept in Content Authoring
>>>>> >
>>>>> > Does any of the discussion include the idea that a
>>>>> resource/entity would
>>>>> > include one or more others?
>>>>> > Sort of similar to the idea of a photo collection/album Michael
>>>>> > mentions, but may also include items of different types...along the
>>>>> > lines of a portfolio which consists of many different types of
>>>>> items
>>>>> > wrapped with a set of instructions on how to display them.
>>>>> >
>>>>> > Sean
>>>>> >
>>>>> > -------------------
>>>>> > Sean Keesler
>>>>> > 130 Academy Street
>>>>> > Manlius, NY 13104
>>>>> > [hidden email]
>>>>> > 315-682-0830
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > Michael Korcuska wrote:
>>>>> > > I think this is what Ihave been imagining, John. A few
>>>>> comments below.
>>>>> > >
>>>>> > > "Resource" is a better word than entity, to be sure, but is
>>>>> loaded in
>>>>> > > Sakai. I don't think I necessarily have a better one...I've
>>>>> been using
>>>>> > > "item" along the way. For my money it is as generic as
>>>>> "entity" but
>>>>> > > less technical sounding. But this is hardly your point.
>>>>> > >
>>>>> > > For browsing/finding "resources/items" I imagine one would
>>>>> want to be
>>>>> > > able to filter the list of items on a variety of criteria
>>>>> including:
>>>>> > >
>>>>> > > * Who created it
>>>>> > > * Individuals that have permission to
>>>>> [view/edit/delete/whatever] it
>>>>> > > * Groups that have permission to [view/edit/delete/whatever] it
>>>>> > > * What content it contains (search)
>>>>> > > * It's name
>>>>> > > * It's tags
>>>>> > > * When it was created/modified
>>>>> > > * It's size
>>>>> > > * The type of item/resource it is
>>>>> > > * It's popularity (how often it has been accessed)
>>>>> > > * Properties "unique" to the type of item (e.g. the number of
>>>>> posts in
>>>>> > > a discussion thread!)
>>>>> > > * What "collections" it belongs to. We haven't really talked
>>>>> about
>>>>> > > the notion of a content collection but this is a common notion
>>>>> in many
>>>>> > > sites that deal with lots of content (e.g. photo management
>>>>> sites)
>>>>> > >
>>>>> > > I'm not suggesting all these be presented to a user in a single
>>>>> > > interface, but I the phrase "universal resources browser"
>>>>> suggest that
>>>>> > > you intend to cast the net pretty wide. And I think an "advanced"
>>>>> > > search or filter capability would want to include these (and
>>>>> I'm sure
>>>>> > > other) criteria.
>>>>> > >
>>>>> > > I must admit I'm not sure what your driving at with
>>>>> Properties. Do
>>>>> > > these govern how the object appears/behaves once you've found
>>>>> it and
>>>>> > > put it somewhere? I can imagine finding a discussion thread,
>>>>> putting
>>>>> > > it on a page I'm authoring and then setting
>>>>> > > the property "DisplayFormat" to "Threaded" or "Flat". Or,
>>>>> after all, I
>>>>> > > might want to simply refer to the object by URL and use the
>>>>> standard
>>>>> > > href target attribute to determine how it opens. If that's
>>>>> what you
>>>>> > > mean I think that's great.
>>>>> > >
>>>>> > > But since you raised this is in the context of a resource
>>>>> browser I
>>>>> > > thought you might be imagining that these properties are used
>>>>> in the
>>>>> > > process of finding the item/resource you want. If so, I'm not
>>>>> getting it.
>>>>> > >
>>>>> > > Michael
>>>>> > >
>>>>> > >
>>>>> > > On Dec 11, 2008, at 16:08, John Norman wrote:
>>>>> > >
>>>>> > >> We have been discussing what a universal resources browser
>>>>> should look
>>>>> > >> like and I have a thought that makes sense to me, but want to
>>>>> check
>>>>> > >> out with a wider group.
>>>>> > >>
>>>>> > >> I think we should use "resource" to mean quite a wide range
>>>>> of things
>>>>> > >> along the lines of Matthieu's "What should an Entity look
>>>>> like?" page
>>>>> > >> ( http://confluence.sakaiproject.org/confluence/x/kQF1Ag). In
>>>>> order
>>>>> > >> for this to work, I imagine we would need a number of
>>>>> resource-types,
>>>>> > >> e.g. ResourceType=DiscussionThread with a defined set of
>>>>> properties
>>>>> > >> (e.g. DisplayFormat=Threaded or DisplayFormat=Flat). I
>>>>> recognise that
>>>>> > >> this is close to the Entity work, but I feel it is more
>>>>> accessible
>>>>> > >> language One ResourceType might be "File" with a property
>>>>> "Open in
>>>>> > >> New Window". A resource browser for a site or for someone
>>>>> looking
>>>>> > >> across a number of sites would then include ResourceType as an
>>>>> > >> orderable or filterable field so you could ask for all the
>>>>> assignments
>>>>> > >> in Physics101 or all the assignments in First Year
>>>>> Engineering Courses.
>>>>> > >>
>>>>> > >> I'd like to start modifying Matthieu's page along these
>>>>> lines, but
>>>>> > >> wanted to make sure others think this makes sense before
>>>>> going too far.
>>>>> > >>
>>>>> > >> John
>>>>> > >>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> > >>
>>>>> > >> This automatic notification message was sent by Sakai Collab
>>>>> > >>
>>>>> >
>>>>> (https://collab.sakaiproject.org//portal<https://collab.sakaiproject.org/portal>
>>>>> <https://collab.sakaiproject.org//portal%3Chttps://collab.sakaiproject.org/portal%3E>)
>>>>>
>>>>> > from the WG: Authoring site.
>>>>> > >> You can modify how you receive notifications at My Workspace >
>>>>> > >> Preferences.
>>>>> > >
>>>>> > > --
>>>>> > > Michael Korcuska
>>>>> > > Executive Director, Sakai Foundation
>>>>> > > [hidden email]
>>>>> >
>>>>> <mailto:[hidden email]><mailto:[hidden email]%3e>
>>>>> <mailto:[hidden email]%3E%3Cmailto:[hidden email]%3e%3E>
>>>>>
>>>>> > > phone: +1 510-931-6559
>>>>> > > mobile (US): +1 510-599-2586
>>>>> > > mobile (FR): +33 (0)6 31 11 58 97
>>>>> > > skype: mkorcuska
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> > >
>>>>> > > This automatic notification message was sent by Sakai Collab
>>>>> > >
>>>>> >
>>>>> (https://collab.sakaiproject.org//portal<https://collab.sakaiproject.org/portal>
>>>>> <https://collab.sakaiproject.org//portal%3Chttps://collab.sakaiproject.org/portal%3E>)
>>>>>
>>>>> > 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<https://collab.sakaiproject.org/portal>
>>>>> <https://collab.sakaiproject.org//portal%3Chttps://collab.sakaiproject.org/portal%3E>)
>>>>>
>>>>> > from the WG: Authoring site.
>>>>> > You can modify how you receive notifications at My Workspace >
>>>>> Preferences.
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> This automatic notification message was sent by Sakai Collab
>>>>> (https://collab.sakaiproject.org//portal) from the DG: Development
>>>>> (a.k.a. sakai-dev) site.
>>>>> You can modify how you receive notifications at My Workspace >
>>>>> Preferences.
>>>>
>>>> --
>>>>
>>>>
>>>> <oracle_sig_logo.gif> <http://wwworacle.com>
>>>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>>> Oracle Academic Enterprise Solutions Group
>>>> 23A Glendale Road, Glendale, MA 01229
>>>
>>> --
>>> Michael Korcuska
>>> Executive Director, Sakai Foundation
>>> [hidden email] <mailto:[hidden email]>
>>> phone: +1 510-931-6559
>>> mobile (US): +1 510-599-2586
>>> mobile (FR): +33 (0)6 31 11 58 97
>>> skype: mkorcuska
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> This automatic notification message was sent by Sakai Collab
>>> (https://collab.sakaiproject.org//portal) from the DG: Development
>>> (a.k.a. sakai-dev) 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
>>
>> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>>
>>
>> Attachments:
>>
>> oracle_sig_logo.gif
>> <https://collab.sakaiproject.org//access/content/attachment/a108f1b3-0840-4371-b11e-af0ca298271d/oracle_sig_logo.gif>
>>
>> ------------------------------------------------------------------------
>>
>> This automatic notification message was sent by Sakai Collab
>> (https://collab.sakaiproject.org//portal) from the DG: Development
>> (a.k.a. sakai-dev) 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: Development
> (a.k.a. sakai-dev) 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/0db1fa13-366c-4660-858c-5b38b0af9691/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.
Jim Eng Jim Eng
Reply | Threaded
Open this post in threaded view
|

Re: Big concept in Content Authoring

In reply to this post by Michael Feldstein

My mistake.  You're absolutely correct that we're talking about more  
than "simplifying" page authoring.  There are already ways to  
accomplish some of what we are trying to enable, but those workarounds  
are so difficult that most of it is better described as "enabling",  
rather than "simplifying" or "enriching".

A case in point:  The simple act of creating a page and making it  
appear in Sakai is hard.  You would have to create an HTML page in the  
resources tool, copy the access URL, and then add the page at the top  
level by pasting that access URL into the web content tool.  That's so  
convoluted, that we can say the capability never existed.  And it's  
even more clear that I should have said "enabling" or some such when  
talking about linking to, quoting or embedding other "items" that  
exist in sakai. People have found work-arounds to accomplish some  
things, but there are generally no affordances for these kinds of  
activities.

I agree with John Norman that we need to focus on the user experience  
now, and that this thread has been confusing because we keep slipping  
back to the developer perspective.

That said, I have two questions for you -- one from a developer  
perspective and one from a user perspective:

1) If we implemented Atom within Sakai (or whatever the relationship  
is), what capabilities would it give to users that they will not get  
from JSON, XML and HTML renderings of the same "content"?  In other  
words, is there some reason that actual end users might care whether  
we use that particular approach, when we get to that point?

2) What would be involved from a developer perspective in adopting  
Atom?  Is it a matter of providing access to data using some  
particular format or protocol?

Jim




On Dec 15, 2008, at 2:50 PM, Michael Feldstein wrote:

> No, I am absolutely not claiming to have an answer. Rather, I'm  
> trying to understand what the question is. A lot of what's described  
> in Confluence doesn't (in my mind, anyway) simplify page authoring.  
> It enriches it in a way that we hope will seem simple to the users.  
> But I don't get how the plan is supposed to work. I'm just throwing  
> Atom and Atom Publishing out as straw men. They exist and are widely  
> adopted. If we can quantify the gap between these existing  
> capabilities and what is envisioned in Sakai, then we can know (a)  
> if something that already exists is fit to task, (b) if something  
> that already exists is close but needs to be extended, or (c) if the  
> Sakai community really does need to go its own way and invent  
> something new.
>
> I'm just looking to a gap analysis as one way to understand what  
> you're trying to accomplish.
>
> - m
>
>
> Jim Eng wrote:
>>
>> I am having a hard time understanding what your point is, Michael.  
>> Is it that there's something inherently wrong with the idea of  
>> trying to simplify page authoring in Sakai.  Or are we going about  
>> it in the wrong way?  If you think that what users want could be  
>> accomplished better or easier using some work that someone else has  
>> done, could you tell us more about that?  Should we suddenly have  
>> sees the light by looking at the ATOM pages you referenced?  Or  
>> will we need help to make the jump?
>>
>> Jim
>>
>>
>>
>>
>> On Dec 15, 2008, at 1:19 PM, Michael Feldstein wrote:
>>
>>> Um...I'm not sure.
>>>
>>> Are these superstrings of academic computing proven to exist in  
>>> sufficient quantity and variety that we are confident that the  
>>> Grand Unified Theory will work? In a way, what I hear you  
>>> describing is really sort of a REST bus. Anything that can be put  
>>> at the end of a URL can be put on the bus. The noun/verb  
>>> distinction no longer applies, as long as the whatever is URL-
>>> addressable. (It's a particle! It's a wave! It's a dessert topping  
>>> AND a floor wax!) But are we confident that it really makes sense  
>>> to mash this all into one metadata format? And if so, has anyone  
>>> else out in the universe done any useful work on a REST bus that  
>>> might be applicable?
>>>
>>> - m
>>>
>>>
>>> Michael Korcuska wrote:
>>>>
>>>> The talk about entities is confusing. Until it isn't.
>>>>
>>>> I think of it as something you want to refer to, or display, or  
>>>> manipulate (e.g. grade) in some way.  It could be a discussion  
>>>> post or a discussion thread. It could be an online test or an  
>>>> online test question or a response to an online test question. It  
>>>> could be an HTML page or a collection of HTML pages.   What we  
>>>> want is a simple way to be able to get at these things.  A nice,  
>>>> clean URL.  A RESTful web service. The reason we've been calling  
>>>> them "entities" is because the Sakai service that allows you to  
>>>> do this in Sakai has been called the "entity broker" or the  
>>>> "entity service".
>>>>
>>>> And not enough of them exist yet. Sakai needs to be modified to  
>>>> allow more "things" to be referenced/displayed/manipulated in  
>>>> this way. The more of Sakai that is exposed in this fashion, the  
>>>> more flexibility we provide. And if we had more of Sakai exposed  
>>>> then the discussion would be less confusing because there would  
>>>> be more examples (which is what my first sentence meant).
>>>>
>>>> Did that help or hurt?
>>>>
>>>> Michael
>>>>
>>>>
>>>> On Dec 15, 2008, at 17:18, Michael Feldstein wrote:
>>>>
>>>>> It made a great deal of sense until I got to the sentence about  
>>>>> entities. Let me see if I can break out some of the pieces into  
>>>>> sufficient clarity that somebody can at least point to the parts  
>>>>> that I have wrong:
>>>>> We have this stuff that we colloquially refer to as "content".
>>>>> "Content" could be a discussion thread, a blog, a survey, a  
>>>>> calendar, etc.
>>>>> We want a mechanism access and re-use the content, regardless of  
>>>>> type.
>>>>> As part of this mechanism, we envision being able to pick  
>>>>> particular chunks of the content, e.g., a blog post, a survey  
>>>>> question, a calendar entry, etc.
>>>>> We speculate it may be possible to create universal packages for  
>>>>> content chunks. Michael K has proposed calling these (imaginary)  
>>>>> packages "items."
>>>>> We have this other stuff that we colloquially refer to as "tools".
>>>>> "Tools" represent bundles of related affordances for particular  
>>>>> types of actions, e.g., discussing, bloging, surveying,  
>>>>> coordinating dates and appointments, etc.
>>>>> We want a mechanism to access and re-use individual affordances  
>>>>> from the bundles, regardless of type.
>>>>> As part of this mechanism, we envision being able to pick  
>>>>> particular affordances, e.g., replying to a discussion, writing  
>>>>> a blog post, answering a survey question, creating a calendar  
>>>>> entry, etc.
>>>>> We speculate it may be possible to create universal packages for  
>>>>> action affordances. We call these packages "entities".
>>>>> We have still other stuff that we colloquially refer to as "web  
>>>>> pages".
>>>>> Web pages represent the user interface in which users interact  
>>>>> with content and affordances.
>>>>> We want a mechanism to access and re-use the user interface.
>>>>> As part of this mechanism, we envision being able to pick  
>>>>> particular chunks of user interface, e.g., a discussion thread  
>>>>> interface, a blog posting interface, a survey question  
>>>>> interface, a date picker interface, etc.
>>>>> We know it is possible to create universal packages for these UI  
>>>>> chunks. We call them gadgets or widgets.
>>>>> Items, entities, and gadgets serve analogous but very different  
>>>>> purposes by acting as...chunkifiers in their various domains. It  
>>>>> is important not to confuse them with each other. At the same  
>>>>> time, they can be complementary to each other. For example, one  
>>>>> might have a discussion thread widget calling a discussion  
>>>>> thread entity and displaying a particular discussion thread item  
>>>>> at the bottom of a page.
>>>>>
>>>>> Does that sound even remotely right?
>>>>>
>>>>> - m
>>>>>
>>>>>
>>>>> [hidden email] wrote:
>>>>>>
>>>>>> I'm only catching up on emails after having been on a holiday,  
>>>>>> so the
>>>>>> point I'll try to make might already have been said in emails  
>>>>>> which I still
>>>>>> need to read :).
>>>>>>
>>>>>> In my mind, the central content repository where all of the  
>>>>>> content is being
>>>>>> stored in, is completely separate from what we are trying to  
>>>>>> achieve in the
>>>>>> WYSIWYG editor. To me, there is a very big distinction between  
>>>>>> the content
>>>>>> itself (the data and its properties) and displaying active  
>>>>>> areas in the
>>>>>> WYSIWYG editor (display).
>>>>>>
>>>>>> For me it makes sense to have a central content repository  
>>>>>> where all of the
>>>>>> content is being stored as "what it is and what it  
>>>>>> contains" (I'm having
>>>>>> difficulty to explain). But I don't
>>>>>> necessarily want to place this piece of content in my WYSIWYG  
>>>>>> editor. I want
>>>>>> to have a view on that piece of content. One of those might be  
>>>>>> very close
>>>>>> to the content itself, but I might only want a small or  
>>>>>> particular part,
>>>>>> I might want to use it for mashup with other things, ... In  
>>>>>> other words,
>>>>>> I am very cautious for having the border between data and  
>>>>>> display blur
>>>>>> too much and end up in a too technically oriented world.
>>>>>>
>>>>>> As an example, a poll can be a piece of content, consisting out  
>>>>>> of the question,
>>>>>> the options, the answers (and the general properties as where  
>>>>>> being used, ...).
>>>>>> I might know a site with this poll, and it is really  
>>>>>> interesting for my
>>>>>> site too. I can mark this poll as being of interest to me, but  
>>>>>> when I come
>>>>>> to the point of embedding this into my site, I might not want  
>>>>>> to have the
>>>>>> entire poll in my site, as I would expect if we speak of  
>>>>>> embedding entities
>>>>>> in a site. I want to embed a view on this entity, being only  
>>>>>> the results for
>>>>>> example.
>>>>>>
>>>>>> Does that make any sense?
>>>>>>
>>>>>> Nicolaas
>>>>>>
>>>>>> > Quoting "Plourde, Mathieu" <[hidden email]>:
>>>>>> >
>>>>>> > Hi Sean,
>>>>>> >
>>>>>> > Yes, an entity should be able to contain another one. In my  
>>>>>> idea of what we
>>>>>> > are trying to achieve, anywhere a WYSIWYG editor can be use,  
>>>>>> and entity can
>>>>>> > be embedded. And if entities end up being in Resources, then  
>>>>>> editing that
>>>>>> > sub-entity shouldn't be an issue.
>>>>>> >
>>>>>> > Best Regards,
>>>>>> >
>>>>>> > =================================
>>>>>> >
>>>>>> > Mathieu Plourde, MBA
>>>>>> > Instructional Designer
>>>>>> > IT-User Services
>>>>>> > 021 Smith Hall
>>>>>> > 18 Amstel Avenue
>>>>>> > Newark, DE 19716
>>>>>> >
>>>>>> > Phone: 302-831-4060
>>>>>> > Fax: 302-831-4205
>>>>>> > [hidden email]<mailto:[hidden email]>
>>>>>> > http://copland.udel.edu/~mathieu/
>>>>>> >
>>>>>> > =================================
>>>>>> >
>>>>>> > From: Sean Keesler [mailto:[hidden email]]
>>>>>> > Sent: Thursday, December 11, 2008 12:59 PM
>>>>>> > To: Michael Korcuska
>>>>>> > Cc: John Norman; Content List; Sakai Developers; Nicolaas  
>>>>>> Matthijs; Tjhien
>>>>>> > Liao; Nathan Pearson
>>>>>> > Subject: Re: Big concept in Content Authoring
>>>>>> >
>>>>>> > Does any of the discussion include the idea that a resource/
>>>>>> entity would
>>>>>> > include one or more others?
>>>>>> > Sort of similar to the idea of a photo collection/album Michael
>>>>>> > mentions, but may also include items of different  
>>>>>> types...along the
>>>>>> > lines of a portfolio which consists of many different types  
>>>>>> of items
>>>>>> > wrapped with a set of instructions on how to display them.
>>>>>> >
>>>>>> > Sean
>>>>>> >
>>>>>> > -------------------
>>>>>> > Sean Keesler
>>>>>> > 130 Academy Street
>>>>>> > Manlius, NY 13104
>>>>>> > [hidden email]
>>>>>> > 315-682-0830
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Michael Korcuska wrote:
>>>>>> > > I think this is what Ihave been imagining, John. A few  
>>>>>> comments below.
>>>>>> > >
>>>>>> > > "Resource" is a better word than entity, to be sure, but is  
>>>>>> loaded in
>>>>>> > > Sakai. I don't think I necessarily have a better one...I've  
>>>>>> been using
>>>>>> > > "item" along the way. For my money it is as generic as  
>>>>>> "entity" but
>>>>>> > > less technical sounding. But this is hardly your point.
>>>>>> > >
>>>>>> > > For browsing/finding "resources/items" I imagine one would  
>>>>>> want to be
>>>>>> > > able to filter the list of items on a variety of criteria  
>>>>>> including:
>>>>>> > >
>>>>>> > > * Who created it
>>>>>> > > * Individuals that have permission to [view/edit/delete/
>>>>>> whatever] it
>>>>>> > > * Groups that have permission to [view/edit/delete/
>>>>>> whatever] it
>>>>>> > > * What content it contains (search)
>>>>>> > > * It's name
>>>>>> > > * It's tags
>>>>>> > > * When it was created/modified
>>>>>> > > * It's size
>>>>>> > > * The type of item/resource it is
>>>>>> > > * It's popularity (how often it has been accessed)
>>>>>> > > * Properties "unique" to the type of item (e.g. the number  
>>>>>> of posts in
>>>>>> > > a discussion thread!)
>>>>>> > > * What "collections" it belongs to. We haven't really  
>>>>>> talked about
>>>>>> > > the notion of a content collection but this is a common  
>>>>>> notion in many
>>>>>> > > sites that deal with lots of content (e.g. photo management  
>>>>>> sites)
>>>>>> > >
>>>>>> > > I'm not suggesting all these be presented to a user in a  
>>>>>> single
>>>>>> > > interface, but I the phrase "universal resources browser"  
>>>>>> suggest that
>>>>>> > > you intend to cast the net pretty wide. And I think an  
>>>>>> "advanced"
>>>>>> > > search or filter capability would want to include these  
>>>>>> (and I'm sure
>>>>>> > > other) criteria.
>>>>>> > >
>>>>>> > > I must admit I'm not sure what your driving at with  
>>>>>> Properties. Do
>>>>>> > > these govern how the object appears/behaves once you've  
>>>>>> found it and
>>>>>> > > put it somewhere? I can imagine finding a discussion  
>>>>>> thread, putting
>>>>>> > > it on a page I'm authoring and then setting
>>>>>> > > the property "DisplayFormat" to "Threaded" or "Flat". Or,  
>>>>>> after all, I
>>>>>> > > might want to simply refer to the object by URL and use the  
>>>>>> standard
>>>>>> > > href target attribute to determine how it opens. If that's  
>>>>>> what you
>>>>>> > > mean I think that's great.
>>>>>> > >
>>>>>> > > But since you raised this is in the context of a resource  
>>>>>> browser I
>>>>>> > > thought you might be imagining that these properties are  
>>>>>> used in the
>>>>>> > > process of finding the item/resource you want. If so, I'm  
>>>>>> not getting it.
>>>>>> > >
>>>>>> > > Michael
>>>>>> > >
>>>>>> > >
>>>>>> > > On Dec 11, 2008, at 16:08, John Norman wrote:
>>>>>> > >
>>>>>> > >> We have been discussing what a universal resources browser  
>>>>>> should look
>>>>>> > >> like and I have a thought that makes sense to me, but want  
>>>>>> to check
>>>>>> > >> out with a wider group.
>>>>>> > >>
>>>>>> > >> I think we should use "resource" to mean quite a wide  
>>>>>> range of things
>>>>>> > >> along the lines of Matthieu's "What should an Entity look  
>>>>>> like?" page
>>>>>> > >> ( http://confluence.sakaiproject.org/confluence/x/kQF1Ag).  
>>>>>> In order
>>>>>> > >> for this to work, I imagine we would need a number of  
>>>>>> resource-types,
>>>>>> > >> e.g. ResourceType=DiscussionThread with a defined set of  
>>>>>> properties
>>>>>> > >> (e.g. DisplayFormat=Threaded or DisplayFormat=Flat). I  
>>>>>> recognise that
>>>>>> > >> this is close to the Entity work, but I feel it is more  
>>>>>> accessible
>>>>>> > >> language. One ResourceType might be "File" with a property  
>>>>>> "Open in
>>>>>> > >> New Window". A resource browser for a site or for someone  
>>>>>> looking
>>>>>> > >> across a number of sites would then include ResourceType  
>>>>>> as an
>>>>>> > >> orderable or filterable field so you could ask for all the  
>>>>>> assignments
>>>>>> > >> in Physics101 or all the assignments in First Year  
>>>>>> Engineering Courses.
>>>>>> > >>
>>>>>> > >> I'd like to start modifying Matthieu's page along these  
>>>>>> lines, but
>>>>>> > >> wanted to make sure others think this makes sense before  
>>>>>> going too far.
>>>>>> > >>
>>>>>> > >> John
>>>>>> > >>  
>>>>>> ------------------------------------------------------------------------
>>>>>> > >>
>>>>>> > >> 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.
>>>>>> > >
>>>>>> > > --
>>>>>> > > Michael Korcuska
>>>>>> > > Executive Director, Sakai Foundation
>>>>>> > > [hidden email]
>>>>>> >
>>>>>> <mailto:[hidden email]><mailto:[hidden email]%3e
>>>>>> >
>>>>>> > > phone: +1 510-931-6559
>>>>>> > > mobile (US): +1 510-599-2586
>>>>>> > > mobile (FR): +33 (0)6 31 11 58 97
>>>>>> > > skype: mkorcuska
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> > >  
>>>>>> ------------------------------------------------------------------------
>>>>>> > >
>>>>>> > > 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.
>>>>>> > ________________________________
>>>>>> >
>>>>>> > 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.
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------
>>>>>> This message was sent using IMP, the Internet Messaging Program.
>>>>>>
>>>>>>
>>>>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>>>>> ) from the DG: Development (a.k.a. sakai-dev) site.
>>>>>> You can modify how you receive notifications at My Workspace >  
>>>>>> Preferences.
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> <oracle_sig_logo.gif>
>>>>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>>>>> Oracle Academic Enterprise Solutions Group
>>>>> 23A Glendale Road, Glendale, MA 01229
>>>>
>>>> --
>>>> Michael Korcuska
>>>> Executive Director, Sakai Foundation
>>>> [hidden email]
>>>> phone: +1 510-931-6559
>>>> mobile (US): +1 510-599-2586
>>>> mobile (FR): +33 (0)6 31 11 58 97
>>>> skype: mkorcuska
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>>> ) from the DG: Development (a.k.a. sakai-dev) 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
>>> [see attachment: "oracle_sig_logo.gif", size: 658 bytes]
>>>
>>>
>>> Attachments:
>>>
>>> oracle_sig_logo.gif
>>>
>>>
>>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>>> ) from the DG: Development (a.k.a. sakai-dev) site.
>>> You can modify how you receive notifications at My Workspace >  
>>> Preferences.
>>
>
> --
>
>
> <oracle_sig_logo.gif>
> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> Oracle Academic Enterprise Solutions Group
> 23A Glendale Road, Glendale, MA 01229


----------------------
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: Big concept in Content Authoring


<snip>

>
> 1) If we implemented Atom within Sakai (or whatever the relationship
> is), what capabilities would it give to users that they will not get
> from JSON, XML and HTML renderings of the same "content"?  In other
> words, is there some reason that actual end users might care whether
> we use that particular approach, when we get to that point?
Let me start by saying that my straw man was aimed at meeting the
already defined set of requirements (to the degree that I understand
them) by re-using something that somebody else has already created
rather than expanding the functional goals beyond the already ambitious
list that exists today. It sounded to me as if there was conversation on
the dev list about creating some kind of object (or item or entity)
model that would be sort of a universal metadata envelope for...stuff,
presumably backed by a set of services. My response was to ask whether
the existing standard for a content metadata envelope (Atom) and related
services (Atom Publishing) were adequate to the task, thus obviating the
need for the Sakai community to roll its own.

That said, there may be functional advantages to using Atom when you
start to look to integrate with other systems. On the inbound side, you
could, say, process the feed from a student's blog (or a professor's
blog, or a Flickr picture stream, or whatever) out in the cloud and pull
it into your content system much more easily. And I think the benefits
on the outbound side are fairly obvious. This is not because of any
particular technical advantage to Atom, which I am not qualified to
evaluate, but rather to the fact that it is becoming the lingua franca.
>
> 2) What would be involved from a developer perspective in adopting
> Atom?  Is it a matter of providing access to data using some
> particular format or protocol?
I don't know because I'm not a developer and because I don't fully
understand the requirements yet. If you're talking about simply creating
ubiquitous feeds on items in a content repository, and basic supporting
content management services for acting on those items in the repository,
lots of systems already do this and open source projects such as Apache
Abdera <http://abdera.apache.org/> exist to help with that sort of
thing. But the group seems to be aiming higher than this. What I hear
(and could be misunderstanding) is that you want every granular content
object and every granular user-facing service to be callable (or
viewable) /and discoverable/ from a user interface. That seems to be
more than can be accomplished with a widget library. When you're talking
about content, I don't know that Atom makes content searching and
browsing any easier or harder. When you're talking about services, I
have read some information about service discoverability using Atom
Publishing (e.g., here
<http://tools.ietf.org/html/draft-snell-atompub-feature-12> and here
<http://www.sixapart.com/developers/product_documentation/typepad/typelist_autodiscovery.html>).
That's about as far as I know how to go.

- m

--


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/d57dcfff-63e7-49d5-9abd-854b86f0abdb/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.
Jim Eng Jim Eng
Reply | Threaded
Open this post in threaded view
|

Re: Big concept in Content Authoring

In reply to this post by Jim Eng

It seems that somewhere along the line we have said things that imply  
there will be a simple "universal" user interface for "discovering"  
relevant items and that there would be some simple "universal"  
solution to the technical problem of discovering relevant "content" or  
"widgets".

My hope is that to users it will seem like there's just one seamless  
UI that gives them the ability to do everything they want to do.  But  
I think we were clear in Dearborn and in the bi-weekly authoring  
meetings that we do not expect some simple "universal" solution that  
by itself solves the problems of discovering relevant "resources" and  
establishing how they will be displayed and how users will interact  
with them in a document, either during authoring or during display of  
an authored document.  We looked at the preliminary version of an  
"entity browser", which is a proof of concept for parts of the  
problem. Every time we discussed the entity browser, I think it was  
with the understanding that getting the user interface right will  
require work and that the way of choosing or setting display options  
for particular types of entities will require specialization. It's  
likely that each webapp within sakai that is an entity provider" will  
also need to provide UI elements (be they widgets, gadgets or magical  
thingamabobs) for parts of this process and that we will need  
something that pulls them together for users.


For further discussion related to authoring, please make sure that  
this address is in the cc-list (or you can add it):  [hidden email]
  The old address (content at  collab.sakaiproject.org) is no longer  
valid.

Thanks.

Jim




On Dec 16, 2008, at 4:47 AM, John Norman wrote:

> I'm content with this position. Although I am more confident than
> Nathan that some sort "universal" solution exists for the things I am
> now coming to think of as "Sakai resources", but I think we will need
> to have examples to point at so we can both say "yes, that is what I
> have been talking about all along" and realise we were using different
> language for the same thing :)
>
> John
>
> On 15 Dec 2008, at 22:12, Nathan Pearson wrote:
>
> > Yes, that's more or less how I see the process. Let's take one
> > piece at a time, think about it's context and come up with a
> > solution that works. That may result in a browser or workflow that
> > is very specific to the piece we're dealing with (ex: discussion /
> > forum thread) or we may find enough commonalities with some other
> > bit that it makes sense to work them in together. But the defacto
> > standard in our thinking should not (I believe) be to fixate on a
> > universal solution before such time that a universal soltuion
> > becomes apparent on its own. Well, we should keep an eye out for
> > one, but again, it's shouldn't be the holy grail.
> >
> >
> >
> > On Mon, Dec 15, 2008 at 2:58 PM, Michael Feldstein <[hidden email]
> > > wrote:
> > Ahh. Now this I understand. (I think.) What I hear is we need a
> > WYSIWYG page editor plus a file browser plus a widget browser. All
> > of these either exist today or are modest to moderate enhancements
> > on what exists today. (And existence is a great virtue.) If we want
> > to populate a bit of functional interface (e.g., a discussion thread
> > widget) with a bit of content (e.g., an existing discussion thread),
> > then perhaps we can rely on the widget embedding an appropriate
> > interface for what may start out as being specific to discussion
> > thread functionality but might be generalized to other types of
> > widgets over time. It therefore becomes incumbent upon the
> > technical...um...entifiers to make the appropriate services
> > available for those things-formerly-known-as-tools and on the widget
> > developers to expose those services appropriately. They will have to
> > collaboratively develop, say, a discussion thread picker capability
> > for embedding in the widget. Best practice emerge across widgets
> > over time, we refactor, lather, rinse, repeat.
> >
> > Yes? No? Maybe?
> >
> > - m
> >
> >
> > Nathan Pearson wrote:
> >>
> >> I agree with John, let's try to get this back onto a user track
> >> when talking about this.
> >>
> >> To start, I think the way Jim Eng communicates these things are
> >> right on (not to criticize anyone else). He uses scenario based
> >> examples to discuss this situation. I would love to hear more
> >> people frame the discussion in those terms.
> >>
> >> So here's my attempt at that:
> >>
> >> As I see it, Sakai is moving toward a more collaborative wiki
> >> model. That's not to suggest Sakai will be purely a collaborative
> >> wiki, but that it will allow users to create and edit pages
> >> collaboratively and embed stuff into those pages.
> >>
> >> I think for the most part, we have an idea of what creating and
> >> editing pages might look like, but we're stuck when it comes to
> >> embedding stuff. The reason we're stuck is that it's not just
> >> embedding stuff. It's finding stuff, editing stuff (either pre or
> >> post being embedded), managing access controls on that stuff, etc.
> >>
> >> Am I on the right track so far?
> >>
> >> Let's take it one thing at a time then. Focusing purely on the
> >> "finding" of the stuff; the question on the table from me is: is it
> >> proper to use a universal UI?
> >>
> >> In my previous post I made the point that it's probably not --
> >> though I'm not ruling out the possibility that it might be. Here
> >> is why I think it is not:
> >>
> >> If I'm adding images to my wiki-esque page, than I'd like to have a
> >> file browser similar to any file browser I've used in the past.
> >> They're familiar, functional, and simply make sense. That's not to
> >> say we can't add a few bells and whistles like tagging, meta data,
> >> etc., but that's a slightly different topic.
> >>
> >> On the other hand, what should the browser look like if it's not a
> >> typical file I need, but rather some functional bit like a survey
> >> question (or a complete survey for that matter)?
> >>
> >> In my opinion, it should NOT look like the same file browser as the
> >> one used to find images. The reason I say this is that a typical
> >> file browser has a strong metaphor and mixing it (as we've done
> >> with the resources tool) is confusing to users You may know what
> >> you mean with all this universal browser talk, but I can almost
> >> certainly promise you that most users will not get it. Some will,
> >> but most will not!
> >>
> >> Instead, the browser to find the survey bits should have some
> >> relationship with the UI in the survey tool. Now some of you are
> >> rolling your eyes thinking that I just don't get it -- that the
> >> survey tool is made obsolete when a universal browser is coupled
> >> with wiki pages. But I disagree. I still think the legacy Sakai
> >> model of having tools is perfectly valid. It's a model that is
> >> pervasive and therefor familiar in many UIs, including your own
> >> operating system where you have a platform from which programs are
> >> launched -- each of which generally have appropriately different
> >> UI's.
> >>
> >> So in my view of Sakai, tools and their respective UIs should
> >> continue to exist (there I said it), but we should also have a
> >> collaborative wiki situation that significantly frames the
> >> product. With the wiki being the cornerstone of the product's
> >> identity, it should be able to pull stuff (be it data or functional
> >> bits) into pages from those tools. And hey, if done right, an
> >> advanced user may even side-step the need for tools and just use a
> >> wiki page with functional bits as a replacement for tools. But
> >> frankly, that's a far reaching goal that should evolve over time
> >>
> >> Now to be clear, I'm not arguing for inconsistency with all talk
> >> against re-usable screens. We need consistency. But I think we
> >> often fail to define what level of it is appropriate. This leads
> >> us to either completely ignore the issue (which results in terribly
> >> inconsistent UIs) or go overboard and try to fit square pegs into
> >> round holes for the sake of consistent. Neither of these extremes
> >> makes sense. Instead, consistency should be a general goal with an
> >> emphasis on contextually relevant UIs with a "commonality" to them
> >> -- as opposed to pure consistency.
> >>
> >> Is any of this making sense? I'll stop here and get some feedback
> >> before continuing this novel. Cheers.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Dec 15, 2008 at 12:17 PM, John Norman
> >> <[hidden email]> wrote:
> >> OK, I'm out :)
> >>
> >> For those who want to stay in the conversation, I urge you to
> >> declare first whether you are talking in concepts for the developer
> >> or concepts for the user. I was trying to develop a concept for the
> >> user, but we keep slipping back into developer perspectives. The
> >> user concepts are evolving on the demo server pages, I'll leave the
> >> taxonomy until they mature further and can be discussed
> >> independently.
> >>
> >> John
> >>
> >>
> >> On 15 Dec 2008, at 18:19, Michael Feldstein wrote:
> >>
> >> Um...I'm not sure.
> >>
> >> Are these superstrings of academic computing proven to exist in
> >> sufficient quantity and variety that we are confident that the
> >> Grand Unified Theory will work? In a way, what I hear you
> >> describing is really sort of a REST bus. Anything that can be put
> >> at the end of a URL can be put on the bus. The noun/verb
> >> distinction no longer applies, as long as the whatever is URL-
> >> addressable. (It's a particle! It's a wave! It's a dessert topping
> >> AND a floor wax!) But are we confident that it really makes sense
> >> to mash this all into one metadata format? And if so, has anyone
> >> else out in the universe done any useful work on a REST bus that
> >> might be applicable?
> >>
> >> - m
> >>
> >>
> >> Michael Korcuska wrote:
> >>
> >> The talk about entities is confusing. Until it isn't.
> >>
> >> I think of it as something you want to refer to, or display, or
> >> manipulate (e.g. grade) in some way. It could be a discussion post
> >> or a discussion thread. It could be an online test or an online
> >> test question or a response to an online test question. It could be
> >> an HTML page or a collection of HTML pages. What we want is a
> >> simple way to be able to get at these things. A nice, clean URL.
> >> A RESTful web service. The reason we've been calling them
> >> "entities" is because the Sakai service that allows you to do this
> >> in Sakai has been called the "entity broker" or the "entity  
> service".
> >>
> >> And not enough of them exist yet. Sakai needs to be modified to
> >> allow more "things" to be referenced/displayed/manipulated in this
> >> way. The more of Sakai that is exposed in this fashion, the more
> >> flexibility we provide. And if we had more of Sakai exposed then
> >> the discussion would be less confusing because there would be more
> >> examples (which is what my first sentence meant).
> >>
> >> Did that help or hurt?
> >>
> >> Michael
> >>
> >>
> >> On Dec 15, 2008, at 17:18, Michael Feldstein wrote:
> >>
> >> It made a great deal of sense until I got to the sentence about
> >> entities. Let me see if I can break out some of the pieces into
> >> sufficient clarity that somebody can at least point to the parts
> >> that I have wrong:
> >> • We have this stuff that we colloquially refer to as
> >> "content".
> >> • "Content" could be a discussion thread, a blog, a
> >> survey, a calendar, etc.
> >> • We want a mechanism access and re-use the content,
> >> regardless of type.
> >> • As part of this mechanism, we envision being able
> >> to pick particular chunks of the content, e.g., a blog post, a
> >> survey question, a calendar entry, etc.
> >> • We speculate it may be possible to create
> >> universal packages for content chunks. Michael K has proposed
> >> calling these (imaginary) packages "items."
> >> • We have this other stuff that we colloquially refer to as
> >> "tools".
> >> • "Tools" represent bundles of related affordances
> >> for particular types of actions, e.g., discussing, bloging,
> >> surveying, coordinating dates and appointments, etc.
> >> • We want a mechanism to access and re-use
> >> individual affordances from the bundles, regardless of type.
> >> • As part of this mechanism, we envision being able
> >> to pick particular affordances, e.g., replying to a discussion,
> >> writing a blog post, answering a survey question, creating a
> >> calendar entry, etc.
> >> • We speculate it may be possible to create
> >> universal packages for action affordances. We call these packages
> >> "entities".
> >> • We have still other stuff that we colloquially refer to as
> >> "web pages".
> >> • Web pages represent the user interface in which
> >> users interact with content and affordances.
> >> • We want a mechanism to access and re-use the user
> >> interface.
> >> • As part of this mechanism, we envision being able
> >> to pick particular chunks of user interface, e.g., a discussion
> >> thread interface, a blog posting interface, a survey question
> >> interface, a date picker interface, etc.
> >> • We know it is possible to create universal
> >> packages for these UI chunks. We call them gadgets or widgets.
> >> Items, entities, and gadgets serve analogous but very different
> >> purposes by acting as...chunkifiers in their various domains. It is
> >> important not to confuse them with each other. At the same time,
> >> they can be complementary to each other. For example, one might
> >> have a discussion thread widget calling a discussion thread entity
> >> and displaying a particular discussion thread item at the bottom of
> >> a page.
> >>
> >> Does that sound even remotely right?
> >>
> >> - m
> >>
> >>
> >> [hidden email] wrote:
> >>
> >> I'm only catching up on emails after having been on a holiday, so  
> the
> >> point I'll try to make might already have been said in emails which
> >> I still
> >> need to read :).
> >>
> >> In my mind, the central content repository where all of the content
> >> is being
> >> stored in, is completely separate from what we are trying to
> >> achieve in the
> >> WYSIWYG editor. To me, there is a very big distinction between the
> >> content
> >> itself (the data and its properties) and displaying active areas in
> >> the
> >> WYSIWYG editor (display).
> >>
> >> For me it makes sense to have a central content repository where
> >> all of the
> >> content is being stored as "what it is and what it contains" (I'm
> >> having
> >> difficulty to explain). But I don't
> >> necessarily want to place this piece of content in my WYSIWYG
> >> editor. I want
> >> to have a view on that piece of content. One of those might be very
> >> close
> >> to the content itself, but I might only want a small or particular
> >> part,
> >> I might want to use it for mashup with other things, ... In other
> >> words,
> >> I am very cautious for having the border between data and display
> >> blur
> >> too much and end up in a too technically oriented world.
> >>
> >> As an example, a poll can be a piece of content, consisting out of
> >> the question,
> >> the options, the answers (and the general properties as where being
> >> used, ..).
> >> I might know a site with this poll, and it is really interesting
> >> for my
> >> site too. I can mark this poll as being of interest to me, but when
> >> I come
> >> to the point of embedding this into my site, I might not want to
> >> have the
> >> entire poll in my site, as I would expect if we speak of embedding
> >> entities
> >> in a site. I want to embed a view on this entity, being only the
> >> results for
> >> example.
> >>
> >> Does that make any sense?
> >>
> >> Nicolaas
> >>
> >> > Quoting "Plourde, Mathieu" <[hidden email]>:
> >> >
> >> > Hi Sean,
> >> >
> >> > Yes, an entity should be able to contain another one. In my idea
> >> of what we
> >> > are trying to achieve, anywhere a WYSIWYG editor can be use, and
> >> entity can
> >> > be embedded. And if entities end up being in Resources, then
> >> editing that
> >> > sub-entity shouldn't be an issue.
> >> >
> >> > Best Regards,
> >> >
> >> > =================================
> >> >
> >> > Mathieu Plourde, MBA
> >> > Instructional Designer
> >> > IT-User Services
> >> > 021 Smith Hall
> >> > 18 Amstel Avenue
> >> > Newark, DE 19716
> >> >
> >> > Phone: 302-831-4060
> >> > Fax: 302-831-4205
> >> > [hidden email]<mailto:[hidden email]>
> >> > http://copland.udel.edu/~mathieu/
> >> >
> >> > =================================
> >> >
> >> > From: Sean Keesler [mailto:[hidden email]]
> >> > Sent: Thursday, December 11, 2008 12:59 PM
> >> > To: Michael Korcuska
> >> > Cc: John Norman; Content List; Sakai Developers; Nicolaas
> >> Matthijs; Tjhien
> >> > Liao; Nathan Pearson
> >> > Subject: Re: Big concept in Content Authoring
> >> >
> >> > Does any of the discussion include the idea that a resource/
> >> entity would
> >> > include one or more others?
> >> > Sort of similar to the idea of a photo collection/album Michael
> >> > mentions, but may also include items of different types...along  
> the
> >> > lines of a portfolio which consists of many different types of
> >> items
> >> > wrapped with a set of instructions on how to display them.
> >> >
> >> > Sean
> >> >
> >> > -------------------
> >> > Sean Keesler
> >> > 130 Academy Street
> >> > Manlius, NY 13104
> >> > [hidden email]
> >> > 315-682-0830
> >> >
> >> >
> >> >
> >> >
> >> > Michael Korcuska wrote:
> >> > > I think this is what Ihave been imagining, John. A few comments
> >> below.
> >> > >
> >> > > "Resource" is a better word than entity, to be sure, but is
> >> loaded in
> >> > > Sakai. I don't think I necessarily have a better one...I've
> >> been using
> >> > > "item" along the way. For my money it is as generic as "entity"
> >> but
> >> > > less technical sounding. But this is hardly your point.
> >> > >
> >> > > For browsing/finding "resources/items" I imagine one would want
> >> to be
> >> > > able to filter the list of items on a variety of criteria
> >> including:
> >> > >
> >> > > * Who created it
> >> > > * Individuals that have permission to [view/edit/delete/
> >> whatever] it
> >> > > * Groups that have permission to [view/edit/delete/whatever] it
> >> > > * What content it contains (search)
> >> > > * It's name
> >> > > * It's tags
> >> > > * When it was created/modified
> >> > > * It's size
> >> > > * The type of item/resource it is
> >> > > * It's popularity (how often it has been accessed)
> >> > > * Properties "unique" to the type of item (e.g. the number of
> >> posts in
> >> > > a discussion thread!)
> >> > > * What "collections" it belongs to. We haven't really talked
> >> about
> >> > > the notion of a content collection but this is a common notion
> >> in many
> >> > > sites that deal with lots of content (e.g. photo management
> >> sites)
> >> > >
> >> > > I'm not suggesting all these be presented to a user in a single
> >> > > interface, but I the phrase "universal resources browser"
> >> suggest that
> >> > > you intend to cast the net pretty wide. And I think an  
> "advanced"
> >> > > search or filter capability would want to include these (and
> >> I'm sure
> >> > > other) criteria.
> >> > >
> >> > > I must admit I'm not sure what your driving at with Properties.
> >> Do
> >> > > these govern how the object appears/behaves once you've found
> >> it and
> >> > > put it somewhere? I can imagine finding a discussion thread,
> >> putting
> >> > > it on a page I'm authoring and then setting
> >> > > the property "DisplayFormat" to "Threaded" or "Flat". Or, after
> >> all, I
> >> > > might want to simply refer to the object by URL and use the
> >> standard
> >> > > href target attribute to determine how it opens. If that's what
> >> you
> >> > > mean I think that's great.
> >> > >
> >> > > But since you raised this is in the context of a resource
> >> browser I
> >> > > thought you might be imagining that these properties are used
> >> in the
> >> > > process of finding the item/resource you want. If so, I'm not
> >> getting it.
> >> > >
> >> > > Michael
> >> > >
> >> > >
> >> > > On Dec 11, 2008, at 16:08, John Norman wrote:
> >> > >
> >> > >> We have been discussing what a universal resources browser
> >> should look
> >> > >> like and I have a thought that makes sense to me, but want to
> >> check
> >> > >> out with a wider group.
> >> > >>
> >> > >> I think we should use "resource" to mean quite a wide range of
> >> things
> >> > >> along the lines of Matthieu's "What should an Entity look
> >> like?" page
> >> > >> ( http://confluence.sakaiproject.org/confluence/x/kQF1Ag). In
> >> order
> >> > >> for this to work, I imagine we would need a number of  
> resource-
> >> types,
> >> > >> e.g. ResourceType=DiscussionThread with a defined set of
> >> properties
> >> > >> (e.g. DisplayFormat=Threaded or DisplayFormat=Flat). I
> >> recognise that
> >> > >> this is close to the Entity work, but I feel it is more
> >> accessible
> >> > >> language. One ResourceType might be "File" with a property
> >> "Open in
> >> > >> New Window". A resource browser for a site or for someone
> >> looking
> >> > >> across a number of sites would then include ResourceType as an
> >> > >> orderable or filterable field so you could ask for all the
> >> assignments
> >> > >> in Physics101 or all the assignments in First Year Engineering
> >> Courses.
> >> > >>
> >> > >> I'd like to start modifying Matthieu's page along these lines,
> >> but
> >> > >> wanted to make sure others think this makes sense before going
> >> too far.
> >> > >>
> >> > >> John
> >> > >>
> >>  
> ------------------------------------------------------------------------
> >> > >>
> >> > >> 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.
> >> > >
> >> > > --
> >> > > Michael Korcuska
> >> > > Executive Director, Sakai Foundation
> >> > > [hidden email]
> >> >
> >> <mailto:[hidden email]><mailto:[hidden email]%3e
> >> >
> >> > > phone: +1 510-931-6559
> >> > > mobile (US): +1 510-599-2586
> >> > > mobile (FR): +33 (0)6 31 11 58 97
> >> > > skype: mkorcuska
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >>  
> ------------------------------------------------------------------------
> >> > >
> >> > > 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.
> >> > ________________________________
> >> >
> >> > 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.
> >> >
> >>
> >>
> >>
> >>
> >> ----------------------------------------------------------------
> >> This message was sent using IMP, the Internet Messaging Program.
> >>
> >>
> >> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
> >> ) from the DG: Development (a.k.a. sakai-dev) site
> >> You can modify how you receive notifications at My Workspace >
> >> Preferences.
> >>
> >> --
> >>
> >>
> >> <oracle_sig_logo.gif>
> >> Michael Feldstein | Principal Product Manager | +1.818.817.2925
> >> Oracle Academic Enterprise Solutions Group
> >> 23A Glendale Road, Glendale, MA 01229
> >>
> >> --
> >> Michael Korcuska
> >> Executive Director, Sakai Foundation
> >> [hidden email]
> >> phone: +1 510-931-6559
> >> mobile (US): +1 510-599-2586
> >> mobile (FR): +33 (0)6 31 11 58 97
> >> skype: mkorcuska
> >>
> >>
> >>
> >>
> >>
> >> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
> >> ) from the DG: Development (a.k.a. sakai-dev) site
> >> You can modify how you receive notifications at My Workspace >
> >> Preferences.
> >>
> >> --
> >>
> >>
> >> <oracle_sig_logo.gif>
> >> 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
> >>
> >>
> >> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
> >> ) from the DG: Development (a.k.a. sakai-dev) site.
> >> You can modify how you receive notifications at My Workspace >
> >> Preferences.
> >
> > --
> >
> >
> > <oracle_sig_logo.gif>
> > 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
>
>
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
> ) from the DG: Development (a.k.a. sakai-dev) 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.
Mathieu Plourde Mathieu Plourde
Reply | Threaded
Open this post in threaded view
|

RE: Big concept in Content Authoring

In reply to this post by Jim Eng

Hi John, Nathan, and all the other happy folks following this discussion,

Maybe it's time to revive this page, which was started for the authoring summit, about use cases.

http://bugs.sakaiproject.org/confluence/display/SAKDEV/Authoring+Summit+-+Use+Cases

There is something there to fuel the discussion to another level IMO.

Best Regards,

=================================

Mathieu Plourde, MBA
Instructional Designer
IT-User Services
021 Smith Hall
18 Amstel Avenue
Newark, DE 19716

Phone: 302-831-4060
Fax: 302-831-4205
[hidden email]
http://copland.udel.edu/~mathieu/

=================================


-----Original Message-----
From: John Norman [mailto:[hidden email]]
Sent: Tuesday, December 16, 2008 4:47 AM
To: Nathan Pearson
Cc: Michael Feldstein; Michael Korcuska; [hidden email]; Plourde, Mathieu; Sean Keesler; Content List; Sakai Developers; Tjhien Liao
Subject: Re: Big concept in Content Authoring

I'm content with this position. Although I am more confident than
Nathan that some sort "universal" solution exists for the things I am
now coming to think of as "Sakai resources", but I think we will need
to have examples to point at so we can both say "yes, that is what I
have been talking about all along" and realise we were using different
language for the same thing :)

John

On 15 Dec 2008, at 22:12, Nathan Pearson wrote:

> Yes, that's more or less how I see the process.  Let's take one
> piece at a time, think about it's context and come up with a
> solution that works.  That may result in a browser or workflow that
> is very specific to the piece we're dealing with (ex: discussion /
> forum thread) or we may find enough commonalities with some other
> bit that it makes sense to work them in together.  But the defacto
> standard in our thinking should not (I believe) be to fixate on a
> universal solution before such time that a universal soltuion
> becomes apparent on its own.  Well, we should keep an eye out for
> one, but again, it's shouldn't be the holy grail.
>
>
>
> On Mon, Dec 15, 2008 at 2:58 PM, Michael Feldstein <[hidden email]
> > wrote:
> Ahh. Now this I understand. (I think.) What I hear is we need a
> WYSIWYG page editor plus a file browser plus a widget browser. All
> of these either exist today or are modest to moderate enhancements
> on what exists today. (And existence is a great virtue.) If we want
> to populate a bit of functional interface (e.g., a discussion thread
> widget) with a bit of content (e.g., an existing discussion thread),
> then perhaps we can rely on the widget embedding an appropriate
> interface for what may start out as being specific to discussion
> thread functionality but might be generalized to other types of
> widgets over time. It therefore becomes incumbent upon the
> technical...um...entifiers to make the appropriate services
> available for those things-formerly-known-as-tools and on the widget
> developers to expose those services appropriately. They will have to
> collaboratively develop, say, a discussion thread picker capability
> for embedding in the widget. Best practice emerge across widgets
> over time, we refactor, lather, rinse, repeat.
>
> Yes? No? Maybe?
>
> - m
>
>
> Nathan Pearson wrote:
>>
>> I agree with John, let's try to get this back onto a user track
>> when talking about this.
>>
>> To start, I think the way Jim Eng communicates these things are
>> right on (not to criticize anyone else).  He uses scenario based
>> examples to discuss this situation.  I would love to hear more
>> people frame the discussion in those terms.
>>
>> So here's my attempt at that:
>>
>> As I see it, Sakai is moving toward a more collaborative wiki
>> model.  That's not to suggest Sakai will be purely a collaborative
>> wiki, but that it will allow users to create and edit pages
>> collaboratively and embed stuff into those pages.
>>
>> I think for the most part, we have an idea of what creating and
>> editing pages might look like, but we're stuck when it comes to
>> embedding stuff.  The reason we're stuck is that it's not just
>> embedding stuff.  It's finding stuff, editing stuff (either pre or
>> post being embedded), managing access controls on that stuff, etc.
>>
>> Am I on the right track so far?
>>
>> Let's take it one thing at a time then.  Focusing purely on the
>> "finding" of the stuff; the question on the table from me is: is it
>> proper to use a universal UI?
>>
>> In my previous post I made the point that it's probably not --
>> though I'm not ruling out the possibility that it might be.  Here
>> is why I think it is not:
>>
>> If I'm adding images to my wiki-esque page, than I'd like to have a
>> file browser similar to any file browser I've used in the past.
>> They're familiar, functional, and simply make sense.  That's not to
>> say we can't add a few bells and whistles like tagging, meta data,
>> etc., but that's a slightly different topic.
>>
>> On the other hand, what should the browser look like if it's not a
>> typical file I need, but rather some functional bit like a survey
>> question (or a complete survey for that matter)?
>>
>> In my opinion, it should NOT look like the same file browser as the
>> one used to find images.  The reason I say this is that a typical
>> file browser has a strong metaphor and mixing it (as we've done
>> with the resources tool) is confusing to users  You may know what
>> you mean with all this universal browser talk, but I can almost
>> certainly promise you that most users will not get it.  Some will,
>> but most will not!
>>
>> Instead, the browser to find the survey bits should have some
>> relationship with the UI in the survey tool.  Now some of you are
>> rolling your eyes thinking that I just don't get it -- that the
>> survey tool is made obsolete when a universal browser is coupled
>> with wiki pages.  But I disagree.  I still think the legacy Sakai
>> model of having tools is perfectly valid.  It's a model that is
>> pervasive and therefor familiar in many UIs, including your own
>> operating system where you have a platform from which programs are
>> launched -- each of which generally have appropriately different
>> UI's.
>>
>> So in my view of Sakai, tools and their respective UIs should
>> continue to exist (there I said it), but we should also have a
>> collaborative wiki situation that significantly frames the
>> product.  With the wiki being the cornerstone of the product's
>> identity, it should be able to pull stuff (be it data or functional
>> bits) into pages from those tools.  And hey, if done right, an
>> advanced user may even side-step the need for tools and just use a
>> wiki page with functional bits as a replacement for tools.  But
>> frankly, that's a far reaching goal that should evolve over time
>>
>> Now to be clear, I'm not arguing for inconsistency with all talk
>> against re-usable screens.  We need consistency.  But I think we
>> often fail to define what level of it is appropriate.  This leads
>> us to either completely ignore the issue (which results in terribly
>> inconsistent UIs) or go overboard and try to fit square pegs into
>> round holes for the sake of consistent.  Neither of these extremes
>> makes sense.  Instead, consistency should be a general goal with an
>> emphasis on contextually relevant UIs with a "commonality" to them
>> -- as opposed to pure consistency.
>>
>> Is any of this making sense?  I'll stop here and get some feedback
>> before continuing this novel.  Cheers.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 15, 2008 at 12:17 PM, John Norman
>> <[hidden email]> wrote:
>> OK, I'm out :)
>>
>> For those who want to stay in the conversation, I urge you to
>> declare first whether you are talking in concepts for the developer
>> or concepts for the user. I was trying to develop a concept for the
>> user, but we keep slipping back into developer perspectives. The
>> user concepts are evolving on the demo server pages, I'll leave the
>> taxonomy until they mature further and can be discussed
>> independently.
>>
>> John
>>
>>
>> On 15 Dec 2008, at 18:19, Michael Feldstein wrote:
>>
>> Um...I'm not sure.
>>
>> Are these superstrings of academic computing proven to exist in
>> sufficient quantity and variety that we are confident that the
>> Grand Unified Theory will work? In a way, what I hear you
>> describing is really sort of a REST bus. Anything that can be put
>> at the end of a URL can be put on the bus. The noun/verb
>> distinction no longer applies, as long as the whatever is URL-
>> addressable. (It's a particle! It's a wave! It's a dessert topping
>> AND a floor wax!) But are we confident that it really makes sense
>> to mash this all into one metadata format? And if so, has anyone
>> else out in the universe done any useful work on a REST bus that
>> might be applicable?
>>
>> - m
>>
>>
>> Michael Korcuska wrote:
>>
>> The talk about entities is confusing. Until it isn't.
>>
>> I think of it as something you want to refer to, or display, or
>> manipulate (e.g. grade) in some way.  It could be a discussion post
>> or a discussion thread. It could be an online test or an online
>> test question or a response to an online test question. It could be
>> an HTML page or a collection of HTML pages.   What we want is a
>> simple way to be able to get at these things.  A nice, clean URL.
>> A RESTful web service. The reason we've been calling them
>> "entities" is because the Sakai service that allows you to do this
>> in Sakai has been called the "entity broker" or the "entity service".
>>
>> And not enough of them exist yet. Sakai needs to be modified to
>> allow more "things" to be referenced/displayed/manipulated in this
>> way. The more of Sakai that is exposed in this fashion, the more
>> flexibility we provide. And if we had more of Sakai exposed then
>> the discussion would be less confusing because there would be more
>> examples (which is what my first sentence meant).
>>
>> Did that help or hurt?
>>
>> Michael
>>
>>
>> On Dec 15, 2008, at 17:18, Michael Feldstein wrote:
>>
>> It made a great deal of sense until I got to the sentence about
>> entities. Let me see if I can break out some of the pieces into
>> sufficient clarity that somebody can at least point to the parts
>> that I have wrong:
>>        * We have this stuff that we colloquially refer to as
>> "content".
>>                * "Content" could be a discussion thread, a blog, a
>> survey, a calendar, etc.
>>                * We want a mechanism access and re-use the content,
>> regardless of type.
>>                * As part of this mechanism, we envision being able
>> to pick particular chunks of the content, e.g., a blog post, a
>> survey question, a calendar entry, etc.
>>                * We speculate it may be possible to create
>> universal packages for content chunks. Michael K has proposed
>> calling these (imaginary) packages "items."
>>        * We have this other stuff that we colloquially refer to as
>> "tools".
>>                * "Tools" represent bundles of related affordances
>> for particular types of actions, e.g., discussing, bloging,
>> surveying, coordinating dates and appointments, etc.
>>                * We want a mechanism to access and re-use
>> individual affordances from the bundles, regardless of type.
>>                * As part of this mechanism, we envision being able
>> to pick particular affordances, e.g., replying to a discussion,
>> writing a blog post, answering a survey question, creating a
>> calendar entry, etc.
>>                * We speculate it may be possible to create
>> universal packages for action affordances. We call these packages
>> "entities".
>>        * We have still other stuff that we colloquially refer to as
>> "web pages".
>>                * Web pages represent the user interface in which
>> users interact with content and affordances.
>>                * We want a mechanism to access and re-use the user
>> interface.
>>                * As part of this mechanism, we envision being able
>> to pick particular chunks of user interface, e.g., a discussion
>> thread interface, a blog posting interface, a survey question
>> interface, a date picker interface, etc.
>>                * We know it is possible to create universal
>> packages for these UI chunks. We call them gadgets or widgets.
>> Items, entities, and gadgets serve analogous but very different
>> purposes by acting as...chunkifiers in their various domains. It is
>> important not to confuse them with each other. At the same time,
>> they can be complementary to each other. For example, one might
>> have a discussion thread widget calling a discussion thread entity
>> and displaying a particular discussion thread item at the bottom of
>> a page.
>>
>> Does that sound even remotely right?
>>
>> - m
>>
>>
>> [hidden email] wrote:
>>
>> I'm only catching up on emails after having been on a holiday, so the
>> point I'll try to make might already have been said in emails which
>> I still
>> need to read :).
>>
>> In my mind, the central content repository where all of the content
>> is being
>> stored in, is completely separate from what we are trying to
>> achieve in the
>> WYSIWYG editor. To me, there is a very big distinction between the
>> content
>> itself (the data and its properties) and displaying active areas in
>> the
>> WYSIWYG editor (display).
>>
>> For me it makes sense to have a central content repository where
>> all of the
>> content is being stored as "what it is and what it contains" (I'm
>> having
>> difficulty to explain). But I don't
>> necessarily want to place this piece of content in my WYSIWYG
>> editor. I want
>> to have a view on that piece of content. One of those might be very
>> close
>> to the content itself, but I might only want a small or particular
>> part,
>> I might want to use it for mashup with other things, ... In other
>> words,
>> I am very cautious for having the border between data and display
>> blur
>> too much and end up in a too technically oriented world.
>>
>> As an example, a poll can be a piece of content, consisting out of
>> the question,
>> the options, the answers (and the general properties as where being
>> used, ..).
>> I might know a site with this poll, and it is really interesting
>> for my
>> site too. I can mark this poll as being of interest to me, but when
>> I come
>> to the point of embedding this into my site, I might not want to
>> have the
>> entire poll in my site, as I would expect if we speak of embedding
>> entities
>> in a site. I want to embed a view on this entity, being only the
>> results for
>> example.
>>
>> Does that make any sense?
>>
>> Nicolaas
>>
>> > Quoting "Plourde, Mathieu" <[hidden email]>:
>> >
>> > Hi Sean,
>> >
>> > Yes, an entity should be able to contain another one. In my idea
>> of what we
>> > are trying to achieve, anywhere a WYSIWYG editor can be use, and
>> entity can
>> > be embedded. And if entities end up being in Resources, then
>> editing that
>> > sub-entity shouldn't be an issue.
>> >
>> > Best Regards,
>> >
>> > =================================
>> >
>> > Mathieu Plourde, MBA
>> > Instructional Designer
>> > IT-User Services
>> > 021 Smith Hall
>> > 18 Amstel Avenue
>> > Newark, DE 19716
>> >
>> > Phone: 302-831-4060
>> > Fax: 302-831-4205
>> > [hidden email]<mailto:[hidden email]>
>> > http://copland.udel.edu/~mathieu/
>> >
>> > =================================
>> >
>> > From: Sean Keesler [mailto:[hidden email]]
>> > Sent: Thursday, December 11, 2008 12:59 PM
>> > To: Michael Korcuska
>> > Cc: John Norman; Content List; Sakai Developers; Nicolaas
>> Matthijs; Tjhien
>> > Liao; Nathan Pearson
>> > Subject: Re: Big concept in Content Authoring
>> >
>> > Does any of the discussion include the idea that a resource/
>> entity would
>> > include one or more others?
>> > Sort of similar to the idea of a photo collection/album Michael
>> > mentions, but may also include items of different types...along the
>> > lines of a portfolio which consists of many different types of
>> items
>> > wrapped with a set of instructions on how to display them.
>> >
>> > Sean
>> >
>> > -------------------
>> > Sean Keesler
>> > 130 Academy Street
>> > Manlius, NY 13104
>> > [hidden email]
>> > 315-682-0830
>> >
>> >
>> >
>> >
>> > Michael Korcuska wrote:
>> > > I think this is what Ihave been imagining, John. A few comments
>> below.
>> > >
>> > > "Resource" is a better word than entity, to be sure, but is
>> loaded in
>> > > Sakai. I don't think I necessarily have a better one...I've
>> been using
>> > > "item" along the way. For my money it is as generic as "entity"
>> but
>> > > less technical sounding. But this is hardly your point.
>> > >
>> > > For browsing/finding "resources/items" I imagine one would want
>> to be
>> > > able to filter the list of items on a variety of criteria
>> including:
>> > >
>> > > * Who created it
>> > > * Individuals that have permission to [view/edit/delete/
>> whatever] it
>> > > * Groups that have permission to [view/edit/delete/whatever] it
>> > > * What content it contains (search)
>> > > * It's name
>> > > * It's tags
>> > > * When it was created/modified
>> > > * It's size
>> > > * The type of item/resource it is
>> > > * It's popularity (how often it has been accessed)
>> > > * Properties "unique" to the type of item (e.g. the number of
>> posts in
>> > > a discussion thread!)
>> > > * What "collections" it belongs to. We haven't really talked
>> about
>> > > the notion of a content collection but this is a common notion
>> in many
>> > > sites that deal with lots of content (e.g. photo management
>> sites)
>> > >
>> > > I'm not suggesting all these be presented to a user in a single
>> > > interface, but I the phrase "universal resources browser"
>> suggest that
>> > > you intend to cast the net pretty wide. And I think an "advanced"
>> > > search or filter capability would want to include these (and
>> I'm sure
>> > > other) criteria.
>> > >
>> > > I must admit I'm not sure what your driving at with Properties.
>> Do
>> > > these govern how the object appears/behaves once you've found
>> it and
>> > > put it somewhere? I can imagine finding a discussion thread,
>> putting
>> > > it on a page I'm authoring and then setting
>> > > the property "DisplayFormat" to "Threaded" or "Flat". Or, after
>> all, I
>> > > might want to simply refer to the object by URL and use the
>> standard
>> > > href target attribute to determine how it opens. If that's what
>> you
>> > > mean I think that's great.
>> > >
>> > > But since you raised this is in the context of a resource
>> browser I
>> > > thought you might be imagining that these properties are used
>> in the
>> > > process of finding the item/resource you want. If so, I'm not
>> getting it.
>> > >
>> > > Michael
>> > >
>> > >
>> > > On Dec 11, 2008, at 16:08, John Norman wrote:
>> > >
>> > >> We have been discussing what a universal resources browser
>> should look
>> > >> like and I have a thought that makes sense to me, but want to
>> check
>> > >> out with a wider group.
>> > >>
>> > >> I think we should use "resource" to mean quite a wide range of
>> things
>> > >> along the lines of Matthieu's "What should an Entity look
>> like?" page
>> > >> ( http://confluence.sakaiproject.org/confluence/x/kQF1Ag). In
>> order
>> > >> for this to work, I imagine we would need a number of resource-
>> types,
>> > >> e.g. ResourceType=DiscussionThread with a defined set of
>> properties
>> > >> (e.g. DisplayFormat=Threaded or DisplayFormat=Flat). I
>> recognise that
>> > >> this is close to the Entity work, but I feel it is more
>> accessible
>> > >> language. One ResourceType might be "File" with a property
>> "Open in
>> > >> New Window". A resource browser for a site or for someone
>> looking
>> > >> across a number of sites would then include ResourceType as an
>> > >> orderable or filterable field so you could ask for all the
>> assignments
>> > >> in Physics101 or all the assignments in First Year Engineering
>> Courses.
>> > >>
>> > >> I'd like to start modifying Matthieu's page along these lines,
>> but
>> > >> wanted to make sure others think this makes sense before going
>> too far.
>> > >>
>> > >> John
>> > >>
>> ------------------------------------------------------------------------
>> > >>
>> > >> 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.
>> > >
>> > > --
>> > > Michael Korcuska
>> > > Executive Director, Sakai Foundation
>> > > [hidden email]
>> >
>> <mailto:[hidden email]><mailto:[hidden email]%3e
>> >
>> > > phone: +1 510-931-6559
>> > > mobile (US): +1 510-599-2586
>> > > mobile (FR): +33 (0)6 31 11 58 97
>> > > skype: mkorcuska
>> > >
>> > >
>> > >
>> > >
>> > >
>> ------------------------------------------------------------------------
>> > >
>> > > 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.
>> > ________________________________
>> >
>> > 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.
>> >
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
>> ) from the DG: Development (a.k.a. sakai-dev) site
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>> --
>>
>>
>> <oracle_sig_logo.gif>
>> Michael Feldstein | Principal Product Manager | +1.818.817.2925
>> Oracle Academic Enterprise Solutions Group
>> 23A Glendale Road, Glendale, MA 01229
>>
>> --
>> Michael Korcuska
>> Executive Director, Sakai Foundation
>> [hidden email]
>> phone: +1 510-931-6559
>> mobile (US): +1 510-599-2586
>> mobile (FR): +33 (0)6 31 11 58 97
>> skype: mkorcuska
>>
>>
>>
>>
>>
>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
>> ) from the DG: Development (a.k.a. sakai-dev) site
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>>
>> --
>>
>>
>> <oracle_sig_logo.gif>
>> 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
>>
>>
>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal
>> ) from the DG: Development (a.k.a. sakai-dev) site.
>> You can modify how you receive notifications at My Workspace >
>> Preferences.
>
> --
>
>
> <oracle_sig_logo.gif>
> 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

----------------------
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.
Jim Eng Jim Eng
Reply | Threaded
Open this post in threaded view
|

Re: Big concept in Content Authoring

In reply to this post by Jim Eng

Thanks, Zack.  Cool demo.

Jim




On Dec 19, 2008, at 2:30 PM, Zach A. Thomas wrote:

> It may help the discussion to throw in a demo of an education
> authoring system that is already conscious of a wide range of content
> types: http://exelearning.org/
>
> And here's a video of it, cuz that's kind of my thing:
> http://aeroplane.s3.amazonaws.com/content-authoring-with-exe.mov
>
> cheers,
> Zach Thomas
> Owner, Aeroplane Software LLC
> http://aeroplanesoftware.com/blog
>

----------------------
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: Big concept in Content Authoring

In reply to this post by Jim Eng

This is interesting.  I'm wondering though, are iDevices templates that
define the purpose of the entire page, or can a page contain more than one
iDevice?  For example, can you have one page with goals + an assignment + a
quiz at the bottom?

Nathan

On Fri, Dec 19, 2008 at 12:30 PM, Zach A. Thomas <[hidden email]
> wrote:

> It may help the discussion to throw in a demo of an education
> authoring system that is already conscious of a wide range of content
> types: http://exelearning.org/
>
> And here's a video of it, cuz that's kind of my thing:
> http://aeroplane.s3.amazonaws.com/content-authoring-with-exe.mov
>
> cheers,
> Zach Thomas
> Owner, Aeroplane Software LLC
> http://aeroplanesoftware.com/blog
>
> On Dec 16, 2008, at 8:55 AM, Jim Eng wrote:
>
> > It seems that somewhere along the line we have said things that
> > imply there will be a simple "universal" user interface for
> > "discovering" relevant items and that there would be some simple
> > "universal" solution to the technical problem of discovering
> > relevant "content" or "widgets".
> >
> > My hope is that to users it will seem like there's just one seamless
> > UI that gives them the ability to do everything they want to do.
> > But I think we were clear in Dearborn and in the bi-weekly authoring
> > meetings that we do not expect some simple "universal" solution that
> > by itself solves the problems of discovering relevant "resources"
> > and establishing how they will be displayed and how users will
> > interact with them in a document, either during authoring or during
> > display of an authored document. We looked at the preliminary
> > version of an "entity browser", which is a proof of concept for
> > parts of the problem. Every time we discussed the entity browser, I
> > think it was with the understanding that getting the user interface
> > right will require work and that the way of choosing or setting
> > display options for particular types of entities will require
> > specialization. It's likely that each webapp within sakai that is an
> > entity provider" will also need to provide UI elements (be they
> > widgets, gadgets or magical thingamabobs) for parts of this process
> > and that we will need something that pulls them together for users.
> >
> >
> > For further discussion related to authoring, please make sure that
> > this address is in the cc-list (or you can add it):
> [hidden email]
> > . The old address (content at collab.sakaiproject.org) is no
> > longer valid.
>
> ------------------------------
>
> This automatic notification message was sent by Sakai Collab (
> https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a.
> sakai-dev) 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.
John Norman John Norman
Reply | Threaded
Open this post in threaded view
|

Re: Big concept in Content Authoring


This concept (creating a page as a stack of sections, some of which  
were active 'tool' sections) was available in Bodington (used at  
Oxford, originating at Leeds) and has partly inspired the thinking. If  
we are reviewing authoring environments, we should not overlook LAMS  
(see "animation" link on this page: http://www.lamsinternational.com/CD/index.html)
 LAMS doesn't create the pages directly, but creates the underlying  
workflow (or 'learning design') for the course or learning unit.

In some future of Sakai, I imagine the activities on pages being  
'sequencable' or controlled by a set of rules. I think of LAMS as one  
of the possible 'workflow engines' that could support the sequencing  
of activities and this interface or similar as the way of an  
instructor defining the sequences.

John

On 20 Dec 2008, at 03:49, Zach A. Thomas wrote:

> Sorry, I was too hasty with my demo; The different iDevices can be  
> stacked together in any configuration on a page.
>
> Sent from my iPhone
>
> On Dec 19, 2008, at 4:49 PM, "Nathan Pearson" <[hidden email]>  
> wrote:
>
>> This is interesting.  I'm wondering though, are iDevices templates  
>> that define the purpose of the entire page, or can a page contain  
>> more than one iDevice?  For example, can you have one page with  
>> goals + an assignment + a quiz at the bottom?
>>
>> Nathan
>>
>> On Fri, Dec 19, 2008 at 12:30 PM, Zach A. Thomas <[hidden email]
>> > wrote:
>> It may help the discussion to throw in a demo of an education
>> authoring system that is already conscious of a wide range of content
>> types: http://exelearning.org/
>>
>> And here's a video of it, cuz that's kind of my thing:
>> http://aeroplane.s3.amazonaws.com/content-authoring-with-exe.mov
>>
>> cheers,
>> Zach Thomas
>> Owner, Aeroplane Software LLC
>> http://aeroplanesoftware.com/blog
>>
>> On Dec 16, 2008, at 8:55 AM, Jim Eng wrote:
>>
>> > It seems that somewhere along the line we have said things that
>> > imply there will be a simple "universal" user interface for
>> > "discovering" relevant items and that there would be some simple
>> > "universal" solution to the technical problem of discovering
>> > relevant "content" or "widgets".
>> >
>> > My hope is that to users it will seem like there's just one  
>> seamless
>> > UI that gives them the ability to do everything they want to do.
>> > But I think we were clear in Dearborn and in the bi-weekly  
>> authoring
>> > meetings that we do not expect some simple "universal" solution  
>> that
>> > by itself solves the problems of discovering relevant "resources"
>> > and establishing how they will be displayed and how users will
>> > interact with them in a document, either during authoring or during
>> > display of an authored document. We looked at the preliminary
>> > version of an "entity browser", which is a proof of concept for
>> > parts of the problem. Every time we discussed the entity browser, I
>> > think it was with the understanding that getting the user interface
>> > right will require work and that the way of choosing or setting
>> > display options for particular types of entities will require
>> > specialization. It's likely that each webapp within sakai that is  
>> an
>> > entity provider" will also need to provide UI elements (be they
>> > widgets, gadgets or magical thingamabobs) for parts of this process
>> > and that we will need something that pulls them together for users.
>> >
>> >
>> > For further discussion related to authoring, please make sure that
>> > this address is in the cc-list (or you can add it): [hidden email]
>> > . The old address (content at collab.sakaiproject.org) is no
>> > longer valid.
>>
>>
>> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal 
>> ) from the DG: Development (a.k.a. sakai-dev) 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 DG: Development (a.k.a. sakai-dev) 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: Development (a.k.a. sakai-dev) 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.
Dr. Chuck Dr. Chuck
Reply | Threaded
Open this post in threaded view
|

Re: Big concept in Content Authoring


John,

I think that we can learn a *lot* from LAMS.  While the "synchronous"  
bit of LAMS leads most to decide LAMS is not for them, the LAMS tool  
protocol is pretty much one of the best I have seen.

LAMS focuses on the entire life cycle of an authored lesson/course -  
from the authoring, configuration, to the use at run time,  tracking /  
monitoring , the the import/export, the ability to email chunks from  
one person to another and have them load up nicely, and a portfolio  
export aspect as well.

Whatever Sakai comes up with in terms of authoring - it would be good  
for that effort to be informed by LAMS and make some effort to meet  
all of the use cases of the LAMS Tool Contract.

http://wiki.lamsfoundation.org/display/lams/Tool+Contract

/Chuck

On Dec 27, 2008, at 11:41 AM, John Norman wrote:

> This concept (creating a page as a stack of sections, some of which
> were active 'tool' sections) was available in Bodington (used at
> Oxford, originating at Leeds) and has partly inspired the thinking. If
> we are reviewing authoring environments, we should not overlook LAMS
> (see "animation" link on this page: http://www.lamsinternational.com/CD/index.html)
> LAMS doesn't create the pages directly, but creates the underlying
> workflow (or 'learning design') for the course or learning unit.


----------------------
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.