Talk:Prototype/Archive 1

From Wikipedia Usability Initiative

Jump to:navigation, search

Contents

[edit] Comments

Please try and be constructive, but positive and negative comments are welcome.

Seconded: too much empty space at top. Screen space is always scarce, especially with browser toolbars eating chunks of it away (and many users would not know how to disable toolsbars). 82.171.96.212 00:55, 3 June 2009 (UTC)
Agree. Too much empty space at top between account info and toolbar. I'm using Firefox 3.0 on Ubuntu 9.04. Probably two much space between menu sections on the left-hand menu pane too. The rest of the beta is shaping up nicely. 146.155.21.158 19:15, 11 September 2009 (UTC)

Thanks, GerardM 06:55, 17 June 2009 (UTC)

[edit] Changes?

I see that the pototypes have the new Vector skin as the default and use MediaWiki 1.16alpha, but are there any other differences? --Michaeldsuarez 20:45, 28 May 2009 (UTC)

We are aiming to make the prototypes as similar to the software and configurations of the actual Wikipedia projects (as they will be upon deployment that is, which is why we are using 1.16). If there's a difference between them, we are either working on it or have not identified it yet, in which case you are welcome to discover such distinctions and let us know if you have some time. --Trevor Parscal 20:58, 28 May 2009 (UTC)

[edit] Missing smart ideas for new skin

In my opinion the prototype has just some cosmetically changes regarding to the current monobook skin. Until now I can't see any big improvements or overwhelming smart ideas. There are still too many confusing links in the sidebar. Why don't you investigate in three or four main sections (like for example in this mock up that considered the site map of the German Wikipedia)? In the German Wikipedia a site map with three main sites for a much easier navigation already exists. The problem is that until know the structure cannot bee seen in the sidebar.
Furthermore it is essential that links with the same "task" are arranged for Wikipedia user groups (readers, editors, admins,...). For example "Printable version", "Permanent link", "Cite this page", "Create book" should be put together to a certain area for readers.
Moreover certain areas should have clear objectives. For example: sidebar -> navigation on Wikipedia-site (articles, portals, about Wikipedia, help,...); area above article -> editing and further details on current article.
I hope that it will be more investigated in clear structures on Wikipedia. In my point of view it's essential that there are as little links as possible for navigation and editing. The challenge to fulfill this task is a very smart creation of groups that guide Wikipedia users to the site or function that they are looking for. --86.32.14.79 11:54, 31 May 2009 (UTC)

Thanks so much for your feedback. We could not agree with you more about a new structure and categorization of the navigation links in the left sidebar. We would love to address all of the issues at once, but we are taking them on one by one. Definitely check back in over the next few months as we hopefully get to addressing the left navigation. --Parul Vora 22:41, 30 June 2009 (UTC)

[edit] Different icon for thumbnails

Currently, we have this icon as symbol for "click here to enlarge the picture". In a discussion at commons-l where this and other posts were written, it was said, that we might need a better icon for this. I guess this project could be the right place to do it. --Flominator 13:53, 1 June 2009 (UTC)

[edit] Some concerns

  1. Drop-down menus do not work on mobile devices like my iPod Touch, which do not have the "hover" feature. This greatly impairs usability on mobile devices. While I realize that there's technically a mobile site, one can't edit from it yet. I commented on this (among other things) back when the new skin was only a mock-up, but didn't hear anything back.
    • Why is the "New section" link for discussion pages hidden in the action menu?
  2. The scripted addition of the note to view the mobile version breaks in an ugly way on a mobile browser.
  3. When a page for a tab (e.g. a talk page) doesn't exist, the blue gradient of an inactive tab clashes with the red of a redlink. (purely aesthetic, but still a consideration)
  4. Can advanced users easily customize the tabs and drop-down menu items?

Thanks, Nihiltres 04:52, 3 June 2009 (UTC)

[edit] From Scratch?

I have a small question,,, why is the beta an empty project and not just connected to the actual wikipedia database,, (or at least an old stable version) that people can just work on it instead of doing everything from scratch??

I assume that should lead to faster testing results, and we'll be able to start measuring differences we'll have when moving the actual thing into the new version from now... Koraiem 12:08, 3 June 2009 (UTC)

We're busy importing content into the prototypes right now; the English and Arabic prototypes already have a lot of content imported. --Catrope 16:54, 5 June 2009 (UTC)

[edit] Add the ability to customize the buttons easily

The new Vector skin is visually appealing. But I'm forced to agree with the writer above that the changes from the present monobook skin are mainly cosmetic. That would fine if cosmetics were the main factor preventing usability. However, my impression is that this skin will not enhance the usability dramatically. Such incremental improvements are disappointing given the number of people working on this project.

I agree with the goal of eliminating clutter and restricting the buttons to the minimum needed for the beginner. Speaking as someone who's edited Wikipedia for years, including Featured Articles, I've never used most of the buttons in the lefthand column of Wikipedia. However, the buttons I choose to ignore – such as "Recent changes" and "Random page" – may well be essential for other users. Have you taken statistics on how often these buttons are clicked by recently registered users? I recommend that you make the portlets in the left-hand column customizable, so that each user can decide what functionality to include in them. Newcomers might be given a small standard set of, say, 7 buttons, e.g., "Help", "Main Page", "About Wikipedia", "Community portal", "Upload file", "PDF version", and eventually the "Create a book" portlet.

The same is true for the 23 buttons at the top of the editing box. Have you taken statistics to see how often they're used? My impression is that most editors don't use them. The XEB extension allows you to customize these buttons and to add forms for the more complicated tasks, such as inline citations; see, e.g., en:User:MarkS/extraeditbuttons.js. Again, I encourage you to make it easier to customize these buttons, and to give newcomers the bare minimum, e.g., "New section", "New subsection", "Add wikilink", "Add external link" , "Add file", "Add inline reference" and possible "Re-use existing reference". A form that connects Diberri's tool with the inline citation creator would be excellent.

You might consider collapsing the interwiki links into a drop-down menu, and also offering the ability to translate them into English on the English Wikipedia, and likewise on the others. I wrote a rudimentary script to do the latter task, which you're welcome to borrow from.

Finally, is this the best venue for offering suggestions? Do you even want outside opinions? Proteins 14:42, 8 June 2009 (UTC)

[edit] My mockup, want to provide some ideas

Article Wikipedia
History of article Wikipedia
Eliminating clutter on talk page, compare with current Wikipedia talk page

So, after reading through the other posts, I want to give some ideas to improve the usability on Wikipedia. I created some mock-ups that are based on screen shost of the new vector skin. The main focus was on the arranging of the links and toolbars and not the layout (there could be some further improvements by a specialist). The main changes are:

This will make the structure of Wikipedia more clearly and will also show new users the full range of possibilities on Wikipedia.

I hope that my ideas can help you a bit and I would be very glad when some of them will be implemented. --Eneas 14:09, 9 June 2009 (UTC)

Excellent work! I really like the second line under the "Article" and "Discussion" tabs, where you list "read", "edit",..., "Other languages". The Category listing may not be clear to newcomers, however. Perhaps preface them with a boldface heading Categories? That could be a drop-down menu as well. Proteins 12:10, 10 June 2009 (UTC)
A few other minor suggestions. I'd put the Search box just below the logo in the lefthand column, followed by the links "Help", "Browse", etc. I'd move the Signpost from the Toolbox to underneath Community Portal. Speaking for myself, I'd also eliminate "Special pages" and "Recent changes" as default buttons, since I believe they're not that important for newcomers, especially on a wiki the size of the English Wikipedia. Perhaps each Wiki can choose its own set of default newcomer buttons? Proteins 12:15, 10 June 2009 (UTC)
BTW, the Talk and History pages are great, too. I like what you did with the header templates on the Talk page. The "More" element on the article and history pages confused me, however; what does it do? Proteins 12:19, 10 June 2009 (UTC)
Article Wikipedia with some minor changes regarding to first mock-up above
Thank you for your comments. I agree with you that the category listing could be a bit unclear but I didn't want to put a heading there. The thing is that in my opinion the category names are more useful than a heading with a pull down menu. However, my idea was to point out some possibilities in arranging things and not to provide a "final draft". As you have already mentioned, just a few links are used regularly by newcomers and perhaps also by people who edited Wikipedia for years. So it has to be found out what links are important and put those links to the correct places. All other links could be hidden in drop-down menus like the "big more-arrow" in the second line under the "Article" and "Discussion" tabs.
After I created the mockups I was asking myself if the links in the the "new second navigation line" shouldn't be arranged on other pages. For example, when we look at the discussion page we can see the "To do list for Wikipedia, Wikiprojects,..." in the extended area of the second line. Perhaps those links are more useful in the extendable "More-area" of the article page and should be put there. Also the page statistics from the "History" page could be put in the mentioned box of the article page. Furthermore it would be possible to put in there links to related help pages. Besides this we have to think about the placement of the icons of sighted versions, excellent articles, geographical coordinates, protected pages and so on. The area above the article pages shouldn't be overloaded as well. As you can see the "more-boxes" open a wide range of possibilities. However, it's very important that the arrangement of those links is very clear, structured and also well-thought-out. On the other hand too much information decrease usability and is contra productive. --Eneas 17:29, 10 June 2009 (UTC)
BTW, just uploaded another mock-up that considered some of your ideas. --Eneas 19:14, 10 June 2009 (UTC)
Hello, Enea. Your suggestions are well thought of and it is great to see them in mock-ups. Both Vector and the new toolbar are still evolving, so I would love to incorporate ideas in the future design. Thanks again for the great design suggestions and mock-ups. --Shuhari 21:12, 12 June 2009 (UTC)
@ Enea: I love you Idea! Thanks a lot for this very well outview, on what is possible at wikipedia. The current Prototyp Design looks very nice, but i don´t think that it is helpfull to increase the usability level for new users. In my opinion, that are only cosmetic changes. Thanks, --91.115.90.244 15:12, 14 June 2009 (UTC)
This is really great. (agreed with the anon above that it is far more than cosmetic, which is nice). What about the interlanguage links? Those are also extremely important and often overlooked. Sj 05:59, 21 July 2009 (UTC)
The interlanguage links are arranged on the right beneath the search button. When the focus of these links should be raised it would be better to place them next to the categories. --Eneas 16:35, 21 July 2009 (UTC)

[edit] 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 :

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)

[edit] Comments and a suggestion

After using the English prototype site, I'm very impressed. I'm glad we're finally moving away from the put-everything-in-a-box design. I also think the new editing interface is a nice improvement (without being too radical). The only thing that threw me off was I couldn't immediately figure out what the icons for the bold and italic functions were for (those 3-D embossed lowercase 'a's) Perhaps they are a bit too fancy. I would prefer the standard bold and italic icons used by WordPress, TinyMCE, etc. They are much easier to recognize. Kaldari 21:24, 15 June 2009 (UTC)

I also think that the icons are not chosen very well. I would use something like [1] for reference, too. Also, it is important for the toolbar to remain customizable. The integrated help OTOH is great; maybe it could even include an equally terse summary of policies? And the context-dependent signature link was a much needed addition. Just don't forget to enable it for the project namespace. --Tgr 15:43, 16 June 2009 (UTC)


[edit] Copyvio

Hello,

the prototype contains copyrigt violations. For example the article EU-Parliament is a copy of the German article without a list of authors or anything else. Its a pity that even we don't respect our own licence and policy. --77.0.37.63 10:51, 21 June 2009 (UTC)

This wiki is for testing purposes only, and is rather confidential because there are very few readers. So on my opinion, copyright is not a priority here. Please do not disturb the developers for such copyright details, which are not the purpose of this usability initiative. Try to provide feedback about usability instead. Thanks. :-) Dodoïste 17:30, 21 June 2009 (UTC)
Yeah, I always knew even Wikimedia doesn't care about the licence. As if it would be soooo complicated to properly import the articles, but how cares. --77.0.47.31 18:58, 22 June 2009 (UTC)
 :-) Maybe they could simply add: "The authors can be found at http://en.wikipedia.orge/wiki/{{PAGENAME}}" in MediaWiki:Copyright ? Dodoïste 20:17, 22 June 2009 (UTC)

[edit] More suggestions for consideration

Hi, good work, thanks for making those changes in the edit-window buttons so quickly! I like the drop-down menus especially.

More suggestions on the edit-window buttons: You have "Lists" and "section headings" listed under "Formatting buttons", which is not intuitive to me and, I suspect, to others. You may want to put those under a separate heading. You also forgot to include one type of Mediawiki list: the discursive list ; and :, corresponding to <DL>, <DT> and <DD> tags in HTML.

A related problem that comes up for visually-impaired Wikimedians is that most other editors aren't careful about where they put the spaces between the list elements, effectively breaking one list into lots of one-element lists. The many lists makes it very hard to follow with a screen reader - try it yourself! That's especially annoying when you go to discussions with >8 participants, e.g., FAC on the English Wikipedia, where they use colons (discursive lists) for indentations. Could you make it so that editors have to do more work to create a separate list? I know it's not directly related to your mandate but accessibility to the blind is part of usability, right? You might want to consult User:Graham87 on the English Wikipedia, or look over the scripts he asked me to write to make his editing easier.

From the second Commons video on usability, I noticed that the infoboxes, inline references, templates, etc. in the edit window were especially daunting to new users. A wall of weird text! A wall from which you can hardly pick out the article's prose. I recommend that, when a typical user opens the edit window, those elements be collapsed into show/hide buttons labeled "Ref1", "Infobox", etc. Making them hidden by default means less clutter for the average new editor, but anyone who wishes to edit those elements can click on them to show them and then edit them. Alternatively, you could make them different colors, as done by the Gadget wikEd, but I think the show/hide approach is much better, because it makes the edit-window version of the article closer to the normal article.

Let me just push again to reduce the number of buttons, particularly in the left-hand column, but allow users to add/subtract/move buttons to suit their own needs. I believe that the present LH-column clutter is confusing and distracting, and also that most of those buttons are little used by most Wikipedians for most of their lifetime on Wikipedia. Again, drop-down menus for the interwiki links and categories, as described above, would be a win.

Perhaps this is asking too much, but your "ref" edit button doesn't distinguish between inline citations (<ref>) and footnotes (<ref group="note">, for example). Both are important elements of the best articles. You also might want to make it standard to give names to inline citations (<ref name="Smith_1979">), so that they can be re-used easily. I'd love to have the option of a fill-in form like the one used in the XEB extension, especially if it links to something like Diberri's tool. The latter would be a tremendous help for scientists who would like to add inline citations to their articles but don't have a lot of free time to edit. Speaking from experience, adding 150 inline citation templates can be half the time I spend in bringing an article up to Featured-Article class. Make that one task more efficient and you make the whole FA process more efficient. Think about it.

Hoping that these suggestions are helpful, and keep up the good work, Proteins 13:25, 24 June 2009 (UTC)

[edit] Still more suggestions on the edit-button bar

Hi,

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

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

[edit] Upper gradient

I like the new design, js help in edit mode is great idea. I however don't particularly like the upper part of the skin. There is (at least for me in FF3) too much space above the navigation tabs, and gradient that fades to white far before the top of the page does not look very well. Goran Obradovic. -- 147.91.1.42 07:59, 26 June 2009 (UTC)

the gradient in general distracts me from the buttons and text. And the turquoise color of the buttons, far more than the color of the separating lines, doesn't look good on my laptop with ff. Sj 05:57, 21 July 2009 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)


[edit] 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)


[edit] 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)

[edit] Vector and toolbar impressions

I cannot reproduce show/hide template function on my FF3/Ubuntu9.04. Will keep looking into it. --Shuhari 06:46, 2 July 2009 (UTC)
Retrieved from "http://usability.wikimedia.org/wiki/Talk:Prototype/Archive_1"
Navigation
Toolbox