Groups and Themes and Things

This page is a slightly edited (for brevity and readability, hopefully not content) email exchange between John Norman, Nathan Pearson, Clay Fenlason and Michael Korcuska that should have been on-list. Hopefully the table of contents will help as well.

A note from John Norman to Nathan Pearson (April 4, 2008)

Hi Nathan,

This is great work, but I'd like to make some observations. I hope I don't sound too critical, because you are really doing excellent work.

First, I'd like to make a general point about the site creation pages from last week. I feel they don't go far enough in reforming current practice and still contain that most American concept, the 3 part course code. There should at least be an option to give courses a code by some other mechanism - e.g. we don't have sections in the UK. But my biggest issue is the process is still cumbersome. I like the way you create a group in Linked-in and suggest we aim for an experience more akin to that model. Selecting the logo is a particularly useful step in branding the site which is often missed by faculty, allowing the logo to appear on your profile page invites some really interesting loyalty/rewards type thoughts.

More comments inline:

On 4 Apr 2008, at 22:20, Nathan Pearson wrote:
Hey guys,

So I'm rounding out broad strokes of the design and will soon be digging into the details a bit more.  But already certain questions have been keeping me up at night.  I'll post a formal summary on confluence (once I get a chance to catch my breath), but I wanted you guys to begin mulling these ideas over a bit.

1. We need a better understanding of the difference between My Account, My Profile, and Settings (Dashboard and Site).

My view is that the My Account functionality should be related to account management issues only (password, email, timezone, etc.)

Settings is related to site management (naming the site, configurations, access control, backup, copy, etc.)  I'm starting to re-think if members should be in the Settings area or if they might better fit in a separate Member tool (or Roster tool in the case of a course site).

As for "My Profile", I think this should be a tool (as opposed to an integrated feature in the site settings, as I've recently presented) that lets users build and manager a MySpace, Linked In, Facebook type environment.  This profile would have two sides (edit and view).  The edit view would allow the user to add his/her photos, update bio, add friends, etc.  The view would be accessible via a direct URL or some searchable tool in Sakai that let's users see and interact with other profiles.

This idea is certainly more involved than the former two, but well worth pursuing in my opinion since if it's done right, it can add a nice new dimension to what Sakai has to offer.  But just to set expectations, I don't see this being fully fleshed out in this two months.  Still, if this is a desired approach, it's good to discuss it now so I can prepare the current screens to match this direction.

I'm not sure why all of this functionality is not in one place (although I don't think it sits easily in *site* settings unless I am supposed to expect it to change from site to site). I think of it as the information that is about me as an individual, who I am, how I am represented in Sakai, how I want Sakai to look and work for me ("Preferable" tool and "settings") and what I want to tell the world about me (which should have a facebook-like baseurl/myname url for the public information). The tricky bit is that in different institutional settings, different bits of information will be in Sakai and different bits in other places. Some of the external information will allow edits from Sakai others will not. So we need a flexible way of indicating which data elements are from external sources and which are not editable in Sakai (with information about where to go to edit). For example, we pull default email from an external LDAP directory so we would want something like "go to www.lookup.cam.ac.uk to change this information" alongside the data or alongside a data block where all the elements had similar characteristics. This is where we should place a "mypublications" feed from the institutional repository. Of course, my thinking is coloured by our lack of an institutional portal apart from Sakai. Those places with strong portals may feel things like "mupublications" belong in the portal. It will be an interesting challenge to work out how to cover both options, but again I assume it will be done with "blocks" of information that will be configured to "omit" if the site runs a portal in the opposite of the information inclusion for email described above.

Later we will be adding "who my friends are" and related elements

2. In the designs I've proposed (inspired by existing functionality in Sakai) there are three site management features emerging:

a) Import/Export - Let's a user export a site (including content, layout settings, select widgets, sidebar or no sidebar, etc.) -- then import everything into a new or existing site.

b) Copy - Let's a user copy a site.  At first I was thinking a copy should automatically imply the content is copied also, but now I'm thinking that users should be given an option to copy with or without content.

b) Templates - which is something I'll present in Monday's demo.  Templates will be both pre-defined by the institution or a user can save his/her site in a template form.  Once a template is created, it can be applied to any site -- thereby changing the site's settings, layout options, selected widgets, etc. to those that are defined in the template.

This is where the plot thickens.  For example, in my export concept, I'm suggesting the ability to select multiple sites and export them into one consolidated file.  What if site A has a sidebar on the left, site B has a sidebar on the right, and side C doesn't have a sidebar at all?  Also, keep in mind, that in order to support "pages" the sidebar is required -- for various reasons.  Anyway, what monstrosity of an export will be achieved in this case?

Why is the sidebar needed for "pages"? In WordPress, a site can have pages in a tab bar across the top or a block in the sidebar. We just need to know that there are pages and what they contain. An export may include a template, but it should not be flattened. That way if an exported site is reimported into Sakai, a different template could be provided (e.g. when moving a course from year to year, which seems to be common practice in the US).

Round 2 between John and Nathan

Nathan,

First comment, not necessarily linked to previous comments. I have always worried about "project" sites. The name only rarely corresponds to what it is used for. It occurs to me that we could look at the sites more in terms of who is in them and thus they could be "group" sites or "community" sites. This invites me to speculate that there could be value in making the choosing of members come earlier. This probably needs a bit more thought.

On 4 Apr 2008, at 23:57, Nathan Pearson wrote:
No worries about being too critical. In fact, now is the time for that! We all need to scrutinize the direction as much as possible.

A few quick comments before I get back to work for the day..

The reason pages are coupled with the sidebar is because that layout option allows for a virtually limitless amount of pages in the vertical direction. Going horizontal forces us into all sorts of UI gymnastics, like: a dynamic roll-up of page tabs that don't fit a variable browser width, limiting the number of horizontal tabs, allowing tabs wrap (line-break), etc. So to avoid those issues, I made a trade-off for the moment in order to have enough time to get at other parts of this design. We can revisit the issue as a future enhancement, so long as the current approach isn't a show-stopper when it comes to some of the other functionality around templates, importing/exporting, etc. If it is... well... we'll just cross that bridge when we get to it.

This is probably more an implementation issue, but I think it would be a mistake to implement in such a way that you build in layout assumptions. So, for example, if we are contemplating a template based world, why not apply a tab metaphor template to a site with few enough "pages" that it works? I suspect, the answer may depend on the likelihood that additional pages will come later. But in general I see it as a problem for the template authors (or site owners) and I don't think the implementation should bake in assumptions about layout.

As for international campus issues, I apologize but this will be a learning process for me. I am however trying to keep the layouts fairly flexible so that if any unique information needs to be added, it can be done fairly easily. I'm not sure if a one size fits all solution is appropriate here. Maybe the best way to go is to offer some sys admin config and templating options around this kind of thing.

I think that for course setup there should be a lot more that is configured by institution and the wizard should adapt automatically. Thus your slides are a demo of one particular (popular) wizard, but a different one (more than one?) would be possible driven by a system wide configuration. If we were to contemplate more than one, perhaps it should be via some sub category of course or a selection among multiple course types (e.g. studio-based course for art). I can't see multiple course types being valuable unless the course catalogue/matriculation is very different. Maybe it could be important for an institution made up of many diverse campuses (like SUNY).

Regarding the Linked-in group creation process, I'm not sure how it's so different from what I've proposed. I've just added an interim step that let's users choose how they want to create a group. Either build a new one, use a template, copy and existing one, or import one from a file. Going down the "build a new one" is almost identical to Linked-in. Just name it, give a description, and you're off.

I think that's the point. It is much quicker and simpler. It is a question of how much is in the setup process and how much is in configuration of the site once it exists. The advantage of keeping the first step short and simple is to get to the approval step as quickly as possible. If you don't need to get approval, the distinction between setup and configuration blurs.

Of course, I haven't fully completed the "created a group" process in Linked-in, so maybe you're referring to some steps further into the process?

Anyway, I look forward to more feedback!

Round 3, regarding layout and templates

On 5 Apr 2008, at 11:06, Nathan Pearson wrote:
...

"This is probably more an implementation issue, but I think it would be a mistake to implement in such a way that you build in layout assumptions. So, for example, if we are contemplating a template based world, why not apply a tab metaphor template to a site with few enough "pages" that it works? I suspect, the answer may depend on the likelihood that additional pages will come later. But in general I see it as a problem for the template authors (or site owners) and I don't think the implementation should bake in assumptions about layout."

So that's just the thing. Imagine if the site owner has site A with 50 pages. He export site A (including all the pages). Then he builds site B – which disables the sidebar (but offers pages as tabs in the header) and then he imports site A. How do you visualize all 50 pages from site A fitting into site B?

We could place the onus on the site owner to realize that this decision turned into mashed potatoes.. but I'd prefer not leaving them hanging with something so catastrophic, if you will.

