I’m just starting to experiment with cross tabs, and very useful they are too. I just have two basic questions: I think I know the answers (“no”), but it’s worth checking… (They’re both minor points at best.)
As far as I can see, the tab is always called “Crosstab”. Can I change that?
The order of the columns seems to be hardcoded to alphabetic (perfectly understandably). Can I change that?
Use case:
I’ve kept my book list in Tinderbox for ten years, with about 900 entries, each of which has some obvious attributes (BookType; Rating; Status (Read, Unread etc); BookTags and so on). I have a series of agents which classify the books by year read and so on.
I thought that Crosstabs would remove the need for these agents, simplify the tbx file and they do this very nicely. (Am I right in thinking that cross tabs require less computation power?)
However, I don’t want to have to create each crosstab every time, but have a persistent window with the various crosstab configurations as tabs. It would be nice cosmetically and for convenience to name each tab (BookType by Year, Rating All etc), but I can’t find a way to do it.
Secondly, the rating attribute (H, M, L) displays in alphabetical order, which isn’t what I want for this attribute, for purely cosmetic reasons. Of course I can refactor the attribute (1-H, 2-M etc), but I wondered if there was another way.
The Crosstabs and Attribute Browser views are atypical in that they are query based-view rather than a different visualisation of (part of) the documents canonical outline structure. The AB view shows the scoping container (in not ‘whole’ document’), Crosstabs does not.
I think what is really being asked for is a way to have saved Crosstabs (and/or AB configurations) saved. This stops one having +++tabs in a document. Though only the front (selected) tab is evaluated/updated the other tabs can be clutter. It would be useful to be able to configure one of these views and store the configuration—with a name—and recall those setting to (re-)configure the current Crosstabs (or AB view). If such were possible, I’d suggest the saved name of the configuration be shown after the view-type label.
I don’t think that question has been asked before, so the answer is not known. What is the case is that Crosstabs (and AB view) can be re-configured. Actually, with care agents can be too but I do I’d agree that having a lot of agents is not an ideal scenario, especially if you only look at their alias list occasionally rather than the agents having some more ongoing structural purpose.
The believe column order is fixed. It is a lexical sort, i.e. “Bear, Zebra, aardvark” rather than “aardvark, Bear, Zebra” as a human would. The odd manner of a computer lexical sort is a quirk of computer history as it works off the number code representing the letter and these codes run A-Z, then a-z. Thus ‘A’ and 'a" are non contiguous, giving this sub-optimal default sort.
Just to be more precise: in the specific case I’ve outlined, I’d keep three or four crosstabs in a permanent window, because if I wanted to consult one, I’d also consult the others. It’s effectively a dashboard in this use, not a query form, so being able to rename the tabs is useful, whether the ‘saved configuration’ feature is implemented or not.
But of course I think saved configurations are a really good idea in themselves!
It does seem logical that a single crosstab of say BookType by Year would be less intensive as a permanent dashboard than the 10 x X individual agents needed. (I know there are routes to minimise the work: I turn off previous years, nest the agents and so on). I’d be interested to hear from Mark B whether there’s a definitive answer on this…
I’m also not surprised that the sort order is fixed — it’s a niche request and there are workarounds I can adopt. BTW, I’ve never understood the point of Lexical sort for users (of course, it used to be easier to sort on ASCII code, but that problem was solved decades ago…). I’ve never quite got round to working out which tags to the cli ls command make it sort in proper AlphaNumeric order…
That perfectly fine - only the current one of these—if any—is evaluated, i.e. the others aren’t a background overhead.
Indeed, but you do configure them, unlike other views, before you get meaningful data. I wan’t thing of a query in terms as literal as $AgentQuery.
As each tab (re-)render on taking focus, for bigger files/scope it might be as quick to load a different configuration in the current tab as to wait for a new tab to render. Either way you can only view one tab at a time. You might be able to be able to show differently configured Crosstab views in 2 different windows but on closing the second window you might delete the tabs only therein by mistake. So the ‘saving’ part of the configuration (in my suggestion above) is a side point, I think the app needs to be able to persist this data about a tab regardless - so it make sense to expose it to the user.
As regards the tab label, it means you need a means to set a (short!) user-defined string that is used as the tab-label. If such were possible, it would also make sense to use it to populate a default name for saved configurations
Yes, I’m happy with all this it if could be made to work (but of course I appreciate that there is always too much to do for the developers and this is at best a refinement and not essential…)
You can keep several different crosstabs views open in in separate tabs, so your window of cross tabs should be available now.
Renaming tabs is under consideration. It’s fairly straightforward.
Crosstabs column sequence is alphabetic for string, set and list attributes, and numeric for numeric attributes and dates. This could be modified. It’s less straightforward.
I don’t think crosstabs are computationally simpler than the corresponding set of agents. I think this is unlikely to matter in practice, but if it does turn out to matter, let me know!
Whether or not case matters to sorting is a delicate problem. Indeed, simply alphabetizing names can be a conundrum, even in English: where do you file the writers Emily St. John Mandel and G. E. M. de Ste. Croix? How do you handle Saint Sebastian, Severus, SATO Noriko, Suharto, and Se7en? Things get more complex in Chinese, in which the same spelling of the same word may have different sequences, and in Arabic, in which different letter forms may be equivalent. For that matter, how do you sort the University of Århus and the city of Aarhus? More concretely, you might want to distinguish Trout, Mike and not have him filed between trout, brook and trout, rainbow. Lexical sorting does have some advantages. See Falsehoods Programmers Believe About Names - With Examples - Shine Solutions Group
The ‘might’ is the key point there. It’s probably more likely in the context of the views discussed here (Crosstabs and AB view) which are more for review than input, that the user wants to see quickly that trout was miss-capitalised (or vice versa). If Trout and trout are not sorted together, indeed no visible on screen together, data is hard to check and you might as well fall back on agents. That is clumsy though as either you need to keep resetting the query or go into non-starter territory if thinking in regex, e.g. all $Fish starting with a lowercase letter etc.
I wonder, politely, if the complex and edge-case-ridden sorting of people’s names is the best example of the general needs of sort. In saying that, I recall I don’t think I’ve come across anyone (especially those without a coding background) who thinks a case-sensitive (lexical) sort is an intuitive default. I’m not suggesting I’ve done a scientific survey on this. Rather, i’m recalling endless less to new users why the default sort give the “wrong” [sic] result; I think that is revealing of the general users differing view, as they have no close knowledge of sort algorithms and efficiencies. A quick canter round a range of tools on my Mac that offer search show that case-sensitive is a non-default option. Yes, search is not sort but the two are close in that a very good reason for sorting is for review, as in the example above.
I’m not trying to make an argument on a zero-sum basis (as one form has to be the default). The synopsis of my post is that no strong evidence is shown for case-sensitive default being a more useful default over case-insensitive. As name sorting needs more tuning than just case-sensitivity to work well, it renders it moot as a deciding use case.
As I said in the original post, having several tabs in a separate window, each with its own crosstab is what I’m doing now—the downside is that all the tabs say ‘Crosstab’, which is why I asked about renaming them! It’s good to know this feature may become available.
I’ll keep an eye out on how the cross tabs perform compared to the agents and let you know if I see any problems/obvious points of interest.
Column order would be nice (presumably as with the Attribute Browser, by drag and drop), but I understand it’s harder to achieve.
Lexical sorting does have its uses, of course — it’s just irritating that it’s the Unix default for files…
Aside, in AB view these are user-selected columns. In Crosstabs they are—at least for lists and String-based—the discrete values of the chosen attribute so aren’t known until the target attribute is tested (within scope) and discrete values parsed out. In the case of numbers they are cut up into buckets. I doubt we’d want a column order 1–5, 11–15, 6–10, so this might affect string-based attribute columns only only.
@brookter, admittedly out of idle interest, what kind of column value sort is needed? I’m guessing it’s ad hoc. IOW, The column value in column ‘6’ are more interesting (bigger/whatever) than those in columns 1–5 so we’ll move that column to column position #1 - or is it something different?
No, it’s as you suggest: adhoc arrangement of values will be fine.
It’s mainly that some attributes should be sorted other than by their alphabetic precedence:H-M-L, Strongly Disagree-Disagree-Don’t Care-Agree-Agree Strongly-Dunno etc. Of course you can precede these with numbers to make the alphabetic sort work, but manual arrangement of columns would be fine in this context.
This raises an interesting wider use case, especially where an attribute uses a ‘fixed vocabulary’, be it via suggested values or otherwise.
The above suggests it might be useful to have a way to set the attributes sort order—as used in Crosstabs, AB view and other places—manually as a list. this might most easily be done by honouring the typed order of items in the attribute’s suggested values. that would limit the feature to those attributes with suggested values (and indeed, be limited to those values). But it might offer a simple implementation route.
That would be fine: for the sort of values we’re talking about (with a non-alphabetic sort), you’re almost certain to know what the preferred order is in advance, I would think.
