Talk:Prototype

From Wikipedia Usability Initiative

Prototype discussion

	Please be specific about which wiki, language preference, browser and operating system you are using when reporting bugs. Ideally bugs should be reported using the Wikimedia Foundation's bug tracking tool.
	This is a general page to discuss the Vector skin and the Beta project.
	To talk about the current toolbar, go here. To discuss the insert dialogs, go here.
	You can find the current list of open bugs for our project on bugzilla here.

[edit] Fix 2nd- and 3rd-Level Heads

Currently, the 2nd-level heads are roman (i.e., nonbold) with a horizontal rule under them. The 3rd-level heads are the same size as 2nd-level and bold. (The heads on this page are not the same format as in the general Wiki articles.)

The problem is that the conventional method of indicating higher-level heads is to use larger sizes and boldface. But here, the two head levels are the same size, and the smaller one is bold rather than the larger. This can be confusing in trying to see how head levels are related.

I suggest making the 2nd-level heads bold and the 3rd-level heads roman and a couple of points smaller, to clarify the relationship between the levels.

[edit] Making Citations Easier

By far the most time I spend on Wiki articles is getting citation formats correct. Why do we have to do this? Instead of having the list of citation types at the bottom of the page, requiring scrolling down to use them, make it a floating, dockable palette in the left margin. When we click a cite type, instead of taking us to a page that shows the format, just open a dialog with the appropriate fields, which we can fill in. For example, clicking a book cite would open a box with fields for author, title, each of the other publication facts, and a blank field at the end for annotation. Fill in any or all, then click Save--the cite is inserted at the cursor location.

One of your strategic goals is to get more readers participating. Since you require citations, if you made creating them less onerous, you'd probably get more people willing to edit. It would also improve the consistency of citations, which are currently all over the place in terms of format.

[edit] Please alter Collapsible Tabs to hide the tab contents onload. Right now they are completely unusable without javascript

This is a common error made when creating expanding/collapsing FAQs. The more usable way to do so is to add a window onload event listener in the script that iterates over the questions and adds a display: none to the node style. That way if javascript is blocked, does not load or has some error, the FAQ still functions just fine. Instead right now the FAQ entries have display: none embedded in the HTML and are unviewable without javascript enabled. This is unfriendly and impairs usability. Given the ease of the fix, I hope you will consider this change.

Thanks for the comment. Vector does the rendering of the drop down menu which you're referring to, but the drop down action is handled with CSS. A :hover psuedo-class is used to change the display: none to a display: block when the user mouses over the menu. It's possible your browser does not support use of the hover psuedo-class on a div element, which may be the reason you're not seeing it functioning. CollapsibleTabs ( which only functions when javascript is enabled ) is a small bit of javascript code that enhances the Vector skin by checking for collisions of the two navigations on the top of the page and shifting menu items into the drop down when necessary to prevent overlaps. --Adam 15:06, 7 January 2010 (UTC)

Since some browsers may not support :hover on arbitrary elements (IE until 7, and IE8 in some modes, and maybe some older versions of other browsers), it seems like a more usable way to do it may be to have the CSS keep them expanded by default, and then use a Javascript "onload" (or similar) function to collapse them when the page is loaded, and add the appropriate "onclick" or CSS :hover stuff. --Aaron dub 19:55, 30 January 2010 (UTC)

[edit] Can we please tidy up and simplify the warnings on the edit page?

My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.

Currently, there are three sources of the warning text on the edit page: en:MediaWiki:Wikimedia-copyrightwarning sits between the edit window and summary box, en:MediaWiki:Wikimedia-editpage-tos-summary sits between the summary box and the edit tools, and en:MediaWiki:Edittools generates the edit tools, as well as a section of warning text that follows it. I feel this is unsightly, confusing, and unnecessarily hard to spot and read. I propose that these messages be merged -- the first two should be deleted, and the text from all three be merged into something I would call "en:MediaWiki:Editwarning" (or something similar) which would be placed immediately after MediaWiki:Edittools, and would contain all the most important warning text of the three old messages, and some new, equally important text that I feel is currently missing. Above is a mock-up of my idea (the code used to generate it can be found at en:User:Anxietycello/Interface) -- Anxietycello 15:13, 2 September 2009 (UTC)

I really like your proposal, Anxietycello. The multiple warning messages have always been bugging me. It is only sensible to put the same type of information in the same place and indicate that they are of the same type. Lecartia 10:15, 10 September 2009 (UTC)

Great proposal. 92.149.132.87 22:43, 10 September 2009 (UTC)

Hear hear! 60.242.48.18 16:30, 16 September 2009 (UTC)

Agreed.HereToHelp (talk) 20:20, 16 September 2009 (UTC)

Glad you all like it! Now how would we go about getting this implemented? -- Anxietycello 21:54, 18 September 2009 (UTC)

Support A really big improvement. I guess to get this implemented you need to get the attention of one of the developers. I hope one of them comments on this.--Diaa abdelmoneim 23:01, 18 September 2009 (UTC)

Strong support, great improvement. 84.226.53.50 18:23, 19 September 2009 (UTC)

Support for change. 86.213.55.50 09:11, 22 September 2009 (UTC)

Would an admin be able to blank the first two MediaWiki pages, and create the proposed text box in the edittools page? That's be an temporary but immediate fix, and then a developer could go through the messages and complete the process..? Unless -- do admins have the right to delete and create MediaWiki pages? -- Anxietycello 17:34, 24 September 2009 (UTC)

Admins can edit it, but we should (1) finalize the prototype and (2) find an admin that knows exactly what they're doing, preferably with some sort of approval. These warnings have legal repercussions of which we should be mindful. You can ask on the talk page. HereToHelp (talk) 00:14, 14 October 2009 (UTC)

Support The message section in the prototype is still way too cluttered. -- JovanCormac 09:48, 5 October 2009 (UTC)

Support much more clear, I support, but first need to check the legal repercussions if any 217.23.3.241 17:25, 14 November 2009 (UTC)

Support - I'd introduce the change in two steps. First clean up the visuals as proposed here, but leave the text untouched (for legal reasons). Second rewrite the text for easier comprehension. --Plauz 15:49, 29 November 2009 (UTC)

Support It's a lot cleaner, and I won't have to scroll as far to get from the Edit pane to the submit buttons. 76.252.13.109 07:21, 1 December 2009 (UTC)

Support. Those small changes make a huge difference. Mahanga 05:32, 19 December 2009 (UTC)

Support I dont like when people repeat themselves, especially if it is on a webpage i see often. --Kirbylover4000 01:44, 10 January 2010 (UTC)

[edit] Alignment in galleries

Here is an example:

some text some text some text File:Giebel Schauspielhaus Demmler.jpg|some text some text some text some text some text some text File:Siegessaeule_(Schwerin)_2.jpg|some text some text some text some text some text some text some text some text some text some text some text

It looks quite bumpy. I think it would be better to align the bottom of the pictures and to align the top of the text. --Rosentod 15:58, 3 September 2009 (UTC)

I think it's fine the current way. SharkD Talk 07:09, 27 November 2009 (UTC)

[edit] "Add section" link at the bottom of discussion pages

It would make sense to have an additional "Add topic" (or "Add section") after all the topics. I (and probably other users too) often read the discussions before posting in a discussion pages, so when it is time to post, I am at the bottom of the page. -W:User:Pgan002

Makes sense. Message boards have a 'Post reply' link at the bottom of a topic thread. Wikipedia should have a 'Add topic' Mahanga 05:34, 19 December 2009 (UTC)

[edit] Greater contrast difference on visited (wiki)links

Todays designs must be little "overcontrasted" - LCD screens have poor color reproduction and especially problems to provide contrast enough. At mine, this technical issue usually boils down to having problems with recognizing visited wikilinks (in general all visited links) from the normal ones.--Kozuch 15:54, 9 September 2009 (UTC)

I agree, it is definitely problematic for me either. I am even thinking about quit using beta just because of that. But since I love the other features, I don't quit. 84.227.56.157 21:10, 9 September 2009 (UTC)

I also agree "Kozuch". Contrast between new or visited links, while very important for users, is often overlooked by webmasters; and even on Wikipedia, is unsufficient in regular edition (where visited links are too less distinguishable from regular text), even worse in this beta. BTW the contrast of inexisting links, unique to Wikipedia (where they are red) is welcome. Michel Merlin 16:11, 15 October 2009 (UTC)

[edit] No good!

I have found the new toolbar to be not very good, it takes somewhat longer to load (I think) and is just one extra thing to deal with when using WikiEd. It slows down the editor loading and has a different form and parameters than Monobook. This will not be welcomed by browser bot operators. I don't like it either when editing by hand. They can always change back to the Monobook skin if they want. I think that there should be an option to turn off the advanced editbar. I do like its drop-down features though. So much for my 2 cents, but this is what I think. Sorry if I made anyone feel bad. Keep at it. Arlen22 00:39, 10 September 2009 (UTC)

I am sure it takes longer to load. When the edit screen is loading you can't do anything than wait. It would be nice if it could be improved. HenkvD 17:52, 12 September 2009 (UTC)

You can just turn it off in your preferences, I don't remember the tab. --90.185.230.210 06:29, 13 September 2009 (UTC)

[edit] Demo feedback

When the pointer is at the top left of the edit box, and I click on the gallery button, nothing appears. But if I move the pointer somewhere else in the editing box, it works properly. I'm using Opera 9.64 with Vista. This problem does not appear in the Açai release. 84.227.159.176 22:26, 14 September 2009 (UTC)

[edit] new version text size

Some of the text seems to big, and other comments: n:Wikinews:Water_cooler/technical#Vector_problems_after_mediawiki_update (permalink). 129.173.163.62 01:46, 17 September 2009 (UTC) (user:Bawolff)

I find the text too small -- it is noticeably smaller than the text on the main site. A text-size control feature at the top of the page might be very helpful. (Not sure how it's implemented through CSS, but I've seen it on some other sites.) (Browser: Firefox ver. 3.5.7) (5 January 2010, user:RandySteer)

 RandySteer 23:11, 5 January 2010 (UTC)

[edit] Add-ons do not work properly

