Toolbar

• To discuss the current Icons go to Opinion Icons.
• To discuss the Vector skin or anything else go to Talk:Prototype.

Userfriendliness in Editing is Key

Hello,

I never edited wikipedia but I installed a wikimedia wiki to assess it as a note taking tool and collaborative work at work and at home.

I came to the conclusion, which seems to be shared even by some among you to a certain extent, that wikimedia due to its lack of userfriendliness could not be used professionnally in the current state because editing required a significant knowledge of html (or its wikimedia subset) which can not be considered as largely widespread or be part of what some has named digital literacy.

It thus required learning it, and of course if we want wikimedia to be used by anyone even for taking notes, this is learning something not related to their main business and they may not have time for that.

This is why, even though I was enthused by its collaborative capability I felt it was impossible to ask people at my job to edit a wiki like they would do for a word processor document, it is already not easy to ask people to take time to document what they do, with the current userfriendliness of wikimedia, and the additionnal time required to edit, they would have drop out documenting.

To be shared widely, I think wikimedia editing should be made as simple as word processors (which use is definitely part of digital literacy) and also featurewise rich enough.

I think among the mandatory userfriendliness features it should be possible simply to :

• choose the color of the text
• choose the font
• choose the size
• introduce the possibility to outline with several colors
• offer the possibility of foot notes
• offer the possibility of comments

all that in a simple maneer (agnostic to html)

I don't know if all that is already included in the scope of your project but I think it is very important for people using widely wikimedia in their home or professionnal projects and therefore be sufficiently familiar with the edition possibilities that they feel no obstacle to one day editing wikipedia when they feel they can contribute.

When I saw the news of this initiative I welcomed it very much, please make it really user friendly this is key (think of the market share taken by the iphone even with a very late release date compared to other phones, it mainly amounts to its user friendliness and ease of use... think about it).

I read that important amount of money was dedicated to this excellent initiative. I think this is annother reason to reach for a real ease of use in order to maximize the impact of this investment and also because in general this kind of opportunity does not come twice.

We support you in this well inspired initiative it is an opportunity to make the needed and decisive difference !

Hoi, the key thing with every new application is that you appreciate what the application is about. Given that MediaWiki, the name of the software, is intended for collaborative editing, you have to look at what it is that you need as such. Several of the comments that you make are a bit bewildering. It is ok that you have to learn about what it is that the software does, MediaWiki is not a text processor, expecting all the attributes of a modern text processor may give the impression that it is a text processor.

It is possible to have different text sizes et al in Wikipedia. However it is not used that often because you are looking for a consistent look and feel. The point, MediaWiki is used professionally and teaching what is special about the software is important. This usability initiative should make many things more intuitive but it should not take away the notion that this is not text processing. Thanks, GerardM 11:45, 15 June 2009 (UTC)

Still more suggestions on the edit-button bar

Hi,

After playing some more with the prototype, a few more ideas occurred to me.

• The Help ("cheatsheet") dropdown menu is great, but again you left off the discursive list (; and :). Perhaps you should at least mention indentation with the colon, since it's so common on Wikimedia projects? Practically every section of every Talk page has them on the English Wikipedia.

• Again under the Help menu, I notice that you don't include ALT text in your example of a Figure caption. I understand that that's simpler for newcomers, but it's disappointing that we don't encourage accessibility for the visually impaired.

• The Heading dropdown menu is likewise great, except that Level 1 shouldn't be listed, since it messes up the Table of Contents (see en:User:Proteins/MoS_Nightmare for an illustration). The levels might be more intuitive for newcomers if the dropdown menu showed the levels more as they might appear in the article, e.g., with larger bolder fonts for the higher levels. (See the "What you get" column of the "Headings" section of the Help dropdown menu.) Bonus points: you should never allow the user to add a heading level that is more than one level lower than the present level, e.g., you shouldn't allow the user to add a H4 heading in the middle of an H2 section. That's a barrier to accessibility for the visually impaired and a major headache for the Manual of Style.

• I would demote the boldface and italics edit buttons to the "Formatting" dropdown menu. That seems like the most natural grouping. For another thing, these two typefaces are not used that often in Wikipedia articles. Boldface is usually used once per article, in repeating the article title in the first sentence of the lead. Unless the article is being created from scratch, that sentence has usually been written already; therefore, most editors in most situations will never need the boldface button. The most common use of italics is in the inline citations (journal names), which are handled already by the citation templates. Thus, it's relatively rare that editors need to introduce italics.

• Perhaps also under Formatting, you might add something for striking out text? That's also common practice on Wikipedia; for example, at FAC, one strikes objections as they are met by the nominator of the article.

• Again, I would promote the "Headings" dropdown menu to the first (leftmost) position on the edit-button bar. I would discourage the use of external links by putting that one last. Lists seem less important than references (at least on Wikipedia) so you might put the three types of lists under the "Insert" dropdown menu.

Hoping these new suggestions are helpful, Proteins 18:27, 24 June 2009 (UTC)

Problem with the headings and lists

When you select the text == Foo == and then select level three from the headings dropdown, you get ===== Foo ===== instead of the expected === Foo ===. The effect of the list buttons on multi-line selections is also not what one would expect. --Tgr 08:00, 26 June 2009 (UTC)

Treatment of "Headings" in editbox buttons

Thanks for making those changes, but I'm not sure that "Advanced" is descriptive enough?

My main suggestion, though, is to promote the Headings dropdown menu to the main line, say next to the add image button. Also, as suggested above, you should remove the Level 1 option, or at least add safeguards. Proteins 15:58, 27 June 2009 (UTC)

Footer and alerts

div#foot with license and copyright info looks much better with monobook skin. See http://www.picamatic.com/show/2009/06/27/08/39/4149639_1280x275.png for real MediaWiki site.

