In the Due list, when you change the due date of an item, the currently selected item follows that item to its new...
In the Due list, when you change the due date of an item, the currently selected item follows that item to its new position, eg. if there's an item due today, and you change it to a week away, the selected line shifts to the 'next week' section of the Due list.
I find this awkward as I'm invariably processing the items in a given section --ideally 'Today', but more often 'Overdue' ;(
The current behaviour forces me to move the selection back to where it was. I think the natural behaviour is to position the selection on the item subsequent to the item that just had its due date changed.
I find this awkward as I'm invariably processing the items in a given section --ideally 'Today', but more often 'Overdue' ;(
The current behaviour forces me to move the selection back to where it was. I think the natural behaviour is to position the selection on the item subsequent to the item that just had its due date changed.
Hello Crispin Bennett,
ReplyDeleteThanks for the comment. We tried to implement a clear feedback on the user action, i.e. it is clear what has happened with the list item after changing its due.
Your pattern corresponds to an expert user, who understands what's going on and want to speedup the process of changing due. A keyboard shortcut like "Home" may help return selection to the top of the page.
A more complete solution may be to support a multiple selection for changing the due, https://checkvist.uservoice.com/forums/2121-general/suggestions/19687723-multiple-selection-support-on-due-page-to-change-d (there are no votes yet, because I posted it only after recent changes on Due page).
Thanks,
Hi Kirill,
ReplyDeleteThanks. As always, there's a careful rationale for why you've done things the way you have, but I think it's not quite correct in this case (or at least unsuited to my way of working with the Due list).
I don't want to duke this out with you repetitively here, so I'll just offer my counter-rationale in case you're willing to rethink this during some future iteration:
I don't think my pattern corresponds so much to that of an expert user, but rather to a keyboard-centric user. Checkvist rightly prides (and advertises) itself as being keyboard-centric, and I find this particular interaction breaks with this paradigm:
(1) This behaviour frequently makes me lose my place when processing items one-by-one in my Due list, which is otherwise predictable and fast
(2) it offers no good (keyboard-centric) way to find my way back. A 'Home' jump would not mitigate this much as there's no guarantee the item I was working on was at the top of the list. Multiple-selection also would be of limited use, as I may not be performing the same action (or even changing to the same date) on items as I go down the list.
The current approach adds a further annoyance: as the Due list doesn't support hoisting, when I'm processing Overdue and Today items, I usually have the other sections collapsed for the sake of focus. Moving an edited item into one of those sections forces them open. So I collapse the section which I didn't want open at all, and then find my way back.
There are tradeoffs of course, but I think making things easier for the person who can't read the 'Due date was updated' message at the top of the screen, but more difficult for someone using Checkvist in a keyboard-centric way, may be the wrong one. In an ideal world where everything was easy, you might show the item with the changed date animate downwards, leaving the selection in place. But I think the 'Due date was updated' makes it pretty clear what's going on.
Cheers
Hello Crispin Bennett, thanks a lot for describing your concerns, they are really reasonable. The problem is we need to provide clear reasonable feedback when task due is changed, both with 'dd' shortcut or with task text editing via smart syntax. Some animation could be a solution, but it should be done nicely, and it is not easy to achieve.
ReplyDeleteWe'll think about it, probably we should carry some additional research to find a good solution.
Thanks a lot!
About finding the way back, I enjoy "Back", "Forward", and "Last edit location" in IDEA. Maybe going back to the recently selected tasks would be an option.
ReplyDeleteRalf Hauber Back/Forward are already too deeply engrained in the browser usage model to be hijacked for a different use. "Last edit location" might work.
ReplyDeleteBut it would be better to deal with the fundamental issue rather than layering on workarounds. Checkvist is 'keyboard centric' (the first highlighted point on its home page!). What this means is that convenience of driving Checkvist from the keyboard is weighted more highly than other interface design considerations when tradeoffs must be made. In this case they slipped up: the needs of users who can't read and/or understand the "Due date was updated" toast at the top of the screen was weighted above the needs of keyboard users.
I definitely wouldn't use the Browser's back/forward. Just mentioned the concept. Other examples: Acrobat (Alt+Left, Alt+Right), or think of e-readers where you jump to a footnote or referenced page and can go back to the reading location. You can also start flipping pages and go back safely (I think Kindle introduced a name for this).
ReplyDeleteI can understand your point, but wouldn't say Checkvist's choice is wrong per se.
Consider these:
On iPhone, when you change the date of an event in day view of Apple's calendar, you get a small view of the new date (to check the context) and have to press "back to original date" to continue. A different calendar that I am using a lot takes you to the new date right away.
The design metaphor is from the physical world: When you move something to a different location, you have to go back to the original location.
Another thought: Bookmarks would also be something that I'd love to have in Checkvist.
Thanks, Ralf Hauber. Good idea with "go to last edit location". Filed as checkvist.uservoice.com - Add a shortcut to go to last edit location (like in IntelliJ-based IDEs) -.
ReplyDeleteBookmarks may work as well, but it is a more complex concept. Personally, I seldom use them in IDEA, though always use 'go to last edit location'.
The question is about shortcut and discoverability, as always :). Something like ''ge"?
Ralf Hauber Fair point on the browser vs app-specific 'back/forward'. Actually I think both a navigation history and return to last edit location would be useful additions, they're just not optimal solutions to this particular issue.
ReplyDeleteI agree Checkvist's choice on this issue isn't 'wrong per se'. UI design is always about tradeoffs. My claim is that it's wrong for Checkvist, given its stated values (with keyboard-centricity at the top).
Anyway I am at grave risk of becoming very boring on the topic so I'll leave it there ;)
Crispin Bennett In fact, I was thinking to introduce 'go to last edit location' as a way to go to the edited due task after changing due. I.e. the message could read "Due date has changed, use [] shortcut to go to the edited item" or something like this. And the selection would remain on the place where it was.
ReplyDeleteThinking into this direction :)
Thanks a lot for your feedback!