Wiki Syntax | The Coffeehouse

Sampy
This will be the sixth time we have destroyed it and we have become exceedingly efficient at it

So I'm working on the wiki (again) after getting the new media player code running and in David's hands (teaser!) and wanted to get some feedback on some of my ideas from the niners.

Most wikis use their own formatting language to change text, create links, make tables, etc. A lot of this was probably designed back in the day when the best editor you had was a text box element and you wanted the syntax to give you a bit of a visual clue as to what the final text would look like when converted to HTML.

Today we have nice rich text box editors and many more people understand how to write HTML. In this vein, I was thinking about using HTML directly in the wiki. There would be no double or triple single quotes to make things bold or italics, lists would use li tags, and images would be your standard img. Some things could remain from the wiki language: using [[ ]] to specify intra-wiki links for example. There would be an editor like there is today where you can use a rich WYSIWYG editor or switch to HTML view. The HTML would run through all the filters that entries run through now.

Thoughts? I think there is a continum here from no HTML to full HTML and the answer lies somewhere in between. Let me know where you think we should land. Post your comments and questions below and we can spec this thing out.

littleguru
<3 Seattle

What's important is that creating new topics and linking to other topics works fast. Linking must be done in an automatic fashion. Like i put the word in [[ ]] or whatever and the wiki does automatically understand that this is another keyword (topic) in the wiki. You could provide an editor, where somebody can just type the topic and the [[ ]] (or similar) are inserted automatically.

I'm for HTML, but limit the possibilities a little bit. I think wiki pages should have a general design, like the title is always looking that way and the text size should be always that size etc.

Not that we get like monster text in the wiki. Makes it hard to read.

W3bbo
The Master of Baiters

Sampy wrote:
So I'm working on the wiki (again) after getting the new media player code running and in David's hands (teaser!) and wanted to get some feedback on some of my ideas from the niners.

Most wikis use their own formatting language to change text, create links, make tables, etc. A lot of this was probably designed back in the day when the best editor you had was a text box element and you wanted the syntax to give you a bit of a visual clue as to what the final text would look like when converted to HTML.

Just give us MediaWiki or Markdown modes, I won't touch Design mode....ever.

...because web-based editors always produce bad markup unless you write a layer between the browser's design-time editing features and the server, like widgEdit, which is amazing btw.

Dr Herbie
Horses for courses

littleguru wrote:
What's important is that creating new topics and linking to other topics works fast. Linking must be done in an automatic fashion. Like i put the word in [[ ]] or whatever and the wiki does automatically understand that this is another keyword (topic) in the wiki. You could provide an editor, where somebody can just type the topic and the [[ ]] (or similar) are inserted automatically.

I'm for HTML, but limit the possibilities a little bit. I think wiki pages should have a general design, like the title is always looking that way and the text size should be always that size etc.

Not that we get like monster text in the wiki. Makes it hard to read.

XHTML-based editor with access to pre-set list of CSS styles. Allows a degree of styling without opening the floodgates the tasteless buffoons (not that we get tasteless buffoons here, but you never know), plus allows style updates from the C9 team through CSS.

Herbie

CannotResolveSymbol
{insert caption here}

For basic tasks, I actually prefer Mediawiki markup over a design-mode HTML editor. I find it to generally be more concise and easier to type, plus linking is much simpler, and it's easier on the eyes when reading or editing versus HTML.

E.g. this is much easier to type and read later (if you edit):

Hey! I just '''love''' this new [http://www.google.com/ website]! It's so amazing and ''awesome'' and stuff!!!!!111one

New paragraphs and lists are cool too:

* One
* Two
* Three

# One
# Two
# Three

than

Hey! I just love this new <a href="http://www.google.com">website</a>! It's so amazing and awesome and stuff!!!!!!111one
New paragraphs and lists are cool too:
<ul><li>One</li>
<li>Two</li>
<li>Three</li></ul>
<ol><li>One</li>
<li>Two</li>
<li>Three</li></ol>

It produces much more consistent markup on the server end than the browsers' design modes can produce and it's still readable even if you are looking at just the source with no formatting (and I'm even being nice here, because a browser's HTML editor would put the above in with no line breaks to make it easier to read.

HumanCompiler
Compiling humans...and code

2 things...

1. Looking at current usage of the C9 wiki shows that there is next to no editing done in the wiki. Of that editing, most of it is done by Microsoft employees.

2. Eventually, the text for posts will be replaced by the text engine that Sampy as built so that we can get things like versioning and have a consistent API across the platform to text.

Keeping those things in mind I would ask that you all consider why are we here? Look at your last 9 posts. Of those, how many are easily done in design view with little or no formatting? Keep in mind, we will make sure the markup is clean and xhtml compliant, so no excuses there. I understand that every now and then, some extra formatting is required. But if 90% of your posts are just talking in a conversation (that's why the coffeehouse is here, right?) then it's a lot less work (for us to spend on something more important in C9) to keep the editing experience simple.

Sampy
This will be the sixth time we have destroyed it and we have become exceedingly efficient at it

Good feedback everyone. I'll clarify a few points of the proposal.

The page editing experience will be exactly the same as editing a forum post. We'd reuse Erik's javascript editor that we use all over the site. In fact, we'd like to use the same engine that tracks wiki versions to control the body of every entry on the site. That way we can prevent a "Beer28"ing of the past by keeping previous versions of every post. This feature is still in the "Wouldn't it be cool if..." stage of development so we don't have details yet but it's something we'd like to investigate.

It seems like a lot of the anti-HTML comments stem from the assumption that the WYSIWYG editor would be bad. Either it would produce crappy markup or you wouldn't use it for personal reasons. Can I take that as a "if you have a good editor, maybe HTML is okay"?

The bad formatting thing can be controlled by filters on our end or the much less technical "it's a wiki so if the formatting is lame fix it" solution. If the page has good info but is ugly, fix it. If it has no good info, then who cares Smiley .

After chatting with the team a bit, HTML seems promising. Keep the feedback coming though.

W3bbo
The Master of Baiters

Sampy wrote:
It seems like a lot of the anti-HTML comments stem from the assumption that the WYSIWYG editor would be bad. Either it would produce crappy markup or you wouldn't use it for personal reasons. Can I take that as a "if you have a good editor, maybe HTML is okay"?

The editor in IE remains unchaged since IE6, even in IE7.

And Opera and Safari are a mixed bag, I've heard it doesn't work over there.

Point is, using a "Designer" is a-okay, provided:

It's a What You See Is What You Mean editor, not "What You Get" since that rule only applies to DTP, not the web
There is an appropriate filter in place to prevent browsers with Design-mode support (Gecko, Trident, etc) from producing convulted markup, see that link to widgEdit I posted
You provide the means to input via direct HTML editing and a nice WYSWIYM syntax, like MarkDown or MediaWiki