The Fluid Project and the New State

1. The Fluid Project and the New State Antranig Basman, Core Framework Architect, The Fluid Project

2. Roadmap • Who am I, and what is Fluid • Fluid Academic and Fluid Engage • Fluid Infusion and Fluid Kettle • New Approaches: IoC and State • Where we’re headed

3. Antranig Basman • BA and Part III, Mathematics, Cambridge, 1994 • PhD, Information Engineering, Cambridge, 1999 • Senior Developer, Amedis Pharmaceuticals, 2001-2002 (ADME Prediction) • Chief Software Architect, Choracle Ltd., 2002-2004 (Drug Toxicity Prediction) • Consultant, CARET, University of Cambridge, 2004 – • Core Framework Architect, Fluid Project, 2008 –

4. Fluid... http://fluidproject.org • Is an open source community of • Designers • Developers • Accessibility experts • Helps other open communities • Consists of universities, museums and individuals

5. What We Do • Offer design advice and resources • Contribute to other communities: • jQuery UI • Dojo • W3C Accessibility • Build Infusion, our JavaScript application framework • Build Kettle, our JavaScript server-side infrastructure

6. The Strategic Nature of Javascript • Designed in 1995 as “LiveScript” • Syntax ordered by Netscape at last moment to be “more Java-like” • “OO” features bolted on at the last moment • Until recently: • Has received little CS attention • not taken seriously as a programming language • Most code produced of low quality with little attention to scalability and engineering principles

7. The Strategic Nature of Javascript II • Actually a functional programming language, and OO features are a distraction • Now receiving serious engineering efforts from Google, Mozilla, Microsoft • Performance enhancements previously considered impossible for an untyped language (“type speculation”, class-based optimisation) • Underlying language theory developed by Douglas Crockford, and now by us • Becoming attractive for uses other than in user agents (persistence via CouchDB, server middleware through Kettle)

8. Javascript: The Good Parts • First presentation of what has come to be called “that-ism” • Many other hygienic Javascript practices

9. Two functional snippets function invert(func) { return function() { return !func.apply(null, arguments); } } var isOdd(a) { return (a % 2) === 0; } var isEven = invert(isOdd); • Unlike the C/C++/Java family of physical resemblance, function invocations allocate heap storage. function curryAdd(a) { return function(b) { return a + b; } } var add2 = curryAdd(2); var four = add2(2);

10. That-ism var creator = function(arg1, arg2) { var privateState = arg2; ... var that = {}; that.publicState = arg1; that.publicMember = function(arg) { return arg + privateState + that.publicState; } }; return that; }; • All of the useful physical effects of programming with “objects” with none of the encumbrance of types and inheritance • Encapsulation of private state • Unforgeable bindings to self reference • Context-safe members (including 0-arg for use as event handlers) • http://fluidproject.org/blog/2008/07/21/about-this-and-that/

11. Namespacing and Versioning var fluid_1_2 = fluid_1_2 || {}; var fluid = fluid || fluid_1_2; (function ($, fluid) { var private = 3; fluid.publicFunc = function(){ { // All file contents here })(jQuery, fluid_1_2); • Standard armouring for every source file • All internal and external clients agree on use of “fluid” symbol • All versions remain in the address space and accessible via simple assignment • Better than the affordances of many “mainstream” languages (C/C++/Java)

12. The challenge of scale-free programming • Many books available on “refactoring”, “design patterns”, other aspects of OO philosophy • Very few books available on underlying motivation of code structure, and planning for indefinite growth • In general, “object orientation”, types, and APIs can appear as a source of dependency weakness rather than a strength – especially in large-scale designs over long timescales • An appealing idea is also that understanding lessons from the largest scales help us to properly organise the smallest scales

13. Lakosian Dependency • The only rigorous approach (IME) to the function of dependency in logical design • Not just another “C++ gimmicks book” - issues which cut across all languages, and all designs • http://rsf.fluidproject.org/Wiki.jsp?page=Levelization

14. Implications of Levelization 3 A What happens here? Arrow Of Knowledge • Lakos takes us this far – but raises (at least) two major concerns • How does this structure get constructed? • What does the code in A come to look like, given that, for example, it may need to broker a functional interaction between G and H? 2 2 B C 0 1 0 1 D E F G 0 0 0 0 H I J K

15. Introducing http://fluidproject.org/products/infusion/

16. Role of Infusion • “Application framework” built with jQuery as foundation • Originally conceived as a client-side framework, but “DOM-free” portions now deployed on server • Open architecture: “more than usual” configurability is required

17. What’s in Infusion? • A development framework for building apps • UI components you can reuse and adapt • Lightweight CSS framework for styling • Accessibility tools and plugins for jQuery

18. Building Great UIs Is Hard • Your code gets unruly as it grows • UIs are hard to reuse or repurpose • Design change requires big code change • Accessibility is confusing • Combining different code/libraries doesn’t always work

19. Flexible User Interfaces • Infusion is an application framework designed to provide unprecedented flexibility while preserving interoperability.

20. Types of JavaScript Tools • Foundational Toolkits • Application Frameworks ... compare and contrast

21. Foundational toolkits • Totally presentation focused • DOM manipulation • Event binding • Ajax jQuery Prototype Dojo core

22. Application frameworks • Model notifications “something changed here” • Views to help keep your presentational code clean • Data binding to sync the display with your model SproutCore Dojo/Dijit/Dojox Cappuccino

23. Infusion is Different • Accessibility baked right in • Carefully designed interactions • Markup is in your control • Not the same old MVC • Model-based idiom is enriched with a conception of “transparent state • Controller layer is destroyed

24. A Metaphor: UX Weave freeform knit & crochet fabric by Prudence Mapstone

25. A Metaphor: UX Weave hand-dyed weave by Felicia Lo

26. Engage’s Technology Goals • Enable great design • Interconnected data • Approachable: easy to extend/adapt • Bridging: connect physical and online • Scalable (up & down) and forward-looking • Fun, cheaper, easier development

27. The Open Web Today • Multi-touch gestures • Audio and video • Vector graphics and animation • Great accessibility • All work on mobile today! • Stable and deeply interoperable • Everyone knows it

28. Engage at a Glance • Interconnected data: services and feeds • Bridging spaces: mobile apps • Exhibit toolkit: great user experiences • Making connections: mapping • Accessibility all the way through

30. The Mobile Experience

31. Big Question for Museums: What platforms should we support?

32. Everything?

33. Everything? Objective-C Java C++ Cocoa Touch Android SDK Carbide

34. Only One?

35. Only One?

36. Mobile: Embrace the Web • Phones now have great browsers built in • Web design is ubiquitous and familiar • Use standard HTML, CSS, and JavaScript • Blends seamless into existing sites • Thin native apps provide access to interactive features (camera, bluetooth)

37. Hybrid App Illustrated

38. Deeply Accessible

39. What is Accessibility?

40. A New Definition • Accessibility is the ability of the system to accommodate the needs of the user • Disability is the mismatch between the user and the interface provided • We all experience disability • Accessible software = better software

41. Assistive Technologies • Present and control the user interface in different ways • Not just screen readers! • Use built-in operating system APIs to understand the user interface Screen readers Screen magnifiers On-screen keyboards

42. DHTML: A New Can of Worms • Shift from documents to applications • Familiar a11y techniques aren’t enough • Most DHTML is completely inaccessible • New techniques are still being figured out

43. The Problem • Custom widgets often look, but don’t act, like their counterparts on the desktop • HTML provides only simple semantics • Not enough information for ATs • Dynamic updates require new design strategies to be accessible

44. The Solution • Describe user interfaces with ARIA • Add consistent keyboard controls • Provide flexible styling and presentation

45. Supporting Assistive Technology

46. Opaque Markup • // These are tabs. How would you know? • <ol> • <li><a href=”#cats”>Cats</a></li> • <li><a href=”#dogs”>Dogs</a></li> • <li><a href=”#gators”>Gators</a></li> • </ol> • <div> • <div id=”cats”>Cats meow.</div> • <div id=”dogs”>Dogs bark.</div> • <div id=”gators”>Gators bite.</div> • </div>

47. Opaque Markup: Tabs

48. ARIA • Accessible Rich Internet Applications • W3C specification in the works • Fills the semantic gaps in HTML • Roles, states, and properties • Live regions

49. Roles, States, Properties • Roles describe widgets not present in HTML 4 • slider, menubar, tab, dialog • Properties describe characteristics: • draggable, hasPopup, required • States describe what’s happening: • busy, disabled, selected, hidden

50. Using ARIA • // Now *these* are Tabs! • <ol id=”animalTabs” role=”tablist” tabindex=”0”> <!-- Individual Tabs shouldn’t be focusable --> • <!-- We’ll focus them with JavaScript instead --> • <li role=”tab”><a href=”#” tabindex=”-1”>Cats</a></li> • <li role=”tab”><a href=”#” tabindex=”-1”>Dogs</a></li> • <li role=”tab”><a href=”#” tabindex=”-1”>Gators</a></li> • </ol> • <div id=”panels”> • <div role=”tabpanel” aria-labelledby=”cats”>Cats meow.</div> • <div role=”tabpanel” aria-labelledby=”dogs”>Dogs bark.</div> • <div role=”tabpanel” aria-labelledby=”gators”>Gators bite.</div> • </div>