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

While functional prototypes always involve development tools (and associated skills), there are, essentially, four classes of tool for creating user interface prototypes:

1. Pen and Paper

It doesn’t get any more low tech than this, which is great because it means that absolutely anyone can take part in the design process. User interface designs can be hand drawn or pre-prepared stocks of user interface elements can be laid out on a page.

Paper sketches can be produced very quickly but making alterations to a design can be somewhat difficult leading to repeated effort if a design needs to be restarted from scratch. It’s often best to spend more time thinking before committing pen to paper.

In test and review situations, a human can act as the computer and present the effects of user actions on a design. It’s highly involved and may be time consuming to run user tests, but it can be very effective.

Of course, this isn’t necessarily restricted to paper. Many design sessions involve whiteboards instead of paper – anything that takes you away from the computer and into the undisputed realm of the ‘mock-up’. But any whiteboard design that needs to be ’saved’ will inevitably end up as a photo image and/or paper printout.

2. Drawing tools

Generic drawing tools can be used to mock-up user interfaces with the obvious advantages over pen and paper of being easier to edit, duplicate and distribute for review.

Many of the popular drawing tools (Microsoft Visio, The Omni Group’s OmniGraffle, etc.) have an increasing number of UI stencils available to them. However, many of these are based on graphic images that do not scale well.

Graphic editors (such as Adobe Photoshop) can also be used for creating interface mock-ups, from low fidelity wireframes to high fidelity pixel perfect renditions. This has been the preferred approach for many Web designers where the exact visual design of graphic elements is important. Expert knowledge of these tools is often required and producing designs quickly from scratch can be daunting.

However, with all of the generic drawing or graphics tools, what you end up with is a set of static screen designs but no easy way to communicate how the parts interact and the workflow between them. Although there are some documented techniques to get around these limitations, they take some skill and learning.

One approach is simply to take printouts of the screens and perform paper prototyping review sessions.

3. Development tools

Development tools have always been an option for the production of prototypes with Rapid Application Development (RAD) tools having earned some degree of popularity. The main benefit is being able to produce a fully working prototype that acts just like the real thing even if some of the actual functionality is being emulated with dummy data.

For evolutionary prototyping, this is the only way to go, but for throwaway prototyping, the additional time and skills involved and all of the disadvantages with regards to evolutionary prototypes, make this a fairly poor choice.

4. Specialised prototyping tools

Here’s where it gets more interesting. Combining the benefits of drawing tools and, in some cases, development tools, specialised prototyping tools (like GUI Design Studio) allow you to rapidly create software prototypes with features that allow the application interaction and workflow to be explored.

Because they are intended specifically for the design of user interfaces, they have dedicated functionality that is not necessarily found in the drawing tools but are as easy to use so they don’t require any specialised technical skills.

Many of these tools will allow designs to be easily annotated, shared for review and used to generate specification documentation.

Of course, I’m biased, but these are really the best type of tool to use for software prototyping.

Whatever approach you take, software prototyping can reap huge benefits in the production of your software projects and make them more likely to succeed.

People often talk about “Throwaway Prototypes” versus “Evolutionary Prototypes” and it’s very important to understand the difference and exactly what type you are creating before you begin.

Throwaway Prototypes

A Throwaway Prototype, as the name suggests, forms no part of the final application. Its purpose is to prove (or disprove) a design and get approval for actual implementation.

It can be produced using any quick and dirty technique and the quality can even be quite poor, so long as it satisfies the requirements of identifying what’s right about a design, what’s wrong and what’s missing.

Because of the speed at which Throwaway Prototypes can be put together and changed (usually on-the-fly), they encourage feedback and continual revision until the design is about right.

Because the effort required to produce them is relatively small, there’s less ‘attachment’ to a design and therefore very little reluctance to change. However, you do need to be careful that you don’t end up in an endless cycle of analysis and revision without making any development progress at all!

Evolutionary Prototypes

In contrast, Evolutionary Prototypes are intended, right from the start, to eventually evolve into the final, delivered application (or system) through incremental developments and changes. In one sense, this seems like a great idea because each increment is getting you closer to a delivery and progress is clearly being made.

However, there are many risks involved in this approach. Because it involves implementation of the system itself, the coding has to be of production quality from the start. The idea of ‘cleaning it up later’ is a very bad one since this will never happen in practice, leading to potential problems and instability later on. But this conflicts with one of the key benefits of being able to create prototypes quickly. Also, because of the effort that’s gone into it, there can become too much attachment to the implementation which leads to a resistance to change.

Not only that, it’s very difficult to see the ‘bigger picture’ with an evolutionary prototype because you can only see, and therefore review, the parts that have been implemented and it’s very difficult to compare different versions or approaches to a given design.

There’s another potential problem with evolutionary prototypes. Sometimes you’ll already know what technology you’ll be using but sometimes you will be free to choose what’s best for the application. By creating an evolutionary prototype you will be committing to an implementation too early when a more suitable technology or component set might become apparent later on once the requirements of the application are better understood.

In the last part of this article we’ll discuss different methods and tools for generating prototypes.

Prototyping in the software industry is not so common but the benefits are just as compelling.

There are two main types of software prototype: functional prototypes and user interface prototypes.

Functional Prototypes

Functional prototypes are nearly always technical in nature and their purpose is to test whether an idea or design is actually feasible using a given technology. For example, whether a particular system might be able to handle 100,000 transactions a second or whether it’s really possible to perform a content match on thousands of data records in real time as a user types in a search query.

Functional prototypes will always involve getting down and dirty with the code and trying to build a working version of something that can be tested to validate the idea.

User Interface Prototypes

User interface prototypes, on the other hand, are more about the presentation of concepts and ideas, and are therefore less technical and more accessible. Interface prototypes represent the front-end of an application or system; the part a user will actually see and interact with. In fact, in most cases, this is all the user is really interested in.

User interface mock-ups and prototypes allow both users and developers to understand the application before it’s built; to test its usability and ensure that all of the requirements are covered. All too often, software is built that has the most amazing functional engine, under the hood, that runs at lightning speed, but users hate it because they can’t understand how to use it. The user interface has just been hacked together rather than carefully thought through.

There are many different techniques for creating user interface prototypes, covering the full spectrum from using nothing more than pen and paper to the use of full-blown development tools. In-between there are more specialised tools, like GUI Design Studio, that are more suited to the job.

In the next part of this article we’ll talk about the difference between a “Throwaway Prototype” and an “Evolutionary Prototype”.