Please don’t get defensive about this, I’m just passing on my experience as a new user (and a retired software designer).

I’ve got the hang of it now, but the #1 problem that made S “hard to learn” for me was the formatting dialog of the compile option. It makes sense to you, but this is what a new user thinks when he/she sees this dialog.

Why are there three lines with the same thing in them (a new user doesn’t notice the difference in the small icons)?

What is this “Level” stuff you speak of? I’ve never heard of “Levels.”

What is the “1+” business?

I’ve got three lines that look the same, and why would I check Title in one but not another… What?

What is this synopsis and notes stuff?

What does a checkmark mean? That I have a title for… What?

In other words, to a newbie, you’ve got a lot of new, unexplained stuff, and no information on what a check mark signifies. Perhaps something that is less concise, but more meaningful.


First impressions aside, have you gone through the relevant section (§22.8, pg. 205–7) in the user manual which explains this section of the compiler? We do realise that there is a lot of stuff here, it’s a powerful multi-level (think of levels in terms of outlining, where indented items are on a different “level” than their parents) system that can adapt to nearly any outlining method, so a certain degree of opacity is to be expected. We do have some ideas for making this a bit more intuitive in the future. For example we are testing a system on the Mac right now where when you click on these rows it will highlight all matching examples in the Binder behind the compile window. So you can click on a “Level 1+” text file and see all of the text files in the Draft section highlighted, or a Level 2+ folder and see only those folders indented past the top level of the outline selected. Like I say it’s an experiment, and it might be changed in the future, but we do want to address a more intuitive mapping between what you see in the formatting rules and what will happen on output.

Don’t change it! It surprised me when I first saw it, but it’s a really good feature. :smiley:

Well, any changes we make will be to make it better—the basic idea is staying. One of the problems with the system right now is that it highlights the Binder, but the project window focus is disabled while Compile is open. Hence, if you had scrolled off to the Research section you won’t see any highlights, and you can’t scroll back up without leaving compile. So that’s one problem with the current system. :slight_smile:

I don’t think that’s entirely fair on yourselves… It automatically scrolls your binder to show you active documents. You are right, though, that you can’t then scroll though to check if a particular document is of a certain level.

So as a feature that shows you the kind of documents that are at certain levels, but if you have a particularly long and complicated manuscript structure you might not be able to verify whether specific docs are captured by a specific rule.

True, I phrased that incorrectly, it’s the ability to scroll to precise areas of the binder you are interested in that suffers—my main point was that the idea in general to highlight directly in the outline structure is something that will stick. We’ve had good feedback on that, and I’ve seen a drop in questions about “levels” in the Mac side of the forum since it was implemented.

[size=150]Down with modal dialog windows!![/size] :open_mouth:

Ha, well in some cases they are a necessary evil to avoid a huge job that doesn’t really provide all that much advantage in the end. With Compile specifically, it has to pull a lot of information from the project binder for the Contents pane. Thus to make it non-modal, you’d have to constantly send messages to it whenever anything changed in the project window. It would be a whole lot of programming, and potential for error, and waste of computer processing time, just to make it so you can leave the Compile window open, or scroll the binder a bit while using it. Another example is Project Statistics. It has to build a static representation (it actually does a quick compile in the background) of the text to get an accurate count, and it can take a lot of processing time to do that. So if the project were left unlocked, it would have to be processing over and over, each time you hit a key. It would make the software unusable, thus rendering non-modality pointless. We do try to avoid them when we can though. :slight_smile: