[DG: Teaching & Learning] templates redux

[Keli Sato Amann]

Hello Bruce, 
I'll do my best to talk about templates the way I'm coming to understand it, though someone may correct me. I'm not a software engineer, so this may still not be what you are asking for.

Sakai 3 has groups of people and it has content, including the communication that these people engage in. In theory, these things can be configured to look like just about anything: a website, a cluster of free-floating files that a particular group has access to, an activity feed, etc. So at the risk of using old vocabulary, one needs site templates to at least get the structure that the content will fit into: at minimum, what types of pages are there? what types of roles are there and the rules for what they can do in both the composition of the site and the group.

But within that site template there are also page templates, which what I think you are concerned about. Page templates do provide pre-populated html, in the sense of structure, boilerplate text and graphics, but they should also provide html references to widgets. These widgets could either display data from other parts of the system (activity feeds) or other external websites (maps, videos, boilerplate text). They could also be used to solicit data entry in a structured way. We don't have all the widgets we need right now, but that's the idea at least.

The question is whether those page structures should be locked into place--requiring certain elements to be in *particular* layout. Right now, they are NOT locked and if I'm reading this right, this is what you find troublesome. If you look at the 3akai server, you'll see two types of pages--what's currently called a blank page and a dashboard page. Each contains widgets, but have different ways of editing those widgets. Blank pages require you to go into edit mode where you can edit text in wysiwyg or html; you can also access the widget settings in edit mode. Dashboard pages do not have an edit mode--you move widgets around and change their settings right there. One advantage of the dashboard style is that they might allow finer control over what is editable because the user never gets to edit the html--you can edit the widgets but not the layout, or you can move the widgets around, but not change what's in them or delete them. 

I'm back from a four month leave and I'm currently working on the OAE team to describe the organization of the elements one might need in these templates at the page and site level, starting with courses. But I'm not designing the way one is creating that organization, that's in the hands of the designers, so I'm bcc'ing a few people so they are aware of this thread and in case I've misspoke. 

Keli Amann
User Experience Specialist
Academic Computing Specialist, Stanford University

----- Original Message -----
From: "Bruce D'Arcus" <bdarcus at gmail.com>
To: "Sakai UX" <sakai-ux at collab.sakaiproject.org>, "pedagogy Learning" <pedagogy at collab.sakaiproject.org>
Sent: Friday, April 1, 2011 1:53:00 PM
Subject: [DG: Teaching & Learning] templates redux

This is sort of a followup to earlier question yesterday about
portfolios, and to a more technical question I raised about how
"templates" are understood in OAE back in August of last year.

<http://collab.sakaiproject.org/pipermail/sakai-ux/2010-August/001440.html>

In a subsequent reply, John explained that "For now the main way a
template works is as a way of providing pre-populated html."

I really don't understand the reasoning behind this: why it's
important (or I guess more specifically, why this particular solution
to the need for reuse), and why it's defined this way.

Today I read new content like this on the wiki about "templates" ...

<https://confluence.sakaiproject.org/display/3AK/Out+of+the+Box+Course+Templates+Discussion>

... and am again asking "what are OAE templates again?"

Meanwhile I read recent discussions of the ePortfolio initiative about
using XForms to do portfolios, which seems really mostly because it's
not apart of the core OAE architecture.

So I'd like to make a more affirmative suggestion (rather than just
asking a question): you need to better define a core concept like
this, and to do it in ways consistent with broader software
engineering usage: as something like a method of binding a data model
to an output view (which appears to be what the portfolio group is
after).

I don't think it does any good to call what is effectively dumb (in
the sense of having no structured meaning) copied HTML a template;
it's just copied content.

A template, then, should be what both the portfolio group and core OAE
functionality needs (at some point; no huge rush): a method to
facilitate more structured authoring of content (syllabi, say).

And for sake of more concrete and forward-looking argument, what if
templates in OAE might be based in part on this sort of a direct
WYSIWYG editor:

<http://www.aloha-editor.org/demos/960-fluid-demo/>

... where one could just easily create, and move around (via
drag-and-drop*) these editable  divs**?

Bruce

* say like this <http://demos.9lessons.info/ddorder/UIpage.php>

** and this example of 3 column CSS in place editing is pretty cool
too <http://aloha-editor.org/demos/3col/>
_______________________________________________
pedagogy mailing list
pedagogy at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/pedagogy

TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"