[DG: Teaching & Learning] [DG: User Experience] templates redux

[John Norman]

I think this conversation is a little dangerous. Dangerous in the sense that two incomplete pictures of different parts of the landscape are being compared and found wanting.

We should probably try to get Nico to weigh in, but our ambitions for OAE and templates are quite consistent with Bruce's ambitions and portfolio comments. However, we are not there yet (by a long way) and in the meantime we have something far simpler that is in the code/UI. This does not represent our end point, however, we will release something with this simpler model and Keli is trying to imagine how the simpler model can be useful at that release point.

Unfortunately, we have a habit of describing things as 'Sakai OAE does (or does not) xxx' where a more accurate phrase might be 'the incomplete prototype is currently capable of (or not) xxx'. Current capabilities are not even necessarily on a linear path to our end goal. They are reflections of what we can achieve in known time/resource steps.

HTH
John

On 2 Apr 2011, at 05:17, Keli Sato Amann wrote:

> 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"
> _______________________________________________
> sakai-ux mailing list
> sakai-ux at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
> 
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"