[Home]WysiwygWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Wiki:WysiwygWiki

A WYSIWYG Wiki is one that allows any average user to change a wiki page, without having to learn any syntax, just like any rich-text editor. Wiki adoption, along with all the advantages they have, would benefit *a lot* from that.

One step further is to completely integrate the viewing and the editing contexts. Don't you feel discouraged to correct a small typo when you have to scroll down the page, click "edit", then scroll down again searching for the typo? Wouldn't it be cool if all you had to do is make your changes right there? You could even submit your changes without leaving your paragraph!

If you have to switch to a separate editor to make your changes, then it is not WYSIWYG, because there can be differences in how the editor and the viewer shows the content.

The challenge is to do that in a web browser. It can't look like a hacked-up wiki: a rich-text editor in place of the textarea. There should be no reloading of the page necessary when going to edit mode. It should be easy to hide the edition toolbar to keep the web page light and clean. Having some kind of "edit mode" concept is still desired for concurrency concerns; a background action would request a lock from the server, and submitting the changes would release the lock, just like current wikis.

A WYSIWYG Wiki also needs to be able to show differences between two versions in a comprehensible way. It should not simply show HTML code differences, but really what happened. It could be line-oriented, or word-oriented, what matters is it has to be useful for any kind of user.

Not convinced? Have a look at http://kupu.oscom.org/

-- NicolasMarchildon

See also WikiWyg.

Related projects

Comments

I have become a fan of the WYSIWYG idea. I have been using SeedWiki for almost two years for collaboration, discussion and course content delivery in our school of architecture (the bricks and mortar kind). Maybe it is simply because of the graphic nature of our students, but it really seems to be the GUI that engages the students in ways that regular wiki does not. The ability to "personilize" their posts is important, along with the ability to upload images easily (seedwiki allows you 2 megs per user in a free account alot more if you pay a little money). I myself am not a coder, but the primary thing that I like about SeedWiki is that it employs what they call "seed widgets" that allow the user to build very sophisticated pages using a very easy-to-learn syntax. The coolest thing is that the proprietor Kenneth Tyler works closely with his account holders to continually develop the code to support our needs. I finally upgraded my account to a paid one because I felt bad getting such great support for no money. How often does that happen. Feel free to check out our site (WikiFish) to see how we use a WYSIWYG wiki. RustySmith

''I've a few problems with WYSIWYG: (1) problems with browsers that don't work (2) long load time for e. g. Java applets (3) only partial support for features (4) not really WYSIWYG (see example) (5) I always stumble upon terrible page like [1]. Can you point me to some pages you really like? -- HelmutLeitner

Hi Helmut. I agree, (1)"browsers that don't work" and the fact that there is often only (2)"partial support" for features are really two of the current "technical" short comings of ALL wikis in general. I always throw in (3)true cross-platform interoperability as the third, but that may be just a subset (super-set?) of 1 and 2. These problems are exacerbated by the added overhead that WYSIWYG requires. I think that they are the major roadblocks to wiki's going "mainstream." #2 is the one that bugs me least, as I understand that most of the code for wiki (WYSIWYG or otherwise) is written and developed by folks that all have regular day jobs/classes- implementation and support comes after users use the product, suggest changes and fixes, and then these enhancements are emplemented. In wiki, the great thing is that users can assist in these efforts. While the bugginess of all wikis can be a /little/ frustrating, the alternative is to wait for microsoft to come out with one built right in to internet explorer (let me be the first to say"gaagghh!"). I bet that one will be really nice! Ultimately, these shortcomings are not high-level concerns of mine, as that in time they will all be "fixed" ushering in a whole other series of technical problems that I will complain about. My support for WYSIWYG is really much more simple: our users like it and it subsequently reduces the initial cost of contribution to a level that is acceptable to them. Getting users to contribute is a huge part of this "game." As crazy as I think that statement is, it has proven to remain true. Whether on the first day of class when I roll out WikiFish, or in an html class when we first launch the html editor, The VERY first things the students want to do is (a)change the font (b) change the color of the font, (c) insert a picture (d) create a link to somewhere else. Once all that is done, only then can we get to work. WYSIWYG allows them to do all of that in less than 3 minutes. From a design pont of view, this level of user customization does contribute to some ugly pages, but the users know each other through font/color/size, without signatures. I personally dislike it, but it really works.

