Outline

• Analysis & extrapolation of a few trends – Web 2.0: the new Desktop? The Future of User Interfaces in Web 2.0 – Collaborative computing in Web 2.0 – Offline applications & storage in Web 2.0 • Implications & predictions Wolfgang Stuerzlinger – Changes to development process York University, Toronto – A few observations & predictions

Why is Web 2.0 successful?

• Web 2.0 offers services – Not applications • Any time, any platform, any location Web 2.0: The New Desktop? • Users are in control – Control access to their data – Choose their services, add to them, collaborate via them,… • Harness collective intelligence – E.g. transition from Taxonomy ⇒ “Folksonomy” & Tagging • Offers real advantages to many people

Web 2.0: The New Desktop? Example: Desktoptwo

• Most traditional applications available in Web 2.0 – Gmail, Google Calendar – Google Docs – …

• Seems to obviate need for traditional “desktop” • Web – Operating system under browser still necessary • But a blurry boundary (iPhone)

1 Web Desktop with Files Web 2.0 Equivalent: Service Aggregation

• Clone Desktop Idea • Different mential model – Advantage: familiarity – Clean break better (less confusion) – Disadvantages • Example: iGoogle • UI performance hit – Configurable by user, everybody’s needs are different! • Speed performance hit • Files - again? • Not really “Web 2.0” – Web 2.0 is about services – Also no collaboration support - desktop is inherently single user

Another way: Desktop Widgets

• Integration of Web into desktop – OS X Dashboard, … Collaborative Computing in Web 2.0

• Finally: Web 2.0 not for everything – Most 3D games, high-performance computing, big simulation, visualization, etc.

Collaborative Systems - CSCW / Groupware CSCW/Groupware Development

• Collaboration • Different from software for individuals – Group of people with common goal – Developers can never know all potential users & their jobs – Goal large enough so that it can’t be tackled individually • Many different target users • Computer Supported Collaborative Work (CSCW) • Managers are biased, too • Critical mass issue • CSCW apps must support • Lot’s of collaborative services on Web 2.0 – Information sharing (easy on Web) – Email, encyclopedia, scheduling, office applications, … – Awareness (hard on Web) – CVS, bug tracking, feature requests, … – Coordination (hard on Web) – Internal company information systems, …

2 Four CSCW/Groupware Design Principles Maximize Personal Acceptance (1)

• Maximize Personal Acceptance • Address disparity in work and benefit – Visible benefits, no training, … – CSCW often more work for those who don’t benefit • Minimize Requirements – Example: group calendars – Any time, location, platform, unobtrusive collaboration, … • Manager able to control your time – ⇒ People don’t use it (rejection) • Minimize Constraints – Or people block days at a time (subversion) – Support roles, allow exceptions, … – Reduce burden to non-beneficiaries • External Integration • Easy-to-use, efficient to use – Data exchange, … – Generate personal (!) benefits • E.g. private use of Blackberry Based on [Cockburn94, Grudin94]

Maximize Personal Acceptance (2) Minimize Requirements & Overhead

• Facilitate adoption • Any time, any location, any platform, … – Example: hospital, only 1 of 5 nurses uses SW ⇒ disaster – Web 2.0 good at that (except not offline) – Low entrance threshold • Unobtrusive CSCW features • Easy-to-learn design – Information sharing and editing • If training required, make it painless • Mostly reading, but encourage contribution – On site, multiple times, user’s schedule – Awareness – Alternative: Screen videos/tutorials • What are others currently doing? • Need to be done well, too – Coordination • Identification of ownership, changes, etc. • Features must be present but never predominant!

Information Sharing & Editing Awareness (Coordination of the Present)

• Example: Wikis • Well known in Chat – “Jill is typing …” • Helps avoid conflicts

• But can be much more – Jack is currently adding calendar entry on Oct 24 – John is currently editing part X of project Y – Jim started editing “Future plans” on current page at 3pm

3 Coordination of the Past Coordination of the Future

• Who did what, when? • Who is planning what? – Not just retrieval, but also comparisons, etc. – Example: Wiki discussions, roadmaps, …

Minimize Constraints External Integration

• Support roles and exceptions • Permit other tools – Organizations have both formal & informal work patterns – Bi-directional data exchange with other systems • CSCW applications tend to flatten hierarchies • Another way to ease adoption • Helps with emergency back-out – May disadvantage some users & threaten their “domains” – If your system is fulfills user’s needs well, this will never happen • Exception handling – Reassurance factor – “This needs to be authorised by Ms. S but she is away for • Web 2.0 services must allow users to retrieve all their data 3 weeks” … “I’ll see if I can get Mr. J to sign for her” – Otherwise: lot’s of workarounds – Humans good at exception handling & improvisation – Flexibility is key here!

More Reflections on Collaboration in Web 2.0

• One of the key features of Web 2.0 – Increasingly more collaborative features • In the future more: reviewing, commenting, … Offline Web 2.0 Applications • What works – Leave individual user in control • Flexibility is key • Otherwise abandonment or lot’s of workarounds – Do one service well • Don’t try to do everything at once – Support user fully in their tasks

4 Offline Web Applications Source of Inspiration

• Main deficiency of Web 2.0 • Mobile Computing Platform – No support for offline work • I.e. when no network connectivity – PDA’s & Smartphones – Algonquin park • Palm/Treo, WM6, Blackberry, iPhone, etc. – Subway – Foreign country – Addition of wireless networks serious “boost” – No network • “Crackberry” addiction – Insecure environment – … • Some people use mobile computing more than desktop! • Offline apps already available today – Best user interfaces: iPhone, Palm – E.g. OS X dashboard “widgets” are Javascript! • Problem: no persistency

How to Enable Offline Work Synchronization

• Keep local copy of data • Local copy – Usually only “touched” data – User edits data when offline • Cache – Changes to be uploaded on re-connect – Better a bit more (see later) – Also download recent changes by others • If network • Conflict resolution – (Upload local updates) – Use network directly – Easy if only one side updated since “time of last sync” • Cache requests • Newest change wins • If no network • Better ideas … (later) – Use local copy • Maps well to Web 2.0 - ! – Store updates

User Interface for Synchronization (1) User Interface for Synchronization (2)

• User's view syncing as a bug, not a feature. • Users don’t understand diff/merge interfaces • Need basic UI that sync is occurring – Diagnosis when network is acting up or sync is failing

• Sync should happen automatically – On first load, network (re-)connect, periodically (autosave) – Users rarely can predict when they will be offline • Local copy of “essential”, “owned”, and “touched” data

5 User Interface for Synchronization (3) Problems with Synchronization

• System needs to make reasonable sync decisions • Issues to think about – Ideally fine-grained – Network delays (async!) • E.g. A changes title of contact, B changes the address ⇒ OK! – Many changes (async!) – For longer documents – Partial syncs due to network drop, crashes (both sides) • Annotate each change – New changes can occur during a sync – E.g. “Track Changes” in Word • User should never loose data – In conflicts, last change survives – System never in unusable or inconsistent state • However, overwritten version must be stored in history – Note: history anyways necessary for collaboration!

Offline Technologies: “Hacks” Offline Technologies: Google Gears

• Store data in Cookies • Three main parts – Well-known problems – Local Server • Store data via Adobe Flash (shared object), ActiveX • Stores all Web requests, if offline delivers cached copy (COM), XPCOM (Firefox), … – Database • SQL lite (variant) – Limited amounts, not platform/browser independent – Worker Pool • Form data storage • for long(er)-running tasks – Limited amounts • Internet Explorer DHTML feature – Also: Sync Engine – Limited to 60k • Worker for synchronization • Store application/data as URL’s – Fairly good, up to limit of browser URL cache • Available for PC, Mac, Linux – Currently not yet on Palm, iPhone, WM6, …

Offline Technologies: Others

• Dojo Offline Toolkit – Part of Dojo AJAX framework – Support for offline storage • DojoSQL and DojoStorage (key-value pairs) Changes on SW Development in Web 2.0 • Encryption for stored data – Support for synchronization • HTML 5 (draft standard) – Offline storage of key-value pairs as well as SQLite – Will be available in Firefox 3, … • Most probably also in IE – No support for synchronization, yet

6 Effects on Development Safety / Security / Availablility

