3akai Sketches

This is how a user's personal dashboard will look.

1. These menu options have a functional purpose and a communication purpose. They allow users to quickly orient themselves and locate major areas of interest in Sakai. They also send a strong message about the type of product Sakai is.

I have included "Groups" in this set for now, but frankly, I'm not sure I see how groups will be used at this level. We can create a unique site type for ad hoc groups which allows for a presentation that emphasizes only a few basic ideas, ex: discussions, members, files. But beyond this idea, I'm not really sure how groups are different from sites.

2. Persistent utility links. The mail icon implies a messaging system within Sakai.

3. This search bar will appear in virtually every main screen in Sakai. A search will return a search result screen which yields context sensitive matches. In other words, if the user searches for something while in their dashboard, the system will return a result that weights relevant findings within the user's files, personal messages, or other data that belongs to him or her.

Beyond that, the system will display results for sites, people, groups, etc., across the entire Sakai network. If on the other hand, the search is used while in a site, the results will be weighted to the content on that site.

The search results screen will be an important screen and will require a fair amount of time to design. The screen will have various filtering and sorting features that will allow users to quickly find the content they're looking for. This implies a content architecture with heavy statistics and meta data.

4. This is the user's dashboard links and profile summary.

The Edit Profile link will present the user with a UI where he or she can change their photo, add personal information, etc. There will be other ways to access the same UI.

The Messages link presents that same UI as the mail link in the persistent utility links. There may be other ways to access this UI - for example, we may have a dashboard widget that shows a list of N most recent messages.

Preferences will allow the user to control email notifications, time zone, etc.

5. This is a widget. I'm sure we can dream up all sorts of widgets that an academic user would find helpful. For example: Important dates, my grades, my to-do's, etc.

6. These buttons will allow the user to add new widgets to the page. The Options button will allow the user to change the layout, maybe change colors, and possibly other settings. This may be replaced by a "Change Layout" button, allowing the other options to fall under the Preferences link in the user's dashboard links. Or it's possible to go the other way and fold the Preferences link under this Options button.

This is how a typical site will look.

See Page View 1:

1. This is the page title. Below it are two important links: "Add a New" and "Publish Site". The former allows users to add a new page, dashboard, or tool to the site (see 1a). The latter walks the user through a wizard to package the content in the site and publish it.

This Publish Site feature is quite different from anything we're doing in Sakai. It's also quite different from any other wikis or site builders. The basic idea is that there are two forms of sites: the first is what is presented here, which is the "working" site. This site has a very collaborative wiki presentation and applies to 85% of Sakai's use-cases. In these cases there may never be a need to publish the site. The second is a "presentation" site, which is the result of publishing the content found in the working site.

During the site publishing process, the user will be presented with a wizard that guides him or her through packaging the content and presenting it in many different formats. For example, the content could be presented as a basic website, a resume or portfolio site, or any other type of site we can dream up.

The site publishing wizard will make use of templates, to expedite the publishing process, as well as fine grained control.

Pages that are published can either be "live" or "static". If live, changes that take place on the working site will be automatically updated to the live site. A static page can only be updated manually.

A site can be published as many times as the user wants - allowing for multiple simultaneous publications, each using different URLs, different design templates (presented in different formats & styles), and different access controls.

Publication settings can always be changed even after the site has been published. A published site can also be duplicated if desired.

2. These are the site links. Any page in the site can be designated as the "Home" page.

The Sitemap will allow for various forms of browsing and search all the pages (and perhaps other content) in the site. I'm currently thinking that the page architecture will be flat, and that hierarchy is implied with navigation inks. However this may change as I think through it more.

Members is self explanatory (details TBD).

The Related Sites link will display sites that have been manually related by users as well as auto-related by way of statistical analysis.

The Published link will display an interface for managing published instances of the working site.

Site Settings is self explanatory (TBD).

3. These buttons will allow users to edit the page and perform various other actions (see 3a).

4. This is the sidebar. It is a deceptively simple feature. The sidebar implies a templating architecture within Sakai. For example, at the bottom of the sidebar, there is a link to edit it. This will present the use with a typical edit page view. In other words, the sidebar is a typical web page (wiki page without the wiki syntax). The only difference is that the "sidebar" template was applied to it. This template not only designates the page to be used as a sidebar, but also filters a set of widgets that are only relevant for the sidebar.

So in this example, the "Browse categories", "Browse tag cloud", and "Related pages" sections are widgets. These could either be the starter set included in all working sites, or perhaps the user chose these when he or she edited the sidebar.

While the widgets may be page aware, the sidebar itself is site oriented. In other words, the widgets selected for the sidebar will be the same across the entire site. But the content within those widgets may change depending on the page. For example, the Related pages widget is displaying a list of incoming and outgoing links based on the page.

5. These sections will allow the display, navigation, and editing their related features.

See Page View 4:

1a. Clicking the "Add a New" link will present a drop down menu with three options: Page, Dashboard, and Tool. Notice that the Dashboard option is gray. This is because there can only be one site dashboard per site. The same with tools - a tool can only be instantiated once per site.

There are still many questions around these options. For example, why does a tool need to be "added" to a site? Can't it just have an omnipresence that can be linked to? Also, can't a dashboard be similar to Google sites dashboard, where it's constructed by the user by editing a standard page?

I have my own answers to these and other questions, but would like to hear your thoughts first.

See Page View 5:

3a. These options are not entirely thought through. This is just a started set to fuel discussion. To quickly summarize:

Page Settings will allow the user to control what features the page will have; for example, should it allow tagging, should it display a sidebar, etc.

View Changes is a link to the revision history. Notify Me of Changes is like a "watch page" option - which emails the user when changes take place.

Sharing & Privacy are access control features.

I hope all the others are fairly self-explanatory

See Page View 2:

4a. We can also dream up other widgets. Here is an example of a photo carousel. This widget lets the user cycle through photo attachments on this page. If there are no photos on this page, the widget heading is not displayed. The same is true for all other widgets that are page aware.

Clicking on a photo will present a page with a photo album UI. The same is true of all other widgets in this sidebar (and in general of most any widgets added to a page). The widget displays summary data and a narrow set of controls. By clicking on it, the user may be taken to a full screen UI that relates to the widget.

See Page View 3:

4b. If desired, any user can minimize the sidebar. The sidebar can be completely removed in the Site Settings area that is available to site managers.

No detail as of yet.

This is an example of the Site dashboard page. A site dashboard can only be used once per site. It can also be designated as the home page, though that is not required.