Talk:Prototype/Archive 2

From Wikimedia Usability Initiative
Jump to navigation Jump to search

Thoughts from Dispenser

Some thoughts on the icons chosen:

  • The globe used for the external link icon, while near universal, is ambiguous. A better icon would just to use the icon that is next to external links (External.svg).
  • The chain while a clever pun and used in many HTML authoring programs; it continues to remain unclear non-English speakers and those without prior experiance.
  • Image icon is hard to read, far too much detail. Perhaps using a paint brush or digital camera (looking at the backside display?). Earlier versions of Windows had wavy borders (like in old photos) were clearer to read. Another option is a simple screenshot of the floating image thumbnail.
  • I mistake Insert Reference for a spell checking icon. This is likely due to a similar icon in the status bar in MS Word for background spell checking.

"Advanced" should be renamed to "Extended", since it doesn’t actually provide the advanced features (that's in "Special Characters"!?!). The external link icon malfunctions with text selections. It should be able to detect the difference between the title and the links perhaps based on a regular expression.

The new skin vector, while on the surface is a nice new design, it is unpolished in colors and screen real estate. The edit box bare fits into my Firefox’s window (netbook, screen resolution: 1024x800). This is annoying as I have to scroll the outer window. I would like to suggest the team look into making a scroll-less edit box with floating toolbars, such that there will only be the outer scroll bars at any time. Additionally about half the colors that the developer has chosen blending white or black and judging from PDF screenshots I'd say that they were bitten by darker gamma from older macs.

How is the extensibility and customization? Two items in English Wikipedia that would added immediately is a port of refTools and template menu/index system. A template tab would likely be all the amboxes and their inline equivalents that could be placed on another “tab”. This would appear much in the same way as files are displayed on OS X with a preview in the final pane. I would prefer if this was defer in loading.

&emdash; Dispenser 20:53, 1 July 2009 (UTC)

The toolbar is expandable with additional tool icons. Special characters will live on the toolbar, but we couldn't make it enable due to technical issues in importing language specific config. --Shuhari 06:51, 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)

Minor design stufs

  • Customized edit buttons.
  • Interwiki links must be smaller or in dropdown menu.
  • Font itself is too big for all left menu.
  • Top talk/preferences/contributions option font must be smaller to - like left side menu.
    • Other design stufs is quite OK. --Digital1 15:12, 2 July 2009 (UTC)

Signatures in Wikipedia space

I notice that in Wikipedia: space, signatures are not part of the editing toolbar. Signatures are not used in most non-talk namespaces, but in the Wikipedia namespace the signature button should be available, since that's where many process discussions take place.--Ragesoss 19:44, 2 July 2009 (UTC)

Signature icon is available in the editing mode in discussion. It is the sixth icon from the left. Perhaps the icon is not intuitive? --Shuhari 04:53, 6 July 2009 (UTC)
The signature icon looks like a sheet of paper, which is usually used for files. Nx 09:07, 6 July 2009 (UTC)
I know what the signature icon looks like (although I do think it could be more intuitive...calligraphy, perhaps?) but what I'm talking about is that when editing anything that's not in a talk namespace, the signature icon is replaced with the reference icon. That makes sense for the article (i.e., Main), file, category, and maybe user namespaces, but not for the Wikipedia (i.e., project) namespace, which should include both the reference button and the signature button.--Ragesoss 18:48, 17 July 2009 (UTC)
The signature icon has been changed to a calligraphy-like icon, and is now shown for all namespaces except the main namespace, including non-talk namespaces such as the Wikipedia namespace. --Catrope 17:54, 9 August 2009 (UTC)

Signature button placement

Proposal: Signature-Button besides "Save page"-Button! --> Two clicks side by side and the edit is completed. So it isn't so easy to forget ones' signature. Gsälzbär 26.7.2009


No .js?

Couple issues, one larger and two small. First, are personal css and js files not working? I tried to enable some things at en.wiki with the Vector skin turned on, and adding to my User subpage of vector.js did nothing. I guess it could be the scripts themselves though, so feel free to take a peek. The other thing is that it was totally not obvious or clear how to add a topic to this page. Might a simple plus symbol be better than using the drop-down menu for that? Lastly, obviously the placement of upper right hand templates like Qui conflict with navigation links, but it seem the widely used {{administrator}} fails to work altogether in the Vector skin. Steven Walling 19:52, 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)


Large fonts and page tabs

When the fonts are large (not extremely large), the tabs do not fit and become hidden under each other.

For example, at a certain text size at 1024x768 in Firefox 3.0 with image zoom disabled, the tabs on commons:Main Page are:

  • OK with English (en) UI.
  • OK with Esperanto (eo) UI.
  • The Read and Edit buttons are hidden with Russian (ru) UI.

If I make the size a step larger, both en and eo have issues, and ru gets its View history tab half-hidden.

--78.106.150.75 13:50, 2 July 2009 (UTC)

Thank you for sharing your observation. We will definitely need to look into the handling of languages whose tab labels tend to be long. We do not have one-fits-all solution yet, but we'll consider scaling down of font size and etc. --Shuhari 16:48, 2 July 2009 (UTC)

What about [MediaWiki:Noexactmatch] et [MediaWiki:Searchresulttext] pages

Hello everybody, and sorry if I am mistaken coming there. On the French Wiktionary we used to have special search tools, which were available through MediaWiki:Noexactmatch and MediaWiki:Searchresulttext. These pages are now ignored. What can I do ? --Szyx 23:39, 2 July 2009 (UTC)

Thoughts on the vector skin

Okay, I have a few thoughts on the new skin.

First, having the search bar on the right hand side is really weird. Why isn't it with "navigation" like it is in monobook? IMO, it's much easier to find and makes more sense with all the navigation links.

Second, having the cactions on the right side also feels a bit off... some buttons being on the left and some being on the right is kind of weird. E.g., to go to an article's talk page history, you need to move your mouse to the left of the screen and then to the right of the screen, whereas in monobook it's just a short distance away. Perhaps the cactions could be placed immediately below the page/discussion links? I like this idea quite a bit in that regard.

My remaining two comments are related to things which aren't currently in the vector skin but which I think should be. The first is that I think the section edit links should be moved next to the end of the section headers. I helped to create and now use en:MediaWiki:Gadget-lefteditlinks.js, and a similar feature is used globally on the German Wikipedia and some other Wikimedia sites. The usability study said that users got confused about the edit links, and I think that in addition to making pages look nicer (no bunching, etc.), this would make them more visible and clear for new users.

I have one other feature request. If the cactions and search box are moved from their current location, which I quite sincerely hope that they are, it would be a nice feature if the page/discussion tabs contained links to subpages of the current page (with right/left arrows to scroll if there are too many); this would immensely aid in navigation of userspace, some talk pages, project pages, etc. If this was done, then the new __NOSUBPAGELINKS__ magic word could prevent them from appearing (e.g., so that there weren't a bajillion subpage links on pages like "Articles for deletion").

Regardless of what is done, user css/js needs to be easily portable to vector if it is going to be a major skin. I understand that it isn't the highest priority, but everything that could be done to make existing scripts work without needing extensive modifications would be very much appreciated. As one example, scripts that add to the cactions or edit toolbar would currently need to be entirely reworked in order to have them work at all.

Thank you very much for all of the work that you have put into this. I really like some of the new features and ideas... the modifications to Special:Search are just plain awesome, and I like the overall style of the vector skin and the new edit toolbar, even though I find their layout to be a bit cumbersome. --Drilnoth 02:33, 3 July 2009 (UTC)

(oh, just noticed this: The edit summary box seems way too small, and any decent length edit summary will need it to scroll to type in, which is kind of annoying). I personally use a CSS style which extends it to the edge of the screen in monobook, which I think might be a good idea here too). --Drilnoth 02:37, 3 July 2009 (UTC)
The links to the subpages are already live in fr.wikipedia. You may want to take a look on fr:Discussion:Paris (talk:Paris). You can see a list of subpages on top of the talk page. This is produced by fr:MediaWiki:Talkpageheader. Take a look at bugzilla:17163. 84.226.86.76 11:37, 3 July 2009 (UTC)
Ooh... nifty. I hadn't known about that. Thanks! --Drilnoth 15:42, 5 July 2009 (UTC)

Some explanations, though they may not be the position of the usability team:

  • Top-left is the convention for search. See also this article. You'll get used to it :)
  • The separation of contents and actions is intentional and good, since they should be separate. The mouse movement time is irrelevant since page load time is always slower.
  • The prototype that you suggest has a lot of non-trivial problems. The "read/edit/history" selector is poorly aligned. It should be a link, not a button. It's style is inconsistent with everything else. Its verb/verb/noun wording is inconsistent. It implies that read/edit/history are states of the current document, which is wrong. Print is in an unconventional location, and too prominent. The actions dropdown is... strange. Actions is grouped with categories, which is wrong. Categories is about content, and doesn't belong there. "More" is unaligned, meaningless, and probably inappropriate. Other languages is poorly aligned, and linebroken, which is ugly. The familiar line under the main heading is missing. The nested navigation thing is a bad idea. The > bullets are ugly, and the line spacing is bad. It all takes up too much space. Too much is changed at once (even if it was good, it would be rejected by the community).
  • I agree that the ugly bracketed edit links should be cleaned up. They should also be moved to beside the title.
  • Skin compatability really is a low priority (though I agree that it would be a nice bonus), since the few users that rely on hard-to-modify scripts can simply change their default skin back to monobook.

Just my two cents. M 19:06, 5 July 2009 (UTC)

    • I was just mentioning the prototype image as an example of where I think the cactions should be located... I'm not a fan of that propoal's categories, interlanguage links, print button, etc. Having the cactions and search on the right-hand side of the screen still just seems weird to me though. (and congrats on the new edit toolbar; building in the help information and making all of the more complicated, less-used buttons collapse under "advanced" is really awesome!) --Drilnoth 14:47, 8 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)

Comments on Vector

  • Overall: good.
  • Separation of Page/Discussion from Edit/Move/etc good, but:
    • "New topic" in a drop down is bad. Used far too often to justify that kind of hiding. Could it go down at the bottom of the talk page (ie, where the topic will be added)?
    • Can you move "what links here" and "related" changes into the drop down?
  • New search location will take some getting used to.
  • It would really be great if the "go"/"search" dichotomy could be fixed. I've written about this before. Search boxes should need buttons. Probably beyond the scope of a skin though.
  • Feels like there is too much space between page/discussion/read/edit bar and the username/my talk/my prefs bar.
  • Can't say I like the turquoise colour of the thin lines around the sidebar etc. Also, all the fadey stuff (line under 'navigation', the lines separating the tabs at the top etc doesn't appeal to me. It makes the overall appearance sort of soft and wishy washy, whereas Wikipedia has always been hard lines and edges.

That's all now. Stevage 05:48, 3 July 2009 (UTC)

I agree with stevage that the turquoise is a bit distracting; and the gradients in background and especially in the separating rules / lines bother my eye. I would rather do without both. Sj 05:56, 21 July 2009 (UTC)

My comments

Having enabled it on Wikinews, I love it!

  • The red colour on the tab for discussion pages is not very obvious and should be made more red.
  • As above, there should be a new section tab somewhere, shouldn't be hidden.
  • I like the fading lines alot, and the colours. Not wishy washy-just modern!

Keep it up!

Things that need fixing

I'm using this as my default skin on enwiki now, and I've been both porting over my small customizations (see e.g. w:en:User:Nihiltres/vector.css and w:en:User:Nihiltres/vector.js) and looking for more general bugs and places needing improvement. Below is a list of small problems I have seen.

  • On Safari 4 on Mac OS 10.5, if the font size is dialed down too far, the Wikipedia logo is visible outside its bounds, both overlapping the "Page" tab and the top of the page. (Why my girlfriend dials down the font size so far is a mystery to me, but since it's an expected potential behaviour, it should be accounted for.)
  • On Safari 4 on Mac OS 10.4, with normal (default?) font size, the icons for IRC links, e.g. wikipedia-en on freenode are missing a few pixels on the top, cutting off the border of the speech bubble.
  • On all browsers, the action that adds a new section should not be hidden in the dropdown list if possible. I also suggest that it should be titled "New section" instead of "Add topic", because the former is semantically clearer (what is a "topic"?). I changed this on the English Wikipedia a while back, when the default was still the somewhat enigmatic "+".
  • On Safari 4 on Mac OS 10.4 (and probably on all browsers?) the skin-default CSS appears to be overriding Common.css, which interferes with styles designed to be site-wide, such as the pink-backed notice on user CSS/JS pages which now appears white.
  • Why are there span tags wrapping the tab text in the views and namespaces bits, but not in the sidebar, personal, or actions (dropdown) bits? Don't get me wrong, it's easier to customize things without the spans*, but it seems like it would make sense for things to be consistent across elements.
    *Specifically, the main historical path to adding tabs, the addPortletLink script, doesn't quite work as it uses .appendChild( document.createTextNode( text ) ) instead of an innerHTML route. The lack of a span causes tabs to have their text float up to the top of the element, which looks broken. Users can't directly use a mod addPortletLink with an if (portlet == "views" || portlet == "namespaces") branch because addPortletLink is licensed under the GPL.

The skin's been greatly improved since my first look at it; it's my hope that it can get even better. Nihiltres 18:40, 3 July 2009 (UTC)

I forgot a point: the bullets (the list-style image) need to have their transparency fixed, since they currently still have white filling in their rectangle, at least as far as I can tell. They should be using proper transparency instead. Nihiltres 20:19, 3 July 2009 (UTC)
I changed "Add topic" to "New section" on the English Wikipedia. If that's really problematic, feel free to revert, but please explain your reasoning. Nihiltres 15:01, 4 July 2009 (UTC)
Thanks for the insightful feedback. On your comment about "New section" vs "Add topic", we chose "Add topic" as this menu only applies to discussion page, and we wanted to make the tags friendly to users who are new to Wikipedia. Also we chose nouns for the state, i.e. "Page" and "Discussion" and verbs for actions on the right hand side tabs such as "Read" and "Edit". As adding a topic or new section for discussion is an action, we wanted to use a verb for the text to be consistent. We will be reading more feedback and discuss the appropriate text. --Shuhari 04:45, 6 July 2009 (UTC)

addPortletLink

The span wrapping of the action links is causing problems with addPortletLink js function. I think either the spans should be dropped, or the addPortletLink function should be modified to support it. Currently I'm working arround it by manually adding the span after the fact (for the scripts on wikinews that depend on it):

          var b = addPortletLink('namespaces', 
              wgArticlePath.replace("$1", "Comments:" + title), tab_view_comment_on_article)
          var text = b.firstChild.firstChild;
          var span = document.createElement('span');
          span.appendChild(text)
          b.firstChild.appendChild(span)

Cheers. user:Bawolff 02:20, 4 July 2009 (UTC)

Also, jsMsg doesn't work. Bawolff 08:23, 4 July 2009 (UTC)
Also, it doesn't really provide any styling for stuff in the class toccolours, which lots of custom on wiki stuff tends to use to make stuff look like a table of contents. Bawolff 08:36, 4 July 2009 (UTC)

New toolbar and floated items

Floated items break the new toolbar. Click here to see what I mean. A clear would probably solve this. Nx 13:31, 4 July 2009 (UTC)

I saw this bug as well. Adding clear:both; to #edittoolbar was able to solve the issue. Nakon 16:57, 5 July 2009 (UTC)

Review

Certainly an improvement. The emphasis on detail and a clean, consistent, and clutter-free design really stands out. I'm on Chrome, trying the Vector skin on en.wikipedia.org. The following glitches jump out:

  • When a new section is created, a "subject/headline" is inserted between the new toolbox and this textarea.
  • The blueness and the underline of "Advanced" and "Help" make me afraid that I'll navigate away from this edit page, so I avoid clicking them. The underline should probably not appear on 'links' that don't take you away from the current page (also 'watch'). It would be very reassuring if this were consistent.
  • Is there a way to replace that heading dropdown with something better for headings? Level 1 isn't particularly descriptive anyway.
  • I would prefer to scroll my main scrollbar a bit lower, rather than have to scroll to select the topics in help. Perhaps increase help's height just a bit, while reducing the height of each topic?
  • The "Description" heading in help is just fluff, and can be removed without anyone being confused.
  • The text baseline the tab text does not match the baseline of go/search. Go/search is a few pixels too high.
  • Perhaps due to kerning, the text of the logo does not appear left-aligned with the navigation links below. The Wikipedia globe logo should be a few pixels to the left.
  • 'Log out' and the search button are not right-padded consistently with the content. It would be a nice touch if they were right aligned upon that vertical line at which heading underlines end. I think it's the 1em padding on #content.
  • The bottom of that little blue man is not on the baseline of My Talk My Prefs...
  • The v dropdown for other actions does not have a blue background, so it seems grouped with go/search, and not read/edit/history. It would look just a bit better if its flat top was on the same topline as the "ory" to its left, rather than the capitals.
  • Whitespace is nice, but the div upon which the tabs sit is about an inch lower, so some prime above-the-fold space is lost. Content being pushed down isn't usually a problem, but for Wikipedia, it might be. If that line upon which the tabs sit moved up to point towards the center of the globe in the logo, this would be nice.
  • The background gradient starts a bit too high, so the tops of the tabs, which are meant to fade out into the whiteness above the gradient, fade out to white into a little strip of gray which is the start of that gradient.
  • The much nicer bullets are added to tables of contents, which makes them look cluttered.

Thanks for your hard work. M 07:26, 5 July 2009 (UTC)

Thank you for detailed feedback using Chrome. To be honest, our testing focus has been on Firefox and Internet Explorer. We will continue looking into fixing the glitches... --Shuhari 04:50, 6 July 2009 (UTC)
“The underline should probably not appear on 'links' that don't take you away from the current page” ? Youtube and other websites use for this kind of link a dotted border-bottom, which I think is a good way to indicate that the link will not take you away from the page. In the current case, perhaps the triangle has the same function. Delhovlyn 08:49, 18 July 2009 (UTC)

Edit/Modify

Hi. Can you test which word (Edit or Modify) makes people clicking in "edit" tab? Perhaps a visits/edits ratio and a random experiment would be helpful. Thanks. Emijrp 09:57, 5 July 2009 (UTC)

Advanced / Help not working

Hello. I'm using Internet Explorer 7.0.5730.13 in Spanish and I do not see any difference when the Advanced or Help buttons are pressed, except that the triangle at the left is rotated 90 degrees. How do I make them work? By the way, I had to hover the signature icon in order to understand its meaning. Best regards, Alpertron 02:59, 6 July 2009 (UTC)

Image issues

The new bullet image is not properly transparent:

  • Example

On Wikipedia the logo is clipped for some reason: the bottom half of the text is cut off and the top and left sides of the logo are outside the screen area. This occurs on multiple languages, and is not a caching issue on my end, as it occurs even after a hard refresh and on projects where I haven't used other skins before. This is with Firefox 3.5. --Stephen Bain 05:49, 6 July 2009 (UTC)

Ditto the transparency on Safari, IE, both on Mac and PC. Wadester16 22:40, 7 July 2009 (UTC)