Re: [Wikitech-l] Alternate/remote editor API?
Yeap, building on WikiEditor stuff is always a good idea! Though, in my experience with the InlineEditor extension, it's quite hard if you want to build a totally different interface. It would be awesome to refactor EditPage sometime to make this easier, and to provide a nice preference with a drop-down to select an editing interface. The relevant bug is 26918 [1] (which has actually been created because of a comment by yourself, Brion :)) The way I solved this was to create a subclass of EditPage with just enough code copy/pasted to suit my needs ;) [2]. For the API some hacking in EditPage has been done, and the class description also talks about a possible refactoring of EditPage [3]. Anyway, just a thought for the backend part of an alternate/remote editor API, for extensions that want to do more than replacing the textbox. :) Cheers, Jan Paul [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=26918 [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ExtendedEditPage.class.php?revision=83338&view=co [3] http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api/ApiEditPage.php?view=co On 6-May-2011, at 20:22, Brion Vibber wrote: > On Fri, May 6, 2011 at 11:20 AM, Trevor Parscal wrote: > >> The way the WikiEditor works right now, the textbox can be replaced with >> anything that can support a few methods, such as getSelection, >> encapsulateSelection, etc. There are some modules that depend on specific >> edit box implementations, such as the current and only alternative to the >> textarea we called "iframe" since it's a contentEditable iframe. >> >> If you take a look at jquery.wikiEditor.iframe.js, you will see what I >> mean. >> It should be pretty straightforward to drop anything in there, and be able >> to take advantage of the toolbar. There are some things, like find and >> replace that may need to be reworked or just turned off, but even things >> like the link dialog should work just fine but just supporting a few >> methods. >> >> The API could be better documented, and re-factored a bit to be even more >> generic, but the basic structure is there, and can be reused without much >> hacking. >> > > Spiffy... I'll play with it for CodeEditor, see if I can make the > special-char inserts for instance work on it (which would actually be useful > for some JS!). > > -- brion > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [GSoC 2011] Introduction + About some ideas
Hey Sagie, Indeed, thanks for your interest in doing a MediaWiki GSoC project! Benedikt already said a bit about in-line editing for MW/SMW. It started out as a research project, but last months there has been some real progress to make it into a usable extension, eventually (hopefully ;)) to be deployed on major wikis. This has been done by myself in close collaboration with Greek researchers from GRNET, who are currently doing usability testing with the latest interface. Next few months I'll be working for WMF as a contractor, which means that hopefully I can work a bit on the InlineEditor extension, but obviously other things have to be done too. Therefore, it would be cool to continue development of the extension as a GSoC project, and I'd be happy to mentor you if you'd choose this project. One of the things that has to be done, is to make sure the editor works fine on the majority of pages: we can even set a quantitative metric for this (e.g. 99% or something). The long term approach for this is the development of a new parser, which is one of the things WMF will be working at. A more short term option is to develop a bit more along the lines of the matching framework currently used in the InlineEditor extension. This means you can work on "conservative" matching of wikitext structures, multi-language sentence boundary disambiguation, detection of incorrect matching of elements (e.g. by detecting misnesting); which all has to be done in a performant and secure matter. Seems like interesting stuff for a CS and linguistics student! :) Other things might include building specialised interfaces for e.g. templates, media and references; calculating robustness metrics to see if we can make this 99%; and making the extension production-ready by integrating the current functions such as conflict resolving. SMW is not really my expertise, so if you want to involve that in your project as well we should find another mentor who can assist in that matter. I hope this gives you a good picture of what working on in-line editing might look like. Please ask if you want to know more about it! Cheers, Jan Paul On 25-Mar-2011, at 10:37, Sagie Maoz wrote: > Hi guys, > > My name is Sagie, I'm a first-year CS and linguistics student at Tel-Aviv > University. I'm applying for GSoC this summer and wanted to introduce myself. > I actually talked with some of you on #mediawiki last night, under the handle > "n0nick". > > I've been a professional web developer for 6 years, mostly done PHP work. I'm > fairly familiar with web & wiki frameworks in general, and have had some > (short) experience with MediaWiki. > > I'd like to read your thoughts on the following projects I had my eyes on: > > * Inline Editing extension for MW/SMW > Sounds like a very interesting and useful project to work on, and seems to me > it fits the timeframe. > I saw that there's been a lot of work done already for this task by user > janpaul123, and was wondering what's the status of this project and how I can > help with making this a possible GSoC project. > > * Sidebar/toolbar customization GUI > I understand there's overhaul work being done on element skin systems, but I > talked with Dantman about the sidebar customization and from what I > understand, it's possible to take this project as long as my work is abstract > (and good) enough. > Anyone has other thoughts on this? Should I perhaps avoid working on > something that might interfere with current developers work? > > * Email notifications > Again, I see in the wiki page that some work has been done on this, and > testing and bugfixing is required. > Do you think it could be a suitable summer project? > > > Would love to hear your thoughts. > Thanks, > > -- > Your friend in time, > Sagie Maoz > sa...@maoz.info // +1 (347) 556.5044 // +972 (52) 834-3339 > http://sagie.maoz.info/ http://n0nick.net/ > > /* simba says roar! */ > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing / InlineEditorextensionupdate
Hey Janesh, > We tested inline edior installation too. > http://www.pragmatictestlabs.com/pragmaticwiki/ Great! The bugs you filed in Bugzilla will be looked at by GRNET developers soon. :) I'll also add some suggestions and bugs from the mailinglist to Bugzilla this weekend. Thanks again for the testing! Cheers, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Parser postprocessor
Usually I don't reply that much on other threads, but for this: +1. Jan Paul On 31-Jan-2011, at 22:55, Trevor Parscal wrote: > Adding yet another discreet parsing step is the reverse of what a lot of > people hoping to clean up wikitext are heading towards. > > What some of us have been kicking around would be migrating away from > pre-procesing the text at all. Instead the text should be parsed in a single > step into an intermediate structure that is neither wikitext nor HTML. > Templates would be required to return whole structures when expanded (open > what you close, close what you open) and would only be present in sanitary > places (not in the middle of wiki or HTML syntax for instance). > > Once the document is in this intermediate structure, it would still contain > enough information about where it came from to make a round trip without a > dirty diff. Alternatively (and more usefully) template elements would be > expanded and the resulting structure would be renderable into a variety of > output formats such as HTML, PDF, a lightweight version of the HTML (for > mobile devices) or even plain text. > > Because the rendered output can be much more configurable, structured and > regular than our current output, it would be more reasonable to perform > additional transformations on it if a skin needed to. > > - Trevor > > On Jan 31, 2011, at 1:31 PM, Daniel Friesen wrote: > >> An interesting idea just popped into my head, as a combination of my >> explorations through the dom preprocessor and my attempt at deferring >> editsection replacement till after parsing is done so that skins can >> modify the markup used in an editsection link in a skin-specific way >> without breaking things, and so that we can stop fragmenting the parser >> cache by user language just for edit section links. >> >> A postprocessor. It would be quite interesting if instead of html we >> started outputting something like this in our parser output: >>foo
> page="Foo" >> section="1">barbar
baz
foo
bar
baz
>> ((don't get scarred off by all the entities, this is nothing new, try >> looking at a preprocess-xml cache entry)) >> >> Course this is a Postprocessor_DOM oriented look, like Preprocessor_Hash >> we'd have a Postprocessor_Hash and it would store a different format >> like we already do with Preprocessor_Hash (serialized?). >> >> The idea being the creation of new markers that aren't 100% parsed but >> are outputted in a easy to deserialize format and finish parsing with >> minimal work and extensions can output and have a postprocessor hook >> expand later on. In essence the idea here is two fold. >> Firstly things like the > section="1">bar I tried to introduce now is no longer a >> hack. And we can try to start deferring minimal processing cost things >> which fragment the parser cache if they aren't needed. Ideally in the >> future if something like {{int:asdf}} isn't used in a [[]] or in a >> parser function and is just a base level bit of display isolated from >> the rest of the WikiText we might be able to output it in a way that we >> don't have to fragment the cache by user lang but can still output the >> message in the user's lang by deferring it. >> And as a big extra bonus, think of the RandomSelection extension. Right >> now extensions like RandomSelection end up disabling the entire parser >> cache for a page, just so they can output a random one of a series of >> options. With a postprocessor they could instead craft partially parsed >> output where all the normal wikitext is still parsed, but all the >> options given in the source text are outputted and the postprocessor >> handles the actual random selection on each page view, only outputting >> one of the three html nodes. >> Likewise we might be able to implement "Welcome {{USERNAME}}!" without >> fragmenting the cache by user or having to disable it. >> >> The key being that we get things as variable as complete randomness, at >> the level of re-executing that randomness on each page view, yet have >> barely any more processing to do than we did before. (like the rest of >> the ui that isn't part of the page content) >> >> -- >> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] >> >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing / InlineEditor extensionupdate
> Few bugs and a enchantement are reported. > We will continue with bit of boundary testing. Thanks! :) > Is it a good idea to keep a track of enhancements/bugsposted by others? > I mean recording them in Bugzilla I'll add the suggestions of the mailinglist to bugzilla somewhere next week. Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing / InlineEditor extension update
On 27-Jan-2011, at 0:04, Platonides wrote: > Jan Paul Posma wrote: > >>> I completely missed the "You can edit the article below, by clicking on >>> blue elements in the page." line. Only found after thinking "this needs >>> some kind of notice on how to edit, since it's not clear what to do to >>> change the page...". >> >> in usability testing I also found that people don't read texts like that at >> all. >> That's one of the reasons I removed the different edit modes. It was > also clear, >> however, that just by moving the mouse over the screen and seeing text being >> highlighted, >> there wasn't any need to read that kind of notices, as all users understood >> the concept >> very quickly. After that they would search for a save button, and would find >> the publish >> button after looking around for a bit. > > That's precisely the kind of things you want to find out from a > usability study. That's why I reported it, not only to show the world > how dumb I am :) > My eyes moved from "Awesome, you are editing Wikipedia!" to "Can you > briefly describe the changes you're making?" completely missing it on > the first scan. Worse, I also wondered for a few seconds where was the > edit box. Haha, yep, that's obviously what's going to happen to current editors with any new interface as radical as this ;) > You need to move the mouse and click to really be sure you're doing it > the right way. > Having the text about blue elements on a (lighter) blue box may not be a > good idea. Good point! Perhaps a grey or white box with blue outline also fits better in the current Vector design. > A few other improvements: > When you open the "line editor" you get the options 'Preview' and > 'Cancel'. It's a bit puzzling not having a button to Save, so I would > rename the first one to "Change", and maybe delay showing the Publish > button until you have done one Change. That needs testing with longer > articles, though. Although that would also allow us to reuse the upper > space for both telling them to click lines, and -after they discover it- > showing the "Remember to press Publish". The text "Preview" was chosen very specifically to indicate that it will not be saved/published right away, as you might think with "Change". This might prohibit new users from starting to experiment as they fear the changes will instantly be visible. On the other hand, I've had many comments on the "Preview" text from the participants of the usability tests. So in the end I'd rather have a label that is a bit weirder at first, but conveys the message of how the interface works better. Your suggestion of showing a remember text later is one I've also thought about. However, it doesn't take away the fear of editing at first. Another way to signal to users that their first changes aren't published, is the text When you're done, don't forget to publish the page!", which also indicates that nothing happens before hitting the publish button. Anyway, I'm not a professional copywriter ;) so yeah, I've heard some good suggestions out there. If you're interested in this kind of "micro" interface design, check out the rationale for the current texts: http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing/Prototypes/Prototype_2 I'm not quite sure if this is something to really think about now or in a later stage of the design (it's still possible that things will change a lot), but it's an interesting discussion nevertheless :) Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing / InlineEditor extension update
> We have found few bugs and enhancements to be reported. > What is the appropriate component for this project. > https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions > I cannot locate InlineEditor. Inline scripts if the correct component? Ah, looking forward to see what you've come up with! Like Roan and Chad said, the InlineEditor component is now in the list, so you can add bugs there. > Very cool. Took me a minute to figure out how to use it, but once I did I > really liked it. I think the user should have some way to correct any > incorrectly parsed sentences though. Doing this would help develop a better > sentence boundary parser in the long run too. Yeah, thought about that, but I think that anything not related to actually editing the wikitext might be distracting and confusing, so I would recommend not do do this. > I completely missed the "You can edit the article below, by clicking on > blue elements in the page." line. Only found after thinking "this needs > some kind of notice on how to edit, since it's not clear what to do to > change the page...". in usability testing I also found that people don't read texts like that at all. That's one of the reasons I removed the different edit modes. It was also clear, however, that just by moving the mouse over the screen and seeing text being highlighted, there wasn't any need to read that kind of notices, as all users understood the concept very quickly. After that they would search for a save button, and would find the publish button after looking around for a bit. If you have suggestions how to make it more clear how this works it would be appreciated, but there already is a minimum of text and notices on the screen right now. Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sentence-level editing / InlineEditor extension update
Hey all, I've been working on the InlineEditor extension again, primarily working on a new interface that doesn't use the different edit modes anymore, as the usability testing showed that this was not the right approach. Luckily, without a change in the underlying algorithms, it was doable to combine all the edit modes into one interface. This also resulted in the deletion of tens of files plus hundreds of lines of code [1], which usually is a good thing, because it shows it's a simpler and more natural approach. If you're interested in testing this on your own wiki or looking at the code, grab your copy from SVN. [2] If you're interested in testing this, a wiki has been set up here: http://janpaulposma.nl/sle/wiki As you might know, some more usability testing will be done soon by GRNET [3], so we can see if this interface works better or not. Feel free to ask questions and throw in suggestions, etc. Best regards, Jan Paul [1] http://www.mediawiki.org/w/index.php?path=%2Ftrunk%2Fextensions%2FInlineEditor&title=Special%3ACode%2FMediaWiki%2Fpath [2] http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/InlineEditor/ [3] https://code.grnet.gr/projects/wikipedia-wysiwyg/wiki ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] helping in WYSIWYG editor efforts
1. Yeah, that's a problem, my usability research was also only in Dutch. What you can do is publish notes with the videos in English. You can even have these notes taken while doing the usability test (e.g. by someone else sitting in the room). 2. The format used at Commons is OGV, so it has to be transcoded. It'd be cool to see the videos though, I'm really curious to see how the participants will work with the different interfaces. But if it's too time-consuming, you shouldn't do it. Cheers, Jan Paul On 22-Jan-2011, at 17:31, Panos Louridas wrote: > We could, if the people captured agree. Two caveats: > > (1) Much of the audio could be all Greek to most. > > (2) Does releasing to Wikimedia Commons requiring transcoding to an open > format? > > On Jan 22, 2011, at 4:59 PM, Jan Paul Posma wrote: > >> I used the open source Camstudio, but (1) seems to be better as you can >> simultaneously capture the camera image. One question I didn't think of >> during the meeting: are you planning on releasing the videos online (e.g. on >> Wikimedia Commons)? >> >> Cheers, >> Jan Paul >> >> On 22-Jan-2011, at 14:29, Panos Louridas wrote: >> >>> Picking up on the usability testing, >>> >>> Since we do not have a dedicated usability lab (but we do have people that >>> have carried out usability studies), we will have to create something >>> ourselves. >>> >>> I understand that the basic requirements are the ability to capture both >>> the screen and the user; and to capture them in a synchronized way. >>> >>> From some research that we did, we came up with the following setups: >>> >>> (1) Telestream ScreenFlow >>> (http://www.telestream.net/screen-flow/overview.htm) >>> >>> (2) Mac OS 10.6 podcast capture (but this requires a podcast server, i.e., >>> Mac OS 10.6 server, and I am not sure it's worth it). >>> >>> (3) Matterhorn capture (http://www.opencastproject.org/matterhorn_capture) >>> >>> We are leaning towards solution (1). We welcome any comments, any >>> alternative solutions that we may explore, or any arguments for (2) and (3). >>> >>> Cheers, >>> >>> Panos. >>> >>> On Jan 21, 2011, at 4:07 PM, Jan Paul Posma wrote: >>> >>>> So a few minutes ago we've had a conversation about this. Panos will set >>>> up a public collaboration space within GRNET. A few developers will be >>>> (part-time) working on this from February for a (so far) unspecified >>>> amount of time. The consensus was that it would be good to start off with >>>> some basic usability testing, to see how well the different tools work for >>>> novice users. It'll be very basic testing, with about 10 subjects from >>>> within GRNET (so with a bit of technical bias) but only those who haven't >>>> edited before. >>>> >>>> Both Magnus' and my tools will be implemented on a clone of the Greek >>>> Wikipedia and we will set up a fabricated article that works well with >>>> both of our editors. It's only about the usability, not about technical >>>> aspects for now. Both editing tools will have to be adapted and localised, >>>> perhaps this can even be done by GRNET developers. We'll use my usability >>>> script that I used before with the Sentence-Level Editing usability >>>> research. >>>> >>>> Once this usability testing has been done, we'll decide how to distribute >>>> the efforts, and what will be done. We'll work closely with the GRNET >>>> developers to assist them in working on these projects. Once we'll have >>>> more information it will be posted to this list. >>>> >>>> Cheers, >>>> Jan Paul >>>> >>>> On 19-Jan-2011, at 23:34, Magnus Manske wrote: >>>> >>>>> I have added Panos to Skype; yes, we should probably exchange Skype >>>>> handles off-list. >>>>> >>>>> I am in Cambridge (London time), so that should work. >>>>> >>>>> Cheers, >>>>> Magnus >>>>> >>>>> >>>>> On Wed, Jan 19, 2011 at 8:34 PM, Jan Paul Posma >>>>> wrote: >>>>>> Skype sounds great! Also, I heard you work with Ariel, which is great >>>>>> because that way you have a more local person to c
Re: [Wikitech-l] helping in WYSIWYG editor efforts
I used the open source Camstudio, but (1) seems to be better as you can simultaneously capture the camera image. One question I didn't think of during the meeting: are you planning on releasing the videos online (e.g. on Wikimedia Commons)? Cheers, Jan Paul On 22-Jan-2011, at 14:29, Panos Louridas wrote: > Picking up on the usability testing, > > Since we do not have a dedicated usability lab (but we do have people that > have carried out usability studies), we will have to create something > ourselves. > > I understand that the basic requirements are the ability to capture both the > screen and the user; and to capture them in a synchronized way. > > From some research that we did, we came up with the following setups: > > (1) Telestream ScreenFlow (http://www.telestream.net/screen-flow/overview.htm) > > (2) Mac OS 10.6 podcast capture (but this requires a podcast server, i.e., > Mac OS 10.6 server, and I am not sure it's worth it). > > (3) Matterhorn capture (http://www.opencastproject.org/matterhorn_capture) > > We are leaning towards solution (1). We welcome any comments, any alternative > solutions that we may explore, or any arguments for (2) and (3). > > Cheers, > > Panos. > > On Jan 21, 2011, at 4:07 PM, Jan Paul Posma wrote: > >> So a few minutes ago we've had a conversation about this. Panos will set up >> a public collaboration space within GRNET. A few developers will be >> (part-time) working on this from February for a (so far) unspecified amount >> of time. The consensus was that it would be good to start off with some >> basic usability testing, to see how well the different tools work for novice >> users. It'll be very basic testing, with about 10 subjects from within GRNET >> (so with a bit of technical bias) but only those who haven't edited before. >> >> Both Magnus' and my tools will be implemented on a clone of the Greek >> Wikipedia and we will set up a fabricated article that works well with both >> of our editors. It's only about the usability, not about technical aspects >> for now. Both editing tools will have to be adapted and localised, perhaps >> this can even be done by GRNET developers. We'll use my usability script >> that I used before with the Sentence-Level Editing usability research. >> >> Once this usability testing has been done, we'll decide how to distribute >> the efforts, and what will be done. We'll work closely with the GRNET >> developers to assist them in working on these projects. Once we'll have more >> information it will be posted to this list. >> >> Cheers, >> Jan Paul >> >> On 19-Jan-2011, at 23:34, Magnus Manske wrote: >> >>> I have added Panos to Skype; yes, we should probably exchange Skype >>> handles off-list. >>> >>> I am in Cambridge (London time), so that should work. >>> >>> Cheers, >>> Magnus >>> >>> >>> On Wed, Jan 19, 2011 at 8:34 PM, Jan Paul Posma wrote: >>>> Skype sounds great! Also, I heard you work with Ariel, which is great >>>> because that way you have a more local person to contact with MediaWiki >>>> questions. Perhaps we can get off-list with those interested to schedule >>>> an introductory meeting? (You, me, Magnus, Ariel, others?) I am located in >>>> the Netherlands, so our hours will be similar. >>>> >>>> Cheers, >>>> Jan Paul >>>> >>>> On 19-Jan-2011, at 19:47, Panos Louridas wrote: >>>> >>>>> Thanks to both Jean Paul and Magnus for taking up the offer! >>>>> >>>>> Based on your input I will look into our developer tool for people with >>>>> expertise in the following: >>>>> >>>>> * Advanced JS, preferably with experience in optimisation issues etc. >>>>> >>>>> * UI design, usability testing, etc. >>>>> >>>>> * Text processing (of sorts) for the needs of SLE >>>>> >>>>> (if you believe I am missing something, say so) >>>>> >>>>> I expect to have the people in place in February, I will let you know. I >>>>> will be following the list. >>>>> >>>>> Jean Paul indicated that we might talk in more detail. I do not follow >>>>> IRC because of my tight schedule; I do use Skype, however (ID: louridas). >>>>> Please Jean Paul, Magnus, and others, let me know if that suits you. As I >>&g
Re: [Wikitech-l] helping in WYSIWYG editor efforts
So a few minutes ago we've had a conversation about this. Panos will set up a public collaboration space within GRNET. A few developers will be (part-time) working on this from February for a (so far) unspecified amount of time. The consensus was that it would be good to start off with some basic usability testing, to see how well the different tools work for novice users. It'll be very basic testing, with about 10 subjects from within GRNET (so with a bit of technical bias) but only those who haven't edited before. Both Magnus' and my tools will be implemented on a clone of the Greek Wikipedia and we will set up a fabricated article that works well with both of our editors. It's only about the usability, not about technical aspects for now. Both editing tools will have to be adapted and localised, perhaps this can even be done by GRNET developers. We'll use my usability script that I used before with the Sentence-Level Editing usability research. Once this usability testing has been done, we'll decide how to distribute the efforts, and what will be done. We'll work closely with the GRNET developers to assist them in working on these projects. Once we'll have more information it will be posted to this list. Cheers, Jan Paul On 19-Jan-2011, at 23:34, Magnus Manske wrote: > I have added Panos to Skype; yes, we should probably exchange Skype > handles off-list. > > I am in Cambridge (London time), so that should work. > > Cheers, > Magnus > > > On Wed, Jan 19, 2011 at 8:34 PM, Jan Paul Posma wrote: >> Skype sounds great! Also, I heard you work with Ariel, which is great >> because that way you have a more local person to contact with MediaWiki >> questions. Perhaps we can get off-list with those interested to schedule an >> introductory meeting? (You, me, Magnus, Ariel, others?) I am located in the >> Netherlands, so our hours will be similar. >> >> Cheers, >> Jan Paul >> >> On 19-Jan-2011, at 19:47, Panos Louridas wrote: >> >>> Thanks to both Jean Paul and Magnus for taking up the offer! >>> >>> Based on your input I will look into our developer tool for people with >>> expertise in the following: >>> >>> * Advanced JS, preferably with experience in optimisation issues etc. >>> >>> * UI design, usability testing, etc. >>> >>> * Text processing (of sorts) for the needs of SLE >>> >>> (if you believe I am missing something, say so) >>> >>> I expect to have the people in place in February, I will let you know. I >>> will be following the list. >>> >>> Jean Paul indicated that we might talk in more detail. I do not follow IRC >>> because of my tight schedule; I do use Skype, however (ID: louridas). >>> Please Jean Paul, Magnus, and others, let me know if that suits you. As I >>> am located in Athens, my waking hours are around East European Time. >>> >>> Cheers, >>> >>> Panos. >>> >>> On Jan 19, 2011, at 3:54 PM, Jan Paul Posma wrote: >>> >>>> A very generous offer indeed! >>>> >>>> My own SLE and Magnus' WYSIFTW are indeed the most active projects, so >>>> that would be a good bet. Actually, for me the timing is just right, as >>>> I'll be working on a paper about this editor for a while, so it'd be cool >>>> to have someone(s) continue the project. If one of your researchers has a >>>> brilliant idea on how to do this right, that would obviously be really >>>> valuable too. >>>> >>>> A lot of things Magnus mentioned apply to my project too: >>>> * Improving detection algorithms, i.e. better sentence-level editing >>>> (perhaps using an external language recognition library), better detection >>>> of other elements. Keep in mind that the editor excludes anything it >>>> doesn't 'understand', so this is a nice fallback, you don't have to write >>>> a complex parser that detects a lot of stuff at once. >>>> * Cross-browser/platform/device compatibility (think mobile, touchscreens, >>>> etc.) >>>> * Usability testing (the more the merrier!) >>>> * Verifying detection coverage (Which % of the wikitext is editable) and >>>> quality (Wikitext -> Adding markers -> MediaWiki parser -> Removing >>>> markings -> Wikitext??) Checking this on a large number of pages. >>>> * Test suites (again, the more the merrier, but only for parts of the code >>>> and in
Re: [Wikitech-l] helping in WYSIWYG editor efforts
Skype sounds great! Also, I heard you work with Ariel, which is great because that way you have a more local person to contact with MediaWiki questions. Perhaps we can get off-list with those interested to schedule an introductory meeting? (You, me, Magnus, Ariel, others?) I am located in the Netherlands, so our hours will be similar. Cheers, Jan Paul On 19-Jan-2011, at 19:47, Panos Louridas wrote: > Thanks to both Jean Paul and Magnus for taking up the offer! > > Based on your input I will look into our developer tool for people with > expertise in the following: > > * Advanced JS, preferably with experience in optimisation issues etc. > > * UI design, usability testing, etc. > > * Text processing (of sorts) for the needs of SLE > > (if you believe I am missing something, say so) > > I expect to have the people in place in February, I will let you know. I will > be following the list. > > Jean Paul indicated that we might talk in more detail. I do not follow IRC > because of my tight schedule; I do use Skype, however (ID: louridas). Please > Jean Paul, Magnus, and others, let me know if that suits you. As I am located > in Athens, my waking hours are around East European Time. > > Cheers, > > Panos. > > On Jan 19, 2011, at 3:54 PM, Jan Paul Posma wrote: > >> A very generous offer indeed! >> >> My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that >> would be a good bet. Actually, for me the timing is just right, as I'll be >> working on a paper about this editor for a while, so it'd be cool to have >> someone(s) continue the project. If one of your researchers has a brilliant >> idea on how to do this right, that would obviously be really valuable too. >> >> A lot of things Magnus mentioned apply to my project too: >> * Improving detection algorithms, i.e. better sentence-level editing >> (perhaps using an external language recognition library), better detection >> of other elements. Keep in mind that the editor excludes anything it doesn't >> 'understand', so this is a nice fallback, you don't have to write a complex >> parser that detects a lot of stuff at once. >> * Cross-browser/platform/device compatibility (think mobile, touchscreens, >> etc.) >> * Usability testing (the more the merrier!) >> * Verifying detection coverage (Which % of the wikitext is editable) and >> quality (Wikitext -> Adding markers -> MediaWiki parser -> Removing markings >> -> Wikitext??) Checking this on a large number of pages. >> * Test suites (again, the more the merrier, but only for parts of the code >> and interface that are considered stable!) >> * Lots of implementation details: embedding the (current) editor toolbar in >> the textboxes, making sure (a fair percentage of) gadgets still work with >> this, and handling unusual cases like edit conflicts, etc. >> >> Perhaps it'd be good to have a (video or IRC?) conversation with you, your >> developers, people from the Foundation, and people from the specific >> projects you want to contribute to. Again, really awesome that you guys want >> to work on this! :-) >> >> Best regards, >> Jan Paul >> >> On 19-Jan-2011, at 9:55, Magnus Manske wrote: >> >>> On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas wrote: >>>> Hi, >>>> >>>> At the Greek Research and Education Network (GRNET) we look at the >>>> possibility of contributing to the development of WYSIWYG editor support >>>> in Wikipedia. We understand that considerable work has already taken place >>>> in the area, e.g.: >>>> >>>> * http://www.mediawiki.org/wiki/WYSIFTW >>>> * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ >>>> * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing >>>> >>>> We therefore think that it will not be productive to reinvent the wheel >>>> over here. >>>> >>>> Our contribution can take the form of providing developers that will >>>> devote part (or all) of their time for some months in 2011. We welcome any >>>> comments and suggestions on how we could push this forward, and in >>>> particular: >>>> >>>> * Specific tasks / components that need to be designed, developed, >>>> optimized, etc., and estimates of effort and timeframe. >>> >>> Hi Panos, >>> >>> a very generous offer! One I would like to take you up on, for WYSIFTW >>> as you no doub
Re: [Wikitech-l] helping in WYSIWYG editor efforts
A very generous offer indeed! My own SLE and Magnus' WYSIFTW are indeed the most active projects, so that would be a good bet. Actually, for me the timing is just right, as I'll be working on a paper about this editor for a while, so it'd be cool to have someone(s) continue the project. If one of your researchers has a brilliant idea on how to do this right, that would obviously be really valuable too. A lot of things Magnus mentioned apply to my project too: * Improving detection algorithms, i.e. better sentence-level editing (perhaps using an external language recognition library), better detection of other elements. Keep in mind that the editor excludes anything it doesn't 'understand', so this is a nice fallback, you don't have to write a complex parser that detects a lot of stuff at once. * Cross-browser/platform/device compatibility (think mobile, touchscreens, etc.) * Usability testing (the more the merrier!) * Verifying detection coverage (Which % of the wikitext is editable) and quality (Wikitext -> Adding markers -> MediaWiki parser -> Removing markings -> Wikitext??) Checking this on a large number of pages. * Test suites (again, the more the merrier, but only for parts of the code and interface that are considered stable!) * Lots of implementation details: embedding the (current) editor toolbar in the textboxes, making sure (a fair percentage of) gadgets still work with this, and handling unusual cases like edit conflicts, etc. Perhaps it'd be good to have a (video or IRC?) conversation with you, your developers, people from the Foundation, and people from the specific projects you want to contribute to. Again, really awesome that you guys want to work on this! :-) Best regards, Jan Paul On 19-Jan-2011, at 9:55, Magnus Manske wrote: > On Mon, Jan 17, 2011 at 1:47 PM, Panos Louridas wrote: >> Hi, >> >> At the Greek Research and Education Network (GRNET) we look at the >> possibility of contributing to the development of WYSIWYG editor support in >> Wikipedia. We understand that considerable work has already taken place in >> the area, e.g.: >> >> * http://www.mediawiki.org/wiki/WYSIFTW >> * https://svn.wikia-code.com/wikia/trunk/extensions/wikia/RTE/ >> * http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing >> >> We therefore think that it will not be productive to reinvent the wheel over >> here. >> >> Our contribution can take the form of providing developers that will devote >> part (or all) of their time for some months in 2011. We welcome any comments >> and suggestions on how we could push this forward, and in particular: >> >> * Specific tasks / components that need to be designed, developed, >> optimized, etc., and estimates of effort and timeframe. > > Hi Panos, > > a very generous offer! One I would like to take you up on, for WYSIFTW > as you no doubt have guessed :-) > > WYSIFTW is approaching feature completeness, as far as wiki markup > parsing is concerned, and improves on usability as well. (just try the > new "floating context hover boxes", in lack of a better name, that I > added last night, wich come up when you hover over a template or a > references, for show/hide and rendered preview, and the new optional > rendering for templates as a key-value-pair table) > > For support later this year, tasks would include > * increase parsing performance (mostly post-parsing steps, focusing on > DOM lookup and manipulation) > * improve editing usability (cut/copy/paste, better specialised > dialogs for images, table/row/cell properties etc.) > * usability testing (I'm using up volunteers fast ;-) > * creating a test suite (to make sure that changes don't accidentally > break anything) > * general compatibility testing (find pages that parse/unparse > wrongly, and patch the code accordingly) > > I like the sentence-level editing function, but once I add > section-level editing to WYSIFTW, these two will start to converge. > I'm curious which of these will be more suited to small fixes and > adding single sentences/references etc. > > As for RTE, I know little about. Apparently, it is not suitable for > Wikipedia in its current form. From brief looks at CKeditor, it might > be quite some work to make it behave nicely around parsed wikitext, as > used on Wikipedia. > > Cheers, > Magnus > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WYSIWTF working demo
> What I would like is some discussion about > * if this approach (working pseudo-WYSIWYG instead of unattainable > perfect WYSIWYG) is the way to go > * if the code I wrote would be a suitable basis for a system we can > throw at the general public > * if anyone is willing to help me with that > > As always, my code is GPL, and I would be more than happy if, in the > end, it would become "official" Foundation code, with staff that > supports it. Well, I can dream... You seem to want to do exactly the same thing as I'm doing, but in the browser only! Maybe you're interested in looking at http://janpaulposma.nl/sle/wiki, http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing, http://lists.wikimedia.org/pipermail/wikitech-l/2010-October/050031.html and http://commons.wikimedia.org/wiki/Category:Sentence-level_editing Anyway, I have also looked at doing parsing in the browser, which is quite interesting. WikiBasha also uses JS parsing, so maybe it's a good idea to look at that too. Trevor also made a JS parser, but I think it's not in SVN (yet). Regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sentence-level editing usability videos
Hi all, A short note for everyone interested in usability testing: the videos of the usability testing of sentence-level editing are available on Wikimedia Commons. Videos are in Dutch, transcripts/notes are in English. http://commons.wikimedia.org/wiki/Category:Sentence-level_editing Best wishes, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] InlineEditor / Sentence-Level Editing: usability review
Thanks for the replies!
There's a few hours of video material, so that might be a bit too much to
subtitle. Perhaps I'll find the time to make a compilation of the highlights,
though.
> A few points which may or may not have been raised before:
> * I think editing inline like this eliminates or lessens the need for
> a WYSIWYG editor because it already is very direct.
> * Serverside parsing with AJAX, good choise. No half-parser
> serverside, this way advanced users are ensured they can use all the
> syntax they know which would work in the full editor.
Yeah, still displaying wikitext and being able to use all wikitext codes is one
of the important design decisions. One of the goals of this interface is not to
replace the current editor, but to make it easier to do simple edits. Also, it
should encourage people to edit more often ("Increase participation", Wikimedia
strategy) and perhaps become regular editors one day, who would more often use
the current / full interface.
> * Currently the editmodes are indicated like tabs, which wrap around
> an instructional paragraph.
> I would recommand making the tabs indicate/wrap around the entire
> article below (just like Page, Discussion, View, Edit are tabs for the
> entire page, "Sentences, "Paragraphs" etc. would be tabs for the
> article part (Ie. full width, and perhaps a suddle border connecting
> the tabs with the article)
This is indeed something that could perhaps solve the problem of the users not
understanding these edit modes. I've got a few other ideas which I'll consider.
Some of them will make it into prototypes next year. If you've got an idea how
to present this in a better way, please respond!
> [snip; lots of bugs]
Those are known bugs which I intentionally did not fix. Once the interface and
user experience become more stable we can focus on making the code more stable!
Two users actually encountered another bug during the usability research, when
trying to add references. :)
> I must say I reallylike the general flow of the thing!
Thanks!
Best regards,
Jan Paul
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] InlineEditor / Sentence-Level Editing: usability review
Hey everyone,
Last week I've done some usability testing with my InlineEditor extension, to
see whether or not it's a good idea at all. I've still got to do formal
analysis, but that'll take a while, so for now I'll only share with you the
most important things I noticed while doing the tests.
First, a few remarks. The test group was heavily biased towards students of
Information Sciences, so towards above average intelligence and familiarity
with codes and programming. There were 3 test groups, testing both versions of
the editor (one where you can select an edit mode like "Sentences",
"References", "Media", etc., and one where you can select "Sentences",
"Paragraphs", "Sections") and a control group.
1. The editing of sentences was great the new way. Users were much more
comfortable seeing the article and being able to directly manipulate it.
2. Users did not really notice the other editing options. This is a huge
problem, as the whole idea of this editor is to show the user an increasing
amount of wikitext complexity. When users did notice it...:
a. In the case of the functional edit options ("References", "Media", etc.),
users used this more as a help center and then proceeded to the full (original)
editor.
b. In the case of the block edit options ("Paragraphs", "Sections"), users used
it correctly and found it helpful. This might indicate that this is the right
way to go (which was my hypothesis), but it still has to be approached
differently.
3. Users did actually like the idea of the interface, whether or not they could
accomplish their tasks. Users noticed the edit summary field earlier and used
it more often (although the test groups were too small to draw a formal
conclusion from this).
In conclusion: users really liked the direct manipulation, but did not get the
different edit modes. So, back to the drawing board! ;)
Full interview videos will be available on Wikimedia Commons somewhere next
month. They are in Dutch, though.
You can try the editor with block edit options at
http://janpaulposma.nl/sle/wiki. It's still work in progress: do expect to run
into bugs that I did not find worthy to fix yet. :)
Best regards,
Jan Paul Posma
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] InlineEditor new version (previously Sentence-Level Editing)
Hi all, As presented last Saturday at the Hack-A-Ton, I've committed a new version of the InlineEditor extension. [1] This is an implementation of the sentence-level editing demo posted a few months ago. Basically what this new version does is building a tree structure from all the markings. This has the advantage of being able to render only part of the tree when doing a preview, which has a significant performance advantage. However, there's also the problem of dependencies throughout the page, the most notable of which is the Cite extension. Right now this is resolved by just rendering the entire page whenever a dependency is encountered. Extensions are responsible for telling this by using a hook, right now there's only built-in support for references (Cite). A more scalable solution would be to enable extensions to rerender only the dependency by using some stored data acquired on the initial parse, and data from the subsequent partial parse. This will be one of the goals for the next version. Another advantage of using this tree structure is that now nested markings are possible. Now there are basically two (or perhaps more) possibilities of defining editing options. One is to differentiate based on functionality, like in the initial demo: Text, Media, Templates, etc. Another possibility is to differentiate based on block size (which uses nested markings): Sentences, Paragraphs, Sections, Full Text. Personally I think the second option will be better if the goal of the interface is to educate new users to become gradually more accustomed to wikitext. Anyway, further research should investigate what's the best interface. I'll be doing some usability research myself in the next few months, and the Wikimedia Foundation will be doing further usability research next year. If you like to play around with the editor, these are the lines you can add to LocalSettings.php to get started: require_once( "$IP/extensions/InlineEditor/InlineEditorFunctional.php" ); // functional approach *or* require_once( "$IP/extensions/InlineEditor/InlineEditorBlocks.php" ); // block size approach Feedback is welcome! Thanks for your time. Regards, Jan Paul [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75344 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] InlineEditor extension
Whoops, I meant to address this mail to wikitech-l, not wikitext-l. ;-) Regards, Jan Paul > Hello, > > In commit 72458 I've added the InlineEditor extension. [1] This extension is > a working implementation of the prototype(s) earlier posted on this list. > It's not actually for use on live wikis, but more a proof-of-concept and > framework to experiment with. I will explain the extension in detail for > those of you who might be interested. > > == Design overview == > The extension exists of several parts, structured in sub-directories like the > UsabilityInitiative extension. The InlineEditor extension itself provides a > framework for different edit modes to build on. It displays the edit modes, > provides an interface to mark editable pieces of wikitext, provides a > client-side inline editor which the edit modes *may* use, is configurable > with several fallback options to the full/traditional editor, and handles > previewing, publishing, undo and redo. > > Every other extension provides an edit mode for the InlineEditor extension. > They hook into InlineEditorMark and InlineEditorDefineEditors. The first one > is called whenever wikitext is passed through the extension, and all edit > modes can mark their editable pieces. Once this is done, a few algorithms > will combine this with information of previously edited pieces, generate both > wikitext to run through the parser, and JSON which is passed to the client, > which maps the editable pieces to the original wikitext. The other hook is to > include CSS, JS and messages to the page. > > == Limitations == > There are many things which are sub-optimal right now: > * The editor is slow. Whenever changing a small element and previewing it, > the entire page is reparsed. This will be fixed by parsing only the element > if possible (i.e. references have side effects at the bottom of the page). > * It's for now only possible to use the editor as primary editor, with a link > to the full/traditional editor. There will be a configuration option whether > to do this, or display a message at the top of the traditional edit page to > switch to this editor. > * I've not tested things in older browsers (or IE at all, for that matter). I > only know it runs fine in Firefox and Chrome, but it may have bugs in other > browsers. > * The edit modes are really, really, basic right now. They may or may not > screw things up. Most of them have just one or a few regular expressions > which do well in general, but may fail at many edge-cases. > * The editor may not handle all the messages and edge cases of the > traditional editor. > * The extensions is written for MediaWiki 1.16 but may or may not work with > other versions. > > Also, I'm not sure at all whether the current set of edit modes is the way to > go. Currently, they are mutually exclusive. Meaning that text marked by one > editor is never included in text marked by another editor. However, maybe > it's better to not have edit modes like this, but different granularity of > editing. I.e. sentence => paragraph => block. This way the user will get > familiar with more wikitext instead of always seeing small portions. The > framework currently doesn't allow for overlap in markings, but I will work to > make this possible. > > == Goals == > Goal of this extension is to provide a framework to easily play with > different modes of editing in-line. Feel free to write extensions that use > this framework, or help with the framework itself. Any usability or technical > suggestions are also welcome! > > I hope to get some documentation up on mediawiki.org anytime soon, but note > that the code is heavily documented inline. Feel free to ask any questions: > I'm probably forgetting to mention some things that may not be clear to > everyone. Also, there is no public wiki at the moment to test this extension > with, will work on that, but if someone else can enable it on a test wiki > that would be great too! > > To install the extension(s), check the instructions in > /trunk/extensions/InlineEditor/InlineEditor.php. Thanks for your time reading > this! > > Regards, > Jan Paul > > [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/72458 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] New committers
Thanks, I'll let you know when the first version is pushed! Regards, Jan Paul On 25-Aug-2010, at 8:12, soxred93 wrote: > As did I. I expect to see some good work now, Jan Paul! But really, > welcome! > > -X! > > On Aug 25, 2010, at 1:28 AM, MZMcBride wrote: > >> Tim Starling wrote: >>> Extension access: >>> * Jan Paul Posma (janpaul123): Sentence-level editing >> >> This is awesome. I really enjoyed the proof-of-concept. :-) >> >> MZMcBride >> >> >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
> You've already applied for commit access right? Did you apply for > extension access or core access? Actually, I didn't say it explicitly, but I mentioned "Sentence-level editing", so that would be an extension. > If and when you get commit access for extensions, you're encouraged to > develop your extension in our SVN repo. Sure! > But suppose I want to be always in this mode, I can't click on links. > Also maybe the user don't really need to see the lines highlighted, > ... here in firefox wen I double-click on a word, the whole phrase is > highlited... is like the user is already acustomed for how > line-selections works on double click. But IANUE. You can't follow links, no. This is an editing mode and not a viewing mode. Perhaps there should be another "Edit mode" option "Preview" or something, to show the page as it would be. But I don't think it's that much of a problem, as you can in fact see if the links you entered are correct depending on the color. This hasn't been implemented in this prototype, obviously, but it should be there in the final version. > Also, there need > to be stronger options, "commit changes", "cancel" or something, > maybe theres a better way to do this. What exactly do you mean? There is a "Publish" button now to save the page, and cancel buttons when you edit individual sentences. > May pay to ask some real usability experts about this, if have some > positive feedback to give, before continue. If WMF or someone else wants to do this, then sure, but I'm not going to pay for it! ;-) Do note, by the way, that I have two supervisors from my university monitoring the project, one of whom is specialized in usability. > Aye, I had one suggestion later on in the message which could apply > there. "Or converting the simple content back to WikiText and showing > the syntax ([[, '', etc...) inline, with a floating cancel and preview > button just using contentEditable as a textarea replacement that doesn't > disrupt the page flow as much." > > contentEditable is more than simply WYSIWYG, it can also be used to > build custom inputs that fuse html and text to provide a text area > enhanced by extra ui inline with the content. I understand your point. If done right, this could look very good, while still embracing the concept of showing the wikitext. For now I personally cannot invest much time in this, as the coding of the extension will take a lot of time. If you like to take a shot at it, the source can be found at http://github.com/janpaul123/sle-prototype. If it looks and works good, I will include it in the extension for sure! Again, thanks for all the responses. I'm quite confident that this is the way to go, judging by your comments. Right now I'm trying to implement a nice way of plugging in these different edit modes, and building the first editor, the basic sentence-level editor. This, by the way, is not that easy, as there are quite some ambiguities on where a sentence ends. Finding a good algorithm is still a topic of research called "Sentence boundary disambiguation". (http://en.wikipedia.org/wiki/Sentence_boundary_disambiguation) If you have any ideas on how to do this right, please share it! Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
I suppose I just go on and build it as an extension then. ^_^ Again, if you have suggestions or want to join in development or anything else, feel free to mail. Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
> This is definitely a huge step in the right direction. Thanks everyone for the positive feedback! > Aside from the simplicity of just editing sentence by sentence, I like the > massive help section you added at the top. We have to assume that the average > contributor hasn't made more than a few edits. If you like to read more about the choices made in the top section, I've written it down at: http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing/Prototypes/Prototype_2 and http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing/Prototypes/Prototype_3 > This will introduce a big chasm in between making a simple sentence edit, and > then making a big change like cleaning up a whole paragraph. But that's quite > acceptable and we can build on this to make paragraph editors, image > inserters, infobox editors, and so on. Exactly, that is the goal. To 'teach' wikitext by slowly introducing more complex concepts. For now I'll focus on the sentence-level editing though. Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
> Interesting. > I find the switch to 3row textarea from content a little jarring. A > further developed version could make use of contentEditable to provide > the same editing ability but without the negative side effects of the > textarea. Actually, showing the original wikitext is one of the goals of this user-interface. The goal of this project is to lower the barriers for novice users, and providing a better way for them to learn the wikitext syntax. Hiding the wikitext completely would defeat this purpose. In the best cases novice users would first edit some sentences, while noticing the wikitext syntax, but only some links and perhaps bold/italics. This is much less scary than a big textarea with lots of code. Then they may experiment with references, images, templates (once these are implemented), so they can slowly learn more. Eventually they can either be advanced users of this editor, or try the editor we have now, which will always be more powerful. The editor I'm proposing *isn't* a total replacement for the current editor, just an addition. Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Sentence-level editing
On 10-Aug-2010, at 11:05, Roan Kattouw wrote: > 2010/8/10 Andrew Garrett : >> I do notice that the "Preview" button for sentence-level editing >> doesn't quite work (it shows the old text). There's some stuff >> missing, but I assume that this is because it's not finished yet. Ah, I guess I wasn't quite clear on that. These are "prototypes", user-interface mashups, without actual server-side logic behind it. The next step of the project will be to write the server-side stuff that matches the sentences, and find out how good this his, what the edge-cases are and how those are handled, etc. Finally, it can be made to a working plugin which only does the sentence-editing. The other things like references, images, etc. are a bit harder. These can be built one-by-one to extend this editor, but I think that only the sentence-level editor can be quite useful already. Besides, with only the ability to edit the sentences there will be enough challenges already: performance, security, handling edit collisions, localization, etc. Anyway, it would take quite a while to be able to do everything shown in the third prototype. It shows what we *could* have eventually. The plan is that in half a year the second prototype will be fully functional and available as an extension. Best regards, Jan Paul ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sentence-level editing
Hello everyone, As this is my first post to the mailing list, let me introduce myself shortly. My name is Jan Paul Posma, and I'm a 20 year old Computer Science student from the Netherlands. I was introduced to MediaWiki by Roan Kattouw, contractor for the Usability Initiative, who also happens to be a friend of mine. :-) The reason for mailing to the list is the research I'll be conducting this year: building a new editor for MediaWiki. Now I guess this has been discussed over and over again, but this is a bit different. Instead of building a true WYSIWYG editor, I'm proposing to build an editor that's based on adding extra markup to the original, rendered page. This extra markup provides the ability to edit these segments. With this approach, it's possible to slowly enable editing for different elements. First, we can enable editing for "simple" sentences (thus the title sentence-level editing). "Simple" in this context means: without most wikicodes. I.e. only links are allowed, and perhaps bold and italic. This editor can be extended step by step to include other elements, such as references, images, templates, lists, tables, etc. The last few weeks I've worked on some prototypes to illustrate this idea. You can find the most advanced prototype here: http://janpaulposma.nl/sle/prototype/prototype3.html The full project proposal and prototypes can be found here: http://www.mediawiki.org/wiki/User:JanPaul123/Sentence-level_editing Right now I'm not looking for anything in specific, just whether or not you think this is a good idea, technically feasible, etc. If you have suggestions of any kind I'll be happy to hear them! Thanks for your time! Regards, Jan Paul Posma ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
