Keynote Speaker - Sakai 3, Architectural Choices and Community Impact Ian Boston, Chief Architect, Cambridge University:

1. Sakai 3
Architectural Choices
Community Impact
Dr Ian Boston
CTO Caret, Chief Architect Sakai
University of Cambridge

2. The community that
developed Sakai
Developers
Academics Students
Universities

3. Community Evolution
Community
Sakai 2.x Users
Users Researchers
Researchers Developers Educators
Educators Designers Developers
Sakai X
Community

4. iPhone
Compelling Platform
Hand and Gestures
Location, GPS,
Strong guidance Accelerometer
Compass
Design Princials
UX Patterns
Power Consumption Fantastic Tools
UIKit
Libraries
XCode/DashCode
Developer Education
Thriving app developer community
Mobile Industry me-too Samsung, LG etc

5. OpenSocial
Shared Standards
OpenSocial API
Huge Userbase Gadget Spec
Community Driven
600M users
20+ platforms
Leverage Existing Community
Gadget Developers
HTML/Javascript
Thriving ? Php
315 Million apps installed

6. Challenges and
Motivation
• Evolve the community
• Create an Sakai App ecosystem
• Improve the core product

7. Choices
Evolve Sakai 2
Designers
Code base
Quality
Conceive Sakai X
Community
Resources
Migration

8. Basic Architecture
HTML/JS UX Lead
UI Developer friendly
UI
HTTP JSON
HTTP REST Scalable
lightweight
Server

9. App Development
UI Server
UX Research UX Design
Development Development

10. 1.3 WORKING WITH THE DATA
User design research We have discussed how to gather data: recruiting your target group, ho
be manipulatable as possible, as you can just swap the order of post-its; it also allows
conduct a diary study and interview. Now we will move onto how to w
the team to familiarize themselves with the data.
1.3.2.1 An extract of a possible interaction aim the interview:
i.e. analyzing it. The during is to identify and understand users’ behaviou
Basically the aim is to construct a set of virtual characters that we
“Yesterday I went on my laptop to look at my emails. That's when I saw my supervisor
replied to an email of mine These supervision. It took awill guide for him team further in the design proc
personas. requesting a personas bit longer this time the
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.”
1.3.1 Profiles
We break down this extract as follows into a common colour for each goal, etc:
Orange: Goal = arranging supervision
Creating profiles – which are summaries of every participant’s inform
Yellow: Motivations = get success in
work
you gained during the interview – is an ideal way to remember all the
Dark pink: Tasks (How something is
done) = Respond, reply and compose This working document can be used during the further data
interviewed.
new emails
Light pink: Frustrations = Setting up a
A profile - based on all the gathered information, like written notes - wou
meeting (synchronizing their time is
tough)
Blue: Good things
• A drawn picture of the participant (nice to look at and easier to re
• Personal details: name, age etc.
Interviews • Research related background information (e.g. their department
• More detailed information you got from the interview (e.g. we w
Diaries what technologies they used and what they used them for)
1.3.2.2 Some extra tips on task goal analysis:
Observation •
•
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 Examples of profiles
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
1.3.2 Task/goal analysis
Task/goal analysis, is a focus on the goals and motivations of the pa
from the tasks they undertake to achieve certain goals, their frustratio
discussed during the interview. This should offer you an understand

11. UX Prototyping
Digital wireframes identify the variations and provide feedback on them. To achieve this the concept
should be obviously and visually different. Strengthening the differences between th
concepts also helps designers to have a clear idea about each concept, and will hel
test participants as well, by offering different solutions which can be compared.
An example of a paper
prototype
Text A digital prototype
Paper prototypes
We used paper prototyping to evaluate our ideas for helping academics and student
communicate about their work.
• The first step in this process was to identify the key screens which wer
fundamental to describing the system as a whole as we imagined it. Then w
could think of the essential elements that these screens should contain, an
the characteristics of each page (such as, is it a home page? Is it a profil
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 wit
pen on A4 sheets of paper; one page per screen (this page limit is a goo
way of selecting the most important elements on the screen which represen
any given concept)
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
2.2.3 User Testing – Concepts
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, Testing
2.2.3.1
but
anything beyond this scope is unnecessary. User testing is one of the fundamental elements of UCD, the primary way of involvin
users from the very early stages of design. User feedback provides data for the designe
to make more accurate assumptions and choices in any design problem. This way th
target audience can affect system design from the earliest stages, making it mor
In our case, we had to make sure that a user could find a person, document orsuitable itforin that users provide not meanfeedback data which can be usedsystem
event their needs. This does valuable however that users design the by th
Instead means
the system in multiple ways. Providing the means to do this is crucial, but doing more is his decisions on (and thus reducing the number of assumptions).
designer to base
users attempt design themselves, the results can converge towards a mass o
a waste of time at this stage. We had to be sure that all our user journeys are covered

12. UI Design
Screens designed as
wireframes with
interactions.
UX Designer, UI Designer
Implemented as HTML
UI Designer, UI Developer
Integrated into
framework
UI Designer, UI Developer
Driving REST API Specification

13. Foster Usability and
Reuse
• No silos
• Permissions separate from membership
• Content everywhere

14. Code base
Sakai Code Modules
Build Time (min)
3rd Party Code
2,000,000 30.0 500
1,500,000 22.5 375
1,000,000 15.0 250
500,000 7.5 125
0 0 0
Sakai 2.6 K1 K2 2.6 K1 K2 2.6 K1 K2

15. Code Coverage
Unit Test Coverage
Automated Test Coverage
Manual Test
90.0
67.5
45.0
22.5
?
0
Sakai 2.6 K1 K2 Apache Code

16. Resource Usage
Perm Space Startup
Working Cache
Minimum Requirements 2G Limit
2,000 2,000
1,500 1,500
1,000 1,000
500 500
0 0
Sakai 2.6 Sakai3 Sakai 2.6 Sakai3

17. Architecture
HTTP REST + JSON
IMAP personal public presence IMS CC ICOM Rules Workflow event JMS
POP3 Shindig friends config resource messaging search locking cache Email
Caldav logging json mime authn authz JPA openid formauth SMS
JR-access JR-user webdav cron engine httpauth Ruby Python XMPP
JR-API JR-Client Http servlets resolver scripting Scala ESP IMS LIS
Version Persistence LDAP
Apache Jackrabbit
Manager Manager
OSGi/ Apache Felix

18. Enterprise Integration
EIS Twitter
Kuali
Apache Jackrabbit
gDocs
Student OSGi/ Apache Felix
ID DAM AWS GData
Institutional
Internet Services
Enterprise

19. Cloud Future
Apache Jackrabbit
OSGi/ Apache Felix
Persistence
Manager
Postgres Oracle MySQL Tarball HBase GMail
Casandra Voldemort
Derby MSSQL DB2
(Facebook) (LinkedIn)
Traditional Storage Cloud Storage

20. Development
GitHub
Clone
Elected Push Push Pull
Merge Merge
Manager
Local Git Local Git Developer

21. Status
Growing designer involvement
design process, growing designer involvement
Better app community support
friendlier environment, simpler skills requirement, stronger guidance
Lighter, more scalable, faster back end
less Sakai code, more standards code, fewer resources

22. Are we nearly there
yet ?
NoDocumentation
Developer training
Migration
Integration
Developer tools
Evanglism
App sharing framework

23. Questions ?
Ian Boston: ian@caret.cam.ac.uk