As to stumbling upon "terrible pages" yes there is a tremendous amount of junk that is created when you have a lot of contributors, and subsequently I guess that the creation of "terrible pages" can in a sense be associated with WYSIWYG wikis as they do make it seem easier for users to participate. I could point out many pages that are much more "terrible" than the one you have selected though. I do flag those for deletion, but I really try to sit on my hands for the most part. I think the real problem that an outsider from any community upon coming in contact with another is the total lack of context (be it historical or temporal) that is required to understand what might be going on. It is only through this type of context that value to anything can be assigned. The page that you reference was of subtle importance at a particular moment in time (I guess you have to trust me on that one, but if you are interested in more I can fill you in). What is really important is that wiki is ONE OF a variety of lines of communication that we employ, so an outsider is only privy to part of the dialogue. That happens here at Meatball as well, perhaps more than you know. I lurk here almost daily, but am still often lost in discerning the current mood and interest of the day, as a large part of the converstion about "important" things takes place via IRC, personal blogs, emails and even telephone conversations that are external to the dialogue here. Mind you, this is not a complaint, but rather a compliment. ALL of these things are important, and I would not suggest getting rid of them. Wiki does tend to channel these streams of collaboration into a flood upon which insiders ride the front wave, but the downside is that outsiders are left to wade around ankle deep in the upstream flotsam and jetsam trying to figure out what just happened. Maybe we should do a better job of cleaning up our messes, but it does not seem to bother regular users that much, and unfortunately daily goings-on often take precedence over historical documentation of events. Maybe the specific problem with WikiFish is that it is an open wiki that is used by a lot of people that come in face-to-face contact with each other on a daily basis, and the urge to refactor is not that high.</I>

I can point you to several types of example pages that have proven useful for a variety of reasons in a host of different contexts. First: the "Student Bill of Rights" section on the start page [2]. This one is the result of the first real online collaboration between students and faculty. [3] and [4] are two that will appear like a train wreck to an outside observer, but at the time served to air greivances outloud over a period of a few short days and subsequently led to a greater understanding of the circumstances and ultimately became the basis of much tighter lines of communication both within our department as well as across campus. Every semester we have a couple of these "blow-ups" that use to simmer under the surface for months - now rumors and partial facts come out in the open fast and can be dealt with accordingly. WYSIWYG allows anyone to fell comfortable putting in their two cents. It takes a great deal of wherewithall to stay out of the conversations, and I probably should refactor them with a little history and conclusion, however. [5] is an example of how wiki allows us to discuss policy changes openly between students, faculty and staff. It serves to augment a wider range of open "town hall-type" discussions. Finally, [6] is one example of collabortive, conference-level writing by faculty that takes place on WikiFish. The students can see (and of course even edit) the content as it is being developed by the faculty. I include this one as the example, even though it is no longer in progress, as it is (a) about wikis in school and (b)students made enough good contributions and observations over the course of the paper as to be included as co-authors. Pretty cool, I think.

In the end I will take it all: the mess, the junk, the garishness and the bugginess as long as I continue to see real-life, on-the-ground-good-stuff" coming from it. For us, WikiFish is not an endpoint, it is rather simply one of many means that allow us to get where ever it is that we are going in a more openly robust way. I will hang on to the baby, while you throw out the bathwater, ok? And I should offer a belated thanks to you Helmut (along to all of the other regulars at meatball who are reading this right now). The work that you do here is both inspiring as well as a tremendous source of knowledge and insight for those of us that are trying to make these things work as part of our day-to-day interactions with our associates, friends and colleagues. Thanks for doing so openly and freely. RustySmith

EditMe (http://www.editme.com) provides WYSIWYG Wiki hosting for cheap. Pretty cool stuff. -RC

To get a glimpse of the economic value of such a beast, have a look at http://www.ektron.com/single.cfm?doc_id=56 . -- FridemarPache

I've looked at it, in hopes of finding a WYSIWYG in-browser web editor for Word-centric organizations. It has a failing matched by many others of this ilk -- it can't cope with assigning styles to components, and especially to SPAN.

Here's a CMS intranet package that actually has a wiki function as one of its features -- http://www.infocetera.com/ -- but the whole package is a little too complex for my intended users.

I'm settling on a basic UseMod wiki with HTML enabled, with a web-site wrapper that includes a file upload button (for the FTP-challenged), and a set of IFRAME-enabled templats to display HTML-ified wiki content pages. Contributors can write in plain ascii, or wiki-syntax, or wiki-plus-HTML, depending on their level of expertise, and with "Preview" check how they're doing. It's almost like using Homesite, but without the complications.

There is now a Wiki:WysiwygWikiContest. -- fp

Now all I need is a function to put stylesheet calls in the HEAD component, to pretty things up a bit.

I think the Major Players (browser and authoring tool vendors) have completely misunderstood the core requirements of the corporate intranet setting, in their rush to proprietize the operation. -- JerryMuelver

You might be interested to have a look at http://koberg.com/ed/testContentEditable.htm (broken link, 2003-01-02). I found the hint from the author Robert Koberg on 3/20/2001 in news:microsoft.public.windows.inetexplorer.ie55.programming.dhtml.scripting and leave him a link to this editable page http://meatballwiki.org/wiki/action=edit&id=WysiwygWiki in the newsgroup to short-cut developer-contacts. -- fp

If the link above doesn't work try http://koberg.com there is only one decent link on that page that goes to http://www.livestoryboard.com/ (2003-01-06 MrWorm?)

I wrote up a quick experimental hack to add wysiwyg editing to MoinMoin -- you can try it at http://piece.stanford.edu/cgi-bin/wysimoin/moin.cgi --BrendanOConnor

Essentially what I've done is convert the QT based WYSIWYG HTML editor that exists to python and I'm in the process of integrating this with a _very_ simple wiki backend.

The simple wiki backend is running here: (REALLY doesn't do much! Barely counts)

The code for the text editor - currently called Owikipad for no real good reason, other than it's inspired by VoodooPad? has screenshots here:

And viewcvs for it is here:

-- MichaelSamuels

Possibly useful OpenSource technologies:

A [list] of Through The Web WYSIWYG Editors.

Other references of note:

Not really WYSIWYG but close: http://www.bananeweizen.de/mozilla/wikipedia/firefox_wikipedia.html

Works only for wikipedia (that means MediaWiki?)

JotSpot provides a hosted wiki which features a WYSIWYG wiki editor, as well as pre-built applications, email integration, and advanced search.
I'm seeing more and more of these companies providing hosted wiki services (or gearing up to doing so) with WYSYWIG editing, AJAX interfaces and other features which deviate from the simple kind of wiki we're all used to. Check out these:

It seems to me these 'next generation' wikis may carry the idea to more people, and achieve greater world domination, just because they are that little bit more friendly for ordinary non-technical users. They don't seem to have taken over the web just yet thought. Is this the future? -- HarryWood

Based on seeing dozens of activists, self-professed "inept" users, warming to WYSIWYG, and hearing the reports at RecentChangesCamp and WikiSym about how wiki really takes off with WYSIWYG, it is clear to me that WYSIWYG is a winner & mandatory, for the mainstream audience.

That said: There's a problem: [CommunityWiki:WysiwygIsntLinking.] The WysiWyg? I saw on PBwiki, which I believe is representative of most wiki's WYSIWYG, makes a big rig-a-marole to link, and thus there's no [CommunityWiki:LinkLanguage,] like we see here on MeatballWiki.

That is, you get a bunch of people making wiki documents with titles like: "What is a WYSIWYG Wiki?" rather than like: "WysiwygWiki" -- terms that are reusable in general. This is in part because newcomers don't know any better. But it's also because: It's so damn hard to link, even if you do know better. You have to do it very intentionally, each and every time.

So, this is a call to wiki writers, and to WYSIWYG platform writers, to think about the question of automating linking.

-- LionKimbro

I've learnt it's important to understand the use cases for the wiki before holding to some particular feature set. There has been a lot of confusion in recent years about what the use cases for a wiki are; certainly, the original use case is a niche cult. The majority use is much more conversational. Few wikis strive towards building a strong coherent corpus of text, designed for IncidentalCollaboration. -- SunirShah

I don't understand how your comment relates to mine. I can conjecture a lot of possibilities, but I don't see it.

Are you saying that people don't need to make link languages or pattern languages, and thus, it's good for them to use WysiWyg? as presently implemented?

-- LionKimbro

Here is an example from one of the two major activist communities I'm working with immediately:

That is what the Wiki seeks to do: to provide a forum within which all who resonate with the idea of the Great Turning can find each other to discuss specific interests, develop common language that will serve to generate "AHA" moments for listeners who are ready to hear the stories, and build the record of stories of positive change that demonstrate the Great Turning is happening.

[Michael Greenman, Columbus, OH]

To my knowledge, Michael Greenman is not an expert in wiki, but he is (I think) an expert in social change and activist work.

When he says, "develop common language that will serve to generate Wiki:AhHa moments for listeners who are ready to hear the stories," I think bingo.

That's wiki. In CommunityWiki we call it "[CommunityWiki:TheoryBuilding]," and we call the tool [CommunityWiki:LinkLanguage].

...and his wiki isn't giving it to him. (Just try the visual editor on the wiki.)

I agree that, for the majority of wiki, theory building and link language don't come into play. But then again, I think that the majority of wiki simply don't work, and they're served better with other tools.

He probably heard that wiki is good for making pattern languages or something, but then he goes to see it, and it's got the nice visual interface, but he can't link, and I'm not sure that someone untrained in wiki would necessarily be able to know, "what's wrong?"

-- LionKimbro

I think you are both right. SunirShah is right that it's worth looking at use cases first, before thinking about features. But in this case, the use case LiomKimbro? is looking at is people new to wikis, who heard about the benefits of wikis, but are running into roadblocks in realizing those benefits.

LionKimbro hypothesizes that a huge part of the problem is the un-intuitiveness of the WYSIWYG editors in wikis like WikiSpaces?, PBWiki, etc

I think Lion is right about this. People who don't understand the underlying concepts of writing in wiki with others, miss the point of linking, and are at a loss about how to construct pages, and how to WikiAsYouLearn?, use wiki for CommunityWiki:TheoryBuilding, etc.

I know that ChristopheDucamp, and wiki companies like Socialtext (and probably HelmutLeitner's company) have discovered that successful wiki implementation usually requires some form of WikiSchool?, to create a literacy of how to use the tool effectively. I think once people discover the wiki paradigm, and if it is adopted by the core "producers" of a group and used, wiki will be successful.

The problems with linking processes of WYSIWYG editors are real, for sure. Although, I've discovered that in some wiki engines that deploy WYSIWYG editors, like MoinMoin, PBWiki, SocialText, and to a lesser extent, DokuWiki, it is possible to activate CamelCase page name creation, so that people can type CamelCase names right into the editor.

Although, I am all for evolving a totally new way to accomplish CommunityWiki:LinkLanguage that is as easy as CamelCase. -- SamRose

Sam, do you think of automatic content table generation, where each paragraph title is an anchor, but can be exported with the whole paragraph to a separate wiki page with a single click? This could nicely play together with a WysiwygWiki. -- FridemarPache

What you describe above is possible right now in OddMuse engine, with PurpleNumbers? module,TransClusion, and FCKeditor WYSIWYG extension. Could be very useful for some groups. They experimented with PurpleNumbers? extension on CommunityWiki, but it didn't get used so much, so they agreed to shut it off.

I can see how it could be quite useful, though, if a community using a wiki makes use of it. -- SamRose

CategoryWikiTechnology CategoryUncommonWikiTechnology

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: