UPDATE: "Untitled Document"

mi
michpen
Posts: 216
Joined: Sun Feb 04, 2007 11:33 pm
Location: Brooklyn, NY

Thu Oct 24, 2013 12:08 pm Post

It appears that the most recent update has inserted greyed-out "Untitled Document" labels to empty files and folders. I find this unfortunate as I had been using empty files, and the previously clear visual space around them, as a way of temporarily (visually) isolating groups of files. The new labels just clutters things up in a distressing way.

Besides the visual clues on the file and folder icons - indicating empty files and folders - are entirely self-evident and perfectly adequate.

Is there a way to turn off this feature? Might this be made into a preference, so that I can turn it off?

Thanks.

User avatar
AmberV
Posts: 23801
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Thu Oct 24, 2013 10:15 pm Post

There is no way to turn that off, however you could use something other than emptiness to help separate things. What I've always done, when I need to separate groups of files that shouldn't be sorted into containers, is to insert an empty item with "————" for the name. I do this often enough to have made a document template for it, and a custom icon.

Image
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

mi
michpen1
Posts: 23
Joined: Thu Jan 12, 2012 1:51 am
Platform: Mac

Fri Oct 25, 2013 2:35 pm Post

Yes, that can be done, but it is a long ways from the visual clarity and Zen simplicity of:

Snap 1.pdf
(15.81 KiB) Downloaded 89 times


And this compared to Scrivener’s most recent version change:

Snap 2.pdf
(18.14 KiB) Downloaded 76 times


I humbly submit that this new visual change to Scrivener is poor interface design. This is a writing program after all, clutter matters, it makes things less clear and useful. Perhaps I fail to grasp the problem that “Untitled Document” is trying to solve. Once again, I believe it is redundant information, and the existing icons contain all necessary navigational information quite clearly — identifying themselves as file or folder, and indicating whether each contains content.

At the very least, please, please, please make this a preference option.

User avatar
KB
Site Admin
Posts: 20718
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Fri Oct 25, 2013 2:54 pm Post

And I counter that it is quite the opposite of poor design, but preparation for changes to come. It will not be possible to have empty areas in titles in future versions of Scrivener, as changes are coming that will make titling much more flexible for most users. The "Untitled Document" placeholder is to make the current version of Scrivener more compatible with versions to come, so I'm afraid this will not be changing back and it will not be made a preference.

However, if you really want empty spaces, there is an easy solution: just enter a single space character for the title. This will prevent the "Untitled Document" placeholder from appearing, and it will also be future-proof.

All the best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

Cl
ClintonKeith
Posts: 12
Joined: Wed Jun 11, 2008 5:20 pm

Tue Nov 19, 2013 10:42 pm Post

As a customer, I agree with mitchpen1. There should be an option to disable this. I have a series of tables that must be on separate pages. Even using a blank space adds an additional title line at the top of the page, which I have to manually delete after a compile to get my tables to fit.

Good UX design (which I teach) is about an intuitive interface that does what you think it should. When I leave a title blank it should be blank. Forcing me to accept "Untitled Document" as a title or to hack in an empty space cannot be the best design decision. It worked better before.
Clint
Author "Agile Game Development with Scrum"

User avatar
AmberV
Posts: 23801
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Wed Nov 20, 2013 3:07 am Post

It strikes me that you might be erasing titles for the wrong reason (or making new sections in the first place for an artificial purpose that isn’t to your favour). If your compile settings are such that the documents containing these tables are not actually book sections, then you should be using the Compile As-Is flag in the Inspector so that they do not follow the formatting rules and have a title applied in the first place. Then you can name your table documents pragmatically, rather than according to some remote external constriction, making your search results better, your binder less of a guessing game and your post-compile processing less of a bother[1]. If you want to talk about UX strategy, that is what the Scrivener outline is all about: liberating you the creative author from the output/programmatic construct—it’s what sets Scrivener apart from stylesheet based outliners such as Word. If you’re having to kludge the outline mechanics to force the compiler to do something, that’s another problem entirely, but in my experience there aren’t too many of those problems left in Scrivener. It’s a pretty robust package for separating what the author needs from what machines and printers need.

Another approach, for when As-Is is not appropriate, is nesting. In some projects I will cut off title generation at a certain level in the Formatting pane. I may export down to “sub-section”, but any documents below what would be that level are effectively invisible to the reader. I can then file components of documents within the visible sections of the book, leaving me with a more useful and granular outline than the official table of contents could ever address.

Finally, and perhaps most to the point, you may consider that if all you need is a page break for the sake of formatting tables that the Edit/Insert/Page Break command is available for just such cases. Why bloat your outline to keep tables from cutting across sheets of paper? Now, if you want each table in its own section so that it can be linked to, referenced from other documents, searched for by keyword or label and so forth—then go for it using one of the other techniques I mentioned. But if all you are doing is paper shuffling, don’t mess up your outline over that.

But if for some reason you absolutely must have a blank chunk of space in your Binder (and everywhere else), Keith already explained a way of doing so.

Notes:

  1. Though, if you are really dead-set on this workflow, I would consider leaving some standard title in so that you can do a global search and replace for that generic “REMOVE ME” (or whatever) title, rather than laboriously going through your compiled document and deleting empty lines between tables!
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
KB
Site Admin
Posts: 20718
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Wed Nov 20, 2013 10:42 am Post

