The more I use Scrivener, the more I like it, but here’s one little thing that bugs me a bit.
The left side is where the Binder, Collections, and Search Results are, and currently, we could customize their colors like so:
But that customization is kind of useless, because as soon as we focus on any of them other than the lowest one in the stack, the color of whichever one we focus on will take over all other ones below it, like this:
Although there are visual cues telling us which tab was chosen, such as the highlighting and the dashes placed before and after the title, they are quite subtle and not very obvious.
My suggestion is something like this:
So, instead changing the colors of all the ones below the tab we select, nothing is changed, except in the content window below, to match the color of the tab we selected, and then the tab selected will have a more prominent visual cue. I did a few possible choices, such as a check-mark, an arrow, a solid circle, or rectangle around the text (there should only be one, next to the title of the selected tab. I only put more on the other tabs to show different possible choices).
The color customziation and the coloring of the tabs below the selected one is meant to be the visual indication–everything matches the color of the selected tab, and if you selected, for instance, the blue “blah blah” collection, you’d see the green and yellow tabs behind it, but blue covering the rest, as though you’d flipped down those front tabs to view the contents of “blah blah”. The fact that the other colors can’t be seen indicates that they’re not the tab in use. I do notice however that there’s another visual indicator meant to be here which isn’t displaying; that is, the titles of the collections should only be grayed out when they’re “hidden” behind the selected tab, whereas currently all titles are appearing grayed out. So that should help indicate the active tab as well.
Yeah, those visual cues do help, but part of my concern has to do with emotional and ergonomic ones regarding writing, not just merely utilitarian.
For example, I have different storylines involving different character’s lives. These different characters have distinctly different personalities, and I assign collections of their individual storylines specific colors to reflect their personalities. A passionate and brooding character might be assigned a dark red, while a innocent a naive character might get assigned a pale grey, and so on.
Currently, when we pick a tab higher up, it changes all the colors of the tabs below it–that’s problem number one. It’s not an intuitive way to design GUI. I’ve worked as art director and designed GUI’s in the past (for video games, film/animation)–this is my area of expertise, so I’m extra sensitive about these issues.
The next issue is that while colors associated with characters’ personalities is very effectively emotionally for the writer, it is a problem ergonomically. For example, not all colors work well as background for a large text box–many colors are fatiguing to look at in a large area and for a prolonged period of time, but in small pieces as simple identifiers, they’re fine. So, the current system allows me to choose the ideal color for a character’s personality, but I’m also forced to have look at the large collection window in that color too–that’s not ideal. The collection window should remain the same color–one that you can customize individually to be non-fatiguing for the eyes.
So, my proposal is to allow us to color-code the tabs to match the emotional association we have for the characters, storylines, topics…etc of our writings, and those color codings has to remain constant instead of getting changed whenever we pick a higher positioned tab (this is especially important if we end up with lots of different collections–finding them by color-coding in conjunction with titles is far more intuitive and faster than titles alone). Whichever tab we pick will be highlighted in a way that’s visually very obivious, but not distracting or fatiguing to the eyes (such as the examples I mocked up), but the main text window’s color will not change–it will remain whatever ergonomic color you have customized for non-fatiguing, prolonged viewing.
I very much agree with Lunatique. Once the collections have all turned to color of the one I am currently looking at, it is more difficult for me to figure out how to select one of my other story lines since they are now all the same color, and I associate the story lines by color, not by some text string (the collection name).
I’ll throw out there another bug in the present incarnation, which is that when you hover over the tabs that below the selected one (and thus “behind” that tab and its color), you should see the color of the tab you’re hovering over; currently that’s not working. So identifying your collections by their color will be doable once this is corrected.
Yes, when you hover over them, the tab should show you the colour of the tab underneath.
jravan - I’m well aware of that “principle” but I’m afraid I disagree in this instance (we certainly haven’t had much surprise from other users before this thread - and collections have been in the Mac version for over a year). If the colours stayed the same it would be very difficult to see what was selected, and Lunatique’s mock-up is far more confusing to me. We thought long and hard about this when designing it on the Mac version, and the current system is intended to sort-of reflect a rolodex. Except, with a rolodex, the selected tab would come to the front - that’s no good, though, because you don’t want the order to change. So instead, it’s visually brought forward by the other tabs being sort of faded out, but hovering over them should show the colour (that’s the main problem at the moment).
Also note that the name of the selected tab is given at the top of the collection in the bar.
It is intended that you pick a collection colour that would work well as a background colour, too - the whole point of the different background colour is that you can see at a glance which collection you are currently using. If you have hidden the collection tabs and close the project and return to it later, if the background colour were the same colour as the binder a number of users would be confused about where the rest of their binder documents have gone. The change in colour is a strong indication that this is something different. Believe me, we answer the support emails.
Anyway, I’m very, very happy with the way collections work, and in over a year of them being out there and in use, this is the first time any users have expressed any issue with them too. So, sorry, but no plans to change this, except for getting Lee to fix the bugs that need addressing of course. Hopefully that will help.
I use a collection for each of the main characters in my story, so I’ve got eight tabs, including the binder. In older versions I could see all those tabs at once, but a recent version imposed a limit of five; I have to scroll the window to see the others. Is that a bug, or is that the intended functionality?
I can drag the bottom of the window, but only to make it show between three and five tabs.
It’s intended, but it’s working currently with some limitations that Lee hopes to be able to get around in a future update. With the old functionality, the collections kept pushing the binder area down with no stopping point, so it could quickly reach the point of becoming unusable because you couldn’t see anything in the collection and there was no way to scroll at all, so if you had so many tabs (or such large fonts for them) that they went off the bottom of the screen, that was it. The new method brings in the scrolling and maintains a minimum height for the binder below the tabs so you’re always able to see the content, but we’d like to revise this so that you have more flexibility dragging the separator between the tabs and the area below, which would then allow you to expand the top so you could see all eight of your tabs at once. This was just too big a change code-wise to be able to implement safely for 1.0, but Lee’s looking into doing it for a 1.x update.
Thanks everyone for the feedback. We have made the following changes to the code that will appear in the next update, due this weekend, that should address most of the issues raised.
The changes include:
Collection titles in the tabs should not all be faded out to grey. Only the titles below the currently selected tab should be greyed out (although still readable).
And even more obviously here in the next screenshot:
There should be a rollover effect when you roll the mouse over collections below the selected tab. Seeing as all tabs below the selected tab take on the colour of the selected tab, rolling over them should show what they would look like where they were to be selected - that is, as long as the mouse is over a tab below the selected one, its title should regain full opacity and the background of that tab should regain its normal colour. Moving the mouse out of the tab returns it to being faded out and taking on the colour of the selected tab.
Yes, I can see how that would have been a problem, especially on smaller screens. Five tabs is a bit of a low upper limit though, especially on screen resolutions like mine (1920x1200), so I’d certainly find it useful if there was a way to increase that. Fingers crossed for that being added in a 1.x update.
Wow! This roll-over effect make collections much more intuitive in 1.0.3 release. Thanks to all those brought up the subject and those already implemented an even better one
A question - when I create a new empty collection and open it, it still retains the previous document view (as it is empty). Is this normal? I was expecting to see an empty corkboard, etc. but the earlier view still remains until I send or create an item in the newly created collection. Also, when I remove documents from the collection sidebar, the view is not updated - the removed document still appears in the view.
And a very very minor non-issue with the collection tabs in the latest 1.0.3 - the colour selection square. With making the collection titles ‘non’ greyed out, these faux-button squares also got ‘non’ greyed out - which means a black square frame (and probably in MS Dİalog font yikes!). Is there a subtler solution to this, like a greyed out square like in the earlier version, or a better one(may be a semi transparent, see-through icon that would indicate this option)?