Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Foundation

Big problem to solve: good WYSIWYG on WMF wikis

 

 

First page Previous page 1 2 Next page Last page  View All Wikipedia foundation RSS feed   Index | Next | Previous | View Threaded


dgerard at gmail

Dec 28, 2010, 3:50 AM

Post #1 of 28 (2978 views)
Permalink
Big problem to solve: good WYSIWYG on WMF wikis

[crossposted to foundation-l and wikitech-l]


"There has to be a vision though, of something better. Maybe something
that is an actual wiki, quick and easy, rather than the template
coding hell Wikipedia's turned into." - something Fred Bauder just
said on wikien-l.


Our current markup is one of our biggest barriers to participation.

AIUI, edit rates are about half what they were in 2005, even as our
fame has gone from "popular" through "famous" to "part of the
structure of the world." I submit that this is not a good or healthy
thing in any way and needs fixing.

People who can handle wikitext really just do not understand how
offputting the computer guacamole is to people who can cope with text
they can see.

We know this is a problem; WYSIWYG that works is something that's been
wanted here forever. There are various hideous technical nightmares in
its way, that make this a big and hairy problem, of the sort where the
hair has hair.

However, I submit that it's important enough we need to attack it with
actual resources anyway.


This is just one data point, where a Canadian government office got
*EIGHT TIMES* the participation in their intranet wiki by putting in a
(heavily locally patched) copy of FCKeditor:


http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html

"I have to disagree with you given my experience. In one government
department where MediaWiki was installed we saw the active user base
spike from about 1000 users to about 8000 users within a month of having
enabled FCKeditor. FCKeditor definitely has it's warts, but it very
closely matches the experience non-technical people have gotten used to
while using Word or WordPerfect. Leveraging skills people already have
cuts down on training costs and allows them to be productive almost
immediately."

http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html

"Since a plethora of intelligent people with no desire to learn WikiCode
can now add content, the quality of posts has been in line with the
adoption of wiki use by these people. Thus one would say it has gone up.

"In the beginning there were some hard core users that learned WikiCode,
for the most part they have indicated that when the WYSIWYG fails, they
are able to switch to WikiCode mode to address the problem. This usually
occurs with complex table nesting which is something that few of the
users do anyways. Most document layouts are kept simple. Additionally,
we have a multilingual english/french wiki. As a result the browser
spell-check is insufficient for the most part (not to mention it has
issues with WikiCode). To address this a second spellcheck button was
added to the interface so that both english and french spellcheck could
be available within the same interface (via aspell backend)."


So, the payoffs could be ridiculously huge: eight times the number of
smart and knowledgeable people even being able to *fix typos* on
material they care about.

Here are some problems. (Off the top of my head; please do add more,
all you can think of.)


- The problem:

* Fidelity with the existing body of wikitext. No conversion flag day.
The current body exploits every possible edge case in the regular
expression guacamole we call a "parser". Tim said a few years ago that
any solution has to account for the existing body of text.

* Two-way fidelity. Those who know wikitext will demand to keep it and
will bitterly resist any attempt to take it away from them.

* FCKeditor (now CKeditor) in MediaWiki is all but unmaintained.

* There is no specification for wikitext. Well, there almost is -
compiled as C, it runs a bit slower than the existing PHP compiler.
But it's a start!
http://lists.wikimedia.org/pipermail/wikitext-l/2010-August/000318.html


- Attempting to solve it:

* The best brains around Wikipedia, MediaWiki and WMF have dashed
their foreheads against this problem for at least the past five years
and have got *nowhere*. Tim has a whole section in the SVN repository
for "new parser attempts". Sheer brilliance isn't going to solve this
one.

* Tim doesn't scale. Most of our other technical people don't scale.
*We have no resources and still run on almost nothing*.

($14m might sound like enough money to run a popular website, but for
comparison, I work as a sysadmin at a tiny, tiny publishing company
with more money and staff just in our department than that to do
*almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
efficient organisation.)


- Other attempts:

* Starting from a clear field makes it ridiculously easy. The
government example quoted above is one. Wikia wrote a good WYSIWYG
that works really nicely on new wikis (I'm speaking here as an
experienced wikitext user who happily fixes random typos on Wikia). Of
course, I noted that we can't start from a clear field - we have an
existing body of wikitext.


So, specification of the problem:

* We need good WYSIWYG. The government example suggests that a simple
word-processor-like interface would be enough to give tremendous
results.
* It needs two-way fidelity with almost all existing wikitext.
* We can't throw away existing wikitext, much as we'd love to.
* It's going to cost money in programming the WYSIWYG.
* It's going to cost money in rationalising existing wikitext so that
the most unfeasible formations can be shunted off to legacy for
chewing on.
* It's going to cost money in usability testing and so on.
* It's going to cost money for all sorts of things I haven't even
thought of yet.


This is a problem that would pay off hugely to solve, and that will
take actual money thrown at it.

How would you attack this problem, given actual resources for grunt work?


- d.

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


emufarmers at gmail

Dec 28, 2010, 5:16 AM

Post #2 of 28 (2931 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 6:50 AM, David Gerard <dgerard [at] gmail> wrote:
> So, the payoffs could be ridiculously huge: eight times the number of
> smart and knowledgeable people even being able to *fix typos* on
> material they care about.

Jan Paul Posma's inline editor seems pretty promising. It's not
exactly WYSIWYG, but people would be able to fix typos with it. And
since he's working on it for school, I suspect he might not even be
getting paid. :-)

http://www.gossamer-threads.com/lists/wiki/wikitech/205322
http://www.gossamer-threads.com/lists/wiki/wikitech/208128
http://www.gossamer-threads.com/lists/wiki/wikitech/213447
http://www.gossamer-threads.com/lists/wiki/wikitech/216940

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


church.of.emacs.ml at googlemail

Dec 28, 2010, 7:16 AM

Post #3 of 28 (2937 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

Hi David,

from what I understand, there's a fundamental problem:
There is no formal description of WikiSyntax. Its specification is:
"what the MediaWiki parser does".
It seems that it's not very hard to write a WYSIWYG that covers 99% of
all WikiSyntax, the problem is the remaining 1%.

That being said, I think WMF should try to tackle this difficult
problems. It's a huge job, but worth the effort.

-- Tobias
Attachments: signature.asc (0.26 KB)


vasilvv at gmail

Dec 28, 2010, 8:06 AM

Post #4 of 28 (2945 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

I have thought about WYSIWYG editor for Wikipedia and found it
technically impossible. The main and key problem of WYSIWIG are
templates. You have to understand that templates are not single
element of Wikipedia syntax, they are integral part of page markup.
You do not insert "infobox template", you insert infobox *itself*, and
from what I heard the templates were the main concern of many editors
who were scared of wikitext.

Now think of how many templates are there in Wikipedia, how frequently
they are changed and how much time it would take to implement their
editing.

--vvv

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


fredbaud at fairpoint

Dec 28, 2010, 8:30 AM

Post #5 of 28 (2935 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

> I have thought about WYSIWYG editor for Wikipedia and found it
> technically impossible. The main and key problem of WYSIWIG are
> templates. You have to understand that templates are not single
> element of Wikipedia syntax, they are integral part of page markup.
> You do not insert "infobox template", you insert infobox *itself*, and
> from what I heard the templates were the main concern of many editors
> who were scared of wikitext.
>
> Now think of how many templates are there in Wikipedia, how frequently
> they are changed and how much time it would take to implement their
> editing.
>
> --vvv

Exactly, that's why someone should start over and create a fork which is
a wiki, quick and easy editing. I've, involuntarily, learned a lot about
coding though fooling with templates, but that is not what I came for.

Fred Bauder



_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


dgerard at gmail

Dec 28, 2010, 8:43 AM

Post #6 of 28 (2924 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On 28 December 2010 16:06, Victor Vasiliev <vasilvv [at] gmail> wrote:

> I have thought about WYSIWYG editor for Wikipedia and found it
> technically impossible. The main and key problem of WYSIWIG are
> templates. You have to understand that templates are not single
> element of Wikipedia syntax, they are integral part of page markup.
> You do not insert "infobox template", you insert infobox *itself*, and
> from what I heard the templates were the main concern of many editors
> who were scared of wikitext.
> Now think of how many templates are there in Wikipedia, how frequently
> they are changed and how much time it would take to implement their
> editing.


Yes. So how do we sensibly - usably - deal with templates in a
word-processor-like layout? Is there a way that passes usability
muster for non-geeks? How do others do it? Do their methods actually
work?

e.g. Wikia has WYSIWYG editing and templates. They have a sort of
solution to template editing in WYSIWYG. It's not great, but people
sort of cope. How did they get there? What can be done to make it
better, *conceptually*?

What I'm saying there is that we don't start from the assumption that
we know nothing and have to start from scratch, forming our answers
only from pure application of personal brilliance; we should start
from the assumption that we know actually quite a bit, if we only know
who to ask and where. Does it require throwing out all previous work?
etc., etc. And this is the sort of question that requires actual
expense on resources to answer.

Given that considerable work has gone on already, what would we do
with resources to apply to the problem?


- d.

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


vasilvv at gmail

Dec 28, 2010, 8:45 AM

Post #7 of 28 (2933 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

More thoughts.

I always viewed wikitext vs. WYSIWYG dilemma as similar to LaTeX vs.
Microsoft Word one.

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


sdaugherty at gmail

Dec 28, 2010, 8:54 AM

Post #8 of 28 (2932 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

Not only is the current markup a barrier to participation, it's a barrier to
development. As I argued on Wikien-l, starting over with a markup that can
be syntacticly validated, preferably one that is XML based would reap huge
rewards in the safety and effectiveness of automated tools - authors of
tools like AWB have just as much trouble making software handle the corner
cases in wikitext markup as new editors have understanding it.

It's no wonder really, as the current markup is the result of bolting on
feature after feature, often to handle various corner cases, basically a
really undisciplined approach to development. I honestly wouldn't
be surprised if there were security issues waiting to be found in the
parser, because of the way it's been thrown together.

The switching cost to a new markup and the development cost for an editor
for it would probably be comparable to that of writing a WYSIWYG editor that
understands the current one. A new markup gives us some huge advantages. A
new parser could potentially handle different output formats (print, web,
mobile, pdf, etc) seamlessly, could largely eliminate accessibility issues
that currently are created from ad-hoc formatting capabilities, and would
enable tools that actually understand the markup to start being employed.
Making that parser XML based would mean we can reuse the existing ecosystem
of libraries and tools for manipulating and parsing XML text, and would have
a truly seamless transition into any future markup changes, thanks to XSLT.

XML also gives us the benefit of being able to do validation, possibly at
the time an edit is saved, allowing us to stop broken markup, rather than
having to fix it later, and it allows us to completely remove presentation
from the hands of casual editors - the presentation of articles could be
controlled at site level, with existing consensus processes similar to that
used to change major templates being required to get changes to the site
templates (the article template basically becomes part of the interface at
this stage.)

Transition will be ugly regardless of whether we keep the current parser or
replace it. There are a lot of complex features in the current markup that
need to go because a WYSIWYG editor wouldn't understand them, and it would
also be ideal going forward to "flatten" the formatting capabilities into a
subset that assures consistency - ad-hoc HTML and CSS formatting would
likely have to go.

I honestly think WYSIWYM is a more realistic target once the more
problematic features in the current markup are gone. The editing experience
is largely the same, with the key difference being that what you see in the
editor doesn't have to look exactly like what you see in the rendered
article. By aiming for WYSIWYM, some things would render in the editor in a
way that makes them easier to understand and edit. For example, templates
could render in the editor as tables or as a block that loads the template
parameters into a sidebar when clicked. The same could be done for
references. This has a very shallow learning curve, and a tremendous
advantage over WYSIWYG in that elements that don't lend well to editing in a
WYSIWYG environment are presented in the manner easiest to edit, rather than
in the manner in which they appear. It may take one or two "second looks" to
figure out what's happening, but after that, it's smooth sailing, and by
doing it this way, we avoid the downsides of editing complicated parts of a
page with a minimum cost of initial confusion. WYSIWYM editors can be
friendly to both experienced and new users alike - take LyX as a good
example of such an editor - being WYSIWYM, things that are naturally complex
and unwieldy in WYSIWYG mode become easy because the interface is built to
provide a visual understanding of what is going on rather than 1:1 fidelity
with the final document - as a result, you spend more time editing and less
time worrying about pixel perfect formatting, because you can trust that the
underlying formatting engine will handle things right when you do go to
render the finished document.

As far as current markup goes, a creative solution would be a fork of the
parser into three parts, with a corresponding fork in namespaces as well.
The resulting parts would be an article parser, a template parser, and a
parser for a new layout namespace. Initially, the existing parser is lumped
into the article parser, and class inheritance is used so that the template
parser inherits all markup from the article parser, and in turn, the layout
parser inherits all markup from the template parser. (I'll get more into
layouts below.) This gives us a framework to do several things that improve
usability and consistency. Once the initial "split" is set up, we begin to
move markup features from the article parser into the template and layout
parsers to remove ugly markup from general use, and to restrict formatting
capabilities to a subset that both allows a WYSIWYG or WYSIWYM editor to
work correctly, and allows some level of consistency to be enforced at a
site level. Layouts would be a new form of template, designed to apply as a
block-level outline to an article, providing both a framework to build a
particular type of article, and defining the formatting for that article in
a manner that templates and article markup would no longer be permitted to
do. It's likely that layouts would be treated like highly used templates and
the interface itself, with the ability to create and change a layout
restricted by a permission bit. Layouts would be one to an article, so the
interface to select one would probably be just selecting it from a dropdown
or typing it's name. Every layout would have at least an article body, and
would have one or more additional "blocks" defined - so for basics you could
have the default layout (a flat article), an article with infobox layout,
and a list layout. The end result of this solution is that ad-hoc formatting
using HTML and CSS is gone as far as most editors are concerned, complicated
or easily misused markup features that might cause problems are removed from
the parser that most users will interact with, and the most problematic of
markup is effectively reserved for experienced editors. A new interface can
then be built at a fraction of the development cost, because the "hard
stuff" is out of article space. This both makes sense for usability now, as
well as makes sense as a possible first step if we are ever going to change
parsers, because the things that we probably couldn't convert would be
"contained" rather than spread across articles.

-Steph
_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


sdaugherty at gmail

Dec 28, 2010, 9:10 AM

Post #9 of 28 (2927 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 11:43 AM, David Gerard <dgerard [at] gmail> wrote:

