This post starts out realistic, and ends up bombastic, just so you know. Don’t confuse the bombast with the 10 minute tweak. Ha!
I was thinking that it would be nice if there were some visual indication that the current document had snapshots. Perhaps a small decal in the corner of its icon; a counter in the General section of the Meta-Data Inspector; perhaps even a Snapshots section below General? Whether functional or decorative, some indicator that the document represents the “head” of another stack of documents behind it, like Aperture does when a set of images has been stacked together, and then collapsed in the browser.
And (Scrivener 2.0) of course, that whole aperture model would be neat in itself! The ability to have document stacks that you could collapse in the binder and treat as one. Snapshots would automatically be attached there, and supporting documents could be dragged inside of it. It is like Bundles for the Binder.
I’m not sure about this one… You can see you have no snapshots if the “Show Snapshots” menu is greyed out, after all. I certainly don’t like the idea of having a snapshots section in the inspector. I think an icon decal may be distracting, too.
On the other hand, if you want to bang a concept together in Photoshop, I’ll certainly take a look.
All the best,
Keith
P.S. I am steadfastly ignoring 2.0 “Dream List” stuff.
Right, that is precisely the problem for me, it is not visible. It requires menu operation to gather information about something, which is unorthodox. Menus are for enactment, not information retrieval. I agree, it should not be distracting, this is minor information. Something as simple as:
Steps 11 and 16 have snapshots, the rest do not. The same curl could be applied to a document group. As for folder type groups, given their intended usage it might not be necessary to display any differences.
I do quite like this, and I may well try it, but there is more than just a conceptual problem here: to check whether a file has snapshots, Scrivener checks the disk to see if one physically exists. This might be too time-consuming when checking multiple documents for the binder every time the binder is displayed. So: maybe.
Tested and it seems to be fine. So, it’s implemented for beta 3, but if it does transpire that it causes problems (ie. if it does turn out to slow things down), it could get removed.
Groovy. Is am guessing that the way you have it set up, setting the icon specifically to something is not possible. The Binder polls everything and assigns icons dynamically?
To be honest, it is certainly something that Scrivener could handle - but it is just the management of this sort of thing that would be a conceptual issue that I don’t want to consider this side of, say, 1.5.
