It’s great that there have been so many sessions focusing on these things as it demonstrates how seriously this stuff is being taken in Plone. Designers and integrators certainly have no need to feel like the poor cousins of the hardcore Python programmers and sys admins.

Here are some of the highlights so far:

1. TinyMCE

This is going to be used as the replacement page editor for Kupu in Plone 4 and upwards, although it’s also available to install as an add-on product in Plone 3.

This is great news as we’ve started to identify some serious usability problems with Kupu and we’re keen to get away from using the third-party commercial editor we’ve been using, Editon-Pro.

Whilst Editon-Pro is a great tool, its reliance on running in a Java Applet makes it slow, especially on older computers and it has no simple integration into the main Plone setup. The main advantage Kupu offered was its ability to insert links and images by browsing Plone’s folder structure and to allow users to upload images directly.

Unfortunately, Kupu doesn’t do many of the things that Editon-Pro does quite well, for instance handling page anchors. Kupu’s implementation of this is frankly baffling but TinyMCE’s handling is far closer to Editon-Pro’s and doesn’t require users to adjust their mental model (in Editon-Pro and TinyMCE users can insert their anchors; in Kupu users can only link to anchors which have been automatically created for them).

Another nice feature in TinyMCE is the paste from Word option which is something that Kupu doesn’t seem able to handle at all — Editon-Pro allowed users to “paste as plain text” which may have removed all formatting but at least it worked.

2. collective.xdv and Deliverance

Plone 3 theming is horrible. Just horrible I tell you! Luckily, this is a view shared with everyone else who has ever done Plone theming so two very similar new approaches have been developed: collective.xdv and Deliverance.

These both use rules-based theming to map sections of a Plone page to a custom-built HTML/CSS theme. In essence this means you create your own design and just display the bits of Plone you want in it (i.e. the content). The mapping is done via a XML rules file which in collective.xdv’s case needs to be created manually. For Deliverance these rules can also be created manually but there is also an exciting new project called Banjo (see what they did there?) which is a GUI for generating the rules and which also provides real-time previews of the integrated theme.

So, what’s the difference? In essence it appears that Deliverance is not just Plone-specific — it can be used to theme any third-party system whereas collective.xdv is completely Plone-specific. Xdv is a little easier to get started with as it’s integrated fully into the Plone architecture (as an add-on product) and Deliverance runs as a proxy on a webserver so has a higher installation / configuration overhead.

The good news is that they basically use the same syntax (statements such as “drop”, “replace” etc.) so it should be able to move easily between the two. However, xdv uses XPath to write rules (it’s XSLT-based) whereas Deliverance uses a slightly more designer-friendly CSS-style syntax.

3. Deco

Slightly confusingly there seem to two elements to Plones 4 and 5 called Deco. One is the basic grid layout CSS used for the new default Plone theme which is similar to other CSS layout tools such as 960.gs. The other part of the Deco framework is a drag-and-drop UI which allows content editors to add different elements to their pages without having to do complex things in the page editor.

From a UI perspective it’s a great approach, although the pessimist in me sees it could also be a recipe for some pretty horrendous looking pages.

4. jQuery tools

More UI loveliness –jQuery tools is a lightweight jQuery plugin which provides a lot of the functionality supplied by jQuery UI at a fraction of the download overhead.

In Plone 4+ this is used to provide some great UI controls such as login boxes in stay-on-the-page overlays and dialogues, tabs and carousels.

5. Dexterity

Dexterity is a replacement for Archetypes (Plone’s framework for creating content types) which can be installed as an add-on product for Plone 3. Whilst statements like that might usually make me run in horror, this is great news for a simple reason: it provides through the web content type creation, just as it should be. Basically, another great UI improvement — no more fiddling around with lots of Python code to create your content types.

So, overall there’s some great stuff here — many of the annoyances faced by designers and integrators have been addressed and it’s great to see such an emphasis put on usability.

Posted via email from What’s this for?

Veda Williams‘ Plone 3 Theming (Packt, 2009) [Amazon UK | Amazon US | Packt] is a useful reference for anyone involved in customising the look and feel of their Plone-based website. Used alongside the various online resources on the plone.org website, particularly the Plone Theme Reference,  it should ease  most of the pain that Plone themers experience. Unfortunately (and this is not a criticism of the author), the book is let down by some poor copy-editing. It also contains a number of errata, which the author is gathering on the plone.org website.

The book is broken down into fifteen chapters, the most useful of which I found were chapters seven to twelve which deal with the day-to-day business of Plone theming.  These chapters cover customising viewlets and portlets, an overview of the Zope templating language ( ZPT), the creation and installation of a Plone theme, template changes, custom page views and theming tips. Although I’ve done a fair amount of Plone theming, I still find it quite esoteric and complex so it’s certainly very useful to have these chapters to refer back to.

Chapter fifteen, written by Alex Limi, gives an overview of the future of Plone theming using products such as collective.xdv and Deliverance. These seem an ultimately saner way to proceed and should allow non-Plone specialists to theme a site without getting too bogged down in Plone specifics. This article is also freely available on the Plone website where it will be updated as the project develops.

I did wonder if the second chapter was really necessary — this provides an overview of the main graphic design, browser and text editing tools. I imagine that most web designers and developers already know about these and the complete beginner would be encouraged to to stay away from Plone until they are a little more experienced.

That aside, the only real complaint I have about the book is the quality of the copy-editing. I think the text would in places benefit from a little slimming down or rephrasing. I occasionally struggled with some of the explanations , although it must be borne in mind that Plone 3 theming is complex so is by its very nature difficult to explain in simple terms. Some other examples: it’s probably not necessary to have sentences like, “now what, you ask?” in a tutorial book and I’m not sure why there is a lengthy code sample from Plone 2 on pages 129-30 which is really only produced to show how things were done the “old way”.

Anyone who has been involved in Plone theming will know how hard Veda Williams has worked on it: in addition to this book, she coordinated the Out of the Box Plone Themes project. For her work I’m sure she has the gratitude of every Plone themer. Hopefully subsequent editions of the book will address the editorial issues and errata.

• Bookmarks
• History
• Tabs
• Stored credentials

The Mozilla Weave project aims to allow synchronisation of this information across different Firefox instances. However, this particular design challenge is looking at ways that this information may be shared across different browsing devices when access to Firefox isn’t possible, i.e. via a web page.

Details of my proposal follow. It has been in part influenced by the findings of one of the Challenge’s recommended readings: Jason Hong, Contextual Web History: Using Visual and Contextual Cues to Improve Web Browser History (PDF), and other existing web-based mechanisms for managing visual assets (e.g. Flickr).

One of the findings of the paper was that visual cues in the shape of thumbnail images of visited websites helped users to better identify sites in their browsing history: the most useful size of these thumbnails was found to be around 235 by 148 pixels (p.5). This visual approach to representing history is being used by other browsers, including Safari and Chrome.

My idea expands on the use of visual cues for browsing history and also applies them them to bookmarks, tabs, credentials and history. As the data in this example becomes visual, it also lends itself to being managed by tools similar to those for managing photos and other visual assets on social networking sites. The Flickr model of page layout and set (”folder”) management, mainly due to its familiarity to me seemed to be of particular use.

The prototypes presented have been created by Balsamiq Mockups and are deliberately lo-fi. However, they help to clarify some of my concepts. They leave aside logging in, Web Weave account management and help screens etc. and are broken down into the following screens:

• Bookmarks
• Browsing history
• Tabs
• Web accounts
• Preferences

Main menu

The main menu provides an overview visualisation of all stored data. All main headings, “Bookmarks”, “My browsing history” etc. can be expanded and hidden and show recent activity.

A search box enables users to search across all stored data (with the exception of passwords) — searches would also be filtered by data type (bookmarks, history, tabs etc.).

Bookmarks

Both Firefox’s existing method of organising bookmarks and the bookmarking sharing service Delicious allow users to file bookmarks of websites and categorise these by tags (Firefox and Delicious) and / or sorting by folder (Firefox). Whilst this allows for cross-referencing of bookmarks, bookmarks are presented textually as the title of the website, its URL, user generated tags, and in the case of Delicious, a textual description.

My model presents the data visually, showing thumbnail images for each bookmark, alongside its metadata, some of which is automatically generated (URL, site title, date visited), other parts of which are user generated (tags). In this visualisation, all data can be edited in place (as with editing photo metadata in Flickr). Bookmarks can also be deleted via clicking on an icon with a suitable “delete” metaphor, and filed in one or more folders (like Flickr “sets”). The method for filing shown in the prototype was also influenced by Google Mail and Reader’s method of associating emails / feeds with one or more folders.

The folders created by the user are shown to the right, much like sets in Flickr. These can be edited by activation of the relevant edit link. Users may wish to edit the folder’s title and thumbnail image, using either the thumbnail of a representative website or an image selected by URL or direct upload. A default placeholder image would be used in the absence of a selected image.

Browsing history

Firefox’s current “show history” option presents a textual list of previously visited sites, showing the following metadata: site title, tags and location (URL).

Jason Hong’s paper cites research that, although up to 81 per cent of web pages visited by users are revisits, web browser history functions are only used around 0.2 per cent of the time to initiate these visits.

In this model, browser history is visualised as it is to an extent in Safari and Chrome, but with more accompanying metadata and the ability to add the sites as bookmarks. Selecting the “Add to bookmarks” functionality allows users to add and amend site metadata and file the bookmark in an existing folder (or in  a a new folder).

The time periods selected for differentiating browsing sessions are kept as per the standard Firefox organisation, i.e. today, this week, then previous months. A calendar widget is suggested as an alternative way of browsing by particular day, with the page content updated dynamically as the user clicks through dates. Other sort options which might suggest themselves are: web site title, URL, the device the page was accessed on or by tabs.

Part 2: tabs, web accounts (credentials) and preferences.

Please read: part one: introduction, bookmarks and browsing history first.

Tabs

Visualising tab history across a number of devices is possibly a little more challenging than considering bookmarks and general browsing history. Tabs can be open on any number of the user’s devices so one obvious question to be considered is how to arrange this information.

The tabs visualisation stays with the main visual metaphor, with history broken down per tab per device. This assumes the user has some way of adding and deleting participating devices — e.g. a copy of Firefox at home, or another browser running on another computer such as a work PC, laptop or mobile browsing device.

Tab data includes the title of the page being viewed and the tab history. The visualisation displays a thumbnail of the currently open page and previously visited pages. There should be a straightforward way for users to open this on their current device (and possibly all tabs open on other devices), and to save to bookmarks (or if the site is already stored as a bookmark to easily see this).

Views may change slightly depending on how the data is sorted — for instance, if the list were sorted by device name, then the displayed metadata could include information about the device the site was initially opened on.

Accounts (credentials)

Whilst it might be useful for users to synchronise account data across a number of devices, it is also the type of data which lends itself least readily to being visualised; in fact it is not appropriate to visualise data such as passwords.

In this model, sites with stored credentials are again presented as browsable thumbnails lending the user the ability to log in directly to protected sites. Some sites may offer API functionality which allows users to manage their credentials via Weave, but the majority will require the user to visit them in order to do so. Any changes to credentials would need to be synchronised immediately in Weave.

Preferences

Firefox preferences include a number of different options, the more obvious being browser home page, or Firefox persona. Some of this information may be Firefox-specific, other less so (e.g. home page). The visual metaphor can still be used, employing site thumbnails for selected home page or a visual representation of the selected persona. It could also be useful for users to be able to export the relevant parts of this information for use with other browsers if it cannot be directly applied (e.g. for Internet Explorer, Safari or Chrome); similarly options should be available to import data from a file generated by another browser or to be accessed via Firefox’s preferences menu, providing an option to pull the information directly in from Weave.

Summary

The model presented is quite simple and does not attempt any advanced data visualisation. Instead it uses models of organisation and interaction that users may be familiar with from using other social networking / asset organising websites. It is particularly influenced by models for organising visual information, for instance Flickr’s model of managing photo metadata.

Posted via email from What’s this for?

