Number of unique screens in Scrivener for Mac?

Does anyone know of the number of unique screen boxes there are in the Scrivener Mac version, or any version for that matter ?

As an example, I count 4 unique screen boxes in the following Scrivener screen image:

Without performing any sort of count, it would not surprise me if the number was in the high hundreds.

I would think the underlying code has a way of keeping track of the number of unique screen boxes, but of course I don’t have (or want to have) access to the code, just a count of the number.

Thanks for reading,
scrive
:thinking:

Re the Number of unique screens in Scrivener:

My reason for asking is to find out the scope of an issue that I have wrestled with over these last few years: Is there a native, built-in, method (not a separate app) within Scrivener to know what the names are for the hundreds of screens and screen objects in Scrivener, such as the 4 screen objects displayed in my original posting.

Often when communicating a specific issue on this platform and elsewhere, (absent rummaging through the hefty, 904 pages of the well-written documentation) I am at a loss how to refer to the hundreds of screen objects, not to mention the thousands of other screen objects (text fields, checkboxes, popups, etc.), that exist in Scrivener.

I would expect that there are unique identifiers within the underlying Scrivener code that identifies each and every unique object that appears on a Scrivener screen. One possible solution would be to have a lookup table operating in the back-ground within Scrivener that would translate the unique source code identifier to the English (or other appropriate language) name for each unique object, and to make that English (or other appropriate language) name available via to the user.

It would be forever helpful if there existed a way, perhaps via a keystroke sequence within Scrivener, or some other approach, to natively (not via a separate app) reveal the linguistic name (or other unique linguistic identifier) of a particular object within Scrivener.

For those who have worked with Scrivener for the decade-and-a-half or so since it’s inception, who know every nick-and-cranny of the application and the names for every screen object, this request may come as a surprise.

For those of us who more recently have struggled with the immense power and flexibility that Scrivener provides, and who come to work with Scrivener with a plethora of learning skills, types, and methodologies (or deficits thereof) the simple task to identify a Scrivener object can be a mysterious undertaking.

What do I call … ? How do I refer to … ?

Scrivener is an ecosystem, and for any ecosystem there needs to be a lexicon of terms and objects, as well as a native, straightforward way to search and link those lexicographic terms and objects to what we see each day we work with Scrivener.

Thanks for reading,
scrive
:thinking:

You can learn the parts of the interface by starting the Interactive Tutorial project, which you can start from the Help menu. The beginning of the tutorial guides you through the names of the various parts of the interface. Even if you don’t go any further, that’s worth the (minimal) effort so that you can ask for help with the right vocabulary.

Note that these are the same in Scrivener for Windows.

  1. The Binder
  2. The Editor
    3 & 4) The Inspector

Those are the basic windows for every base project. You can turn off/hide both the Binder and Inspector, change the Editor (go from single to multi-document (Scrivenings), corkboard, outliner), change what you see in the Inspector, but those are the three windows where things start from.

I understand your question, but I don’t think the information you’re looking for would help. The reason is that a lot of the interface elements are coded as instances of generic MacOS objects. Knowing, say, that something is implemented via the NSTableView class doesn’t really help anyone who isn’t a developer know what you’re talking about.

As @Rdale said, the best introduction to Scrivener’s terminology is the Interactive Tutorial project. When asking for help, posting screenshots is good, too.

Hi kewms,

Thank you for your feedback and for pointing out my lack of specificity in my original posting. Instead, I should have included the term instances of in my posting, e.g.:

“My reason for asking is to find out the scope of an issue that I have wrestled with over these last few years: Is there a native , built-in, method (not a separate app) within Scrivener to know what the names are for the hundreds of screens and instances of screen objects in Scrivener, such as the 4 instances of screen objects displayed in my original posting.”

etcetera, etcetera, … throughout my post …

I realize that the current state of the particular instance of the underlying code used to write the current versions, e.g. instances of, Scrivener may not be able to accommodate the linguistics for each and every instance of each screen object.

This is not just a Scrivener issue. The ‘state of the art’ of the underlying code used to develop Scrivener may simply not be up to the task of providing the coder with efficient and powerful tools to linguistically identify for the user each and every instance of each screen object.

More broadly, it is not just a software issue. The human interface is key to the long term development in almost every industry, from automobiles to airlines to space travel. Leveling the learning curve is a challenge for us all.

Technically speaking, a driver only needs to obtain a drivers license to be able to drive any automobile. A passenger only needs to purchase a ticket to fly on any commercial passenger airline from any airport to fly anywhere in the world.

