When we started designing this feature, we looked around for examples of different calendars in desktop and web applications. We found a wide range of different designs; some with one month, some with 3 or 4, some highlighting “today”, others highlighting a particular day or a range of days. Of course, each application had quite a different visual design to its calendars as well.

In the past, we’ve tried to simplify elements and minimize the number of settings and options they have but, with this new element, we felt we had to provide for the increasing demand on design flexibility.

The problem, as all of you designers of great user interfaces will know, is that with flexibility comes complexity. We didn’t want to give you a tool which is hard to learn or slow to use because it has so many options and special cases, but we did want to give you a tool which will let you create the calendar design you need, quickly and simply.

That was the aim.

We’ve ended up with eleven different areas or labels. There is the Main Control background to the element, the Title Box, an optional Week Numbers column, a Week Day Names and Weekend Names title row (weekends don’t have to be different from week days, but they can if you like).

Then there are the Week Days and Weekends that appear in the calendar body. You can choose to display the Trailing Days in a month (these are the days from the previous month that make up the first week of the current month, and the days of the next month which complete the final week).

Finally there are the specially highlighted days; Today Highlight, Selected Day and (because selected days can be in the trailing period) the Selected Trailing.

Each of these needs a colour for the background (Fill), the Border and the Text. That is 33 different colours!

Here’s what the ‘Colours’ property panel looks like:

And that’s before we even start talking about the options to specify what parts of the calendar should be included, cell sizes and spacing and various other controls.

Actually, we could have gone further. While trying to replicate some of the designs we came across, we found the need for even finer control over some of the colour and layout parameters.  But there comes a point when you need to say ‘enough is enough’ and compromise between total flexibility and usability.

Clever use of the different colours and the various borders and spacing between the elements allows you to create an incredibly wide variety of calendar designs.

You’ll find a small gallery of some of the possible designs below. The top one’s from Windows XP but the rest of the examples are loosely based on calendar designs from around the Web, including Google and a range of examples highlighted in Antonio Lupetti’s blog post on “Beautiful datepickers and calendars for web developers”.

So, what do you think? Did we provide enough styling options, or too many?

We think we’ve got the balance just about right, but we’re happy to hear your opinion too. We’d also love to showcase your own beautiful calendar. If you have a design you’d like to share, or something to say about the new element, why not post a comment?

Enjoy your GUI Design Studio Calendars!

The experts at UXmatters have done extensive research in this area and have a lot to say on the subject.

In an article, published earlier this week, they provide detailed answers to a question about Label Alignment in Long Forms.

And that article is essentially a follow up to their Label Placement in Forms article published over 3 years ago but still as relevant today as it was then.

Using eye tracking tests with users, they tested the time spent filling forms and, specifically, the eye saccades between labels and entry fields. This basically showed how much effort was required by the eyes to scan the form and by the brain to make sense of what it was seeing.

Here’s my interpretation of the results:

1. Placing labels above the entry field is preferable in most cases as users can view the label and input field at the same time. It’s important to leave space between each input field and the next label.
2. When placing labels to the left of fields, although left alignment allows a user to quickly scan down the list of entries, right alignment is much better as it keeps the label with the input field and greatly reduces eye movement and effort.
3. A caveat to right-aligned labels placed on the left is that it’s very important to try to keep them all to a similar length to avoid large areas of ragged whitespace. Shorter, concise labels are better but they must still make sense.
4. Bold text labels are almost always a bad idea. Users find them harder to read and they pull the focus away from the input fields. The increased time with bold compared to normal labels in the tests was surprisingly significant.
5. For long forms, placing labels above entry fields increases the length of the page so might not be such a good thing. Long forms can often be improved by grouping entries and group labels can also add visual confusion when labels are above fields.
6. These are not rules, they are guidelines. More important than any of this, especially for long forms, is to ensure that users can easily comprehend the form, that they scan easily and that users are only presented with requests for essential information so that they are not daunted by the form and are willing to complete it.

This is just a very brief summary and doesn’t do the detailed articles justice at all. I highly recommend that you read both articles. If you thought this was a mundane subject before, these articles and the huge number of comments they provoked will open your eyes and hopefully make you a better interface designer.

We are planning a complete revamp of element property editing in GUI Design Studio (among other things) so this has been vital information for us. I think there are improvements we can make everywhere in this area!

Here are the article links again:
Label Placement in Forms
Label Alignment in Long Forms

In the highly competitive smart phone market, a new breed of phones based on Google Android are doing just that, going head-to-head with the Apple iPhone.

Whether or not you’re interested in smart phone technology, this video, comparing the new HTC Hero with the iPhone 3GS (courtesy of PhoneDog.com), contains a great example of taking a specific user profile and creating a targeted user experience for them.

In many respects, the two phones are similar, but see how the folks developing the HTC Sense UI have focussed their efforts on provding a far superior interface for people who need to communicate through email and social media. This is a very specific (and growing) target market and a key distinction for HTC when the Hero lags behind the much more mature iPhone in many other areas.

Parts 2 and 3 of the review are less interesting from a user interface design and usability point of view as these are more concerned with performance and comparison of like-for-like application features.

However, it’s worth watching Part 2 from around the 7 minute mark for another great example of how the HTC keyboard interface and the spell checking facility has some really well thought out advantages over that of the iPhone.

From a hardware usability perspective, it’s interesting to note how the ‘chin’ of the HTC Hero causes the device to flip up when it’s placed on a flat surface and the buttons are pressed. This may have become an issue for early users because newer versions seem to have dispensed with the chin and adopted the more streamlined, flat form factor.