Submitted by Pierre_Admin on 2009/08/10 22:51
For text oriented outlines, the current column-click sorting is way too dangerous, as sub-items (i.e. paragraphs) will be sorted.
 
I'm proposing the following solution to equaly handle numeric and text oriented outlines:
  1. If the sort bar is visible, then the behavior is unchanged. Column click sorts items and sub-items
  2. If the sort bar is not visible, then a click on the header selects the column but does not sort . To sort, I've added Sort Ascending and Sort Descending menus on the Column context menu. These will sort TLIs only (hence providing an extra level of protection)
Comments?
 

Comments

Interesting, but it still seems a bit complicated and unintuitive to me as these conventions are not immediately obvious to the user. There are already too many of these invisible or "hard" conventions in IQ. I can already foresee or hear the questions about the sorting and column behavior...
 
here are some more precise comments :
 
1- response to first case : I don't see why someone wouldn't care about "saving" or "preserving"  the "manual" sorting when the sort bar is in use. But maybe am I missing something.
 
2- response to second case : I think this unintuitive and adds useless layers of complexity (see my first comment)
 
 
Note that I previously took the time to make some propositions myself on the exact same important subject (Save and recall arbitrary/manual sorting) but never got any real feed back... (Well, Mark left a little note.)
:(
 

Pierre, thanks for taking up an issue on yesterday's Google discussion. Sorting issues embody the tension in IQ between the outliner, with its imperative of arbitrary arrangement of data blocks, and the SQL engine, which expects clear sorting criteria.

My preferred approach mirrors Armando's: that manual rearrangements of items should probably manifest themselves in a sort field, either explicit or implicit. If the user has dragged paragraphs around to his liking, he might click a button to save a named or enumerated sort. At that point, IQ could fill a sorting field with values that reflect each item's position. If the user drags or creates an item between two others, a sort weight reflecting that position is assigned; and all are recalibrated if groupings get crowded.

Moreover, if each item's sort weight were stored as an array, then IQ could have the ability to restore several previous item sorts.  And the existing sort could be saved to the array field not only at the user's request, but when some other field sort is requested in the interface. So we could go beyond rules and warnings, and have the ability to undo mistakes, or to see, without risk, how a particular arrangement looks or reads.

Since IQ's rules are going to be hard to remember, I think the various clicks and options that effect sorts should display some information in a status zone about the scope of the sort, how many items will be rearranged, whether the rearrangement will be temporary or permanent, and whether it will affect only the active grid, or others as well.

Rgds
Jerome