I'm going to labour this only because I think there is some fundamental misunderstanding somewhere and I'm trying to work out where it is. The key seems to be in when and how the template is applied (or possibly in what we think a 'template' is and does). You seem to be implying you see it as an irreversible decision, made before the site can be viewed and thus a real problem for the site owner if the imported site displays badly. I see it differently, site template can be changed at any time (my mental model is wordpress themes). I also imagine the sequence for site import to be 1. Create new site (title, description, owner), 2. import old site (select content) 3. apply template (review and possibly modify).

Now there is a consequence for this model, which may be helped by the soon-to-be-introduced hierarchy system. The options you have for course templates (or even non-course templates) may be limited by institutional policy. So (for example) the Engineering department may decide that all engineering courses will use the same template (a real case for us). But that does not mean the Engineering template will be identical to the English department template and Architecture may decide that all of their courses are encouraged to create distinctive templates but use them consistently from year to year. This is why I want flexibility, even if the institution decides to lock it down for their deployment. I agree we could make an arbitrary decision and say "hey this is Sakai" but it puts huge importance on getting that decision right.

Does this make sense?

John

Nathan expands on Templates and Themes

I don't think our view on templates is entirely different – at least in terms of the value they offer the user.

To be clear, I do see templates as something that can be changed on the fly at any time the site owner wishes. The difference I think in my view is what the result is once a template is changed.

I also think a template and a theme are two different things, so I would like to keep the concepts separate for now. From that perspective, I think the wordpress analogy more closely resembles a theme idea rather than a template idea.

Let me see if I can explain the difference:

Theme

A theme in my view makes a fundamental change to the UX, and possibly the product in general. Changing a theme could theoretically change the perceived nature of the product. I realize that's vague comment, so bare with me.

As I've mentioned in my previous email, one theme might be imagined as a portal presentation with drag and drop widgets while another theme might offer a more structured environment. Take Google groups for example. They have a specific layout that can't really be modified by the user. What you see is what you get with them. In contrast, MyYahoo gives users more freedom to personalize their layout by adding pages, moving widgets around, etc.

Both however use similar tools: calendars, email, addressbooks, bookmarks, etc. From that perspective, Google groups and MyYahoo could actually be the same product, only re-packaged with a different theme. The theme is what controls how the tools are presented to the end user.

This would imply the following hierarchical relationship:

Sakai --> Theme --> Site --> Template --> Tools --> Data (content, users, etc.)

From within a Sakai deployment, a theme is selected. Once a theme is selected, sites are now built within the boundaries of that theme.

Once a site is laid out and configured to the extent possible based on its particular theme, it can be saved out as a template for re-use within that same theme. Tools and data are the universal building blocks that can transcend themes.

Perhaps a way to help crystallize my point is to think about all the design work I've been showing to-date as "a theme". Other themes can be designed as well.

Template

A template is a saved package containing layout and setting configurations based on a particular theme. For example, all the stuff I've shown in the site settings area could be captured in a template and applied to some other future site that uses the same theme. This would include color scheme, site name, description, etc. Also, if a site owner added pages, defined the layout of those pages, and added certain widgets to those pages – all this could be captured by a template.

Therefor, assuming you're using a particular theme, a template can be used either as a starting point in building a new site (generating a site shell based on a template) or as a way to apply saved settings and layout options to some existing site.

As for the wordpress theme analogy... I think it better matches what I've described above as a theme, not a template. One indication for this is that switching themes in wordpress is simply not as seamless of an operation as one might imagine. While some basic objects, like blog posts, carry over from one theme to another, other theme specific modifications are not so gracefully realized and can break the site. A template, in my view, should never be able to break site!

Anyway, I think this is a healthy discussion so let's just make sure we understand each other. Sorry if I'm not being as concise and clear as possible, but I'm not operating on too much sleep at the moment.

Nathan

Clay chimes in

First a reply without reading John's. Forgive me if this leads into
redundancy, but I'll have to catch up to the rest of the thread later.

Re: #1

There seems to be a member of this family of concepts missing: what
about those settings (or in current language, "Preferences") that cut
across sites?

Re: #2

I don't understand the difference between copying a site without
content and using a template, and would wonder if the former might
muddy some expectations, and prove to be ultimately an unhelpful
option. In fact, why could not any existing site be referenced as a
template without a "saving" action? It might feel like a nuisance to
come to the point of site creation and then realize "Oh, I need to go
back and copy that other site instead," or "Oh, I need to go back and
save that other site as a template first."

~Clay

Clay and John on Project Sites and Groups

Clay

On Sat, Apr 5, 2008 at 6:06 AM, Nathan Pearson <me@nathanpearson.com> wrote:

"First comment, not necessarily linked to previous comments. I have always
worried about "project" sites. The name only rarely corresponds to what it
is used for. It occurs to me that we could look at the sites more in terms
of who is in them and thus they could be "group" sites or "community" sites.
This invites me to speculate that there could be value in making the
choosing of members come earlier. This probably needs a bit more thought."

Yep, I totally agree. That's why I went down the path of offering course vs
non-course sites – keeping the non-course site idea as generic as possible
so that users can build whatever type of site they want.

I wonder if that doesn't go far enough. I found myself in the curious
position lately (while discussing the idea of enterprise group
integration) of arguing that Sakai really doesn't create groups. It
creates spaces (or sites), and then grants access to an ad hoc
collection of people as a secondary matter. The definition of the
group amounts to "Whoever can access this site right now," and there
is little user experience of these groups persisting beyond the
context of the site. By the same token, a relatively weak sense of
group identity.

What if that got turned around, and the people came first? What if
site setup were simply the last step of group setup? Perhaps that
won't work out well, but it seems something worth pressing on.

John
I am interested in this line of thinking.

The focus for a 'group' can take many forms

1. The focus can be a purpose; this year's Carnival planning
2. A group of friends who are interested in what each other are doing and who help each other out (Social Networking concept)
3. A group can be defined by membership rules, e.g. the Provost's IT Committee and has a record-keeping function as well as collaboration
4. A group could be for a research project (with external members)
5. The group could be a collaboration space for an ad-hoc study group (not necessarily on the same course at the same time, but more likely than not)
6. The site could be the place you go to express an opinion on campus issues (authenticated) membership = campus login
7. The site could be the place you go to express an opinion on Department or College issues, or to find restricted access documents
etc.

I can carry on if this is useful. Maybe we should move some of this to the Wiki...

A critical question is whether the nature of site setup should be affected by the type and purpose of the group. There is certainly a gap in provision of a campus group service. We have toyed with moving into that space a number of times. The Computing Service claims part of the space for some 'official' groups (e.g. Departmental membership) with an LDAP directory, but does not stray into ad-hoc groups of any kind.

Michael, Clay and Nathan on Copying Sites

Clay

"I don't understand the difference between copying a site without
content and using a template, and would wonder if the former might
muddy some expectations, and prove to be ultimately an unhelpful
option. In fact, why could not any existing site be referenced as a
template without a "saving" action? It might feel like a nuisance to
come to the point of site creation and then realize "Oh, I need to go
back and copy that other site instead," or "Oh, I need to go back and
save that other site as a template first."

Nathan
This a good point. Perhaps the answer here would be to consolidate the template feature into the copy without content option. This would offer the same benefit to the user as a template, without the abstract "template" terminology.

When creating a site, the user could then copy a site with or without content, as well as have options to pick from pre-defined sites made available by the system admin. I think this could get us to the same place in a rather clever way without the confusion of having so many similar concepts.

Only problem with this idea is if we ever wanted to offer users the option of sharing templates. Can you share a site copy? And if so, which type... those with or without content? But I think that might be too far down stream for us to worry about at the moment.

Michael
Powerpoint handles this fairly well (as loathe as I am to admit this). I have a current presentation (or am starting a new one) and I want to use a particular theme. I can apply the theme from a either a pre-defined set of themes or I can choose an existing presentation and apply the theme that it uses. I think of a pre-defined theme, often codified as a template (.pot) than a presentation (.ppt), as one that has been well thought out and "blessed" for reuse. The .pot doesn't contain content (usually, although there is nothing that prevents this). I'm never confused about what is happening.

I think this analogy holds up here. I can build my site from a template or I can apply the template used by (or maybe it is better to say "implicit in") a particular site I like.

Also, I do think changing templates could "break" a site (at least temporarily). I'm assuming that a template contains, for example, information about what tools are present. If I apply a template where a tool is missing then I could have a "broken" site (where is that discussion forum I need?). But this could be fixed by adding that back to the site, although it would be missing potential layout/presentation/other information (since the applied template didn't have that tool).

You could imagine the wizard detecting that kind of problem and warning the user. You could also imagine that the theme (yes "theme") would contain default preferences/hints for tools and that the target site would simply pick up those up if the weren't present in the template (or, rather, the template carries them even for tools it doesn't use...this is an implementation issue, I'm fairly sure).