It is still aggravating to work with styles!

[gryphonent]

OmniOutliner still has an awkward and unintuitive handling, especially when it comes to styles. Reading from feedback on Versiontracker and MacUpdate I’m not the only one complaining about these issues... and they have been present since version 3 came out.

Working with styles in Omni Outliner remains aggravating. Disabling the “Automatic Level Style” doesn’t really help as it seems to be “on” by default for every new document. The way your program handles styles is too complex for users... I think Pages is taking the lead when it comes to simplicity. I’d love to mark “all level 2 rows” then call up the font menu and make changes that are instantly translated onto all level 2 rows. The marker changes to red on the “all level 2 rows button” and I can decide whether to save that change. Keep it simple and stupid.

[JKT]

Umm:

http://homepage.mac.com/jtyzack/.Pictures/screenshots/OOutstyles.jpg

Then:

http://homepage.mac.com/jtyzack/.Pictures/screenshots/OOutstyles2.jpg

Then:

http://homepage.mac.com/jtyzack/.Pictures/screenshots/OOutStyles3.jpg

Also:

http://homepage.mac.com/jtyzack/.Pictures/screenshots/OOut4.jpg

[Agnostus]

OmniOutliner still has an awkward and unintuitive handling, especially when it comes to styles. Reading from feedback on Versiontracker and MacUpdate I’m not the only one complaining about these issues... and they have been present since version 3 came out.

I fully agree, and I think JKT's screenshots rather show how confusing it is, than make a case FOR the style handling (or, JKT, was it your point to demonstrate how awkward it is and I didn't get it? ;) ). Seriously, I really just cannot force myself to get used to the OO style implementation.

[gryphonent]

Hmm... I just thought the same. I think the main problem is —at least to me — that OO is forcing upon the general user an approach that is totally different from the way other apps are handling styles. And I’m not sure if it is for the better.

[bashosfrog]

I may be missing the entire point here, but I pretty much ignore Styles view for mass changes and just use the Utilities panel. ie. Select "All Level 2 Rows" in the lower window (OO clicks into Styles View), then make changes in Inspector = all Level 2 rows changed as expected.

I don't really "get" Styles View either. Not for everyday use. But I haven't needed to use it in order to set up OO documents of stunning style :-)

[JKT]

That is the styles view, just accessed through a different part of the interface:

http://homepage.mac.com/jtyzack/.Pictures/screenshots/OOutstylesdrawer.jpg

Gryphonent - I haven't come across any two apps that do use the same interface for styles... ever. In terms of ease of use (in word processors) Pages (pretty good)>=NeoOffice/OpenOffice.org (good)>>>>>>>>>>>>>MS Office (mind-bogglingly awful). However, OmniOutliner is not a word processor, so it is only natural that it uses yet another (different) interface for styles. IMO, it is still very easy to use and the point of my screenshots was to show that it is very simple to do what you requested - see and change the style of all Level 2 rows.

[jimphelps]

I find the styles process baffling also. I have had to select whole documents and unset everything then rebuild my headings et al because I have become lost in "what is applied where and why does this section look like that!"

[Agnostus]

I find the styles process baffling also. I have had to select whole documents and unset everything then rebuild my headings et al because I have become lost in "what is applied where and why does this section look like that!"

That sounds too familiar to me. Now, I am not an experienced OO user, but I find myself often in the situation where it seems the easiest ways to remove all styles and start all over - which is tedious. Omni might want to try to do something for the more casual users here, or: try to get better introductory documentation, as discussed in a thread in the OmniGraffle forums (I think its called "OmniGraffle the definitive guide")

[ksg]

That sounds too familiar to me. Now, I am not an experienced OO user, but I find myself often in the situation where it seems the easiest ways to remove all styles and start all over - which is tedious. Omni might want to try to do something for the more casual users here, or: try to get better introductory documentation, as discussed in a thread in the OmniGraffle forums (I think its called "OmniGraffle the definitive guide")

I agree that it is far from intuitive. And as for removing all styles and starting over, it's often not possible to do that: my experience is that if an outline originated as a .rtf file, for example, it seems to inherit some fonts and sizes and weights that you have to change one entry at a time. Tedious hardly begins to describe it. Just Selecting All and setting the font doesn't seem to work.

[semi]

I rather like OmniOutliners handling of styles :eek: but what i really miss is a proper introduction to the style features in the pdf-manual!!! Or perhaps an extra styles-manual... I think the problem is not that its bad - but it's bad-documented.
I found a bit of an introduction here: Named Styles in OmniOutliner and TAO (http://atpm.com/11.12/atpo.shtml)

[akatsuki]

That sounds too familiar to me. Now, I am not an experienced OO user, but I find myself often in the situation where it seems the easiest ways to remove all styles and start all over - which is tedious. Omni might want to try to do something for the more casual users here, or: try to get better introductory documentation, as discussed in a thread in the OmniGraffle forums (I think its called "OmniGraffle the definitive guide")

I find styles absolutely impossible to use properly and automatic level styles are beyond just annoying. I generally just try and remember to turn off styling and then style at the end.

The system just doesn't work elegantly and never gives you a clue what the hell is going on. Pages really does have a better system.

Frankly using styles in Omnioutliner makes me want a different product.

[WrongSizeGlass]

I too find OOP's implementation of styles to be painfully unintuitive.

Styles acts like toggle switches - applying a style again removes its attributes (if they have not been changed by another style).

Styles are also cumulative - they do not override any attributes not specifically defined in that style, so you never know what you are going to get when applying one to any text that may already have other style attributes.

Also, choosing a style from the popup menu in the ruler can act differently than choosing a style from the Utility Drawer. That doesn't help the situation.

Styles in OOP are frustrating at best.


James B

[DerekM]

Ok, I'm going to take a stab at this and this hopefully clarify many things and generate ideas and solutions to make the style system better for you. Although remember in general, if you have a feature request, please send it by email, omnioutliner@omnigroup.com or from the Help -> Send Feedback from the OmniOutliner help menu.

[DerekM]

Working with styles in Omni Outliner remains aggravating. Disabling the “Automatic Level Style” doesn’t really help as it seems to be “on” by default for every new document.

You can turn off Automatic Level Style by editing the default template.
OmniOutliner -> Preferences -> General tab -> Edit New Document Template
Turn off Automatic Level Style from the Format menu and save the file.
Now all new documents made from the template will have Automatic Level Style turned off by default.


The way your program handles styles is too complex for users... I think Pages is taking the lead when it comes to simplicity. I’d love to mark “all level 2 rows” then call up the font menu and make changes that are instantly translated onto all level 2 rows. The marker changes to red on the “all level 2 rows button” and I can decide whether to save that change. Keep it simple and stupid.

Here's how you do this, and I think it's pretty straight forward.
http://forums.omnigroup.com/attachment.php?attachmentid=65&stc=1&d=1152911742

[DerekM]

Hmm... I just thought the same. I think the main problem is —at least to me — that OO is forcing upon the general user an approach that is totally different from the way other apps are handling styles. And I’m not sure if it is for the better.

How is it totally different? Aside from a different interface, what exactly is confusing you? It may be that you are experiencing some bugs that we're working.

[DerekM]

I may be missing the entire point here, but I pretty much ignore Styles view for mass changes and just use the Utilities panel. ie. Select "All Level 2 Rows" in the lower window (OO clicks into Styles View), then make changes in Inspector = all Level 2 rows changed as expected.

I don't really "get" Styles View either. Not for everyday use. But I haven't needed to use it in order to set up OO documents of stunning style :-)

Styles View is another way of representing the styles applied to each row. I will agree that it can be confusing, but you can do everything with styles without using it.

[WrongSizeGlass]

Although remember in general, if you have a feature request, please send it by email, omnioutliner@omnigroup.com or from the Help -> Send Feedback from the OmniOutliner help menu.Derek,
I've sent in several requests and comments regarding the Styles to the email address since I purchased OOP v3.0.3 (back in Sept '05).

It's almost maddening when using the Style popup in the Ruler and having it not work the same way as the Inspector (or sometimes not even holding the style attributes). Getting those two to work the same would be a step in the right direction.

If I want a simple style for the text, I type it in TextEdit and then paste it into OOP.


James B

[DerekM]

I agree that it is far from intuitive. And as for removing all styles and starting over, it's often not possible to do that: my experience is that if an outline originated as a .rtf file, for example, it seems to inherit some fonts and sizes and weights that you have to change one entry at a time. Tedious hardly begins to describe it. Just Selecting All and setting the font doesn't seem to work.

So one thing that might not be clear to everyone is that the styles have a hierarchy structure. Explained in the help file under "Style hierarchy". What is likely happening when you import/paste text that has formatting applied to it, is that those styles are brought in as applied on one of the top two levels depending on the format.

The hierarchy:
Text insertion
Whole row
Level groups
Column
Whole document

Styles defined in one level of the hierarchy will overwrite any conflicting styles of the levels below it. So if you had font size 14 applied to the whole document and then applied font size 8 at text insertion, the text would be size 8.

You can see the style attributes and the hierarchy of the selected text in the Style Attributes inspector. Styles at the top of the list overwrite styles below if they conflict.

This is how all other style systems I can think of work in general, you just might not see the hierarchy laid out for you.

What I think confuses people is when you want to overwrite existing styles in groups instead of adding to the current style.

A simple way to erase any styles that you brought in with text is to highlight those rows and then Format -> Clear Style.

It is possible to apply a style and have it complete overwrite all style of the same level and below. You can do that by dragging the style from the style palette and hold down the command button. (You will notice if you don't hold down the command button, a plus sign will appear indicating you are adding that style) This won't however overwrite styles applied above that level, in this case, the text insertion level.

I understand parts of this functionality can prove confusing at first, but it is quite logical to me anyways. What you want to avoid doing is applying styles at the text insertion level if possible as should you decided you want to change them all, it could prove tedious. The style system is powerful if used properly.

[DerekM]

I find styles absolutely impossible to use properly and automatic level styles are beyond just annoying. I generally just try and remember to turn off styling and then style at the end.

Automatic style does cause some odd behavior. It's functionality is being reviewed for 4.0.

What the Automatic level style feature does, is when you individually apply a style to to a whole outliner level, that style will be automatically promoted to the "All level x rows" style. So say you create a new document with 1 row and color the text red. As it currently is, all level 1 rows in the document has red text. So the automatic level style feature promotes the red color to the "All level 1 rows" style. If you made a document with 2 level 1 rows and only colored the text of the first row red, the red style attribute is applied only to the first row.

[DerekM]

Styles acts like toggle switches - applying a style again removes its attributes (if they have not been changed by another style).

Yes, this is true, if you use the hot keys for apply styles, you can apply it and unapply it. Can you give me a situation where this causes a problem?


Styles are also cumulative - they do not override any attributes not specifically defined in that style, so you never know what you are going to get when applying one to any text that may already have other style attributes.

Yes, they are cumulative, but if you pay attention to your style hierachy it behaves exactly as you would expect. You can override attributes by command-dragging the style and applying it that way. How would you like it work?


Also, choosing a style from the popup menu in the ruler can act differently than choosing a style from the Utility Drawer. That doesn't help the situation.

Yes, we are aware the rule styles behave differently. The ruler was made to mimic Apple's that is used in TextEdit which may or may not have been the best idea. But, all the style options from the ruler can be done from the apperance inspector.

[DerekM]

Derek,
I've sent in several requests and comments regarding the Styles to the email address since I purchased OOP v3.0.3 (back in Sept '05).

Thank you for doing that, I was not with Omni at the time so I likely haven't read your specific emails but your requests should be in our system.

It's almost maddening when using the Style popup in the Ruler and having it not work the same way as the Inspector (or sometimes not even holding the style attributes). Getting those two to work the same would be a step in the right direction.

Ok, I found one of your emails, do you still want the ruler styles to work like the command-drag? Or do you want it the same as the rest of the style style? Or are you saying you want everything to behave like the ruler styles?

If I want a simple style for the text, I type it in TextEdit and then paste it into OOP.

Like I mentioned in the other reply, you don't need to use the ruler styles at all. Everything can be done through the Appereance inspector. We are considering putting the same menu that's on the ruler in the Appereance inspector however. Would that help?

[WrongSizeGlass]

Styles in OOP are powerful ... but they don't work like other programs and are a frustrating transition. There is a big difference between "applying a style" and "adding this style to the current style to create a cumulative collection of defined style attributes". Applying one style attribute by hand is one thing, but you'd better know what attributes where set by the previously applied style before you apply another style in OOP or you may not get what you thought ... or want.

Though styles are cumulative, applying one style on top of another style only overrides the style attributes specifically defined by the 2nd style. Applying a style should apply all the attributes of that style.
One example:
* Style A has the weight set to Regular, and other attributes
* Style B has the weight set to Bold, and other attributes
* If style B has been applied to some text, applying Style A will only apply the attributes defined for it - but the result leaves the text Bold
* How can I define "not bold" in Style A?

In order to get what I want, I need to remove Style B - if I know which style or hot key is assigned to that style (or clear all styles) and then apply Style A, OR, open the Utility Drawer and command-drag the style I really want from the bottom (ie. hidden on an iBook screen) onto the text.

Personally, I think using the modifier keys should perform the "style merge" and choosing the style by it self should apply that style (and that style only) to the text. Why? Operations + modifier keys should do "special" things (like merging styles), not the other way around. Especially since command+'hot key' and command+'style from ruler' don't do anything, and they certainly don't do the same thing as command-drag from the Utility Drawer. Ever had slips or mishaps while dragging (command or otherwise) on the track pad of an iBook? I sure have. Ok, I found one of your emails, do you still want the ruler styles to work like the command-drag? Or do you want it the same as the rest of the style style? Or are you saying you want everything to behave like the ruler styles?I would like things to work the same everywhere in the application. No matter how you folks choose to implement styles, it should work the same no matter where in the application I use them.

I should not have to worry that things work differently from different user interface elements of the application. You wouldn't have the Print function work differently if chosen from the File menu rather than the toolbar. But, all the style options from the ruler can be done from the apperance inspector.
...
Like I mentioned in the other reply, you don't need to use the ruler styles at all.True, I don't need to, though sometimes, like when I'm working on my iBook, having an Inspector or the Utility Drawer open takes up valuable screen real estate. If the ruler styles aren't supposed to work, then remove them. If they are there, they should at least work in the same fashion as the other style implementations.

The Ruler and the Inspector can remove different style attributes set by the other. Try selecting some text, choosing Italic from the Inspector and then Bold from the Ruler - and tell me where my Italic went? Yes, this is true, if you use the hot keys for apply styles, you can apply it and unapply it. Can you give me a situation where this causes a problem? I was simply explaining how they worked, though it is not always intuitive in practice if you don't remember in which order you applied multiple styles. It appears that they function as a 'stack', and if you use multiple styles on the text you'd better remember what order you did it in later on. Originally Posted by gryphonent
Hmm... I just thought the same. I think the main problem is —at least to me — that OO is forcing upon the general user an approach that is totally different from the way other apps are handling styles. And I’m not sure if it is for the better.How is it totally different? Aside from a different interface, what exactly is confusing you?Most other applications do not have cumulative styles. If you apply a style, it changes the text to that style, not the previous style + the new style. Since this is not only the default behavior, but the only behavior unless you command-drag from the bottom of the Utility Drawer, it takes extensive planning to define your styles to make sure they change every possible attribute if you ever intend to use multiple styles (and even then not all of them will override the previous style).


James B

[DerekM]