I ordered a cycling map from Transport for London today. I think the “personal details” section of their form could do with a little work. All the fields are mandatory, including title (Mr, Ms etc.) and phone number. If you don’t fill these in then you get an error message, although you’re not dropped back to the relevant section in the form to correct your “mistake”.

I’m struggling to work out why your phone number and title could be in any way relevant for the delivery of a free cycle map by post.

Posted via email from What’s this for?

But, the worst part of the process for me was at the payments stage. When asked to submit my credit card details, I automatically hunt out the sure signs of a secure payment system — basic stuff such as a https in the URL bar and a padlock icon appearing. I saw neither in this case. Ok, it’s possible that the secure part of the site was buried in a frame, so I right-clicked to get a context-sensitive menu on the form hoping that this might reveal some information. It didn’t, so I quickly cancelled my sign-up.

I contacted the City Lit the next day and they assured me that the process is completely secure. This is what they had to say:

Thank you for your observation and be assured we take online card security very seriously. You will be comforted to know that Netbanx collects card payments on our behalf in a secure and PCI compliant environment. PCI DSS (Payment Card Industry Data Security Standard) is a world-wide benchmark mandated by the card schemes for the protection of cardholder identity and transaction information. Netbanx is a reputable company that was founded in 1996 and was the UK’s first payment service provider . We have been using their services since July 2006 without incident … Please be reassured that whilst the padlock does not appear, the payment window within the online enrolment window is secure with 128 bit encryption.

The first part of this sentence doesn’t mean much to me not being a security specialist. However, whilst I’m reassured that they do take security seriously, I’m concerned that the user receives no information or feedback as to the level of site security.

Now, I haven’t got any screen shots to back this up  – and can’t get any without going through the process again — so I’m prepared to admit I may have missed something, although I did examine the page in-depth. Some clear, explanatory text would have set my mind, and presumably others’, at rest — if you take pride in the level of security you offer, then let your users know (maybe skip the bit about PCI DSS though!).

Posted via email from What’s this for?

But, what I like about it the most is the fact that positioned next to it, held on by a fraying piece of sellotape, is a sign on A4 paper that gives you instructions on how to use it: something along the lines of (capitals as per original):

PANIC ALARM BUTTON.

PRESS THE BUTTON ON THE UNDERSIDE OF THE BOX

I love the fact that should you find yourself in a state of panic, you need to carefully read some instructions (which may or may not still be pinned to the wall) to locate the exact whereabouts of the button you need to press to set off the alarm.

Actually, I think all panic buttons should look like Ren and Stimpy’s history eraser button:

I would have preferred to have had some way of navigating through the information on the splash image — for instance, some carousel-style controls or something along the lines of the BBC home page:

On the BBC home page, there are clear controls to change the splash image — they even tell you what you’ll expect to see.

The problem with the Tate approach is that each image displays for about five seconds. I counted six images, so that’s thirty seconds you need to wait if you want to take another look at something that caught your eye. One sure way to frustrate your users.

I really like this approach — summarising the new features in a lightweight overlay with two clear headings: one announcing the new drag and drop functionality relating to labels and messages, and the second answering the question, “where did all my labels go?”. If you’re left in any doubt, the two diagrams nicely sum things up. There’s some clear calls to action in there too — the “Ok” dismisses the overlay and the “Manage labels link” allows you to decide for yourself which labels you want to appear on the left.

The functionality itself is quite interesting — it’s the closest Gmail has come so far to emulating the traditional folder set up found in many email clients. If you drag a message, it gets assigned a label and automatically archived, so it doesn’t appear in the main inbox. Gmail’s lack of folders has never personally bothered me; in fact I tend to find that using folders is quite often a short-cut to losing mail. Still, it’s quite useful when it comes to things like mailing lists which can quickly overwhelm your inbox.

A valid drop target is indicated via the label name becoming highlighted in inverse, e.g. white text on a blue background which is pretty intuitive. The tool-tip, “Move x conversation[s]” also changes colour to match. It’s less obvious when you choose an invalid target — in fact you get no feedback other than nothing apparent happening:

A valid drop target in Gmail.

An invalid drop target