Can anyone tell me if there is already in existence an editor program that enables one to edit mediawiki pages in a "what you see is what you get" mode (editing for dummies)? I have an associate who says he could build such a program quite easily. I'm thinking, if it's so easy why hasn't it been done; surely it has been done; if so, where? Thanks Sterling D. Allan Executive Director, PES Network Inc http://pureenergysystems.com http://freeenergynews.com http://peswiki.com http://pesn.com

On Sun, 13 Mar 2005 19:49:49 +0000, Tony Linde <tony(a)linde.me.uk> wrote: The plog4u eclipse editor plugin isn't a direct "what you see is what you get" editor. It's focusing on editing Wikipedia articles offline (through downloading and uploading articles) and creating PDF documents from the articles. The built-in "html preview browser" refreshs it's view if you save the edited text to the local file system and let "you see what you get". -- Axel Kramer http://www.phpeclipse.de - PHP Eclipse Plugin http://www.plog4u.org - Wikipedia Eclipse Plugin

I would not go quite so far as Paul, but I think there are better places to put resources than WYSIWYG editing. The beauty of Wiki is it is collaborative. Some people have ideas they don't articulate well. Some people are expert wordsmiths, but don't necessarily have ideas. Some people are editors and copyreaders. Some people delight in formatting arcana. The downside of WYSIWYG is Bad Design. Now everyone with a pirated copy of Word is a publisher -- NOT! I've been through various flavors of roff, TeX, Merganthalier and Quikset typesetting codes, HTML, and many others. I think the beauty of formatting code is it makes you think. Because of the "high entry fee" (aka "dumbass tax"), you spend a bit more time figuring out how things are going to go together, and it shows in the results. That's one of the reasons I Don't Do Word. Most Word docs are atrocious, with multiple spaces used for indentation and multiple line feeds used for vertical spacing. Someone sends me a Word document, and by the time my translators get through with it, it needs to be re-formatted anyway. I avoid hurting anyone's feelings that I re-formatted their "masterpiece" by explaining that I don't have Word, and my translation software "must have messed it up." :-) It's not that WYSIWYG doesn't have a place. But let's just keep it there, okay? On 14 Mar 2005, at 00:28, Paul Johnson wrote: :::: Some call it vision; some call it temporal lobe epilepsy. :::: Jan Steinman <http://www.Bytesmiths.com>

On Mon, 14 Mar 2005 11:59:47 -0700, Sterling D. Allan wrote: Or, say, for my mother, who is likewise not going to learn wiki syntax any time soon. Just opening an existing page to make a typo edit is slightly baffling to her. Especially since by default she doesn't have section-editing turned on, and figuring out how to scroll to where you were in the viewable document is... non-trivial. When I ask regular readers why they don't contribute, the most common response is they're not experts in anything, they don't feel they have anything to add. A close runner-up is that they tried once but got frustrated; they're not sure where to add an idea, or how the syntax works; or they don't have time. The clearer and more intuitive the editing interface, the faster the learning curve, and the fewer people who will think they don't have time to figure it out. -- +sj+

