[historydoll]

I'm a new user, mostly very happy with OOP3. But I'm trying to create a style that I can apply to specific lines with a hot button, and I simply can't figure out how to do it. I've read the documentation, and I've read all the posts in this thread. Derek, I understand that it seems simple to you, but I agree with the users who say that the explanatory posts have only made it increasingly clear how very complex and difficult the styling process is.

I am a user of MS Word, and although I'm not fond of very many things about it, the styling process is very simple. You build on styles which already exist, and in the process you are given opportunities to change any or all features of the original style. You give your new style a name, and it is then available to you, from a dropdown box or by keyboard command, at any time. (And it is applied only where you want it to be applied, and not elsewhere.)

I have tried any number of ways to create a new style; it's in the list in the styles drawer, but it doesn't seem to actually have any effect on anything. I can live without this, but it seems like there ought to be a comprehensible way to do it.

[WrongSizeGlass]

HistoryDoll,
Try this:
* Select your text
* Right-click and choose 'Clear Style'
* Hit the hot button for the Style you desire (or command-drag the Style from the Styles section of the Utility Drawer)

Just make sure your style has a font & color selected (even if they show up in the Inspector, 'Set' them anyway to make sure they are applied), as well as the other attributes that you desire. And don't choose the attributes from the Styles popup menu in the Ruler - always use the Inspectors.


James B

[DerekM]

Originally Posted by FredH

One thing I'd like to see with the next major release is an overhaul in the documentation. Give some more examples of how to do different things with styles, not to mention all the other capabilities of the app.

We are working on a more comprehensive manual for 4.0. We are aware our documentation is thin, it's a lot of work for one guy :) We hope to provide much of what people are requesting.

[DerekM]

I was writing a response.. but I don't feel it's progressing anywhere. So, if you have any more questions or specific suggestions please send them to omnioutliner@omnigroup.com and I will work with you individually.

Thanks!


--
Derek M.
Support Ninja
The Omni Group

[Stormchild]

As a long time and everyday user of OO, and extensive user of the styles system, I thought I'd add my comments on this thread, and OO's style system in general. I apologize for the length; I know the software very well, and as such I'm in a position to be thorough about unravelling some of the problems and frustrations people are having with it.

I generally find OO3's style system to be very useful and powerful. I initially found some aspects of it a little confusing, but in general I feel that it makes sense and works well, once you understand it. With the exception of a couple bugs or quirks, the essential problem here is the age-old challenge of adding advanced features to software while trying to keep it simple enough for casual users to understand and use the system.

One helpful feature (that maybe not everyone is aware of) is the "Styles View" toolbar button (which can also be activated with View > Show Styles View). This is the same style view that appears when you select a style "level" in the utility drawer, but perhaps a more convenient way to access it. If you ever have a problem with styles appearing where you don't want them (or vice versa), just click this button and you'll get a comprehensive view of all the styles in your document. IMO, this view makes it very clear that the style system is hierarchical, and easy to find where a particular row is inheriting its styles from.

Coming from my background as a web developer, I find the styles system works a lot like CSS, in which styles are applied hierarchically and fall back (or cascade) from the most specific use (a particular selection of text) to the most general (the entire document). In fact, I really wish -- when working on webpages -- that I could just click a toolbar button and instantly see my entire CSS hierarchy, and quickly identify where an element is getting its style rules from in the case that something looks wrong!

But one aspect of OO's styles system that is confusing is the process of removing an inherited style from a particular level. Let's say you set all level 2 rows to "bold", but for one particular set of level 2 rows (all the ones under a specific level 1 heading), you want to remove that. If you enable Styles View, select the "children of row ..." icon for that heading, and look at the Style inspector, you'll see the bold rule under "All level 2 rows". If you click the 'x' to remove that rule, you're removing it from all level 2 rows, not just the ones you've selected, and that's where the confusion lies. One would intuitively expect this action to apply only to the selected objects, because that attribute wasn't shown in the UI until those objects were selected.

It was stated earlier in this thread that there is no way to remove bold or italic from a particular level or selection of rows because there isn't a "not bold" or "not italic" attribute. Actually that isn't true -- rules *do* exist that can set a property to default, but the confusion lies in how to apply such a rule.

