[DerekM]

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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?

Originally Posted by WrongSizeGlass

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.

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]

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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.

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]

Originally Posted by WrongSizeGlass

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?

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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]

Originally Posted by WrongSizeGlass

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?

Originally Posted by WrongSizeGlass

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.

Originally Posted by WrongSizeGlass

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.

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]

Originally Posted by 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.

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.

Originally Posted by johnswhitehead

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.