Imagine if a person needed to read through a multi-hundred page user manual before purchasing and driving a car. Imagine if all airline passengers needed to read through a multi-hundred page user manual before flying out on vacation or on a business trip.

As applications such as Scrivener continue to improve in power and complexity, bringing new users into the fold will become increasingly crucial to help reduce to ratio of the:

  1. time and effort required to learn a particular technology, to
  2. utilizing the productive capacity that the technology affords the user.

Each minute I spend trying to learn the terminology of a particular technology in order to learn how to use the technology increases that ratio, decreasing the overall efficiency of the effort to utilize the technology as a tool.

My post was an attempt to address my particular instance of using Scrivener as a writing tool to possibly reduce the effort of others to utilize such an amazing writing tool.

Thank you again for your feedback.
scrive
:thinking:

I think you will find that there is going to be a loss of efficiency if Scrivener were able to do what you request, not an increase, because there are a great many individual control instances on a typical screen – enough so that the signal-to-noise ratio skews unfavorably toward “noise.”

That multi-hundred page manual would increase dramatically in size.

That’s not even counting the fact that what a given UI element is called in code often has nothing to do with what it’s call in human language – and that’s before we get into the topic of localization.

I think there is a reason why programs don’t do this.

1 Like

Hi devinganger,

Thank you for your comments.

There are certainly a number of reasons ‘why programs don’t do this’, but I’m a bit short on time at the moment and I’d like to collect and organize my thoughts before I respond.

Thanks again,
scrive

Technically speaking, a user only needs to open a project and start writing to make use of Scrivener. But just as some vehicles (trucks, motorcycles) may require additional training beyond a basic automobile license, and just as actually finding your gate is more difficult in some airports than in others, using the more complex features of Scrivener may require additional effort.

But I’m still not understanding how your proposal helps reduce that effort. Knowing what the Compile Format Editor is called doesn’t seem to have much to do with the ability to use it effectively.

The interactive tutorial project is not a multi-hundred page manual. It’s a project with very brief explanations in each document that explain the topic at hand. In the binder, the list of document titles indented under the “Main Interface” document tells you what the names of the primary interface elements are. The Inspector document further has the names of the views within that element.

Fewer than 100 words just looking at those titles will tell you more, in less time, than responding to this post, and will provide you with the words to discuss Scrivener’s writing interface.

Note that each of those documents contains at most a few hundred words, some with illustrative screen shots, and they’re all housed within the Scrivener interface, so you can immediately see what they’re describing.

image

2 Likes

Thank you devinganger, kewms, and Rdale for your thoughts and comments:

After thinking about my query in light of your comments, I had a bit of a ‘light bulb’ moment. In the interest of time and limited bandwidth I’ve copied my salient thoughts from another posting Is there a way to rename a character or paragraph Style? - #13 by scrive below:

I’d like to apologize for consuming limited bandwidth perhaps less efficiently that I might have by answering my own question. On the way, however, I’ve learned a new appreciation for the code-linguistic interface and how efficient coding may affect the linguistic efficiency of the user interface.

Thanks for reading,
scrive
:thinking:

"Unfortunately, after some research and reflection, I’ve come to understand that the underlying structure of Object-Oriented-Programming (OOP) and the enormous coding benefits available from OOP may run counter to creating and maintaining a linguistic name for each and every screen object that is rendered and displayed to the user.

If this is in fact the case, it shifts the burden for effective user documentation toward improved search and indexing capabilities such as proximity word search, but also so much more, so that if I search for ‘rename Styles’, I’ll instead be referred to ‘redefine Styles’ to learn how to rename my Styles.

I have no idea what tools are available to create that type of search engine, except perhaps some sort of hybrid, dynamic thesaurus or synonym-index search that we all are familiar with, e.g. Google?"

Heh. Yes, this is the case for every non-trivial program – and is made worse because there are usually a mixture of visible and non-visible UI elements that combine to make up the UI, making UI elements that look like a single entity actually be a layer or more of compound elements. Some of those elements are provided by the OS or toolkit(s) used and (usually) are compound elements themselves. Which of those elements are necessary to provide a linguistic name for and which are not? It adds a whole new layer to UI design which requires yet more developer and tester interaction and time, as opposed to the trends that seem to be allowing more and more use of wizards and other automation to build, validate, and ensure consistent UIs.

I could not have said it better … it was a light-bulb moment for me when I realized what was going on … but the challenge remains as to how to address the linguistic needs for the user to communicate with others … I don’t know if I’ll ever have another light-bulb moment to address that one …

Thank you for so eloquently putting into words the challenge that OOP presents for the developer.

Glad to hear the perspective of others,
scrive
:thinking: