Can someone please tell me, in precise technical terms, what is wrong with Wikia's WYSIWYG editor and why we can't use it?
I have heard that it has bugs in it, but I have not been told exactly what these bugs are, why they are more relevant for Wikimedia than for Wikia, or why they can't be fixed.
Years ago, we talked dismissively about WYSIWYG. We discussed the features that a WYSIWYG editor would have to have, pointing out how difficult they would be to implement and how we didn't have the manpower to pull off such a thing. Now that Wikia has gone ahead and implemented those exact features, what is the problem?
-- Tim Starling
On 11-05-02 12:04 AM, Tim Starling wrote:
Can someone please tell me, in precise technical terms, what is wrong with Wikia's WYSIWYG editor and why we can't use it?
I have heard that it has bugs in it, but I have not been told exactly what these bugs are, why they are more relevant for Wikimedia than for Wikia, or why they can't be fixed.
Years ago, we talked dismissively about WYSIWYG. We discussed the features that a WYSIWYG editor would have to have, pointing out how difficult they would be to implement and how we didn't have the manpower to pull off such a thing. Now that Wikia has gone ahead and implemented those exact features, what is the problem?
-- Tim Starling
I wouldn't say more relevant for Wikimedia than Wikia, but more relevant for encyclopedia that care about their wikitext than a social wiki run by newbies who don't even know what wikitext or a template is.
Most of the wiki I was involved in on Wikia all have the RTE disabled because the RTE made additional unwanted changes when editing destroying diffs, in one case destroyed a bulleted list item every time the page was edited, and also increased the number of new users making bad edits like inserting an image in the middle of a run of text because on their monitor in the WYSIWYG editor it was aligned where they thought it should be.
On 02/05/11 17:31, Daniel Friesen wrote:
I wouldn't say more relevant for Wikimedia than Wikia, but more relevant for encyclopedia that care about their wikitext than a social wiki run by newbies who don't even know what wikitext or a template is.
I am looking forward to a future when even experienced Wikipedia editors won't know or care what wikitext is. Just because Wikipedia is a serious project doesn't mean we have to make our editors care about markup.
Most of the wiki I was involved in on Wikia all have the RTE disabled because the RTE made additional unwanted changes when editing destroying diffs, in one case destroyed a bulleted list item every time the page was edited,
That sounds like a bug. Is there a test case? Was it reported to Wikia's bug tracker? Was it fixed? Is it theoretically fixable?
This is the sort of thing I've heard before, but I need test cases or a pointer to the relevant code so I can evaluate it properly.
and also increased the number of new users making bad edits like inserting an image in the middle of a run of text because on their monitor in the WYSIWYG editor it was aligned where they thought it should be.
Conversely, I've seen a lot of new users making edits to Wikipedia which are completely broken due to them not understanding some detail of how wikitext works, for example, putting a space at the start of a line, or pressing the enter button for a new line instead of <br/>. I don't think using wikitext is the best way to make things easier for new users.
-- Tim Starling
On Mon, May 2, 2011 at 10:02, Tim Starling tstarling@wikimedia.org wrote:
don't think using wikitext is the best way to make things easier for new users.
It's always been a dilemma for me to see how much amount of computer illiterate users should be wished for (or actually possible to tolerate). I don't feel that web number dot number (whatever version we call it) is fast, reliable, useful enough to be used as the main way to input encyclopedia text. These usually very slow, and quite unreliable (including google docs stuff which is I believe the most advanced tech out here in this topic).
And... People habitually completely get lost in DTP software (be that [open/whatever]office or else), they can't comprehend formatting, fonts, text annotation and other advanced features. I do not see that WYSIWYG would've made them more able to use the techniques. There are some guys who actually learned enough markup to completely screw up wikibooks (putting flashing 80pt large fonts in scrolling frames with all kinds of - otherwise not horrible on purpose - features of CSS), and I just fear what they can do with wysiwig. Such texts are sometimes just easier to completely reformat (reset ALL formatting to default and start over).
Foundation's purpose is to make it easier for everyone and to invite and involve everyone, I know. I just have my doubts and worries, which I have just shared.
Peter
On Mon, May 2, 2011 at 9:31 AM, Daniel Friesen lists@nadir-seen-fire.com wrote:
Most of the wiki I was involved in on Wikia all have the RTE disabled because the RTE made additional unwanted changes when editing destroying diffs, in one case destroyed a bulleted list item every time the page was edited,
I've had a similar experience on a wiki I was involved in about 3-4 years ago. We gave the editor a try, but every time you edited an article, no matter how small the edit, the editor would go ahead and "normalize" all links of the form [[Foo]] to [[Foo|Foo]]. In a several-kilobyte encyclopedic article with links in every other sentence, this produces an enormous diff that makes it impossible to tell what the real change was.
While I'm sure this particular bug has been fixed, it sounds like the underlying problem remains. FCKeditor seems to be converting wikitext to HTML, let users edit the HTML, then convert the HTML back to wikitext. The bugs would then result from the fact that the wikitext->HTML->wikitext round-trip (or wikitext->whatever internal representation is used->wikitext) isn't clean.
Trevor and I talked about this issue about a year and a half ago, and figured the best way around round-trip bugs was to not do round-trips at all. Instead, wikitext or something close to it should be used as an internal representation, and/or only the parts of the page the user touches should actually change.
So that's what I know about the issues when introducing FCKeditor to an existing wikitext 'codebase'. I hear it's fairly decent when used from the start, but I'm not familiar enough with it to comment on that.
Roan Kattouw (Catrope)
On 02/05/11 18:15, Roan Kattouw wrote:
While I'm sure this particular bug has been fixed, it sounds like the underlying problem remains. FCKeditor seems to be converting wikitext to HTML, let users edit the HTML, then convert the HTML back to wikitext. The bugs would then result from the fact that the wikitext->HTML->wikitext round-trip (or wikitext->whatever internal representation is used->wikitext) isn't clean.
Trevor and I talked about this issue about a year and a half ago, and figured the best way around round-trip bugs was to not do round-trips at all. Instead, wikitext or something close to it should be used as an internal representation, and/or only the parts of the page the user touches should actually change.
What about using a kind of document tree representation of wikitext? You could have an intermediate representation which precisely represents all of the source wikitext, but was easy to convert to displayable HTML. Kind of like HTML, but annotated to show which of the multiple options for HTML to wikitext transformation should be chosen on the return trip in order to preserve unchanged wikitext precisely.
That's what Wikia's editor does. It uses a subclass of the core MediaWiki parser to generate HTML-like output which is richly annotated with comments and custom attributes, allowing precise round-trip transformation of unchanged text.
The client side is not a generic HTML editor, rather it responds to UI events by editing the intermediate DOM representation, using code which is aware of the special structure of that document tree.
Maybe there are remaining round-trip bugs, but there's no obvious reason why they couldn't be fixed using this general approach.
So that's what I know about the issues when introducing FCKeditor to an existing wikitext 'codebase'. I hear it's fairly decent when used from the start, but I'm not familiar enough with it to comment on that.
That's not what I hear. I hear that there were some teething problems, especially related to round-trip conversion, but that those were sorted out long ago.
By the way, it's not FCKEditor. The server side seems to have been rewritten from scratch by Wikia, and the client side has been extended and patched. RTE is probably a good name for it, since that's what they call it.
If you want to know more, this appears to be the relevant code:
https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/
-- Tim Starling
On Mon, May 2, 2011 at 1:29 PM, Tim Starling tstarling@wikimedia.org wrote:
What about using a kind of document tree representation of wikitext? You could have an intermediate representation which precisely represents all of the source wikitext, but was easy to convert to displayable HTML. Kind of like HTML, but annotated to show which of the multiple options for HTML to wikitext transformation should be chosen on the return trip in order to preserve unchanged wikitext precisely.
That's what Wikia's editor does. It uses a subclass of the core MediaWiki parser to generate HTML-like output which is richly annotated with comments and custom attributes, allowing precise round-trip transformation of unchanged text.
The client side is not a generic HTML editor, rather it responds to UI events by editing the intermediate DOM representation, using code which is aware of the special structure of that document tree.
Maybe there are remaining round-trip bugs, but there's no obvious reason why they couldn't be fixed using this general approach.
Yeah that sounds good. I was unaware that Wikia had moved to this approach.
So that's what I know about the issues when introducing FCKeditor to an existing wikitext 'codebase'. I hear it's fairly decent when used from the start, but I'm not familiar enough with it to comment on that.
That's not what I hear. I hear that there were some teething problems, especially related to round-trip conversion, but that those were sorted out long ago.
By the way, it's not FCKEditor. The server side seems to have been rewritten from scratch by Wikia, and the client side has been extended and patched. RTE is probably a good name for it, since that's what they call it.
Well that just speaks to how ancient my experience with it is, I guess.
Roan Kattouw (Catrope)
On Mon, May 2, 2011 at 4:15 AM, Roan Kattouw roan.kattouw@gmail.com wrote:
I've had a similar experience on a wiki I was involved in about 3-4 years ago. We gave the editor a try, but every time you edited an article, no matter how small the edit, the editor would go ahead and "normalize" all links of the form [[Foo]] to [[Foo|Foo]]. In a several-kilobyte encyclopedic article with links in every other sentence, this produces an enormous diff that makes it impossible to tell what the real change was.
Editors do this all the time anyway. Typically using automated tools so they don't have to do any actual work. Surely someone here has had to wade through someone changing every REF to that bag of hammers CITE tag.
On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz maury.markowitz@gmail.com wrote:
Editors do this all the time anyway. Typically using automated tools so they don't have to do any actual work. Surely someone here has had to wade through someone changing every REF to that bag of hammers CITE tag.
Sure, but those aren't typically mixed with "real" changes in the same edit. That's what was hard: spotting the actual changes in the midst of all the normalization noise.
Roan Kattouw (Catrope)
On 2 May 2011 13:09, Roan Kattouw roan.kattouw@gmail.com wrote:
On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz maury.markowitz@gmail.com wrote:
Editors do this all the time anyway. Typically using automated tools so they don't have to do any actual work. Surely someone here has had to wade through someone changing every REF to that bag of hammers CITE tag.
Sure, but those aren't typically mixed with "real" changes in the same edit. That's what was hard: spotting the actual changes in the midst of all the normalization noise.
The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit.
On 2 May 2011 15:27, Thomas Dalton thomas.dalton@gmail.com wrote:
The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit.
Only if you immediately go all-WYSIWYG and no-one is ever allowed to directly edit wikitext ever again. This strikes me as likely to go over very badly indeed.
- d.
On 2 May 2011 15:31, David Gerard dgerard@gmail.com wrote:
On 2 May 2011 15:27, Thomas Dalton thomas.dalton@gmail.com wrote:
The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit.
Only if you immediately go all-WYSIWYG and no-one is ever allowed to directly edit wikitext ever again. This strikes me as likely to go over very badly indeed.
No. I clearly said there would be small amounts of normalisation to deal with new wikitext edits, but that the whole article would only need to be normalised once. I was not assuming we would do away with wikitext editing entirely (and wouldn't support doing so).
On 11-05-02 08:12 AM, Thomas Dalton wrote:
On 2 May 2011 15:31, David Gerard dgerard@gmail.com wrote:
On 2 May 2011 15:27, Thomas Dalton thomas.dalton@gmail.com wrote:
The normalisation only really needs to happen once, though. There may be a few little bits where people have made wikitext edits since the last WYSIWYG edit, but the whole article will only need to be normalised the first time there is a WYSIWYG edit.
Only if you immediately go all-WYSIWYG and no-one is ever allowed to directly edit wikitext ever again. This strikes me as likely to go over very badly indeed.
No. I clearly said there would be small amounts of normalisation to deal with new wikitext edits, but that the whole article would only need to be normalised once. I was not assuming we would do away with wikitext editing entirely (and wouldn't support doing so).
He might be alluding to the fact that even after you normalize it, someone not using WYSIWYG can go and make an edit that happens to use pre-normalized stuff, and as a result that gets messed up the next time someone edits using a WYSIWYG editor.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Mon, May 2, 2011 at 9:17 AM, Daniel Friesen lists@nadir-seen-fire.comwrote:
On 11-05-02 08:12 AM, Thomas Dalton wrote:
No. I clearly said there would be small amounts of normalisation to deal with new wikitext edits, but that the whole article would only need to be normalised once. I was not assuming we would do away with wikitext editing entirely (and wouldn't support doing so).
He might be alluding to the fact that even after you normalize it, someone not using WYSIWYG can go and make an edit that happens to use pre-normalized stuff, and as a result that gets messed up the next time someone edits using a WYSIWYG editor.
In a sane world, you might actually end up with the same normalization regardless of what method you used to edit; we do after all perform post-save transforms using the parser, which turns ~~~ into a signature, [[Foo (bar)|]] into [[Foo (bar)|Foo]] etc.
It would not be unreasonable for a human- or bot-made source edit to get run through the parser for normalization on save, leaving you with only "real" diffs going forward.
I think that "little" markup normalization like this will eventually not be too big a deal; either the system will start applying the normalization consistently, or it won't have to because all the information available to reconstruct the original source is round-tripped through the wysiwig side.
A bigger deal will probably be actually changing structures that don't render consistently, and that'll depend on how brave we are changing nested template & table structures to fit a hierarchical document model.
We've basically got two levels of stuff:
* parsing wiki markup into a document structure that's useful for editing * using the document structure to render HTML output or an editing environment
Our classic MediaWiki parser does only a tiny bit of the first in the preprocessor, and then leaves a lot more of our markup to the transformation layer, which is how we end up with things like templates that expand into an HTML tag opener, of which which some adjacent templates contain the contents and endings.
If we can devise a way to consistently treat expansions that *aren't* a hierarchical match fro the HTML node tree, then we might not have to change templates much. If we can't, then we might have to start enforcing hierarchical template & other code nesting and go through and migrate a bunch of existing templates.
-- brion
Brion Vibber wrote:
A bigger deal will probably be actually changing structures that don't render consistently, and that'll depend on how brave we are changing nested template & table structures to fit a hierarchical document model.
We've basically got two levels of stuff:
- parsing wiki markup into a document structure that's useful for editing
- using the document structure to render HTML output or an editing
environment
Our classic MediaWiki parser does only a tiny bit of the first in the preprocessor, and then leaves a lot more of our markup to the transformation layer, which is how we end up with things like templates that expand into an HTML tag opener, of which which some adjacent templates contain the contents and endings.
If we can devise a way to consistently treat expansions that *aren't* a hierarchical match fro the HTML node tree, then we might not have to change templates much. If we can't, then we might have to start enforcing hierarchical template & other code nesting and go through and migrate a bunch of existing templates.
-- brion
{{Open template}} text {{Close template}} structures are IMHO a big problem for any WYSIWYG editor. But there's no way they are going away.
On 11-05-02 03:32 PM, Platonides wrote:
Brion Vibber wrote:
A bigger deal will probably be actually changing structures that don't render consistently, and that'll depend on how brave we are changing nested template & table structures to fit a hierarchical document model.
We've basically got two levels of stuff:
- parsing wiki markup into a document structure that's useful for editing
- using the document structure to render HTML output or an editing
environment
Our classic MediaWiki parser does only a tiny bit of the first in the preprocessor, and then leaves a lot more of our markup to the transformation layer, which is how we end up with things like templates that expand into an HTML tag opener, of which which some adjacent templates contain the contents and endings.
If we can devise a way to consistently treat expansions that *aren't* a hierarchical match fro the HTML node tree, then we might not have to change templates much. If we can't, then we might have to start enforcing hierarchical template & other code nesting and go through and migrate a bunch of existing templates.
-- brion
{{Open template}} text {{Close template}} structures are IMHO a big problem for any WYSIWYG editor. But there's no way they are going away.
Sure they will... ;) if we have loop functions.
*snicker*
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Mon, May 2, 2011 at 3:32 PM, Platonides Platonides@gmail.com wrote:
If we can devise a way to consistently treat expansions that *aren't* a hierarchical match fro the HTML node tree, then we might not have to
change
templates much. If we can't, then we might have to start enforcing hierarchical template & other code nesting and go through and migrate a bunch of existing templates.
{{Open template}} text {{Close template}} structures are IMHO a big problem for any WYSIWYG editor. But there's no way they are going away.
If we determine they have to go, then we can devise ways to find and migrate them -- it'll be a process that takes time and a lot of helper tools, and it's necessary to not underplay that difficulty.
But it's not an intractable problem. Essentially, anything in the format:
{{start}} content1 content2 {{end}}
can be rewritten something like:
{{container| content1 content2 }}
with some variation based on what needs there are on customizing the start/end and such. That could then expand cleanly:
template: 'container' param 0: 'content1' 'content2'
->
expanded-template: 'container' table: row: 'start' row: cell: 'content1' 'content2' row: 'end'
Now, it may well be feasible to actually let the table rows just sit there in the parse tree and coalesce them into the adjacent table during final HTML transformation or something, but if that's not practical to do in the parser & translation layers it shouldn't be impossible to migrate.
Where wrapping bunches of things in separate rows is done currently, some basic (and sane) loop parser functions could also help with making those clean.
-- brion
Brion Vibber wrote:
{{Open template}} text {{Close template}} structures are IMHO a big problem for any WYSIWYG editor. But there's no way they are going away.
If we determine they have to go, then we can devise ways to find and migrate them -- it'll be a process that takes time and a lot of helper tools, and it's necessary to not underplay that difficulty.
But it's not an intractable problem. Essentially, anything in the format:
{{start}} content1 content2 {{end}}
can be rewritten something like:
{{container| content1 content2 }}
It's equivalent, but uglier to type and work with. I don'think people would resist moving to it. You also get some problems in getting some markup because you no longer are in the first line, don't remember exactly.
Now, it may well be feasible to actually let the table rows just sit there in the parse tree and coalesce them into the adjacent table during final HTML transformation or something, but if that's not practical to do in the parser & translation layers it shouldn't be impossible to migrate.
diebuche moved tables to an AST-like structure recently. I wonder if it's still efficient enough for wikipedia, though.
On Mon, May 2, 2011 at 4:01 PM, Platonides Platonides@gmail.com wrote:
But it's not an intractable problem. Essentially, anything in the format:
{{start}} content1 content2 {{end}}
can be rewritten something like:
{{container| content1 content2 }}
It's equivalent, but uglier to type and work with. I don'think people would resist moving to it. You also get some problems in getting some markup because you no longer are in the first line, don't remember exactly.
'Uglier' to work with depends very much on what the tools to work with it looks like... if the result is we make it a billion times easier to maintain your infoboxes on your articles because the whole box can be treated as a unit in the editor or even handed off to a specialized infobox wizard, then I'm a lot less worried about what it _looks like_ in the markup.
Humans *shouldn't* be worrying about whether they got the whitespace or escaping right to embed one structure in another; they should be able to just edit text in the box, and the editor worries about constructing the markup properly to describe the document.
We'll be freer to make use of things like escape sequences to disambiguate embedded structures if we know that most of the time it'll be a machine, not a human that's typing the |s (or occasionally |s) or worrying about whether there's a newline in a particular place or not -- these are things that power users doing hardcore template editing can mess with, without most people needing to worry about them.
-- brion
Thomas Dalton thomas.dalton@gmail.com writes:
On 2 May 2011 13:09, Roan Kattouw roan.kattouw@gmail.com wrote:
On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz maury.markowitz@gmail.com wrote:
Editors do this all the time anyway. Typically using automated tools so they don't have to do any actual work.
Sure, but those aren't typically mixed with "real" changes in the same edit. That's what was hard: spotting the actual changes in the midst of all the normalization noise.
The normalisation only really needs to happen once, though.
What about combining the benefits of separated automatic edits with the ease of WYSIWYG modification?
Upon starting to edit the page the WYSIWYG editor automatically makes a “normalization” edit. Such edits are noted with the comment “WYSIWYG Normalization” or some such so that they're easy to find.
When the user clicks “Save page”, a separate edit is made containing just the user's changes.
This seems like it would preserve the usefulness of diffs, doesn't it?
Question: why does it have to normalise at all?
I do think that the editing environment at Wikipedia means that consistent non-normalised editing by wikitext users and subsequent normalisation by anyone using WYSIWYG would be messy and disruptive, but would a change whereby it more precisely records the wikitext, and then doesn't try and change it unless that part of the document is edited, be feasible?
On 2 May 2011 19:34, Mark A. Hershberger mhershberger@wikimedia.org wrote:
Thomas Dalton thomas.dalton@gmail.com writes:
On 2 May 2011 13:09, Roan Kattouw roan.kattouw@gmail.com wrote:
On Mon, May 2, 2011 at 1:41 PM, Maury Markowitz maury.markowitz@gmail.com wrote:
Editors do this all the time anyway. Typically using automated tools so they don't have to do any actual work.
Sure, but those aren't typically mixed with "real" changes in the same edit. That's what was hard: spotting the actual changes in the midst of all the normalization noise.
The normalisation only really needs to happen once, though.
What about combining the benefits of separated automatic edits with the ease of WYSIWYG modification?
Upon starting to edit the page the WYSIWYG editor automatically makes a “normalization” edit. Such edits are noted with the comment “WYSIWYG Normalization” or some such so that they're easy to find.
When the user clicks “Save page”, a separate edit is made containing just the user's changes.
This seems like it would preserve the usefulness of diffs, doesn't it?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, May 2, 2011 at 11:54 AM, Alex alejrb@gmail.com wrote:
Question: why does it have to normalise at all?
I do think that the editing environment at Wikipedia means that consistent non-normalised editing by wikitext users and subsequent normalisation by anyone using WYSIWYG would be messy and disruptive, but would a change whereby it more precisely records the wikitext, and then doesn't try and change it unless that part of the document is edited, be feasible?
Indeed, that's the nicest thing to do.
-- brion
On 03/05/11 04:54, Alex wrote:
Question: why does it have to normalise at all?
I do think that the editing environment at Wikipedia means that consistent non-normalised editing by wikitext users and subsequent normalisation by anyone using WYSIWYG would be messy and disruptive, but would a change whereby it more precisely records the wikitext, and then doesn't try and change it unless that part of the document is edited, be feasible?
That's basically what it does already. There's no normalisation as such. For instance if you type <b>x</b> into the source view, you get
<b data-rte-washtml="1">x</b>
But if you type '''x''', you just get
<b>x</b>
If you type [[x|x]], you get an anchor tag with a data-rte-meta attribute containing:
{"type":"internal","text":"x","link":"x","wasblank":false,"noforce":true,"wikitext":"[[x|x]]"}
Whereas if you type [[x]], the data-rte-meta attribute is:
{"type":"internal","text":"x","link":"x","wasblank":true,"noforce":true,"wikitext":"[[x]]"}
These attributes are sent to the server, and in principle, the wikitext could be reconstructed precisely. There is a bug in the particular case of [[x|x]], it gets translated to [[x]] at some point, but lots of other cases work correctly.
If [[x|x]] is the only reason we're not using the WYSIWYG editor, let's just fix it. It's an isolated case, not an architectural issue.
-- Tim Starling
Roan Kattouw <roan.kattouw <at> gmail.com> writes:
While I'm sure this particular bug has been fixed, it sounds like the underlying problem remains. FCKeditor seems to be converting wikitext to HTML, let users edit the HTML, then convert the HTML back to wikitext. The bugs would then result from the fact that the wikitext->HTML->wikitext round-trip (or wikitext->whatever internal representation is used->wikitext) isn't clean.
Hi, I work at Wikia (although I am relatively new and I have only made small modifications to the editor). This basic criticism of the design is true and is still the source of issues, but it's been improving. I think another problem for experienced wiki editors is the "sea of puzzle pieces" that happens when you edit a complicated page, because it can't render templates (plus a bunch of other things it can't render that show puzzles)
We are currently almost finished with a look-and-feel revamp of the RTE, which is being rolled out over the next few weeks. A blog post about it can be read here:
http://community.wikia.com/wiki/User_blog:Sarah_Manley/A_Facelift_for_the_Ed...
I'd encourage those with an interest in such things to skim the comments, it's an interesting range of responses, but mostly positive. This re-skin is feature identical for users, but for developers it addresses the puzzle piece problem, which should allow us to more easily add custom widgets to render particular extension tags. It's not in this first release but we've also internally been experimenting with ways to render templates in a more useful way than a green puzzle piece.
I wish I could point to a running instance, but it will be out there soon and I'll put up a link to a test wiki asap if anyone is interested. Many of the look and feel changes are all specific to the custom skin that Wikia uses so I'm not sure how useful it is to others, but the code just got checked in to our trunk SVN this weekend:
http://trac.wikia-code.com/browser/wikia/trunk/extensions/wikia/EditPageResk...
Trevor and I talked about this issue about a year and a half ago, and figured the best way around round-trip bugs was to not do round-trips at all. Instead, wikitext or something close to it should be used as an internal representation, and/or only the parts of the page the user touches should actually change.
Internally we have discussions about the future of the RTE but they are still at the "grand vision" stage to be honest. I think the current plan is to see what transpires with the upcoming Parser redesign and keep our code in sync. The primary authors of this RTE reskin will be at the Berlin hackathon as well.
I'm also happy to field any particular questions about the RTE and get them sent to the right people here at Wikia.
Owen Davis
On Mon, May 2, 2011 at 3:40 PM, Owen Davis owen@wikia-inc.com wrote:
Hi, I work at Wikia (although I am relatively new and I have only made small modifications to the editor).
Hi!
This basic criticism of the design is true and is still the source of issues, but it's been improving. I think another problem for experienced wiki editors is the "sea of puzzle pieces" that happens when you edit a complicated page, because it can't render templates (plus a bunch of other things it can't render that show puzzles)
Note that for Wikipedia that's not just going to affect experienced editors -- it will affect *everyone*, since just about every article includes templates and tag hook extensions for references etc, and we strongly encourage editors to make use of them liberally. It needs to be very easy to create, review, and edit them.
This re-skin is feature identical for users, but for
developers it addresses the puzzle piece problem, which should allow us to more easily add custom widgets to render particular extension tags. It's not in this first release but we've also internally been experimenting with ways to render templates in a more useful way than a green puzzle piece.
Do you mean that it doesn't yet provide any way to see and edit the contents of templates and tag hook extensions, but that infrastructure has come in which will make it possible in the future?
-- brion
Brion Vibber <brion <at> pobox.com> writes:
Note that for Wikipedia that's not just going to affect experienced editors
Very true! I think we have more inexperienced editors, and that's been a product design focus for us for a while so I tend to make assumptions based on that.
Do you mean that it doesn't yet provide any way to see and edit the contents of templates and tag hook extensions, but that infrastructure has come in which will make it possible in the future?
Yep, that's my understanding. We have added custom editing tools for a few home grown Wikia things but it's painful and requires modifications to the Parser and I don't recommend looking at that code. :) One of the internal goals was to make that easier and my understanding is it's been done. I don't know the details yet, we are getting a full presentation on it next week by the developer. For templates, the proposal just showed them expanded/rendered in the page but read-only and I'm not sure if that's going to be in the product or not. For tags, there are hooks that allow the extension developer to put up a modal edit/design mode, and since those are just simple HTML templates and ajax calls, it's a lot easier to develop.
An example of that is here (in the old editor, done the old way with an ugly parser hack).
http://kirkburn.wikia.com/index.php?title=PollTest8&action=edit
On 05/02/2011 06:40 PM, Owen Davis wrote:
I think the current plan is to see what transpires with the upcoming Parser redesign and keep our code in sync. The primary authors of this RTE reskin will be at the Berlin hackathon as well.
Who are those authors? I'd like to know so I can find them in Berlin and drag them into any relevant discussions, etc.
-Sumana Harihareswara
Some of them are already going. After talking with some of them about our new parser and editor plans, and that we would be doing work on that in Berlin, they said they were likely to send some people. Obviously it's up to a variety of factors how many of Wikia's people show up, but we do know that they are aware of the topics, the relevance of their work and what will be done at the conference, and have shown interest.
Historically, Wikia sends a few people each year, and often presents on something they are working on.
- Trevor
On Mon, May 2, 2011 at 5:26 PM, Sumana Harihareswara sumanah@panix.comwrote:
On 05/02/2011 06:40 PM, Owen Davis wrote:
I think the current plan is to see what transpires with the upcoming Parser redesign and keep our code in sync. The primary authors of this RTE reskin will be at the Berlin hackathon as well.
Who are those authors? I'd like to know so I can find them in Berlin and drag them into any relevant discussions, etc.
-Sumana Harihareswara
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Tim Starling <tstarling <at> wikimedia.org> writes:
Years ago, we talked dismissively about WYSIWYG. We discussed the features that a WYSIWYG editor would have to have, pointing out how difficult they would be to implement and how we didn't have the manpower to pull off such a thing. Now that Wikia has gone ahead and implemented those exact features, what is the problem?
In addition to the whole "unecessary changes" issue, I always thought part of it was that, due to parser quirks that Wikipedia editors have long relied upon, the editor handles a non-negligible number of pages incorrectly.
(This was less of an issue for Wikia, with the much newer nature of most of their wikis.)
The conclusion, then, would be that "no WYSIWYG" is better than "WYSIWYG (normally)". Not sure where I got this idea from; correct me if I'm wrong.
-- Harry (User:Jarry1250)
wikitech-l@lists.wikimedia.org