Talk:Prototype/Archive 5

Where are the feedbacks sent?

Hello. A question has been posted on Japanese Wikipedia about where the feedbacks are sent, and whether one can write them in Japanese.[1] He is also asking what sort of user information is sent along with the feedback. I myself could not find the information on this site so I appreciate if a staff member could clarify these points. Thank you. --Aotake 12:05, 10 August 2009 (UTC)

No right-click on tabs / Short Edit summary box / Why hide tabs?

In order of importance to me:

1. Right-clicking on the tabs, which allowed the browsers I use to choose between "New tab" / "New window", is not possible.
2. The "Edit summary" box is unnecessarily short.
3. Why are some tabs hidden behind a drop-down arrow? There is enough space to display all tabs, so hiding some doesn't gain anything.

-- Michael Bednarek 07:07, 11 August 2009 (UTC)

Why hide tabs? Exactly! Why hide "Add topic"? Why hide anything? This really displeases me. - BalthCat 07:40, 11 August 2009 (UTC)

I noticed the Right clicking on the tabs is just below the actual link (at least on my IE7). Not all links behave like this only Page / Discussion / Read / Edit / View History. This behaviour is very anoying. HenkvD 18:14, 11 August 2009 (UTC)

"Add topic" has been restored to the default view. Trevor is exploring whether we can render the tabs dependent on available screen resolution, rather than always show a fixed number of them; a primary reason to shift some tabs into a dropdown is to avoid tab clutter for low resolution users.--Eloquence 00:43, 12 August 2009 (UTC)

@HenkvD: Thanks for pointing out the obscure and unintuitive location for the right-click on the tabs — that's what I call an Easter egg.

@Eloquence: Clutter? I have huge oceans of white space between the "Discussion" and "Read" tabs (and to the right of the edit summary box); surely, the "next generation" interface is not designed for 800 horizontal pixels?

Something positive: I really like the alert on cancel/close window; inadvertently closing a window has caused me much (self-inflicted) pain. -- Michael Bednarek 14:08, 13 August 2009 (UTC)

Missing tabs on Commons?

I miss the tabs that are used only in commons:
For images the tabs: check usage / find categories / log / purge / en
For user pages: gallery /orphans / untagged
Am I the only one who noticed this? It might be that this issue should be solve by adminstrators on Commons, but I mention it here anyway. HenkvD 18:22, 11 August 2009 (UTC)

Edit Link

So can anyone tell me why the "edit" link for each section is still on the far right edge of the screen, in the most inconvenient place ever?

Two suggestions:

• move the link to either right after the section title or underneath it
• rename it to "edit section" to avoid any confusion

76.182.251.78 03:17, 12 August 2009 (UTC)

Translateability - Internationalization

We customarily call it i18n, but since this term goes with the grossly wrong, and outdated idea "One nation, one language", I'd rather write about translation. :-)

This may be the wrong place for my message, but could not find a better one. Feel free to move it!

Please use message documentation (in the qqq local use language code array) so as to describe what your message texts are about. Do not leave it to translators to find out, or guess. That was a real waste of labour and time. Currently, I found an up to ~50% error quote and misunderstandings in my, and my fellow translating editors, work.

Some random misinterpretatons of the last hours

original	mistranslations	real meaning
"size"	byte count, filesize, girth, amount of data	font size
"big text"	upper case, much text, huge text	enlarged font size
"match case"	hit, in case of a match…	perform a case sensitive search

Especially such short messages or single words as above are ambigious, and prone to being misunderstood. Even more so, when found outside of their context, which is the usuall situation, when you encounter them on translatewiki.net - most often in a bulk with new, or amended, messages from various sources and other extensions. Most translators seem to "believe" in their first (random) associative match, and seem hardly to believe that they could be wrong with it. Since I happen to read a handful of related languages to some extent, when I translate on translatewiki.net, I have the software show me the existing translations that I may understand, and thus I find lots of hardly compatible or even contradictive translations. Getting them straight is some work for several people. Most of it can easily be avoided. When a message is added, you only need to do two things:

• in the qqq array, add a contextual description of the message text, plus a list of its parameters, if any, and their meanings,
• in the en array, add the English message text.

You as the authors doing this, rather than arbitrary other people, also has the advantage that thinking over meanings of message texts, more often than not yields clearer and more precise wordings in English as well.

Thank you for reading this.

Btw. there is a page having internationalization hints in the MediaWiki wiki.

--Purodha 12:38, 12 August 2009 (UTC)

Background

I dont like, that the page background on discussion pages is now the same type as in article pages. This makes ist harder to see where you are. SteMicha 16:48, 13 August 2009 (UTC)

Selecting the beta search box with keyboard

Would it be possible to have the search box in such a way that a single TAB press selects it? It would improve usability IMO. ---Marcus- 07:57, 14 August 2009 (UTC)

Doesn't the accelerator key Alt+f (or Alt+Shift+F, depending on your browser) work for you? -- Michael Bednarek 14:26, 20 August 2009 (UTC)

Thank you for the tip. I was unaware of the existence of such a shortcut. I suppose such a TAB functionality would be redundant then. -Marcus- 07:06, 11 September 2009 (UTC)

Search box placement and empty top space

As a webdesigner I'm immediately struck by the bad placement of the search box and the unused space at the top. The easiest and surely one of the best solutions would be to move the search box to just under the logotype, like Wikipedia Commons does it. The top space should simply be shrinked as much as possible, preferably by also moving the top-most links ("Log out" etc) to the same row as the page edit links ("Edit"/"View history" etc). This would allow the maximum number of users to easily find and navigate to the search box, while minimizing scrolling when reading articles, two very important usability concerns for a site like Wikipedia.

Another option would be to place the search box at the top-left, right next to the logo above the Page/Discussion links, but I believe this position is harder to identify than right under the logo, and it would make it more difficult to shrink the top.

Good work otherwise on the graphics! A nice balance between simple, quality changes while still maintaining the old look. Wintran 08:36, 14 August 2009 (UTC)

HereTohelp's Mockup

Hopefully this has some good ideas.

Hi! After reading through some of the comments I have created a crude mockup of how I think the next revision could look. Notice the following improvements:

• The reduction of whitespace at the top.
• By putting the Read/Edit/History options underneath Article (or Page, whatever) and Talk, we imply that those three options are available for both pages.
• Important options (new section, watch) are displayed and easily accessible. Rarely used options (move, admin actions) are hidden.
• A few extraneous elements are removed: the "view" from "view history", and the bust icon by the user options. Removing one of the search buttons is a possibility, too.
• Tabs can be open or closed, but I think that square edges work better. This skin has a lot of angles and no curves.

None of these ideas are fixed, but rather put forth to spur discussion and goal-oriented ideas. Reactions? HereToHelp 16:02, 14 August 2009 (UTC)

I agree definitely. See also my mockup from this section --Eneas 10:20, 15 August 2009 (UTC)

I basically agree, although I think the search bar is misplaced in both of your mockups. It should be outside the "page" line - since now its position indicates searching within the page. Not sure where to place it, but another alternative would be let the article border go beneath it while keeping the position. Skalman 10:45, 19 August 2009 (UTC)

Thanks for your feedback. That's a good point about the search box. We could put it back over to the left where it is/was in Monobook. On a different note, how do we get someone to implement this idea (which has a 3-0 "consensus")?--HereToHelp 02:36, 20 August 2009 (UTC)

Special characters selector ignores "CapsLock" and "Shift" states

The new "Special characters" list is really cool, compared to what has been activated today in most Wikipedias/Wiktionaries.

Wouldn't it be cool if the "Special characters" selector could detect the current state of "CapsLock" and "Shift" modifier keys, so that it would only show the relevant small letter or capital letter, within the bicameral scripts where they are significant (Latin, Greek, Cyrillic) : this would avoid us to scroll on the list of characters to find the appropriate one, because the displayed list of characters would be twice smaller.

If the current keyboard modifier states can be tracked, then it should be reflected on screen within active buttons which could alternatively be selected with a mouse click.

Additionally, you should be able to select one character in the edited text, and if the selection contains only one character, the list of special characters would be immediately updated to show only (but all) characters that have the same base letter (including those with the other letter case): this would facilitate the edition, because we could just type the text with most letters, adn then be able to correct the few instances by selecting them (shift + left or right arrow, or mouse dragging) and then just click on the character button in the lsit to replace the selected character by the other character variant.

Characters variants to consider should also contain things that are appropriate for some languages: allowing apostrophes to be typed by default with the appropriate character, without needing a special keyboard driver, having then just to select the other apostrophes with the one-character replace feature from the displayed list.

Other things to consider: the support for input methods for non-native scripts, allowing to type greek or cyrillic much more simply by just typing the "equivalent" Latin base letter (i.e. support for transliterations), when the special characters box is open and another script is currently selected and displayed. Possibly extend this support for Hebrew and Arabic. For other scripts, it will be often more complicate due to lack of reference models, but this may be done later as well for some script pairs: discuss this with the users on Wikipedia or Wiktionnary editions for the relevant languages using those scripts, and that quite often need to transliterate words from/to Latin. Note also that transliterations are not often perfect and full of exceptions, but given that we can select a single character after it has been transliterated, and that we correct it in situ with the concept of the 1-character selection and reduced special characters list exposed earlier, this would really facilitate the life of many people, not just the casual editors.

Also make sure that you add the support for the missing scripts.

And complete the support for Vietnamese (that really needs and uses Latin letters with two diacritics, one of them being a modifier for creating a new vowel, the other one being used on top of any vowel to encode the tonality, an extremely important feature of most East-Asian languages that have lot of distinct words with single short syllables where only the tonality allows theur distinction).

And please sort the IPA characters by phonetic type:

• Here also you should not need to scroll this list.
• E.g. group consonnants vs. vowels, then from back to front, consistant order between voiced and unvoiced.
  • You could take an example of sort order from the table that appears in the articles speaking about IPA;
  • Add selectable selectors for consonants or vowels or others (ties, length modifers, stress marks, tone marks, and additional IPA diacritics like nasalisation/rhotacization/etc.).
  • If there are various options, make sure that the IPA symbols from the reduced subset of IPA used in the notation of phonologies come before the other IPA symbols used in the more precise (or academic) notations of phonetic realizations: this could be an interesting option for supporting IPA according to the main language of the current wiki project (but if there is a language selector in addition to the script selector, you could as well take it into account for the input method of any selected script).
  • Make sure that the default script that appears is the default one for the lain language of the current wiki project.
• Or by using the Unicode DUCET order described in the UCA standard, rather than the Unicode binary order (which makes absolutely no sense for most users, given that it just reflects the order of allocation in time, where characters were added in successive versions or in distinct blocks when the existing blocks were full, or when IPA symbols were kept unified with Latin or Greek letters);

  Note that even Unicode admits that the IPA 'g' should not have been encoded, given that this is just a style variant only for typography purists that prefer a single eye rather than a possible double-eye here, this symbol was then just allocated at a time when there was still no "Variant Selectors" in the Unicode standard; on the opposite, most of the Latin versions of Greek letters were NOT allocated specifically for IPA (even if there is a block named with "IPA extensions"), but for actual languages that need additional letters in their Latin orthography : in that case IPA uses these letters preferably, but IPA symbols are in fact not restricted to the Latin script, as it is just a notation, and not an orthography for any language.

• And here also you should be able to group the symbols by similar letters/sounds (consider the various variants of 'r' or 'l' or 'n') using the one-character selection exposed above (which could also be extended to two characters for tied symbols, like t?s or t??).

In other words : continue to improve the usability of the "Special characters" list, to make it even smarter and user-friendly for each supported script (and for transliterations, most often from/to Latin). Verdy p 07:08, 15 August 2009 (UTC)

i think you have some great ideas, but implementing them might be a challenge. HereToHelp 17:13, 15 August 2009 (UTC)

External links with different protocols

For reference, see: normal external link, Gopher, HTTPS, mailto, news, FTP, IRC. And next to each other:        

Some comments:

• The icon sizes aren't the same (all except HTTPS seem bigger than the standard .
• The icons don't seem to be from the same theme.
• The HTTPS and FTP icons don't have distinct borders which makes them a bit fuzzy.

Skalman 17:03, 16 August 2009 (UTC)

Make it clearer that I'm previewing

Right now the text telling that I'm previewing this edit is black and in the same color as the other text so I mix them. I would suggest making it even clearer than in Monobook, perhaps something similar to the usermessage. An example of what it could look like:

Preview

Remember that this is only a preview. Your changes have not yet been saved!

Skalman 17:03, 16 August 2009 (UTC)

