Published on

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Workshop

    1. 1. Inclusive Accessibility Standards Liddy Nevile La Trobe University
    2. 2. Summary <ul><li>Inclusion </li></ul><ul><li>Context </li></ul><ul><li>World Wide Web Consortium work </li></ul><ul><li>IMS GLC / ISO / DC /….. AfA work </li></ul><ul><li>FLUID </li></ul><ul><li>… . </li></ul>
    3. 3. Inclusion <ul><li>Where would we be without </li></ul><ul><ul><li>Einstein, Beethoven, Edison, Roosevelt, da Vinci or Stephen Hawking? </li></ul></ul><ul><li>Exclusion leads to a vicious cycle of disenfranchisement </li></ul><ul><ul><li>lack of self-esteem, under-education, unemployment, poverty and social instability. </li></ul></ul><ul><li>Inclusion leads to a virtuous cycle of enfranchisement </li></ul><ul><ul><li>new ideas, flexibility and adaptability. </li></ul></ul>- Jutta Treviranus
    4. 4. The dimensions of inclusion <ul><li>People with disabilities </li></ul><ul><ul><li>Medical, cognitive, cultural, …. </li></ul></ul><ul><li>People in disabling circumstances </li></ul><ul><ul><li>Eyes-busy in the car, in a noisy environment, wearing safety equipment, … </li></ul></ul><ul><li>People in mobile environments </li></ul><ul><ul><li>Away from institutions, away from home, on the road, … </li></ul></ul><ul><ul><li>… </li></ul></ul>
    5. 5. Context for standards <ul><li>Philosophical/political differences </li></ul><ul><ul><li>Who’s responsible? </li></ul></ul><ul><li>Jurisdictional differences </li></ul><ul><ul><li>How’s it enforced? </li></ul></ul><ul><li>Industry-led standards </li></ul><ul><ul><li>Different goals and outcomes </li></ul></ul><ul><li>State-led standards </li></ul><ul><ul><li>Different levels of expertise </li></ul></ul><ul><ul><li>Political considerations </li></ul></ul>
    6. 6. Economic advantages <ul><li>Inclusive in workplace terms </li></ul><ul><ul><li>More people available to do the work </li></ul></ul><ul><li>Inclusive of new market share </li></ul><ul><ul><li>More people able to use the products </li></ul></ul><ul><li>A more inclusive, happier society </li></ul>
    7. 7. Accessibility beneficiaries
    8. 8. The ‘size’ of the problem
    9. 9. How do we know what he needs?
    10. 10. How do we know what he can do? Braille Jaws Zoomtext
    11. 11. How do we know what they need? they
    12. 12. How many options?
    13. 13. Quality products or processes <ul><li>If the products are not perfect, what happens? </li></ul><ul><li>The legal defence to not having good products (in Aust/NZ) is unreasonableness of the work required to have good products (ie the process) </li></ul><ul><li>Should the quality of the process be the focus? </li></ul><ul><li>A focus on process would support certification of compliant organisations…. </li></ul>
    14. 14. TILE <ul><li>E-learning environment that enables learner-centric transformation of learning content and delivery </li></ul><ul><ul><ul><li>Authoring support for transformable content and Metadata </li></ul></ul></ul><ul><ul><ul><li>Browser </li></ul></ul></ul><ul><ul><ul><li>Learning Object Repository </li></ul></ul></ul><ul><ul><ul><li>Learner Preference System </li></ul></ul></ul>http: //barrierfree .ca/TILE
    15. 23. Accessibility accommodations <ul><li>By lowest common denominator? </li></ul><ul><ul><li>W3C / WAI standards </li></ul></ul><ul><li>By presumed audience? </li></ul><ul><ul><li>Guess work by site developer </li></ul></ul><ul><li>By individual user? by context? </li></ul><ul><ul><li>AccessForAll standards </li></ul></ul>
    16. 24. Universal accessibility <ul><li>The World Wide Web Consortium’s Web Accessibility Initiative’s </li></ul><ul><ul><li>Web Content Accessibility Guidelines (WCAG) </li></ul></ul><ul><ul><li>Authoring Tools Accessibility Guidelines (ATAG) </li></ul></ul><ul><ul><li>User Agent Accessibility Guidelines (UAAG) </li></ul></ul><ul><ul><li>Accessibility implications of all W3C recommendations </li></ul></ul><ul><ul><li>…… </li></ul></ul>
    17. 25. W3C ‘universal’ accessibility
    18. 26. W3C ‘universal’ accessibility
    19. 27. WAI-ARIA <ul><li>Is for developers of </li></ul><ul><li>Web browsers, assistive technologies, and other user agents </li></ul><ul><li>Web technologies (technical specifications) </li></ul><ul><li>Accessibility evaluation tools </li></ul><ul><li>For Web content developers and authoring tool developers, a separate document will provide best practices for implementing WAI-ARIA in Web content. </li></ul>But…. (Accessible Rich Internet Applications)
    20. 28. Disabilities Rights Commission (UK) <ul><li>In 2003 tests of 1000 UK sites </li></ul><ul><li>808 failed to reach minimum reqs of WCAG </li></ul><ul><li>100 conformant sites had 585 accessibility and usability problems </li></ul><ul><li>45% of problems not violations of WCAG </li></ul>
    21. 29. It seems…. <ul><li>no guidelines will make all sites accessible for everyone but anyway, not all sites will be accessible </li></ul><ul><li>so </li></ul><ul><li>a broader approach (AccessForAll) has been developed to complement the W3C WAI work. </li></ul>
    22. 30. Accessibility metadata <ul><li>Even if resources are accessibility standards conformant, those that suit an individual user are: </li></ul><ul><ul><li>not necessarily accessible to her </li></ul></ul><ul><ul><li>not discoverable if they are accessible </li></ul></ul><ul><li>Resources that are not ‘universally’ accessible </li></ul><ul><ul><li>might satisfy her needs and/or preferences </li></ul></ul><ul><ul><li>might have been made accessible retrospectively </li></ul></ul><ul><ul><li>might be made accessible just-in-time </li></ul></ul>
    23. 31. AccessForAll metadata <ul><li>Originally 3 main components: </li></ul><ul><li>Metadata to describe needs and preferences of user </li></ul><ul><li>Metadata to describe accessibility characteristics of resources </li></ul><ul><li>Accessibility service to match resources to needs and preferences </li></ul>
    24. 32. AccessForAll metadata <ul><li>Interoperability is critical: </li></ul><ul><li>originally for education - driven (IMS GLC) </li></ul><ul><li>contemporaneously cross-sectoral (DCMI) </li></ul><ul><li>ISO supported (JTC1 SC36) </li></ul><ul><li>Government support </li></ul><ul><ul><li>AGLS, NZGLS, Ontario, … </li></ul></ul>
    25. 33. Personal Needs and Preferences (PNPs) <ul><li>Display: </li></ul><ul><ul><li>how resources are to be presented and structured, </li></ul></ul><ul><li>Control: </li></ul><ul><ul><li>how resources are to be controlled and operated, and </li></ul></ul><ul><li>Content: </li></ul><ul><ul><li>what supplementary or alternative resources are to be supplied. </li></ul></ul>
    26. 34. Display preferences <ul><li>Where the user can’t see the text, it may need to be transformed into another mode - auditory or tactile (Braille). </li></ul><ul><li>Text may need to be bigger and a different colour. </li></ul><ul><li>Images may need to be bigger. </li></ul>
    27. 35. Control preferences <ul><li>Some assistive technologies effectively replace the typical mouse and keyboard combination without any adjustment </li></ul><ul><li>but others use technologies that require special configuration. </li></ul><ul><li>An on-screen keyboard will use screen space e.g. </li></ul>
    28. 36. Content preferences <ul><li>A dyslexic person may need additional images to avoid excessive text density </li></ul><ul><li>a ‘foreigner’ may need an alternative language </li></ul><ul><li>a eyes-busy person may need a text description of an image. </li></ul>
    29. 37. Simple PNP descriptions
    30. 38. Digital Resource Description (DRDs) <ul><li>Display: </li></ul><ul><ul><li>how the resource can be presented and structured, </li></ul></ul><ul><li>Control: </li></ul><ul><ul><li>how the resource can be controlled and operated, and </li></ul></ul><ul><li>Content: </li></ul><ul><ul><li>what supplementary or alternative resources are supplied with the resource. </li></ul></ul>
    31. 39. Basic DRD metadata includes: <ul><li>Access Mode: vision, hearing, touch, text </li></ul><ul><li>Access Mode Usage: informative or ornamental </li></ul><ul><li>Display: amenability of a resource to transformation of the display </li></ul><ul><li>Control: how the method of control is flexible </li></ul><ul><li>Alternatives: any known alternatives </li></ul>
    32. 40. and, where appropriate, <ul><li>Components: any parts that make up this resource (a sound file, an image, etc.) or a composite resource of which it is a part </li></ul><ul><li>Hazards: any dangerous characteristics </li></ul><ul><li>Support tools: electronic tools associated with the resource (calculator, dictionary, etc.) </li></ul>
    33. 41. & DRD for alternatives also includes: <ul><li>Identity of the original resource </li></ul><ul><li>Type: kind of alternative </li></ul><ul><li>Extent: extent of coverage of original resource </li></ul><ul><li>Detailed description of the alternative: description of its characteristics necessary for matching it to details of the PNP. </li></ul>
    34. 42. The Matching Process <ul><li>in a closed environment </li></ul>
    35. 43. The Matching Process <ul><li>in a distributed world </li></ul>
    36. 44. Proving the concept <ul><li>ABC video on demand </li></ul>
    37. 45. AfA is an approach … PNP DRD  Dlfkng fg jhgj fglhk fgh Rt hrtj hlkjg hklj thkkj tt Rt grlkthklj thk thl kjrthk Rthnk tlhkk jthk rth th lrt Framework PNP DRD
    38. 46. But …
    39. 47. !DEA Workshop Brisbane 2007
    40. 48. Project leadership <ul><li>Jutta Treviranus, ATRC, U of Toronto </li></ul><ul><li>University of California, Berkeley </li></ul><ul><li>University of Cambridge, UK </li></ul><ul><li>University of British Columbia </li></ul><ul><li>York University and </li></ul><ul><li>at least 5 other universities and 3 corporations </li></ul>
    41. 49. Vision <ul><li>Advance status of UI development and design in academic community source projects </li></ul><ul><li>…so that they can fulfill their potential as platforms for innovation… </li></ul><ul><li>UI = user interface, user interaction, user experience, usability and accessibility </li></ul>
    42. 50. Current Problems <ul><li>Systemic problem of poor and inconsistent UI </li></ul><ul><li>Frequently left to programmers </li></ul><ul><li>Tackled at the end </li></ul><ul><li>Redundantly developed </li></ul><ul><li>Inadequately tested and refined </li></ul><ul><li>User experience (UX) designers not well integrated into development culture </li></ul><ul><li>and…. </li></ul>
    43. 51. “You say tomato, I say tomato, let’s call the whole thing off” <ul><li>Academic communities are very diverse </li></ul><ul><li>People differ greatly in preferences, needs, habits, concepts, comforts, convictions…. </li></ul>
    44. 52. Different strokes for different folks… <ul><li>Institutional preferences and branding </li></ul><ul><li>Conventions of academic discipline </li></ul><ul><li>Cultural differences </li></ul><ul><li>Linguistic differences </li></ul><ul><li>Differences related to age </li></ul><ul><li>Differences related to role and perspective </li></ul><ul><li>Different teaching approaches </li></ul><ul><li>Different learning approaches </li></ul><ul><li>Disability and environmental constraints </li></ul>
    45. 53. Differences related to academic discipline <ul><li>language (e.g., the meaning of color) </li></ul><ul><li>values and notions of quality </li></ul><ul><li>tools </li></ul><ul><li>environment </li></ul><ul><li>modes of interaction and academic engagement </li></ul><ul><li>In academia, we foster and thrive on diversity. </li></ul>
    46. 54. Accessibility <ul><li>Legal commitment to equal access </li></ul><ul><li>No system-wide strategy, band-aid approach at greater and greater cost </li></ul><ul><li>Guidelines seen to constrain creativity </li></ul>
    47. 55. Goal: Consistent User Experience <ul><li>Growing number of tools </li></ul><ul><li>Growing number of developers </li></ul><ul><li>A consistent identifiable look </li></ul><ul><li>Intuitive and transparent design </li></ul>
    48. 56. Consistent User Experience vs. Accommodating Differences <ul><li>Do we need to choose? </li></ul><ul><li>Or can we have our cake and eat it too? </li></ul>
    49. 57. Proposal: “Flexible User Interface” <ul><li>Swappable styles </li></ul><ul><li>Swappable UI components </li></ul><ul><li>Either runtime transformation for unique needs of individual </li></ul><ul><li>or customization at configuration </li></ul>
    50. 58. 2 Interwoven Approaches <ul><li>Address systemic or process shortcomings as well as education and awareness </li></ul><ul><li>Address barriers related to the software, architecture and tools </li></ul>
    51. 59. Overarching Goal <ul><li>To support the precarious values of usability, accessibility, internationalization/localization, quality assurance and security </li></ul><ul><li>To incrementally improve the overall user experience of Sakai, uPortal, Kuali Student, and Moodle </li></ul>
    52. 60. Participating Projects <ul><li>Sakai </li></ul><ul><ul><li>Collaboration and learning environment </li></ul></ul><ul><ul><li>Teaching, research, and group collaboration </li></ul></ul><ul><li>uPortal </li></ul><ul><ul><li>Enterprise portal system </li></ul></ul><ul><ul><li>Aggregates personalized content </li></ul></ul><ul><li>Moodle </li></ul><ul><ul><li>Learning management system </li></ul></ul><ul><ul><li>Strong focus on pedagogy </li></ul></ul><ul><li>Kuali Student </li></ul><ul><ul><li>Upcoming, next generation student system </li></ul></ul><ul><ul><li>Viable alternative to high-cost commercial products </li></ul></ul>
    53. 61. Supporting Objectives <ul><li>To develop: </li></ul><ul><ul><li>architectural framework for a flexible UI </li></ul></ul><ul><ul><li>living library of robust, usable, accessible UI components </li></ul></ul><ul><ul><li>community processes that support innovative, high quality user experience design and development </li></ul></ul><ul><ul><li>tools and processes for developing and implementing modular, sharable UI components </li></ul></ul><ul><ul><li>mechanisms for refining components </li></ul></ul>
    54. 62. The Fluid Approach <ul><li>Cross-project collaboration </li></ul><ul><li>Take a holistic approach by combining both technology and UX design </li></ul><ul><li>A two-fold path: </li></ul><ul><ul><li>Social : build a community around UX </li></ul></ul><ul><ul><li>Technical : new UI development tools </li></ul></ul>
    55. 63. What will FLUID build? <ul><li>A living library of flexible UI components that can be used across applications </li></ul><ul><ul><li>Easy to wire up and customize </li></ul></ul><ul><ul><li>Components are more than widgets </li></ul></ul><ul><li>A new component framework built specifically to improve usability </li></ul><ul><li>Semantics and specifications </li></ul><ul><li>Integration with open source projects </li></ul>
    56. 64. User Experience & the Designer’s Toolkit
    57. 65. Fluid Deliverables
    58. 66. Designer’s Toolkit <ul><li>UI Design Patterns </li></ul><ul><ul><li>Help grow the current Sakai library </li></ul></ul><ul><ul><li>Extend to uPortal and Moodle </li></ul></ul><ul><li>Component library </li></ul><ul><ul><li>Iterative design and testing </li></ul></ul><ul><ul><li>Component design artifacts </li></ul></ul><ul><ul><li>Design Patterns as taxonomy / folksonomy </li></ul></ul>
    59. 67. User Experience Inspections <ul><li>Goals </li></ul><ul><ul><li>Identify pain points </li></ul></ul><ul><ul><li>Identify “componentizable” solutions </li></ul></ul><ul><ul><li>Drive component work priority </li></ul></ul><ul><ul><li>Create shared protocol & process </li></ul></ul><ul><ul><li>Provide baseline for future evaluation </li></ul></ul><ul><li>Protocol </li></ul><ul><ul><li>Usability & accessibility heuristics </li></ul></ul><ul><ul><li>Cognitive walkthroughs </li></ul></ul><ul><li>Organic process </li></ul>
    60. 68. UX Inspection Plan <ul><li>Define protocol: with help! </li></ul><ul><li>Identify functionality “chunks” within applications </li></ul><ul><ul><li>Iterative: focus on highest-used areas first </li></ul></ul><ul><li>Define and share report templates </li></ul><ul><li>Sub-group Inspections </li></ul><ul><ul><li>Sakai, Moodle, uPortal, Accessibility </li></ul></ul><ul><ul><li>Synthesize across groups </li></ul></ul><ul><li>Identify issues </li></ul><ul><ul><li>Common issues = common components </li></ul></ul>
    61. 69. Components <ul><li>Components are recurring interactions: </li></ul><ul><ul><li>Navigation </li></ul></ul><ul><ul><li>Forms and data </li></ul></ul><ul><ul><li>Direct manipulation of objects </li></ul></ul><ul><ul><li>Workflows, wizards, and sequences </li></ul></ul>
    62. 70. Component Design <ul><li>User centered process </li></ul><ul><li>Based on real user research </li></ul><ul><li>Looking across communities and applications </li></ul><ul><li>Agile, iterative process </li></ul><ul><li>Close and constant communication with development </li></ul><ul><li>Closely related to design patterns </li></ul>
    63. 72. A bit about the technology <ul><li>Unique challenge: how to enable support for very diverse presentation technologies? </li></ul><ul><li>Based on JavaScript, DHTML, and AJAX </li></ul><ul><li>Thin binding layer between client and RESTful, largely stateless server </li></ul><ul><li>Loose coupling, works across applications </li></ul><ul><li>In summary: </li></ul><ul><ul><li>Web 2.0 made more usable & accessible </li></ul></ul>
    64. 73. Fluid Accessibility <ul><li>Web 2.0 will be accessible </li></ul><ul><ul><li>it’s just a matter of time </li></ul></ul><ul><li>ARIA: Accessible Rich Internet Applications (W3C) </li></ul><ul><li>AccessForAll for component metadata </li></ul><ul><li>Ongoing toolkit accessibility support </li></ul><ul><ul><li>Dojo, YUI, others? </li></ul></ul><ul><li>Design specific alternatives </li></ul><ul><li>Fluid: Accessibility from the ground up </li></ul>
    65. 74. Flexibility & Customization <ul><li>Fluid will be a highly flexible UI layer </li></ul><ul><li>At configuration-time: </li></ul><ul><ul><li>Appearance, branding, style, page text </li></ul></ul><ul><ul><li>Locale, reading level, density </li></ul></ul><ul><ul><li>Functionality and user experience </li></ul></ul><ul><li>At run-time: </li></ul><ul><ul><li>Swap in accessible controls </li></ul></ul><ul><ul><li>Re-styling for higher contrast, etc. </li></ul></ul><ul><ul><li>Components built for specific disciplines or user needs </li></ul></ul>
    66. 75. Configuration-time customization
    67. 76. Run-time Transformation
    68. 77. What is a Reusable Component? <ul><li>On the client-side, a Fluid component consists of: </li></ul><ul><ul><li>One or more HTML templates </li></ul></ul><ul><ul><li>One or more layers of CSS </li></ul></ul><ul><ul><li>JavaScript for behavioural logic </li></ul></ul><ul><ul><li>Accessibility metadata (control, presentation, etc) </li></ul></ul><ul><li>And on the server-side: </li></ul><ul><ul><li>A set of conventions for accessing service logic </li></ul></ul><ul><ul><li>The ability to deliver the appropriate markup, metadata, and user preferences </li></ul></ul>
    69. 78. Anatomy of a Component
    70. 79. Component Architecture <ul><li>Markup-driven components are general: </li></ul><ul><ul><li>Server delivers fully-rendered HTML </li></ul></ul><ul><ul><li>JavaScript manipulates DOM based on id contract </li></ul></ul><ul><ul><li>Greater flexibility and reuse, but greater server dependency </li></ul></ul><ul><li>Data-driven components are smarter but slower: </li></ul><ul><ul><li>Handle their own template processing </li></ul></ul><ul><ul><li>Require multiple round-trips to the server for data </li></ul></ul><ul><ul><li>Allow for less dependency on server-side presentation framework </li></ul></ul><ul><li>We’ll support both for different contexts as necessary </li></ul>
    71. 81. The Fluid Framework <ul><li>Framework infrastructure </li></ul><ul><ul><li>lifecycle supports, server-side communication, etc. </li></ul></ul><ul><li>Components themselves </li></ul><ul><li>Transformation engine </li></ul><ul><li>Server-side binding and delivery </li></ul>
    72. 82. The Fluid Framework
    73. 84. RESTfulness <ul><li>REST: not just a buzzword. </li></ul><ul><li>General principle: use the Web’s natural architecture </li></ul><ul><ul><li>Client statefulness, server statelessness </li></ul></ul><ul><ul><li>Meaningful URLs </li></ul></ul><ul><ul><li>Emphasize named resources over actions </li></ul></ul><ul><ul><li>Don’t invent new messaging APIs: use HTTP! </li></ul></ul><ul><li>Benefits: </li></ul><ul><ul><li>Back button friendly </li></ul></ul><ul><ul><li>Bookmark-ability </li></ul></ul><ul><ul><li>Light weight web services </li></ul></ul><ul><ul><li>Natural integration point with diverse presentation frameworks </li></ul></ul><ul><ul><li>Extract and generalize for reuse </li></ul></ul>
    74. 85. Binding to Presentation Frameworks <ul><li>Reality: there are a lot of different presentation frameworks in use today across applications </li></ul><ul><ul><li>At least 5 in use within Sakai </li></ul></ul><ul><li>FLUID approach: </li></ul><ul><ul><li>Move appropriate logic and state from server to client </li></ul></ul><ul><ul><li>Support the best frameworks </li></ul></ul><ul><ul><li>Try to make it easy to bind to other frameworks </li></ul></ul><ul><li>Start with two server-side frameworks: </li></ul><ul><ul><li>RSF and Spring Portlet MVC </li></ul></ul><ul><li>FLUID will continue to revisit this decision over time </li></ul>
    75. 86. Component Road Map <ul><li>Prioritize based on usability research </li></ul><ul><li>Start with specific solutions in context </li></ul><ul><ul><li>Lightbox: organizing images </li></ul></ul><ul><li>Build general solutions over time </li></ul><ul><li>Lightbox leads to all kinds of resource organization components: </li></ul><ul><ul><li>Drag and drop </li></ul></ul><ul><ul><li>Folders and hierarchies </li></ul></ul><ul><ul><li>Re-ordering and rearranging items </li></ul></ul>
    76. 87. First Component: Lightbox <ul><li>Image Gallery: a mini iPhoto for Sakai </li></ul><ul><li>Some clear UX problems to solve </li></ul><ul><ul><li>No way to re-order or sort images in albums </li></ul></ul><ul><li>Plans </li></ul><ul><ul><li>Build components for reorganizing images </li></ul></ul><ul><ul><li>Create accessible controls </li></ul></ul><ul><ul><li>Test in Sakai </li></ul></ul>
    77. 88. The Lightbox
    78. 89. Drag & Drop Accessibility <ul><li>What does accessibility mean here? </li></ul><ul><ul><li>Keyboard access </li></ul></ul><ul><ul><li>Support for magnification and linearization </li></ul></ul><ul><li>Focus on the goal, not the task </li></ul><ul><ul><li>Re-ordering images </li></ul></ul><ul><ul><li>Doesn’t necessarily look like DnD </li></ul></ul><ul><ul><li>What alternatives are available on the desktop? </li></ul></ul><ul><ul><li>Cut and paste-style interactions </li></ul></ul>
    79. 90. Short Term Goals <ul><li>Plan heuristic evaluations </li></ul><ul><li>Foster a vibrant community </li></ul><ul><li>Evaluate technology in practice </li></ul><ul><ul><li>Develop real components with candidate technology </li></ul></ul><ul><li>Create prototype component components </li></ul><ul><ul><li>Design, develop, integrate, test, iterate </li></ul></ul><ul><ul><li>Create accessible alternatives or equivalents </li></ul></ul><ul><li>Plan ongoing architecture and design </li></ul>
    80. 91. Where FLUID’s Going Next <ul><li>Comprehensive usability evaluations of Sakai, uPortal, and Moodle </li></ul><ul><li>Implementation of new components that improve high-priority UX problems </li></ul><ul><li>Definition of new AccessForAll branch for UI components: </li></ul><ul><ul><li>Metadata </li></ul></ul><ul><ul><li>Preferences </li></ul></ul><ul><li>Integration and expansion of framework </li></ul><ul><li>Helping to make real improvements in Sakai </li></ul>
    81. 92. In Summary <ul><li>For more information, visit the Fluid Project web site: </li></ul><ul><li>Design and development work is ramping up </li></ul><ul><li>Goal: incremental, achievable improvements </li></ul><ul><li>Join the FLUID community, they invite your input! </li></ul>
    82. 93. <ul><li>Thank you. </li></ul>