headers
Dan Steinicke | 1 Nov 2007 18:29
Favicon

Should dashboard display order change immediately after edits?

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.

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.

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. 

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
(Continue reading)

Permalink | Reply | 34 comments |
headers
Keith Winsor | 1 Nov 2007 23:05

Re: Should dashboard display order change immediately after edits?

Dan Steinicke wrote:
> 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.        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  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Dan,

I agree re automatic sorting making it confusing to keep track of items.

I'm not so sure about 'simplifying' the Triage button. I've noticed 
(i.e. this method of usage has crept up on me and your post has made me 
realise how I do it!) that I tend to make triage decisions in the Now 
section on a screenful of items at a time, then triage to dispose of the 
Dones and Laters I've just marked, before dealing with the next batch. I 
guess it gives me my instant gratification in more manageable chunks! It 
occurs to me that if someone has amended a shared Later event (which 
pops into Now as a result) that by doing this I might miss the event 
unless it shows up on the first page of Nows, and triage it unseen back 
to Later, so maybe I should just change my usage pattern, in which case 
using headers would be a viable solution. But I think the triage button 
is a bit of a USP of Chandler and genuinely gives you that 'I've 
achieved all of this' feeling, where clicking on a column header 
doesn't. So objectively I agree but subjectively I disagree!
(Continue reading)

Permalink | Reply | 29 comments |
headers
Bobby Rullo | 2 Nov 2007 00:41
Favicon

[cosmo] Too Many Dashboard Items!

There is a bug (https://bugzilla.osafoundation.org/show_bug.cgi? 
id=10759) which says Cosmo UI takes too long to load.

The reason it takes too long to load is because there are lots and  
lots of NOW items, and we always return all NOW items in the  
dashboard query.

The reason there are lots and lots of NOW items is because people  
don't triage their items.

Those are the facts. What is less certain is WHY people don't triage  
their items - I suspect it's for a number of reasons such as:

	a) They don't use triaging
	b) It takes too long to triage each item manually

Esther was the impetus for filing this bug - she went to view the  
Mitch8 calendar and it had 38 pages of NOW items. She and Mitch don't  
use the triaging bits of Chandler right now, so she never triages  
stuff to DONE. (For clues to _why_ she doesn't use triaging see  
http://lists.osafoundation.org/pipermail/chandler-users/2007-August/ 
000437.html and the rest of the thread. Esther wants finer-grained/ 
customizable statuses for one thing...)

Several ideas on how to fix this problem have been proposed. From the  
bug comment:

> We could limit the amount of items returned in the now query to  
> some arbitrary
> number.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Andre Mueninghoff | 2 Nov 2007 14:12

Re: Should dashboard display order change immediately after edits?

Though I'm not annoyed particularly by the automatic re-ordering in
response to edits, I think it is unhelpful much more often than helpful.
I find the automatic re-ordering somewhat useful when I have sorted on a
particular column, for example, and am making similar changes in that
field for several items, as the changed items "disappear" to their new
location in the table, there is a sense of completion of sorts. The
downside being that if I have further edits or want to verify my edits
for some of these items that have jumped automatically to a new
location, I have to go find them. 

I have a proposal. What if the Triage button on the toolbar became in
essence the "refresh the sort order" button for all columns displayed in
a table. That is, there would be no automatic re-ordering of items in
the table in response to user edits. Edits to items in any field
displayed in the table (including kind stamps) would be used to sort the
items when the Triage toolbar button is pressed. Automatic reordering
triggered by alarms firing, inbound changes to items, etc. would be
unaffected. Behavior produced by clicking on the triage status column
header would be unchanged. 

My personal new item triage workflow frequently includes making several
different edits to each item in addition to changing its triage status.
I think this proposal would address Dan's issues, and Keith's usage.
What do you think? What am I missing?

Cheers, Andre

On Thu, 01 Nov 2007 22:05:34 +0000, "Keith Winsor"
<kjwstuff <at> btopenworld.com> said:
> Dan Steinicke wrote:
(Continue reading)

Permalink | Reply | 28 comments |
headers
Jeffrey Harris | 3 Nov 2007 04:26
Favicon
Gravatar

Re: Should dashboard display order change immediately after edits?

Hi Dan,

> 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.

I'd be happy with changing this behavior, from a usability perspective,
but I'll note that I think implementing such a feature would be non-trivial.

Personally, I never bump into this because I never sort on anything
except triage status, but that's just me.

> 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.

The problem with this is that the triage button is important to sharing
workflows.  If you're viewing items sorted by title and you get new
inbound items, you don't want to click on sort by triage and lose the
information that there were inbound changes to a later item.

I'd be happy to rename the Triage button Re-sort, though.  There was
feedback today at our usability sprint that "triage" isn't a generally
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andre Mueninghoff | 4 Nov 2007 02:49

Re: "restore published shares.." menu option


On Wed, 5 Sep 2007 17:16:16 -0700, "Mimi Yin"
<mimi <at> osafoundation.org> said:
> Hi Aparna,
>
> When you fill out your IMAP account info in your mail client. All your
> IMAP folders and messages get synced automatically.
>
> You can think of Chandler Hub accounts in the same way. When you set
> up a Chandler Hub account, we can automatically kick off re-setting up
> all the collections you've published to Chandler Hub in Chandler
> Desktop.
>
> We could pop-up the dialog that lets you choose what collections you
> want to sync to Chandler Desktop, but I'm not even sure that's
> necessary.
>
> Mimi
>
Hi, Apologies for my not engaging earlier in this thread. After a bit of
time with the new "Automatically Restored Published Shares" feature, I
have some feedback. It's only somewhat nice that it's automatic, and
it's a little too automatic from my perspective. To review, the current
implementation begins to restore ones published shares immediately after
one clicks the OK button to close the Accounts dialog (after having
entered username and password info for a Chandler Hub account). There is
no warning that this is what will happen, and no option to cancel the
operation. Given the process intensity of the restore, Chandler becomes
very sluggish if responsive at all. This could be alarming or confusing
at best for users. Clues that a sync is occurring include (on Windows
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mimi Yin | 5 Nov 2007 19:43
Favicon

Re: "restore published shares.." menu option

Hi Andre,

I think this is a good enhancement request. Here's a rough proposal.

1. Ask if the user wants to restore shares right now.
2. Give user option to select which shares to restore, or restore all  
shares.

===
Sync Account
-----
You have 4 collections in your Chandler Hub account. Which of them  
would you like to sync?

[ ] Sync all collections
     [ ] Collection - 1
     [ ] Collection - 2
     [ ] Collection - 3
     [ ] Collection - 4

[Never Sync]		[Sync Later] [Sync Now]
-----

The question remains...if the user selects [Sync Later] when do we  
prompt them again? Upon next start-up?

I assume this option would only pop-up the first time the user adds a  
sharing account *and* when/if new collections appear in their sharing  
account.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mimi Yin | 5 Nov 2007 19:47
Favicon

Re: Why no Note view?

Hi Andre and Reid,

When do you find yourselves wanting to see only Notes? Is it when  
you're searching for a particular note? Or do you have a 'Note-mode'  
you work in?

Mimi

On Oct 23, 2007, at 5:05 PM, Andre Mueninghoff wrote:

> You are correct, to my understanding. I must say this did not  
> become an
> issue for me until lately now that I've accumulated a couple dozen
> notes. I find that in the table view I am unable to distinguish  
> between
> Notes and Events. There is not Event or Note type icon in the table
> view. Tasks are clearly visible. The date column doesn't help
> particularly since the creation date or an alarm can appear there for
> Notes as well as Events. I recall 0.6AlphaSomethingOrOther having  
> three
> separate columns that clearly indicated how an item was stamped. The
> downside being the amount of screen real estate required using that
> method. Nonetheless, I now miss that.
>
> Andre
>
> Reid Ellis wrote:
>> I find myself wanting to see only "Notes", but there seems to be no
>> facility for this. Am I wrong?
>>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mimi Yin | 5 Nov 2007 19:58
Favicon

Re: Should dashboard display order change immediately after edits?

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? I think the idea is  
that most of the time, users are sorted by Triage, so this isn't as  
much of an issue.

> 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?

> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mimi Yin | 5 Nov 2007 20:00
Favicon

Re: [cosmo] Too Many Dashboard Items!

Seems like this problem will solve itself once we implement auto- 
triaging of events to DONE.

 From other users on the design/users list however, it doesn't sound  
like this is the common case.

On Nov 1, 2007, at 4:41 PM, Bobby Rullo wrote:

> There is a bug (https://bugzilla.osafoundation.org/show_bug.cgi? 
> id=10759) which says Cosmo UI takes too long to load.
>
> The reason it takes too long to load is because there are lots and  
> lots of NOW items, and we always return all NOW items in the  
> dashboard query.
>
> The reason there are lots and lots of NOW items is because people  
> don't triage their items.
>
> Those are the facts. What is less certain is WHY people don't  
> triage their items - I suspect it's for a number of reasons such as:
>
> 	a) They don't use triaging
> 	b) It takes too long to triage each item manually
>
> Esther was the impetus for filing this bug - she went to view the  
> Mitch8 calendar and it had 38 pages of NOW items. She and Mitch  
> don't use the triaging bits of Chandler right now, so she never  
> triages stuff to DONE. (For clues to _why_ she doesn't use triaging  
> see http://lists.osafoundation.org/pipermail/chandler-users/2007- 
> August/000437.html and the rest of the thread. Esther wants finer-
(Continue reading)

Permalink | Reply | 501 comments |

Gmane