General Requirements

  The requirements and constraints for the implementation must meet specific user centric needs and provide base level compatibility:

Browser compatibility  Any IE 5.0 or greater, FireFox, or Safari browser. W3C XHTML compliant. Runs on a minimum system configuration in Windows 98 through {style:type

span|font-size=12px}Vista

{style:type=span|font-size=12px}, Mac OS 10 and greater, and Linux. General compatibility with and W3C XHTML/CSS compliant browser.

 Most of the site and content view should be functional without JavaScript enabled (Editing and creating will be limited). ===

Accessibility  Fully Localizable/Internationalizeable (UTF8/Unicode and right to left compatible) and Accessible/Section 508/W3C WCAG compliant interface and navigation (tab to cycle, enter to select, text browser/screen reader support etc.)

Functional  Provides the required functions (as it presently does), renders quickly (is as light weight as possible), and provides for extensibility. The presentation should support both fixed (the current layout) and variable width displays. The full site's "content" must be crawlable by spiders, meaning that a Search Engine Robot following all links from the home page will find all content on the site. Spiders must be unable to change or modify anything.

Utility  The layout and display should be logical and intuitive, and be as non-modal as possible.

Consistency  The UI elements for all areas of the site should be built from common and shared rudiments that use consistent style class tags and names.

Clean modular display with several viewing modes and customizable style sheet  The display should support print, standard, full width, and embedded (embeddable) view modes and related style sheets. It should be possible to create custom style sheets for partners that will apply globally or conditionally to content collections. The intent is to enable a number of optional or customized styles for UI, view and print and enable partners and groups to create their own custom output styles. The layout, while set for fixed width, should support changing the display width or enabling variable width displays for view, print and output forms. Furthermore, the display macros involved in view must be used in future releases for rendering the output in all planned rendered forms (from HTML page sets in ZIP file Content Packages, to transformation into a PDF for printing, or for specific XML like DocBook). This includes "flattening" a hierarchical collection. Lastly the view modules should be extensible to support adding new asset types and asset type displays and editing interfaces over time.

Consistent and terse URL naming with the underpinning for a REST URL structure  Regardless of degree, the unneeded elements of the current URL (XWIKI, View, Bin) should be minimized or removed globally, while ensuring that links to current pages still work (correctly re-direct or render).

Documentation and modularity  Each independent functional component should be designed and documented as a reusable module (set of pages, macros and scripts). Each funtional module in the applicaiton will be defined individually, but will share common characteristics in and shodul be build by a single rudement and sub-module library (As defined here.)

The documentation should describe all shared style classes and macro rudements used by the module, all funtional aspects of the Macros and Modules (I/O), including exampels and funtional annotation, and any and all module specific style classes. The modules will also have their sub-elements or 'rudiments' identified and described. This is needed to enable transformation of these display macros for different rendered output forms and to support maintenance, extension, and re-use. It is also needed to identify what macro rudiments and style classes are shared across multiple modules. 

    
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 12.10.5-node1 - Documentation