[Design] viewing by creation/modification date

[Mimi Yin]

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 <mimi at osafoundation.org> 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 <mimi at osafoundation.org> 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
>>
>>