Also known as Wysi Wiki.
by some; see WysiwygWikiUsefulArguments
for a discussion if Wysiwyg is good for editing wikis.
- WYSIWYG Wiki Editors
- WYSIWYG HTML Text Editors - Adds a option boxes to the top or bottom of the text area.
- WYSIWYG Wiki Engines
- WYSIWYG PersonalWikis
- WYSIWYG Wiki Farms
- http://www.guiki.com/Guiki BrokenLink (18.4.04) is a very simple WysiWiki with almost all existing cross-browser editing tools for demos and testing. This has also a PhpNuke? module and is for sure one of the simplest and shortest wiki implementations around. -- ReiniUrban
- EclipseWiki is Wysiwyg in the sense that what you see is what you get but it doesn't do much text formatting. -- ChanningWalton
The design of a WYSIWYG Editor for wiki seems very doable. Here are a couple of approaches:
- WYSIWYG HTML editor -> HTML to Wiki translation -> Store in dB
- WYSIWYG Wiki editor -> database
- WYSIWYG HTML editor - Store HTML in dB (not recommended on principle)
for HTML versioning its possible to use
[Html Tidy | http://pecl.php.net/package/tidy
] and then continue on per line basis.
functionality is available in perl and python - http://esw.w3.org/topic/HtmlDiff
(needs registering without approval).
[proposal from wikipedia | http://meta.wikipedia.org/wiki/WYSIWYG_editor#HTML_to_Wiki_markup
Why harmful at all? Surely this is the Wiki ideal.
Actually, it isn't. WikiWiki is supposed to be
fast, which means fast to display, fast to read, and fast to edit and update. WYSIWYG editors are none of these. It takes time to load the code behind the editor. It takes noticably longer to display and layout the text you're editing. Hidden markup gets out of sync with what's on the screen all the damn time (JotWiki? anyone?). It takes forever to edit, because you're constantly switching between the mouse and keyboard. And finally, they don't use any standard text-area fields, which prevents the use of custom editors (e.g., Vim, via the mozex extension), thus making the user experience so unbearable that it derails your train of thought when typing. None of these things are ideal. --SamuelFalvo?
Having to use weird markup is the most uncomfortable bit about current Wikis. Accessibility isn't an issue because of keyboard shortcuts. Implementations that aren't cross-browser may be moderately harmful, but that's nothing to do with the idea of WysiwygWiki
. I too would have liked to have seen the discussion. -- DannyAyers
:-) N888-8-26 :-) Danny, believe it or not, the prevailing opinion among old-school wiki users was(is?) that learning to use a wiki (a new concept for most everyone, to think about being able to edit a webpage at all) and its archaic text-code syntax was an "intelligence test of sorts" a very specific sort of intelligence
that kept certain undesirables ("the video game generation") at bay :-) My opinion was(is) that the easier for new users you can make it, the more and wider-variety of contributors can participate and the better the results for everyone to share :-) I personally fought a wiki-battle on this point (when multiple editors jocky for space, both strongly believing their opinions, checking-up on the pages frequently, perhaps even removing or rearranging others comments to make their view more apparent to casual readers) and due to the widespread agreement on the promise of WYSIWYG wikis that I find here and now, I hope that I made a lasting contribution :-) My next project is an assembly language wikiserverOS for the ARM9 CPU in my Nokia 6600 smartphone that does nothing more than fixed-width font (basic character by character WYSIWYG!) so that it can edit its own code and evolve many different ways from there (recording, sharing and collaborating on music over short range 'whisper' wireless, for sure!) :-)
N888: There are those who disagree with you. You claim that letting all and sundry contribute creates "better ... results for everyone to share". The evidence of this wiki and many other fora is that there are many, many people who have nothing useful to say, nothing useful to contribute, but who will still insist on crapping all over the place. Sometimes they are just being a WikiPuppy, sometimes they are well-intentioned but misguided, and sometimes they are malevolent.
My direct personal experience is that requiring someone to invest some time and energy learning how to use a site means they are less likely to crap on it. Further, I'm willing to accept that some people may be turned away from this and I will lose the opportunity to learn from them. But then, if someone isn't willing to do some learning first, I think I'm going to be less likely to listen to them.
I look forward to properly implemented WYSIWYG wikis - it will be interesting to see if they are as hard to read, hard to follow, and visually assaulting as most private web sites. If they are, I doubt they'll get much high-quality traffic.
Oh, and please stop leaving your advertisements all over the place. I've removed some of them from the above - you are starting to smell of spam ...
You mean a PricklyHedge
I remember that browser agnostic and not browser agnostic solutions were presented. Even a Java beans solution. A reference to AmayaBrowser
, the W3C recommended free Wysiwyg Browser Editor with source
, adaptable to a WysiwygWiki
. Outlook Express as a Wysiwyg user interface. MicrosoftFrontPage
. Perhaps some people might wish to (re-)expand this. I see a great potential in this concept for an AllInOneWiki
For Java programmers, it might be a good idea to build on a Html browser kit:
javax.swing.text.html, which provides the class HTMLEditorKit
, supporting classes for creating HTML text editors, working online as applets or applications for joint editing.
Can someone please explain how the WYSIWYG part of WikiCpp
- How does it work in the browser?
- How does it update the server as content is changed?
Assuming you have the system requirements (VC++ or ECGS, any Web server you can configure, and IE), you could download it and see.
source for the WYSIWYG editor that used to be here:
http://www 'dot' mywebos 'dot' com/
Mywebos was one of the "dot com bubble" companies that popped. They obviously started with a huge BigDesignUpFront
coding effort, based on VendorLockin?
, and when the VentureCapitalist
s ordered everyone to start turning a profit or eject they took the second option.
to track the font attributes and such of an entire page.
packs the current HTML source of the inner page into a "hidden" <input> tag, and POSTs its form back to the server. This reads the field and writes a file.
promises they are working on a Netscape version of their server-side desktop metaphor, so we'll see what we can "borrow" for WikiCpp
v. 2 when they do! "Browser agnostic", however, will be a long way away without a centralized fix like Java. -- PhlIp
Ok, then programmers with some minutes spare time might want to start a "Browser gnostic" Wysiwyg Wiki with Microsoft's DHTM edit control
, usable from Script/VB/C++:
for a realization with JScript. -- FridemarPache
is using ActiveEdit
, a WYSIGWYG control as an optional page editor. Seems to work fine. We had to fiddle a little with the page parsing so that Wiki Names would still create pages. It works only for IE, but users seem to really like it.
That is the approach (I think) used by WebPageInPlaceEdits
- the ultimate I would look for is:
- a wysiwyg wiki with different layers to edit online: html, txt, xml, xsd, xslt/xsl-fo, owl/triple
- the nearest I could find by now is the free xmlspy browser edition (which is not really a wiki, works on local files)
- preferred source in java, forth
- could think of a hybrid xulplugin solution also
- just to name the thing: VisOwlWiki - since this is the highest abstraction layer
- probably nonexistent by now, time to do it! :-)
- I really appreciate ANY feedback on this idea
- prj expected to be launched soon, but not too soon due to lack of time
I have PhpWiki
working on my server for posting up documentation. The only thing is that my wife hates the idea of using *, !, and # signs to start lines. She would prefer to push the button. For people like this, the WYSIWYG is the most accessible. BTW, my grandmother has no problem with wiki syntax. -- TD
I started a SourceForge
project to help generate some demos of what is possible. I think when people actually see the editors, they will think "that's a lot easier that what we are doing now." Right now, I think people think the dB storage must include HTML. Not true, we can translate the other way too... Also, people who would like to keep with the current system of wiki text can keep intering [entering?
] that way.
wysiwiki.com appears to have been acquired by some company, if it ever referred to a RealWiki
. -- RohanTalip?