On Mon, 14 Mar 2005 14:08:38 -0700, Sterling D. Allan &lt;sterlingda(a)pureenergysystems.com&gt; wrote: Well, *extremely* early on in the development of wiki software, the choice was made to favour *simplicity*. Ward Cunningham called it "wiki wiki", meaning quick, and that's what it was - a barebones structure, that "just worked", without too much fuss. To "go in the WYSIWYG direction" you have to first create some underlying machine-readable code [you have to store it somehow], and then make some kind of human graphical interface that produces that code. So if you're going for simplicity, human-oriented code is the way to go, because you can just dispense with the last step - it's not so much "going in the code direction" as "not going as far as the crossroads". Simplicity also meant that there wasn't really much to learn - mostly, you were just typing text with the odd CamelCaseLinkPattern in. Plus, of course, it was never meant to be "for as wide as possible an audience" - it was a kind of collabourative notebook for those interested enough to take part, and most of the people who were involved spent more time using their wikis to discuss things than developing them to be flashy and user-friendly. So my guess is that for the first, slow, wave of wikis the syntax really wasn't that big a problem. Bear in mind also that the original wiki dates all the way back to 1995, when the idea of a reliable in-browser WYSIWYG editor would probably have seemed like asking for the moon on a stick [1]. And, AIUI, MediaWiki is only 2-and-a-half steps removed from that original wiki, with a distinct feel of 'evolution' [2] so it's maybe not surprising that although people have started looking at the WYSIWYG end of things, it's tended to be in more "revolutionary" takes on the wiki concept. That's not to say the time hasn't come to WYSIWYGify MediaWiki - although the limited JavaScript editting toolbar we now have demonstrates just how cleverly something has to work to be "idiot proof" (just look around for newbies inserting text like '''Bold text''' and [[example link]]...) - but I think the claim that a decision, bad or otherwise, was taken in the past is somewhat naive. Notes: ===== [1] I couldn't resist referencing this: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/moon-on-stick.ht… [2] I believe the progression goes: WikiWikiWeb --> UseModWiki (a "WikiClone"; the one WikiPedia started using) --> "Phase 2 Wikipedia" (UseMod rewritten in PHP with bells on) --> MediaWiki ("Phase 3") -- Rowan Collins BSc [IMSoP]

On 14 Mar 2005, at 13:53, Rowan Collins wrote: So let people enter plain text! What's wrong with that? Why must EVERY USER be a graphic artist? (I assure you, they are not!) With the exception of [[square brackets]] instead of CamelCase, one can use MediaWiki in pretty much the same way as one uses c2.com, no? The only exception I can bring to mind is if unsophisticated users are interested in correcting typos in heavily-marked-up text. And if that's the case, nothing short of a full WYSIWYG authoring environment is going to do the job. (Those who are seeking "full WYSIWYG", take a look at GoLive or Dreamweaver. Do you really want to turn THAT loose on your unsophisticated users?) Page authors should either assume THEY are going to be doing 95% of the maintenance, on they should KISS the complications goodbye, and make it inviting for less sophisticated users. :::: Sell your cleverness, and purchase bewilderment -- Rumi :::: Jan Steinman <http://www.Bytesmiths.com/Item/99-6313-15>

it's not difficult if you know how. I use BBEdit and Applescript to edit pages. I have complete non-geeks editing pages happily. How can wiki text get 'heavily marked up'? anyway? It's not that bad, however bad it is (we're not talking HTML, are we?) WYSIWYG is usually very poor under the hood - I don't even use Word Processors any more. Trying to do some kind of Dreamweaver would be really over the top! As for Word import, it hasn't worked with any other Word Processor properly (believe me, I've tried...) so what's the point?

Is there any cheatsheet on wiki-tags, easily printable sheet with all the wiki-tags.. so that newbies like me can print it and keep it aside while working on wiki's ? TIA, -=skillz=-

Jason Davies wrote: http://meta.wikimedia.org/wiki/Help:Editing is pretty much what you want ;-) I suppose it would be useful to do it up as a single page printable PDF or similar, to stick on the wall or whatever. - d.

While they don't cover everything, I re-wrote some of the help tables into what I think is a bit more readable form. See http://wolfandturtle.net/Indigo/index.php/Help:Contents mostly the 'Editing and formating' page. Myria

Quoting Evan Prodromou, from the post of Wed, 16 Mar: I think those were mentioned in the beginning of this thread as being problematic when crossing platforms. indeed, maybe a Java implementation will be the most standard (won't be as quick and flexible as a Flash implementation, but will run on more platforms I guess) -- Marzipan model Ira Abramov http://ira.abramov.org/email/

My user base ranges from wiki-experts to computer novices. The novices are usually unable to grasp the idea of a markup language and give up before making contributions. On the other hand, some of my wiki-experts are frustrated with YAWML--Yet Another Wiki Markup Language. It's nice to live in one wiki world, but it's not always possible and the local markup dialects seem unending. Both extremes and many users in between would benefit from a more direct editing approach that avoided the markup nature of current wikis. Even a limited set of capabilities would provide scaffolding for the novice and a welcome relief to the expert. The current markup can be available for those who want to add complexity or elegance. This issue is probably not a MediaWiki issue. Supporting Wikipedia and family is obviously job #1, and it seems well-served by the current structure. But there are many of us who have borrowed the MediaWiki tool (for all it's benefits) and applied it to other contexts. If WE want different editing capabilities, then WE will probably need to step up to the plate and make it happen. Con Rodi Center for Human-Computer Interaction Virginia Tech On Mar 14, 2005, at 1:59 PM, Sterling D. Allan wrote:

Quoting Sterling D. Allan, from the post of Mon, 14 Mar: ok, this is the third thread to open on the subject in two days. I feel like this is starting to look like a trolling frenzy. Features like that are hard to implement, as people posted here. If you want your dream - build it and we will come. now let's make room on the list for other stuff. (one tiny final note, I agree with Jan's view that a tool with more options does not necessarily cause users to start using it right. I prefer non-techie people to post informative articles, even if badly phrased or stylized and have other wikipedians fix it up for them, then have them avoid posting altogether. -- Bundle of joy Ira Abramov http://ira.abramov.org/email/

Jason Davies wrote: That's because, as any Wikipedia wikiholic knows, it's *utterly compelling*. That's excellent! What are the copyright terms? GFDL or something else? - d.

On Mon, Mar 14, 2005 at 10:19:46AM -0800, Jan Steinman wrote: I agree almost completely with you ... the problem comes with tables where the text layout becomes complicated and where a WYSIWYG interface would be useful. Twiki for example has a great add-in via a %TABLE command that allows for the formatting of the table (header, footer, alternate rows) to be defined without having to put the code in the actual table. I have tried numerous open source packages and none of them allow for easy tables in a wiki -- this is what is missing for the masses. Regards James

Hi A new plog4u version 1.1.5 is available here * http://prdownloads.sourceforge.net/plog4u/plog4u.community_tools_1.1.5.bin.… I must admit that the greatest change in the latest release is the move to a new sf.net project page: * http://sf.net/projects/plog4u Please submit your bugs and features on this new project page. Anyone who likes to help in the development of the wikipedia editor plugin is welcomed. Description of a new configuration option: * http://www.plog4u.org/index.php/Using_Eclipse_Wikipedia_Editor:Configuratio… -- Axel Kramer http://www.phpeclipse.de - PHP Eclipse Plugin http://www.plog4u.org - Wikipedia Eclipse Plugin

On Sun, 13 Mar 2005 16:03:36 -0500, Evan Prodromou &lt;evan(a)bad.dynu.ca&gt; wrote: It might also be worth looking at http://meta.wikimedia.org/wiki/Alternative_parsers and http://en.wikipedia.org/wiki/Wikipedia:Tools for some of the things people *have* already coded. From memory, the only thing that comes anywhere close is the Eclipse plugin [as linked by Tony] - it's not wysiwyg, but I believe it does "understand" wikitext natively, and render it live, as well as interfacing with the server, so it's possibly only that one step away (I haven't actually used it by the way, just read about it). -- Rowan Collins BSc [IMSoP]