Also, EditWarning alerts (like any other javascript alert) are very annoying and should not be used by default. --85.141.235.251 16:50, 27 June 2009 (UTC)

EditWarning should be quiet after undo

The EditWarning extension is great -- warning that if you leave, your changes will be lost. However, the following use case should be fixed:

1. Edit a page
2. Type an "X"
3. Type ctrl-Z to undo
4. Click any link to leave the edit page

Currently, EditWarning will pop up an alert. It should not, because nothing has changed. (Probably you are just keeping a "dirty" bit that indicates whether the edit box has been touched.)

The simplest way to do this, in addition to your "dirty" bit, is to store the original wikitext when editing begins, and compare it to the current wikitext when the user tries to leave (window.onbeforeunload). I've been doing this in my own EditWarning-type extension and it works great, even for large pages.

This is a small change, but if you suppress these unnecessary warnings, that is definitely good usability!

--4.79.245.132 20:38, 30 June 2009 (UTC)

I think this is an overhead, and there were no big benefit when this function would be implemented. How often do you think user do the described action above. For me too seldom. --129.27.129.83 10:21, 1 July 2009 (UTC)

This has been fixed; EditWarning now only warns if the contents of the edit box are different from the initial contents. --Catrope 17:40, 9 August 2009 (UTC)

LaTeX next to Special Characters

Hi,
like the Special Characters Menu, there should be a similar menu for Math/LaTeX markup as used by texvc and BlahTex. The supported LaTeX commands should be grouped by their use ("greek symbols", "arrows", "integrals", etc.).

See Help:Displaying a formula for a reference of commands.

— MovGP0 21:43, 30 June 2009 (UTC)

This would be very useful. If it is not possible, please bring at least the "math button" again... in math texts, usually there are more math tags than paragraphs (!) It is bad idea to type < m a t h > every time! 143.107.45.43 12:33, 15 September 2009 (UTC)

Even better implement something like this extension that no longer seems to be supported (tried on V1.15.x Mediawiki) but had a good user-friendly approach: http://www.mediawiki.org/wiki/Extension:TeX_Editor

More suggestions for the edit page

At my suggestion, en:User:Cacycle recently added a feature to wikEd which you might consider here. The feature collapses references and long templates into placeholders, which reveal their contents when clicked (my original idea) or onmouseover (Cacycle's implementation). I also suggested tables, although wikEd doesn't do that as yet.

The advantages of this approach are several. First, references and templates such as infoboxes/navboxes are unfamiliar in syntax and usually stretch over many lines, sometimes even filling the visible edit box. This is particularly grievous at the beginning of the article, where long infoboxes are common and where most newcomers will first try to edit. By collapsing each of these long elements into a small labelled placeholder, you make the text far more readable, much closer to the article as read. In effect, this approach distinguishes between simple wiki-markup (links, section headings, italics) and complex wiki-markup (references, templates, tables). The simple markup is a much smaller "perturbation" of the normal article and much easier to learn.

You might consider other innovations of wikEd for usability as well, such as its icons, its color coding, its find/replace mechanisms, its automated fixing routines, etc.. It's well-liked by many of Wikipedia's most productive editors. I've listed a few more ideas for wikEd on en:User talk:Cacycle/wikEd, which you might also consider. Proteins 01:02, 2 July 2009 (UTC)

PS. A third warning, please listen: Including "level 1" in the Heading dropdown menu is an invitation to disaster on a massive scale. If this new skin succeeds in recruiting thousands of beginning editors to Wikipedia, as we all hope, they will naturally choose level 1 for their first heading, right? I hope you know that level-1 headings are never appropriate on the English Wikipedia, and I suspect most other languages and Wikimedia projects. Even if you ignore all my other suggestions here and above, please pay attention to this one.

The usability team is listening. Great point about level 1 heading is not appropriate for Wikipedia. How about external MediaWiki users though? We may need to find a way to customize for Wikipedia and MW project wikis.
P.S. Will check out content folding of wikiEd. Thanks for the pointer. --Shuhari 06:39, 2 July 2009 (UTC)

Level 1 headings translate to h1 tags, which are normally only used to denote the title of the article. It is unlikely that many external MediaWiki sites would like to use multiple h1 tags, so IMO level 1 should be left out by default. If it is possible to customize the toolbar, the minority of wikis using L1 tags should be the ones to do that. --Tgr 20:51, 4 July 2009 (UTC)

Line breaks

For complex (multiline) inserts like gallery or table implicit line breaks can help to recognize easily what has been inserted with one click. After all manually inserted galeries or tables markup seldom flow inline with other text. Erik Zachte 03:39, 2 July 2009 (UTC)

 The following candy bars have a good taste to price ratio. <gallery>
 File:Example.jpg|Caption1
 File:Example.jpg|Caption2
 </gallery>Of these the following also have a high tooth decay factor. {| class="wikitable" border="1"
 |-
 ! header 1
 ! header 2
 ! header 3
 |-
 | row 1, cell 1
 | row 1, cell 2
 | row 1, cell 3
 |-
 | row 2, cell 1
 | row 2, cell 2
 | row 2, cell 3
 |}Consume at own risk.
 

Better

 The following candy bars have a good taste to price ratio. 
 <gallery>
 File:Example.jpg|Caption1
 File:Example.jpg|Caption2
 </gallery>
 Of these the following also have a high tooth decay factor. 
 {| class="wikitable" border="1"
 |-
 ! header 1
 ! header 2
 ! header 3
 |-
 | row 1, cell 1
 | row 1, cell 2
 | row 1, cell 3
 |-
 | row 2, cell 1
 | row 2, cell 2
 | row 2, cell 3
 |}
 Consume at own risk.
 

A simple yet powerful way to increase intuitiveness. --Shuhari 06:44, 2 July 2009 (UTC)

Fixed, should now work on prototype wikis. Fix not tested on IE yet. --Catrope 16:22, 10 August 2009 (UTC)

Undo and redo

Could u please create an undo and redo button in the edit box? It works automatically on Firefox with ctrl-z and ctrl-y but most novice users don't know the shortcuts. Thank you.--Diaa abdelmoneim 10:24, 2 July 2009 (UTC)

Most block level elements should add a new line

I'll try to explain by example. Suppose I'm writing some text...

Type, type and want to make next text bold '''click''' (Seems OK).

And now I'm typing some more text and want to make a list... Go to a new line
* OK. And now... click to go to next item?* wrong - same line

Further more if I'm inside a line (not at the end) that has a list character, clicking on the list button should make the list disappear (this is would be similar to how it works office editors). But this could be a little tricky so another button for adding new list item should be added to avoid confusion.

OK. Now I want to insert a table... Well this won't work:{| class="wikitable" border="1"
|-
! header 1
! header 2
! header 3
|-
| row 1, cell 1
| row 1, cell 2
| row 1, cell 3
|-
| row 2, cell 1
| row 2, cell 2
| row 2, cell 3
|}

BTW. I have this experimental table adder which you might use (I think I won't be able to finish this soon). It's not much but I guess it's better then just pushing the code straight away to the editing area (there is a simple, light editor that adds/removes new columns and rows and inserts code after finishing). I'm almost sure it worked in all modern browsers + IE 6, but it was quite a long time since I worked on it so I won't give my head on it. Some comments are in Polish so if you have a problem figuring something out just let me know. Anyway the code is here: wp_ted_0.0.2.zip a general class used for JS-pop messages (not in a new window): [1]. The script adds a button above the textarea. Obviously it wasn't tested on new Vector skin (it was made for monobook), but I think it will work for it too. --Nux 22:18, 2 July 2009 (UTC)

A few thoughts on the enhanced edit toolbar

First off, thanks for all the effort as it is looking quite nice. A few thoughts... is it possible to reverse the "internal" and "external" links buttons, as per the standard tools? (While it is only a minor inconvenience remembering the order, I don't see an actual need to swap them - and having the external link button first might just inspire people to add them!) Thoughts? --Ckatz 02:50, 3 July 2009 (UTC)

Signature help

On the enhanced edit toolbar -> Help -> Discussion, it would be useful to add a simple example like w:Wikipedia:Talk_pages#Example:, or you'll see things like this. Thanks, Nemo 07:26, 30 July 2009 (UTC) P.s.: Very odd not to have the sign button here on namespace 0.

Custom buttons and icons

Hi. So I'm trying to figure out how too add custom icons. So far I figured out that I have to do it onload and I can use label (instead of labelMsg) to use text (not read it from MediaWiki).

But the problem is I cannot add new icons - as seems they have to be in .../extensions/UsabilityInitiative/EditToolbar/images/, which is not very useful for custom buttons. So is there a way to add an icon under a specific address e.g. this one?

I would also like to run a specific js-action (function) instead of defining some action (something like onclick="wp_sk.run()").

Regards, Nux 18:53, 3 August 2009 (UTC).

Maybe you can browse to the top directory by ../../.. etc.--Liangent 11:07, 11 August 2009 (UTC)

Might work for some, but thumb generating only works for SVG and only for local files. The rest needs different domain... I'm waiting for bug 20125 to be resolved, and in the mean time I'm currently using my script for adding buttons. --Nux 20:44, 11 August 2009 (UTC)

You can use Special:FilePath --Liangent 05:20, 14 August 2009 (UTC)

I now the path, but there is no way to use it. --Nux 18:52, 25 September 2009 (UTC)

Headings in edit window

Under the advanced drop down, there's an option to specify headings. The headings start at one and end at five. I see two problems with that. The first, HTML lets you go to a sixth level heading (although articles rarely go beyond the fourth). The second, Heading 1 is generally reserved for the title of the document, not for sections; for editors unaware of this, we might see some header problems in terms of the English Wikipedia's WP:LAYOUT. ChyranandChloe 04:46, 4 August 2009 (UTC)

Header 1 has been removed. --Catrope 18:29, 9 August 2009 (UTC)

Customizing the toolbar

The old toolbar made it (relatively) easy to add new buttons using user/site JS with the mwCustomEditButtons JS global variable. Will the new toolbar have anything like that?

I'd like to rewrite my script - w:en:User:Mr.Z-man/refToolbar to use the new toolbar, but there's no easy way to do it, and the HTML of the toolbar seems to be changing in an incompatible way with the next release. Mr.Z-man 23:35, 5 August 2009 (UTC)

Could some kind of default citing script be added, either something like Mr. Z-man's or like w:en:User:Odie5533/SnipManager. Having a default method of citing sources would make it much easier for anonymous and new editors.Smallman12q 00:29, 7 August 2009 (UTC)

Someone has reported it to MediaZilla. See MediaZilla:20125. --PhiLiP 20:33, 8 August 2009 (UTC)

Kind of found a way to do it, I did a google search and found this: http://en.wikisource.org/wiki/User:Alex_brollo/vector.js?match=pl

I just kind of modified his code, but the bottom part of the code seems to be of no use for me as it doesn't seem to display under my current settings. It's so hard to find info on customizing the toolbar and vector it seems! While i'm here I should also ask, is there a way to make the toolbar "advanced" section load on default without the user clicking it first? and why is there no signature button on this toolbar? Weird!--Bluesoju 10:39, 15 June 2010 (UTC)

Vietnamese characters

Although the new toolbar features a "Latin" section in the Special Characters pane, it lacks most of the characters required for typing in Vietnamese. The Vietnamese Wikipedia has used the <charinsert> extension inside MediaWiki:Edittools to provide access to these characters, for those without access to an IME. (We also provide a JavaScript-based IME, but browser support varies, so the character palette is still necessary.)

Would it be possible to add a separate section for Vietnamese (similar to the "IPA" section)? It would only be necessary on Vietnamese-language wikis. Here's the full list of characters:

À Á Ả Ã Ạ

a à á ả ã ạ

 Ầ Ấ Ẩ Ẫ Ậ

â ầ ấ ẩ ẫ ậ

Ă Ằ Ắ Ẳ Ẵ Ặ

ă ằ ắ ẳ ẵ ặ

Đ đ ₫

E È É Ẻ Ẽ Ẹ

e è é ẻ ẽ ẹ

Ê Ề Ế Ể Ễ Ệ

ê ề ế ể ễ ệ

I Ì Í Ỉ Ĩ Ị

i ì í ỉ ĩ ị

O Ò Ó Ỏ Õ Ọ

o ò ó ỏ õ ọ

Ô Ồ Ố Ổ Ỗ Ộ

ô ồ ố ổ ỗ ộ

Ơ Ờ Ớ Ở Ỡ Ợ

ơ ờ ớ ở ỡ ợ

U Ù Ú Ủ Ũ Ụ

u ù ú ủ ũ ụ

Ư Ừ Ứ Ử Ữ Ự

ư ừ ứ ử ữ ự

Y Ỳ Ý Ỷ Ỹ Ỵ

y ỳ ý ỷ ỹ ỵ

 – Minh Nguyễn (talk, contribs) 05:43, 7 August 2009 (UTC)

I've added the entire 1E00-1EFF Unicode range as a separate "Latin extended" set. All of the characters mentioned above should be in either Latin or Latin extended. --83.119.125.27 21:31, 9 August 2009 (UTC)

While that's nice, it's not really useful for anyone, because the characters users are looking for will be buried in a list of other languages' characters. It would be very nice to have a set of system messages that define custom character palettes, similar to the way gadgets can be defined using MediaWiki:Gadgets-definition and friends. – Minh Nguyễn (talk, contribs) 07:10, 3 October 2009 (UTC)

...and just about any other set of characters

I'm noticing that some Cyrillic letters are missing (for example È è Ѝ ѝ). This new interactive toolbar should be easily modified on all the individual projects when it gets deployed, right? Will it be possible to create and customize new subsets of characters on, for example, an advanced wiki-markup set. And will MediaWiki:Edittools be obsolete after this toolbar? --Brainmachine 11:30, 7 August 2009 (UTC)

Yes, the special characters section will be customizable; projects can add, remove and alter buttons and sections as they wish. And yes, MediaWiki:Edittools will hopefully be obsolete when the toolbar has matured. --83.119.125.27 19:50, 9 August 2009 (UTC)

…and hebrew niqqud and cantillation

niqqud: ָ◌ · ַ◌ · ֵ◌ · ֶ◌ · ִ◌ · ֹ◌ · ֻ◌ · ְ◌ · ֳ◌ · ֲ◌ · ֱ◌ ··· cantillation: ּ◌ · ׁ◌ · ׂ◌ · ֿ◌ · ֽ◌ ··· etc.

--Joystick 13:43, 7 August 2009 (UTC)

Thanks. We had these and a lot of other Hebrew characters lying around, but we didn't know about the ◌ trick yet. I've added a bunch of Hebrew chars with ◌s to the toolbar. --83.119.125.27 21:31, 9 August 2009 (UTC)

Special characters on Search page

I suggest you also take into account the special characters in the search box. More or less as in the picture below:

--Joystick 14:21, 7 August 2009 (UTC)

Possible increase in icon spacing on Toolbar

I have not had the opportunity to view the toolbar in anything other than IE8, but I find the icons a little close together - just a tiny bit more space (laterally) would give them a more pleasing look. I am not suggesting wasting lots of screen real-estate, and am aware that on small screens they may will run into difficulties, but a tiny tweak would help (perhaps even 2 pixels per icon)Bedales94 00:27, 8 August 2009 (UTC)

They are already wasting too much space. This indicates that there needs to be more than one mode for the toolbar. I will suggest so below. - BalthCat 07:27, 11 August 2009 (UTC)

"Script is too slow" error message

With Firefox, when using the new beta on edit pages. See screenshot below :

Teofilo 05:26, 8 August 2009 (UTC)

Translation: A script on this page may be busy or not responding. You can end it now or wait to see if it finishes. HereToHelp 02:28, 10 August 2009 (UTC)

While they may be not your primary target audience, keep in mind that a huge percentage of the internet users are using 10 years old, or older, personal computers, with little memory and small and slow hard disks, some even with likewise old operating systems. Internet connections may be slow and expensive. Having tried all these new JavaScripts on such dangling a system (with excellent internet connections, though) I tend to say that they are likely too slow to be useful except for owners of rather new hardware, that many third world users will likely not get until its again 10+ years old, and completely useless for us. --Purodha 10:40, 12 August 2009 (UTC)

Also when I see on Releases/Acai/Compatibility_Matrix that the new prototype is supposed to be compatible with Internet Explorer 6 makes me a bit skeptical. Perhaps the new prototype is compatible with Internet Explorer 6 on a brand new smart and fast computer, but I guess that most of the people who use Internet Explorer 6 now are people with an old slow computer for which Internet Explorer 7 or 8 are not available. So in fact the so-called "browser compatibility" remains a fiction as long as you do not conduct "older computer compatibility testing". Teofilo 09:19, 16 August 2009 (UTC)

LanguageConverter markups

I'd like to advise some language converter markups. Which are widely used by some wikis like Chinese Wikipedia. Here is a complete list of these markups:

1. All text convert(add rules into conversion table) but hide parsed result

   Input: -{H|zh-cn:zh-cn content; zh-tw:zh-tw content;}-; '''zh-tw content'''

   Output (zh-cn): ; zh-cn content

   Output (zh-tw): ; zh-tw content

2. All text convert(add rules into conversion table) and display parsed result

   Input: -{A|zh-cn:zh-cn content; zh-tw:zh-tw content;}-; '''zh-tw content'''

   Output (zh-cn): zh-cn content; zh-cn content

   Output (zh-tw): zh-tw content; zh-tw content

3. Single convert

   Input: -{zh-cn:zh-cn content; zh-tw:zh-tw content;}-; '''zh-tw content'''

   Output (zh-cn): zh-cn content; zh-tw content

   Output (zh-tw): zh-tw content; zh-tw content

4. Title convert

   Input: -{T|zh-cn:zh-cn title; zh-tw:zh-tw title;}-

   Output: Use the specified title to replace the original page title

5. Raw content

   Input: -{R|zh-cn:raw content; zh-tw:raw content;}-

   Output: zh-cn:raw content; zh-tw:raw content;

6. Remove rules from conversion table

   Input: -{H|zh-cn:zh-cn content; zh-tw:zh-tw content;}-'''zh-tw content; -{-|zh-cn:zh-cn content; zh-tw:zh-tw content;}-zh-tw content'''

   Output (zh-cn): zh-cn content; zh-tw content

   Output (zh-tw): zh-tw content; zh-tw content

7. Discriptions

   Input: -{D|zh-cn:zh-cn content;zh-tw:zh-tw content}-

   Output: Chinese (China): zh-cn content; Chinese (Taiwan): zh-tw content;

• --PhiLiP 20:27, 8 August 2009 (UTC)

Maybe only on wikis with Language Converter enabled? Or use php-generated javascript? --Liangent 17:44, 10 August 2009 (UTC)

Most Used Special Characters Section Needed, Everything Else Awesome :)

The Special Characters in the edit toolbar are the only nuisance I can see in the German prototype. The problem is: there is no section with the most used special characters like there is currently at the bottom of the German WP edit pages. Just please add a section "mostly used" ("meistgenutzt") with the already established selection of most often needed secial characters:

Ä ä Ö ö ß Ü ü • „“ ’ ‚‘ “” ‘’ «» ‹› »« ›‹ – • + − · × ÷ ≈ ≠ ± ≤ ≥ ² ³ ½ † # * ‰ § € ¢ £ ¥ $ ¿ ¡ ∞ ‣ • 〈〉 … → ↔ •   [[]] | {{}} ~~~~ • ° ′ ″

The same should be done for the other language versions, repectively.

Other than that, the Prototype is simply awesome :). The edit toolbar symbols are just in the right order, the header with the search bar is much better, the short syntax help is simply wonderful and the new look/stylsheet looks gorgeous :) :). Also great is that the basic functionality still works with Javascript comepletely disabled :).

Many of the Babaco proposals are awesome as well :). It's great to see that WP is continually improving usability and accessibility and flow of reading and editing and searching articles :).

–91.14.197.76 14:34, 9 August 2009 (UTC)

The problem is that "most used" differs per wiki. On dewiki, ÄäÖöÜü would indeed be among the most used ones, but the folks on frwiki don't care about Umläute and want to see ÀàÁáÂâÇçÈèÉéÊê... instead. For this reason, it's best that such "most used" sections be added through local customization. --Catrope 18:32, 9 August 2009 (UTC)

Perhaps "selected" or "recommended" would be a better term. HereToHelp 02:40, 10 August 2009 (UTC)

Catrope, Yeah, exaclty such local lists of mostly used special characters, like they already exist e.g. in the German WP, I was referring to (yes, that "91.14.197.76" was me before I got me a handy unified login account today, really useful thing, that :D :) :)). As I said already, other than that I love the beta and I really do appreciate your usability initiative and the thought and passion you all put behind it :). Just want to contribute my two cents :D :).--Sternenmeer 14:35, 29 August 2009 (UTC)

Advanced editing functionality

(Discalimer: these ideas might be a little early in the process.) I think that the collapsible toolbar has great potential to make the default interface very simple while being extremely versatile and powerful. Someone mentioned wikiEd above and I think that we can excerpt some of its more commonly useful features for the main interface. Color coding, for example, promises to make the editing window more comprehensible to neophytes and veterans alike. I'd also like to see some way to hide references in the editing window, since in well-sourced articles they can make it very difficult to work with the flow of the text. Speaking of which, refTools is another handy gadget that could be integrated into the default editing space. And as for hiding, the list of pages transcended onto the current page is rather cumbersome. This should be hidden, or removed outright (it would improve load speeds and lessen server load). Does anyone think these are good ideas? HereToHelp 02:39, 10 August 2009 (UTC)