You'll have to find a way how to integrate the special add-ons into the new look. On Huwiki for example, the upper tabline is extended with a button that can insert the most frequently used patrolling templates, making the life of patrollers and sysops easier. With the beta version it often works with errors. Same for the article rating tab, when you try to select a Wikiproject to rate the article, it collides with the article's coordinate template and have to switch out of Beta to be able to use the feature correctly. The extra buttons of Template Master and Cite are also gone if I use Beta. These are add-ons many users use, and for me, a sysop and patroller, are vital. Probably the creators of these add-ons can modify the srcipts according to the new skin, and it is not something the developers can solve, but just wanted to mention. --Teemeah 12:55, 18 September 2009 (UTC)

Hopefully some of these add-ons will be built into the skin. There was a mockup of a template selector somewhere, for instance…HereToHelp (talk) 20:11, 18 September 2009 (UTC)

[edit] Archiving

This talk page is seriously filling up, 114 threads, over 150kb long. Migrated a few templates from the English Wikipedia. Archive threads September 1 and before into six archives with twenty threads max in each. All past discussions are likewise searchable. ChyranandChloe 21:52, 20 September 2009 (UTC)

Thank you so much for organizing the talk page, it is much much more usable. --Shuhari 00:11, 7 January 2010 (UTC)

[edit] In text citations

There has been no simplification of the citation format. While I'm an experienced user (4.5 years/5000 edits), I tend to shy away from using it because it is tricky to use and takes a long time. The <ref> tags are fine, but the <refname {{cite... tags are a real pain in the neck, and I often get it wrong, needing several attempts in preview for a single ref. I avoid editing Featured Articles for this reason! You need to sort this out, particularly as FAs are the ones displayed on the mainpages. I suggest a dropdown menu item, with "type" of ref, then boxes for the relevant fields. 150.203.230.8 23:07, 20 September 2009 (UTC)

I should also add that this is of course going to be worse for a novice user. I remember that when I first started editing in early 2005, almost all of the markup used in the articles was wikilinks, and a little simple html style markup. It was clean and simple, and very easy to use. Most articles on popular subjects were shorter and simpler too. It's proliferated since then, such that an FA is almost unreadable in editing mode. Any usability initiative that fails to address this properly will not have a significant impact on making Wikipedia more usable (and as my above comment suggests, not just for new editors either). 150.203.230.8 23:17, 20 September 2009 (UTC)

I feel your pain. I use refTools, which makes the process much simpler. I would like for this tool to be implemented as standard (in some form) to address the very problems that you mentioned. --HereToHelp (talk) 00:19, 21 September 2009 (UTC)

The beta could take some ideas from WikiEd.[4] One feature is syntax highlighting which makes it easier when sorting through the article, and another is to collapse the references like so.[5][6] Another idea would be the new refs= feature. For example you could name your references and have them all at the bottom now.[7] ChyranandChloe 22:55, 21 September 2009 (UTC)

All of those sound really useful. Can we start an informal "Good ideas list" so this stuff doesn't get lost? HereToHelp (talk) 23:10, 21 September 2009 (UTC)

(outdent) Done. If you want you can move the list to the top of the page, you're a step ahead of me. HereToHelp, can you upload a screenshot for reftools and then insert it into the list? Recommend w:Jing (software) if you need a program that'll do it for you.[8] ChyranandChloe 04:41, 22 September 2009 (UTC)

[edit] I really hope there's an option to move the watchlist back into the tabs

Having the watchlist hidden in a dropdown select causes pain

1. I frequently look at the top of a page to see if the page I'm on is watched or not. Usually I'm working on 20 or more pages at once in tabs and like to know at a glance if it's watchlisted or not.
2. Having the watchlist creates an extra mouse click. That extra click also causes pain in that sometimes I have several pages in browser tabs that I want to either watch or unwatch. I used to hover the mouse over the "Watch" link and do a click/Ctrl-tab sequence to quickly step through all of the windows.

Presumably there's some consensus to hide the watchlist in the dropdown but can a Preferences item be added to allow this to be shifted back into the tabs? I suspect if you are doing this you should also allow the Move function to be added to the tabs just in case there are people that needs to do many moves. Presumably some of the administrative functions are now hidden in the drop-down and those would need editor control too. Marc Kupper 00:55, 21 September 2009 (UTC)

I'm not sure where the "consensus" came from (or any consensus around here, for that matter), but I'm all for putting watch back in plain sight. (Keep in mind that some of the buttons may be moved around.) I think move and admin stuff will be hidden. HereToHelp (talk) 03:11, 21 September 2009 (UTC)

The most common admin tabs are Delete and Protect. If Protect gets put into the drop-down list I suspect many admins will be asking for it back as it shows the page's protection state. If a page is protected the tab says "Unprotect." I've sometimes run into pages where I spotted the protection was wrong as the tab is (or was) clearly visible. Marc Kupper 04:44, 21 September 2009 (UTC)

What about some sort of automatic, always correct system rather than the templates we have now? I think that keeping interfaces changes for admins/non admins would be a good thing (although I see your point). HereToHelp (talk) 23:13, 21 September 2009 (UTC)

These sound like defaults, for example to keep the "watch" out of the drop down. I think the skin should allow customization, one-size-fits-all doesn't always fit; it also saves the figuring over which button should or should not be hidden. ChyranandChloe 04:41, 22 September 2009 (UTC)

We're hoping to investigate two solutions:

• In general, we'd like the tab-bar to be more dynamically responsive to the screen resolution, so that more tabs become visible if space is available, and fewer become visible if it's not.
• For watchlists specifically, we want to look into a "star icon" type approach that's familiar from GMail, Firefox, and other apps. This would save space, allow us to always have the watch feature present, and make the watch state immediately obvious.--Eloquence 04:56, 22 September 2009 (UTC)

I've been using gmail and Firefox for one year and one year and a half respectively. Thanks for explaining me what the star actually means, 'cause I've been wondering what it is until now. I felt it was not important since it is so small and clueless. So I never really tried to use that star. 160.53.250.114 11:09, 22 September 2009 (UTC)

Case in point: I don't think that the star (or any icon) will work. Also, remember that watch is not available to anonymous editors. So the skin will have to change by privilege. I like the idea of each user being able to customize which buttons are shown to his/her liking.HereToHelp (talk) 00:08, 23 September 2009 (UTC)

That makes three things we want: (1) better defined defaults, (2) responsive to editing privileges and screen resolution, and (3) customization. The fourth concept is a "star icon", that is the icon would light up if the page is watch and remain either hollow or dimmed if the page is not; well right now if a page is "watched" the text simply changes to "unwatch", the reversed if the page is not watched. I think this fourth concept is not worthwhile discussed alone, there are two reasons for this: (1) without the text, and for new users, the idea of a star lighting up would be ambiguous; (2) if we had the text and the star, then why not cut the redundancy of the star. Now, with customization, then this could be something to our own choosing, and those who want it or something similar will get exactly that. ChyranandChloe 04:58, 23 September 2009 (UTC)

I really think think the watchlist needs to be a default tab for logged-in editors. I like the goal of being more responsive to screen resolution but this is a tab that one prefers to be seen on sight, rather than have to select to drop down. The Star icon sounds like a cool idea; as to concerns about not being intuitive, it is fairly standard as a bookmark icon and it would presumably have a tooltip popup. DoubleBlue 00:53, 1 October 2009 (UTC)

Two comments:

1. I have designed some basic* JavaScript that will move a tab out of the drop-down menu. I've only tested it in modern versions of Safari, but it's available at w:en:User:Nihiltres/vector.js, near the bottom (the moveActionOutOfMenu function). I've used it mostly for admin-specific usability enhancements like moving the delete button out of the menu whenever a recognizable deletion template is present on the page.

   *I am a newbie at JavaScript; I'm self-taught and my main motivation has been to add bits of JavaScript for use on Wikipedia, so "crude" is probably more accurate :)

2. A star is not necessarily the best symbol to use** for the idea of watching a page, given that we use stars to indicate Featured Articles. Generally, we should try to make sure that there is only one concept per symbol. Perhaps a better symbol would be an eye, a magnifying glass, or some other symbol indicating the general idea of observation. Of course, those are tricky in that there may be symbol conflicts with FlaggedRevs. Nihiltres 19:28, 3 October 2009 (UTC)

    **This assumes that using a symbol as opposed to a label is desirable in the first place. 19:36, 3 October 2009 (UTC)

Good point about the star and Featured. I think that binoculars might work, but I think that it would be too confusing as a default option. I have no problem with offering it with a slew of options to those willing to customize their skin - namely established editors. This means that the defaults can be more friendly to new editors. However, we should make customization as easy as possible, and supported natively (rather than ugly javascript add-ons). I (an probably a lot of others) don't need something as heavy as wikiEd but would like, say, syntax highlighting. And it should have an aesthetically pleasing user interface. This means both appropriate eye candy and simplicity, which are lacking from must add-ons. HereToHelp (talk) 01:41, 4 October 2009 (UTC)

[edit] Watchlist compatibility with Opera Mini browser

Hi.

I exclusively use the Opera Mini 4.2 web browser for JAVA MIDP 2.0 enabled phones (in the more efficient "Mobile view" mode) for reading and contributing to the English Wikipedia. When I try the Beta layout, the "Watch" link disappears from the bottom of the page (the page menus have always appeared there due to the browser ignoring most CSS in Mobile View) when reading an article. This, I guess, is the only major problem I've had with the Beta layout.

Apparently the link is hidden behind some control, according to the above report? Is it using AJAX or something else like that? Because if my phone browser can't read the page properly, then screen readers for visually-impaired users would also have difficulty, and thus this is a more general accessibility issue.

41.157.10.75 06:17, 21 September 2009 (UTC) (En:User:Zyxoas)

You're right, the "watch" is hidden under a drop down, see discussion above. ChyranandChloe 04:41, 22 September 2009 (UTC)

The drop down is either not properly displayed or not available. This is an accessibility issue and needs to be rectified.

41.157.10.70 15:29, 22 September 2009 (UTC) en:User:Zyxoas

[edit] Slideshow

the slideshow is not functioning! -- 217.255.124.29 15:21, 22 September 2009 (UTC)

[edit] easy customization

