= !BluePrint for CSS =

We have moved to a full page design to allow maximal screen real estate to be available for list views & data entry. Ours is based on:
 * http://matthewjamestaylor.com/blog/perfect-full-page.htm
 * This was inspired by the work done on Sahana PHP: http://demo.respere.com/dnn/
 * Link on doing something similar with the default web2py menu: http://groups.google.com/group/web2py/browse_thread/thread/ecffcd0427af0fec
The logo font is Brush Script.

Q: Should we migrate to [http://bluetrip.org BlueTrip]? [[BR]]
A: Probably not as their value isn't proven.

The CSS could still do with some cleaning up to remove unused styles.

CSS can be previewed in different browsers, however no interaction is possible:
 * http://browsershots.org/
 * IE only: http://ipinfo.info/netrenderer/

Original Sahana CSS documented here: [wiki:DeveloperGuidelinesCSS]

Maximal usability ideas:
 * http://www.alistapart.com/articles/progressiveenhancementwithcss

== Theme Manager ==
 * The selection & application of a theme should be moved to the same (or related) area as the Theme Editor, rather than hiding it within the main Settings area.
 * 'Apply Theme' should be an explicit option.

== Menus ==
The current 3 menu system should be migrated to a single menu to take upo less screen real estate & provide a consistent UI experience.

Ideally this would be loaded once & then cached (e.g. have the system generate a static menu.js which can then be loaded/cached)

We should always know where in the system we are.
 * e.g. Chevron-style breadcrumbs (e.g. http://www.guardian.co.uk/world/usa)
 * e.g. Highlight the active menu item using CSS (JS to set this would be in the main body template, rather than in menu.js)

Icons in Menus?
 * http://groups.google.com/group/web2py/browse_thread/thread/aeb21cca011e4632

ExtJS menus are flexible & can allow DRY creation of navigation elements (buttons/menus):
 * http://www.extjs.com/deploy/dev/examples/menu/menus.html
 * http://www.extjs.com/deploy/dev/examples/menu/actions.html

== Alternative layouts ==

We should include alternate layouts which different views can inherit from (common areas included into these to be DRY):
 * Site home & Module homes act as portals, which require a more complex layout, such as:
  * 3 columns: http://matthewjamestaylor.com/blog/perfect-3-column.htm
  * Stackable: http://matthewjamestaylor.com/blog/perfect-stacked-columns.htm
Q: How to {{{{{include}}}}} content into multiple areas? (How is it done with the JPolite app?)

Can use {{{LOAD}}} to import a component into an area of a webpage. Updates to this component happen independently to the rest of the page:
 * http://www.web2py.com/AlterEgo/default/show/252
=== Right-to-Left theme ===
We already have a simple:
{{{
body {
    direction: rtl;
}
}}}

This is currently set using the Theme.

We could look at setting this based on a lookup of the current locale.

=== Print View ===
Provide a view which allows for better Printing
 * CSS sufficient? ({{{media=print}}})
Browsers don't print pages in identical ways...if this is key, need to use PDF.

Like for format=ocr.

=== Mobile View ===
Provide a cut-down version for use on low-screensize, low-bandwidth devices, such as Mobiles
 * CSS sufficient?
 * http://mobiforge.com/Designing
 * http://www.slideshare.net/nickf/mobile-ux (eye opening examples on mobile usability)

Use the RESTlike CRUD controller's ?format=plain

----
BluePrints