Try this example. Create a document with a few rows, then create some children (level 2 rows) under each of those. Make sure these all have text in them. Open the drawer and select "All level 2 rows", and hit command-B to make them all bold. Now let's say we want the children of one of those top-level headings to *not* be bold. As I mentioned before, selecting the icon for "children of row ..." of the desired top-level row, then clicking the 'x' to remove bold will now remove it from the whole document, so we can't do it that way. Instead, hit command-B again (or alternately, choose "Regular" in the Weight menu, in the Appearance inspector > Font). Now you can see in the Style inspector that these rows still show the "bold" setting under "All level 2 rows" -- as it should be -- and now have an additional rule under "children of row ..." which states that font weight is regular. Since the latter rule is applied to a more specific element, it overrides the default for all level 2 rows, exactly the way it should (and the same way that CSS works).

The essential problem seems to be that you have to *apply an additional rule* in a situation where what you really want is to remove a rule. A user may try to "clear style" for a particular selection of rows, and be frustrated that any of its inherited style attributes are not removed. Perhaps this confusion may stem from the fact that "default" styles are not shown in the styles inspector (even though all the defaults (normal font weight, no background, etc.) are in fact styles), which implies that we should be able to "go back to the defaults" by removing -- not overriding -- styles.

Since the average user has problems understanding the subtle details of how a hierarchical style system works, one "solution" would be to just do away with the hierarchy, and have all styles applied explicitly to everything in the same way. But obviously this would be a great disservice to the many people who do understand and benefit greatly from such a system, and also defeats one of the main purposes of using an outliner instead of a word processor. So that one's out.

In order to keep the system, but make it less frustrating to casual users, some features could be tweaked or added to make things behave more the way people expect them to.

For example, since "clear style" does not remove any inherited styles (which I don't want it to), perhaps there could be a similar command called "apply default styles" that not only removes any styles from the selected objects, but also applies whatever styles are necessary to override inherited styles and return them to the defaults. But honestly, the idea of adding another command for the sake of making styles easier to understand seems like the opposite of what we want to do here. So I think this one is out too.

When I first started using OO3, it didn't take me long to disable the "Automatic Level Styles" feature, and turn it off in the default template as well. I never fully understood how it works, and I would suggest that it should perhaps be off by default, or even eliminated. If any of you *do* use this feature, can you explain a bit about why you like it?

Having said that, there is another, similar behavior that annoys me on a fairly regular basis. When I apply a style to a particular row, then continue editing, the rows I create after that will "inherit" the same styles (not actually inherit, but copy), which I then have to manually remove. This not only applies to a particular row, but any rules for its descendants as well. If I create a row that has rules for one or more descendent levels, the next row I create on the same level as that first one will have the same rules for itself and its descendants. I don't want this, but there is no way to stop this from happening. Essentially what I'm asking for, is for rows to *only* have their inherited styles unless I *explicitly* change the style of a selection of text or rows -- AND -- I don't want those rules to be carried over into rows I create after that point. There may be some situations in which people do want this behavior; all I want is the ability to turn it off (as in, toggle the behavior on/off at will, not completely disable it).

Anyway, that's enough out of me for the moment. I hope my long-winded feedback was helpful or at least interesting.

[WrongSizeGlass]

Coming from my background as a web developer, I find the styles system works a lot like CSS, in which styles are applied hierarchically and fall back (or cascade) from the most specific use (a particular selection of text) to the most general (the entire document).

To be honest, I really don't want to use OOP to work on web pages, or deal with OOP documents as if they were web pages.

It was stated earlier in this thread that there is no way to remove bold or italic from a particular level or selection of rows because there isn't a "not bold" or "not italic" attribute

What I said was I can't make a Style "not bold", not that I can't 'remove' bold. I can manually remove bold, but I cannot set a predefined Style to be "not bold".

Let's say you set all level 2 rows to "bold", but for one particular set of level 2 rows (all the ones under a specific level 1 heading), you want to remove that.

There is a huge misconception that we all want to have all text within a section or group of sections related by level, etc, to have the same Style. When I make notes within a document to be changed/added/reasearched/etc at a later date, I don't want it to be the same Style as the rest of that section ... or even that subsection of that section (and so on). I want to be able to make the note stand out, and hopefully convey what has to be done with it based in part on its style attributes.

The essential problem seems to be that you have to *apply an additional rule* in a situation where what you really want is to remove a rule.

That is part of the problem. Adding extra steps to undo things you don't want to do in the first place is making it more complicated.

Since the average user has problems understanding the subtle details of how a hierarchical style system works

As a professional programmer for 24 years, I am in no way, shape or form an 'average user'. The implication that those of us who "don't find the Style implementation intuitive" just don't understand it is ridiculous. Yes, it is hierarchical, for most - but not all - style attributes. And yes, it applies those style attributes hierarchically most of the time. And yes, you can get the end result you want by removing attributes you don't want instead of being able to define a style with the attributes that you do want. So yes, I understand it.

Perhaps the bugs and inconsistent implementation of some style related features make it frustrating. Or maybe it's the hierarchical nature of it, or it's flexibility and complexity. Maybe it's all of those things. But no matter what the reason, it is still frustrating trying to get the simple things done. And for the "average user who doesn't understand the subtle details", well, that's what we are trying to do - to get the simple things done.


James B

[akatsuki]

Automatic styles are, in fact, constantly evolving styles that ensure there is no consistency in your document.

The little style boxes that appear when you invoke styles mode don't mean anything and do not indicate anything. The confusion is created because the application of a document style to a particular row level is mixed together with a specific instance or variance from that style. This makes it confusing, and you can never figure out where you are applying a style... I think this is true for many of the people on this thread, but styles get in the way of finishing the document and so most of us don't use them until the very end, because it just creates headaches otherwise.

I have attached an image of a bug and what is wrong with "automatic" styles.

[Stormchild]

Originally Posted by WrongSizeGlass

To be honest, I really don't want to use OOP to work on web pages, or deal with OOP documents as if they were web pages.

I had a feeling that comment might be misunderstood. I didn't mean I want to use OO for working on web pages (I can't really imagine why one would use it for that; I use BBEdit for web stuff). I meant it would be nice to have a similar feature -- in whatever program -- that gives me an overview of the CSS styles in use on a particular web page. The closest thing we've got are the DOM inspectors in Firefox (and now Webkit) -- which are great, but aren't specifically made for viewing the style hierarchy and as such, don't give the same comprehensive view of styles as OO's Styles View. My point being, it's a nice feature, and helpful in resolving any confusion about how styles are being applied in a particular situation.

Originally Posted by WrongSizeGlass

What I said was I can't make a Style "not bold", not that I can't 'remove' bold. I can manually remove bold, but I cannot set a predefined Style to be "not bold".

Understood. It seems you thought I was replying to your comments directly, when I was actually just speaking generally. I actually agree with most of your points, and if we continue to discuss it I'm sure we can identify what actually needs to be done.

I recognize that you can't specify a Named Style as being "not bold" (or other defaults) -- you can only specify a default style for an object that has an inherited value for that attribute. As has already been pointed out, if you Command-drag a style instead of just dragging it, it will also remove any styles not specified in that style. But that doesn't really solve the whole problem, because it isn't really removing styles (it's overriding them), and will only remove unwanted styles on the particular row(s) it's been dragged to. As I see it, this leaves us with two main problems:

1. A style cannot be set to only include the attributes specified therein. If one wanted a particular Named Style to always behave that way, one would always have to Command-drag that style. This also means that the style cannot be applied with a keyboard shortcut, because it's not possible to hold Command while pressing the shortcut and get the same effect.

2. Since the method for "removing" unwanted style attributes is to override whichever unwanted ones happen to be present in the target rows at the time a style is applied, if the inherited attributes change, you will again have styles you don't want, and have to Command-drag the Named Styles to the affected rows again. This defeats at least part of the purpose of using Named Styles.

The ability to explicitly set a style attribute to its default value (in any context) would be helpful. However, I have another idea that may prove more useful in most situations: a new rule called "don't inherit styles", which could be applied to Named Styles, or even to individual rows or text. In general, I feel this is a better way to solve the problem of only wanting the attributes given in a particular style.

However, I still think we should be able to explicity set a style attribute to its default value; this would allow us to override a particular inherited rule without eliminating all the others.

