Hi, I have enough attributes in one prototype for the list to scroll down beyond the size of the key attributes display pane, as per screenshot, where you can see the slider present to indicate a couple of hidden KAs.
The only ways I can see to avoid this are to
remove some of the attributes;
move the less important ones to the bottom, off-screen, as it were;
reduce the font size of the attributes.
Having 10 or so KAs doesn’t seem excessive, but I can’t find anything in the forums or FAQ that addresses this (I see horizontal issues, where the values are truncated). Does anyone have any suggestions?
Many thanks, again, in advance, and happy holidays to those of you celebrating any or all of them.
Currently, the maximum number of rows that are visible without scrolling is 15. This is not a completely arbitrary number:
The ideal limit for a scannable list is 7 +/- 2
This is twice as large, because Tinderbox users are likely to be better than average at scanning lists
We don’t want the table to grow without bound, as one might need to open a document on a small-screen laptop and that document ought to be usable.
.
How many key attributes are enough? I’m open to suggestions.
The number of attributes in the KA list is not limited, but once the number exceeds 15 items, the list has a scroll-bar as only 15 items are shown at once. this ensures some space remains for the note’s text ($Text). There is no user control that alters the number of items visibly shown in the list to be greater than 15. Altering the KA font size does not affect this.
A workaround: when doing qualitative work I tend to use a lot of user attributes and little/not text in the initial stages. If I my working set is >15 items, I generally use a some mechanism to swap out the list ($KeyAttributes) via a prototype. I either switch prototype for the note or have a series of stamps for the different lists and stamp the one I want onto the prototype to swap out the KA list for all notes using that prototype.
That said, I think little harm will be done if we try a more liberal policy for large key attribute tables — perhaps allowing them to grow to up to half the height of the text pane.
Thanks, @mwra and @eastgate, as ever. I think allowing them to grow would be wise, given bigger screen sizes these days even on laptops. My screen resolution isn’t that high, but it still leaves plenty of text pane real estate (the image needs enlarging to view the full pane height):
**
**
I tend to add more KAs than I might eventually use, just to try out various approaches (and as I’m still learning, to add a new KA attribute to move existing fields to from a less suitable one). I think having them all visible, or at least the possibility of having them all visible, makes for a better process.
