• Name: Michael Utech
• Email:
• Company Name: Utech IT-Dienstleistungen GmbH
• Company URL: http://www.itd.utech.de
• Country: Germany
• Hear From: While searching for a Wiki implementation on Google

Please free free to modify this page, if you want to discuss any of my comments. Also if you think that some of these comments should be activated an fit into a discussion anywhere, just do it and leave a link to the new place here

Some of the proposals may well be beyond the scope of TWiki, so I'm not asking anybody to implement my ideas, just to tell me what you think about it. Maybe too much critique let's you think I don't like TWiki, but that's not true, it's just very inspireing to me

Ways I'd like to see TWiki improved or changed:

WikiWords

Syntax (in FeatureBrainstorming)

(is this topic classification correct?)

I like the idea of wiki words very much, but the decision to use ThisWayToWriteThemIsInMyOpinionVeryDefective. I prefer to use underscores to identify a word or sentence as a wiki word because:

• Using underscores preserves the case of words.
• As a result, it's possible to render a wiki word stated in underscore syntax LikeThis, but not vice versa. So if somebodies taste differs from mine, at least there is a way around. F.g. MartinCleaver's approach to render wiki words separated by spaces is good, but still the result is somewhat ugly, as all words are capitalized.
• Underscores could be left out when rendering a wiki word, so that it looks as (IMHO) it should.
• The underscore approach handles abbrevations properly
• A lot of computer related terms use wiki word syntax but are not supposed to be recognized as such most of the times.
• (take from somewhere else) Some languages do not have case, so there it's difficult to create a wiki word. (Eg Chiq_chaq mentions Hebrew, Arabic, Kanji. -- EdAvis)
• Having preseved case, it now makes sense to ignore case when creating or *go*-ing a topic, since case now doesn't serve as a word delimitter.

My proposed definition of a WikiWord

• A wiki_word consists of at least two words separated by underscores (_)
• A word is made of digits and letters. A TWiki installation may extend this definition to include local characters.
• If a non-wiki_word is forcably used as topic name via [[...]], this name becomes by definition a new wiki_word.

Allowing digits in numbers seems less problematic here then with the original syntax. A topic name like 100_ways_to_do_it_in_perl is just fine for me (at least).

Expanding the definition to include strings which are not by itself wiki names is IMHO the proper way to handle them, but that's not really important to me, just added it for the sake of completeness.

Handling the definition of what is a letter to a local installation seems appropriate to me, since unicode is large, and I'm not able to define a sensitive subset as "letters". For European languages it's not so much of a problem and if "my" server is supposed to be used f.g. in a german/english environment, its really easy to define the set of letters excatly.

Some pros and cons (just add yours, please):

Pro

• No loss of information
• No side effects like "Windows FS is not case sensitive"
• If wiki words get rendered spaced, there is generally no need to force topic names, which is now a quite common practice by users who don't like nonspaced display

Contra

• Users who got used to it won't like to change
• more?

-- MichaelUtech - 18 Nov 2001, 23 Nov 2001

Nice summary Michael.

Underscores aside for the moment, consider also BumpyWordsForDocumentWriting.

-- MartinCleaver - 19 Nov 2001

I hacked TWiki.pm to recognize my proposed syntax. This seems to be working

Take a look at http://schnoffos.utech.de/twiki/bin/view/Main/new_wiki_word_syntax if you're interested to see how it looks like.

As far as I can tell, this seems to be working fine, but I don't know TWiki well enough to be sure. I'ld be glad, if someone would point out any possible problems regarding this hack.

Is there a chance that this will find it's way to the standard distribution, once it's proven to work?

Implementation notes

• As off now, the "old" syntax is still working
• I didn't find a good place to make topic names using the new scheme case (only them) case insensitive. I could do with some help there, please

-- MichaelUtech - 21 Nov 2001, 23 Nov 2001

I guess you need to store them in a predictable case and then munge the user's input to force it to match. Hence, you could go for initial cap plus cap after every underscore.

In terms of a place I guess this would be in the "go" box and wherever the topic name is taken. I believe that this is not centrally handled and that this is a change that must be necessary for other reasons. (e.g. if you type view?topic=Web.Topic it fails yet you can type that in the Go box).

Good luck in implementing it. I would support a vote to have it a standard optional feature.

-- MartinCleaver - 23 Nov 2001

Normalizing case would destroy the benefit of this approach, since preserving case was what I actually wanted.

So far I'm quite satisfied. I tried all feature I use and have not yet encountered any problems. It's even working smoothly together with the old scheme.

-- MichaelUtech - 24 Nov 2001

For langauges without upper and lower case, and perhaps for languages where losing the correct capitalization is just too confusing, it's clear that underscores would be used. But for existing English-language Wikis, as you say, existing users would not want to change. Many prefer the mixed-case style. Perhaps the choice of which style to display could be up to the user: SomeWord and some_word would be equivalent.

Personally, I'm with Rob Pike on this one: 'I eschew embedded capital letters in names; to my prose-­oriented eyes, they are too awkward to read comfortably. They jangle like bad typography.'. The MixedCaps style comes from Smalltalk - developed on a machine with no underscore character! But the style is strongly embedded in Wiki culture so probably should remain the default setting, at least in English.

-- EdAvis - 12 Oct 2003

Other issues

• In a topic, the topic name should not be rendered as a link by default. It's by far more probable, that the Author does not attempt to link to the top of the current page.
• As soon as a topic is defined using a non-wiki word (f.g. a singleton word, which sometimes make sense IMHO) this word should by definition become a wiki word (given that this mechanism is not abused, this could be easily implemented by keeping a hash of one word wiki names or a single regexp like /(word1)|(word2)/o. The performance and memory overhead should be minimal.

Text formatting

I use bullet lists a lot, so this may be a very personal problem. I would like to have paragraphs in bullet lists. If I insert a paragraph, the list is terminated, even if the new paragraph starts indented. I'ld propose to check the indentation and if it matches (n*3)+2, interpret the text as part of the item of the leading list.

As far as I remember, HTML does not allow paragraphs in lists (not sure anymore), but I find this very intuitive and would like not to have to use HTML to achieve the effect.

Opinions?

Bulletin Boards, Guestbooks and such

A BBS promotes a kind of communication that tends to have a high noise rate. This is one of the reasons why I love the Wiki Way. On the other hand, Wiki talk tends to be a bit annoying, especially if peoples styles differ. (I for my part annotate passages by using a bullet list item and emphasizing (or de-emphasizing). Like this you can modell threads. Others like to hrule and put comments to a chronological order or whatever).

Whether to use a wiki or a bulletin board to collaborate is in my opinion not a principal question but very dependant on the topic and goal of a collaboration. Sometimes, I would like a topic to just be a bulletin board with all it's neat features, sometimes I'ld prefer to be able to insert either %BBS{topic=Main.MichaelUtech,how=as_link}% or %BBS{topic=Main.MichaelUtech,how=expanded}%. Another neat thing could be a discuss topic action. Like this is would be easy to mix both concepts.

Given a BBS it would be desirable to write a message as wiki text (formatting, linking). So the other way around would also be nice to have.

Implementing both should be quite trivial, but I'm a bit afraid, doing so may lead to a lot of lazy people just using the BBS and letting the wiki degrade to a BBS. Many people do not understand a wiki. They either see it as complicated chatroom or as a traditional web site (depending on the kind of topic the see at first glance) or even are just afraid to edit a topic. These folks visit once and often just go away. I don't know if that's good or bad. If they saw something familliar like a BBS, they may stay and start flooding the site with small talk, which is at least not what I want, since there are enough sites having this characteristics. Users who appreciate what a wiki may be, on the other hand miss BBS techniques which simply just are more appropriate sometimes.

What do you think?

Your opinion goes here:

• Incorporating BBS is a bad idea: 0 votes
• Doing so is a good feature: 1 votes
• I can't tell: 1 vote

Super Webs (in FeatureBrainstorming)

I encounterd the term super web in another context (dunno where) on twikiDotOrg. I'm not sure if that term applies properly to what I want here...

It would be nice to have a web which contains common topics (such as documentation, definitions of frequently used wiki words and such) so that if a wiki word is not defined in the current web, but it is in the "super web", then the wiki word should refer to the topic in the superweb (think of it as a fall back).

Topics to put in the "super" web:

• Users
• Help documents

I'm not sure if this feature is really worth the price, since it introduces quite some complexity. Just wanted to mention it to gather some opinions about it.

-- MichaelUtech - 20 Nov 2001

Take a look at TopicNotFoundInThisWeb and MultiLevelWikiWebs.

-- MartinCleaver - 20 Nov 2001

Sorry, I did not encounter these. This certainly obsoletes my new topic.

-- MichaelUtech - 20 Nov 2001

Multi language topic scheme (in FeatureBrainstorming)

I initially wanted to be my public wiki multilingual, but that would have ask too much discipline from it's users. A scheme that would make this possible would be:

A topic may have several language versions, all refered to by the same topic name, distinguished by an optional language suffix (.en, .de, .it, ...). If a topic is referred to without language suffix, it's created or displayed in the user, web or twikis default language in that order. A user may specify which languages (s)he speaks, an existing topic which has none such version lead to an oops saying so and listing available language versions. If there are multiple versions the best one is choosen. What beeing the best choice actually means is not clear to me, especially if the contents of a topics language versions differ (see below).

Each language version may differ from others not only in language, but also in content. This is not desirable, but also not to much of a problem if the meanings of a topics languages version don't depart too much. If the do, they may be splitted, if both branches are good.

For important topics, or if a wiki wants to be equally available in all languages, a concept of topic maintainers for a set of languages and topics could be introduced, which notifies a translater that a topic needs re-translation.

This is probably some work, but it would be very desirable for non-english or multilanguage environments.

Alternative solutions

I thought a while about how to achieve the same goal without changing twiki itself, but I did not find a satisfying solution.

-- MichaelUtech - 20 Nov 2001

External and internal Links

• It would be quite easy to extract all external links from a topic, storing them in a database. This can be used to periodically check if they are still reachable. Also a sysadm could check the links for critical contents. TWiki could be configurable so that unchecked links need approval (so that a unapproved link referes to an oops page). Another usefull feature would be to periodically check for dead links, either removing them or notifying the inventor of the link. Then a link could be checked for availability when first entered and rejected it's it's mistyped.
• ...

Structured data, forms and such

needs some more thinking on my side

Layout and Design (in FeatureBrainstorming)

It's quite easy to create a local style sheet to render the contents a bit neater. But it would be very nice to have this feature in the default distribution, especially because if you don't use them very often, it's a some work to assemble a consistent set of styles.

I would appreciate it, if such settings like web colors would be replaced or synchronized with such a style sheet, and in the case of webcolors to have the possibility to use color pairs, for not to be restricted to the light pastell colors.

I did all but the color pairs for webcolors (I'm not yet working on a design) and it has been a trivial task. It would nevertheless be good to have CSS support in core TWiki, since doing it my way means editing a lot of template files (everywhere, where there are BODY tags). As it is now, I'ld have to redo this each time I update the system.

-- MichaelUtech - 20 Nov 2001

I have spent a little time attempting to CSS-ify TWiki and have found the process to be an accessible but nevertheless non-trivial exercise. I think I could put together a skins package with about another 20 hours of playing around but I simply don't have the time right now. : (

For somebody who has spent time actually developing TWiki it might be a little easier (because they would already understand how all the parts are put together).

Some other places this discussion has occured are: TWikiStyleSheets, TWikiUsingCSS, UsingTopicToDefineCSS, PreferencesAsStyleSheets, AutomaticSizingOfEditWindow, UsabilityIdeas

-- MattWilkie - 20 Nov 2001

Style Sheets

Skins

...