Wasted space

The edit bar is enormous, like a child's editbar. The icons much larger than I need them to be. I thought perhaps that this change was because my laptop is not a 20" monitor, like is more and more the standard, but then the Advanced tab opens a new bloated line below rather than utilising the four inches to the right of "Help". It's bloated and ugly as far as I'm concerned. I'm against this sort of screen-creep. Someone above even said the icons need to be spaced out more. So this signals to me that more than one theme of editbar should be standard, as I cannot even conceive of how it needs /more/ space. I also don't want the toolbar to baby me. I know what ^ and V and + and - mean beside a font. (Also, there is some suggestion that chosing from the Heading drop box will change the toolbar row, rather than insert the heading code.) - BalthCat 07:36, 11 August 2009 (UTC)

Lady Aleena's list of missing buttons

Talk:Prototype#Missing_wiki_markup

To which I add: strike - BalthCat 08:24, 11 August 2009 (UTC)

I suggest strike, too. (Big is imho unnecessary) --Purodha 11:43, 12 August 2009 (UTC)

Backup?

What about a button that stores a copy of a page elsewhere for you to work with. For example, it could copy to /User:BalthCat/Backups/Article Title, and then include the author data at the very end of the backup? Not sure if that is "safe" considering license issues, but it's an interesting idea. Saves the cut/paste/create/save/etc. - BalthCat 08:27, 11 August 2009 (UTC)

I suggest using the Draft Extension for this purpose, and deploy it on each wmf wiki. I tested it locally, and found it saving some 2/3 of of all page versions, which is quite some disk space, backup file size, etc. when projected to Wikipedia; plus nicely giving me a secure feeling that I may not loose much on the next power loss. --Purodha 10:55, 12 August 2009 (UTC)

Position of "insert" button list

Sreenshot, cropped, with marker

There are some buttons which, when the "advanced" edit toolbar view is selected, should be shown following the "insert" label, and not be positioned at the same places as without this selection. Maybe, the move should be in the opposite direction, i.e. both the label, and the additional buttons behind it could be placed where the unlabelled buttons are in non-"advanced" view. I suggest to add labels to all groups, including the two ones remaining in the screen shot shown here, when "advanced" view is selected. --Purodha 11:44, 12 August 2009 (UTC)

Special character lists

I suggest adding two (sticky) buttons formatting the lists of special characters:

1. adjust block height so as to exactly accomodate all special character buttons and not waste space (i.e. shrink or expand verically as needed)
2. where applicable, arrange buttons in a keyboard-like fashion. E.g. for Cyrillic characters, I am faster finding the right ones when they are presented resembling a keyboard, like Macintosh has it, than in the order in which they are pesently presented.

--Purodha 11:10, 12 August 2009 (UTC)

"Wrapping" buttons

I use the "signature" button most, and self-made quoting buttons like "" «» „“ „” ¡! ¿? <code></code>, etc., second most. Note that, typographical correct quotes are extremely rarely found on computer keyboards. As a consequence, many use "'s, and there is a considerable amount of editing owed to correcting quotes, and dashes. --Purodha 11:10, 12 August 2009 (UTC)

Colons in Edittoolbar labels

Sreenshot, cropped, with colons following labels

There are some labels in the new edit toolbar that imho should be followed by colons, at least when translated ;-) see screenshot. Maybe, it is a matter of style, and colons are not needed in English. I admit that the colon-less style looks appealing to me. --Purodha 11:10, 12 August 2009 (UTC)--Purodha 11:42, 12 August 2009 (UTC)

Can I opt out ?

