Wikipedia:Phase II feature requests
This is a list of feature requests for the Wikipedia system.
Improved Search
Could the search list be ranked either based on traffic or like Google by the number of pages linked to it, so that the most popular pages come up first. This would prevent some of the wading through a large list of obscure pages and redirects which are less popular?
When you get a search result could we add an option to do a Google search on the subject? (I found this useful in the old software)
Also when the search results come up any wiki links in the example text which have a searched phrase do not work because the html bold tags are added into the link - so far I haven't seen many accidentally formed pages with the bold tags built in, but this should be fixed. It might be on the bugs page already.
I know I have seen a request for advanced search capabilities somewhwere, but I will restate that request here for compactness. Trelvis
I would like to have redirected articles and "Complete list of Encyclopedia topics" pages omitted from search results. AxelBoldt
- I agree that it shouldn't search the body of a #REDIRECT, but it should still search the title; otherwise, the failed searches page become unnecessarily longer when users type in a misspelled word for which there is a redirect but which is not used in any regular article.
Looking at mis-spelled search requests for 'Circumsision', 'Circumsicion', 'Circumsission' and 'Lamberghini', we should probably use something like Soundex or Metaphone to search for a sound-alike article if a literal search fails. Note that recent versions of PHP have a metaphone() function built in.
See http://www.zend.com/manual/function.metaphone.php for more details.
-- The Anome
To improve performance on special pages:
Most wanted is currently manually refreshable, and it displays the 50 most wanted items. Why not have it schedule an automatic refresh when there are ten or more wanted pages that have been filled when a user pulls the page? If that's not feasible, why not have the pages simply refresh periodically? (Or do you already do that?) --Damian Yerrick
- This would be helpful. The top 50 most wanted are a great things-to-do list. Refresh doesn't do anything useful; it just gives a ridiculous number of minutes that I should wait before refreshing again. Of the 50 items on the list at this time 36 appear as done, and only 14 remain undone (mostly in areas that I don't feel ready to tackle.)--Eclecticology
- Apparently, the "can't refresh till June" bug (yes, I'm enough of a t00l to have calculated how long 160,000 minutes is) has been fixed, but I don't know if Most wanted is automatically refreshed.
- special:WantedPages has been made more efficient so it now updates live every time you load it. Fun, huh? Brion VIBBER
- Apparently, the "can't refresh till June" bug (yes, I'm enough of a t00l to have calculated how long 160,000 minutes is) has been fixed, but I don't know if Most wanted is automatically refreshed.
I'd like a way to list all pages in a namespace. For example, http://www.wikipedia/wiki/wikipedia%3A should list all pages in the Wikipedia namespace that the current user can access, and http://www.wikipedia/wiki/special%3A should do the same as special:Special pages. --Damian Yerrick
From the New Features page:
- Talk namespaces All namespaces have their own Talk namespace ("Talk", "Wikipedia Talk", "User Talk"), to use instead of a /Talk page. Listed at the bottom of every page, empty Talk pages are red, existing ones are green.
I'd like to suggest that these links should have the same presentation as in-article links: that is to say [talk:My Article]? if not present, and talk:My Article if present. This enforces the same semantics and appearance for these articles as for the rest of the system, making the user interface simpler and more intuitive: there's one less thing to learn. -- The Anome
To get favicons working in a standards-compliant way in Wikipedia:
add <link rel="SHORTCUT ICON" href="http://www.wikipedia.com/favicon.ico"> to the head element in all generated pages. This will tell the browser to fetch the icon at the named URL. At the moment, some browsers default to fetching favicon.ico from the site, but this will
- tell all compliant browsers to do this
- gives you the option of having different icons on different pages, should you want to
- There is no http://www.wikipedia.com/favicon.ico. Should there be? --Brion VIBBER 2002/02/05 11:48 PST
- Shouldn't the icon be a PNG instead of an ICO? Unlike ICO, which is a Microsoft proprietary format, PNG is a W3C standard. --Damian Yerrick
In an ideal world, yes. If we want to look nice and be more user-friendly, we have to live with the fact that most users will be using IE. We should not bash Microsoft if it affects our users adversely. Fortunately, leading open-source browsers (Mozilla) support the .ico format for this purpose. A bit of open-source browser evangelism targeted at IE users would be good, though - I am an enthusiastic Mozilla beta-tester, and 1.0 should be fantastic for the typical PC user.
Suggestion: send .ico to IE users (for user niceness), .png to all others. Give MS until (say) late 2003 to catch up with W3C standards (plenty of time), and then pull the .ico support. -- The Anome
Has anyone actually checked whether MSIE allows PNGs as shortcut icons or not? In any case, I've uploaded a couple of examples of a shortcut icon for Wikipedia, based on the quote, File:Favicon-q.png, and the W, File:Favicon-w.png. --Carey Evans
- I checked, and IE doesn't appear to support PNGs. IMHO the W looks quite good, so I turned it into a standard 16-colour Windows icon: [1]. IE, Mozilla, Galeon, Konqueror, and probably Opera support this. --Carey
Here's the right thing to do:
- <link rel="icon" href="/upload/favicon-w.png" type="image/png" />
- <link rel="SHORTCUT ICON" href="/favicon.ico" />
Mozilla will look for the icon; IE will look for the SHORTCUT ICON or the favicon.ico depending on version. And you don't need to store the image at too high quality; a 16-gray PNG should be small in byte size without losing any visible quality. --Damian Yerrick
If several changes have been made to an article and I go to the History list, I would like to have a way to see all the diffs at once, the net change to the article since I last saw it. With the old software, I'd have clicked on the "diff" link corresponding to the first change, which would have displayed the difference between the original and the current version. The new software (I think?) forces me to click on all "diffs" separately to get a sense of the net changes. AxelBoldt
- I second this. The old software was annoying because it only let you see cumulative diffs. The new software is annoying because it only lets you see diffs of individual changes. There should be a way of seeing both types of diff. --Zundark, 2002 Jan 27
My watchlist
Yes, I adore the watchlist feature. So anyway, I was wondering if it would be too much of an additional grind on the server to list the number of pageviews for each of the pages on our watchlist? I think many people would be interested in this.
I would also like to be able to make my watchlist public. I hope this could be a feature that can be added in the future. Public watchlist (default: no)
It would be nice to have a history table (and an auto-generated graph as well if possible), showing the trends, day by day, week by week, etc. for each of the monitored variables. This would give an instant overview of what's going on.
See MRTG for an example of this sort of thing (for network traffic in this case), or the trends graphs at seti@home for another. -- The Anome
See also the plots at http://www.distributed.net/statistics/ --Damian Yerrick
A very minor issue: I don't want my minor edits showing up on my contributions page. I don't consider myself to have contributed the article on Agatha Christie, for instance, and my contribution to it (a typo correction, IIRC) was so minor as not to deserve notice. I would not, however, mind have the page list articles I instigated, e.g. Dziga Vertov and Dave Brubeck--those, in my mind, are more properly contributions. Best, Koyaanis Qatsi
- It seems this has been changed, but I don't like it at all. Previously I've been able to set my preferences so that the meaningless distinction between major and minor edits effectively disappeared. No longer is this the case. --Zundark, 2002 Feb 2
Orphans
I would like the Orphans page to not list User: and User:Talk pages. The User pages don't need to be linked to anything, since they are not articles. The User:Talk pages are Talk pages, not articles. They aren't actually orphans anyway: Users are already linked from the List of Users page, and the User:Talk pages are linked to from the User pages. -- Dreamyshade, Feb 5
- Seconded. I've been trying to clear out orphans for a while. A more general strategy may be to exclude from the list talk pages where the 'parent' page isn't an orphan, and then to make the namespace links more conspicuous. --Damian Yerrick
- Not necessarily. The list of users links to all users, but special:AllPages links to everything.
Also, would it be possible to omit the various Complete list of encyclopedia topics pages when generating orphans? A link from these pages is not really helpful in terms of the general navigation of Wikipedia, there are probably plenty of articles which are only linked to from here and which nobody will ever notice. Bryan Derksen
As a more "out there" idea, how about doing the orphan search as a graph traversal starting at the homepage? That way it would spot "islands" of articles which link to each other but not to anything else in Wikipedia. Bryan Derksen
I think this is a great idea, but it should probably be on a different Orphan page (maybe a "Stranded" page), to separate true orphan pages from island pages. Dreamyshade
Edit page
Edit conflicts would be a lot more fun and a lot less grueling hot metal pins stuck under the fingernails if a diff between your version and the other person's version were shown. --Brion VIBBER, 2002/02/06 (Suggestion originally from eo::Bezonataj Funkcioj.)
- Seconded. --Damian Yerrick
Recent changes
Editing an article causes the previous edit summary for that article to be removed from Recent Changes. This is incredibly annoying. Not only does it mean that I can't see many of the summaries that other people write, but also I obliterate my own summaries if I edit an article a second time. With the old software there was at least a way to change this behaviour, and it was reasonable to assume that anyone who was inclined to read summaries had set their preferences so that they could see them all. So I would like an option for full Recent Changes (and preferably it should be the default). --Zundark, 2002 Feb 7
Search, Sherlock, and Mozilla
It would be nice if the search engine could produce results that worked better with Sherlock search plugins, like the one on my user page. Basically, this would mean:
- Having some easily identified text near each result, the same as Google does with special comments.
- Using a unique URL, that Mozilla can spot as a cue to pop up the search sidebar when I search from the search box at the top or bottom of the page.
- Using GET, because Mozilla's search sidebar seems to have issues with POST.
Listing New Articles on User page
It would be nice if the ten newest articles that someone started would appear at the bottom of their user page. --Chuck Smith
Change to username
Changing a username. Extract from FAQ
"Q. How do I change my username?
A. Simply go to special:editUserSettings and enter a new username and password, then save your settings. The old account will eventually be pushed off the Recent Changes page and can, if you like, be deleted by an administrator."
I tried this, either I am completely daft (very likely), or it cannot be done (perhaps). If it CAN be done, can someone please provide clear instructions, I cannot see a field in special:editUserSettings for changing the username, or if it cannot be done, can the facility be provided please. I ended up creating a new username, which seems a waste. user:Perry Bebbington
- I tried it too, for a lark; it does not work.
- The only way is to create a new username and start using that one. I'll change the FAQ answer. AxelBoldt
- You must first Log Out before putting in a new username (yes, it was different on the old system).
Adding text documents to the upload page, and linking to the uploaded file in an article, displays the text in non-editable text box
I just added a new entry on What Wikipedia is not. The entry is concerned with the habit of some, to do wholesale copy-and-paste jobs of public domain source material (i.e. entire books, laws, etc.). One of the worst (or best?) examples is the The Origin of Species article that has each entire chapter in its own subpage! This would be a real nice, cool and useful thing, if the entire planet couldn't edit the text and therefore change what Darwin said. This type of use (misuse?) of public domain text is, for practical reasons, useless. I agree that short and highly relevent documents should be in an encyclopida -- It is just not possible to protect what the original authors said if the text is editable in the wiki way. It would be great, if we had a place to "upload" such text, link to it in an article, and have it displayed in a non-editable, text-box (all it would be in edit mode is the URL to the text file -- just as it now is with images). In this way, the text will be at a stable IP, be content secure (unless somebody overwrites the file), and also be formatted and presented in a consistant way. maveric149
The "Upload" page needs a lot more features if it's going to scale well. There needs to be some way to determine whether any of these files are linked to from Wikipedia articles, and if so, which ones. Also, this page is eventually going to become really big. Don't know how much of a problem that will be, though. Perhaps some way to sort these files by something other than upload date would be useful? Bryan Derksen
Overwrite warning and/or history for Upload files page
Another scalability issue has to do with the fact that there is no overwrite warning issued when you upload a file that has the same name as a file already on the server. Some type of warning, along with limiting uploads to logged in users (to help prevent somebody from maliciously uploading a porn image, with the file name Pope_John_Paul.jpg for example, to replace an valid image of the Pope with the same file name), would also help. maveric149
Just got into a bit of an upload war :) I was blotting out a whole bunch of stupid banner images from the "never take shit" guy as he was uploading them, and removing some of his earlier spam while I was at it, and it occurred to me how easily I could wipe out a whole bunch of legitimate uploads instead. There should be some sort of "history" for the uploaded files to allow reversion to previous versions. Bryan Derksen
"What articles are linked to this file"
Sheesh, there's a ton of stuff in there now which doesn't look like it belongs in an encyclopedia. What would really help is some way of finding out what uploads are linked to from which Wikipedia articles. That way it'd be easy to spot which aren't linked at all, and which are linked to from inappropriate articles. Bryan Derksen
Should we add requests to the top or the bottom of this page?
2002 2 25 Wouldn't it also be a good idea to include the date of the request as well or is there a convention against that? Vignaux
Reverse the date ordering of the "New Pages" listing
2002 2 25 It is the opposite of the ordering of the "Recent Changes" listing (latest at the top) which I prefer. Vignaux
2002 2 25 I really like the idea of having different colors for all the user pages, talk pages and wikipedia pages. However, could a better color scheme be used? Really, lime green for the wiki pages, and salmon pink for the user pages (I do hate pink) are just horrid choices! And the blue of the talk pages makes it difficult to tell where hyperlinks are when your settings are set to not underline them. But the concept is real cool and will be most useful. I will play around with some colors and report back in a day a two. maveric149
- I hate the idea of colors. The web is busy enough as it is, and wikipedia is a major busyness offender. Colors are just one more layer of not very interesting information between us and the TEXT. I'm here for the text, people. The interface can go play somewhere else. Metawikipedia? MichaelTinkler
- I'm a relatively new contributor, but as a design student and extensive user of online encyclopedia's, I have to say that almost any implementation of color and/or graphical features is going to make this place more desirable for those looking for a professional resource. Right now, the design is geared almost 100% toward the editing end and very little toward the user end. Personally, if I were designing it, I would make the top frame thinner with a more horizontal orientation of the logo and give both it and the side menu some type of cohesive color scheme (blue with a compliment perhaps). I would also suggest making the default font the verdana, arial, helvetica family because it's much cleaner and easier to read than the seriffed times new roman. Jazzoctopus
- I'd be quite annoyed to get Helvetica after choosing the very readable Lucida Bright in my browser. I agree with you about the size of the top section though; I had the UseMod Wiki set up to have only the title and logo at the top, with everything else down the bottom out of the way. --Carey Evans
- I would suggest that the colors be made considerably paler - they do interfere with the hyperlinks - and that the main article pages should be backed by plain white. Being able to read the pages is, after all, the most important aspect, with all else secondary to that. -- April
- How about leaving the main text area of all pages white, and only have different color schemes for the top, side and bottom menubars? The more I think about, the more I am being convinced that having any color other than white for the main text area is a bad thing. I do alot of work in :Talk pages with tables with their own color schemes before I place the tables in the article. Now with the different background colors, the eye is tricked, and anything you work on that has color on a :Talk page will look very different when you place it in the article. maveric149
- How about a setting in preferences so I can turn off these colors altogether? The current scheme is truly awful, but no matter what it's replaced with it's going to look bad for someone. Really, do we need to be hit over the head like this about what sort of namespace any given article is in? Bryan Derksen
- An alternative would be just a coloured bar down one side, which looks quite neat, IMHO of course. Something like "html { border-left: thick solid green; }" in the CSS stylesheet for this page, for example. --Carey Evans
- What I'd love to see is for the people who'd like to see something specifically different in the interface to take a page from the wiki, save the HTML, modify it to their heart's content, and post it for everyone to see. Then if people publicly admit to liking it (as opposed to every change to the live code which is met only with scattered complaints), we foolish blind programmers will have something concrete and pre-approved to put into the code! --Brion VIBBER 2002/02/25
- I agree that the main text area should have a white background, but the sides and top should have some interesting color to create a contrast. The problem with leaving it plain and making the user edit it to their choice is that a casual user won't do that and just think it's a plain, boring looking website. And I still think that most web designers agree that the arial family of fonts is clearer and more professional for websites. Jazzoctopus
Alternate designs
Fair enough, Brion. I've put together a few pages, which are living at http://home.clear.net.nz/pages/c.evans/wp/ for now. The most useful link there is the Talk link at the bottom of the page, that explains it a bit. I haven't tested it in IE, and I know it won't look as good in Netscape 4. --Carey Evans, 2002-02-27
- I looks nice with IE as well. But, even though the top part in this wiki might be too large, the one in yours seems too small. No edit/Main Page/Recent Changes link (try that on a very long page!), no info about how you're logged in, no search box, and you'd definitely want to have some kind of horizontal line there to divide the header from the rest of the page. The "think colored line" thing is very nice, though. I agree to change the background color of the text back to white on all pages. Either we let the header/footer/QuickBar change the color, or we use the "thick colored line" thing. --Magnus Manske
- Thanks, Carey! It looks great (I, too, love the line along the edge), but I have to agree with Magnus that *some* info at the top is darn useful. When I use the non-English wikipedias which are still on the old code, I go mad looking for the edit link at the top... (Also, the edit links seem to be broken.) This situation might be improved upon with a decent sidebar; one that's a little cleaner looking and only takes up space at the top (ie, float:right). Perhaps the sidebar might be a chunk which includes the logo? Just a thought. --Brion VIBBER
Old feature requests:
- Top priorities: really important features we still don't have
- Report features and automation
- Interface and user preferences
- Wiki shortcuts: new shortcuts, code tricks
- Naming conventions (this is all done, but not yet implemented on Wikipedia)
- Cookies, logins, and privacy
- Other feature requests
- Completed feature requests
- Really ambitious and fanciful feature requests
- Wikipedia approval mechanism