Keep track of sort order history #275
Comments
|
I don't think an implicit, hidden sort order history is a good idea. In the relevant threads, what I've said we might do is left-to-right sorting, so that you could drag columns into the order you want them sorted. If you click a given column, it would sort by that column and then the column to its immediate right, and so on. |
|
Could you elaborate a bit on why it is not a good idea? I think it's quite intuitive, but I'm sure I'm overlooking some pitfall. |
|
I just don't think it's intuitive at all. (Are you aware of any software that does this? That's not a dealbreaker, but it certainly changes the context in which to predict users' expectations.) When you click on a column in a sortable list in any program, the sort changes to just that column. The program doesn't remember your history of clicks and sort by whatever you were previously sorting by with no indication. Even if we could display some sort of secondary sort indicator—which I'm not sure of, since the tree view is pretty limited—I don't think this is something a user would ever expect to happen, and people could easily end up with sorts they didn't want just by clicking around normally. Doing secondary sort by column order is pretty non-standard too, but there's at least some precedent in terms of how people are used to sorting spreadsheets/tables, and it'd be pretty clear from looking at it what was happening. |
|
The downside to column order sorting is that you really want the title all the way on the left, so if you do want to sort by Year then Title you don't really have a good solution. One other possibility mentioned in the threads was a modifier-click on a column for a secondary sort, which I believe some programs do (though I've never seen it personally). I'd consider that if we could actually add an indicator to the secondary header. |
It's surprisingly hard to find this, but, I'm also not aware of a lot of software where there are many columns to sort by. It's an obscure example (although it is marginally related to Zotero) but Mp3tag (http://www.mp3tag.de/en/) implements stable sorting. I'll try to dig up some more examples.
I'm not sure that there is much need for a secondary sort indicator. You don't have to think of this as secondary sort, but rather as stable sorting. That is, for equivalent items, the sort order does not change from what you had before. I'm honestly surprised I cannot find more software that implements this, because it seems so intuitive to me. Perhaps this is because it requires the extra effort and I think 99% of software has no use for such granular sorting.
I like this idea too and I think it would work very well even alongside the stable sorting that I was talking about. I don't have strong a strong opinion about the secondary sort indicator. Would this be limited to two sort keys though? I think it would have to be. Otherwise I can see some implementation difficulties. Either way, I think some sort of more predictable secondary sorting is needed. The whole reason I brought this up is because of the current sorting behavior with Creators. Sorting by Creator defaults to (reverse) Date Modified as the secondary sort (I'm sure this is not intentional, but rather comes from the order in the database). This is already somewhat awkward, but it's made worse if you're trying to edit items while they're sorted by creator. Particularly true with standalone notes, which don't have Creators, so they are all sorted to the same place. When editing, a note, it jumps to the bottom of the list when saved (i.e. when losing focus). So if you're editing a note, and go to click on another note, you end up misclicking, because the notes got rearranged. Obviously this can be fixed by setting some sort of different secondary sort, but (A) it becomes a pain to figure out proper secondary sorts for all columns and (B) I don't think there's any need to remove the flexibility of letting the user choose the secondary (tertiary, etc.) sort. |
|
On Ubuntu there are a few more examples (though I haven't looked very hard). Nautilus does stable sorting as well as System Monitor :-) Maybe Finder on Mac OS also does this. |
We already have stable sorting, though. The order is just hard-coded. I was asking for examples for the thing you were describing (some hidden sort order following the click history), not for stable sorting.
No, it doesn't. If you sort by Creator, Date is the secondary sort. If you sort by something else, it's that, then Creator, then Date. Date Modified comes last (though if it's reverse that might be a bug). Standalone notes just don't have any other fields to sort by, so they're a special case. We could perhaps use itemID instead of Date Modified for the last sort (for notes or for everything) to avoid moving them as they're edited. |
|
Or we could just incorporate the title into the sort order, which would avoid this problem for notes in most situations when you're sorting by Creator. |
That's not the sorting stability I've always thought of. I.e. from Wikipedia (http://en.wikipedia.org/wiki/Sorting_algorithm#Stability)
And going off of that definition, I think keeping track of sorting history is essentially implementing stable sorting.
Oops, sorry, I was testing with items that did not have dates. Edit: I think what you were describing is closer to deterministic sorting rather than stable sorting (http://www.unicode.org/notes/tn9/) Edit 2:
I guess it depends what is considered reverse. I should have said ascending, which in most cases is not reverse, but, IMO, for Date Modified most recent first is the more common sorting. |
OK—rereading your comment above I see the comparison you were making, though I don't think the traditional definition is totally relevant here. The SpiderMonkey sort algorithm is stable, and the tree doesn't change ordering on its own with successive sorts. We just happen to use Date Modified as one of the sort fields, so when people edit items the actual sort data changes. Given your examples that seems somewhat ill-advised, though, so I've switched that to Date Added, and added Title before it. Try the latest build. |
That works better now with just modifying notes. There's still some awkward behavior, but it's mostly just nitpicking now. E.g. for creators, empty creators sort last, but for titles, empty title sort first. So when items are sorted by creator and you already have some notes in the list, the new note is added to the middle of the list. I.e. above all other notes (since they don't have creator) but below other items with creators. Maybe empty creators should sort before A. Though I feel like this was an intentional design decision.
That's great. I looked more closely at the sorting code and to get the behavior that I'm talking about is quite easy. I replaced itemTreeView.js#L1419-1438 with The only problem is single item sorting. Since there is no sorting history, there's no way to know where exactly the item should go if the primary sort keys are equal (and, say, the secondary sort key value changed). My solution would be to leave the item in place, though that's probably not ideal based on what the user might expect. In light of this, your arguments above make more sense to me now. I'll think about this some more. |
Otherwise use full date, even if Date column is hidden Addresses #275
When sorting by Title, empty titles get sorted to the top of the items list for visibility, but when sorting by another column and using the title as a secondary/tertiary sort, empty titles should get sorted last so that new empty items go to the end of the list rather than the middle. This is a little weird, and the alternative would be to just always sort empty titles last even when sorting by Title, but this preserves the current behavior for Title sorting. (Before f0f6772 titles weren't used for secondary sorting at all, so there's no precedent for title-sorting behavior when sorting by another column.) Addresses #275
- Each column in the middle pane can now have its own persistent secondary sort column, configurable from a new submenu in the column picker menu (top right of items list). The settings are stored in extensions.zotero.secondarySort.[primaryField]. The submenu title includes the current primary field (e.g., "Secondary Sort (Creator)"), which is pretty weird, and I'm not sure I want to keep it, but it does convey that the setting is specific to the selected column. - The fallback sort fields (firstCreator, date, title, dateAdded) are now configurable via the extensions.zotero.fallbackSort. Setting that pref to an empty string avoids all fallback sorts, which allows reverse-order clicking to set the order, as requested by @aurimasv in #275. - The previous behavior of sorting based on the exact Creator string (rather than the actual creators) can now be restored with the extensions.zotero.sortCreatorAsString pref. (It simply circumvents all the newer code, so it's pretty safe.) This setting should result in faster sorting in large libraries that have many items with the same Creator string. - Some of the lesser fields in the column picker menu are now in the More Columns submenu (which is now alphabetical) - The "Type" column is now the less-ambiguous "Item Type". - This uses a different method to modify the column picker menu that is simultaneously less and more hacky. (It no longer has to duplicate Mozilla code in a custom XBL binding that wouldn't reflect future upstream changes, and instead it bushwhacks its way through various boxObject properties to get to the underlying menupopup.)
I don't think I need to elaborate too much on this, but...
Click to sort by Title, then click to sort by Year. Should display items sorted by Year then Title.
This has been requested before, tough I don't have a link right now.
The text was updated successfully, but these errors were encountered: