Sakai 3, Architectural Choices and Community Impact

Sakai 3Architectural Choices Community Impact

Dr Ian BostonCTO Caret, Chief Architect Sakai

University of Cambridge

The community that developed Sakai

Developers

StudentsAcademics

Universities

Community

Users Researchers Educators

Developers

Community

Designers Developers

Sakai 2.xUsers

Researchers Educators

Community Evolution

Sakai X

Compelling Platform

Strong guidance

Fantastic Tools

Hand and GesturesLocation, GPS,Accelerometer

Compass

Thriving app developer community

Design PrincialsUX Patterns

Power ConsumptionUIKit

LibrariesXCode/DashCode

Developer Education

iPhone

Mobile Industry me-too Samsung, LG etc

OpenSocialShared Standards

Huge Userbase

Leverage Existing Community

OpenSocial APIGadget Spec

Community Driven

600M users20+ platforms

Gadget DevelopersHTML/Javascript

PhpThriving ?315 Million apps installed

Challenges and Motivation

• Evolve the community

• Create an Sakai App ecosystem

• Improve the core product

Choices

Evolve Sakai 2

Conceive Sakai X

DesignersCode base

Quality

CommunityResourcesMigration

Basic Architecture

HTML/JSUI

HTTP REST Server

HTTP JSON

UX LeadUI Developer friendly

Scalablelightweight

App Development

UX Research UX DesignUI

DevelopmentServer

Development

User design research1.3 WORKING WITH THE DATA

We have discussed how to gather data: recruiting your target group, how to prepare and conduct a diary study and interview. Now we will move onto how to work with the data, i.e. analyzing it. The aim is to identify and understand users’ behaviour and their goals. Basically the aim is to construct a set of virtual characters that we will later on call personas. These personas will guide the team further in the design process.

1.3.1 Profiles

Creating profiles – which are summaries of every participant’s information and details you gained during the interview – is an ideal way to remember all the participants you interviewed. This working document can be used during the further data analysis.

A profile - based on all the gathered information, like written notes - would consist of: • A drawn picture of the participant (nice to look at and easier to remember them)• Personal details: name, age etc. • Research related background information (e.g. their department, subject, role)• More detailed information you got from the interview (e.g. we were interested in

what technologies they used and what they used them for)

1.3.2 Task/goal analysis

Task/goal analysis, is a focus on the goals and motivations of the participant, derived from the tasks they undertake to achieve certain goals, their frustrations and so on, as discussed during the interview. This should offer you an understanding of the user’s underlying goals and behaviours.

The main material you will be working with is post-it notes. While reviewing the interview, every criterion you identify (goal, motivation etc.) will be written on another colour of post-it. This way of writing allows you to assign a meaning to every entry and the data to

Examples of profiles

InterviewsDiaries

Observation

be manipulatable as possible, as you can just swap the order of post-its; it also allows the team to familiarize themselves with the data.

1.3.2.1 An extract of a possible interaction during the interview:

“Yesterday I went on my laptop to look at my emails. That's when I saw my supervisor replied to an email of mine requesting a supervision. It took a bit longer this time for him to respond, so the arranged time that I agreed with my supervision mates, may have become not available anymore. I went to one of my supervision mates and asked whether she was still available at that day and time. I also emailed some. When all of them replied, I replied my supervisor to confirm the supervision day and time.”

We break down this extract as follows into a common colour for each goal, etc:

1.3.2.2 Some extra tips on task goal analysis:

• If you want your data to be portable and cuttable later on, big paper can be useful - stick all your post-its to big sheets

• Have lots of colour-coded post-its: regular sizes but in different colours.• Write with black markers: this is readable from a distance.• You may want to write down the names (or the initials) of the person on each

post-it as you will need to know who said what afterwards.

1.3.3 Affinity sorting: identify clusters in the haystack of data

Affinity sorting is used to sort large amounts of data (the post-its of the task goal analysis) into logical clusters which you decide as a team. It allows you to understand relationships within the data in more detail, to analyse the data and identify different

Orange: Goal = arranging supervision

Yellow: Motivations = get success in work

Dark pink: Tasks (How something is done) = Respond, reply and compose new emails

Light pink: Frustrations = Setting up a meeting (synchronizing their time is tough)

Blue: Good things

UX Prototyping

Another important issue around digital prototypes is the degree of depth and interactivity within the prototype; these should be constrained to the purpose of the user test. If the designers would like to get data from the user on a particular feature or user journey, the interactivity and relations between the corresponding elements have to be present, but anything beyond this scope is unnecessary.

In our case, we had to make sure that a user could find a person, document or event in the system in multiple ways. Providing the means to do this is crucial, but doing more is a waste of time at this stage. We had to be sure that all our user journeys are covered and that multiple combinations of activities are possible with the prototype. This meant that more elements were not clickable in our prototype than clickable. We created an OmniGraffle document consisting of 10 pages, with a rough link between each page. The layout and content of each page aims to express minimum functionality, what the system would offer, and the relative importance of various components.

2.3.3 User Testing – digital prototype

In our case a second round of user testing was conducted where we tested our merged concept with the help of a digital prototype. This process was fairly similar to the paper prototype testing, so this section concentrates on the differences between the two tests.

From a practical point of view the main difference is the computer which is involved in the process. The user, after a set of warming up questions is asked to perform a task, or solve a problem within the designed prototype. At this stage is better to have multiple ways of solving a particular task, as at the end, designers can see which way was preferred by most people. In our case this was done by asking a set of warming up questions ("How long have you been using computers?, What social networking tools do you use? etc...") then asking the test participant to find a certain event, document or person within the system. Usually test participants are asked to think out loud and explain what they will expect to see on the next page before actually navigating there within the prototype. It is also good practice to inquire about what can one do on a

A digital prototype

identify the variations and provide feedback on them. To achieve this the concepts should be obviously and visually different. Strengthening the differences between the concepts also helps designers to have a clear idea about each concept, and will help test participants as well, by offering different solutions which can be compared.

We used paper prototyping to evaluate our ideas for helping academics and students communicate about their work.

• The first step in this process was to identify the key screens which were fundamental to describing the system as a whole as we imagined it. Then we could think of the essential elements that these screens should contain, and the characteristics of each page (such as, is it a home page? Is it a profile page?)

• Then, we could take each concept apart, and identify its key differences from the other concepts, which then were drawn out in the prototypes.

• We created 5 screens for each concept, sketching out screen layouts with pen on A4 sheets of paper; one page per screen (this page limit is a good way of selecting the most important elements on the screen which represent any given concept)

2.2.3 User Testing – Concepts

2.2.3.1 Testing

User testing is one of the fundamental elements of UCD, the primary way of involving users from the very early stages of design. User feedback provides data for the designer to make more accurate assumptions and choices in any design problem. This way the target audience can affect system design from the earliest stages, making it more suitable for their needs. This does not mean however that users design the system! Instead it means that users provide valuable feedback data which can be used by the designer to base his decisions on (and thus reducing the number of assumptions). If users attempt design themselves, the results can converge towards a mass of incoherent functionality thrown together; also, users often struggle to think what might be possible, as their thinking can be too constrained by what they are used to dealing with - products and systems that exist today.

An example of a paper prototype

Text

Paper prototypes

Digital wireframes

UI DesignScreens designed as wireframes with interactions.

Implemented as HTML

Integrated into framework

UX Designer, UI Designer

UI Designer, UI Developer

UI Designer, UI Developer

Driving REST API Specification

Foster Usability and Reuse

• No silos

• Permissions separate from membership

• Content everywhere

Code base

0

500,000

1,000,000

1,500,000

2,000,000

Sakai 2.6 K1 K2

Sakai Code3rd Party Code

0

7.5

15.0

22.5

30.0

2.6 K1 K2

Build Time (min)

0

125

250

375

500

2.6 K1 K2

Modules

Code Coverage

0

22.5

45.0

67.5

90.0

Sakai 2.6 K1 K2 Apache Code

Unit Test CoverageAutomated Test CoverageManual Test

?

Resource Usage

0

500

1,000

1,500

2,000

Sakai 2.6 Sakai3

Minimum Requirements

Perm Space StartupWorking Cache

0

500

1,000

1,500

2,000

Sakai 2.6 Sakai3

2G Limit

Architecture

logging

Http

config

authn authz JPA

locking cache

personal public presence

resource

event

messaging searchfriends

JR-API

json mime

cron engine httpauth

openid formauth

JR-access JR-user webdav

servlets resolver scripting

Ruby Python

ESPJR-Client Scala

Shindig

Apache Jackrabbit

OSGi/ Apache Felix

JMS

Email

SMS

XMPP

IMAP

POP3

VersionManager

PersistenceManager

IMS CC ICOM Rules Workflow

IMS LIS

LDAP

HTTP REST + JSON

Caldav

Enterprise Integration

Apache Jackrabbit

OSGi/ Apache Felix

EIS

Kuali Student

ID DAM AWS GData

gDocs

Twitter

Institutional Enterprise

Internet Services

Cloud Future

Apache Jackrabbit

OSGi/ Apache Felix

PersistenceManager

Oracle HBaseMySQL

MSSQL DB2

Postgres

Derby

Tarball GMail

Voldemort (LinkedIn)

Traditional Storage Cloud Storage

Casandra (Facebook)

DevelopmentGitHub

Local Git

Pull

Local Git

Push

Clone

MergePush

Developer

ElectedMerge

Manager

Status

Growing designer involvement

Better app community support

Lighter, more scalable, faster back end

design process, growing designer involvement

friendlier environment, simpler skills requirement, stronger guidance

less Sakai code, more standards code, fewer resources

Are we nearly there yet ?

NoDocumentation

Developer trainingMigration

IntegrationDeveloper tools

EvanglismApp sharing framework

Questions ?

Ian Boston: [email protected]