It shouldn't be a good idea to change the font-size in "#bodyContent" from the default of browsers. When the size is properly configured in browsers (and it should be), the changed size is too small. If some people want the Vector skin to change the size, it should be customized without customizing CSS.

I also want the following can be chosen easily:

• font-family in "#content" (if sans-serif is recommended, it can be warned so)
• background-color configured as white in the skin (since contrast is too strong for me, I changed them to #fcfcfc in my custom CSS, but "li.selected" doesn't seem to be changed without customizing JS) --KAWASAKI Hiroyuki 04:36, 27 September 2009 (UTC), modified 04:59, 27 September 2009 (UTC)

[edit] beta at other wikis

I'm currently working out a new encyclopedia in wikipediastile and think the beta is actually not bad. But can I - and if I can - how can I insert the new way of editing and textwriting in the new encyclopedia? I would like to try it out. But there's no link on the top like in the normel wikipedia. Can anybody help me?

Our beta only runs on wikis operated by the Wikimedia Foundation. Other wikis may or may not choose to run our beta, that's their choice. There's nothing you can do about that other than to push them to add our beta. --Catrope 23:35, 20 November 2009 (UTC)

[edit] Feature suggestion

Hi! It would be great, if a wiki could customize the characters at the "Special scharacters" insert. I really miss the ellipses, endash, and so on. And when one insert a new table, it would be great if one could choose a style, too (like "prettytable").Glanthor Reviol 09:38, 3 October 2009 (UTC)

[edit] Proposal: Introduce a "Reading Mode"

The usability initiative appears to be all about improving usability for editors so far. I propose to do another step and improve reading experience as well. See the following mockup of a "Reading Mode" feature:

All UI elements not directly related to reading are gone, the Wikipedia Logo retreats to the top, language navigation is done using a combo box. Users can conveniently switch to and back from the reading mode at any time with a single click.

This gains a gargantuan amount of screen real estate (20+ percent at a typical resolution) and removes all elements that can possibly distract from reading.

The reading mode is superior to both PDF creation (much easier and faster access) and the printable version (better layout, navigation is still functional) currently used on Wikipedia. -- JovanCormac 10:52, 5 October 2009 (UTC)

We want to encourage people to edit, not just read Wikipedia. We don't need something that places an extra divide between the outward-facing encyclopedia and the inward-facing community. That's the reason that cleanup templates on pages have been around for so long: they encourage people to edit, tell them that they can help with a specific problem on a specific page. In any event, the current design is quite amenable to reading: vertical space isn't at a premium and the sidebar provides nice negative space once the navigation links run out. I don't see a particular advantage in this idea. If you're really concerned about screen space I'd suggest maybe some JavaScript to (voluntarily) tuck away the sidebar when it's not in use, but a "reading mode" doesn't sound like a good idea. Nihiltres 20:14, 7 October 2009 (UTC)

I was afraid that someone would be thinking like this. This is a really dangerous sentiment IMO, albeit a common one. Wikipedia is an encyclopedia, as the "big guys" on WP never get tired of telling everyone. It can be edited, but 90% of users aren't interested in that, as statistics show. Most people just want to read it, because that's what an encyclopedia is for. Editing is an option, not a duty. Showing "Edit" links all over the place with no way to turn them off is not encouraging users to edit themselves, it's practically compelling them. I know people personally who find the many links to be distracting, and would prefer to just read. Having all the extra links visible for everyone all the time just to "preserve the project spirit" has the potential of slowing down the growth of Wikipedia over time. -- JovanCormac 21:18, 7 October 2009 (UTC)

I strongly support Nihiltres' POV: the value of Wikipedia is that it's been read and edited by The People, so anyone who happens to know something that would gain from being added or updated, immediately knows he really can do that edit at once. Of course most people (like me, or Nihiltres, or JovanCormac, or else) spend 95% of their time reading, not writing; most people are reasonable, so the one frantically editing everything may be a danger in a few ones' minds and fears, not in reality. It's against openness, efficiency and progress to divide the society into "readers" and "writers"; everyone should be seen as both.Michel Merlin 17:14, 15 October 2009 (UTC)

JovanCormac, why do you say that "all the extra [edit] links visible for everyone all the time […] has the potential of slowing down the growth of Wikipedia"? My understanding has always been that Wikipedia content is added by editors, not readers. :) Wikipedia can always, always use more editors, and that's a significant amount of what this Usability Initiative has been about—making it easier for people to contribute to Wikipedia. Nihiltres 16:18, 17 October 2009 (UTC)

There'll come a point in the very near future (one could argue it's already here) where people who don't have highly specialized knowledge have very little to add to Wikipedia. Already, in the stastistics, one can clearly see the shift from exponential to logistic growth, with estimates showing that within 3 years, the English Wikipedia will basically have reached its maximum number of articles. From that point on, making Wikipedia grow will mean getting new readers, not new editors, and one way to accomplish that is by making it possible to switch to an interface that caters specifically to readers. -- JovanCormac 08:22, 18 October 2009 (UTC)

I actually agree with both sides. We want to recruit editors, but at the same time, having two interfaces would benefit both mostly-readers and mostly-writers. The mostly-readers interface (that I would call "simple", not "reading" interface) would be focused on reading (with a clean interface not cluttered by tools mostly used by regular participants) but could offer a more proeminent incentive to start editing (maybe something like a big, red, blinking visible "You can improve this page" button that regular editors don't need). On the other hand, the mostly-writers interface (that I would call "advanced", not "writing" interface) could use a lot of links and shortcuts that are most useful to regular participants, who are used to this heavy interface anyway. The advanced interface would actually look a lot like the current interface. This would be a win-win solution in my view. guillom 20:18, 17 October 2009 (UTC)

guillom, I really like your ability to see both sides. As an option, we could Advanced interface Standard and make it default. Advanced, to me, implies that we have optimized it beyond the current interface, doing things that are impossible with a one-size-fits-all interface. Which would be great, but it looks like those things are being integrated into the current interface, and actually getting easier to use (template selectors, dialogue boxes, syntax highlighting). I'm worried the term Advanced would be off-putting.HereToHelp (talk) 22:32, 17 October 2009 (UTC)

I meant "advanced interface" as "interface for advanced users". Links like "What links here", "related changes", "special pages" (in the toolbox), or "(cur) (prev)" (in the history) are particularly incomprehensible; they're typically things that the seldom user doesn't need and that are only useful in case of an "advanced" use of the website. Perhaps "advanced" is not the good word here, because it seems to mean two different things to you and me :) But you get the idea. guillom 06:48, 18 October 2009 (UTC)

Guillom, I like your POV here. Having different views (think "Simple", "Standard", "Advanced") is a reasonable way to go. My concern is mainly the elimination of the invitation to edit. As long as it's clear to users that they can edit, be bold, et cetera, I am quite happy. I'd like a simple mode too, but the key distinction is between simplification and obfuscation. I am fine if people get a reading mode as long as that reading mode does not distance them from the editing mode! I think I'm going to mock up a few ideas on how it could work, and play with hiding the sidebar. Those would be some of the key changes. Nihiltres 19:17, 18 October 2009 (UTC)

I took a few minutes and coded up a really basic implementation of a script to hide the sidebar. It doesn't use fancy sliding animations like the toolbar, or anything, but it does give extra space for reading or editing. Ideally, this sort of thing would be implemented through the software, but as is JavaScript is great for live comparison mockups. Look in the mess that is w:en:User:Nihiltres/vector.js, at the bottom, to find the script. It's really simple; crude, even, but effective. Didn't need to think much about it past looking for what needed to move how far. Nihiltres 21:19, 18 October 2009 (UTC)

I couldn't get it to work. It does nothing for me. -- JovanCormac 08:43, 24 October 2009 (UTC)

Are you using Internet Explorer? I know that it won't work in Internet Explorer (tested with IE8) as written, (no idea why :/ ) though it works perfectly for me in Safari on Mac OS and Firefox on both Mac OS and Windows. Note that you have to select the "Toggle sidebar" option in the Vector drop-down menu even when it does work—I'd like to add some sort of cookie-based setup for the setting to be remembered, but I don't know quite enough JavaScript to do that, yet. Nihiltres 18:55, 24 October 2009 (UTC)

Addendum: noting this revision, you have to include the earlier-defined functions expandSideBar() and collapseSideBar(). That might also cause the failure of the script, since that code in your vector.js page will produce a button that does nothing. Nihiltres 19:04, 24 October 2009 (UTC)

[edit] Syntax highlighting editor

Since it looks like we're not going to see WYSIWYG anytime soon, how about wikitext syntax highlighting for the editor?

I'm not all talk, I've whipped up a fully functional prototype using the CodeMirror framework ([9]).

You can try the fully functional prototype at its SourceForge project page, http://mwcodemirror.sourceforge.net/.

The parser could be further developed to highlight the code even more helpfully (e.g. underlining the caption of a link to indicate what will actually be seen) and to indicate a wide variety of common markup errors while typing. I believe that the CodeMirror framework is flexible enough to even add advanced features like auto-closures and auto-code formatting, but even as it is it can be extremely helpful when editing.

I know there is wikEd which already does this and more, but I have found it to be cumbersome and it looks hard to integrate into Babaco as well with all the icons. Also, wikEd requires the user to click a button each time the text is edited in order to highlight the syntax again. This is not neccessary with CodeMirror. wikEd is also not compatible with Internet Explorer (a show stopper), while MWCodeMirror is.

Feedback is welcome. -- JovanCormac 19:22, 6 October 2009 (UTC)

While I appreciate that it's a prototype, you're still missing a lot of syntax, including headers, references, ordered and unordered lists, template syntax including templates and their calls, parameters, ParserFunctions and other magic words, signatures, supported HTML, extensions, et cetera—do you think that all of those are feasible within this CodeMirror framework? I like the error catching in particular: it would be great if newbie mistakes (e.g. unnecessarily starting a line with a space) would be manifestly evident in syntax highlighting. One last comment: how is the syntax defined to the parser? The ideal parser would grab at least certain parts of its definition (e.g. available extension tag names) from MediaWiki—not all installations of MediaWiki are equal. Nihiltres 20:39, 7 October 2009 (UTC)

All of the things you mentioned are definitely possible with CodeMirror, and more. The editor could easily be adapted to handle complex code highlighting like wikEd has, but with none of its shortcomings. Why wikEd wasn't built around CodeMirror in the first place eludes me. -- JovanCormac 21:25, 7 October 2009 (UTC)

Although the coloring will change, be debated, and (may) ultimately be user-defined, I support the idea fully.HereToHelp (talk) 23:52, 8 October 2009 (UTC)

The coloring and the way the editor is embedded into the user interface I leave to the Usability Initiative team (they're good at it, I really like the designs). As for myself, having now understood how CodeMirror actually works (which I have to say isn't easy), I'd be willing to go all the way in order to turn MWCodeMirror into a fully functional syntax coloring and error-highlighting parser which actively helps users to edit, provided it gets the approval of the UI team's officials. -- JovanCormac 10:19, 9 October 2009 (UTC)

I like it but it doesn't work well with Opera yet. Everytime I try to type in line breaks they appear at the top of the text and the cursor will go there too. I also miss highlighting of template calls and template parameters. It would be helpfull to highlight closing/opening brackets which belong together especially for template programmers. --Danwe 18:15, 19 October 2009 (UTC)

It's just a prototype. Everything you asked for is possible with CodeMirror, but I don't want to put too much work into something that probably won't be used anyway in the end. The feedback process here is awfully opaque for an open platform, with almost no re-feedback from people actually working on the project. Reminds me more of Microsoft than Wikimedia. -- JovanCormac 15:40, 20 October 2009 (UTC)

We're including syntax highlighting as one of the primary features in our Citron release. --Catrope 23:34, 20 November 2009 (UTC)

Wow! having a table of contents in the Edit pane is NICE!!!! 76.252.13.109 07:17, 1 December 2009 (UTC)

[edit] personalising

fist: please excuse my english I'm a medicin student, and when I learn usually wikipedia helps me to get global information (and often also deeper) for nearly all themes i have to learn. I really love to learn with wiki, but it would be even better if it was possible to mark words or passages, that are important for me, put the page in my bookmark, and find my marks again, one ore two weeks later... is that possible? ahaha , it a nice topic

This is already possible with a Firefox extension called Book Text Mark. Please sign you posts btw. -- JovanCormac 13:51, 9 October 2009 (UTC)

[edit] Auto save option

Greets! i am presently working on mr.wikipedia. i do not have a knowledge of programming etc. Can wikipedia have an 'Autosave option' feature installed on it? i generally work 'on line' there and sometiomes face problems like loosing the data due to supply flickering etc. can anyone help in it.

V.narsikar 05:56, 15 October 2009 (UTC)

I know what you mean... sort of like Gmail or Zimbra (et al.) 'auto save' draft option for unfinished emails. However, that would typically require periodically saving a draft version on the server (and therefore perhaps a difficult sell, considering the cost vs. benefit). As an alternative, perhaps a client-side solution may work in the meantime, such as a browser plugin that saves form data? For example, such as "Lazarus" for Firefox? ~ MickScott ~ 01:39, 20 October 2009 (UTC)

[edit] Accessibility issue with the navigation tabs

Hello. The "action" tab is not accessible to keyboard using most browsers, like IE8. This is a major issue, because blind users like w:User:Graham87 - who is an admin on the english Wikipedia - won't be able to use the new skin.

The problem is, when we're on the "action" tab using the keyboard, the menu doesn't expand, and the links are not shown. So they cannot be selected using the keyboard. I hope this can be fixed. :-) Thanks. Dodoïste 16:30, 18 October 2009 (UTC)

[edit] Feature missing in the link dialog

Link dialog with Opera.

Hello. I am using Opera (9.64 and 10). Usually, when I add a new link, I type the text first, then I select it, and I click on the link button. With the new dialog box, when I do that the text I have already written doesn't appear in the "Link text:" form. I am obliged to rewrite it again. Plus, if I select the text, and I click on "insert link", thinking that it would add brackets to make a link, it deletes the text. I hope you can improve that. :-) Thanks, and keep up the good work! Dodoïste 16:15, 20 October 2009 (UTC)

That's a bug in our code, this does work on other browsers. It may or may not have been fixed with the recent bugfix deployment. --Catrope 23:32, 20 November 2009 (UTC)

[edit] Search and replace dialog : cannot replace current selection

There a four buttons : "cancel" ; "replace all" ; "replace next" ; "find next".

When the user clicks on "find next", he may want to replace the current selected word. But there is no button to can do that. Also, the user is not likely to use the "replace next" button, since he won't see what he will replace with that button. It's hard to feel confident when you don't know what you are doing. :-)

I suggest to replace with : "cancel" ; "replace all" ; "replace" ; "find next". Yours, Dodoïste 16:59, 20 October 2009 (UTC)

this makes good sense. By the way - I love the idea of the find-replace button. Neat! Witty lama 14:16, 20 December 2009 (UTC)

[edit] Easier to link to a section

Currently the way to link to a section isn't well done. The proper way is to copy the (article) title, (editor) paste, (editor) type #, copy the (article) section title, (editor) paste, (editor) remove the leading extra space that comes from the [edit] link. This is far too cumbersome!

I propose that we enhance the URL cut-n-paste scheme so it produces nice title, I have posted code to w:User talk:Cacycle/wikEd#simplifyLinks code for prettifying links and suggest that the new fancy editor actually be able to recognize strings beginning with wgServer+wgArticlePath.replace('$1',"") as a article link (as long as there isn't ? character too). 72.68.30.244 20:43, 20 October 2009 (UTC)

[edit] Edit tab missing in Swahili

At present the edit tab in the Swahili Wikipedia is missing in those pages not in the main namespace that have long descriptions of their namespace (eg Project namespace). Perhaps it would reappear if we renamed 'Kufungua historia' ('View history') as just 'Historia' ('history'). Lloffiwr 17:13, 25 October 2009 (UTC)

Should be resolved with the recent introduction of CollapsibleTabs, which collapses the history tab when it runs out of space. --Catrope 23:30, 20 November 2009 (UTC)

[edit] Search Box on the right?

Why is it better to have the searchbox on the right? The connection between logo and search was logical for an encyclopedia. Now it is no longer the first element on the page and has lost this logic. And why two redundant buttons "go" and "search"?

- This was the first thing I noticed, too. Users who already know Wikipedia, will not understand, why the searchbox was moved. BTW: Have you tried a prominent googlish searchbox in the mainframe on the homepage? For me, searching for an article is THE application for Wikipedia. --212.12.50.3 10:39, 28 October 2009 (UTC)

In our usability tests, we had a guy who only realized the search boxed had moved after he'd already used it successfully. Apparently (people who know more about UX than I do may know why) people thing the top right is the logical place to look for a search box: this guy seemed to look there unconsciously. --Catrope 23:29, 20 November 2009 (UTC)

I was also confused by the new location, but for another reason: it appears to be part of the article navigation not the global site navigation.

In the long term, it makes sense to have the search box on the upper right. Search in the upper right of a site is an emerging standard in site layout. See facebook or myspace. But unlike now I'd place it in the very upper right corner.

In the short term I'd place the search box with the rest of the global site navigation on the left, between logo and "Navigation". --Plauz 16:23, 29 November 2009 (UTC)

ENABLE SEARCH CRUSOR UPON ENTRY TO THE SITE... I don't care if the search box is moved to the upper right, but think it should be displayed somewhere more PROMENENTLY than it has been, and at the TOP OF THE HOME PAGE. Wherever it is, I think it is would be vastly improved if the CURSOR is palced IN THE SEARCH BOX upon entering the site, enabling the viewer to start typing the search terms right away. I find myself often starting to type before I have remembered to place the cursor in the box. Sites like yahoo! do this, and it is notably easier. [B. Briggs]

[edit] What do you think of the beta enhancements?

How do the beta enhancements work for you? Tech Blog Post --Shuhari 01:32, 27 October 2009 (UTC)

I haven't tested the prototype again, but just from seeing the blog post screenshot, let me reiterate that the star is a bad choice of symbol for page watching, since stars at the tops of pages are usually reserved for Featured Articles on Wikipedia. Wouldn't it make more sense to use a symbol that implies the act of observation rather than one that can easily be confused with a long-standing indicator of quality? Of course, I don't think that symbol-only buttons are necessarily good for usability in the first place, so this is just… the reverse of the proverbial icing on the cake? …I'll do some more thorough testing in a minute. Nihiltres 23:06, 27 October 2009 (UTC)

[edit] Location of the search box

Quite often I find a term on a Wikipedia page, about which I want to view the article. However, the term is not linked. What I usually do is copy the term and paste it into the search box. However, with the search box entirely on the top of the page, this is a lot of scrolling. It would be nice if there would be an extra search box on the bottom. It may even be helpful to have a copy of the entire navbar on the bottom. Bryan 14:53, 27 October 2009 (UTC)

I think the search box should be unwinded and kept on top like the advanced features are have a look at Polish search and replace gadget. You can test it by visiting polish wiki and activating the gadget "Wyszukiwanie i zamiana". The interface is Polish, but I think the interface is quite easy to learn ("znajdź" is "search", "zamień na" is "replace with"). Oh, and you need to use old toolbar for searching - new toolbar doesn't allow this script to set focus on the textarea. version 1.4.1 should work fine with new toolbar --Nux 08:48, 28 October 2009 (UTC) --Nux 01:04, 28 October 2009 (UTC)

[edit] Search Box / Navigation - why not try fixed postioning?

