See also: BetterMarkupInGeneral, BetterMarkup and BetterColors and of course TWikiDocGraphics and of course TooUglyForNonTechnicalUsers.

---

This is brainstorming at the moment. Some details of the definition and specification remain.

Indicators in the Text

Indicators are graphical markers that draw attention to part of the text.

Current Scheme

The set of indicators available on a site are defined in TWiki.TWikipreferences (see the section "Miscellaneous Settings", they are just under the part on colorization).

A set of shorthand tags are defined such as %N% for the graphic for "*new*".
These are documented in TWikiDocGraphics.

Problems

The major shortcoming is

• The set of indicators is predefined by the site administrator

Although some people may view that as an advantage

The minor shortcoming is

• The abbreviations are non intuivie and difficult to remember.
  • Using longer words eats into the name space.

Some people who view things from the UI POV may consider this the major shortcoming.

At worst, users can always interject their own graphics like this:
As site administrators, though, we'd rather keep them focused.

Proposed Solution

The solution is in two parts.

1. Update TextFormattingRules to include the syntax for indicators, be it the "original" or what is proposed here.
2. Have a plug-in for the indicator that handles intelligent mapping of symbolic names.

Advantages

Use of Symbolic Names: It one thing to remember that %N% means "new" but what when you want the little bulb - %B% or %T% or %I%. Handling of Defaults : If there is no symbol of the name supplied an intelligent default action can happen. Suggestions include:

• • Have a default symbol such as a small red star
  • Try to do a spell-check ... "pudated" -> "updated"
  • Do nothing
  • If in preview mode, insert a flashing neon sign saying "use of unknown indicator"

Implementation

Personally, I think "%INDICATOR%" is a bit long winded; how about "*%FLAG%*"?

Syntax

Straightforward : "This is New *%FLAG("new")%*" comes out as "This is New ".
So do the variants such as %FLAG("NEW")% and other case variations.

Setup

The site prefernces will of course have the definition table, only now it will be in a Topic of its own.

The variables there will have to support:

• The default symbol
• The default action if the name is not found
  whihc must be from the set that is actualy implemented!