> On 28 December 2010 16:06, Victor Vasiliev <vasilvv [at] gmail> wrote:
>
> > I have thought about WYSIWYG editor for Wikipedia and found it
> > technically impossible. The main and key problem of WYSIWIG are
> > templates. You have to understand that templates are not single
> > element of Wikipedia syntax, they are integral part of page markup.
> > You do not insert "infobox template", you insert infobox *itself*, and
> > from what I heard the templates were the main concern of many editors
> > who were scared of wikitext.
> > Now think of how many templates are there in Wikipedia, how frequently
> > they are changed and how much time it would take to implement their
> > editing.
>
>
> Yes. So how do we sensibly - usably - deal with templates in a
> word-processor-like layout? Is there a way that passes usability
> muster for non-geeks? How do others do it? Do their methods actually
> work?
>
> e.g. Wikia has WYSIWYG editing and templates. They have a sort of
> solution to template editing in WYSIWYG. It's not great, but people
> sort of cope. How did they get there? What can be done to make it
> better, *conceptually*?
>
> What I'm saying there is that we don't start from the assumption that
> we know nothing and have to start from scratch, forming our answers
> only from pure application of personal brilliance; we should start
> from the assumption that we know actually quite a bit, if we only know
> who to ask and where. Does it require throwing out all previous work?
> etc., etc. And this is the sort of question that requires actual
> expense on resources to answer.
>
> Given that considerable work has gone on already, what would we do
> with resources to apply to the problem?
>
>
I think the second part of what I just posted answers this. Split parser to
disallow markup constructs that would break editing interfaces and confuse
new editors (the complicated stuff happens out of sight out of mind in
templates and article layouts). With a little work, the way templates are
designed could be changed to insure they provide a usable prototype to be
able to be edited like forms. Make the editor WYSIWYM rather than WYSIWYG,
it's close enough to WYSIWYG to provide a good editing experience, but
dispenses with 1:1 fidelity in favor of clarity within the
editing environment when necessary - we allow for some elements to be
rendered in an "editing friendly" manner that can be drastically different
from the way the article renders when only viewing it, for example, by
having a template show up as a block or inline element symbol (according to
it's prototype), which can be clicked on and edited as a form. Some
formatting can also be ignored in WYSIWYM mode, so long as there is some
representation that shows the user what to expect (think "show formatting
codes" mode in some WYSIWYG word processors, except, in this case rather
than show all formatting codes, we show the ones that aren't being rendered
at the moment. Other than the initial surprise factor for those that haven't
used that sort of interface, there's not much in the way of a learning curve
- one or two edits at most before someone picks up on what's happening and
can roll with it, and it beats a WYSIWYG interface for a lot of complicated
tasks because it emphasizes "say what you mean" rather than worrying about
how exactly to format it.
_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


meta.sj at gmail

Dec 28, 2010, 2:17 PM

Post #10 of 28 (2918 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

David Gerard writes;
> Our current markup is one of our biggest barriers to participation.

Yes.

> * Starting from a clear field makes it ridiculously easy.

We could start with solutions for first-time posters, new articles,
and new talk-page comments -- any comprehensive solution should be
compatible with short-term solutions that solve this 'ridiculously
easy' part -- which happens to address what many first-time editors
need.


Stephanie Daugherty writes:
> Not only is the current markup a barrier to participation, it's a barrier to
> development. As I argued on Wikien-l, starting over with a markup that can
< be syntacticly validated... would reap huge rewards in the safety
and effectiveness
> of automated tools.

A lack of WYSIWY* is often a barrier to adoption of MediaWiki as
opposed to other wiki platforms, independent of whether or not
potential editors who visit a MW site feel comfortale editing it. I
recall that P2PU for instance wanted to run MW but used pbwiki instead
because of its WYSIWYG editor.

> By aiming for WYSIWYM, some things would render in the editor in a
> way that makes them easier to understand and edit. For example, templates
> could render in the editor as tables or as a block that loads the template
< parameters into a sidebar when clicked... WYSIWYM editors can be friendly
> to both experienced and new users alike - take LyX as a good example

Victor writes;
> I always viewed wikitext vs. WYSIWYG dilemma as similar to LaTeX vs.
> Microsoft Word one.

In this context, LyX is a good example; it sees its WYSIWYM
implementation as halfway between the two.

Stephanie writes:
> Layouts would be a new form of template, designed to apply as a
> block-level outline to an article, providing both a framework to build a
> particular type of article, and defining the formatting for that article in
> a manner that templates and article markup would no longer be permitted to
> do. It's likely that layouts would be treated like highly used templates and
< the interface itself... one to an article, so the interface to
select one would
> probably be just selecting it from a dropdown or typing it's name.

I really like the idea of separating article text, local templates,
and page-wide layout. I don't know if 'three different paresers' are
needed, but just being able to define a stylesheet for a named layout
would save time and frustration.


Brion writes:
> Getting anything done that would work on the huge, well-developed,
> wildly-popular Wikipedia has always been a non-starter because it has to
> deal with 10 years of backwards-compatibility from the get-go. I think it's
> going to be a *lot* easier to get things going on those smaller projects
> which are now so poorly served

How do we make it easier to implement new things for individual
smaller projects?


> For the Wikipedia case, we need to incubate the next generation of templating

Is this a problem space we could tackle in tandem with MindTouch and
others who care about simple interfaces to edit and view complex
information?


Sam.

--
Samuel Klein identi.ca:sj w:user:sj +1 617 529 4266

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


meta.sj at gmail

Dec 28, 2010, 2:37 PM

Post #11 of 28 (2923 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 8:16 AM, Benjamin Lees <emufarmers [at] gmail> wrote:
> On Tue, Dec 28, 2010 at 6:50 AM, David Gerard <dgerard [at] gmail> wrote:
>> So, the payoffs could be ridiculously huge: eight times the number of
>> smart and knowledgeable people even being able to *fix typos* on
>> material they care about.
>
> Jan Paul Posma's inline editor seems pretty promising.
>
> http://www.gossamer-threads.com/lists/wiki/wikitech/216940

That looks like a neat project, certainly good for some use cases.
Kudos to JPP.

We could use a variety of editor options, with a simple way to switch
between them while editing.

For instance, simple small icons to indicate different types of
editing could let you choose an inline-section-editor when fixing a
typo, without losing the option to open a full editing screen. Useful
to power-users and new users alike.

--
Samuel Klein identi.ca:sj w:user:sj +1 617 529 4266

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


sdaugherty at gmail

Dec 28, 2010, 3:24 PM

Post #12 of 28 (2914 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 5:17 PM, Samuel Klein <meta.sj [at] gmail> wrote:

> Stephanie writes:
> > Layouts would be a new form of template, designed to apply as a
> > block-level outline to an article, providing both a framework to build a
> > particular type of article, and defining the formatting for that article
> in
> > a manner that templates and article markup would no longer be permitted
> to
> > do. It's likely that layouts would be treated like highly used templates
> and
> < the interface itself... one to an article, so the interface to
> select one would
> > probably be just selecting it from a dropdown or typing it's name.
>
> I really like the idea of separating article text, local templates,
> and page-wide layout. I don't know if 'three different paresers' are
> needed, but just being able to define a stylesheet for a named layout
> would save time and frustration.


I say 3 different parsers because the effort is as much about restricting
what wikitext can be used where as it is about simplifying the templates and
layouts, and breaking up the parser in this manner is a straightforward way
to keep "ugly" markup out of articlespace. If you make it so the complicated
code that would render an editor hopelessly broken can't directly appear in
an article, you keep the ability to use that code appropriately by template
transclusion. I suggested layouts as an extension of that concept, because
with layouts you can make it so HTML/CSS hacks that could negatively affect
formatting can be left to a process that is more likely to be tested -
there's no reason for every article to have it's own custom CSS positioning
and such - those decisions are better done at a site level where they can be
done consistently and with consideration for things like screen readers,
mobile devices, and print output, something that most editors don't even
need to understand.

The point is to "dumb down" the both the required interface and the
underlying by only having what you need to write articles available.
Advanced editors could continue to develop templates for structured data,
and collaborations between experts would do the really dicey stuff to make
the site look pretty.

The only (immediate) changes to templates required would be a little extra
"glue" to give a WYSIWYM or WYSIWYG editor "hints" about how a template
works - whether the template produces a block or an inline element, and what
parameters it takes so that the editor can display a nice easy to edit form
to fill those parameters while showing the user what they do.

Layouts would likely have a lot more bolted on to them than is currently
possible, because you actually want to define a structure for an article,
with editable regions - they'd likely be a cross between a stylesheet, a
DTD, and a template by the time we got done implementing them.
_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


dgerard at gmail

Dec 28, 2010, 3:43 PM

Post #13 of 28 (2923 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On 28 December 2010 16:54, Stephanie Daugherty <sdaugherty [at] gmail> wrote:

> Not only is the current markup a barrier to participation, it's a barrier to
> development. As I argued on Wikien-l, starting over with a markup that can
> be syntacticly validated, preferably one that is XML based would reap huge
> rewards in the safety and effectiveness of automated tools - authors of
> tools like AWB have just as much trouble making software handle the corner
> cases in wikitext markup as new editors have understanding it.


In every discussion so far, throwing out wikitext and replacing it
with something that isn't a crawling horror has been considered a
non-starter, given ten years and terabytes of legacy wikitext.

If you think you can swing throwing out wikitext and barring the
actual code from human editing - XML is not safely human editable in
any circumstances - then good luck to you, but I don't like your
chances.


- d.

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


sdaugherty at gmail

Dec 28, 2010, 4:01 PM

Post #14 of 28 (2914 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 6:43 PM, David Gerard <dgerard [at] gmail> wrote:

> On 28 December 2010 16:54, Stephanie Daugherty <sdaugherty [at] gmail>
> wrote:
>
> > Not only is the current markup a barrier to participation, it's a barrier
> to
> > development. As I argued on Wikien-l, starting over with a markup that
> can
> > be syntacticly validated, preferably one that is XML based would reap
> huge
> > rewards in the safety and effectiveness of automated tools - authors of
> > tools like AWB have just as much trouble making software handle the
> corner
> > cases in wikitext markup as new editors have understanding it.
>
>
> In every discussion so far, throwing out wikitext and replacing it
> with something that isn't a crawling horror has been considered a
> non-starter, given ten years and terabytes of legacy wikitext.
>
> If you think you can swing throwing out wikitext and barring the
> actual code from human editing - XML is not safely human editable in
> any circumstances - then good luck to you, but I don't like your
> chances.
>
> I'm thinking along the mindset that only "advanced" users would prefer to
directly edit code regardless of the existence of a good WYSIWY* editor, and
that validation would be performed as it's saved. A syntax-highlighting and
code completing editor would make manual edits of XML code palatable. Also,
while XML text isn't that much better for manual edits because of it's
verbosity, it's no different than manually editing HTML code, which people
successfully manage to do all the time, and it can actually be easier to
grok than wikitext because its more generous in where it will allow you to
use whitespace, allowing you to use indentation to make the code easy to
follow:

<article>
<title>Foo</title>
<section title="Introduction">
This is the introduction. Maybe you really want the <internal-link
article="Sandbox">Sandbox</internal-link>
</section>
&boilerplate; <!--Some boilerplate text to be transcluded via an
entity--!>
<category name="Test" />
</article>

Yes, the added verbosity is bad, but if it enables better tools to be used,
including an editor that's actually usable by "the rest of us", it's worth
it.
_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


george.herbert at gmail

Dec 28, 2010, 4:12 PM

Post #15 of 28 (2914 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 3:43 PM, David Gerard <dgerard [at] gmail> wrote:
> On 28 December 2010 16:54, Stephanie Daugherty <sdaugherty [at] gmail> wrote:
>
>> Not only is the current markup a barrier to participation, it's a barrier to
>> development. As I argued on Wikien-l, starting over with a markup that can
>> be syntacticly validated, preferably one that is XML based would reap huge
>> rewards in the safety and effectiveness of automated tools - authors of
>> tools like AWB have just as much trouble making software handle the corner
>> cases in wikitext markup as new editors have understanding it.
>
>
> In every discussion so far, throwing out wikitext and replacing it
> with something that isn't a crawling horror has been considered a
> non-starter, given ten years and terabytes of legacy wikitext.
>
> If you think you can swing throwing out wikitext and barring the
> actual code from human editing - XML is not safely human editable in
> any circumstances - then good luck to you, but I don't like your
> chances.

That is true - "We can't do away with Wikitext" always been the
intermediate conclusion (in between "My god, we need to do something
about this problem" and "This is hopeless, we give up again").

Perhaps it's time to start some exercises in noneuclidian Wiki
development, and just assume the opposite and see what happens.


--
-george william herbert
george.herbert [at] gmail

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


sdaugherty at gmail

Dec 28, 2010, 4:47 PM

Post #16 of 28 (2921 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On Tue, Dec 28, 2010 at 7:12 PM, George Herbert <george.herbert [at] gmail>wrote:

> That is true - "We can't do away with Wikitext" always been the
> intermediate conclusion (in between "My god, we need to do something
> about this problem" and "This is hopeless, we give up again").
>
> Perhaps it's time to start some exercises in noneuclidian Wiki
> development, and just assume the opposite and see what happens.
>

We've got some serious thought going along three lines (with some crossover
between them.)


1. Bolt WYSIWY* functionality on top of what we have that will just
cordon off what it can't grok and let the user edit the rest.
2. Strip out or restrict the use of some of the current wikitext elements
to simplify the markup.
3. Make a fresh start.

All of these are at least remotely feasible with a sustained effort and
commitment to implement a finished product. None of these results in an
optimal solution, but all of them result in a situation that is way ahead of
where we are now. Accepting a bad situation as "the way things have to be"
because the alternatives aren't perfect is foolish. Any measurable
improvement from where we are now would be just that - an improvement.
That's reason enough to go forward with something!!!!
_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


z at mzmcbride

Dec 28, 2010, 9:13 PM

Post #17 of 28 (2914 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

David Gerard wrote:
> Our current markup is one of our biggest barriers to participation.
>
> [snip]
>
> * Tim doesn't scale. Most of our other technical people don't scale.
> *We have no resources and still run on almost nothing*.
>
> ($14m might sound like enough money to run a popular website, but for
> comparison, I work as a sysadmin at a tiny, tiny publishing company
> with more money and staff just in our department than that to do
> *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
> efficient organisation.)

You inexplicably posted this to foundation-l, so let's look at this from an
organizational/political standpoint.

The issue isn't a technical one, though there are technical challenges, to
be sure. The issue is one of priorities. If there were a grant involved,
Wikimedia would find a way to push out some half-assed code at the eleventh
hour. If there were some way to tie this to fundraising, you could get one
or two full-time developers working on this, plus a staff of "associates."
But this isn't tied to a grant and it isn't fundraising-related. It isn't
glamorous work and it doesn't directly involve money, so it's left in The
Pile next to the thousands of other ideas that desperately need attention.

Or put another way, "this seems like far better outreach than a thousand
outreach officers."

It's clear where Wikimedia is putting its priorities. Screw being able to
click edit on the "Microsoft" article and not wanting to kill yourself,
in-person wiki editing training is the way forward! Or so the funds flow.

The saving grace of this idea (i.e., the reason it might one day move
forward) is that, as you note, easier editing bolsters participation. And if
one thing has been made clear through the strategic planning charade, it's
that participation is actually viewed as very important to Wikimedia.
Quality be damned, Wikimedia wants quantity. It's this attitude that might
finally drive some resources toward making the edit screen less of a
nightmare, but I wouldn't hold my breath. It still assumes a higher level of
competence than has been demonstrated historically.

All of this sidesteps that even if you had a brilliant extension/patch that
could solve this problem (and it's not as though such a patch or extension
would be simple), the likelihood of it being committed to SVN and going live
before 2012 is pretty low. (Unless, again, there were a grant attached.)

I think this is an important problem that deserves thoughtful consideration
and attention. Which of course begs the question of why you think Wikimedia
will be the one to solve it. This is the prime target for a competitor
coming in and making something better. Why stand in the way?

MZMcBride



_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


wiki-list at phizz

Dec 29, 2010, 1:18 AM

Post #18 of 28 (2922 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

z [at] mzmcbride wrote:
> David Gerard wrote:
> > Our current markup is one of our biggest barriers to participation.
> >
> > [snip]
> >
> > * Tim doesn't scale. Most of our other technical people don't scale.
> > *We have no resources and still run on almost nothing*.
> >
> > ($14m might sound like enough money to run a popular website, but for
> > comparison, I work as a sysadmin at a tiny, tiny publishing company
> > with more money and staff just in our department than that to do
> > *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
> > efficient organisation.)
>

In comparison $14m does seem highly profligate. Our R&D budget was 10m (approx $16) in 2009, spent almost entirely on software development, and we have over 160 software engineers working on our products. Remind me just how many full time developers does WMF have?


z at mzmcbride

Dec 29, 2010, 2:07 AM

Post #19 of 28 (2916 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

wiki-list [at] phizz wrote:
> z [at] mzmcbride wrote:
>> David Gerard wrote:
>>> Our current markup is one of our biggest barriers to participation.
>>>
>>> [snip]
>>>
>>> * Tim doesn't scale. Most of our other technical people don't scale.
>>> *We have no resources and still run on almost nothing*.
>>>
>>> ($14m might sound like enough money to run a popular website, but for
>>> comparison, I work as a sysadmin at a tiny, tiny publishing company
>>> with more money and staff just in our department than that to do
>>> *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
>>> efficient organisation.)
>>
>
> In comparison $14m does seem highly profligate. Our R&D budget was 10m
> (approx $16) in 2009, spent almost entirely on software development, and we
> have over 160 software engineers working on our products. Remind me just how
> many full time developers does WMF have?

These two pages should give you an approximate count:
* http://wikimediafoundation.org/wiki/Staff
* http://meta.wikimedia.org/wiki/Wikimedia_Foundation_contractors

MZMcBride



_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


dgerard at gmail

Dec 29, 2010, 2:15 AM

Post #20 of 28 (2916 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On 29 December 2010 05:13, MZMcBride <z [at] mzmcbride> wrote:

> You inexplicably posted this to foundation-l, so let's look at this from an
> organizational/political standpoint.


I deliberately posted it there because what I'm asking for is broad
and difficult organisational commitment. And almost didn't post it to
wikitech-l, fearing that doing the latter would result in what it did,
i.e, more of the same from the past five years, where the necessity is
buried under more off-the-cuff ideas that won't get it through.

And a pointer here from internal-l and wikien-l.

Sorry, was it not entirely clear that was what I was doing? It is. My
dream is that more than me will consider this worth the serious
pushing it will take.


> I think this is an important problem that deserves thoughtful consideration
> and attention. Which of course begs the question of why you think Wikimedia
> will be the one to solve it. This is the prime target for a competitor
> coming in and making something better. Why stand in the way?


Unfortunately, Wikia seems to treat its codebase with nearly the
hygiene WMF does at times, so using their work would be comparable
effort to reimplementing it ...


- d.

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


z at mzmcbride

Dec 29, 2010, 3:03 AM

Post #21 of 28 (2913 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

David Gerard wrote:
> On 29 December 2010 05:13, MZMcBride <z [at] mzmcbride> wrote:
>> You inexplicably posted this to foundation-l, so let's look at this from an
>> organizational/political standpoint.
>
> I deliberately posted it there because what I'm asking for is broad
> and difficult organisational commitment. And almost didn't post it to
> wikitech-l, fearing that doing the latter would result in what it did,
> i.e, more of the same from the past five years, where the necessity is
> buried under more off-the-cuff ideas that won't get it through.
>
> And a pointer here from internal-l and wikien-l.
>
> Sorry, was it not entirely clear that was what I was doing? It is. My
> dream is that more than me will consider this worth the serious
> pushing it will take.

I was aware that you'd posted to four separate mailing lists about this. The
underlying motive wasn't as clear to me. Thank you for clarifying.

You seem to have snipped out the reasons laid out in my previous post for
why I think your dream (broad and difficult organisational commitment) is
just a dream, though. ;-)

>> I think this is an important problem that deserves thoughtful consideration
>> and attention. Which of course begs the question of why you think Wikimedia
>> will be the one to solve it. This is the prime target for a competitor
>> coming in and making something better. Why stand in the way?
>
> Unfortunately, Wikia seems to treat its codebase with nearly the
> hygiene WMF does at times, so using their work would be comparable
> effort to reimplementing it ...

The way I read this, you're almost suggesting that Wikia is a competitor to
Wikipedia. Of all the sites on the Web, I think it's reasonable to say that
Wikia is one of the few that inherently was not designed to be a competitor
to Wikipedia, given its founders.

As for Wikia's codebase, the idea of Wikimedia's code improving Wikia and
Wikia's code improving Wikimedia is certainly a nice one. However, I can't
say the reality has really matched the ideal. I think we agree here.

MZMcBride



_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


dgerard at gmail

Dec 29, 2010, 3:39 AM

Post #22 of 28 (2918 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

On 29 December 2010 11:03, MZMcBride <z [at] mzmcbride> wrote:

> The way I read this, you're almost suggesting that Wikia is a competitor to
> Wikipedia. Of all the sites on the Web, I think it's reasonable to say that
> Wikia is one of the few that inherently was not designed to be a competitor
> to Wikipedia, given its founders.


I wasn't saying they're a competitor, but they're an organisation that
has code that aims to allow the widest possible range of editors. With
varying success. And that they do actually share their code.


- d.

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


wiki-list at phizz

Dec 29, 2010, 5:22 AM

Post #23 of 28 (2921 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

z [at] mzmcbride wrote:
> wiki-list [at] phizz wrote:
> > z [at] mzmcbride wrote:
>
> > In comparison $14m does seem highly profligate. Our R&D budget was 10m
> > (approx $16) in 2009, spent almost entirely on software development, and =
> we
> > have over 160 software engineers working on our products. Remind me just =
> how
> > many full time developers does WMF have?
>
> These two pages should give you an approximate count:
> * http://wikimediafoundation.org/wiki/Staff
> * http://meta.wikimedia.org/wiki/Wikimedia_Foundation_contractors
>

We make a profit on a turnover of 32m with 500+ direct employees, and a further 200 in joint oversees ventures. We have offices in most European countries, and regional centres in the US, India, China, Japan, Korea, and a team of application engineers flying the world to train, and provide expert sales support etc.

Draw your own conclusions.


cunctator at gmail

Jan 1, 2011, 10:20 PM

Post #24 of 28 (2888 views)
Permalink
Re: Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

I can promise you that the reason edit rates has gone down is not because of
problems with wikitext. Though the cruft is a symptom.

On Tue, Dec 28, 2010 at 6:50 AM, David Gerard <dgerard [at] gmail> wrote:

> [crossposted to foundation-l and wikitech-l]
>
>
> "There has to be a vision though, of something better. Maybe something
> that is an actual wiki, quick and easy, rather than the template
> coding hell Wikipedia's turned into." - something Fred Bauder just
> said on wikien-l.
>
>
> Our current markup is one of our biggest barriers to participation.
>
> AIUI, edit rates are about half what they were in 2005, even as our
> fame has gone from "popular" through "famous" to "part of the
> structure of the world." I submit that this is not a good or healthy
> thing in any way and needs fixing.
>
> People who can handle wikitext really just do not understand how
> offputting the computer guacamole is to people who can cope with text
> they can see.
>
> We know this is a problem; WYSIWYG that works is something that's been
> wanted here forever. There are various hideous technical nightmares in
> its way, that make this a big and hairy problem, of the sort where the
> hair has hair.
>
> However, I submit that it's important enough we need to attack it with
> actual resources anyway.
>
>
> This is just one data point, where a Canadian government office got
> *EIGHT TIMES* the participation in their intranet wiki by putting in a
> (heavily locally patched) copy of FCKeditor:
>
>
> http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034062.html
>
> "I have to disagree with you given my experience. In one government
> department where MediaWiki was installed we saw the active user base
> spike from about 1000 users to about 8000 users within a month of having
> enabled FCKeditor. FCKeditor definitely has it's warts, but it very
> closely matches the experience non-technical people have gotten used to
> while using Word or WordPerfect. Leveraging skills people already have
> cuts down on training costs and allows them to be productive almost
> immediately."
>
> http://lists.wikimedia.org/pipermail/mediawiki-l/2010-May/034071.html
>
> "Since a plethora of intelligent people with no desire to learn WikiCode
> can now add content, the quality of posts has been in line with the
> adoption of wiki use by these people. Thus one would say it has gone up.
>
> "In the beginning there were some hard core users that learned WikiCode,
> for the most part they have indicated that when the WYSIWYG fails, they
> are able to switch to WikiCode mode to address the problem. This usually
> occurs with complex table nesting which is something that few of the
> users do anyways. Most document layouts are kept simple. Additionally,
> we have a multilingual english/french wiki. As a result the browser
> spell-check is insufficient for the most part (not to mention it has
> issues with WikiCode). To address this a second spellcheck button was
> added to the interface so that both english and french spellcheck could
> be available within the same interface (via aspell backend)."
>
>
> So, the payoffs could be ridiculously huge: eight times the number of
> smart and knowledgeable people even being able to *fix typos* on
> material they care about.
>
> Here are some problems. (Off the top of my head; please do add more,
> all you can think of.)
>
>
> - The problem:
>
> * Fidelity with the existing body of wikitext. No conversion flag day.
> The current body exploits every possible edge case in the regular
> expression guacamole we call a "parser". Tim said a few years ago that
> any solution has to account for the existing body of text.
>
> * Two-way fidelity. Those who know wikitext will demand to keep it and
> will bitterly resist any attempt to take it away from them.
>
> * FCKeditor (now CKeditor) in MediaWiki is all but unmaintained.
>
> * There is no specification for wikitext. Well, there almost is -
> compiled as C, it runs a bit slower than the existing PHP compiler.
> But it's a start!
> http://lists.wikimedia.org/pipermail/wikitext-l/2010-August/000318.html
>
>
> - Attempting to solve it:
>
> * The best brains around Wikipedia, MediaWiki and WMF have dashed
> their foreheads against this problem for at least the past five years
> and have got *nowhere*. Tim has a whole section in the SVN repository
> for "new parser attempts". Sheer brilliance isn't going to solve this
> one.
>
> * Tim doesn't scale. Most of our other technical people don't scale.
> *We have no resources and still run on almost nothing*.
>
> ($14m might sound like enough money to run a popular website, but for
> comparison, I work as a sysadmin at a tiny, tiny publishing company
> with more money and staff just in our department than that to do
> *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
> efficient organisation.)
>
>
> - Other attempts:
>
> * Starting from a clear field makes it ridiculously easy. The
> government example quoted above is one. Wikia wrote a good WYSIWYG
> that works really nicely on new wikis (I'm speaking here as an
> experienced wikitext user who happily fixes random typos on Wikia). Of
> course, I noted that we can't start from a clear field - we have an
> existing body of wikitext.
>
>
> So, specification of the problem:
>
> * We need good WYSIWYG. The government example suggests that a simple
> word-processor-like interface would be enough to give tremendous
> results.
> * It needs two-way fidelity with almost all existing wikitext.
> * We can't throw away existing wikitext, much as we'd love to.
> * It's going to cost money in programming the WYSIWYG.
> * It's going to cost money in rationalising existing wikitext so that
> the most unfeasible formations can be shunted off to legacy for
> chewing on.
> * It's going to cost money in usability testing and so on.
> * It's going to cost money for all sorts of things I haven't even
> thought of yet.
>
>
> This is a problem that would pay off hugely to solve, and that will
> take actual money thrown at it.
>
> How would you attack this problem, given actual resources for grunt work?
>
>
> - d.
>
> _______________________________________________
> foundation-l mailing list
> foundation-l [at] lists
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l


julianadacostajose at googlemail

Jan 4, 2011, 1:03 PM

Post #25 of 28 (2887 views)
Permalink
Big problem to solve: good WYSIWYG on WMF wikis [In reply to]

Hello all,

about WYSIWYG have a look to to this links:

* http://meta.wikimedia.org/wiki/WissensWert/75_-_Einsatz_des_TWX_WYSIWYG_Editors
* http://www.wiki4enterprise.org/index.php/Datei:Artikelbearbeitung_Twoonix.jpg.png

TWOONIX is working on an on an MediaWiki based editor.

Best Juliana

_______________________________________________
foundation-l mailing list
foundation-l [at] lists
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

First page Previous page 1 2 Next page Last page  View All Wikipedia foundation RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.