Talk:Prototype/Archive 3

Editing issues with IE 6.0

I have another problem this time on Internet Explorer 6.0.2900.2180 when editing this page and write past the right scroll box. Instead of perform line wrap, the input box extends over the right margin so I cannot see the characters I'm writing. I'm using Show preview in order to see something. There is also an error shown in the status bar at the lower left corner of the window. When I press it a pop up window appears:

Line: 48
Char: 1
Error: 'editToolbarConfiguration.characters' is not an object
Code: 0

Best regards, Alpertron 13:20, 6 July 2009 (UTC)

On which wiki is this? Also, could you try to clear your cache (Ctrl+F5) and see if the error goes away? --Catrope 17:24, 7 July 2009 (UTC)

I wrote: editing this page. So the wiki is this one. The same problem occurs with English wiki. Best regards, --Alpertron 21:37, 7 July 2009 (UTC)

Show/Hide functionality not working

Using Firefox 3.0, Windows XP. Anything on wikipedia that uses a show/hide link is missing the link, and while some of them default to visible, some default to hidden, making them invisible. (see http://en.wikipedia.org/wiki/Discography_of_Final_Fantasy_V for the first option, http://en.wikipedia.org/w/index.php?title=User:PresN&oldid=300305024 for the second.) Additionally, though it's a more minor note, using an absolutely positioned div at the top of the page works in monobook, but not in vector- is there any way to detect if the viewer is using vector and adjust the margin parameters accordingly? (see user page example above). --70.112.182.139 00:48, 7 July 2009 (UTC)

Both articles you linked to worked for me on Firefox 3.0 on Linux (OS shouldn't make a difference here). Please try to clear your cache with Ctrl+F5 and see if the problem goes away. --Catrope 17:22, 7 July 2009 (UTC)

Nope, and I also checked in Firefox 3.5 on Windows- in the article example, the tracklist is supposed to be collapsed/collapsible, and in the user page example, each section is expandable when using monobook- using vector, the show/hide links don't appear for either one. The absolute positioned div problem did go away, however. --163.181.251.10 14:39, 8 July 2009 (UTC)

I have tried again using Firefox 3.0 and 3.5 on Linux and even with IE7 on Windows, and all the show/hide stuff works for me in both Monobook and Vector. Are you sure you don't have JavaScript disabled or have some user JS/CSS interfering here --Catrope 16:45, 9 July 2009 (UTC)

Don't have any user css/js in any skin; javascript is enabled. Checks in IE7 as well, no dice. Also- if you click hide on that Wikipeida elections message at the top (at least in IE7) the appearance of the page breaks, with things overlapping, and requires a refresh of the page to fix. --163.181.251.10 18:03, 9 July 2009 (UTC)

search box

Although it is a good idea to put the search box at the top, I found it hard to find in the top-right corner, especially on e.g. a widescreen resolution. Although moving more to the left or at lest middle would possibly break some of the esthetic balance, I think it would increase the accessibility. --Rainman 13:54, 18 June 2009 (UTC)

I agree. Just under the logo in the lefthand would work better for me. Proteins 13:50, 24 June 2009 (UTC)

I disagree!! It is much more convenient to have the searchbox at the top-right. People are used to it through the browser-search-box.--194.95.111.222 10:48, 6 July 2009 (UTC)

Same here: Just under the logo in the lefthand would work better for me, Also the new layout uses up (waists) vertical "line-space". In the new version the space under the logo is of no use at all for the "average reader". --Zwikki 17:53, 9 August 2009 (UTC)

I strongly agree that the small top right corner search box is a problem. I find that the most popular websites that have the search box towards the top right are fixed-width pages, and are not search-oriented. Usually on sites that are search-oriented, as Wikipedia is, the search box is towards the top middle or top left. They also use bigger, more noticeable search boxes. (e.g. YouTube, Google, IMDb, Dictioary.com) It really is quite a reach when you make the window big, which I think is encouraged by the flexible design. I think it would be good to place it to the right of the Talk / Discussion tabs.--JerrySun 08:15, 16 August 2009 (UTC)

Cursor position

The "average reader" would probably very much welcome, if the cursor were automatilally placed into the search box upon entering the page. On some sisterprojects e.g. in Wiktionary this is already realized. Why not in Wikipedia? --Zwikki 17:53, 9 August 2009 (UTC)

There was a lengthy community discussion against it. Microchip08 20:06, 14 August 2009 (UTC)

Something to do with screenreaders, I believe?--HereToHelp 21:50, 14 August 2009 (UTC)

Why don't put an automatic focus on the searchbox? --synth 18:47, 17 August 2009 (UTC)

It would be horrible for screen readers. That's typically something we should avoid. 89.217.41.230 18:09, 17 September 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)

Toc list and file pages

Toc listing needs the bullets removed in CSS and file pages need CSS as well. Particularly, the file pages need the ToC and metadata skinned. --Izno 00:40, 2 July 2009 (UTC)

Both issues have been fixed. --Catrope 17:47, 9 August 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)

I agree that the "collapse" functionality in WikEd is a great improvement. There are widespread complaints that the "wikitext" is difficult to edit (see the recent discussion at Wikipedia talk:Citing sources). It's hard to write well when you can easily read what you've written. ---- 67.201.96.2 02:33, 8 August 2009 (UTC)

localisation of wiki syntax

It would be great if you could change your syntax messages, so that's possible to localize wiki syntax, too. E.g. MediaWiki:Edittoolbar-help-content-file-syntax: On translatewiki i have to use "File" and "thumb" on german localisation at the moment, because otherwise it would not work on all wikimedia projects. But on german wikis it would be great if "Datei" and "miniatur" is used instead. Merlissimo 10:28, 2 July 2009 (UTC)

We're aware of this issue, but haven't implemented it (yet) because of technical difficulties. We want to fix it, but haven't found the right way yet. --Catrope 17:50, 9 August 2009 (UTC)

Usabitlity atracting more testers.

I'd suggest having a banner at the top of Wikipedia saying "Test our new skin prototype" linking to how to do so. I didn't know at all about this until I saw the blog post on the techblog. Having also something like report a bug or report a new feature at the top of the pages like what is done in Windows 7 would show that the communities input is valued. How would someone know about the new skin without knowing the techblog?--Diaa abdelmoneim 10:51, 2 July 2009 (UTC)

This has been done now with the "Try Beta" link in the top right of the screen. We'd been planning to do this for a long time, but held off on it until the issues with right-to-left wikis had been fixed. --Catrope 17:52, 9 August 2009 (UTC)

Errors using W3C validator

All pages I've seen with this new skin fail the validation performed by http://validator.w3.org . Best regards, Alpertron 14:10, 6 July 2009 (UTC)

To follow up on this a little: Special:BlankPage on Vector on enwiki is valid, but the "Plutonium" article on Vector on enwiki fails with duplicate IDs (due to the page content) and a duplication on the view tab of class="selected". Looks like a relatively simple bug… Nihiltres 22:31, 6 July 2009 (UTC)

Duplicate classes were fixed. We should sanitize the article content more thoroughly, but that's not a skin issue: the exact same thing happens on Monobook. --Catrope 17:57, 9 August 2009 (UTC)

Non-clickable tabs

The tabs Read/Edit/View_history should not be clickable when the user is already in the relevant page. If the user is already in the edit page, the tab should be there but not clickable (just showing where they are). --Geraki 21:05, 7 July 2009 (UTC)

No! They should indeed be clickable (although they don't have to look as clickable). E.g. while editing a section I have to be able to click "edit" - that way I can easily cancel/change my mind and edit the whole page. Another example: if I am looking at a redirect (i.e. redirect=no in the URL) I have to be able to click that same page to follow the redirect (I do that more often than clicking the redirect text since this alternative has an accesskey).

I'm sure there are a lot of other reasons - but please make them clickable. Skalman 16:19, 14 July 2009 (UTC)

This was fixed a while ago: now these tabs are clickable but don't look like it. --Catrope 17:58, 9 August 2009 (UTC)

Mass text layout

Is it possible to arrange the text in columns? The displays become wider and the lines lack for readability. Look at the paper-based daily newspapers. --91.63.138.183 22:35, 9 July 2009 (UTC)

I totaly agree: This would be soooooo nice! But technically it's hard and definitely not possible for WP :(--Juxn 21:38, 11 July 2009 (UTC)

Also: we are considering to introduce a fixed textblock-width in order to solve that problem.--Juxn 21:40, 11 July 2009 (UTC)

The textblock width need not be fixed. A CSS expression like max-width:50em would make the text box variable in size when browsers have text zoom enabled. Also, I think a larger, relative font-size like .9em would make the text more legible.--ao5357 14:19, 7 August 2009 (UTC)

Content

Article content is the "main thing" on Wikipedia. I was using MonoBook skin. I tried the prototype skin in Chinese Wikipedia and English Wikipedia and found that article content is way too low. Too much space at the top. This kind of wasting of space is not acceptable.--? 23:35, 9 July 2009 (UTC)

Accesskeys

You've got to keep the accesskeys as they were in Monobook. Right now the accesskeys for the content page (c) and talk page (t) don't work (maybe there are more - but most seem to be intact). Skalman 19:57, 11 July 2009 (UTC)

Bug 20019 is created. --Shuhari 05:31, 31 July 2009 (UTC)

Another problem: The accesskey for edit (e) doesn't work while editing. Skalman 23:52, 16 August 2009 (UTC)

Not a word processor

While for MS Word tasks, for example, changing font size is a pretty often-used feature, on Wikimedia projects is is not used in mainspace in 99,9% cases. Same thing for most third-party sites. Adding such prominent buttons for <big> and <small> would lead to novices using them inappropriately, which is kinda ... unusable. 62.140.253.9 11:03, 12 July 2009 (UTC)

You're right. Let's remove those <big> and <small> from this toolbar now. Headings and lists are also as important as bold and italic, in my opinion. Delhovlyn 08:37, 18 July 2009 (UTC)

I agree as well. They should at least be removed in Wikipedia, where they serve no purpose and can only do harm. ---- CharlesGillingham 03:49, 8 August 2009 (UTC)

Add Topic

I think the "Add Topic" button on a talk page shouldn't be hidden in the "more" tab. It's one of the most often used things on a talk page... --APPER 21:25, 13 July 2009 (UTC)

I agree. It's nearly invisible for beginners as it is now. Delhovlyn 08:29, 18 July 2009 (UTC)

I totaly agree too. I would suggest a more visible option like in this mockup, see also this section. --Eneas 20:43, 19 July 2009 (UTC)

Bold / Italic

In the new "edit toolbar" there are two buttons for "bold" and "italic". Using the "a" as indicator is a bad idea. Because of having another a for italic (single-story lowercase) it looks like you can switch the font type or something different. I was confused until seeing the tooltips. Not many people know, that this type of a is used in italic. --APPER 21:29, 13 July 2009 (UTC)

Totally agree. This confused me as well. Anxietycello 16:56, 14 July 2009 (UTC)

Agree - a bold "b" and italic "i" would make sense.--Mervyn 09:05, 18 July 2009 (UTC)

That would be English-centric. Besides, you couldn't use the initials for each icon, since some would be duplicates (superscript and subscript, for example). Maybe the two icons should use a more recognizable font (they don't even seem to be the same font), such as something in the lines of Times New Roman. --Waldir 23:04, 18 July 2009 (UTC)

Waldir - well done for pointing out that it would be English-centric (didn't occur to me, I'm not being sarcastic) but I have to say I don't see a problem with this, provided other languages can customise the icons. I realise I slightly stretch the point, but no-one is complaining the tooltips are English-centric... Whatever the solution, I think they've absolutely got to look for some change to those two icons - they're (IMHO) terrible amongst a field of otherwise excellent UI choices --Bedales94 23:54, 7 August 2009 (UTC)

The tooltips aren't English-centric: they have been translated by the folks at TranslateWiki (which took some time, so you may initially have seen English tooltips in non-English environments). --Catrope 18:01, 9 August 2009 (UTC)

Talk or Discussion inconsistency

Not just about Vector, but usability in general - there is confusion about whether the term "Talk" or "Discussion" is used for talk pages - needs consistency. --Mervyn 09:05, 18 July 2009 (UTC)

General concerns and thoughts

I hope you don't mind my being critical -- but I would be unhappy if the current version suddenly became my logged-out wikipedia experience.

• Color - the turquoise background for top buttons really bothers me. I would prefer sticking with the blue/light blue palette.

  that said, please make the Go and Search buttons match the default color of the site; if you switch from gray to light blue, change them too.

• the "v" carat for more options -- please make this a user option; if you want this to be the default for new users, that's fine, but it isn't a very good one for active editors (as mentioned above).

  "Add topic" is currently line wrapping under that menu, as well.

• gradients - I don't like either the top gradient or the gradient rules in the sidebar. a very subtle gradient from blue to gray of the same hue would be one thing; fading to white distracts my eye constantly to the top of the page.
• placement of categories and interwiki links -- how will this be done? I haven't seen good examples yet...
• coloring tabs - if you must color the button tabs at the top of the screen, please make each button a separate constant color (perhaps with a matching 'selected' version that could be paler or could have a gradient fading from its color into the backround of the page -- that's a use of gradient with a purpose :). This will make the whole much less confusing.
• The footer isn't clear.
• The top links for My preferences / My watchlist / My contributions &c run together. separating with a · or the like might help.
• The new edit toolbar and bullet icons are definitely nicer.

Thanks for all of your work so far, Sj 06:05, 21 July 2009 (UTC)

Table of contents CSS error

The version of Vector on the Wikimedia sites has an error to do with indenting on items in the table of contents (it's not present in the SVN version, for some reason a different version is running on the Wikimedia sites). The rule:

#toc ul ul,
.toc ul ul {
	margin: 0 0 0 2em;
}

needs to be set to:

#toc ul ul,
.toc ul ul {
	margin: 0 0 0 2em !important;
}

because a parent rule has !important set, meaning that unless this is changed the rule has no effect. --Stephen Bain 15:39, 21 July 2009 (UTC)

We will look into it. Naoko --Shuhari 05:17, 31 July 2009 (UTC)

This bug was fixed in SVN, I'll be poking Brion to poke this and a few other fixes live. --83.119.125.27 08:46, 31 July 2009 (UTC)

Preference option inconsistency

The option "Enhanced recent changes (requires JavaScript)" in the recent changes tab of the preference page affect both recent changes and the watchlist. I would suggest moving it to the Misc tag or combining recent changes and watchlist together. Dispenser 14:28, 22 July 2009 (UTC)