Start page

Invoice view

Account setup

The layout is rather straight-forward (a top header and a 2-column layout in the main content area), but when viewed using an iPhone the text size is much too small to be usable and a lot of vertical scrolling is required to scan the entire page width.

jQuery Mobile framework

I experimented with the jQuery Mobile Framework (currently in alpha release) and the results seem promising, with little effort required.

iPhone view using jQuery mobile

The only issue is that all existing templates have to be rewritten using the jQuery Mobile markup. jQuery mobile makes use of the HTML5 features.

Even with a well designed separation between the presentation data and the templates a lot of the markup has to be rewritten entirely.

A theme engine for mobiles

I am thinking of registering a new “jquery mobile” engine for use with mobile devices. This is meant instead of the default tabled-layout rendering engine which was designed for desktop browsers (Firefox, IE, …).

jQuery mobile targets most known devices: iPhone, Android, Windows Mobile, BlackBerry ..

It would be up to the application designer to decide which URLs to serve using the jquery-mobile engine, e.g. (mysite.com/nuxeo/site/my-app/mobile/) by registering a specific application view:

<application root="/nuxeo/site/my-app" template-engine="freemarker">
  <view id="/mobile">
    <theme>myapp/mobile</theme>
    <engine>jquery-mobile</theme>
  </view>
</application>
 

A jQuery mobile engine would include:

• the required javascript, css files and images using by the mobile framework
• a translation of pages / sections / cells concepts already used by the nuxeo theme engine into jQuery Mobile concepts (pages, page sections, horizontal content grids)
• probably new fragment views corresponding to jQuery Mobile UI elements (lists, menus, navigation elements, …) to offer a new presentation layer for existing content.

Probably this will be released as an add-on. See NXP-6584 for more details.

Source: http://blip.tv/file/4452869

Here are some preview pictures:

Seamless integration with the theme editor:

Some Javascript source files could not be safely minified (e.g prototype.js and jquery.js). This is why an extra parameter called shrinkable had been added to the XML resource configuration descriptor:

<resource name="prototype.js">
  <path>nxthemes/html/scripts/prototype.js</path>
  <shrinkable>false</shrinkable>
</resource>

I have now experimented with YUI Compressor and so far all javascript source files that I have tested with have been safely compressed.

YUI Compressor can also compress CSS files which are now being compressed by default.

Compatiblity

Although I haven’t tested yet it says in the changelog:

YUI Compressor 2.4, 2008-10-21
------------------------------
Allowed the YUI Compressor (which uses a modified version of Rhino)
to work alongside the original (unmodified) rhino library by using
a custom class loader.

So let’s hope that incompatibility issues observed between Rhino and customized versions of Rhino have been solved.

The changes are planned for upcoming 5.3.2 release of Nuxeo DM.

Screencast showing the new CSS editor

• 2 edit mode buttons (CSS / FORM)
• a drop-down list of CSS selectors (h1, a:hover, form input, …)
• a group of  style category buttons (all, color, background, border, font, image)
• the actual input fields for setting CSS properties
• a style picker

CSS property editor (before)

Because of the long list of properties the UI requires a lot of scrolling.

The category buttons are not very useful because they target the wrong elements, for example to change the color of a font it seems more intuitive to go to the Font section than to the Color section. The Image category begs the question: the image of what?

So what are the changes?

• we use the Tahoma font for better readibility
• property names are right-aligned to better match labels and input fields
• we use a more neutral style picker icon
  
• we show already set properties first to minimize the need for scrolling
• we introduce new style categories: backgrounds, borders, font, text, visual, …
• we use an accordion layout (+/-) to display categories and properties

CSS property editor (after)

A word about CSS3

The compatibility level is CSS 2.1 by default.

But since newer generations of web browsers are beginning to support CSS level 3, a CSS3 button is added to get access to visual features such as:

• box-shadow
• text-shadow
• border-radius
• border-image

It contains some interesting new features:

• the integration of a new CSS selector engine (Sizzle) with much improved performance compared with Prototype’s own engine (see performance tests)
• a more concise API for handling events (Element#on)
• a measure tape for computing layout dimensions (Element.Layout)
• an ECMAScript 5 compliant JSON implementation

The first live tests show so far no particular compatibility issues with the theme editor, except for the form data which isn’t serialized as expected.

This is easily fixed by replacing:

    formMap.toJSON()

which now according to the ES5 specification has to return an object, with:

    Object.toJSON(formMap)

which returns a string.

>>> Take a look at the screencast

The operation is done in four steps:

1. Selecting a fragment type (data)
2. Selecting a view (HTML)
3. Selecting a style (CSS code)
4. Reviewing the selection and adding the fragment

Each step determines the range of choices available in the following steps.

Fragments are responsible for generating data according to a data model (menu, feed, region, navigation, …). For any given type of data model, a limited list of views is available.

The views are responsible for converting the fragment data into HTML code. For example a list of links may be represented as a vertical menu or as a horizontal trail, or as news ticker…

Since views expect a given type of data format, they know in advance how to interpret the data. There is so to speak a strong typing between fragments and views.

A special type of fragment called the generic fragment generates no data at all, which means that views are responsible for obtaining the data directly from the application.

In this example we select the search box view:

Here is the HTML code of the search box:

<form action="${Root.getPath()}/@search" method="get">
  <div>
    <input type="text" name="fullText" value="" />
  </div>
</form>

In the third step we can choose to apply a style to the selected view. This is an optional step.

The CSS code of the search box style is:

form {
 background-color: "light blue (Chalmers ST colors)";
 border: 1px solid "white (Chalmers ST colors)";
 margin: 18px 15px;
 padding: 8px;
 text-align: left;
}

form input {
 background: "search (Chalmers ST backgrounds)";
 border-color: "dark blue (Chalmers ST colors)";
 border-style: solid;
 border-width: 1px;
 color: "dark gray (Chalmers ST colors)";
 font-size: 12px;
 padding: 4px 20px;
 width: 120px;
}

It is clear that not all styles are designed for the search box view. The typing between views and styles is weak and there is no guarantee that styles will match any given view.

Finally we review the selection. A preview is generated on-the-fly and by clicking on the ADD FRAGMENT button we can insert the fragment into the theme. This operation, as all other theme operations, can be undone by clicking on undo add fragment.

Screencast showing the four steps

Improvements

There is no way to know in advance how well styles and views will match one another. A solution would be to restrict the list of styles that can be applied to a view. In that case when a style is created or being edited there should be an option where to specify a list of compatible views. If no view is selected one could assume that the style applies to any view.