Styles in OOP are powerful ... but they don't work like other programs and are a frustrating transition.
I'll admit, I don't have many other programs to play with their styles right in front of me. However, I think it's more of a POV thing that makes it seem so different. From what I remember of my experience with other programs and styles, they are cumulative in that you apply a style, and then say, oh I want this but BOLD, so you apply BOLD to it and now you have style+BOLD, not just BOLD. Bold IS a style, just a simple one that you generally won't create a custom style just for it. So the difference is when you apply custom or preset groups of styles. But aren't styles nothing more then applying multiple attributes at once? But enough about this.


Though styles are cumulative, applying one style on top of another style only overrides the style attributes specifically defined by the 2nd style. Applying a style should apply all the attributes of that style.
One example:
* Style A has the weight set to Regular, and other attributes
* Style B has the weight set to Bold, and other attributes
* If style B has been applied to some text, applying Style A will only apply the attributes defined for it - but the result leaves the text Bold
* How can I define "not bold" in Style A?


This is a good point. We should see if it's possible to know when you want to specify Regular weight for a style. Are there any other cases like this with different attributes? While I would say command-dragging would be the solution to this, using the style system we have, it's completely valid to want Weight: Regular definable in a style.

Personally, I think using the modifier keys should perform the "style merge" and choosing the style by it self should apply that style (and that style only) to the text. Why? Operations + modifier keys should do "special" things (like merging styles), not the other way around.
My argument against having all style presets working like command-drag is that, what if you want to apply something like the highlight style? I would not want applying highlight to erase the the other styles applied to the text. I would want it to simply add the yellow background fill. Applying a style is no different to me then applying attributes one after another to achieve the same thing.

I should not have to worry that things work differently from different user interface elements of the application.
There are valid points for and against this. I will make sure it's considered.


If you apply a style, it changes the text to that style, not the previous style + the new style. Since this is not only the default behavior, but the only behavior unless you command-drag from the bottom of the Utility Drawer, it takes extensive planning to define your styles to make sure they change every possible attribute if you ever intend to use multiple styles (and even then not all of them will override the previous style).

Yes, some planning is needed, but you could say it's actually getting you to save time once you understand it. Styles applied to a wide amount of content should be kept basic and you build it up as individual cases come. So, lets just forget about the argument that OO doesn't work like other program and focus what needs to be fixed.

[WrongSizeGlass]

So the difference is when you apply custom or preset groups of styles. But aren't styles nothing more then applying multiple attributes at once? But enough about this. The difference is that when you apply a preset group of style attributes, all of the style attributes of the text they are applied to change. This is not the case in OOP. Are there any other cases like this with different attributes?I'm sure there are, such as the color Black, but since I try to do all my stylizing outside of OOP I couldn't provide a laundry list.I should not have to worry that things work differently from different user interface elements of the application.There are valid points for and against this. I will make sure it's considered.What other portions of OOP's UI elements work differently when you use them besides styles? Does adding/removing a section work differently when you choose it from the Menu or the Toolbar or the Utility Drawer? Does attaching a file? Does printing?Yes, some planning is needed, but you could say it's actually getting you to save time once you understand it. I understand how it works, that is not the problem. The problem is that they don't work the same throughout the application, and some attributes don't get changed even if they are defined in a style.
Styles applied to a wide amount of content should be kept basic and you build it up as individual cases come.This assumes that I want the same style as the "base" for everything at the same level or in the same section. This isn't always the case. So, lets just forget about the argument that OO doesn't work like other program and focus what needs to be fixed.Like I said in an earlier post, I don't care how you implement styles, it's your application and it's your perogative. Just make them work the same throughout the application (including the same modifier key functionality), and make the attributes set in a style apply when you apply that style (be it Regular, Black, etc). Different rules for different attributes used from different UI elements is not intuitive ... it is frustrating.


James B

[DerekM]

I'm sure there are, such as the color Black, but since I try to do all my stylizing outside of OOP I couldn't provide a laundry list.
Black actually works fine, just click on the color palette and select black. One that won't work is Helvetica font face as it's the default font. The things you can't set for named styles are most default settings (the issue that needs to be address is how do we determine when the user wants the default settings in the style). The solution is to not make all default settings automatically part of the style as that completely throws out the hierarchy system.

