- Wiki's emphasis is on content, not presentation. The simple markup rules make people focus on expressing their ideas, not making them pretty. Some people have found that working in this minimal medium improves their writing.
- Wiki's TextFormattingRules were designed to DoTheSimplestThingThatCouldPossiblyWork.
- Typing HyperTextMarkupLanguage tags breaks the flow of one's thoughts, particularly for complex tags such as tables. (See example below.)
- Part of WikiNature is that the code should be readable; that extends to the raw text of WikiPages. When editing, content should be instantly identifiable, not lost in a sea of angle brackets.
- Allowing the full range of HTML tends to turn pages into bewildering mess of multiple fonts, colors, etc. If you just want to communicate an idea, YouArentGonnaNeedIt.
- Allowing all HTML opens security holes through JavaScript exploits, etc (although this is easy to fix; see discussion on JavaScriptEnabledWiki).
- Converting 25,000+ pages and the scripts that run the site would be a major undertaking without equivalent benefit. In other words, ItJustWorks. IfItAintBrokeDontFixIt.
- Many people don't know HTML. Wiki markup is easier to learn. [CitationNeeded]
- Some other wikis in fact do HTML, e.g. http://www.wikihtml.com[Doesn't work 9 July 2012.]
See WikiDesignPrinciples which is a statement from the early days.
An Example of HTML vs. Wiki Syntax
A table formatted so:
| X | Y |
|---|---|
| 1 | 2 |
| 3 | 4 |
X Y 1 2 3 4Until TabMunging farks it up.
However the markup for WikiTables used on other wikis retains the benefits of HTML tables without the noise:
| X | Y | | 1 | 2 | | 3 | 4 |
Testimonials
From RobertDiFalco:
I should say here that I am a big time WikiWikiWeb lover. But then again, it drives me crazy that I can only do:
one two three...in monotype! :) -- RobertDiFalco
BigBracketedTags is not WikiZen. -- AnonymousDonor
Ya know? You're right. I've changed my mind. Our Twiki at work allows HTML, and some people can't help but take that to extremes making editing unruly and certainly not WikiZen. Some pages are so full of big bracketed tags that one cannot find the text or its structure. They detract from the flow. Many people know and can edit HTML, but very few can look at an unrendered HTML document and see the text and not the markup. By contrast, unrendered WikiWiki MarkupLanguage (see TextFormattingRules) allows you to avoid CantSeeTheForestForTheTrees problems.
I love finding out I'm wrong, makes me feel that I'm still a kid at 37 (02 March 1963). -- RobertDiFalco
I think WikiMarkup is one of the best things WikiWiki has given us. Well, I do think that the emphasis characters are ill-chosen (and WardsWiki's HTML output is bad), but the idea of having a simple, easy-to-read markup language with standard formatting rules to simple, easy-to-read HTML is good. I think all content should ultimately be in a format like this: plaintext, NoHiddenContent, convertible. -- PanuKalliokoski
From another AnonymousDonor:
The argument that tags are more natural for blockquote is silly when I can recall several instances of my work at a helpdesk involving the removal of spaces and carriage returns from a secretary's attempt to do blocked quotes. Even fewer people would ever use blockquote in the first place.
Objections to Wiki's TextFormattingRules
Wiki's TextFormattingRules aren't perfect. Some of the most common objections:
- Obscurity. Is it any more intuitive to type two single quotes than ? If contributors must use a markup language, why not use one that already exists (HTML)?
- Tabs. Typing tabs is difficult in many browsers, so much so that the page TipForTypingTab was created.
- Quote blocks. Combine tabs with obscurity and the result is the syntax for quote blocks: "
+ space + colon + " is hard to remember and to type. See SimulatingQuoteBlocks. - It's hard to remember whether it takes four, five, or SixSingleQuotes to break the LinkPattern.
- It can be hard to distinguish between participants when more than three or four contribute to a discussion.
- The TextFormattingRules are incomplete. The rules do not support some markup features which might be necessary in certain contexts, for example underlining text and HtmlTables.
Alternatives
- See WikiStyleSheet. Wikis with this system can turn their <br> back into
, so you can add custom tags as you need them, not all BigDesignUpFront. - Add a WysiWyg Java editor to the edit page. However, this creates problems:
- It won't be powerful enough for some users
- People have to learn yet another editor
- Some folks disable Java
- Some folks don't install Java in the first place
- Some browsers can't use Java: LynxBrowser, WebTv (though the WebTv users at Wiki are probably few to zero)
- Add WysiWyg functionality on the server using web browser Rich Text Controls for basic functions, like Epoz, http://mjablonski.freezope.org/epoz/test.html/edit which works with http://zope.org and http://plone.org, but apparently not yet http://zwiki.org, the (only?) wiki that runs on Zope. You need mozilla 1.31+ or IE 5.5+ or Netscape 7.1+. I guess you could modify it to render WikiSyntax instead of HTML, or allow multiple formats in your wiki server (best idea). See http://betterdifferent.com/software/superwiki for more ideas.
- Allow people to type either HTML or WikiSyntax, and translate it to a standard format (e.g., XML) at save time. Translate it back to the user's preference when presenting the page for editing. See XmlBasedWiki.
- Use HTML as THE syntax for the Wiki system. There are a few Wikis and WikiLikeThings that simply work with HTML instead. MassMind is one example, and there must be others.
Another View
Maybe the consistent desire we see to put BigBracketedTags into WikiWikiMarkupLanguage is because the TextFormattingRules are unnatural to the user. I find it hard to believe that it's because it's not powerful enough.
I put my thoughts on a new set of TextFormattingRules on TextFormattingRulesRevised. -- MattBehrens
HTML Semantic View
HTML is technically for content, not presentation, unlike noted in the second bullet at the top. Works like XHTML and CSS aid in clarifying this. As such, perhaps it is more or less of anti-HTML presentation elements (such as b, i, and font), rather than just anti-HTML (which includes some excellent elements which can be used to create semantic data). -- CortlandHaws
In that spirit Wiki TextFormattingRules totally breaks this goal allowing bold, underline, italic, etc instead of only or etc. IMHO Wiki TextFormattingRules is more about presentation than about semantic. So always IMHO all answers to the question at the top of this document are completely nonsense. -- BrunoBeaufils
"Is it any more intuitive to type two single quotes than ? People are familiar with HTML. Wiki forces them to learn new TextFormattingRules."
What people are familiar with HTML? Programmers and Web designers. What about everyone else? We use a wiki at my day job, and I'm sure glad I didn't have to teach my whole company (which includes electrical and mechanical engineers, physicists, salesfolk, skilled technicians, and admin assistants, not just software geeks) HTML in order to be able to use it. I'm sure it would've been an immediate turnoff for most people. -- MikeSmith
Good point. The comment above has been changed to emphasize instead the fact that Wiki introduces a new markup language in a domain where a standard already exists.
(Possibly move to AlternativeTextFormattingRules?)
Someone wrote, "Wiki's TextFormattingRules were designed to DoTheSimplestThingThatCouldPossiblyWork" - but the simplest thing would be for the wiki server to simply copy the text of the page from its database to the Web server, and not muck around with converting quotes to boldface, stars to
- if it's the first one), and all that dreck. -- BillTrost
While that would be simple to implement, it wouldn't "work" in that it doesn't meet the requirements. People who tried to edit with no familiarity with HTML would have a lot of difficulty writing plain paragraphed text and creating links between pages, which is the essence of WikiWiki.
I would agree that the bold, italic, and list syntaxes used here are confusing and arbitrary - particularly anything requiring a tab followed by a space! But they are incidental features, not essential ones. The majority of text here consists of paragraphs of text with embedded links, and the Wiki syntax for these is perfectly simple and intuitive for the user and very simple to implement as well.
Wiki's TextFormattingRules are incomplete. For example, in order to properly annotate a written source someone would need to have the ability to underline text. Also, image source tags are automatically created and there is no option to dictate how text should wrap around the image. As a result one does not have the ability to generate good looking page. A more extensive ability to markup would be nice, though it certainly does not have to be comprehensive.
Instead of worrying about a GoodLookingPage, concentrate on just making a GoodPage.
The fact that Wiki supports MarkUp at all is an indication that format and layout is important to being able to convey meaning and ideas. Contrary to what appears to be the consensus for this wiki the 2 goals (GoodLookingPage/GoodPage) are not mutually exclusive, rather they are often the same goal. If part of the WikiNature is to have readable text, then it should not allow images at all. The URL reference for an image is not necessarily useful in determining the information contained in the image. For example a graph named "Web Log Traffic Analysis" does not communicate to the reader of the text the information contained in the graph itself. Rather you must see the rendered page to see the trends in the graph, at which point explanatory text becomes useful to interpretation of the data. Further it would be useful, and improve readability of the finished rendered page if the text could appear to the right of the graph as opposed to necessarily being below the graph. In general systems have wider displays than they are tall, it is good design to be able to set up pages with this in mind. The bottom line is that the current text formatting rules are lacking.
The wiki markup isn't a presentational markup, it is a semantic markup. The fact that it is always discussed in the context of text formatting is merely because this is the easiest way to explain it. It provides enough markup to give emphasis, separate sections and define lists. Each of these provides a level of information to the text. Making text appear next to images or other layout issues are pure aesthetics
First of all, aesthetic choices are important. The choice to not allow a "bewildering mess of multiple fonts, colors, etc" is a purely aesthetic choice.
Second, the ability to place text in relationship to an image is a functional necessity, not just aesthetics. People's eyes are trained from years of reading to scan efficiently from left to right. (If your language reads left-to-right; not all do.) The ability to place an image with explanatory text to the left or right of the image makes a huge difference in the ability to effectively and efficiently process the image and explanatory text. This is especially true if the image is tall. If I inserted a tall image in this wiki it would leave a lot of wasted white space to the right of the image and force users to scroll up and down to see the image and get the explanatory text. This is an issue of functionality for the rendered page.
Lastly, perhaps it is the lack of presentation capabilities which is the reason the MarkUp is ineffectual. Perhaps it is beyond the scope of this wiki to allow more advanced presentation. Please bear in mind that this criticism is aimed at the wiki software running this site, not this site itself. Perhaps the limits of the software are acceptable for the scope of this site, but the creation of the WikiClones (a good example is http://en.wikipedia.org/wiki/Biological_cell) is a testament to the need for wikis with more capabilities than this site's software offers currently.
There are wikis that do HTML including JavaScript (make them instances of WikiWithProgrammableContent), e.g. FoxWiki.
Admittedly, WikiWiki MarkupLanguage (see TextFormattingRules) may not be the perfect way to achieve WikiZen, but it's much closer to it than HTML. Don't you think?
- I for one have been thinking about that... I think HTML is much more powerful and intuitive [WuWei], and I think that if you simply strip out all the
- end quote from:
Why Doesnt Wiki Do Html - C2 Wiki
wiki.c2.com/?WhyDoesntWikiDoHtmlSome other wikis in fact do HTML, e.g. http://www.wikihtml.com [Doesn't work 9 ... However the markup for WikiTables used on other wikis retains the benefits of ...
- As you can see there are many opinions of what people like about any computer language and what they don't like. It's sort of like how people feel about actual human languages like English, French and German. Some people like English because it is a great language for business because it developed from ocean traders coming to England to trade their goods.
- Some people like French because they can better express their feelings in French or do philosophy better.
- Some people like German because it can be concise but others don't like the sharp sounds it makes.
- However, if you listen carefully to English it combines elements of both German and Nordic languages and French all in one language.
- So, computer languages are just like this in that everyone prefers different things. So, likely both human languages and computer languages will continue to be modified over the years for many different tastes and uses ongoing.
No comments:
Post a Comment