Because of what I said above (#"Script_is_too_slow" error message), I would like to opt out.

I have successfully set the appearance option to "monobook" in Special:Preferences. However, I don't see how I can remove the new toolbar and instead use the older more simple toolbar here on http://usability.wikimedia.org . Teofilo 09:07, 16 August 2009 (UTC)

You can't do that on this particular website, but on all other project wikis, you can do so by pressing the "Leave Beta" button. --Mephiles602 16:12, 17 August 2009 (UTC)

Hello,

Well, not exactly "all other project wikis". http://strategy.wikimedia.org has no "leave Beta" button. My question concerns not only the present but also the future, after açai is no longer a "beta test", but has become a standard product : when that happens, the "leave beta" link will be removed, won't it ?

In the "edit" section of Special:Preferences, I am left with no other choice than enabling or disabling "edit toolbar" (which means here or on http://strategy.wikimedia.org , enabling açai or disabling açai). Why not create another line in the "edit" section of Special:Preferences with "enable old and simple edit toolbar" ? Teofilo 04:01, 18 August 2009 (UTC)

I am sorry that you cannot switch back to old and simple edit toolbar. We are looking into a way to provide preference for it. Bug 20361 Shuhari 06:46, 23 August 2009 (UTC)

You can get rid of the toolbar entirely. Edit your Vector.css (My Preferences / Appearance / Custom CSS) and add this

.wikiEditor-ui-toolbar {display: none;}

Make sure you follow the directions about refreshing the browser cache after you save the CSS file. Unfortunately, you can't restore the old toolbar other than by leaving the beta. Ideally they would have used a different class-name for the new toolbar with the default for it being display:none. Then you could switch to the old or new toolbar as desired. Marc Kupper 00:32, 21 September 2009 (UTC)

Toolbar causes Firefox to lose changes in editbox during back/forward

I am used to walking through browsing history using back/forward when editing (e.g. to check the current article state), which (at least in Firefox) is usually not a problem, since the form contents is kept. However, when the advanced toolbar is enabled, Firefox loses the editbox contents and every time restores it to the original state, losing all my changes.

I know this is not a bug on UsabilityExtension’s part, but in Firefox, but this behavior is a showstopper for me nonetheless; the advanced toolbar had to go. (OK, as an experienced editor, I almost did not use the toolbar anyway…)

For the more technically inclined: the problem seems to be triggered by wrapping the textarea to some divs (using jQuery’s wrap, which clones it in the process), and adding an input above it (in this case, the SELECT for Heading). I commented about the problem at https://bugzilla.mozilla.org/show_bug.cgi?id=209292#c22 Maybe if the toolbar did not use the SELECT…

--Mormegil 15:22, 20 August 2009 (UTC)

It seems the toolbar has been tweaked so there is no SELECT anymore! Perfect, I can use it once again now! --Mormegil 11:28, 9 September 2009 (UTC)

Comparing entries in different languages

I would suggest adding a notation for entries in different languages, e.g., wordcount, categories, completeness, stubness etc.

Template tab

As mentioned here, it would be VERY nice if we godt such a template tab. The tab should be customizable, so that wikis could enter their templates. I dont know if that could be possible, but i hope so! --Masz 16:07, 8 September 2009 (UTC)

Definitely! It took me ages (as a not welcomed newbie) to find the WP page listing possible templates! What I want: A structure drop-down menu containing frequently used templates, plus a link somewhere to en:WP:TEMP page for more information. Nageh 20:15, 6 February 2010 (UTC)

Is this skin designed for rtl (right to left) languages?

I change my language to pesrsian (fa/ فارسی) but it seems skin is not designed for right to left languages. (sidebar doesn't go to right,etc)

Use the Prototype wiki to find the answer to your question. --Mephiles602 15:36, 1 October 2009 (UTC)

Integrating the Wikisaurus project in the editbox

I had the proposition to integrate the Wikisaurus project (http://en.wiktionary.org/wiki/Wiktionary:Wikisaurus) that i seem is really interesting in the editbox of Wikipedia, it could be by a button or function to turn it on off, for some people it is a very useful application, because its saves them time to write an article, also OpenOffice has this function, and brandnew Google Wave also implements this function, why not using a existing project?? --Subcomandante8411:50, 13 October 2009 (UTC)

I would also do the proposal to create a new Logo for the project, Thesaurus has a Dinosaurus, so i just thinked about a Dinosaurus in the form of a W and found the Pterosaurus, the logo is just a dummy for the moment, but anyone can feel free to modify or redesign it. --Subcomandante8419:51, 20 October 2009 (UTC)

Add a word counter to the editbox

I would also propose to add a word counter to the editbox and display the number of words written in the article beneath it, so articles could also been classified by the number ofs it words, articles with 3000 words, articles with 5000 words, and so on... --Subcomandante8414:19, 27 October 2009 (UTC)

A site similar to "Get satisfaction site" from Mozilla

I found the site "Get satisfaction" from Mozilla http://getsatisfaction.com/mozilla/topics, and i found that a really good example for how you could improve suggestion scheme, it is very simple, has a nice front end, and the ideas are voted by the community so the best idea is integrated. I found that a really interesting project which is thinking in the same direction then Wikipedia is thinking, to evolute the web, and make a product for the customer and for the community --Subcomandante8418:22, 27 October 2009 (UTC)

Make the top bar and the menu always visible

It is a bit unhandy to scroll upwards every time you want to see the bar. Perhaps it would be better to get the article into an iframe or something like that so we have a scrollbar on the right of it and always see the controls. Or the menu and the top bar could be initially hidden and show up only when the mouse pointer gets over them, but this would create big problems with console browsers like Links.

better: change css for #panel to positon:fixed 84.114.177.169 04:18, 20 November 2009 (UTC)

Paste issue

While I applaud the WMF usability initiative, can they please give us a feature to paste formatted text as unformatted? It's incredibly frustrating to try to copy from another source into the article text box and find that it's carried over formatting. Certainly this is getting in the way of me clearing the admin backlog on certain areas. - Tbsdy lives 03:03, 5 February 2010 (UTC)

Agreed. I often make piped links the old-school way, by copying the article name into the edit window. Now I wind up with something like big and ugly (although once you save the source code loses the formatting). Still very annoying; there's no reason to (manually) format the text of source code. HereToHelp (talk) 19:19, 6 February 2010 (UTC)

The usability tech team is working on several issues introduced by the release on February 4th. One of the issues is experimental features kept turned on even if you leave the beta. Bug 22402 We should have a fix in place soon, but until then you can restore your old toolbar by going into preferences and disable experimental features under "Editing" tab. Shuhari 19:28, 6 February 2010 (UTC)

The issue of not being able to opt-out from the beta completely has been resolved. Bug 22402 Shuhari 20:39, 6 February 2010 (UTC)

Inserting wikicode into the textarea (iframe)

I've written a script which inputs text into the textarea. How would this most cleanly be done with the new iframe? Is there a good API?

By the way - the normal accesskey and tabindex for the textarea don't work. Skalman 22:39, 6 February 2010 (UTC)

Same problem here. My script looks for the textarea and helps me editing the text. How to do the same with the iframe? Besides, I don't understand why the textarea is replaced with an iframe? Currently I don't see any advantage or benefit. On the other side, the behaviour of the iframe is very different from the textarea. This makes it hard to use and not very "useable". For example, it's not possible to set the text cursor to the end of the text by clicking in the free region below the last line. Selecting text is also very different (try to double click and hold the mouse button to select multiple words, it does not work, at least in Opera). A lot of other problems. So, what's the point? Please tell me if this is'nt the right place to ask such questions. --TMg 21:14, 11 February 2010 (UTC)

It seems Talk:Prototype is the right place to discuss this. --TMg 22:07, 11 February 2010 (UTC)

Localizable character palettes

Someone responded to my request for Vietnamese characters by adding a "Latin extended" category to the "Special characters" pane. But what we really need is a way for localizers (at Translatewiki, for instance) or individual wikis to specify a custom category. Currently the pane is very inconvenient for Vietnamese users, because Vietnamese characters are arbitrarily split between two different categories (three if you count the đồng sign). I realize this arrangement is based on Unicode, but for a Vietnamese speaker, "Á" and "Ả" are each a vowel with a tone mark – they belong next to each other. – Minh Nguyễn (talk, contribs) 07:08, 7 February 2010 (UTC)

One solution would be to create a list for every single language, rather than a list only for different character sets. This would, of course, be quite long... I wonder whether it would be possible to create a personal "favourites" section in the character pane? This might be a solution to the length issue, although it would mean that each Vietamese user would have to create the same personal list. Witty lama 02:11, 8 February 2010 (UTC)

It doesn't necessarily have to be a personal list, just a localizable one. So each MediaWiki locale would be responsible for a system message like MediaWiki:Wikieditor-toolbar-characters-definition. It would have a format much like en:MediaWiki:Gadgets-definition: an unordered list with each item representing a locale-specific category. Each item would have the category name, a vertical bar, and the name of the system message containing the characters for that category. It would look like this:

*Tiếng Việt|wikieditor-toolbar-characters-vietnamese

And MediaWiki:Wikieditor-toolbar-characters-vietnamese would contain a space-delimited list of characters:

À à Á á Ả ả Ã ã Ạ ạ Â â Ầ ầ Ấ ấ Ẩ ẩ Ẫ ẫ Ậ ậ Ă ă Ằ ằ Ắ ắ Ẳ ẳ Ẵ ẵ Ặ ặ Đ đ ₫ È è É é Ẻ ẻ Ẽ ẽ Ẹ ẹ Ê ê Ề ề Ế ế Ể ể Ễ ễ Ệ ệ Ì ì Í í Ỉ ỉ Ĩ ĩ Ị ị Ò ò Ó ó Ỏ ỏ Õ õ Ọ ọ Ô ô Ồ ồ Ố ố Ổ ổ Ỗ ỗ Ộ ộ Ơ ơ Ờ ờ Ớ ơ Ở ở Ỡ ỡ Ợ ợ Ù ù Ú ú Ủ ủ Ũ ũ Ụ ụ Ư ư Ừ ừ Ứ ứ Ử ử Ữ ữ Ự ự Ỳ ỳ Ý ý Ỷ ỷ Ỹ ỹ Ỵ ỵ

The locale-specific categories would be placed at the top of the category list. MediaWiki:Wikieditor-toolbar-characters-definition would be blank by default, so locales (like English) wouldn't be required to create their own categories.

 – Minh Nguyễn (talk, contribs) 07:09, 8 February 2010 (UTC)

Malayalam transliteration Script

Hi, I am from Malayalam Wikipedia (ml:), we are having a transliteration script to type Malayalam using English keyboard. But this script get disabled in Enhanced Toolbar and editbox. Please provide a way to include this kind of scripts to Beta. --Praveenp 17:41, 11 February 2010 (UTC)

Can you link to this script? --83.119.125.27 17:17, 18 February 2010 (UTC)

Sure, Toolbar/Malayalam transliteration Script (extracted from ml:Mediawiki:Common.js). This script is limited to some pre defined text areas. Once we added a script which can work on every text areas. But it got some problems with internet explorer. So we reverted that. Both scripts given in the above mentioned page. If possible add these scripts to enhanced toolbar.--Praveenp 12:30, 18 March 2010 (UTC)

Missing feature

I use the new babaco toolbar and I've noticized that the acai "search and replace" feature it has been removed. It has been dicussed before removing or is a "surprise"? I think it's very helpful form my contributions in "wikify" pagese. Regards.

Just a brief feedback about vector costumization

I just added the first personal button into my Vector it.source skin, boldly manipulating my vector.js file, and I'm very happy and perfectly satisfied. It was impossible to work into it.source under Vector without my own buttons! Pathoshild's Regex Framework works too. The most encouraging point: I am really a deep js-ignorant. :-) --Alex brollo 15:08, 15 April 2010 (UTC)

Could you post a link or something? It would be helpful for others. Also how do I add one of the seperator bars? And hell how do I add the search and replace on my toolbar for my own wiki?

Reporting user's suggestion

Ticket:2010060310036186 would like to suggest a "hide column" link to hide the left toolbar when not needed. User:Elitre 95.247.20.31 19:30, 4 June 2010 (UTC)

No toolbar on Wikipedia

I don't have anytoolbar anymore on Wikipedia (FR at least; probably EN too). I do have the toolbar when logged out, but I don't when I am logged in. Where should I start investigating?--David Latapie 07:53, 10 June 2010 (UTC)

More Klicks - definitely worse than before.

My most used toolbar button is "insert wikilink". It was changed from a one-klick to a two-klick operation. Very bad, since it also forces an additional cursor movement. Time needed is quadrupled. I hate it. --Purodha 11:58, 31 August 2010 (UTC)

Lost Buttons - a huge usability drawback

Among the toolbar buttons, that I use quite often, are "change selection into #REDIRECT[[...]]" and "insert the local typographical pair of quote characters around selection". I have added them to the toolbar with personal JavaScript. With the advent of the "enhancements" of the Unsability Initiative, they became unavailable and thus unusable. Very bad.

My hope had been, to get these two as standard buttons. My hope had been to even receive some more usability built into them:

• change selection into #REDIRECT[[...]], and delete eveything outside the selection,
• insert local typographical pair of quotes around selection, and remove any kinds of quotes at both edges inside selection,

which I had not been able to program myself yet.

Greetings --Purodha 12:16, 31 August 2010 (UTC)

Major problem at Wikisource

There is at least one major problem at Wikisource: [2]. Innotata 22:15, 1 September 2010 (UTC)

Focus lost with new toolbar

There is a difference when using the new advanced toolbar and comparing with the old one:

When editing a page, I usually start typing in the edit box before the toolbar loads completely. Before, I had no problem: I would type and the toolbar would eventually load, and once it did, nothing was disturbed.

With the new toolbar, I tend to do the same: while the toolbar loads (it's usually the last thing to finish loading), I am already typing in the text area but as soons as it finishes loading, the focus on the edit area is lost. Some of my keystrokes are lost and I have to take the mouse to click on the edit area and recover focus.

It would be great if this could be ammended. Right now, I disabled the new toolbar to avoid this effect.

Thanks, Malafaya 13:59, 20 September 2010 (UTC)

Adding character attributes for symbols

Templates generally require that certain special characters, e.g., =, be encoded if they are not to be interpreted as delimiters, e.g. {{tlx|rp|page=666}} must be encoded as {{tlx|rp|page&#061;666}} in order to render as {{rp|page=666}}. This would be asier if the toolbar included something similar to Special characters -> Symbols that included the basic ASCII symbols and that inserted character entities instead of the actual characters. Chatul 13:57, 11 October 2010 (UTC)