Sakai 3, Architectural Choices and Community Impact

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

The community that developed Sakai Developers Academics Students Universities

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

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

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

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

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

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

App Development UI Server UX Research UX Design Development Development

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

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

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 Speciﬁcation

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

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

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

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

Architecture HTTP REST + JSON IMAP personal public presence IMS CC ICOM Rules Workﬂow event JMS POP3 Shindig friends conﬁg 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

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

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

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

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

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

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

Sakai 3, Architectural Choices and Community Impact

by AuSakai on Sep 25, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 10

Statistics

Sakai 3, Architectural Choices and Community Impact — Presentation Transcript