• Shift from applications to services • Services should be always available – More users ⇒ more beginners – Google already “world-wide critical infrastructure” :-) • Hence, usability #1 priority, not more features – Design for user’s needs – 99.999+% availability – Do not maximize functionality, minimize it • Offline support helps here • More features make everything harder to find – Ideally no crashes (server & client) • User has no time for tutorials, documentation,… – “Ballons” may work well • Encrypt data • Alternatively, 3 different levels of service – Transmission – Beginner, intermediate (most users), expert (a few) – Back button = undo for everything – Local cache • Store changes even across sessions – Never share user’s data without explicit permission – Good visual design, avoid web terminology, KISS, … • Allow bookmarking of screens

Technical Web 2.0 Trap Web 2.0: Opportunity

• Update everybody’s “program” at almost any time • Get immediate feedback from actual use – Advantage & disadvantage – Continuous feedback • Fix everybody’s service immediately – Fast identification of problems • Break everybody’s service immediately • Is a feature actually used? – Hard for user to revert in this case, as no local copy (!) – Monitor successes » Disaster • When & where do users abort / fail? • Another problem: caches not always updated immediately – Monitor partial “transactions” – Can be months: 4 week vacation, 2 week conference, 2 week sick – Fast adaptation possible • Necessitates good version management – Must always allow upgrade “old” data versions • Key aspect of Web 2.0 business model • With no user effort (or at the worst minimal effort)

Future Web 2.0 Toolkits Effects on Development Teams

• Collaboration support • Web 2.0 necessitates “back-end” & “front-end” • Offline & sync support – Front-end: Focus on users & their tasks • Encapsulate Web 2.0 UI “look & feel” • Mix of IT, UI, CSCW designers • Current examples • Typically more code here than at backend – Dojo – Back-end supports front-end – Google Web Toolkit + Google Gears • Must not dictate front-end development • Focus on system stability, data security, performance • Future • Often shared among different projects – Web 2.0 UI toolkits – Both need to collaborate to succeed – Web 2.0 CSCW toolkits • Special needs back-end code similar to “middleware” – Web 2.0 Offline & sync toolkits

7 Web 2.0 SW Development Model Change

• AJAX fundamentally changes code – In particular: “Asynchronous” • Hence, back-end cannot control UI Closing Thoughts

My Advice for Web 2.0 Technological Advice for Web 2.0

• #1: Test your user interface • Technical advice – Even more important than on desktop – None (on purpose) • #2: Get the basics right (standard Web UI guidelines) • Technology is just a means, not an end! – Simple design, consistent UI, clear navigation, good feedback, error – Support collaboration resistant, as simple as possible, CSCW, offline & sync, … – Support off-line storage & synchronization • #3: Communicate clearly • Both will become common in Web 2.0 – Users want to spend minimum time • Quickly & easily convince them that your site is worthwhile • #4: Provide what users need • Remember: the “invisible” computer wins – Match their expectations & needs – See your parents car, cell-phone, etc. • Research requirements most carefully – Our job to make Web 2.0 as invisible as possible

Disclaimer Trademarks

• Company, product, or service names identified in the text may be trademarks or service The IBM Center for Advanced Studies (CAS) regularly marks of IBM or other companies. Information on the trademarks of International publishes technical documents that are aimed at Business Machines Corporation in the United States, other countries, or both is located facilitating an exchange of information. These reports are at http://www.ibm.com/legal/copytrade.shtml. written by individuals or groups of authors and represent • Java and all Java-based trademarks are trademarks of , Inc. in the their opinions and do not necessarily reflect those of United States, other countries, or both. • Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft IBM. In the event of questions or concerns regarding Corporation in the United States, other countries, or both. individual reports or presentations, email addresses have • Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered been provided for most authors. Alternatively, please feel trademarks of Intel Corporation or its subsidiaries in the United States and other free to contact CAS at [email protected]. CAS is countries. • is a registered trademark of The Open Group in the United States and other dedicated to providing a forum for IBM employees, countries. research affiliates, and university students to publish • Linux is a trademark of Linus Torvalds in the United States, other countries, or both. results of their work, their views on technical issues, book reviews, and workshop reports. • Other company, product or service names may be trademarks or service marks of others.

8