Hi Hank,

Here is my belated response to this email. Apologies in advance for the long ramble. You bring up some interesting points that touch on many of the design principles undergirding Chandler's design.

See in-line comments...

On Jan 25, 2007, at 11:08 AM, hank williams wrote:

> Mimi,
>
> Yes I think what you described does the trick.
>
> My only concern, which I experienced when playing with the latest
> published version, is the logic for what will get displayed in the
> date column is very confusing. I know you are trying to just make the
> best judgement as to what is put there, but I call this kind of UI
> issue "action at a distance". It is the notion that you change
> something on one side of the room, and for reasons that are not
> exactly clear, other things change on the other side of the room. My
> point here is that it is not at all clear, from an item to item basis
> why a given date is showing up.

I am not surprised that you have this experience today. The Date column is mostly an Alpha5/Preview feature. What is in Alpha4 is a tiny fraction of the work Bryan Stearns has done for Alpha5. We will be looking for feedback from you on the Date column when Preview is released :o)

We are also very concerned about whether or not users will get the Date column. From the design perspective, this is our 'best guess design' amongst a sea of not-so-great alternatives. As soon as you go down the path of trying to display variegated data types in a single table, you are faced with an impossible choice between: A. A separate column for each variant on date/time information; or B. Pick one common date value (e.g. Date created) which for many things simply won't be useful; or C. Pick a smart date column that tries to guess the right value at the risk of confusing the user.

We chose to take a crack at C, before giving up and retreating back to A or B.

> And interestingly, you find it too
> complex to explain here, which is interesting evidence in and of
> itself.

As a design philosophy, I disagree with the idea that things that are difficult to verbalize are necessarily hard for people to understand. It's incredibly hard to verbalize the exact attributes that make an orange and orange. Yet humans have no difficulty recognizing one. The verbal part of the human brain is just that, a part of the brain and I find that in general, the 'write-it-down' approach we take to designing software functionality places a huge limitation on designs, essentially boxing users into experiences that are easily definable in words and code. That being said, complex design does not necessarily make good design. So, we are watching dogfood feedback concerning the Date column very closely.

Part of the complexity I was trying to avoid in the thread was going over all of the user research and interviews that led up to the design, rather than explaining the rules that govern the date column in and of itself.

Most importantly, we are eager for dogfood feedback to understand where users get stuck/confused with the Date column in the context of specific use cases. That is our best, proven method to not only identifying problem areas, but also coming up with design solutions.

> I know the little icon is supposed to help out with
> understanding what is going on, but initially I really didnt
> understand that at all. After a while I kinda guessed that it might be
> something like what you said, but I wasnt really comfortable. One
> thought is to create a rollover for each date to explain what type of
> date it represents.
> Text is always better than icons, and it would
> work for more than just the distinction between alarm and start time.
>

True, text is better...with the caveat: for some people, in some situations. Because it is also true that icons are better for others people in other situations.

A well-executed icon can communicate the essence of an idea way better than text, primarily because text (at least in alphabetic writing systems) is uniform. The same letters are arranged and rearranged to express everything from complex human emotions to mundane everyday objects. The word BAD doesn't look any bad-er than the word GOOD. The word GREEN doesn't look any green-er than the word RED. Images are grokked all-at-once, subconsciously. Words need to be parsed and processed consciously. But some people are faster at processing words than images. It's the good ole left brain - right brain debate.

We can't help the differences between people (other than to try our best to offer both icon and text options whenever we can, so your tooltip suggestion is definitely the right thing to do here.) But most of the time, you still need to pick a default. This is where context comes in. We can improve our changes of picking the right default by understanding: 1. The nature of the concept we are trying to communicate; and 2. The nature of the communication tools at our disposal: text and icons.

In other words, we want to avoid banging the proverbial nail with the proverbial screwdriver.

It's not that hard to figure this out. Concepts that have clear, unique physical manifestations do well as icons.

Concepts that don't, don't: Philosophy, Language, Strategy, Level playing field, Wait, Undo, Parking, Mistake, Difficult. You can imagine lots of things that would communicate Mistake, but are they unique? Could you different them from icons representing Broken, Surprise, Regret, Alert, Danger?.

Concepts that do, do: Happy, Men, Women, Physical objects like Telephone and Hammer, and Concepts that have 'universally understood physical gestures' Stop. The more abstract a concept, the harder it is to convey as an image. The more concrete, the easier it is to render as an image.

When icons fail it is because they are rendered poorly or are being misapplied. The uniformity of most UI frameworks (e.g. You can either have all icons with text or all text with no icons, or all icons, not text makes it harder to be smart, aka context-sensitive about how and when you use icons and text. We get around this inflexibility in Alpha5 by creating graphics with text on them to represent NOW, LATER and DONE...in the Dashboard and Markup bar. But as you know, doing that will be make it harder to localize the triage status button.

Because they are concrete, physical objects, Calendar and Alarm are 2 relatively easy ideas to communicate visually. What we have today is not the best execution possible, but it's something we can improve on over time.

Now, back to practical matters, Tooltips will certainly help. ;o) We could also have text abbreviations in the column, the way we do for the WHO column. ST (Start), REM (Reminder). Although that will take up precious horizontal real estate. I have added a request for tooltips for the Date column to the Dashboard tooltip bug: https:// bugzilla.osafoundation.org/show_bug.cgi?id=6357

Mimi

> Hank
>
> On 1/25/07, Mimi Yin wrote:
>> In a word yes, you will be able to do what you describe below.
>> It's not
>> really a separate view, but one of the ways you can manipulate the
>> 'center
>> pane'. See more in-line...
>>
>>
>> On Jan 24, 2007, at 9:19 AM, hank williams wrote:
>> On 1/24/07, Mimi Yin wrote:
>> > Would you mind elaborating on the specific use case motivating your
>> > request?
>>
>>
>> Sure. Years ago I wrote a PIM, and one of the most popular
>> features (and the
>> feature that I hear most about from former users) is the ability
>> to look at
>> your collection, including addresses, calendar items, note items,
>> todos etc,
>> in the order that they were created/edited, with the most recent
>> first. This
>> allows a user to see what they have worked on more recently. For
>> example "I
>> know I added this guy in the last few weeks" or "I know I added
>> this note
>> within the last few days". Being able to see your workflow in the
>> order you
>> create it is exceedingly valuable.
>>
>> Yes very cool!
>>
>> In the Preview timeframe, you will be able to do the following:
>> + Sort by the 'Date column' which will sort items by the date that
>> appears
>> in the Date column.
>> + Most of the time, the Date will be something to the effect of
>> date created
>> or date last modified (which includes date last sent as well.)
>> + The only caveat on that is: If an item is an Event, then the
>> Event start
>> date/time displays in the Date column; and/or
>> + If the item has a Custom Tickler date, aka Alarm, then the Alarm
>> date/time
>> displays.
>>
>> It's actually more complicated than that, but I won't get into
>> that here.
>> You can read Bryan Stearns' extremely succinct write-up to the
>> list here:
>>
>> Post Preview, we would like to be able to implement a more
>> sophisticated way
>> to 'browse' items by date which would include things like:
>> + Sectioning a view by Date ranges: Today, Yesterday, This past
>> week, Next
>> week, Last month, Next month, Last year, etc... (Essentially a
>> timeline view
>> of your PIM activities :o)
>> + The ability to list a single item multiple times across multiple
>> sections.
>> e.g. Item was created on this date, and then edited on that date
>> and then
>> sent on that date and then added to the calendar for this date and
>> then
>> tickled for that date.
>> + Ability to 'narrow' down the range of items you see using the
>> mini-calendar control.
>>
>> Is that along the lines of what you were imagining?
>>
>> Mimi
>>
>>

-- MimiYin - 09 Feb 2007