Talk:Main Page

From Wikimedia Usability Initiative
Jump to navigation Jump to search

Archives: 1

Usability wishlist for new wikis

(va rog sa scrieti in romana...ca nu inteleg nimic!)


I believe there are some very basic administrative / wiki-creation aspects of usability that should be tackled by this project -- some of the most important changes to usability that could be made from the perspective of new groups adopting MW. A detailed look into interfaces and extensions for already-created wikis might miss this.

Database and new-wiki creation

  1. Ease of adding interwiki links / defining a new wiki in a wiki-set
    For example, there is apparently no interwiki (such as [[usability:foo]]) for this wiki. Part of the creation process for new wikis should ask if a new wiki is part of a family (you are already asked whether you want a database prefix-extension so that multiple wiki tables can be kept in one database) and let you define an interwiki abbreviation.
  2. Ease of adding inteBold textrlanguage links / defining a family of languages for a wiki
    In a similar fashion to the above, one should be able to clone a wiki and make a new one in a different language. One might even want to be able to preserve all creation- and database-preferences from the initial wiki when making the second.

Login and user privileges

  1. Ease of modifying options on the login/account-creation screen
    This should be some sort of site-admin preference.
  2. Ease of generating a set of user powers/tools
    The options for what sets of user groups one wants to create should be similarly easy to set
  3. Definition of 'newbie editor', and restrictions on same
    Spam control is a major preoccupation and overhead cost for wikis. Adding a decent set of default spam extensions is important. So is restricting new editors from higher privileges (page moving, editing semi-protected pages). The definition of 'new' is currently set in LocalSettings, but is a sensible thing to tweak during high-vandalism periods : a good site-admin preference.

Passing changes upstream

  1. How should a local wiki store its changes to site interface strings? How should it pass [some of] these back to the core MediaWiki stringset? The default MediaWiki stringset should certainly be different from the default Wikipedia stringset. Where is it (in all of its languages) kept?
  2. If I have a new extension installed on my system, how can I submit it for addition to the library of MW extensions?
    There should be a simple way, even from within MW's interface, to a) check for updates, and b) submit it for inclusion.

Feel free to add more to the above. Sj 23:36, 11 August 2009 (UTC)[reply]


Localisation

Here is an excerpt from the FAQ :

Are you going to localize these changes in all the languages of Wikipedia and the other projects?
All code will be ready for localisation. (FAQ)


There was a talk on the French Bistro, on January 14th : fr:Wikipédia:Le Bistro/19 janvier 2009#Simplicité, modèles et références about "simplicity, templates and references". The example which was mentioned was the code in this encyclopedic article. Especially parts of the code like <ref name=""""...">""" and {{cite news}} are frowned upon. The latter, which is a template, could be easily translated into French by the French speaking community. But <ref name=""""...">""" cannot be translated into French at present time. In French it should become something like <réf nom="...">. This seems nothing for computer-litterate English-litterate French people/French speaking people, but perhaps we should start thinking about doing something about that if we want to reduce barriers for newcomers.

Usability in other languages

What's with users, who dont speak english? Is the project in several languages? ---Ralf Roletschek 05:18, 23 February 2009 (UTC)[reply]

I think there should be a multilingual suggestion page, where everyone can bring in new ideas and discuss them. --Church of emacs talk 10:14, 23 February 2009 (UTC)[reply]


Editing interface

It is difficult to read the code of a long article especially when the article is well documented or includes an infobox. The creation of an interface based on several windows for different kind of information could help to find the right place to change or to add text. en:user:Magnus developed a nice interface which divides the text into three windows (see en:User:Magnus_Manske/less_edit_clutter.js). The improvement of such a tool can reduce the complexity of an article especially if it is possible to develop a MediaWiki version of the references system of Latex: in the main text only tag will be used and the references will be edited in a specific window perhaps using a form. Then use of colors to detect html or template code can be interesting too. Snipre 22:03, 28 January 2009 (UTC)[reply]

Why not a full-fledged, WYSIWYG word processor?

It's always puzzled me, but why has nobody tried to implement a full-fledged, WYSIWYG word processor as the editing interface for a wiki, and dispense altogether with textual representation?

Of course, it'd have to be augmented with features for link/page creation and management. But that's true of any editing interface.

I realize this is a larger project than any text-based or pseudo-WYSIWYG editor, but why not the best? And, why not adopt some existing, high-quality, web-based word processor to do the job?

The generated output of WYSIWYG editors tends to be difficult to read and full of redundant fluff. Some idiot would use it on a template page and then we'd all be screwed. 87.194.147.203 14:44, 14 June 2009 (UTC)[reply]

What about XML?

You may wish you check out Jorsek.com. They have a web based WYSIWYG xml editor which looks very slick and easy to use. It would allow the constraints that wiki-text provides to keep things consistent while guiding the editing user through the document creation process. Also new elements could be incorporated very easily, like image galleries, and schemas can be used to keep all documents valid. Not to mention its a step in the right direction towards linked data / semantic web.

Google Docs Editor Style

They have a pretty clean style (looks really nice) for their WYSIWYG. have a look here.--Alnokta 17:50, 27 April 2009 (UTC)[reply]


Make the 'edit' button blue, like on the French Wikipedia?

Hello, I would be interested, what are other people's opinions on changing the colour of the edit button at the top of the English Wikipedia so that it is similiar to that of the French Wikipedia? You can see this attrubute on the 'modifier' button at http://fr.wikipedia.org/wiki/Portail:Arts.

The need of colouring the edit-tab shows that the monobook-skin is crowed with too much information and links (sidebar,...). Furthermore it shows that the tabs are very inconspicuous. Also the current vector-skin in my opinion has lacks in making the edit-button more visible for newcomers (mentonied in the german usability studie). I think the grouping of the tabs (page and discussion vs. read, edit and view history) is well done. However, the position of the read, edit and view history buttons is not very well-thought-out. As they are very close to the search field, newcomers could think that those tabs have a connection with the search field (just first impression without reading the text). Moving the mentioned groups closer together leads to the problem that the grouping is not noticeable anymore. So in my opinion the best solution would be moving "read", "edit" and "view history" beneath "page" and "discussion" (like this for example) --Eneas 09:04, 24 July 2009 (UTC)[reply]
I am an active editor on the french Wikipedia, and I observed the impact of the color change of the edit button. I can tell it has changed nearly nothing, and the statistics confirm my thought, as the number of editors and newcomers remain stable. Experience has proven it is useless, so let's trust the usability team's design. 84.226.80.23 23:42, 24 July 2009 (UTC)[reply]
Something like that would be annoying (and per above near useless) --190.93.144.13 01:05, 13 August 2009 (UTC)[reply]

references to look at:

Accessibility

Accessibility as usability metrics

"measurably increase the usability of Wikipedia for new contributors by improving the underlying software on the basis of user behavioral studies, thereby reducing barriers to public participation."

The focus on new contributors surely includes groups that have historically had an especially hard time to contribute... including those with accessibility issues. I hope that part of the usability assessment works with a partner who deals with accessibility who can tell you whether there are obvious areas for improvement (notably for contribution by the motor or visually impaired, since most contributions are currently text).

Simple elements of this, such as providing keyboard shortcuts for basic mouse-only actions and being friendly to screenreaders, are just good web style -- and most of the active wiki designers on Wikipedia already take them into consideration when redesigning Main Page layouts or skins. Sj 05:00, 25 February 2009 (UTC)[reply]

Fix all accessibility bugs

I say simple, just fix all accessibility bugs, [1]. Jidanni 05:53, 8 April 2009 (UTC)[reply]


Concerns

This project worries me a bit. I've seen many, many cases where software that was once built very well became unbearably unusable due to what they call software "enhancements". This is usually because at some point, the software became well-known enough to make some money, or in this case, a donation.

Also, it isn't specificed how user testing will be done. but if we're talking computer-generated tracking and analysis, please note that user input should come first. Just look how well built English Wikipedia's infrastructure of templates is built, that was all made by going hand in hand with user suggestions.

I direct this message at all participants of this project to ask two things:

  • Always leave users the option to disable any enhancements through their personal user prefrences. Even when you're absolutely sure no user can benefit of how a feature worked before you improved it, there will be some that will oppose the update greatly.
  • Take it slow, don't rush improvements for the sake of enhancement, sometimes simplicity and logic overpower the latest study or user testing.

Thank you. You're welcome to drop me a line on my talk, I'm willing to volunteer as an overseer of this project. --Bitbit 03:00, 7 March 2009 (UTC)[reply]

I share many of your concerns. I love the philosophy of a website called http://www.oldversion.com/ : their motto is "Because newer is not always better". Teofilo 13:40, 18 April 2009 (UTC)[reply]
I second User:Bitbit's concerns. Please leave users the option to disable any enhancements and don't rush improvements for the sake of enhancement. — AjaxSmack 00:05, 13 August 2009 (UTC)[reply]

Confused a bit

Hey guys. How am I supposed to "participate" in the extension survey? When I'm logged out I see rating stars, when I log in they go away. Any pointers? Also should Wikipedia Usability Initiave:Copyrights be created since it's on the bottom of every page? Maybe something similar to Wikispecies:Copyrights. Thanks, Stepshep 19:35, 7 March 2009 (UTC)[reply]

TADA! It doesn't work with Vista/IE7, I'll have to test it later on Win7/IE8 and see if that makes a difference. For now Firefox does the trick, but I hate it's security. Stepshep 20:54, 10 March 2009 (UTC)[reply]
This has been fixed. Trevor Parscal 20:15, 18 March 2009 (UTC)[reply]

There is no "Stanton Foundation"

For someone to edit with the correct info, it should be the Ruth And Frank Stanton Fund. -- Thekohser 19:39, 23 April 2009 (UTC)[reply]

How not to do usability...

