Fog Creek Software
Discussion Board




Knowledge Base
Documentation
Terry's Tips
Darren's Tips

Feature request: programmable toolbar

It would be great to have a simple "programmable" toolbar, a la Arachnophilia, where the user can create self-defined formatting buttons using an easy script language.

How I would use the feature is to set up my style classes. Highlight a piece of text, click a button, and it is enclosed in a p-tag with class=whatever. This way the Normal view becomes even more flexible for the developer, the web monkey, and the non-monkeys.

Actually, the more I think about it, the more I'm convinced it's a killer idea.

Amos
Wednesday, March 26, 2003

Oh yeah.... that IS a great idea.

For exmaple, a macro that can build a loop for you based on user input:

click on [build index] and it writes the index for you, prompting you for which folder you want indexed.

The developer can write the script, and just replace the condition with the prompt...

www.marktaw.com
Wednesday, March 26, 2003

Plus, I think the font-size & color should be CSS driven. When I switched from a white-background to a black-background site it was murder on the font colors I chose before.

www.marktaw.com
Wednesday, March 26, 2003

Terrific idea! Argues for having not one, but two programmagble toolbars, one for normal view, and the second only visible in design view.

Amos
Wednesday, March 26, 2003

Here's something, very limited, that you can do today... It allows you to have 1 special paragraph style and 3 special character styles.

In your style sheet, create styles for BLOCKQUOTE for your paragraph style, and STRONG, EM, and U for character styles.

Then you can use the indent button to get the BLOCKQUOTE style, and the B/I/U buttons to get the other three styles.

For example, you can use the BLOCKQUOTE style to create yellow post-its (like the quotes on the CityDesk home page). As another example, in the CityDesk documentation we created a style for STRONG which uses a typewriter font, so the [B] button can be used to create code samples.

Joel Spolsky
Thursday, March 27, 2003

I have taken to using <i> italics </i> for emphasis rather than color changes. I'd rather not change what <i> does though because one day I'll forget and when I want <i> it'll turn out fucia or something. =)

Thanks for the tip though.

www.marktaw.com
Thursday, March 27, 2003

Umm...well...I'm of a different mind.  The user, who is the editior, whould not be worrying about formatting.  The editor is concentrating on content.

The tags that the editor should be able to apply should define content, not format.  Formatting should be defined by style sheets that are created by people who are experts in the field of visual display.

CD provides a way to override this: A formatted Word document can be cut-and-pasted into CD and displayed beautifully.

So, to me, more important than a style editor (via a toolbar) would be an interface to a XML validator to ensure that the editors are inputing stories that conform to specific Document Type Defiinitions (DTDs).

If one wants a system that assists the user to apply styles, then it should be able to parse the definitions in a programmer-specified list of CSS files.  The list of available styles can then be built and presented to the editor for use when editing content. 

But this could get pretty messy.  Defining content type is easier than defining styles, for example:

<story>
<author>..</author>
<title>..</title>
<subtitle>..</subtitle>
<date>..</date>
<section heading="">
.....
</section>
<section heading="">
.....
</section>
</story>

Joel Finkel
Friday, March 28, 2003

Interesting.

If you import a Word doc, then you accept the inline style calls embedded by MS Word.  Your stylesheet has no affect.

If you just let the CD editor do its work, then everything is a plain <p> tag.

I don't understand the complication of highlighting a string and clicking a button labeled "Author" which applies the appropriate <p class=author>text</p> or <span class=author>text</span> or, for that matter <author>text</author> if you have XML/XLS set up.

All the user has to know is to click a button. The scripting is done by the developer in creating the toolbar.

Amos
Friday, March 28, 2003

Joel S.

I've been playing with your workaround suggestion. It's good to a point.

I tried to use the <u> tag with padding on a block of text with a <br>. After the break, the padding did not take effect. In fact, the padding only worked on the first line of wrapped text. Bummer.

Amos
Friday, March 28, 2003

Joel F. I have not met a single content contributor that didn't want more control over the appearance of their content.

Though, if presented with a plaintext box, I doubt they would complain, if given any editing options at all, they would want to use them.

www.marktaw.com
Friday, March 28, 2003

Content contributors may want many things.  That does not mean that it makes sense to give it to them.

Consider a Book Titile.  How should it be displayed?  Should it be in italics?  Should it be in quotes?  Perhaps that depends on the output medium.  Perhaps it depends on the location in the document.  Perhaps it depends on the style being imposed by the publisher.

Therefore, it does not make sense to give the content provider the ability to embed a <u> tag, does it?

Instead, one should define an XML <book_title>..</book_title> tag, and let the content provider use that.  The publisher should be free to transform that into <u>..</u>, or "".."", or whatever, as they see fit.

I can see an exception for lists.

Joel Finkel
Wednesday, April 09, 2003

I object to a certain style of "bold at least every third word" that I saw a lot in press releases when a certain writer was around.

On the other hand, the web page should have the ability to look just like the print release, so bold should be an option.

www.marktaw.com
Wednesday, April 09, 2003

*  Recent Topics

*  Fog Creek Home