Re: Should dashboard display order change immediately after edits?

Mimi Yin wrote:
> On Nov 1, 2007, at 10:29 AM, Dan Steinicke wrote:
>
>> Currently the display order of summary table rows can change 
>> immediately after a user completes an edit on an item.  I think this 
>> is undesirable behavior.  I think the table view should only re-order 
>> when the column headers are clicked, or in response to the passage of 
>> time.
>
> Dan, are you speaking from a testing perspective? 
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.
> 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.
>
>>         Are there users out there who like the automatic re-ordering 
>> in response to edits? Are there users out there who are annoyed by 
>> the dashboard re-ordering in response to edits?
>> Dan  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design