Jump to content

Editbox

From Wikimedia Usability Initiative

Editbox discussion

Feel free to add your opinions on the new edit box.
To discuss the current icons, go here. To discuss the Vector skin, or anything else, go 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)

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)

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)

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)

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)

I second this. Any editor should have an undo / redo function. There is no acceptable reason not to have this. Thanks

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)

Off the rails, and half way down the embankment

while I do like the new additions and modifications to the box, I think you are not on the right track. We use mediawiki at work, and have more than 1000 articles in place. However, I find it very difficult introducing new users (GenY,Z) to authoring articles. They just don't get it. They think the editing is clunky and old fashioned. GenY are really looking for a wysiwyg editor, not a text editor. Text editing is fine for sms, but for nice looking easy to read articles, folks want a slick editor. MS-Word, OpenOffice Writer are good examples. If this initiative is to succeed, it must create a wysiwyg editor. Perhaps an alternative is to provide good bi-directional connectivity to openoffice writer? Folks can then simply Edit as they do today, but instead of the editbox, the article/section will be sent directly to openoffice? Please take this is the positive manner in which it is offered. --Paul Kennedy 01:04, 5 August 2009 (UTC)

Retrieved from "https://usability.wikimedia.org/w/index.php?title=Editbox&oldid=2646"