I'm hoping other people respond to this as a wider view is why I'm doing this on the forums. Take the case about having a bold style applied and then wanting to apply a non bold style. So using our style system, the current solution depends how how that bold style is applied. Is it applied to 'All level 1 rows'? Or is it applied to that specific row? If it's applied to 'All level 1 rows' and you need to change enough of them that you make another style, the solution is command-dragging. If it's applied to that specific row, you can just delete that style from the row in the Style Attributes. If you simply need to change a single instance or two, you can select the text and un-bold it.

Now you've mentioned that you can't command-drag apply styles using other methods. I'll make sure that's address. Is there something else wrong with this implementation though?


This assumes that I want the same style as the "base" for everything at the same level or in the same section. This isn't always the case.
If you don't want the same style as the base for that level, applying the style to "All level xx rows" is obviously the wrong place to do it. You should highlight all the applicable rows and apply the style to that level of the hierarchy.

Like I said in an earlier post, I don't care how you implement styles, it's your application and it's your perogative. Just make them work the same throughout the application (including the same modifier key functionality), and make the attributes set in a style apply when you apply that style (be it Regular, Black, etc). Different rules for different attributes used from different UI elements is not intuitive ... it is frustrating.
It was not my intent to argue with your over these things. You've identified the ruler as behaving differently and I've made note of that. What I want to know is there anything else that's a problem. I need specifics as to what you think is "broken" as the issues you face aren't the same as mine.

Thanks

[WrongSizeGlass]

Black actually works fine, just click on the color palette and select black.It doesn't always work. I tested it last night before I added it to my post. If I have a style and I give it a color of Black, applying that style on top of another style that was not Black, the text remains the original color.Now you've mentioned that you can't command-drag apply styles using other methods. I'll make sure that's address.Testing for the 'command' modifier key when applying a named style would be nice.Is there something else wrong with this implementation though?Applying a style attribute from the Ruler's Styles popup menu should not revert all other manually applied style attributes back to those of the last named style applied.

Also, is there a reason the mini icons for the named styles in the Ruler's Styles popup menu are upside down?If you don't want the same style as the base for that level, applying the style to "All level xx rows" is obviously the wrong place to do it. You should highlight all the applicable rows and apply the style to that level of the hierarchy. There are plenty of times I want some text within a row/section to have a different base from the other text in that row/section. What I want to know is there anything else that's a problem. I need specifics as to what you think is "broken" as the issues you face aren't the same as mine.It would be nice if the style attributes 'checked' in the Font submenu of the Action menu in the toolbar were in sync with the actual settings in the Inspector. It's not always the case, especially if you have made changes via the Ruler.

Or if the 'Clear Style' from the contextual menu always cleared all styles. If you apply multiple styles, there are times that it doesn't clear everything. I'm not sure if this is caused by applying a style from the Ruler or the Utility Drawer, but it happens.


James B

[DerekM]

It doesn't always work. I tested it last night before I added it to my post. If I have a style and I give it a color of Black, applying that style on top of another style that was not Black, the text remains the original color.
Can you send a file with these styles defined to omnioutliner@omnigroup.com please?

Also, is there a reason the mini icons for the named styles in the Ruler's Styles popup menu are upside down?
That would be a bug.

Or if the 'Clear Style' from the contextual menu always cleared all styles. If you apply multiple styles, there are times that it doesn't clear everything. I'm not sure if this is caused by applying a style from the Ruler or the Utility Drawer, but it happens.
This is something else I would need to see an example of to know if it's a bug or a result of how styles are handled.

I won't be responding to any more things to do directly with the ruler. It will be looked at.

[johnswhitehead]

It seems to me, Derek, that your extended explanations make their own point: it's complex and difficult. I am another user who has bounced off OOP's styling, giving up in mystified frustration when all I want to do is make the document look good. I'm quite prepared to accept that they have a logic that I could master with enough time, it's just that that's not a good use of my time.

What I'm used to in word processors and dtp packages is the notion of stylesheets. These control all the styles that apply to their object, either paragraph or character. In some cases one gets to control whether they are what one might term "absolute" -- 14pt Arial Bold -- or "relative" -- 14pt Bold of whatever font is already applied. Character styles can be applied to differentiate text within a paragraph and these typically survive when a new stylesheet is applied to the paragraph. They typically employ a hierarchy (heading 1, heading 2 etc) but there are also non-hierarchical elements for other purposes.

Something along these lines would be very welcome, along with the ability to specify the stylesheet to use by default for rows of a given level. Please consider this alternative to the current over-engineered system.

Many thanks

[DerekM]

It seems to me, Derek, that your extended explanations make their own point: it's complex and difficult. I am another user who has bounced off OOP's styling, giving up in mystified frustration when all I want to do is make the document look good. I'm quite prepared to accept that they have a logic that I could master with enough time, it's just that that's not a good use of my time.

Thanks for chiming in. We understand there are feature to the style system that cause confusion. But, the main things I've address in this thread in my opinion have been more about inconstancies or bugs. Perhaps I need to reread everything I've posted though. I have been trying explain how the styles work which is really not that complex but the default behavior may be slightly different then what you're used to.


I am familiar with styles sheets, but unfortunately as far as word processors go I mainly only know MS Word (and I find the PC version better laid out for modifying styles oddly). So when I compare OO to something else, I don't have that much else to draw from.
In some cases one gets to control whether they are what one might term "absolute" -- 14pt Arial Bold -- or "relative" -- 14pt Bold of whatever font is already applied. Character styles can be applied to differentiate text within a paragraph and these typically survive when a new stylesheet is applied to the paragraph. They typically employ a hierarchy (heading 1, heading 2 etc) but there are also non-hierarchical elements for other purposes.
Honestly, to me, you are describing OO's style system. Styles applied to all rows of level x are absolute, anything else more specific is relative. If all rows 1 are Arial pt 12, and then you make a row bold, that row is now bold Arial pt 12. So it would help me to know how this isn't how you see OO's styles.

There are certain features which we've decided was a bad choice, such as much of the automatic features, so what will help us is knowing what other then those things people don't like. I'm under the feeling that those who've given the style system a look at, are put off as the result of either a bug or result of a specific feature that we will get rid of. But once we remove that feature, the basic system will still be the same. If we had the resources to release a version right now that did away with the automatic stuff, we'd put it out to get feedback. But unfortunately that isn't possible so I'm trying to do what I can.

Just so you know, I've actually only been with Omni for about a month now, and as such was not around when this style system was developed, so like you I thrown into this program and had to learn how it works.

Thanks.
--
Derek M.
Support Ninja
The Omni Group

[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.

[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]

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]

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.

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.

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.

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.

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]

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]

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?

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.

[qomni]

I'm "fairly" comfortable with styles in OmniOutliner, nevertheless I am frequently flummoxed, whereas, by now, I'd think I should have a comfortable flow throughout the application.

So I'll mention two beguiling aspects of styling in OmniOutliner:


I'm often unclear about when the Style inspector is going to add an additional style to just the selected rows or columns, and when it is updating a row level or column level style (i.e. making a global style change). Seems like the only way to set styles is when a level is selected in the utilities sidebar. And this leads to the next issue.


I know how to select a row and column levels but—from my perspective—doing so is a mine sweep. I have to click the levels in the utilities sidebar and observe what gets selected in the outline. Seems backwards.

I think it would be far intuitive to have a mechanism that does the reverse. Click a level in the document; have a means for identifying this.


And I agree with the user who recommends the Pages approach. It is fairly elegant.

Also limiting in Outliner:


styles are ALWAYS associated with (a property of?) a level. Why not have styles be styles, which could be applied to any level?

And where oh where is the import/export styles?


Overall it's hard for me to imagine a simpler outliner. Keep up the good work. I use OO everyday!

qomni