Exactly. There is no good reason to have documents without titles in the binder - the entire approach of Scrivener is that the documents have a title and that there aren't horrible big gaps there. This decision will make more sense in the future with other changes that are to come, but for now it's enough to note that it will not change, that there are very good reasons for the change, and that if you are using empty titles in the binder then you are probably taking the wrong approach. Not that Scrivener generally tries to dictate the "right" approach in most areas, but it *does* expect there to be some content in the binder. Again, this will make more sense in the future, but for now, the current version is future-proofed against changes that are to come. Placeholder text has a long and noble history on the Mac and is certainly not contrary to good UX design, even if it is not what a particular user wants.
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

mi
michpen
Posts: 216
Joined: Sun Feb 04, 2007 11:33 pm
Location: Brooklyn, NY

Wed Nov 20, 2013 1:04 pm Post

Well... not wanting to belabor the point, particularly since it is not going to change...

...the entire approach of Scrivener is that the documents have a title and that there aren't horrible big gaps there.


When Scrivener discourages a visual approach of using clean space between some documents it is dictating a "right" approach -- limiting a writer's preferences, and assuming how their brain works best during the squirrelly business of composing works. I find clear visual space between documents in the binder (an outline of ideas) a valuable aid. I find the labeling of this creative preference as a "wrong approach" frankly judgmental, counterproductive, and surprising in a wonderful program like Scrivener which was designed (as I understand it) to give writers flexibility.

This all makes me a little nervous about the coming changes in Scrivener that you keep alluding to. I certainly hope they do not change the current work flow, the visual presentation of the binder, and the binder/editor relationship.

$.02

User avatar
KB
Site Admin
Posts: 20718
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Wed Nov 20, 2013 1:32 pm Post

When Scrivener discourages a visual approach of using clean space between some documents it is dictating a "right" approach -- limiting a writer's preferences, and assuming how their brain works best during the squirrelly business of composing works. I find clear visual space between documents in the binder (an outline of ideas) a valuable aid.


And I've already told you how to achieve just that if it's really what you want to do (a space for the title).

I find the labeling of this creative preference as a "wrong approach" frankly judgmental, counterproductive, and surprising in a wonderful program like Scrivener which was designed (as I understand it) to give writers flexibility.


It is meant as neither judgemental or counterproductive - the upcoming changes will allow for more flexibility, not less, but the payoff is that users who want blank space will just have to enter a space in the title, which I do not think is unreasonable, and it's easy enough to set up a document template for such documents if you use them a lot. My comment on the "wrong approach" was specifically aimed at the idea of leaving a title blank because you do not want the title to appear in Compile. That *is* generally the wrong approach. You can still achieve exactly what you want to achieve, and the upcoming changes will make Scrivener more flexible for more users, so I don't really see that there is any cause for complaint when everything is taken into consideration. But ultimately, whenever there are changes, there will always be some users who don't like them, and we can't hope to please everyone, unfortunately.

This all makes me a little nervous about the coming changes in Scrivener that you keep alluding to. I certainly hope they do not change the current work flow, the visual presentation of the binder, and the binder/editor relationship.


They do not. For the vast majority of users, they will represent a distinct improvement.
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

mi
michpen
Posts: 216
Joined: Sun Feb 04, 2007 11:33 pm
Location: Brooklyn, NY

Wed Nov 20, 2013 1:39 pm Post

They do not. For the vast majority of users, they will represent a distinct improvement.


Great, good luck on the revisions. Look forward to taking them for a spin.

mi
michpen1
Posts: 23
Joined: Thu Jan 12, 2012 1:51 am
Platform: Mac

Thu Dec 05, 2013 12:05 pm Post

However, if you really want empty spaces, there is an easy solution: just enter a single space character for the title. This will prevent the "Untitled Document" placeholder from appearing, and it will also be future-proof.


The problem with this solution is that every time I close and reopen a project the unwanted "Untitled Document" placeholder reappears, even though I'd replaced it with an empty space. In my usage, this could run up to a hundred empty documents used for visual spacing that are lost. Any chance of changing this behavior (retaining the empty space in these documents)? Please.

User avatar
KB
Site Admin
Posts: 20718
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Thu Dec 05, 2013 3:37 pm Post

Argh. This is a limitation of Apple's XML classes - if an XML value contains only whitespace, it gets read as blank. That's annoying. Let me ponder on this.
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

User avatar
Jaysen
Posts: 6170
Joined: Mon Dec 17, 2007 4:00 am
Platform: Mac + Windows
Location: East-Be-Jesus-Nowhere SC, USA

Thu Dec 05, 2013 3:43 pm Post

That makes no sense. Whitespace characters are valid and should be preservable. Bah!

What about string replacing whitespace only values with non-standard characters on save then restoring to whitespace on load? It's a hack but it might work...
Jaysen

I have a wife and 2 kids that I can only attribute to a wiggle, a giggle, and the realization that she was out of my league so I might as well be happy with her as a friend. 26 years marriage later, I can't imagine life without her. -Me 10/7/09

Image

User avatar
Jangari
Posts: 127
Joined: Mon Jul 23, 2012 5:03 am
Platform: Mac
Location: Melbourne

Thu Dec 05, 2013 9:16 pm Post

Surely if it's just a visual requirement, for the ease of separating chunks of documents, then wouldn't an underscore or two do the trick? Or a pipe? Or any other character?

User avatar
AmberV
Posts: 23801
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Ourense, Galiza
Contact:

Thu Dec 05, 2013 9:35 pm Post

Once you start inserting Unicode characters into your binder, the possibilities are endless!

Image
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles