February 22nd, 2008

Forum’s Ready

It was missing. Users wanted it. And the “Blog” and “Wiki” buttons really needed another companion: today we added a Forums section to our Things pages.

The user forums are based on the open source Phorum software. We took some time to create a suitable template however. Forums around the internet have a tendency to look cluttered, which is why we tried to cut down everything to the essentials. One of the key design features is that, even when only briefly glancing, the user always knows which level of the hierarchy he or she is looking at:

  • the list of all forums,
  • the topic list of a selected forum, or
  • the list of posts of a selected topic.

These three levels have a distinct look and feel without compromising the visual unity of the user forums as a whole. We also carefully made sure that the forums would fit in well with blog and wiki. We even redesigned the comments section of the blog to use the same visual approach as posts do in the forum.

Not every aspect is completely finished. In particular, users will need to create a new account for the forums even if they already have a Wiki account. The software for the Wiki (MediaWiki) and the Forums (Phorum) is completely different and it would have taken us much more time to write unified user management for both. We hope to be able to do it some time down the road. But the level of refinement should be more than sufficient for discussing everything Things.

Now who will be the one to create the first topic?

February 4th, 2008

Habemus Dialogum – We Have a Dialog

This article is about a single dialog. The dialog with which users will be able to specify the repeat settings of a recurring task.

When you set out to do something new, it is a good idea to have a look at what others in the field have done before. When we began to approach recurring tasks, we looked at iCal’s recurring events. We wanted Things to be as flexible and powerful as iCal. The corresponding interface in iCal also seemed well done. Naturally, we copied it. Here is an example:

blog_repeatingtasks_old.jpg

Not too shabby, is it? It seemed fine in theory. But after implementing and combining it with the underlying logic, it took us only minutes to discover that it didn’t work as expected. Not that anyone was able to tell exactly why. And that’s often the case when developing user interfaces. It just didn’t feel right. But how to improve it? We don’t remember how many mock-ups we passed to each other in the search for a solution. Here is a selection of them, together with the iCal inspired ones:

blog_repeatingtasks_dialogposter.jpg

In hindsight it is much easier to tell why we didn’t like the previous approach:

  • We made users think about whether recurring tasks have a due date even before they had a chance to enter the recurrence pattern.
  • Regardless of the chosen interval (daily, weekly, monthly, yearly), the last option was always “after completion”. Repetition in user interfaces is often a bad sign.
  • We wanted to have the option of generating tasks for iCal events (think birthday calendar). But the user had to select “yearly” first in order to even discover this option.
  • The iCal inspired controls itself weren’t optimal. They took up a lot of space. And we often accidentally selected multiple days when we just wanted to change the current setting.
  • We wanted to add support for start and end dates as well and felt that this would clutter up the dialog even more.

To cut a long story short, we are still friends :), but we fought uncompromisingly, and now each one of us is satisfied with the result:

blog_repeatingtasks_createfinal.jpg

Why we like this one:

  • The user gets to choose “daily”, “weekly”, “monthly”, “yearly”, “after completion”, “for iCal events” first. No more repetition of the “after completion” option. The “iCal events” option is easily discovered.
  • The box below the pop-up collects precisely those controls that depend on the chosen selection. (“Next” and “Ends” don’t apply for the “after completion” and “iCal events” selection and needn’t be shown in those cases.)
  • Simple recurrence rules can be specified using just one line of controls, e.g. “every 1 month on the 1st day”, or “every 1 month on the 2nd Sunday”. If the recurrence rule is more complex, additional lines can be added by clicking the + button. So, the complexity of the dialog scales with the complexity of the recurrence rule!
  • Unlike iCal we don’t have the luxury of a large calendar to show the result of specifying a recurrence rule. Yet, we still found a good place to show upcoming dates: right after “Next”.
  • Some repeating tasks have due dates, some don’t. Just before the user confirms the dialog, he or she is invited to clarify whether the specified dates were actually meant as due dates (e.g., “pay rent on the last day of every month”). In that case, the user might want to also specify how many days before the due date she would like to see the corresponding task in her Today list (for the better part of the month she probably doesn’t want to know about the payment).

blog_repeatingtasks_duefinal.jpg

Note how the dialog slightly changes to reflect that dates are now meant as due dates.