We need to make it noticeable, but not too conspicuous. I like the idea, although not the big blue box. HereToHelp 02:38, 21 August 2009 (UTC)

I support this idea. Why not to change page background color? Many times I did not realize I was previewing in the middle of a page and ... you know, changes go lost :(.--Kozuch 15:56, 9 September 2009 (UTC)

Fix display with CSS disabled

Right now there are a few things that don't look very nice when CSS is disabled.

• In the beginning it says "Jump to:[navigation], [search]" (i.e. no space between the colon and [navigation])
• Creating a new section: The textarea should be on a row of it's own. (i.e. not the same as "Subject/headline:")
• The headline for the Page/Discussion nav is "<namespaces>" and for Move/Watch it's "<actions>"

Skalman 00:09, 17 August 2009 (UTC)

How to get more people to try Beta

And why I haven't done so: the Try Beta page doesn't say anything about how easy it is to go back to the old version if I don't like Beta, nor does it say anything about whether it can erase any of my settings/preferences/etc. (my preferences are heavily customized and I loathe to do anything to risk loosing them). --Piotrus 18:46, 17 August 2009 (UTC)

"Try Beta" becomes "Leave Beta" after you opt in, and it doesn't change your prefs (though customizations in your user JS/CSS may stop working while you're running the beta). More than 30,000 people are actively using it, so I don't think there's a widely held concern that it will break things.--Eloquence 07:55, 19 August 2009 (UTC)

Accessibilty improvements via WAI-ARIA

Dear usability team,

Thank you for your work on improving the usability of Wikipedia. I had a look at the current prototype and its source code and immediately thought: Wait, there is something missing! Usability and accessibility go hand in hand. The last weeks I had a deeper look into WAI-ARIA and its support in browsers and assistive technology. The test cases were promising. In fact, so promising that I was wondering why Aria hasn’t been on the agenda yet. (Gez Lemmon gives a good overview of Aria in his article.)

While Aria offers quite a lot there are three concrete things I am suggesting to implement:

1. landmark roles (all are applicable to the prototype)
2. widget roles (applies to our toolbar in edit mode: menubar, toolbar etc.)
3. document roles (article and math will be useful)

As one of the most visited websites worldwide we can provide much better access to our projects for user’s with assistive technology and we can help to promote the usage of Aria. So far, some big players have already implemented Aria in their web applications or plan to do so. We can at least implement the above suggested three types of roles, i.e. adding a role="<type>" to the appropriate elements in our source code. Doing this for the search box will look like this: <div id="p-search" role="search">. Adding roles doesn’t break anything in any older browser or assitive technology, it just get’s ignored.

Is accessibility within the scope of the usability team’s work? Please let me know, if Aria is goingt to be delt with by you. Let me also know, if you need further information or if I can be of any assistance. I am happy to discuss my ideas with you in detail.

Kind regards,
Maria (Wikimedia Deutschland)
Lecartia 13:52, 20 August 2009 (UTC)

I do not know anything about the Wikimedia source code or Aria and very little about usability. But from your description it sounds like it might be doable, and I would consider it within our scope. HereToHelp 02:37, 21 August 2009 (UTC)

Hello HereToHelp, I am happy to hear that you consider accessibility within the scope of your work. So how do we proceed? Is anyone of your team going to look into aria? Would you like to get assistance with that? I was thinking about getting the University of Illinois onboard. They provide the majority of current aria examples and surely would be qualified to analyze your prototype and give valuable feedback. Maria (Wikimedia Deutschland), Lecartia 11:08, 27 August 2009 (UTC)

By the way, there is already one patch concerning aria in the bugzilla for the Monobook skin. However, it is only concerned with landmarks. Widget and document roles are still missing. Maria (Wikimedia Deutschland), Lecartia 11:27, 27 August 2009 (UTC)

Bugzilla is probably a good idea; you can file bugs for the other two roles. You can also try contacting a developer. This project is primarily concerned with the user interface, not the source code, until we move beyond prototyping (which could be several months). If you wait that long, this will probably get lost (which would be a real shame). Hope that helps, HereToHelp (talk) 01:09, 28 August 2009 (UTC)

Do you know Simplepedia ?

Hi folks,

I am on this page, only because internet is full of surprise, this wasn't my aim, but anyway you all seem to be talking about the new Wikipedia.

I have an idea that I'd like to share. I use Firefox + GreaseFire + GreaseMonkey, i.e two addons that allow the user to instantly apply a script from userscripts.org. So now when I am on Wikipedia, the Simplepedia script applies. I think you really should take a look at it, as it makes Wikipedia clear, peaceful and straight to the point.

Hope I helped.

Show Preview-Show Changes as tabs

Props on the new design, and on the ongoing discussion and obvious effort you guys have put in. But... :)

The first time I edited en:wikipedia, the pseudo-html was quite daunting. Now, as I edit, the preview button irritates me:
make changes, scroll down, hit Show Preview, wait..., scroll up to preview, sigh, scroll down to the edit box, rinse, repeat.

Both are symptoms of the same thing, the separation of the raw-code in the text-edit-box from the natural layout of the preview.

I was wondering if it would help to have four tabs above or below the tool-bar: Save Page, View Code, View Layout, View Changes, which would switch easily between the three views. It would feel more natural.

More so, if you can make the text in "View Layout" (ie, preview) editable, how much easier would it be for a newb to edit a table or caption if they don't have to see the formatting? Or for anyone to make a quick drive-by edit, such as a typo or grammar fix, without having to search through a jumble of code for the right part. (Seriously, how many times have you wanted to click on the Preview text while editing?)

It would also create an inherently WYSIWYG design which, as the server-side improves or as html5 adds Java-like browser functionality, would make it easier for you to add further GUI/WYSIWYG functionality; like drag and drop creation and editing of tables and text-boxes, or importing and positioning images. But without replacing the raw code edit-box for heavy lifting.

Hopefully I've explained all that clearly. -- 203.171.199.183 (PaulxSA) 07:12, 21 August 2009 (UTC)

I'm not sure I follow you all the way to WYSIWYG, but having the three views accessible without reloading the page would be a huge improvement. I'm not sure if it can be done, though. HereToHelp 03:03, 23 August 2009 (UTC)

Find and replace, and other functions

A find and replace box in the toolbar would be an enormous timesaver. wikEd has one that works - perhaps you can employ some of that code. en:User:Audacity, 18:56, 22 August 2009 (UTC)

This is already implemented in the latest beta. See a demo here under Advanced of the toolbar. This search and replace is an early demo and might disappear or change of course. TheDJ 12:09, 23 August 2009 (UTC)

I see, thanks. If you have any room to spare, I suggest expanding at least the search into an already-visible box. en:User:Audacity, 14:08, 23 August 2009 (UTC)

I'm not sure I'm following you Audacity, but the DJ, that's a really neat prototype. HereToHelp 14:43, 23 August 2009 (UTC)

Can you take the color-coder from wikEd while you're at it? HereToHelp 03:01, 23 August 2009 (UTC)

That will be a tad more difficult, but it is also one of the things that will be looked at in the future. TheDJ 12:09, 23 August 2009 (UTC)

I think it would be very useful. What about a way to hide references while editing? When half the paragraph is citation templates, it makes it difficult for veterans and intimidating for newcomers. HereToHelp 14:43, 23 August 2009 (UTC)

No wiki markup on Macedonian version of Beta interface

Hello, I am an admin on the Macedonian Wikipedia and translator of the Beta interface, which has recently been implemented. I addressed all this at the talk page on translatewiki.net but no one seems to respond. Upon checking in, we found a very significant problem, which renders the new Macedonian interface useless. Namely, when we edit in the old version we have the Wiki markup buttons below (dropdown menu plus all the tags) as normal. But now on this new version, there is no such thing at all. (while, the new English version does have them). I have no idea why they disappeared for mk.wiki! This means the entire thing is useless, when people can't even have the most fundamental functions like internal linking, categories etc. What should be done?

Another minor issue is that in discussion pages in the new interface, appears the tab "Add topic" in English, in spite of the fact that that message has been translated here long ago. Also the following tags need to be updated, as they have been wrongly translated, and are now corrected. They are: "Talk", a corrected External link icon description and "www.example.org" (which is now translated). Thank you very much in advance!

definition

It would be a great thing to add a definition mark up in editor to let users create a definition for the topic (if applicable), so that the engine could place this definition as a pop-up to every link to the page (title property of <a> tag). This will allow people to quickly understand the context of other pages where this defined term was mentioned. To