VisibleMarkup

This is a solution for WYSIWYG editing, alternative to JavaScript-based, complicated interactive editors. Instead of making the edit mode look similar to the presented page, the presentation of the page can be made similar to the raw text of the page.

The idea is to not remove the “markup characters”, like “[[” or “*” when rendering the page to html, but style them so that they are visible, but not obtrusive instead (ex. make them light gray on a white page). Of course that’s not possible with all markup rules (links with an alternate text would be hard), but at least a limited subset of commonly used markup can be treated this way.

This has several benefits:

There are also some disadvantages:

This is an idea I had some time ago. As far as I know, it was only tried on my toy wiki engine, but I think it might have some potential, especially in teaching new users how to wiki. What do you think?

Gmail uses a similar idea in it’s chat thing. You can put * around a word and they will first be displayed normally, then after a fraction of a second, they will disappear and the word will be bold. Smileys are also replaced this way, and in addition, the smiley is an animated gif that does the transformation from the ascii “sideways” form to the coloured, upright form. And if you pass your mouse over it, it does the transition again, so you can see how to create it. Nifty.

This seems to align with WikiNature:

Output should suggest the input required.

I think that WikiWords are so popular (despite many bad things about them) precisely because they are WYSIWYG in the same way the VisibleMarkup is. Also the well-accepted markup for bullet lists is as close to their rendered look as possible (at least for the 1st level lists, but they are the most common). I wonder what’s the reason behind using “’” for ephasis though, when there is a well-accepted standard of using asterisks, both in e-mail and news. I experimented a little with the idea on Yarnball Wiki.

is there a possibility to tell the browser to replace a section with an editable raw text, if you click in (the left margin of) this section?

  • would look
    • like
      • this
[new:sigi:2006-08-26 03:12 UTC]
is there a possibility to tell the browser to replace a section with an *editable* raw text,
if you click in (the left margin of) this section?
* would look
** like
*** _this_

This reminds me of the “pretty printing” formatters for most programming languages. They also are careful to preserve every marking character of the original source code.

I like it. Current trends seem to be towards the production of ever-more-complex items. So people are discouraged from creating anything, because hand-made items look so very primitive compared to store-bought plastic-wrapped versions.

I am all in favor of anything that makes it easier for people to learn how to do it themselves – even when the result may not appear as polished and “professional” as some of the alternatives.

Sometimes primitive-appearing items function better than hi-tech alternatives. For example: Morse code is faster than text messaging. Jotting things down on a Hipster PAA is faster than entering them into an electronic PDA. Whole-wheat bread has more vitamins and fiber than white bread. Etc.

Um… Forgive me for launching into an unrelated rant. Again. :-).

@sigi – yes, it’s basically section editing, with the preview of the rest of document displayed both over and under the edit box. As such, it suffers all technical difficulties with section editing – similar to those of PurpleNumbers.

I think the best solution would be to have syntax highlighting and clickable links directly in the textarea. Of course that’s not possible with plain textareas, but can be done using the same technology as the “WYSIWYG” javascript editors. Only much simplier, as you don’t want all the MS Word features in it.

But this is all bells and whistles, as with VisibleMarkup you are not relying on technology to do WYSIWYG – you have it also in Lynx.

perhaps we may design quite a new wiki markup language, which only consists of square brackets (good for high lightning) . each page has a list with the meaning of the brackets (same sequence as in the page) . if you click on a bracket, you can edit the content of this bracket . if you are in the edit modus and you click on a bracket, a little box opens with the cursor in it and you can define the markup function of the bracket .

then the example above would look like

[[sigi]is there a possibility to tell the browser to replace a section with an [editable] raw text,
if you click in (the left margin of) this section?[would look[like[this]]]]
list: [new [header [bold [list [list [list & underlined

or in pretty printing (the markup-ed version is quite the same)

[[sigi]
 is there a possibility to tell the browser to replace
 a section with an [editable] raw text, if you click in
 (the left margin of) this section?
  [would look
   [like
    [this]]]]

What a horrible user interface, full of modes. Looks almost as bad as Lisp ;).

But jokes aside, using different syntax for different elements makes it simplier both for the computer to highlight, and for the human to read/write. We don’t need the generality of Lisp in wiki markup – and this generality comes at a cost. So why should we pay for it if we don’t need it?

But personally, I like the approach of some experimental wiki I saw (can’t recall the name now) in which you don’t put the urls in the text, but put a small marker, like [1] in there, and fill in the urls in a separate form. This allows you to focus on writing, not looking for the page address in the middle of thougt.

ya! True. This is a major drawback on wiki-witing. You “think” edit mode. You take ages to fill in url’s before continuing a thought. With EditableTitles you would fix the links in the preview. Afterwards.

LocalNames are even better solution of this problem.

We do have CommunityLocalNames on this site…

Not sure now that this page really fits the topic of this wiki, I think will ultimately move it all to wiki features wiki.

Just for the record, JSPwiki has a java-applet-based editor with syntax higlighting, and Zim desktop wiki (standalone application) uses a similar technique of replacing certain markup with rendered equivalents as you type (doesn’t make the markup visible though).

Have you thought about making the stars in indented lists visible, somehow? Perhaps make the ones leading up to the final ones really faint, and using some CSS-foo to make bullet points display like the stars?

Though I’m not sure if it’s really possible…

Bullet points w/ images… [1] If you want to get around graphic content, perhaps there’s a way to smoosh in an XMB or something?

Not sure how to do the multiple stars, for multiple levels of indentation.

Though, here’s an idea: Make an icon that is two stars, overlapping, for two levels of depth, and then an icon that is three stars, overlapping, for three levels of depth, ..?

This page is quite welcome on WikiFeatures, though, by my book, at least. We have been known to talk about wiki, and wiki features here, for some time: See the ancient and venerable CategoryWikiTechnology, which I would categorize this page as.

Making the bullets into stars is certainly possible with CSS2, not with CSS1 thought (at least not without using graphics).

The followoing style snippet should do the trick for 3 levels of nesting:

    ul > li:before {display:marker;content: "*"}
    ul ul > li:before {content:"**"}
    ul ul ul > li:before {content:"***"}

The example is available (temporarily only) at http://sheep.art.pl/misc/asterisks.html (in addition it has the asterisks styled somewhat and the default list bullets removed).

Here’s how I started to implement the suggestions above: The CSS is on the page visible-markup.css which you can edit.

Point your browser to this URL from hell.

Here’s what it does:

  1. It tells your browser to visit VisibleMarkup.
  2. It tells Oddmuse to serve you our default CSS, green.css
  3. It tells Oddmuse to also serve you the raw text of visible-markup.css, telling it to use the text/css MIME type, since Firefox will not use it otherwise.
  4. It tells Oddmuse to use the visible class for the body tag, allow us to write the visible markup CSS as a theme.

The theme element is there so that we can eventually merge visible-markup.css with green.css. This is purely a preference of mine, to have everything in the same file.

Actually, if you look at green.css, you’ll see several themes in there already. :)

And here’s your reset link!

Too bad I can’t figure out how to undo the indentation of nested list items. :)

It doesn’t need to be so spartan, some syntax highlighting helps greatly.

Good point regarding the addition of color! Will you copy your CSS over to visible-markup.css?

I’m experimenting with markup that is more noticeable than normal text, by using contrasting colours and a larger font for the symbols. At first I though this was a subtle difference to VisibleMarkup, where the markup rules are ‘visible though not obtrusive’.

I’m starting to realise that it’s motivated by very different principles, so I think it would benefit from a different name: ConspicuousMarkup?.

It seems to me that more noticeable or less noticeable than normal text… it’s still Visible Markup.

Keep the discussion on this page. Put existing content in sections, if you need to. Put your new stuff in a new section. Keep comonalities in the page introduction.

Yes the implementation is similar, but I see ConspicuousMarkup? as a wider pattern not confined to WYSIWYG editing.

ConspicuousMarkup? need not be visible, because it could be indicated by touch, with braille, or perhaps audibly, even outside of computing, and in printed documents, for people who’d never usually work with markup languages.

Some benefits of popularising markup are:

  • it enables us to make community technology easier to grok overall, which dramatically changes relationships between people; and
  • it can be used in hand-written text too, expressing a desire for the readers to copy and remix, and to urge them (discretely) to get involved online.

Perhaps a mind map would be better here, but these are some thoughts:

  • Intuitively, I think greyed-out symbols will have the effect of subtle noise that is hard to filter out. So the non-obtrusive markup might actually be more distracting than big high-contrast symbols, because we’ll unconsciously know that they’re coming in advance (as we read sequences of parallel characters) and we’ll just read straight past them – are there any experts on readability who could verify or quash this dubious fact?
  • When markup symbols are presented they can make the text appear unfinished, and when they give a distinctive impression this is an advantage! The scaffolding is prominently exposed as a clear invitation to keep working on the text.
  • By applying ConspicuousMarkup?, we would make the unusual symbols look dramatic, stylish and never obscured.
  • To protect people from nasty surprises, I suggest this approach to VisibleMarkup: When switching from editing to reading mode, never conceal the markup or change the reading-order, but insert information and formatting in expected locations. During reading mode, give a visual indication of the parts that will be removed when editing (with distinctive colour, background or border), so people quickly understand which parts are automatically inserted.
  • If we aim to use markup sparingly, then making it very conspicuous should deter us from excessive use.
  • When ConspicuousMarkup? is used on a wiki, the markup rules that cause confusion when switching between editing/reading should be presented as plain text, and not interpreted. This is less strict than PlainTextWiki, because it assumes that people can handle changes in colour and whitespace, and surely embedded graphics, audio and video are important for expression?
  • When the markup is made brighter and colourful, it must slightly change the way we use it to express ourselves, so perhaps we need standards for presentation too. I suspect PlainTextWiki is a bit too aesthetic for most people, and that communities need technology that is a pleasure to use.
  • URLs are still not designed to be human readable, so they seem to be the ugliest part of VisibleMarkup/ConspicuousMarkup?. Since they are not intended to be read, it must be safe to subdue them with very low-contrast/small font, as long as there are obvious ways to select and inspect them.

So on the implementation side, I’m experimenting with bright/high-contrast colours and larger fonts to display the markup. Line-spacing can be increased to improve readability and accommodate larger symbols within regularly spaced baselines. The external URLs can appear small, and greyed-out until hovered with the mouse. I haven’t tried to achieve the effects with CSS alone though. It might help if OddWiki produced more div sections to support older browsers, but VisibleMarkup for IE will require a lot of non-semantic HTML :(

Some slightly different conventions might also be needed for VisibleMarkup language. Fortunately, Creole 1.0 is nearly ideal, and will become more intuitive and readable if we just support the WikiCreole:AlternateLinkSyntaxProposal?.

Below is an example in standard Creole. Can you briskly read a list like this?

  * [[http://www.youtube.com/watch?v=-dnL00TdmLY | Wikis in plain english]]
  * [[http://www.scribd.com/doc/2340879/A-Wiki-Is-Like-A-Room | An analysis of wikis]]
  * [[http://www.scribd.com/doc/16161185/Collaborating-on-the-Internet-With-a-Student-Wiki | Some personal ideas about wiki]]
  * [[http://www.art.co.uk/products/p12101221-sa-i1526025/eve-shpritser-connections-i.htm?sorig=cat&sorigid=1822&dimvals=1822&ui=94d3dedf916d4fd29899f76e43657dfe | A website that uses really messy links]]

This is the alternative in VisualMarkup?. Is it better?

  * [[Wikis in plain english -> http://www.youtube.com/watch?v=-dnL00TdmLY]]
  * [[An analysis of wikis -> http://www.scribd.com/doc/2340879/A-Wiki-Is-Like-A-Room]]
  * [[Some personal ideas about wiki -> http://www.scribd.com/doc/16161185/Collaborating-on-the-Internet-With-a-Student-Wiki]]
  * [[A website that uses really messy links -> http://www.art.co.uk/products/p12101221-sa-i1526025/eve-shpritser-connections-i.htm?sorig=cat&sorigid=1822&dimvals=1822&ui=94d3dedf916d4fd29899f76e43657dfe]

I believe those symbols ‘->’ will be displayed as ‘<-’ in a right-to-left font, so this should work intuitively in all languages.

Another benefit of the ‘->’ syntax is that it might actually make local links on VisibleWiki? more readable than conventional wiki, because readers will be less surprised when a link takes them to a page with a different title. The reader will see this text:

  [[Link title -> PageTitle]]

So which side of that ‘->’ do you think should be the hyperlink?

It seems likely authors will do things like this:

  [[The following article is interesting -> VisibleMarkup]]
  [[Ceci n'est pas une pipe -> Wikipedia:Pipe_(character)]]

So a benefit of this is that it breaks up the different aspects of a link. I saw this in ‘Are Wikis Usable?’ by Désilets, Paquet & Vinson (can somebody turn this into a blockquote btw?):

  [This study] identified types of usability issues that
  were encountered by our subjects. The most important type had to
  do with the creation and management of links to pages and
  images, and it accounted for 49% of all problems and for 79% of
  problems with catastrophic consequences.
  It is worth noting that many of the Link creation and
  management problems seemed to be caused by confusion in the
  subject’s mind between different concepts related to links,
  namely: the link itself, its anchor text (i.e. text displayed for the
  link), the name of the page it currently points to, and the actual
  page that lies at the other end of the link. This is very similar to
  the confusion that novice C programmers experience when they
  first start working with pointers [23], and is best illustrated by an
  example. Suppose a subject edits a page and changes a WikiWord
  from old_wikiword to modified_wikiword. We observed that
  in some cases, the subject would correctly expect the wiki to to
  reorient the link to point at page modified_wikiword, but
  keep page old_wikiword intact. But in other cases, then
  expected the wiki to simply change the anchor text to modified
  wikiword, but leave the link pointing at page old_wikiword. In
  other cases still, the subject would expect the wiki to actually
  rename page old_wikiword to modified_wikiword and to
  make the link point to that renamed page. Note that we observed
  these different expectations not only between different subjects,
  but sometimes for a same subject at different points in time.
  The confusion between anchor text and name of the target page
  also often manifested itself in a different guise. Often, subjects
  would type extraneous action words in the WikiWord for a link.
  For example, in trying to create a link to a page the_dungeon,
  they might type return_to_the_dungeon instead of return
  to the_dungeon.

Logically then, we can leave the link title blank:

  [[->AnotherPage]]

By adopting conventions for presentation, the alternative syntax would also be useful for positioning images relative to the text:

  {{An image title presented before the image->image.jpg}}
  {{image.jpg<-An image caption presented after the image}}

Which could be supported along with the Creole standard:

  {{image.jpg|An image caption presented after the image}}

(On a slight tangent, another advantage of this alternative link syntax is that the symbols ‘->’ are much easier to explain to beginners than the pipe ‘|’, especially on many keyboards where the symbol looks identical to a capital ‘i’, and you are expected to press the key with a broken bar ‘¦’, which should really be a different character, shouldn’t it? On UK keyboards the pipe/broken-bar/shift+alt-graph behaviour is even more confusing, because it differs between operating systems and even keyboard-drivers! So I think the case for the alternative link syntax is particularly compelling in ConspicuousMarkup?, even if it does extend current wiki standards.)

I suspect that VisibleMarkup+ConspicuousMarkup? could serve a useful role in teaching and community projects, and I’m keen to test this suspicion.

My main question to Alex and Radomir is this: are you suggesting (with the CSS approach) that VisibleMarkup is purely a change of presentation that can be conveniently disabled? In ConspicuousMarkup? I propose to put the markup rules positively in-yer-face – as a means of actively involving and affecting the audiences, beyond an isolated learning environment.

Sorry for not responding earlier, for some reason my feed reader is not picking up the changes in RSS feed of this wiki. Marcus, you are touching a lot of different parts at once, let me try to answer to some of them, starting with your last question.

The distinction between “content” and “presentation” is completely artificial and comes from incidental properties of the implementation, a little like the distinction between foreground and background on a picture – depends on what you are concentrating on. We are experimenting with CSS because that’s the easiest way to try it without breaking this wiki. Ideas hanging in the air are worthless until tested – and it’s best to test them in realistic environment, like a living wiki. On the other hand, you don’t want to kill the wiki with a misguided experiment. An opt-in stylesheet seems to be a good compromise, even if it only works on non-broken web browsers.

About changes to link syntax: it has been discussed ad nauseam at the WikiCreole wiki. As far as I know nobody decided to do any experiment to prove or disprove various assertions, so it’s all just handwaving and personal preference for me. On the other and I find it very interesting how making the markup visible makes you care more about how good it is! I think that people will always have problems with links, simply because links are difficult to understand, no matter what markup is being used for them.

About ease of reading with all the markup getting in the way: it is a problem when there is excessive markup. But it is a problem anyways even if the excessive markup is not visible, because it’s there to have some effect, and each change in the font face, size, spacing, ornamentation, etc. has deteriorating impact on the ease of reading. According to this article on how we read, we mostly look at the length of words, and read several words at a time. If each word is somehow different, it’s hard to develop a consistent metric by which our eyes can measure and guess the words. I think it’s important to make the markup different from the regular text – both to show its special meaning, and to make it easier to filter out. Whether you make it more or less prominent depends on whether you want to optimize for reading or searching, I think.

That’s very interesting Radomir. Yes ‘model’ and ‘presentation’ are artificial (I think there are good reasons to avoid the word ‘content’) but I find them useful abstractions. I’ve used them for as long as I can remember – which probably says more about my memory than my experience :) Anyway, I am hacking a mockup page in static html for now to see what ConspicuousMarkup? might look like (including in broken-browsers), and I’ll upload it this week.

For links, I’m very interested in the "confusion..between..the link itself, its anchor text (i.e. text displayed for the link), the name of the page it currently points to, and the actual page that lies at the other end of the link". VisibleMarkup exposes this to some extent and if we separate the page title from the URL slug (page name) it might help avoid several major problems described in the usability paper above. Is there a page on CommunityWiki that discusses this separation?

Radomir, you may be right about making markup less prominent for grey printed text – this would save a little ink as well – but I think differentiating symbols with colour will make them easier to ignore on-screen – we’ll see. It seems inevitable that VisualMarkup? will reduce readability to a degree, so I guess we’ll use soft technology to minimise markup when needed, but I think that readability is not the only ideal. We can also be expressive using the markup to some extent.

What you say about ornamentation is interesting, because it may help us read past ugly things like URLs. I’ll try adding soft borders to them.

I did try rendering URLs with a smaller font (and with smaller letter-spacing) in some styles (for example the one used on the WikiFeatures wiki), and I must say it works for me: they have smaller chance of wrapping around or sticking out of the page, distrub the text less and people who are used to reading urls are usually also used to just hovering the cursor on the links and looking at the status bar/tooltip. I actually add a tooltip with the link’s target to the links in Hatta too.

Aside from that, going back to the hypertext and why it is difficult to grasp – I don’t think it’s the presentation of links that is troublesome. It’s the concept of a multi-dimensioned interlinked abstract lattice that the pages form – not only it’s complicated, requiring abstract thinking, but it’s also invisible!

The original wiki, with its WikiWords actually made some things easier. You have a 1-1 mapping between the links and the pages: everywhere where you see the page’s name, clicking on it takes you to that page. With the exception of the actual page title, which I think is a fault, but that’s a small exception. Not only the link targets are clearly visible, but they are also simple: just the page name, no unnecessary technical information such as protocol, name of the server and organization owning it, information about internal server organization (path) and technology being used (file extension) – just the relevant information, the page title.

Now, creating the pages is often considered difficult and confusing: make a link to the page first, then click on it and edit it. But I blame the way the test are prepared. You usually have something like “test how easily the users can create the page”, then you say to the user “ok, now create a page, any page”. That’s not how wikis were supposed to work.

Define external redirect: AlternateLinkSyntaxProposal ConspicuousMarkup VisualMarkup VisibleWiki

EditNearLinks: WikiWords WikiWord JavaScript

Languages: