(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Yes, I agree with this practice. This is why I prefer to not use regular expressions for parsing, as the temptation becomes to add requirements to a syntax so it can be parsed unambiguously. Shifting a burden further to the user, and away from the developer.

-- JaredWilliams, 02-02-2007

Well, it seems this point more interpreted as MakeTheDeveloperWorkHarder. As a developer, I must admit that I do not fully agree with this. Making the machine work harder makes sense, as long as we have enough computing power, which we probably have. Making the developer work harder is different. On the one hand, the user should get the optimal solution. On the other hand, we must keep the effort reasonable. Keeping the parsing simple helps spreading creole, because more people can easily implement a parser. Complicated parsers also tend to have more bugs. See also about parsing in Good Practices.

The current Creole suggests also to have very forgiving markup. Headings with and without ending equal signs or paragraphs that close bold markup, if the user forgets to close the bold markup himself. Is this really necessary? This is one of the points that make parsing more complicated. And I'm not sure if it is really the best for the user when there are multiple alternatives for the same markup. The more markup can be written in different ways, the more the markup between users will vary. Creole should unify the markup, so there should be only one way of writing headings. Of course headings are only an example.

I still agree that the user should get the best solution, and not the programmer. But we should carefully think whether more freedom in markup is always better for the user. Of course I am biased - as a programmer I am used to follow a special syntax. And normal users may think different. But in the end the user still has to learn how to write headings, or lists, or tables. Optional closing markup does not make it easier for the user. The only reason I see is to make it more compatible to other Wiki engines, but it is still against the goal to unify the markup.

-- SteffenSchramm, 2007-02-06

The problem is that users will not read specs. The will not read all the exceptions we put in like not allowing space after bullet, or that you have to close a heading with the excat number of equals signs you have at the beginning. People are learning the markup by trying out things. The will save and see what happens. They will maybe save again if it not works on the first try but thats it. If it still don't work they will tell you that markup sucks and all your hard developer work is in vain.

-- ChristophSauer, 2007-02-06

Christoph, that's not exactly how it is. It's true that users will not usually read any instructions (there are several ways of encouraging them, but that's irrelevant). But they don't come from outer space, you know. Especially on the wikis.

You seem to assume that the users are being caught on the street, seated in front of a computer with an empty editor screen, and told to type in long text with sophisticated markup. This is ridiculous.

  • Before editing any page, the users are likely to at least browse other, exisitng pages (rendered).
  • The first edit is done on an existing page, with some already formatted text present on it.
  • The first edit is most likely to be brief, several lines of text without sophisticated formatting. If the sophisticated formatting is needed, it will be added by other, more experienced users.

The users learn markup by observing it used on the pages (and very rarely, by examining cheat sheets), not by guessing it or by divine intervention. It's impossible to parse markup that is just made up by the user from thin air -- no matter how forgiving the parser is. The only case in which accepting a wide range of markups makes sense is when there actually are several standards requiring specific syntax, and the users are likely to want to use the same syntax on the wiki.

That's why I think that the rules for Creole markup should be:

  • obvious from looking at them,
  • visually distinctive,
  • readable,
  • lacking special cases that only appear in some rare contexts (and thus are impossible to learn from examples),
  • compatible with existing markups where possible.

I somewhat agree with the "make single person work harder for the benefit of many persons" rule:

  • make the spec writer work harder to make developer's work easier,
  • make developers work harder to make user's work easier,
  • make users work harder to make reader's work easier.

-- RadomirDopieralski, 2007-02-07

I know :-). I painted the worst case scenario. My post was intentionally exaggerated.

-- ChristophSauer, 2007-02-07

I think that we have no chance of success with the worst case scenario, and that focusing on it might cripple Creole's functionality in more common situations.

-- RadomirDopieralski, 2007-02-07

I think that we have no chance of succes with the best case scenario either, and that focusing on it might cripple Creole's functionality in more common situations as well.

-- ChristophSauer, 2007-02-07

Then maybe we should prepare a number of UseCases, you know, the boring made up short stories about people with names starting with A, B, C... Then we can try and accomodate them.

I think that we are, in several places of Creole, at points where there is not simple "better" and "worse" approach, and that we have to choose based on the target audience.

-- RadomirDopieralski, 2007-02-07

I agree with the point that users will probably start looking at existing pages and doing some smaller edits. I think that is also a reason not to allow too many markup alternatives. An experienced user (like from Wikipedia) just says "Let's see how headings are done here' and adopt it. Users new to Wikis also want to find out how these headings are done. Both will see it in the existing Wiki code (or the formatting help of the Wiki). It is just confusing if they find different variants of headings there. Then they have to decide which variant they want to use, and they probably begin to wonder why there are these alternatives.

-- SteffenSchramm, 2007-02-07

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 07-Feb-2007 19:59 by SteffenSchramm.