farcry cms

Drawing up the naughty and nice list for Christmas, the Daemonites are looking at releasing a series of very significant changes to the behaviour of the image formtool. These changes will be checked into the 6.0 maintenance branch and trunk. Although they are pretty stable, folks running on the HEAD of the maintenance branch should use caution in just upgrading.

In any event, take a look and let us know what you think.  This work has been put together by the mighty Blair based on the collective thoughts of the Daemonite team.

The image formtool has been rewritten to accommodate several new requirements:

• UI for visual selection of crop area (via Jcrop)
  • with intuitive limits on image size ratio and minimum dimensions
  • ability to make the JPEG resize quality adjustable
• "inline" upload (via Uploadify)
  • with a fallback "traditional" HTTP post option
• Simplified UI that:
  • Has information about the current image
  • Unambigously presents the state of the property and what will happen when the user saves
  • Has clear links to alternate actions (e.g. autogenerate -> upload custom)
• Updated workflow to reflect the best practice that there are "source" fields that are not modified (except to account for extremely large images), and "dependant" images that are cropped and resized versions of a source image.

The Image library is a classic example of all of these requirements in use. Here you can see two image fields: Source Image (a "source" field) and Mid Size Image (a "dependant" field). Notice that the default UI for an empty field is different for each.

When the fields do already contain an image they look like this.
Source Fields
The default upload option is now "inline" uploading (via Uploadify). As soon as a user selects an image from the dialog a progress bar appears showing progress with a matching cancel option. I would like to show a screenshot of that but I wasn't quick enough :). There is a shot of the "completed" stage further down.

Hover over the help icon to see the image requirements and cropping settings. Source fields will usually only specify allowed file types, while dependant fields will also have specific dimensions, the default crop method, and the default resize quality.

For people who don't have flash or have other issues with the inline upload, there is the option to switch between "inline" and "traditional" upload.
This swaps in the standard HTTP file upload input. NOTE: the inline upload allows users to go on and use the custom cropping tool immediately. Users that use the fallback UI will have to rely on the default crop for the initial save, then re-edit the object to do a custom crop. If there is an upload error it is displayed inline. Once an inline upload is complete an alert is displayed to make it clear that the file has changed on the server, even if the object isn't saved. NOTE: according to established behaviour, if the field already has an image attached then the old file isreplaced - the new image is given the same filename as the old image and copied over the top.
The UI is also updated to show information about the new image, which gives the user confirmation that upload worked as expected.
Finally, the user has the option to upload a different image. NOTE: this behaves the same way as uploading an image when there is already a file attached - the new image will have the same name as the old image.
Dependant Fields
Once again, hover over the help icon to see information about the default crop settings and the required image types. Even if the user chooses a custom crop, this will show what the defaults are and the target resize dimensions.
The user can still choose to upload a hand-optimised image from their computer. The UI for this is essentially the same as the upload UI for the source image. NOTE 1: if (and only if) the uploaded image is the wrong size it will still be resized by the server. NOTE 2: if the user chooses to upload they will not have the option to custom crop. This reflects the best-practice that original images are always available through "source" fields should "dependant" images need to be re-cropped.

The user can choose to custom crop their image. NOTE: this option only appears if the edited object already has a source attached or if the user has uploaded a source through the inline UI. If the source is empty or the user has used the fallback "traditional" UI, it will not. You can see this in the first screenshot comparing the "source" and "dependant" fields.

Thanks to the Jcrop jQuery plugin, we now have a visual tool to define a custom crop. This UI respects aspect ratios on fields that define both ftImageWIdth and ftImageHeight (the selection automatically scales the selection according to the ratio - try the thumbnail field of an Image object) and minimum dimensions (this stops a user from selecting an area which is too small and would be scaled up). NOTE: if necessary the image in the selection area is scaled down to fit the size of the dialog. The selection will still reflect the actual size of the source image.
While the user selects the best crop area, the info box shows the details of the selection. NOTE 1: the dimensions reflect the actual selection size on the source image, not scaled down size (if it was resized to fit the selection area) or the target dimensions of the field. NOTE 2: If the field as a set aspect ratio (meaning both the target width and height is defined) this value will stay set. NOTE 3: The default quality for JPEG resizing is defined with ftQuality. This value can be made editable by setting ftAllowResizeQuality to true, which will switch in a text input. There are plans to make this a jQuery UI slider, but that is not part of this release.
The custom crop is applied once the user saves. The confirmation of the custom crop is shown to them in the mean time.
If they decide they aren't happy with it, they can still cancel the custom crop before saving.

That is all!