What Should an Entity Look Like?
1. Sakai Entities
The UX group also refer to these as "vignettes". A list of potential vignettes is available on this page: Potential Vignette Use Cases.
One of the cornerstones of the Content Authoring idea is that entities (or resources or items or parts or fragments or ...) should be URL addressable. Currently many Sakai tools only allow access from a single, top-level URL, and the user has to manually navigate to specific views or items within the tool. In some conversations the work that needs to be done to enable such direct access to tool content has been called "entification", but in more standard web 2.0-speak, we are referring to REST (REpresentational State Transfer), or, in other words, talking about enabling RESTful access to tool content.
Anthony Whyte et al. have prepared a "how-to" document on entifying Sakai tools.
Entities could be generated by the following tools:
Source:
Claude Coulombe
2. Outside Entities
Outside entities may
- not need to know anything about the user
- may need to know who the user is in an insecure way
- may need to know who the user is in a secure way
- may store information about the user or contributed by the user that Sakai does not need to access/store
- may store information about the user or contributed by the user that Sakai does need to access/store
Media and dynamic content:
Type |
Variations |
---|---|
Video |
Link, icon, thumbnail, embedded with player, description, tags |
Audio |
Link, icon, embedded with player, description, tags |
Image |
Link, icon, thumbnail, description, tags |
RSS feed |
Title, date, user, content, embedded media, summary, tags |
Javascript widget |
Sakai must allow pasted HTML code from trusted sources |
URL (bookmark) |
Link, icon, thumbnail, iframe?, user, description, comments, tags, relative and absolute |
For the following entities, do we want to be able to create them from scratch in the workspace, create them in another web application, or simply link to them?
Type |
Variations |
---|---|
Structured Vector Graphics (SVG) |
Link, icon, thumbnail, embedded |
CML - Chemistry |
Link, icon, thumbnail, embedded |
MathML - Mathematics |
Link, icon, thumbnail, embedded |
MusicML - Music |
Link, icon, thumbnail, embedded |
VRML - 3D Graphics Viewer |
Link, icon, thumbnail, embedded |
OML and OPML - Outline markup language |
Link, icon, thumbnail, embedded |
Spreadsheet |
Link, graph, diagram, tabular view |
Formatting entities:
- Sections (like with this wiki)
- Columns
- Floating containers with wrap-around text (div-like)
- CSS link/in-line editing
- Reusable content units (somewhat pre-constructed objects that could be replicated elsewhere)
- Templates
3. Entity States
- Listed: Entity has not been placed on page. Depending on the selected design (drag and drop from sidebar, insert button with wizard, etc.), this listed entity might look totally different.
- Placed:
- Linked to: Entity has been placed on page and is simply linking to the real thing. Looks like a simple URL.
- Embedded: Entity has been placed on page and has different visualization options or trigger zones.
- Popped-up: Hovering a placed entity shows more info about it.
- Broken: Target entity is not available anymore.
- Conditional:
- Denied: Target entity is not available to current user.
- Hidden: Target entity is not available to current user and hidden from him/her.
- Granted: Target entity is available to user because user has satisfied a/multiple condition(s) for the revealing of the entity (by completing a quiz, being a part of a certain group/section, date driven, Gradebook, Post'Em, Assignment entry satisfactory, etc.).
- Edit mode: User is changing the behavior of an entity through a menu.
4. Entity Picking Scenarios
Mathieu's original mockup from the Paris conference.
Scenario 1: Sidebar
In this scenario, the entities can be revealed/hidden by clicking or dragging a sidebar. Afterward, entities will be dragged and dropped on the work area. When an entity is dropped, a menu will pop up to offer visualization and permissions options.
Advantages |
Inconvenients |
---|---|
- Can be hidden easily. |
- Uses prime editing real estate. |
Scenario 2: Insert Button
In this scenario, clicking on the Insert button will trigger a wizard that will take over the screen (could fade the background, like in Nathan's designs). It could also replace the URL icon since it serves the same purpose: adding something to the page.
Advantages |
Inconvenients |
---|---|
- Non-intrusive, apart of the toolbar. |
- Extra clicks to get to the entities. |
Scenario 3: Floating Widget
In this scenario, a button in the WYSIWYG editor could toggle on and off a floating widget from which entities could be picked and dropped in the work area. Like the first scenario, when an entity is dropped, a menu will pop up to offer visualization and permissions options.
Advantages |
Inconvenients |
---|---|
- Can be hidden easily. |
- Can get lost if too far away from the work area. |
Here is an example of a floating WYSIWYG widget from Wikispaces:
5. Listing/Adding/Editing Entities
- Scenarios 1 and 3: Drag and Drop
- Scenario 2: Simple Entity Linking (Most probable scenario)
6. Permissions and Tracking
Depending on the user type, some features or tools might be unavailable. At the page level, we could make a page trackable for two reasons: 1) to trigger a release/hide condition, and 2) to keep track of the users who viewed the page, in a SCORM-like fashion.
7. Wiki Considerations
Question: Do we still need a wiki tool if we get a nice WYSIWYG editor up and running?
A key functionality of a wiki is the ability to add a page (by clicking on a button, or by linking to nowhere). Other than that, it's a way to author content. If we include the page creation behavior in or project, we might not need the wiki anymore, or we might leave it there to let the users decide if they want to use it. Adding versioning is another important feature.
Another point of view would be to offer a wiki editing mode for regular HTML pages.