SAIL portal requirements

Ideas and discussions about a new rudimentary, vanilla SAIL portal that is generic and extensible.

Basic Overall Requirements

1. manage user accounts
2. manage user groupings
3. manage and deliver curriculum
4. authentication
5. authorization
6. email
7. skinable
8. i18n

User Management Requirements

1. sign up (do we enforce required unique email address?)
2. user administration (delete, suspend accounts, etc.)
3. define roles (teacher, student, researcher)
4. assign students to workgroups (teacher assigns or students assign?)
5. concept of a class? teacher has a list of classes, and a student belongs in a class
6. password reset (send email to user)

Curriculum Management Requirements

1. curriculum administration (delete inappropriate content, etc.)
2. upload curnit to host based storage
3. link to externally stored curnits
4. require authorization for all curriculum management tasks
5. dynamically generate JNLP for launching curnit

Community and Mentoring requirements

1. Mentoring and Community

Possible technologies and/or packages to be used

Portal frameworks

Alfresco - Alfresco is an open source enterprise content management repository and portlets (CMS) built by a team that includes the co-founder of Documentum. Its modular architecture uses the latest open src Java technologies: Spring, Hibernate, Lucene and JSF.

Liferay - Liferay Portal is an open source portal that helps organizations collaborate more efficiently by providing a consolidated view of disparate applications. It is used by large and small organizations all over the world. Liferay has an extensive list of features that compares with most commercial portals but without the high license fees.

Generic web application frameworks

AppFuse - AppFuse is an application for "kickstarting" webapp development. Download, extract and execute ant new to instantly be up and running with a kick-ass Java webapp running on Tomcat/MySQL. Uses Ant, XDoclet, Spring, Hibernate (or iBATIS), JUnit, jMock, StrutsTestCase, Canoo's WebTest, Struts Menu, Display Tag Library, OSCache, JSTL and Struts (Spring MVC, WebWork, Tapestry and JSF are also options).

Grails - Grails aims to bring the "coding by convention" paradigm to Groovy. It's an open-source web application framework that leverages the Groovy language and complements Java Web development. You can use Grails as a standalone development environment that hides all configuration details or integrate your Java business logic.

Trails - Trails is a domain driven development framework in the spirit of Ruby on Rails or Naked Objects. The trails project aims to make Java enterprise application development radically simpler by allowing developers to focus on the domain model and having other portions dynamically generated. We will leverage existing technologies such as Spring, Tapestry, and Hibernate rather than reinventing the wheel.

TO BE ADDED ABOVE

10/25 - some notes from Jim

Here are a couple of Portal functions that are important.

1. Authoring.

The ability to come into portal and find those curnits that you had authored, and had authoring permissions on. The ability to share authoring permissions on those projects for which you have ownership. WISE had this nice ability to type in partial usernames and get a list of WISE users, from which you could select the one you were searching for. This may have been a violation of security - not sure. It would suck to have to know the exact username to ascribe permissions to, but maybe that's the way it should be.

2A. Student registration under a teacher.

Here, a student needs to be able to attach himself or herself - or to be attached by hand by someone else - as "belonging" at least temporarily to a teacher. They might belong to more than one teacher (e.g.,k in English, and math). They would like to keep their user account from one year to the next, but there is a huge problem of them forgetting their WISE usernames (e.g., "JimS32") - and really made more sense just to re-register them the following year. This part of the WISE portal was slightly broken although to its defense we made it work fairly well - just always frustrating at some level.

2B. Class/Student offering.

A teacher needs to be able to set up periods to run with a curnit. Closely related to 2A - where the teacher basically adds 180 students into 5 periods, shuffles students into various periods if they registered for the wrong period, etc.

3. Communities or subgroups.

This is a 'circle" of users who basically share things by virtue of being in the group. Groups I can imagine are groups of teachers within a school, groups of teachers concerned with one topic (e.g., frogs or climate change), groups of designers working on one curnit, with numerous versions). These groups may not share everything - there should be some nice user interface for assigning what gets shared (e.g., would teachers share their students' work with all other teachers in their group? Could they if they wanted to?

4. Multilingual features.

Here, we had something pretty good going with the WISE multilingual features. Any WISE user from any other country could come to WISE, and start the language translation process for the WISE student interface, authoring interface, grading tools, etc. You can see this feature at: http://wise.berkeley.edu/teacher/resources/wiseInTranslation.php

In designing SAIL, we made an explicit specification that language would be separated from content. The aim of this was to really enable a multilingual curnit, and a multilingual portal. We have more talking to do about this - maybe we should make a wiki page about language. I know Cynick has direct experience with this, from his prior efforts within ATRC. Also, Turadg had his eye on industry translation management systems - not sure if any are open source, and could be customized, but he had been looking at Rosetta: https://launchpad.net/rosetta

Thoughts on groups from Jim on 6/12/2006.

On the portal design, I don't know where we left things with the whole grouping process - where students see each others' sock contents. But as I move forward in the "SAIL Smart Space" design (firmly into non-pas territory...) it looks like one thing that will invariably occur is to swap kids in and out of groups on a fairly regular basis.

While I'm thinking about it - a couple notes and examples:

Often this would occur "by design" - e.g., at time of authoring, I suppose what would be the curnit. Grouping would be done either into a set of categories (e.g., groups A, B, C, D), or into groups with a certain number of students (3, 4, 5, 6).

The curnit author could also have groups rotate what category they are assigned to (i.e., the same group of 4 start out working on category A together, while the other categories do their thing, then the A folks go into category B, the B group moves into C, etc. I suppose this doesn't change the grouping at all, but illustrates that groups may be manipulated in terms of what they are working on.

Another kind of grouping would be what is known as "jigsaw" - where you start out grouping everyone into "specialization groups" (e.g., the questioners/hypothesizers, the background researchers, then data analyzers and the concluders) - then after they've done some focused activities on their specialization, you re-group people so that a new set of groups is determined where each group has one person from each of the previous specialization categories. I think there's an even more stringent view of this, where then you re-do the whole thing successively until you've made sure that every kid gets a chance to play every specialization role - but I suppose if we can solve the first case we could do that monster (not sure what curnit would ever have enough TIME to allocate to such a design...)

Another kind of group would be the dynamic grouping, where kids are sorted into their group based on content from previous pods in the curnit (e.g., assessment responses, or just "select your preferred group") -

or I suppose even more dynamic, where they just go to a chat room and find partners and create their own groups.

Hopefully this is enough "group think" to bend your mind a little! If you want to put those notes up into docs.telscenter, or expand on them, go right ahead. I've had trouble getting that wiki to come up today, for some reason.