The "participate" box has blue text with indistinguishable blue links. Pretty hard to see!

Seriously though, great project, wish there was more info about how people can get involved. Stevage 04:36, 1 July 2009 (UTC)[reply]

We just added the page Your Opinion where we'll place a couple of questions.--Juxn 08:01, 10 July 2009 (UTC)[reply]

"non editors" [sic]

Has the concept of prefixes ceased to be taught? This page refers to "non editors", with no hyphen. I've seen this usage several times on Wikipedia. Where's it coming from? Michael Hardy 15:46, 7 August 2009 (UTC)[reply]

The hyphen is becoming less common in written English. Prefixes are less common than adjectives in this language, so speakers tend to treat 'non' as an adjective. You can also notice this trend in the stress patterns of spoken English. http://en.wikipedia.org/wiki/Hyphen#Customs_of_usage_in_English 74.67.189.162 22:28, 17 September 2009 (UTC)[reply]

SUL on this wiki

Please add SUL for usability-wiki for easy voting! --86.33.201.60 10:54, 22 February 2009 (UTC)[reply]

Because we are running this site from a different network as our other projects SUL is not yet available. This may change in the future and account unification will be able to take place. Trevor Parscal 17:31, 2 March 2009 (UTC)[reply]
I disagree with SUL, which has many drawbacks. Thank you for allowing at least this place to be a SUL-free place, this makes it a friendly place. Users should be free to choose if they want to have a local or global account. Requiring all new accounts to be global is not a good decision, I'm afraid. Teofilo 13:47, 18 April 2009 (UTC)[reply]

Wikipedia user names do not work!

I cannot login, and I am pretty sure that I used the right names. Is this a mediawiki foundation site at all?

Although this project IS an official Wikimedia project, we're hosting this project off-site at the moment, which prevents the use of SUL. We are looking to resolve this issue in the near future, but encourage you to create an account here so you can later link them. Trevor Parscal 16:18, 20 April 2009 (UTC)[reply]
Is this solved yet? Sj 00:03, 6 June 2010 (UTC)[reply]
Yes, but you have to login/logout locally. --Nemo 09:25, 6 June 2010 (UTC)[reply]
See bugzilla:14407. --Nemo 21:46, 8 June 2010 (UTC)[reply]

Extensions!

Is there a usability phase dealing with extensions?

Hi, there should also be a phase 3 dealing with all kinds of extensions. Enlarging the number of "core" extensions by extensions not only used on WikimediaProjects would clearly further increase the market position of MediaWiki. Some of these non core extensions would make a great deal and increase usability like for example WikiCategoryTagCloud Sadly they are mostly more or less in an advanced development- or beta-phase at best. Cheers --Marbot 12:30, 5 July 2009 (UTC) Arc[reply]

No wiki markup on Macedonian version of Beta interface

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

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

Can anyone help? --222.152.100.234 03:34, 21 August 2009 (UTC)[reply]

Sorry for not responding sooner. Special characters are incorporated in the toolbar, and wiki mark-up is available in help menu in the toolbar. The drop down menu for special characters below the edit box can be restored by an admin. Hope this helps. Shuhari 21:52, 11 October 2009 (UTC)[reply]

This project has a limited scope which corresponds to our grant

This is a really bad approach. Wikimedia needed an usability project long before some grant was given. Why to restraint the use of this new wiki to this GRANT only??? Makes no sence at all. This can be a nice community usability initiative for all Wikimedia projects. And as one of many projects it can contain "The big grant" usablity project for big bucks.

Why dont you let the community usablity for other wikis go alongside? It would do much more good than all the $$$s.--Kozuch 20:06, 25 August 2009 (UTC)[reply]

Use a WYSIWYG EDITOR!

Seriously, how hard would it be. 82.36.252.142 03:03, 27 August 2009 (UTC)[reply]

Things to fix in this page

  • "Involved" is misspelled in the last title: "Getting Invovled".

hopiakuta DonFphrnqTaub Persina 19:10, 5 September 2009 (UTC)[reply]


Are the terms disability-access-barrier, disability-access-community, element to this project? Please do justify your response @: wikipedia : user : hopiakuta.

hopiakuta DonFphrnqTaub Persina 19:10, 5 September 2009 (UTC)[reply]

Localisation of feedback form

The intro to the feedback form does not at present say which language any respondent should use to write their responses. All the messages making up the feedback form are included for translation. But if the questions are all translated then you can expect narrative answers to be provided in the language of the question. Are you translating any non-English replies at all? Are you binning any non-English replies? If you can only cope with narrative replies in English then we should add a note to that effect to the intro message. If feedback is being received in other languages then could you let the translators at translatewiki.net know which are OK to use? With best wishes. Lloffiwr 17:58, 20 September 2009 (UTC)[reply]

Thank you for your patience in waiting for a response. We are receiving feedback in local languages and we plan to reach out to the translation community for help in translation once the data is organized and ready for translation. --Shuhari 02:43, 30 September 2009 (UTC)[reply]
Thank you for the information. I await developments (presumably over on Meta-wiki?). Lloffiwr 12:26, 2 October 2009 (UTC)[reply]
We consulted the possibility of using translatewiki.net to translate the survey, but as the nature of the translation is quite different, our case requires multiple languages to be translated into English, while usually the translation is done from English to multiple languages, we are likely to use meta or usability wiki for the translation. --Shuhari 21:55, 11 October 2009 (UTC)[reply]

What are you doing with the grant?

First things first: I have been using the beta on Commons for quite a while now and I find it to be a clear improvement. I really like the new design, and the toolbar shows careful attention to detail.

...but...

Unless I misunderstood this page, you have been given close to a million dollars for usability improvements! Enough to employ 10-15 highly skilled software developers in the U.S. (or 100 equally skilled ones in a country like India) for a whole year, providing at least 15.000 man-hours!

As good as the interface improvements are, I simply cannot believe that they have cost more than 10% of that, even with all the (modest) future features still planned (full-screen editing and collapsible messages). Basically, the project seems to consist of conducting a few surveys, creating an (admittedly very good) script editor, and a few CSS changes. A statistician, a developer and a designer could do that together in six months, with time to spare. There is no way in hell this costs $890.000 U.S.

I really hope more is coming, for as much as I like the present (and planned) changes, I must say that if they really cost you 900K you got ripped off, big time. -- 77.1.58.28 07:55, 5 October 2009 (UTC)[reply]

The question that pops here up is if it were not better to use closed source software. I think trying to stick with open source software (because of some higher, philosophical or ideological reasons???) is very resource-hungry solution. Why to continue developing the dinosaurus MediaWiki in PHP and not for example Ruby on Rails from scratch??? Wikimedia has a mission of providing free knowledge, the mission does not say how do we achieve that, am I right?--Kozuch 11:12, 11 October 2009 (UTC)[reply]
To 77.1.58.28: Thank you for your comment. The current beta only reflects what we have released as Acai release. NTOC and dialogues for links and tables are released as user preferences in Babaco release on September 30th. The team is starting the design/planning process of Citron, which is comprised of forms for templates, syntax highlighting, and possibly side-by-side preview. What slows us down is to make sure the new featuers are compatible with supported browsers in over 260 languages. Please see the compatibility matrix for Acai and Babaco. As stated in my blog, we are trying to surface the language specific issues where the beta retention rate is lower than average. Shuhari 21:33, 11 October 2009 (UTC)[reply]
To 77.1.58.28: That is only considering quantity. But usability is not quantity, it is rather efficiency. Plus, it is impossible to change the whole interface all of a sudden. On a website that big, users are accustomed with the current design. If you change it completely and suddently, users will totally dislikte it, and leave.
The Usability Initiative is doing it the right way. They are improving the interface without disturbing the users as much as possible. They are doing a lot of user testing, to ensure that what they are doing is efficient. They are gathering feedback, and involving the community, to make sure that they are not disturbing the users. Doing it that way takes a lot of time. :-) 84.226.105.208 22:13, 11 October 2009 (UTC)[reply]

I simply couldn't find upload tool

Am I blind?

Here it is: http://usability.wikimedia.org/wiki/Special:Upload --Kozuch 18:24, 26 October 2009 (UTC)[reply]

Tour of wikipedia

I know several expert people who do not edit wikipedia because they do not know how to. They press edit and there is a lot of computer code, which is found scary so run away. I think it would be very useful having a nice notice (like the fund-raisers and now there is a survey ones at the top) saying "Ever found information missing in Wikipedia and wanted to modify or improve the article but did not know how? If so, follow this easy step by step guide showing many the hidden tricks! Many of which can help you look for information hidden in the site" and linking to a specifically made page Briefly explaining what are discussion pages, help desk, wiki projects and the basics of editing (such as [[something]] makes an internal link, while {{something}} is a template etc). --Squidonius 15:38, 29 October 2009 (UTC)[reply]

We are considering dialogs to help new users. (Maybe some kind of new-article-wizard?). But this is not high priority.--Juxn 10:02, 6 December 2009 (UTC)[reply]

Please rename this project

It is a bad idea to name a wiki after a specific grant. This should be "Wikimedia usability initiative" and not "Wikipedia usability initiative". Recently, this wiki became a home for Multimedia Usability Project (Multimedia:About), which deals with Wikimedia Commons. Current name of the project is really misleading.--Kozuch 07:46, 30 October 2009 (UTC)[reply]

Yes, I was waiting for the Multimedia usability project to really start before renaming, but now it makes sense. guillom 10:06, 30 October 2009 (UTC)[reply]
Ok, hopefully we see the result soon.--Kozuch 09:58, 5 November 2009 (UTC)[reply]
Thanks for the logo change. However, the site title (browser page title) says Wikipedia still.--Kozuch 09:24, 11 December 2009 (UTC)[reply]

Please unlock the Main page

