On Nov 6, 2007, at 9:14 AM, Dan Steinicke wrote:
No, I am speaking as a user of software. I like software behavior
that follows established conventions (sorting caused by clicking
column headers, tables not re-ordering immediately after edits),
unless there is a very clear need to operate differently. I don't
see the need to depart from convention in these cases. I fear
that needlessly departing from convention makes it harder for new
users to understand the app and will lead to lower adoption levels.
Is that always true? In OS X, the list views resorts automatically.
Not sure why our table follows that convention rather than the
Windows convention. John / Robin might be able to answer that
question better.
I think the idea is that most of the time, users are sorted by
Triage, so this isn't as much of an issue.
Right, so long as they are sorted by triage, one of seven possible
sorts, they are good to go. I feel that a large segment of our
potential users won't understand this and will be confused and
disappointed by the behavior. I see confusion of new users as a
major barrier to adoption.
As part of recording a test script I wanted to select each item
in the table from top to bottom and add a 'X' at the beginning of
each title. I found this operation difficult to do because
regardless of which column I sorted on (I tried Title, date, and
task) at some point the table would re-order in response to my
edits. I find this automatic re-ordering very annoying behavior
and find it hard to believe most users would want the table to
behave this way.
This would work if you sorted by Triage Status, no?
Yup.
I think this also ties in to the end user confusion around the
"Triage" button. I have always thought it would be much more
intuitive to just have the triage column header button do what
the "Triage" button now does. In my understanding the main
function of the "Triage" button is to prevent row reordering when
you change the triage state. If rows only re-ordered when the
headers were clicked then it would seem we would be able to
simplify this work flow as well.
I think we can make the column header do the same thing as the
Triage button.
The disadvantage of having *only* the column header as the way to
Triage is that users will want to 'Triage' often, but not reverse
the sort order often. I think we'll run into people not wanting to
click on the column header because they don't want DONE to be at
the top.
I don't see this as much of a disadvantage, all they have to do is
click the header a second time to get back the sort order they
want. If this makes our app more intuitive for first time users I
still think it is a better way to go. If this is a big concern I
could see changing the triage header work by reversing the sort
order _only_ if there was no triaging to do, if there was triaging
to do it would only do that.
I think if we can come up with a better name for the Triage button,
that would be the best solution. I don't know about sacrificing every-
day usability for something as central as the Triage workflow. I
*hate* the fact that in Apple Mail I always have to sort by Date
column first and then sort by the Flag column to get the sort order
right. I do it 10 times a day. If the column header also works to re-
order items, why get rid of the Triage button?
There's also the problem that if the column header resorts *and* re-
orders, there's no way to do one, but not the other.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
