Wikia has hackathons every quarter or so and I once built a keyboard shortcut legend interface. It could either supplement the toolbars or stand on its own. I stress, this is a hack (not localized, not optimized, may not match your keyboard layout, might not work in your browser, etc). :)
http://southpark.christian.wikia-dev.com/wiki/Paul_Shaffer?action=edit To use the keyboard shortcuts, hold Ctl-Alt-[key]. To make text bold, use Ctl-Alt-B. If you hesitate for too long (holding only Ctl and Alt), the keyboard shortcuts legend will appear. -Christian On Apr 23, 2012, at 7:26 PM, Erik Moeller wrote: > 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 > > _______________________________________________ > Wikitext-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitext-l
_______________________________________________ Wikitext-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitext-l
