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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