One other thing that might help us here (and in other situations) would be the ability to apply rules to "all descendants" of any given row. Currently the only way to apply rules to descendants is to do so for each descendent-level manually. By applying my proposed "don't inherit styles" rule to "all descendants" of a particular row, you could opt that entire section of the outline out of the global style rules.

Originally Posted by WrongSizeGlass

There is a huge misconception that we all want to have all text within a section or group of sections related by level, etc, to have the same Style.

Not on my part there isn't. I frequently apply styles to individual rows or even selections of text within those. Perhaps you misunderstood me, or perhaps I'm misunderstanding you.

Originally Posted by WrongSizeGlass

That is part of the problem. Adding extra steps to undo things you don't want to do in the first place is making it more complicated.

This is true, but even though we currently don't have all the tools we need to control inheritance properly (making it difficult to create exceptions), the concept of inheritance is the foundation of the styles system, and what makes it so powerful.

I believe we need to carefully evaluate ways to give advanced users control over the inheritance, and at the same time, ways to allow users who don't want to deal with all the complexity to avoid these problems in the first place.

In regard to the latter point, I think the main thing that needs to be done is to turn off "Automatic Level Styles" by default (and from what I understand, that's Omni's plan). Since I don't use that feature, I won't say that it should be removed entirely; some people might like the way it works. But if it's off by default, then at least new users will be shielded from the potential problems and confusion of style inheritance. For those who don't need or want the complexity, or aren't even aware of the whole style system, styles would always be applied explicitly to selections of text or rows, and would always be easy to remove or change.

Originally Posted by WrongSizeGlass

As a professional programmer for 24 years, I am in no way, shape or form an 'average user'. The implication that those of us who "don't find the Style implementation intuitive" just don't understand it is ridiculous.

I didn't mean to suggest that anyone who finds the style system unintuitive or confusing is somehow at fault. The complexity of the system makes it confusing for average users (because the default "Automatic Level Styles" thrusts everyone into it) and occasionally frustrating even for those who understand how it works (because it lacks proper means to control inheritance).

It's my hope that the changes I've suggested will help with both of these problems. Since I tend to be overly thorough (i.e. "babble on and on") about things, I'll summarize my suggestions here:

1. "Automatic Level Styles" should be off by default.

2. An additional style rule -- "don't inherit styles" -- should be available, and able to be applied to any row, level, or Named Style.

3. We should also be able to explicitly set a style attribute to its default value in any context (not just when it happens to inherit a different value for that attribute).

4. It should be possible to apply style rules to "all descendants" of a particular row (not just to individual descendant-levels).


P.S. I have one other idea as well. It introduces additional complexity and is not immediately relevant to the main topic here, but would nonetheless be useful. A Named Style could also include rules for its descendants, which would allow you to set the styles for a row and all of its descendants in a single step. If you want to have particular subsections of a document styled a certain way that differs from the global styles, this would be the answer. This idea makes sense in my head, but might end up opening a can of worms of additional problems, so it'll require some thought and discussion.

[Stormchild]

Originally Posted by akatsuki

The little style boxes that appear when you invoke styles mode don't mean anything and do not indicate anything.

Incorrect.

Those style boxes DO mean something and DO indicate something. They don't tell you whether any styles have been inherited, but they certainly do tell you whether any styles have been applied to a particular row or its descendants.

[DerekM]

Originally Posted by akatsuki

Automatic styles are, in fact, constantly evolving styles that ensure there is no consistency in your document.

I can't say I agree with this. What is your perception of what automatic styles is doing? This is the reference to the 'Automatic Level Styles' correct?

Originally Posted by akatsuki

The little style boxes that appear when you invoke styles mode don't mean anything and do not indicate anything. The confusion is created because the application of a document style to a particular row level is mixed together with a specific instance or variance from that style. This makes it confusing, and you can never figure out where you are applying a style... I think this is true for many of the people on this thread, but styles get in the way of finishing the document and so most of us don't use them until the very end, because it just creates headaches otherwise.

The style view is actually very powerful and useful. I'm personally just discovering how handy it is. Although I did discover an obvious bug looking at it. Currently if you have Automatic Level Styles on, you can end up with invisible chits, pretty much making the style view only half as useful. One feature that is best accessed through the style view is applying styles to decent levels. If you hover the cursor over one of the chits, it will tell you what that box controls.