• Common aliases for the symbols (e.g. "bulb" = "new idea" and "attention" = "alarm" = "please note"

---

Deferment

I'm not going to do anything with this until the BeijingRelease is stabilized.

I'd like feedback on this, but read BetterMarkupInGeneral? and BetterMarkup?

-- AntonAylward - 03 Jan 2003

ThreadMode Comments

Perhaps we could use a similar method to some of the Forum software, for when they provide smilies. They usually have a list of the smilies to one side (or beneath), and clicking on the chosen item adds the specific markup into the editor at the current cursor position.

We could also adopt the naming conventions such as :roll: for rolleyes - so we could have :new: for new, etc.

I'm not sure quite how appropriate it is, but it certainly works well.

-- MichaelKearns - 03 Jan 2003

Please don't take offense Anton, but %FLAG("new")% sucks, while %N% merely sucks less. Too much extra typing and too many shift-keys. It also makes a sentence harder to read in edit mode. I would much prefer dropping both syntaxes and using something like Micheal's suggestion: :new: or new! or some variant thereof.

I have the same problem with the indented quote example in BetterMarkup.

-- MattWilkie - 04 Jan 2003

I don't take offence. I like Michael's idea too. I can only remember three smilies, and But they are soooo easy to remember and type, even if they do need a couple of shift keys.

As to whether there should be one syntax for all graphics, I'm uncertain. The net, be it mail, Usenet or web, has a long tradition of smilies and many people, apart from myself :self-reflective-sarcasm:, are very familiar with them. Introducing :new: is, I agree cleaner than %FLAG("new")%. But can we generalise that to refer to any graphic? How about other languages and aliases ... :nuveau: :achtung: :important:. Babel time again -- BabelOfWikis

I also like Michael's idea of the additional pick-list of synbols. Quite a few of my other software packages have that. You can see it in many editors - OpenOffice is one exaple, but there its a pull-down. The question then becomes one of browser compatibility, which you know about, Matt, from your work on style sheets, and screen real estate.

In my mind there is another question. Using %N%, :new: or the smilies, their existence my a but occladed but they are not intrusive. If you don't want to know abot them their existence diosn't bother you. We are primarily a text meduium. Having a sidebar or pull-down for graphics starts another slippery-slope. How much do we put there? How do we manage that screen real estate, not least of all when the window size alters? Do we threat smilies the same as other indicators even though there are many people who would use smilies but have no interest in indicators? Would having such a sidebar lead to a prolifereation of excessive graphic markup aking to the early days of the GUI and the 'ransome note' effect where users tried using every font and style? And finally, how do we deal with issues of accessibility, even at the basic level of users with only text browsers or test-to-speach browsers?

And no, I'm not joking.

-- AntonAylward - 04 Jan 2003

A limited form of dropdown is already available in JavascriptBasedEditor. The SmiliesPlugin will accept any text as smilies and anyone with update access on it's topic can add new ones.

-- JohnTalintyre - 04 Jan 2003

You're missing the point, John. End user's don't want to have to keep customizing and smilies are a special case, whereas I'm trying to address a more general one. Smilies are part of 'Net culture and most users are familiar with them and type them as a matter of course (except perhaps those that type "LOL"). Mapping them to graphics is common fearture. Most people don't have to look them up - yes I'm an exception, I only know those three.

But I'm talking about indicators in general.

Adding a section to the TextFormattingRules would certainly help.

As MattWilkie has pointed out, the limitation with converting to CSS is that we have to accomodate all manner of browsers. Using templates/edit.iejs.tmpl is a hack. We cannot in general assume the browsers have "feature X" enabled. We have to be end-user centric and not programmer centric about this. The purpose of the Wiki is to supply a service to the end users, and that service needs to be smooth and should not involve them in what's "under the hood" - be that hood the registery, config files or the internal workings of the application. You and I can merrily hack our registries and config files, and all power to us, but if we want a Wiki to be accepted by the end users, we can't make that kind of assumption. See TooUglyForNonTechnicalUsers.

If we can do pop-ups with CSS, that would be great.

This is why in BetterColors I suggested a syntax that allowed the end user to make use of symbolic names for colors, any symbolic name, not one that has to be pre-loaded by the Twiki Administrator; this is why in BetterIndicators I suggested symbolic names and aliases.

Lets face it, %E% could be anything. %FLAG("exclamation")% and %FLAG("eye-winking")% - for example - make sense to the user typing them in. The first falls into the fallacy of "minimizing keystrokes", which really means "making it obscure and ambigious". The latter may be clunky, but we can see a scheme whereby users can in their own Topic page add aliases.

-- AntonAylward - 06 Jan 2003

I've just started renaming the graphics variables in my TWikiPreferences, to short symbolic names like %YES% for the . No way are non-technical people going to memorise a set of one letter mnemonics. Sure, it eats into the name space a little, but Wiki pages should be readable in text form as well as when rendered.

By the way, I changed the term "brianstorming" at the top to "brainstorming" as I couldn't spot any Brian involved in this discusssion. Sorry Brian if you're out there!

-- AndyPryke - 24 Apr 2003

I just want to register a vote in favor of the wiki markup syntax like: new!, updated!, wink!, blink!, exclaim!, etc. Maybe that's a longer term solution?

-- RandyKramer - 25 Apr 2003

I support longer, more mnemonic names for default graphics, too. I did it, too, but did not reported Longer, more mnemonic names should be easy to get implemented in standard distro - but my bet is: it is not going to happen.

-- PeterMasiar - 28 Apr 2003

Perhaps the underlying assumption is wrong. Essentially this discussion is about how to represent metadata:

1. how to call attention to something which is [new, important, changed, deleted, etc.]
2. communicate emotion.

For item 1, what we really want is WebChanges combined with personal preferences. E.g. show me what has been changed since the last time I read this topic, not what the previous editor marked as new, two years ago.

For item 2, well the smilies are it I think. My personal preference is just to use normal words [smiles]. There are no codes to remember, instantly multi-lingual, and works as well on the printed page as on screen. The "most correct" answer would be to have everyone write like a novelist, using normal language to communicate emotion. We wont see fast progress on this front methinks. [grin]

An interim soution would be to have twiki render everything between [] (or some other easy to type delimiter) [like this], or similar using css and the span tag.

-- MattWilkie - 28 Apr 2003