Can someone ulonck this page? I think it is very uncollaborative to prevent someone from editin... In case you are affraid of spam and vandalism, you can lock it so that only registered users can edit it. Thank you. PS. Strategy wiki went the same path - the Main page was locked first, but than Philippe decided it is better to only lock it to registered - since that time it definitelly looks better thanks to efforts of other users.--Kozuch 08:03, 30 October 2009 (UTC)[reply]

The usability wiki is mainly a work wiki for the usability teams, whereas the strategy wiki is mainly a sharing platform acting as a link between the strategy team and the Wikimedia community. guillom 10:06, 30 October 2009 (UTC)[reply]
You are just repelling people willing to help... I really dont understand this.--Kozuch 10:00, 5 November 2009 (UTC)[reply]
You do realize that you can redesign the main page on a subpage, right? That way you can work on it in peace and we can swap it in if we like it. --Catrope 14:13, 7 December 2009 (UTC)[reply]
The main page is semi-protected as of December 7, 2009. --Shuhari 03:52, 8 December 2009 (UTC)[reply]
Thanks, hopefully we will be able to make it more up-to-date from now.--Kozuch 22:55, 10 December 2009 (UTC)[reply]

Interwiki links

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, on the page of the village pump discussion I posted a picture to propose how this could be avoided. Although it requires coding by wikimedia staff and may work only in certain skins. If this may interest you, please see it here --Squidonius 14:31, 5 November 2009 (UTC)[reply]

Demo sample for SciRefs script can be found here

I've made a new script instead of tags <ref> in "scientific" style (but compatible with it and any other markup). It makes refs easier to read and easier to use. Description is here. X-romix 17:12, 6 November 2009 (UTC)[reply]

Good work! I like it and I am sure this helps readability of references - though I am not sure if it has a negetive impact on the text readability. (Because the the longer supertext might be disturbing for people who just like to read the article). We will definetly consider and discuss your idea.--Juxn 09:59, 6 December 2009 (UTC)[reply]

I'v made an MediaWiki extension (see section below) that can switch labels off (hide it or use a star character to shorter labels). By theory it can be tuned in user preferences. X-romix 11:50, 30 April 2010 (UTC)[reply]

Question

Why don't you move completely to a WYSIWYG editor?

This is already under discussion. --Mephiles602 10:19, 6 December 2009 (UTC)[reply]

Addition of Template:Backstage projects

May I ask someone to add Template:Backstage projects to the bottom of Main page? Thanks!--Kozuch 17:24, 27 November 2009 (UTC)[reply]

The main page is unlocked now. So feel free to add the template of sister projects. I personally do not like the name "Backstage projects" though. They all have great potential although they are not getting as high traffic as Wikipedia. --Shuhari 03:50, 8 December 2009 (UTC)[reply]

What are you doing?

I just looked at the last few comments, but you guys are not doing well with the collaborative wiki way. You desperately need a page that's transcluded both ways with en.wikipedia. Or, you've decided that involving the community will hinder the process. If that's the case, you may be right, in which case just go for it. But, if you want to involve the volunteers, you couldn't do it much worse. - Peregrine Fisher 05:12, 29 November 2009 (UTC)[reply]

I don't expect any sort of reply, based on other people not getting any reply, but if you do, do it at my wikipedia user page, since this is no mans land. - Peregrine Fisher 05:13, 29 November 2009 (UTC)[reply]

This wiki just sucks, that is correct. I will try to reach some admins or other poeple in charge to do something about it...--Kozuch 13:53, 5 December 2009 (UTC)[reply]

We really try to answer most questions. But please try to see it from our perspective: We are pretty busy designing and developing stuff, that's why it is hard to answer everything. Especially questions that already have been answerd long time ago. (Why not WYSIWYG for example). But anyway,.. I'll try to be more present in this wiki and I am sure the others will do what they can as well.--Juxn 09:54, 6 December 2009 (UTC)[reply]

Well I for one would like to point out that you all are doing a brilliant job. --Mephiles602 10:18, 6 December 2009 (UTC)[reply]
We are certainly trying ;) --Parul Vora 23:27, 15 December 2009 (UTC)[reply]

Forgive my naivte'

I want to try Beta but I want to be sure that I can switch back in the event I have problems. Is there an "undo" button? Thanks Tide rolls 17:48, 20 December 2009 (UTC)[reply]

Nevermind. I found the "try/leave beta" reference. Apologies...I should have been more diligent in my original search. Regards Tide rolls 17:52, 20 December 2009 (UTC)[reply]

nice

http://www.hannestank.de/wikipedia/video_2/screenvideo_with_comments.html

Where can I read / ask questions about / participate in "Vector appearance" aka "BETA"?

I want to change and many things in it. I have never seen a page about this "Vector appearance" aka "BETA". I do not know its official name. Maybe I want to participate. Do you know an official URL of all this project? q/0/k 12:40, 30 December 2009 (UTC)[reply]

We track features by releases. Acai and Babaco are currently offered under the beta program. You can either leave your comments in the discussion page of each release or start the discussion thread at the Beta Feedback Survey page. --Shuhari 02:56, 7 January 2010 (UTC)[reply]

Watchlist

I'm probably just missing the blindingly obvious, but where did the watch/unwatch links go? I used to be able to watch/unwatch a page just by clicking a link as I was viewing the article. Since trying the Beta, I cannot find the way to do this without having to go to the page for editing the watchlist... if the links really aren't there, may I suggest adding them? They greatly enhance usability, at least for me. Thanks! 72.196.216.10 01:10, 12 January 2010 (UTC)[reply]

And of course I find it right after posting this. I have to say, a five-pointed star doesn't scream out "watchlist" to me...oh well :) 72.196.216.10 01:13, 12 January 2010 (UTC)[reply]
Glad to hear your found it. Only sorry to hear that it was obvious and took 5 minutes! Parul Vora 22:17, 8 February 2010 (UTC)[reply]

Screwed up editing

Read this. Apparently this page also has the annoying rich text thing. - 74.32.172.4 01:41, 6 February 2010 (UTC)[reply]

We, the usability team, is working on the fixes right now. We'll post the update shortly. Shuhari 02:14, 6 February 2010 (UTC)[reply]

Web Slices

I'd like to suggest that more "web slices" be offered. There is a related discussion at w:Wikipedia:Village_pump_(technical)#Webslices_for_the_main_page.Smallman12q 14:55, 6 February 2010 (UTC)[reply]
Thanks for your suggestions! Parul Vora 22:15, 8 February 2010 (UTC)[reply]

Wasting Time

I don't know how much time I waste because there aren't separate tabs for:

  • Edit this page (article)
  • Edit this page (discussion)
  • History (article)
  • History (discussion)

I have a really slow connection, and this drives people away. And this applies for templates. There should be 6 short cuts, not just those 3 view, edit, discussion letters.

You can't make a new section tab for articles, cause which headline would you use?

In view source pages, the new section tab doesn't even have to appear, since it would be impossible to add ANYTHING anyway.

I can't understand why there are a "million" blue links on the left, and 6 simple tabs can't be put into the web pages.174.3.98.236 23:52, 8 February 2010 (UTC)[reply]

I know that the usability team did a lot of work in the first iteration of their changes on the look/feel of the tabs at the top. The current layout has been arrived at carefully. However, I too had the same issue (wanting to display the tabs for both the article and the discussion page and talkpage at the same time). There is/was a script for that [2] although I must admit I can't find it right now... Witty lama 09:25, 9 February 2010 (UTC)[reply]
Scripts are only available for registered users. There is wide consensus in the community that this is what we need. The layout here is a good start.174.3.98.236 23:30, 9 February 2010 (UTC)[reply]
The builds are on beta. Before going live, fix this problem that wikipedia had at the very start. When I first started editing, we had no "new section" tab. Then it appeared. This change will not rock the boat.174.3.98.236 01:09, 11 February 2010 (UTC)[reply]
I don't understand. There have been HUGE changes to the edit page. All the functions have incorporated a ribbon format. Why haven't the tabs turned to 6, or 7? We have 6 tabs in discussion pages, but it's even more confusing then having just 7 SEPARATE tabs. Having 6 or 7 separate tabs will harmonize with the ribbon design.174.3.98.236 01:13, 11 February 2010 (UTC)[reply]
I'm not sure why you double posted but anyway for anyone not aware the other post has some discussion from someone more involved in the iniative Talk:Prototype#Wasting Time Nil Einne 23:07, 14 May 2010 (UTC)[reply]

Suggestion from Pump: "Move" -> "Rename"

See w:en:Wikipedia:Village_pump_(proposals)#Rename_the_move_function_to..._rename --Cybercobra 01:20, 14 March 2010 (UTC)[reply]

Hello, I'm impressed by all the improvement the usability team has achieved, I had a question though, are there plans to make inserting references easier? For example did u study the citation tool where the user enters the url title author and publication date? making inserting a reference much easier and without the need to look at the wikisyntax?--Diaa abdelmoneim 11:40, 26 March 2010 (UTC)[reply]

RefToolbar

Why can't I use en:Wikipedia:RefToolbar on Beta? Am I missing something? The whole thing is practically worthless if basic gadgets don't work. 128.232.247.170 06:03, 5 April 2010 (UTC)[reply]

Take a look at RefToolbar 2.0 at http://en.wikipedia.org/wiki/User:Mr.Z-man/refToolbar_2.0. Mahanga 04:53, 7 April 2010 (UTC)[reply]

Make reftools 2.0 default

The reftools 2.0 gadget is a major usability enhancement over the normal reference button. Could the gadget be integrated instead of the reference button? Clicking on it would behave in the same way as clicking cite. Users usualy don't know how to put references and the reftools gadget improves that to a great extent....--Diaa abdelmoneim 09:59, 16 April 2010 (UTC)[reply]

Seconded. 129.120.94.122 18:48, 26 April 2010 (UTC)[reply]

I'v made an extension to support Harvard-style references (alternative to Cite.php)

Example of Harvard references support.

Extension:HarvardReferences supports Harvard-style references, e.g. Smith 2008:1. It compatible with Cite.php and can be used jointly. Harvard references is more traditional for scientific literature. Jimbo strongly supports this proposal. :-)

  • Link - in square brackets:
    [Smith 2008]
  • Anchor to link -
    [*Smith 2008]

--X-romix 11:44, 30 April 2010 (UTC)[reply]

Main Page improvement

To make the main page, y'know, more clean-cut it might be better to use [[irc:#wikipedia-usability|#wikipedia-usability]] rather than an entire barebone link there. Killiondude 16:54, 13 May 2010 (UTC)[reply]

Discussion on the design and rendering of the new logo is taking place here in Commons. Please direct your comments and feedback there. --Shuhari 20:30, 14 May 2010 (UTC)[reply]

Font size/text size

I haven't see a rationale anywhere for reducing the text size. What gives with that? People have pointed out on http://blog.wikimedia.org/2010/05/13/a-new-look-for-wikipedia/ that the new size is non-standard and too small. Is there some usability study that came to the conclusion that tiny text is more usable than normal sized text? There wasn't anything I could see on the usability study page that people have loved to link to as evidence that all these changes should have been made.

This new look and feel is a disaster

I really resent the fact that I have to sign in just to be able to turn off this obnoxious new skin. Apart from reducing ease of use (more clicks required, search box in the wrong place, etc) it's ugly and uncomfortable to read. And the tabs just make the pages look like they aren't fully rendered. I don't know if anyone offers awards for "most unusable usability effort" but you folks should be contenders. People get paid for this kind of thing? Nice work if you can get it. 72.229.55.107 01:45, 20 May 2010 (UTC)[reply]

Autonumbering across table columns

Is this the right place to ask for a coding enhancement...?

When I have a numbered list which is getting too long, I may wish to split it up into table columns:

  1. Alpha
  2. Bravo
  3. Charley
  4. Delta
  5. ...

In a 6-column table, this becomes:

  1. Alpha
  2. Bravo
  3. Charley
  4. Delta
  5. Echo
  1. Foxtrot
  2. Golf
  3. Hotel
  4. India
  5. Juliett
  1. Kilo
  2. Lima
  3. Mike
  4. November
  5. Oscar
  1. Papa
  2. Quebec
  3. Romeo
  4. Sierra
  5. Tango
  1. Uniform
  2. Victor
  3. Whiskey
  4. X-ray
  5. Yankee
  1. Zulu

This way, the numbering restarts in each column, which is obviously not intended.

A brief look at the HTML code generated shows that the <ol> and </ol> tags are placed within each table cell, which explains this behaviour.

If I may suggest a solution, a simple one would be to define a new tag pair, say, <longlist> and </longlist>. When these are placed before and after the entire table, then the <ol> and </ol> would still be placed within each cell, but the opening one would be automatically modified into <ol start = "n">, where n is the correct starting number (= the number of items counted so far, plus one).

If this does not work for any reason dictated by HTML, another solution might be to have the Wiki interpreter do the actual item counting and produce a <ul> - </ul> list within each table cell with the numbering insterted by the Wiki interpreter.

213.233.248.4 08:14, 2 June 2010 (UTC) (Sorry, I wasn't logged in. HHahn 08:16, 2 June 2010 (UTC))[reply]

Right place to suggest TeX improvements?

Is this the right place to submit proposals for improvements in TeX? I have written something in Dutch, and I am willing to translate it to English, but not to just dump it at a place where nobody will do anything with it.

The actual subject is how to control the background colour (including the "transparent" colour value) of the PNG file generated. As it is now, any background colour specification is just ignored. I have made soem examples, but where can I submit them?

HHahn 15:22, 4 June 2010 (UTC)[reply]

why is increasing the font size so elusive? Could someone just give me a clue?

Don't hide "Move"

In my experience, when novice users want to rename a page, they click the "Edit" tab, look around, and wonder why there's no way to change the title. The #1 FAQ in our wiki, for years, is how to rename an article, so I was surprised to see the Move command has been hidden from view in the Vector skin. Please reconsider. 4.79.245.132 14:11, 10 August 2010 (UTC) pula mea e mare...SA MIO SUGI[reply]

brilliant interface: Open Buildings

http://www.openbuildings.com/buildings/la-llotja-de-lleida-profile-362.html

Most of what Open Buildings has done is worth learning from. From their prominent Edit tab and clean placement of information to their structured data display to their simple flow of signing in when you try something that requires it...

How can we get rid of the new surface?

Hi I am one of the bureaucrats at sw:wikipedia. One of these days a new surface appeared and I guess that comes from this project. I am personnally not too fond of it but found out that I can choose a surface similar to the old one (although not the same!). Now I discover a problem that the tutorials we have all refer to the "old buttons". But new users start automatically in the changed surface. I do not think it was ok to push these changes on everybody and also on us without consultation. For us it means that we have to rework all tutorials and check where we have to make changes in explanations. As many of our Swahili users are not too computer savy it is a problem when tutorial says "search window on the left" and now it is different. ETc. We have too few active people and too much work to start unnecessary jobs because of well meant but for our situation not thought-through actions which are being forced on us. So who is the one who switch that feature off for our wikipedia? Kindly react to my talk page at sw-wikipedia User:Kipala on Kiswahili-wikipedia

Thanks for your message. I tried leaving a message on your talk page, but it was locked from editing. Sorry to hear about the issues you've been having with the new skin (Vector). We did our best to notify the community by running a Central Notice and posting on various blogs. What issues (other than the location of the search box) are problems for your tutorials? And are there any other issues with Vector on your project? Howief 20:16, 17 September 2010 (UTC)[reply]
Thanks for your reaction. Sorry for my protected page which I did not open again after some past spammer attack. Ok the problem is that our help pages have
b)explanations for locations of buttons, search windows etc. (third from right...)
b) images of icons that should be used (e.g. Overview "How to start an new article")
c) and also sep-by-step explanations based on the previous arrangement.
Is there really no way of letting new users start with the old (mono?) and open the chance to move to the new shell?
The enhanced problem is at the moment that we are usually a quiet wikipedia with few editors but now google is running one of these Jimmy-Wales-related pep-up-small-Wikis initiatives whereby medical people participated in workshops to translate health related articles to sw. They can forget our help pages.
And I see also that as user on de.wikipedia I can choose to retain the old face but on sw.wikipedia I cannot get that is just a mix of old and new. User:Kipala on sw.wikipedia.


Wikipedia:User experience feedback

Are you guys still monitoring w:Wikipedia:User experience feedback? Along with the occasional on-topic comments and inquiries, it seems to be an unpatrolled magnet for spam and non-germane personal expression. ~ Ningauble 15:36, 18 September 2010 (UTC)[reply]

prototypes

just to let you know all the prototypes like here are broken right now 198.169.16.48 16:54, 4 November 2010 (UTC)[reply]

Improvement suggestion for "What links here"

Recently I had to change an article's title. The original title became a disambiguation page, and the article itself got a modified name. So I used the "What links here" page to find out all link references to the old name (i.e., now the disambiguation page).

Frome these actions, a suggestion arose on two possible improvements on the What links here page. As these two improvements are related to eacht other, I describe them here in one topic.

1. Adding a selection option Show/hide references in templates

Currectly, there are three selection links, viz. Show/hide transclusions, Show/hide links and Show/hide redirects. What I am missing here, is another selection, Show/hide references in tempates.

Navigation and other templates containing many links to related articles are often used at the bottom of a page, and/or in a sidebar. Several of these links may of course also be referred to in the articles themselves. By showing the references in templates and hiding all other references, one may quickly find the referencees in templates and modify them first. A refresh of the What links here page will in many cases now show a much shorter list of references. As a practical implementation, this will probably reduce to showing or hiding all references in the Template: namespace.

There may be external tools to do this, but it would be much simpler if an extra selection criterion were available here.

I have checked whether I might have misunderstood how you use the term "transclusion". But as far as I understand, this only refers to those references where the current page is being transcluded into another page, or in other words, the current page is being used elsewhere as a kind of a template. What I am referring to, however, is the reverse situation, i.e., references to the current page from within templates.

2. Changing the selection links to checkboxes and one activation link or button

If one wants to only show one of the three (or four) categories, one has to click and wait for the page refreshing twice (or three times). At times when the internet is slow, this may take relatively much time. If instead one could just select the checkboxes of the categories wanted, only one page refresh would suffice, which is much faster.

HHahn 13:17, 16 December 2010 (UTC)[reply]

--- Moved reaction to the end. HHahn 16:36, 16 December 2010 (UTC) ---[reply]
On the Recent changes page is option invert selection. Could be possible to add an option invert selection for hiding templates and other namespaces on the "What links here" page and other special pages (new articles)? Showing references in templates is possible. Przykuta 16:14, 16 December 2010 (UTC)[reply]
--- End of move ---
As far as I understand, "Recent changes" is quite a different thing than "What links here". "What links here" should show links independent of how "old" they are. "Recent changes" will, as I see it, not only show changed links, but any (recent) change. Or am I wrong?
Or do you only suggest it as an example of how to solve my question? It might be an option, but being able to set/unset any single condition, seems much more flexible.
HHahn 16:36, 16 December 2010 (UTC)[reply]
I think only about invert selection used on the RC. Do you use namespace box on the "What links here"? Przykuta 17:07, 16 December 2010 (UTC)[reply]
EXACTLY! THAT'S IT!. I never even noticed that box! It pefectly solves what I need! Thank you very much! HHahn 10:06, 17 December 2010 (UTC)[reply]
no problem ;) Przykuta 15:14, 17 December 2010 (UTC)[reply]