How can we make the Visual Editor as efficient as, or more so than,
wikitext editing when it comes to handling complex tasks like
citations, templates, etc.? I know it's a bit early to talk about
detailed aspects of the editing surface, but this may have some impact
on architectural considerations for plug-ins and such, so I wanted to
raise it on this list.
I don't think it's that much of a stretch goal to be more efficient
than wikitext editing for a lot of common cases. For example, using
complex templates manually is extremely inefficient, usually requiring
a visit to a Template: namespace to read the template documentation,
then apply the correct syntax and hope you're not making a typo in the
process.
A few models:
* Wikia's current-generation visual editor offers panels with access
to templates and categories, autocompleting as you type. If our goal
is to create an editing surface that focuses on the content and gets
out of the way (and IMO it should be), these types of panels add
clutter which is likely unacceptable.
* Most RTE editing surfaces have toolbars, and some also add desktop
application style pulldowns. The pulldown/toolbar combination has many
known usability issues as software complexity increases -- they become
cluttered, and keyboard shortcuts for anything but the stuff you use
all the time become hard to remember.
* Code IDEs use a lot of hinting/autocompletion based on intelligence
gathered from parsing the file you're editing, or any other files.
This works well when what gets rendered in the editing surface is
identical to what the user is typing. It's easy to auto-complete
"myObject.getSomeStuff()", but it's less discoverable that I should
start typing "{{Infobox country" to get a beautiful right-aligned
table.
* vi is the best example of a powerful modal editor which can perform
complex operations by essentially entering an in-editor command-line.
It's also well-known to be very difficult to learn and master, in
large part because its UX is so different from other applications
people commonly use.
What other models ought to be/are being considered?
A couple of ideas:
== Inline menus ==
You could have a menu key, say Ctrl+I or, if we want to be more
radical, a single compose key like "\", which triggers an in-editor
menu structure with associated keyboard hints.
E.g. if the user types <menu key>c, they see an overlay expanding at
cursor position:
w - cite a website
b - cite a book
n - cite a newspaper
j - cite a journal
So by typing: <menu key>cw, I could enter whichever the appropriate
dialog is for citing a website (which itself could be rendered in-line
if that gives us additional efficiency).
This type of system could intelligently trigger auto-completion where
appropriate. Say "y" is the shortcut for category, and I type:
<menu key>yChurches in <cursor down><cursor down><cursor down><enter/tab>
to insert the category "Churches in the United Kingdom".
Or say "t" is short for template, so I could type:
<menu key>tInfobox a<cursor down><cursor down><enter/tab>
to insert the template "Infobox album" and invoke the appropriate dialog.
One could make such a feature discoverable by adding hints to the UI
in appropriate places, e.g. if the most obvious invocation method is
through a tabbed dialog, each dialog could have a small hint
indicating how to quickly invoke it inline.
== Inline markup completion in visual mode ==
Another option would be to just intelligently detect use of existing
markup, e.g. to magically complete "[[Category:Churches in" or "{{Cite
web" or "{{Infobox co" even when in visual mode. This is beneficial
for people who already know wiki markup, but is arguably less
efficient/user-friendly than a menu/command structure that's designed
from scratch to be maximally efficient, discoverable and intuitive. It
also would tie us permanently to wiki markup.
What do you think? How can we make the visual editing surface
maximally efficient for frequent use?
All best,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
Is there a tool (or a chain) that would allow one to input wikitext
and output either
* something slidelike (ODP or PDF, suitably formatted)
* something that easily converts to something slidelike (e.g.,
TeX beamer, HTML for Slidy)
Why I ask:
I have several long pages on a governmental MediaWiki that I used as
rough drafts for a presentation, which (after favorable review) I'd
like to turn into "real slides." Unfortunately the admins of that MW
are notoriously savage, so my chances of getting something installed
on the wiki instance, e.g. the mw-slidy extension
http://www.mediawiki.org/wiki/Extension:Mw-slidy
, are negligible (though I'll ask). Hence I probably need something
that converts offline (i.e., not on a MediaWiki); I seek, e.g., a
commandline tool such that I can do something like
$ magic < input.mediawiki > output.pdf
One option is Eclipse Mylyn's WikiText module
http://wiki.eclipse.org/Mylyn/Incubator/WikiText
but that seems rather heavyweight for this task, since I'm not
currently using Eclipse for anything else. I'd prefer something like
Deplate
http://deplate.sourceforge.net/
but that only inputs the markups={rdoc, viki}, which both seem quite
remote from (MediaWiki's) wikitext: i.e., creating a wikitext ->
{rdoc, viki} converter seems like more work than writing HTML or TeX
by hand.
Am I missing something? Care to recommend a candidate app, or
Something Completely Different?
Your suggestions are appreciated, Tom Roche <Tom_Roche(a)pobox.com>
Hi all!
I just noticed that MediaWiki uses two different mime types for wikitext:
* application/x-wiki is used by AjaxResponse, OutputPage and StreamFile.
* text/x-wiki is used by RawAction.php (i.e. when you use action=raw)
Is there a good reason for this, or is it just an oversight? I suggest to use
the same mime type everywhere, and keep the old one for compatibility reasons -
i.e. we should use application/x-wiki consistently, and RawAction could support
text/x-wiki as an alias.
That being said... the *correct* mime type would imho be
application/x-mediawiki. But i don't insist on it :)
-- daniel
I was made aware of work done on an "inline editor" -- see
http://www.mediawiki.org/wiki/Extension:InlineEditor and code at
http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/InlineEditor/ .
This work was done by a team coordinated by GRNET (Greek Research
Network), which developed a WYSIWYG editor that produces MediaWiki syntax.
I presume that the Visual Editor team (Wikimedia Foundation and Wikia)
already know about this work as a predecessor to their own, but just
wanted to share it in case it's useful to anyone else while they wait
for the Visual Editor.
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Regarding the Inline Editor mentioned in today's post by Sumana:
(http://www.mediawiki.org/wiki/Extension:InlineEditorhttp://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/InlineEditor/)
To give credit where credit is due, the editor was the brainchild of Jan Paul Posma, then a student at Groniger, now a graduate student at Oxford, who coordinated our contribution. GRNET worked together with Jan Paul to carry out improvements as well as an interesting usability study that we presented in last year's Wikimedia Conference in Berlin.
We have since stopped working on the project since we were not sure that there was interest for it to be used. However, if there is a possibility that it may be useful in some way, we would be happy to see what could be done, discussing with Jan Paul.
Best Regards,
Panos Louridas
GRNET
Hi,
I have not really looked into the code yet, but I just wanted to get
your oppinions on the question: Will there be a possiblity to integrate
userscripts or other extensions into the VisualEditor? Particulary i
would be interested in reusing the Parsoid and retrieve something like
"get parent heading from cursor"... I hope that makes sense :)
Regards
Jonas
Awesome -- thanks!
I have a couple of questions to ask, too. These aren't urgent, so feel free
to reply whenever you have the time.
1) Conformance vs. enhancement
I'm not sure if you saw my comment in the diff, but some of the ISBN
validation code I wrote is deliberately unreachable because it's stricter
than the naive validation the Mediawiki currently performs. (I stupidly
wrote it before checking to see what exactly the current parser does.) In
general, is it ever desirable to try and improve on the old parsing grammar
or is total conformance the overriding goal?
2) ECMAScript target
Should I strive to write code that is compatible with older browsers? Thus
far I've avoided ES 1.5 constructs like forEach, map, filter, etc. But if
this is only going to run server-side under node for
the foreseeable future, maybe that's an unnecessary handicap.
3) Intermediate representation vs. parser hacks
The preliminary work I've done to parse behavior switches (__TOC__ &
friends) has the parser directly toggle attributes on a configuration
object. It does this rather than produce a token for some subsequent tree
visitor to interpret. So the parsing is arguably somewhat lossy in this
case, but possibly not: when serializing back wikitext, you could read all
behaviors from the configuration object and encode them at the top; their
position isn't significant, afaik.)
So: did I make the right decision? PEG.js's support for arbitrary
JavaScript code in the grammar makes this tempting to do sometimes, but
perhaps it's wiser to insist that the parser not overreach the goal of
building a tree. What is your take?
I'm CCing wikitext-l, since your responses are likely to be useful to
future contributors.
Best,
Ori
On Mon, Apr 2, 2012 at 12:41 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote:
> Hi Ori,
>
> I committed your patch in https://gerrit.wikimedia.org/r/#change,4094.
> Looks good, and lets 14 more tests pass ;) Thanks!!
>
> Gabriel
>
>
> On Mon, Apr 2, 2012 at 9:59 AM, Ori Livneh <ori.livneh(a)gmail.com> wrote:
>
>> Hey Gabriel,
>>
>> Working on this on stolen time, as it were, but I do have some modest
>> progress to report. The attached patch revises the handling of RFC
>> auto-links and adds support for ISBNs, PMID links, and preliminary support
>> for behavior switches (things like __TOC__).
>>
>> I applied for git access, so hopefully I'll have my own branch set up
>> soon and we'll be able to do this in a slightly less haphazard way
>>
>> Hope you've had a nice trip,
>>
>> Ori
>>
>
>
I found this task in [[mw:Parsoid/Todo]]:
* Move list handler from tokenizer to sync23 phase token
transformer to support list items from templates.
Does this mean, using a template like {{Foreach|delim=*}} can generate some
list items, and the calling page has control over
whether these items are in their own list, or continue
another list? In this case, the attached tests describe the
feature correctly?
Regards,
Adam Wight
Forwarding this to the wikitext-l list just in case.
-------- Original Message --------
Subject: [Wikitech-l] Cutting MediaWiki loose from wikitext
Date: Mon, 26 Mar 2012 16:45:51 +0200
From: Daniel Kinzler <daniel(a)brightbyte.de>
Reply-To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Organization: Wikimedia Deutschland e.V.
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>,
mediawiki-l(a)lists.wikimedia.org
CC: Lydia Pintscher <lydia(a)pintscher.de>, Abraham Taherivand
<abraham.taherivand(a)wikimedia.de>
Hi all. I have a bold proposal (read: evil plan).
To put it briefly: I want to remove the assumption that MediaWiki pages
contain
always wikitext. Instead, I propose a pluggable handler system for different
types of content, similar to what we have for file uploads. So, I propose to
associate a "content model" identifier with each page, and have handlers for
each model that provide serialization, rendering, an editor, etc.
The background is that the Wikidata project needs a way to store
structured data
(JSON) on wiki pages instead of wikitext. Having a pluggable system
would solve
that problem along with several others, like doing away with the special
cases
for JS/CSS, the ability to maintain categories etc separate from body text,
manage Gadgets sanely on a wiki page, or several other things (see the
link below).
I have described my plans in more detail on meta:
http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler
A very rough prototype is in a dev branch here:
http://svn.wikimedia.org/svnroot/mediawiki/branches/Wikidata/phase3/
Please let me know what you think (here on the list, preferably, not on
the talk
page there, at least for now).
Note that we *definitely* need this ability for Wikidata. We could do it
differently, but I think this would be the cleanest solution, and would
have a
lot of mid- and long term benefits, even if it's a short term pain. I'm
presenting my plan here to find out if I'm on the right track, and
whether it is
feasible to put this on the road map for 1.20. It would be my (and the
Wikidata
team's) priority to implement this and see it through before Wikimania. I'm
convinced we have the manpower to get it done.
Cheers,
Daniel
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l