A mobile theme

I am currently setting up a payment portal for the university.

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.

Nuxeo World 2010 presentation

Here is a 10 minute film presented at Nuxeo World 2010 showing the new features of the theme editor.

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

Theme bank application to be released soon

I am currently finishing some work on a theme bank application inspired from wordpress themes.

Here are some preview pictures:

Seamless integration with the theme editor:

From SkrinkSafe to YUI Compressor

To reduce the size of Javascript resources, Nuxeo Theme had until now used the DojoToolkit’s  ShrinkSafe javascript compressor based on a custom version of Rhino (a Mozilla  implementation of Javascript written in Java).

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.

New CSS editor available

The changes described in the previous articles (New CSS property editor and Redesigned fragment factory) have been checked in and should soon be available in the latest nuxeo DM snapshots.

Screencast showing the new CSS editor

New CSS property editor

The CSS property editor is getting a usability overhaul. In its current form it consists of:

• 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

Prototype 1.7 RC1

The first release candidate of Prototype 1.7 was released a week ago.

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.

Redesigned fragment factory

The fragment factory is used to insert page fragments into a theme (by clicking on Add fragment via the contextual menu).

>>> 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.