> 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
