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 discuss the current icons, go here. To talk about the current toolbar, go here.
	You can find the current list of open bugs for our project on bugzilla here.

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

[edit] Alignment in galleries

Here is an example:

some text some text some text

some text some text some text some text some text some text

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)

[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

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

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

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

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

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

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

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

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

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

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