Here's an idea --- why not use "position: fixed" (CSS rule) on the global and page navigation so that it can always be got to without scrolling? Here's a page with an example of positon: fixed (on the little left navigation area): [10] -- (there are some issues with that page, like fixing the width of the main container, so that the fixed navigation doesn't get hidden if window width is too small, but it shows the principle). It works on IE 7 and later, and on all "good" browsers. Could come up with an alternate fix for those still on IE <= 6.

The whole top and left areas navigation could be fixed so as to be instantly accessible --- and could even add some javascript to optionally show/hide them for people who don't like it that way, or want the article to rule the full window area. Could set an "overflow: " rule on the left nav so that it could still scroll if necessary, if it's too long to fit in the window --- or you could just use it for the top area and not the left.

All you'd have to do for a basic implementation is add "position: fixed" to #panel and #head, (they're already set to "position: absolute" so it's a pretty small change), and then tweak the background and bottom border a bit on #head (adding the existing background-image applied to <body> would work for the background, and maybe something with #head-base for the bottom border).

I'd be happy to help implement if necessary. I think it would be a great usability enhancement.

--Aaron dub 20:21, 30 January 2010 (UTC)

OK I've cobbled together some user CSS to test this concept -- if you want to try it out, go to "my preferences", "appearance", "Vector" (skin), "custom css", and here's the code: [11]

It's not the most 100% ideal code, since ideally I would be able to add a little bit of HTML markup, and I've only tested it in firefox, but it works so far and I like it.

--AaronW from ABQ 21:25, 30 January 2010 (UTC)

[edit] Bug in prototype's "jump to section" feature

Go to http://prototype.wikimedia.org/en-wp/index.php?title=Manchester_Small-Scale_Experimental_Machine&action=edit to edit the article "Manchester Small-Scale Experimental Machine" in the prototype Wiki.

The bug is the following:

• Clicking on the section link "Background" in the editor jumps to the corresponding section, displaying the line "==Background==" at the top.
• Clicking on the section link "Programming" jumps to the Programming section, displaying the line AFTER "==Programming==" at the top.

The first line shown should always be the code for the section header itself in case the user wants to edit that. -- JovanCormac 07:03, 29 October 2009 (UTC)

This is a known bug, which we expect will be fixed in our next release. --Catrope 23:26, 20 November 2009 (UTC)

[edit] Miscellaneous comments

I like the new skin a lot! Two comments:

1. The new skin males the Wikipedia logo look dated and out of place. I suggest replacing it with a vector image, or a better render that makes some use of the new skin's color scheme. If someone can direct me to the POV-Ray source code for the logo, I can see about trying to spruce it up a bit.
2. I would like to see recommendations for infobox/navbox stylings (on Wikipedia and elsewhere) by the same people who created this skin.

SharkD 16:54, 31 October 2009 (UTC)

Agree with both points. It's definitely time to update the logo (while keeping its concept intact). -- 77.1.51.247 10:17, 2 November 2009 (UTC)

Thx for your comment. Both points are pretty much "owned" by the community. If the community decides to redesign the infoboxes I would love tohelp. (Even in my spare time if my boss thinks this is not in the scope of the usability project). Though I cannot start the discussion in the community..--Juxn 21:11, 6 December 2009 (UTC)

[edit] Problems with Beta

1. When you are editing a page, and you click outside of the text area (for example: you open another window or tab) and return to the editing page, you can not edit the text area; when I click on the text area, it jumps to the end of the page and selects, without any reason, a random text around the text area, and when this happens I can't edit the page anymore and finish my story.
2. When you click on a special character (for example: IPA), it placed the character randomly in the text area. When you do this once or twice, there isn't a huge problem but because you have to click on the text area again you get problem "1". Woolters 19:03, 3 November 2009 (UTC)

(If you have any questions about the above statements, please reply on this page!)

I translated the above text from a user on the nds-nl Wikipedia. I don't use Beta so I don't really know what is going on there. What I did notice was that when you use special characters, it places it randomly in you editing page (not where the cursor is). I also noticed, that when you click outside of the editing area then the cursor jumps to the end of the page (quite annoying). I hope someone here can tell me more about this phonomena. Thanks in advance. Servien 19:03, 3 November 2009 (UTC)

I have repeatedly experienced problems similar to those described above. After some trouble free editing. I attempted to insert a cursor prior to selecting a block of text, this resulted in the selection of text after the edit box (ie lists of templates used) and a complete inability to place the cursor within the edit box. The only work around I could find, rather than lose all my edits, was to attempt to refresh the web page, dismissing the two dialog boxes, I managed to refresh the edit page with only the loss of my most recent edits. I am using IE7 under Vista.

82.69.47.218 11:37, 19 November 2009 (UTC) (actually User XTOV)

These bugs should be fixed with the bugfix deployment last Wednesday. --Catrope 23:20, 20 November 2009 (UTC)

[edit] Move "Try/Leave Beta" links further left

I suggest the "Try/Leave Beta" links be moved to the left side of the page instead of the right, above the "Page" and "Discussion" links. I keep clicking on them by accident instead of my User and Talk pages. Here's a quick mockup as an example. SharkD 06:30, 6 November 2009 (UTC)

While this fits on screens with large resolutions, this space would not be available on smaller resolutions like 800x600. See also the section right below this one. --Catrope 22:45, 20 November 2009 (UTC)

I am browsing this site using 1024x768. I don't see how reducing this to 800x600 would make that much of a difference. SharkD  Talk  07:03, 27 November 2009 (UTC)

[edit] Interwiki links

I have posted a comment on the village pump of wikipedia (here) to address the issue of the sister projects (and one or two comments (like this) around to point to there). There is a lot of discussion against the policies and people proposing to merge etc, but I think the simples solution is to improve the inter wiki links which don't work as well as they should. Due to the fact that they need to be in the text, the interwiki links (w:template:sisterlinks) are barely used as much as they should despite being possibly more useful to most people that the inter language links which work well. Although it requires coding by wikimedia staff and may work only in certain skins, but hopefully if it gets the right attention someone who can will fix it. 4 users so far have said they like the idea. --Squidonius 14:31, 5 November 2009 (UTC)

I like this idea. SharkD 04:29, 11 November 2009 (UTC)

This does not scale for large numbers of interwiki links (e.g. from the enwp main page to all other Wikipedias' main pages). Also, screen space on the tab bar is limited, which is why we're collapsing tabs now. It may not look like that in your screen size (looks like 1440px wide or more), but on 800x600px with German texts (which are longer than English ones), stuff gets really tight. --Catrope 22:36, 20 November 2009 (UTC)

Could icons be used in place of text? how about vertical links that go down the left side of the page instead of along the top? SharkD 07:59, 21 November 2009 (UTC)

Here's a quick mock-up of vertical tabs for inter-wiki links:

Of course the color blending isn't as nice, but that can be fixed.

I can upload the HTML source if needed. This and this site offer some CSS tips on getting vertically aligned text working in several browsers. Of course, use of icon images would eliminate the need for "stupid CSS tricks".SharkD 09:20, 21 November 2009 (UTC)

I would like access to the source PSD (or other 32-bit) files used to create the skin's images. Using the 8-bit versions I am unable to create smooth gradients for the vertical links. SharkD 06:53, 27 November 2009 (UTC)

[edit] Question from JS developer

As a sysop maintaining Common.js etc. in one of the WMF projects I have the following questions:

• Can I expect jQuery and plugins.combined.js to stay included on the edit pages all the time? They're so useful that I want to use them but if you suddenly turn them off I'll have to deal with lots of complaints, especially considering the caching of Common.js.
• Is jQuery going to be added on other pages (view, history, special, ...) in the future?
• Is there any guide on how to properly add custom buttons to the beta toolbar?

Alex Smotrov 17:28, 13 November 2009 (UTC)

• Yes, edit pages will have jQuery activated provided the user has enabled at least one beta feature. In other words, jQuery is present if it's needed. Vector also counts as a beta feature, since it uses EditWarning on all edit pages and CollapsibleTabs on all pages, both of which are jQuery-powered.
• Yes, jQuery is currently present on all Vector page views (for CollapsibleTabs, and later for search box enhancements). Also, a certain percentage of page views (0.1% at the moment) use ClickTracking, which will cause jQuery to be loaded regardless of the user's preferences. There is a vague intention to load jQuery on all MediaWiki page views and rewrite MediaWiki's core JS (wikibits.js and the like) to use jQuery, but there are no concrete plans for that yet.
• There is an API for that. It's not extremely well-documented, but there's a rather comprehensive test suite serving as documentation here.

--Catrope 22:33, 20 November 2009 (UTC)

Thank you for the answers. So the current situation when all visitors have about 6 "UsabilityInitiative" css/js files linked from the HTML source is temporary? Then I guess I'll have to write if (!window.$j) importScriptURI('/w/extensions/UsabilityInitiative/js/js2.combined.min.js') in the beginning of my jQuery-based scripts (I hope the path will stay the same). Alex Smotrov 19:26, 24 November 2009 (UTC)

I'll try to figure out how to properly add buttons to the beta toolbar and then maybe make our local extra edit buttons and gadgets work with both toolbars. P.S. I find it a bit odd that beta toolbar option doesn't remove inline script with 11 addButton(...) from HTML source. Alex Smotrov 19:26, 24 November 2009 (UTC)

[edit] Suggestion: "Trash can" for deleted material

Sometimes it happens that an article is deleted for any reason. I suggest to put old material in a Trash can so people can see what has been deleted and why Actually I have used several - now deleted pages - that were perfectly fine.

I - as an example - once wrote an article on a neuro-psychological theme. The editor deleted it with a very expressive reason - "Bullshit!". I just saw my PhD going out the window there. But the experience was good, as it made me question Wikipedia, and also taught me never to write an article for wikipedia ever again. It would have been good though, to at least see it in an available trash-area.

"Deleting" should be "Moving to trash-area". Many articles actually have value - and are still deleted, as just happened to "List of organized crime by country" (or something like that). It would have been so brilliant to have a list like that, which is hard to find elsewhere, and people can check up on themselves - if it is available... even available in the "trash-area".

People don't write immense long articles about something for no reason. Deleting anything that has cost someone effort, puts off the motivation of creating articles.

The trash-can could even have different categories. One for spam. One for "Bullshit!". One for "voted 'keep', but was overruled by an editor."... I'm sorry, but my respect for the wiki editors is not immensely high at this point, due to past experiences. Hopefully this will change.

Pethol

Good idea. But that "trash can" should not be indexed by googlebot and others, it should include a NOINDEX tag or something. 160.53.250.114 18:06, 16 November 2009 (UTC)

Well, you assume that the articles are okay but were still deleted. Many deleted articles are promotion for companies, copyright violations, pure nonsense or contain private personal information (like cyberbullying). Each time a page is deleted, the moderator would also need to decide whether to delete or half-keep it? That's an unnecessary burden because the option delete was put there for a reason. I agree that there are deleted articles (let's say pages) that have value in them but we do have policies to distinguish what needs to be kept and what not. - Simeon 12:53, 19 November 2009 (UTC)

This isn't so much a usability suggestion as a content suggestion, and it's been suggested so many times that it's got an entry on the perennial proposals page on the English Wikipedia: w:WP:PEREN#Deleted_pages_should_be_visible. I think it would be an interesting idea, but it's impractical. Nihiltres 16:40, 19 November 2009 (UTC)

Yes of course there is a lot of junk, as you mention. What I'd like to see kept are those articles that have been written with an effort to add something of true value. I am no internet techie, so I have no idea how to do it on the practical side. As for deletion - if any doubt, the article should go through a user voting for 30 days or so. Almost like a "death-row" for articles with possebility to stay alive in the trashcan for life.

A "death row" or "trash can" is a policy thing that should be suggested to the wiki communities. It's not a technical thing and it's not in our project scope, so although it may be a good idea, this project (the Stanton Usability project, that is) is not gonna implement it. --Catrope 22:41, 20 November 2009 (UTC)

[edit] Cascading Tab

Why is the cascaded tab (with the arrow) on the right side of the watch-tab? It would make more sense if the cascaded tab would be at the same place like its original tab.

[edit] "Link" icon

The "Internal link" icon in the toolbar is not symbolic for non-English speakers.

You made a lot of fuss about not using "B" and "I" icons for bold and italic because those terms start with different letters in other languages, so it is only consequent to apply the same strictness here.

The chain link as a symbol for link is impossible to understand for, I daresay, the majority of worldwide users. You might as well omit the icon entirely.

Example: German. A hyperlink is called "Verweis" or simply "Link" as well. However, a chain link is called "Kettenglied", with "Glied" meaning "Link" when related to a chain. "Glied" can also mean "member" or "penis", but it certainly has nothing to do with a hyperlink.

An underlined, blue word (i.e. a "link") should do the trick. -- 77.1.45.143 15:21, 20 November 2009 (UTC)

Let's explore alternatives. All that I can think of is a globe icon. Has anyone got any other ideas?

We already had a discussion about the link icon, because the chain-metaphor is weak and not intuitive for non-english speakers. But there are not many alternatives

And the chain icon it is not that bad, because it is established as THE icon for link. All around the world. Take a look at popular Software: Most of them make use of the chain. That's why this icons is comprehensible. By the way: Noone says "Verweis" for a weblink, that's a word for references in papers or books; noone has the association "Glied" and "Penis"..

Yes, they do. See http://de.wikipedia.org/wiki/Hyperlink, where hyperlinks are repeatedly being called "(elektronische) Verweise" bzw. "Querverweise". The German Wikipedia also lists the meaning "penis" for "Glied" before the meaning "chain link"... -- 77.1.22.75 13:31, 21 November 2009 (UTC)

The only other idea that might works as well, is a blue link with a hand-cursor. (see: Your Opinion --Juxn 07:56, 21 November 2009 (UTC)

That would obviously be superior to the one used now. -- 77.1.22.75 13:31, 21 November 2009 (UTC)

Thanks for all of the feedback! Unfortunatley, things are rarely so obvious in designing for Wikipedia and all of its communities. That (blue hand cursor) link may have worked if we had kept the icons for creating "internal" and external" links separate. If you have the updated Beta, you'll see that we now have one link button which can be used to create links to pages within Wikipedia, as well as external websites. Our user study confirmed the reasoning behind this merger - namely that less experienced users do not differentiate the two types of links. --Parul Vora 19:27, 23 November 2009 (UTC)

[edit] Search Box for Help-Pages in Edit Page

I would love to have a search box in the edit Pages that searches all "Help" pages for a keyword. For example, when inserting a <ref></ref> I feel oblidged to search on Google to find all the attributes of this element. --Sebculture 12:03, 21 November 2009 (UTC)

[edit] Known Bugs?

I headed to the bugzilla install to see if the issues I'm having are known issues. This page should provide some guidance on which component(s) beta/prototype bugs should be found in. While it's obvious to the implementers, t's not clear to the users....

• Cortado: Cortado video player java applet
• dbzip2: Local and network-distributed bzip2 compression tool.
• MediaWiki: The wiki software itself -- most issues about how the wiki works should go here.
• MediaWiki extensions: MediaWiki extensions, including EasyTimeline, CharInsert, Renameuser, Cite, etc.
• Mediawiki Testing Environment: Bugs relating to the Mediawiki Testing Environment, an effort to standardize testing for Mediawiki.
• mwdumper: Java-based tool for converting and importing MediaWiki XML database dumps
• mwEmbed: MwEmbed is a general library for embedding JavaScript interfaces.
• Wikimedia: Configuration issues and other issues specific to Wikimedia servers, Wikimedia websites (including Wikipedia, Wiktionary, Commons, and the MediaZilla bugtracker) and other Wikimedia specific things
• Wikipedia Mobile: Wikimedia mobile project
• Wiktionary tools: Extended JavaScript and other tools for Wiktionary

I've noticed that the gadgets I use don't seem to work. Rollback doesn't work either: the rollback options don't appear.--69.199.159.154 20:05, 23 November 2009 (UTC)

Clarified bug tracker component at Prototype. Broken gadgets happen, contact the gadgets' authors for that. And which rollback options don't appear? --83.119.125.27 18:49, 25 November 2009 (UTC)

[edit] Nothing new, however.

The classic appearance is what Wikipedia was like prior to 2003. Its features:

• like vector project:
  • a search box at right top,
  • edit page link at the top
  • history link at the top
  • new section link in a quite affordable place
• better than vector project:
  • "my talk-mypreferences-watchlist-contribs-logout" are not cluttered in one continuous line at right top
  • languages list is at the top (I use it quite often)
  • style is more accessible and calm
    • no gradients
    • no color dominance (blue)
  • toolbox is more narrow
  • less space is empty at the top
  • toolbox has no dark background
  • the font is serif, what means much easier to read.

Therefore, I would rather choose the minimalistic classic appearance. (You can try it out - choose "classic appearance" in your preferences.) This is my feedback, and I would be extremely surprised to hear anything good about this new project. Want to surprise me? Please reply here. Q0k 07:31, 26 November 2009 (UTC)

Just a few off the top of my head: --Catrope 23:37, 26 November 2009 (UTC)

Dear Catrope, I thank you for your time and attention. For clearer understanding, please reply on every of my following paragraphs: Q0k (~~ ?) 01:04, 27 November 2009 (UTC)

• Clearer separation between namespace tabs (Article, Discussion) and action tabs (Read, Edit, Add section, History) --Catrope 23:37, 26 November 2009 (UTC)

No, the classic theme groups action links at the left, in the toolbox, all of them; this vector theme makes you forget that you can also to such actions, as watch this page and move this page. Besides, discuss this page also is an action, isn't it?! Q0k (~~ ?) 00:40, 27 November 2009 (UTC)

Where is the upload file action in vector theme?! Are you joking?! Can't I upload files anymore? The word "upload" is absent on this page... So is the word "file"... Bad news... Q0k (~~ ?) 00:43, 27 November 2009 (UTC) Aa, I found it at Wikipedia prototype, but it is very far from the action tabs (Read, Edit, Add section, History). Why? Is file upload really not an action? It feels like "file upload" action is lonely in vector theme... Q0k (~~ ?) 00:56, 27 November 2009 (UTC)

• Collapsing Add section and History tabs into dropdown when the screen is narrow --Catrope 23:37, 26 November 2009 (UTC)

That does not happen at my machine, and makes you forget about one of them: either forget about history, or forget about adding sections. Nothing very good, I do not have complaints about classic theme with narrow screen. Q0k (~~ ?) 00:40, 27 November 2009 (UTC)

• Nicer-looking search box (only on the prototypes right now) --Catrope 23:37, 26 November 2009 (UTC)

Why exactly do you think that search box looks nicer? Though I do not see any difference, that sounds really interesting. Q0k (~~ ?) 00:40, 27 November 2009 (UTC)

Oh, I have found the prototypes, and the new search box.Q0k (~~ ?) 00:52, 27 November 2009 (UTC)

Why can't I do two different actions: Go and Search - now? What's wrong with them? I do not want to "Go" to Bonzo Dog Doo-Dah Band, as this search box does, I want to "search" which articles mention it... Q0k (~~ ?) 00:52, 27 November 2009 (UTC)

The older search box could contain "01234567890123456789" fully seen, while this new box can contain only "0123456789012345"; the new one is 4 symbols, 20% shorter, why so cruel? I am often searching for some physics phenomena, they are not that short... Q0k (~~ ?) 00:52, 27 November 2009 (UTC)

• The watch star (relatively new) --Catrope 23:37, 26 November 2009 (UTC)

That is confusing: watch star and starred articles, isn't it? Q0k (~~ ?) 00:40, 27 November 2009 (UTC)

I didn't design Vector, and I'll ask the guy who did to give a more elaborate and more informed response after the Thanksgiving weekend. Also, note that some of these things (like the Read tab and the namespace/action separation) were designed for the benefit of novice users. --Catrope 23:37, 26 November 2009 (UTC)

That is a common misconception: "novice users see only basic actions, they do not need advanced features.". I do not agree. The interface should not concentrate on the level of proficiency/experience/abilities of the user, and must be accessible (classic theme certainly is). Q0k (~~ ?) 00:40, 27 November 2009 (UTC)

Searching for "012345": the top sentence is "This is a prototype wiki used by the usability project to showcase their improvements and allow people to test them. THIS IS NOT A REAL WIKI.", and the bottom one is "Create the page "012345" on this wiki!". Is it not contradictory? Q0k (~~ ?) 00:59, 27 November 2009 (UTC)

I am sorry that you don't like our work. But please note that we did professional usertesting whereas you just reprensent a single opinion.--Juxn 16:52, 27 November 2009 (UTC)

Please be so kind as to explain your opinion below each of my paragraphs, I'm just curious about why all this is going on. ☺ I promise not to answer your comments (for not to create a conflict), and in return I pledge you to express your thoughts as full as you can ♫. Q0k (~~ ?) 23:39, 27 November 2009 (UTC)

Q0k, you should try the sandbox 5. Once you have go to Opinion Colors to discuss it. --Mephiles602 09:58, 28 November 2009 (UTC)

To summarise, I'm creating a table, hope anybody fills it out. Q0k?... 00:10, 29 November 2009 (UTC)

Actually you are free to opt out and keep using monobook. We are only creating a new skin, which is like a new offer. Everyone is free to choose. By the way: We have a retention rate for en-WP of 83%. Not too bad in my eyes.--Juxn 19:32, 4 December 2009 (UTC)

• You know, when I am not logged on, I have to look at the default appearance of wikis. At Wikipedia, the skin was monobook, not so ugly.
• When I came to Wikinews from Google results page and saw this vector appearance, I was frightened, I thought this is a fake site, and I closed the browser window. The main ugliness of it is in
  • the gradients (though this is not objective),
  • go/search combination in search box (like the Microsoft Bing and Live searches, Microsoft is a very bad example with its Windows 7 decline),
  • many empty space above the tabs, and
  • its overall look like for children (the so-called "novice users get confused" paradigm).

121.168.5.179 01:49, 5 December 2009 (UTC)

Well the fact is that it is impossible for everyone to like the vector skin. You are one of the people in the world who dislikes it and there is absolutely nothing wrong with that. Personally, I love it, but there's absolutely nothing wrong with you using a different skin. --Mephiles602 10:19, 5 December 2009 (UTC)

I want to say that I also prefer the monobook theme, especially the location of the search bar. --76.104.142.246 01:41, 10 December 2009 (UTC)

[edit] Customizable main page

The most visited page on Wikipedia is the main page. It's arranged in boxes including the featured article, In the news, Did you know, On this day, Featured Picture. Why not make this customizable from the user's preferences? Maybe make the user able to change the order of these boxes like on the google user page. An easier solution could be a main page section in the appearance tab in "My preferences" which includes different main page templates, like one which displays the current US Box Office, recent deaths, the watchlist..--Diaa abdelmoneim 06:24, 27 November 2009 (UTC)

Assuming each box has its own ID attribute, you could create a modified CSS file or JS script to hide them. They would technically still be downloaded each time you visit the page; you just wouldn't see them anymore. SharkD  Talk  07:01, 27 November 2009 (UTC)

It's customizable like SharkD pointed out, it's just not easy. However, this is not a major barrier for people to start editing, which is why we're probably not gonna tackle it. --Catrope 22:08, 30 November 2009 (UTC)

[edit] Navigation still horryfing bad

Hi, although I like the prototype better, one thing still is terrible: the navigation. If you take a look as an ip, i.e. not logged in you see: five different navigations (Login, read edit etc, page discussion, navigation and toolbox). These are three too many.

Suggestion: one nav bar above the page containing (Page, discussion, Main page and per max 3-5 more links (from the old navigation). Everything else goes into the left bar: log in first then edit then view history then the toolbox. --134.76.2.131 14:10, 27 November 2009 (UTC)

[edit] no edit images

I beg you not to add a pencil icon for each edit link.129.65.230.246 10:31, 30 November 2009 (UTC)

Why? Can you describe you concerns?--Juxn 14:21, 30 November 2009 (UTC)

I second that. As for the reason... aesthetics/distraction. -- JovanCormac 17:17, 1 December 2009 (UTC)

We got that idea, because new users have a hard time finding the section edit link. Do you have an idea of how to solve that issue? Actually I am not totally happy about that icon, too.--Juxn 21:06, 6 December 2009 (UTC)

[edit] Internal / external link lables

With reference to the problem users were seen to be having with internal/external links, why not provide more explanatory mouseover discriptions? The current "Internal link" and "External link (remember http:// prefix)" are not very helpful. Perhaps it would be better to have them as something like "Link to another article" and "Link to an external website" respectively? -- Anxietycello 05:15, 6 December 2009 (UTC)

We hope to solve this issue with the new insert link dialog. See prototype.Though that's not the final design, since this is still in progress.--Juxn 21:04, 6 December 2009 (UTC)

[edit] A tiny inspiration

This is an interesting screenvideo on a Wikipedia-Design: [12]. Although I like the usability initaitive, this screenvideo could be an inspiration for you. It's a quite clean design. --92.224.216.132 10:43, 9 December 2009 (UTC)

The author of the screen video, Hannes Tank, also known as Juxn is part of the usability team.  :-) --Shuhari 18:25, 10 December 2009 (UTC)

This is a beautiful concept video - I'd love to see that in all it's glory on the live Wikipedia. Lucky that Hannes is already on the team! Witty lama 14:17, 20 December 2009 (UTC)

[edit] What links here: will it ever accept section names?

The content of Wikipedia cannot be managed without What links here. Currently What links here just kicks the section name out.

Q. What links to a section?
A. The tighter organization of a more highly efficient and structured Wikipedia.

If "Wikipedia is forever" it will need a What links here for sections because section names are a structural guidance to both content and links to content —a foundational, systemic structure— but systemic restructuring cannot occur without changing the name, and changing the name cannot occur without What links here.

Meanwhile in order to manage content we have to pass notes, make humanly impossible searches, and patch with anchor templates.

Cpiral 18:45, 12 December 2009 (UTC)
Cpiral 18:25, 18 December 2009 (UTC)
Cpiral 00:20, 9 January 2010 (UTC)

[edit] histoty(NS) and history(discussion) all at once?

Hello! (I haven’t used the Beta; haven’t look through all threads; and I’m not sure my question is for here; - apologizing for all that:) Is it possible to have two separate and permanently visible history tabs – one for the (article) page and one for the talk page? (Maybe it should work only for registered users.) Now, if I’m on a talk page and want to see the reflection of this discussion to the article, I have to go to the article tab first and then to the article’s history tab – which is, sometimes, uncomfortable and slow. --78.128.16.156 22:24, 22 December 2009 (UTC)

[edit] Better citation system

Currently, the book icon only yields <ref>Insert footnote text here</ref> (Can we get the nowiki tag button back, too?). I would like to see a more helpful interface, probably a dialogue box, useful for adding references. A user would input information like URL, author's name, date of publication, and so on and the tool would automatically format a citation template. There is an extension on en.wiki (which the beta disables) called refTools, which I think makes an excellent model and starting point. It is so useful that I have left beta to use it, and would love to see it integrated into the default interface. Thanks! HereToHelp (talk) 17:38, 24 December 2009 (UTC)

that's on our to-do list! ;) --Juxn 09:31, 27 December 2009 (UTC)

[edit] Meaning of message: Prefstats-counters-expensive

I am trying to translate this message on translatewiki.net:

• $1 users have enabled this preference since preference statistics were activated
  • $2 users still have it enabled
  • $3 users have disabled it since
• In total, $4 users have this preference set

Unfortunately, I don't understand the difference between the variables 2 and 4. Could anyone enlighten me? Lloffiwr 17:52, 27 December 2009 (UTC)

[edit] Bug? Display error?

In German Wikipedia we have the Coordinate-Template, that displays coordiantes of locations in the top right corner. This worked without th Beta. But with the new Beta skin this does not work. The Coordinate just shows up where the template is in the source code (so in most articles either at the top of the regular article text or at the bottom of it, under the weblinks).

Same problem with the icons of featured articles. They used to have a small icon in the top right. It's simply not there anymore.

Is this a problem of the new skin or a problem of our templates? I didn't find a good place in our WP to ask this question, so I ask it here. Thanks. --84.183.248.10 12:16, 1 January 2010 (UTC)

This is strange, because it works fine in the English Wikipedia. --Mephiles602 10:35, 3 January 2010 (UTC) Test it to see if it appears in the Monobook skin while the beta is enabled.

[edit] Mismatched cases of letters in russian translation of new Wikipedia and WikiCommons

This is the screen of current "Beta" WikiCommons and Wikipedia interfaces in Russian:

As we can see, some captions are started from capital letters, some are not. Mismatches are higlighted by bold red. In good interface, all higlighted captions should start with capital letter.

I would like to help with correcting this, but where I should login|go and what to do?

Thank you for reporting this! Usually Bugzilla is the best point to report bugs.--Juxn 19:02, 4 January 2010 (UTC)

[edit] Talk pages

LiquidThreads seem to be an easy and good looking way to discuss things. Maybe they could be nice to have in the new beta? --Masz 12:25, 5 January 2010 (UTC)

[edit] "Leave Beta" Link is GONE!

When I first clicked on the button to try the Beta site, there was a "Leave Beta" link at the top of the page that supposedly would take a user back to the current production version. But after looking up a couple of specific topics, the "Leave Beta" link is gone. The links that show now are: [RandySteer (me)] [My talk] [My preferences] [My watchlist] [My contributions] [Log out]. (user: RandySteer, browser: Firefox 3.5.7, date: 5 January 2010)

RandySteer 23:12, 5 January 2010 (UTC)

I tried to reproduce the problem by going through random pages of English Wikipedia, but I can see "Leave Beta" link on top of all pages I reviewed. I use FF3.5 on Ubuntu 9.04. Which project wiki were you browsing? --Shuhari 22:53, 6 January 2010 (UTC)

[edit] Page editor improvements

I would just like to bring up a few bugs and ideas for the editor.

• It would be nice if when we are editing we can temporarily disable the edit toolbar using a GET command, e.g. index.php?title=Some_Page&action=edit&disabletoolbar=yes.
• The word "Advanced" in the improved edit toolbar should actually say "More" as these functions are not very "advanced".
• The heading dropdown should be an image something like the following:

H
---
H1
H2
H3

(etc...)

• Looking at the source of the edit page, the reason the toolbar takes forever to show is because the JavaScript is in the middle of the page. Placing it in the <head>, after the Wikibits and Ajax js will make the toolbar show immediately.

Keep up the good work. Kirbylover4000 02:21, 10 January 2010 (UTC)

[edit] Please alter Collapsible Tabs to hide the tab contents onload. Right now they are completely unusable without javascript

[edit] Reference generator

Like this maybe?

If we could at least provide some sort of basic citation generator, that would be awesome. I know it would take some adapting for the local wikis, but still, its just something Wikipedia runs on. ViperSnake151 15:28, 15 January 2010 (UTC)

If there was something like what you have provided in that mockup graphic that would be so incredibly useful. Please usability team - do that! Witty lama 03:40, 28 January 2010 (UTC)

Citation tool or dialogue is definitely in the usability team's radar after collapsible templates and form-based templates are implemented and released. Great mock-up, ViperSnake151! --Shuhari 04:39, 28 January 2010 (UTC)

[edit] word highlighting copies subsequent space

I believe this is a standard 'feature' of the browser (not a bug) but it does have an annoying consequence for the link dialogue. When you double click on a word with the intention of creating a link with it, the browser for some reason also includes the space following the word too. This means that if you double-click on the word "prototype" whilst editing and then click the "link" icon, the new dialogue pops up and says "page does not exist" because the software is searching for a page called [[prototype_]] not [[prototype]]. This is misleading and annoying, it makes us look like we don't have articles on perfectly normal things. Do you see what I mean?

Is there a way of forcing the browser to only include the word when you double-click, and not the subsequent space too?? Witty lama 04:10, 27 January 2010 (UTC)

[edit] Experimental features - navigable table of contents

I would like to switch this feature on or off additional at the edit page with a button. Because there are only few articles where this feature is a help. --92.192.75.182 11:50, 27 January 2010 (UTC)

I don't agree with you that there are "only" a few articles where this will help - I think it will help in a very large number of cases. However, it is a valid issue. Perhaps, the Navigable ToC could be displayed by default, but if a user chooses to hide it then it is hidden by default from then on? Or, the Navigable ToC only displays when the ToC is longer than 'x' number of subheadings? Witty lama 12:01, 27 January 2010 (UTC)

I have seen that the new prototype that will be released today has already this feature. Well the navigable table of contents is useful if you edit an article as a whole or there are many subtopics and subsubtopics. I don´t think someone will edit an 50+ kb article as a whole but for example the Economy-section in the United States-article with four subsections. With four+ subsections this feature is a help. --92.192.75.182 12:15, 27 January 2010 (UTC)

Maybe this feature will pop in (if it is switched on) on it´s own if there are more than 4 (or what ever number one like) sections at the edit page? --92.192.120.168 01:56, 28 January 2010 (UTC)

[edit] Link Dialogue

I was demonstrating the new interface to a newbie recently - and showed them the new "add link" dialogue box. In my own private (and admittedly not statistically good) UX survey I asked the person to add a link from the article to a different article. Interestingly, they completely misunderstood the texts "target page or URL" and "text to display". Instead, they wrote the article name in the bottom box and the word they wanted to display in the top box.

Can I suggest that the link dialogue box is not yet clear for newbies - especially non-technical ones. I understand that it is a lot better and it is impossible to please everyone. Can I suggest you investigate:

1. reversing the order of the dialogue box so that the "text to display" is on top and "target page" is on the bottom.
2. changing the wording of the dialogue fields, "target page" is pretty meaningless for non-techies. You might want to also add in an example for each to demonstrate what is meant.
3. if someone puts in a full-URL to a wiki page (instead of simply putting in the article name) the software recognise this and automatically (and silently) reformat the text to just the article name.

Witty lama 02:18, 2 February 2010 (UTC)

Interessting, honestly I was unsure about the naming myself. Though I am German - so I leave this naming-issue for the native speakers. I think we will observ the link dialog in the upcoming UX study and this will hopefully bring some clearifying results.--Juxn 15:14, 2 February 2010 (UTC)

[edit] Enable articles as PDF

Wikipedia is great, but the transferability of the knowledge is still rather low. There is an option enabling you to print a Wikipedia page, but for me sitting on a rather awkward network I would like to be able to save the articles I want to read as PDF for printing. I believe many users would appreciate being able to download articles as PDF's and it would increase the value of the knowledge on Wikipedia. However, I understand that it might be an issue about server load, seeing as creating PDFs can be a rather tedious task for a machine.

[edit] Paste issues

While I applaud the WMF usability initiative, can they please give us a feature to paste formatted text as unformatted? It's incredibly frustrating to try to copy from another source into the article text box and find that it's carried over formatting. Certainly this is getting in the way of me clearing the admin backlog on certain areas. - Tbsdy lives 03:04, 5 February 2010 (UTC)

The behavior you observed was not an intended behavior. The carried over formatting is reset once the edit is previewed or saved. Nonetheless, it is a problem that the usability team is currently working on. Bug 22394 Until the problem is resolved, I recommend that you turn off all experimental features from your user preferences under Editing. Our apology for slowing down your work. Btw, what browser and OS do you use? We are observing this issue with Firefox 3/3.5. Shuhari 04:07, 6 February 2010 (UTC)

[edit] Two bugs

I have found two bugs:

1. I just copied text from one article text box to another, and it seems to be adding breaks at every 75 characters or so. However, word wrapping is enabled by default on articles. Why is this so?
2. After I click in the subject/headline, then I press tab, it doesn't take me to the article textbox. This is a big usability issue.

Thanks for all your efforts though. But I rather think that these two issues are going to seriously get in the way of contributions from editors, and for the first bug I have a feeling we are going to see a few mucked up articles and editors running around cleaning up after a problem in the UI. I think we have enough maintenance already to do without sorting these sort of issues out. - Tbsdy lives 03:06, 5 February 2010 (UTC)

Thank you for reporting the issues. The usability tech team is working to resolve the line breaking issue. Bug 22398 Tabbing issue Bug 22311 has been fixed in the code, and hopefully the patch will be released on Monday, February 8th. I will keep you posted. Shuhari 03:53, 6 February 2010 (UTC)

I have found another bug, or is it a feature? If I copy text, for example a H2 headline with big Letters, into the edit page those letters with a formating are seen in the edit page too. The formating disappear after the preview, what is right. But shouldn´t the copy work without the formating? I mean we format letters big or italic not in the usually way. --92.201.209.144 05:38, 6 February 2010 (UTC)

Yes, that's a bug. The problem you described is tracked with Bug 22394

[edit] iframe instead of textarea

I think iframe instead of textarea is a bad idea:

• I (and I guess many other people) don't like to work with WYSIWYG so iframe has nothing to contribute. Rich editing interface may be an alternative interface to the simple editing interface, but shouldn't replace it as it breaks the KISS principle, and as the simple interface is supported by more browsers.
• It breaks many scripts, and make it much harder to write new scripts (to parse the text in iframe?!)
• It cause many bugs and make the editing interface much harder to maintain: undo/redo bugs (e.g: when using toolbar buttons), copy&paste bugs (#Paste issues, #Two bugs). It may also be a security risk, as there are many iframe security bugs in browsers, which can't happen in textarea.

Please return the simple textarea. Unless there are new features (such as WYSIWYG), textarea should be the only option, and if such features exist iframe should be an option in the user preferences (as in the FCKEditor extension. ערן 11:28, 5 February 2010 (UTC)

Allthough the transition to using an HTML IFrame in place of an HTML Textarea will require working out some bugs, it's not true that the textarea "supported by more browsers". In fact, we found very early on that the textarea had it's own share of issues, and since we knew we were eventually going to need something more powerful, we made the transition early to get a head-start on sorting the bugs out and also to stop wasting time trying to fix bugs in the textarea implementation just to throw it out altogether. A good example of the kinds of bugs that we encountered in the HTML Textarea would be that it's impossible to get an accurate scroll position from the cursor position in all browsers. Beyond that, and other similar limitations, we knew we were going to be implementing template collapsing, which would require the placement of stylized and interactive controls, side by side with the plain wiki-text, and in future releases we will likely begin using syntax highlighting to help visually differentiate the markup from the content. All this adds up to an absolute necessity to migrate to an HTML IFrame for the code editor. It's also important to understand that this is not intended to be a WYSIWYG editor, it's a code editor. Finally, you may turn off the new editing features at any time and return to the old editing interface by visiting your user preferences and un-checking options in the Editing/Advanced section. Trevor Parscal 18:02, 5 February 2010 (UTC)

Totally agree with ערן! Our gadgets in be-x-old.wiki don't work. Buttons for quick inserting of tags and characters don't work too. Pasting text from another page is a hard action to manage - it's inserted overformatted. Wikifacator tool (changing - to —, etc.) doesn't work. You even can't fall back this, you say, "Usability". You made a great job, but I have to say at this moment it's crappy. Sorry. Wizardist 12:58, 6 February 2010 (UTC)

As Trevor says above, you can disable the beta features by unchecking experimental features. Please go to Preferences -> Editing -> Experimental Features and uncheck all three features. The issues the usability team is focusing for resolution can be found here. Shuhari 16:33, 6 February 2010 (UTC)

I've seen it. But the beta which is now... it's even not alpha. Previous beta had a very comfortable toolbar with find/replace feature. The last one works fine now and then, but I can't deal with this editbox in Firefox. No one can. Duh... Wizardist 21:52, 6 February 2010 (UTC)

Yo Wizardist - why don't you read WP:CIVIL. Identifying bugs = helpful. Insulting people's work = not helpful. Witty lama 00:42, 7 February 2010 (UTC)

More bugs:

• On the Mac, Cmd+LeftArrow and Cmd+RightArrow serve dual purposes: in textareas they move the caret to the beginning and end of the line (equivalent to the Home and End keys in Windows), while anywhere else they navigate Back and Forward. In Firefox, these keys navigate Back and Forward when editable iframes are focused. (Cmd+Shift+*Arrow still works, fortunately.) I've gotten quite used to the Cmd+*Arrow key bindings, so I've found myself losing work frequently with the new editor. The "unsaved changes" alert helps, but I missed the shortcuts enough to disable the Beta entirely. The bindings work fine in Safari.
• In Firefox, when the edit box is focused, tabbing brings you to the search box instead of the Summary box. Instead you have to hit Shift+Tab twice, which is counter-intuitive. In Safari, there's no way to tab to the Summary box. Tabs are treated literally, which is kind of neat, but definitely something that should be overridden by holding down Shift or Ctrl or something.
• In Firefox, successive line breaks are collapsed, preventing me from starting a new paragraph by skipping a line.

 – Minh Nguyễn (talk, contribs) 06:53, 7 February 2010 (UTC)