sakai 3, architectural choices and community impact
Post on 22-Oct-2014
2.144 views
DESCRIPTION
Keynote Speaker - Sakai 3, Architectural Choices and Community Impact Ian Boston, Chief Architect, Cambridge University:TRANSCRIPT
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
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
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]