Talk:Prototype/Archive 8

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 ([1]).

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 n o re-feedback from people actually working on the project. Reminds me more of Microsoft than Wikimedia. -- JovanCormac 15:40, 20 October 2009 (UTC)

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

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

The problem with wikicode is that it is not line-based, most elements can be deeply nested over many line breaks. One needs a real whole-document based wikicode parser for correct wikicode highlighting, otherwise the results will be misleading for all but the most simple articles. Also, reference and table folding rquires a reliable and correct parser. The upcoming version of wikEd that has been in beta testing for a while has such a wikicode parser and I will start working on on-the-fly highlighting shortly (which has become possible at least for Firefox due to some recent changes). Another problem with many rich text editors including this one is that they break the built-in undo/redo history (e.g. from the context menu) and they cannot detect text drag-and-drop with the mouse events. Cacycle 23:38, 24 March 2010 (UTC)

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)

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)

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)

He probably already uses keyboard shortcuts (alt-m for move, alt-c for page, alt-t for talk, alt-e for edit, alt-h for history). Any other issues like this could be solved by a special skin for the visually impaired (text2speech friendly, keyboard shortcuts improved, default focus on search box/edit box in edit mode, etc.)Manishearth 08:38, 16 March 2010 (UTC)

Providing another skin just for a certain user group doesn’t make much sense, when the issue can be fixed with moderate effort. Separate skins tend to outdate easily. Lecartia 05:08, 20 April 2010 (UTC)

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)

Search and replace dialog : cannot replace current selection

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

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

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

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

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)

It would be nice if the new link editor suggested sections, instead of suggesting article names only. Manishearth 08:05, 16 March 2010 (UTC)

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)

Search Box on the right?

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

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

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

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

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

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

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

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)

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)

There could be a second floating searchbox on the side of the page. It should be on the side where the search box in monobook is, and should not cover up the sidebar. If you want I'll write a bit of js for it..... Manishearth 08:10, 16 March 2010 (UTC)

Here's your js (works in both beta and monobook):

addOnloadHook(function(){
document.getElementById((skin=="vector")?"panel":"content").innerHTML+='<div id="p-search" style="display:block;position:fixed;bottom:295px;left:0px;z-index:2"><h5 lang="en" xml:lang="en"><label for="searchInput">Search</label></h5><form action="/w/index.php" id="searchform2"><input type="hidden" name="title" value="Special:Search"><input type="submit" name="go" class="searchButton" id="searchGoButton" value="Go" title="Go to a page with this exact name if one exists"><input type="submit" name="fulltext" class="searchButton" id="mw-searchButton" value="Search" title="Search Wikipedia for this text"><button type="button" ONCLICK="window.open(wgServer+\'/wiki/\'+document.getElementById(\'searchInput2\').value)"><img src="http://bits.wikimedia.org/skins-1.5/vector/images/external-link-ltr-icon.png"> </button><BR><input id="searchInput2" name="search" type="text" title="Search Wikipedia [alt-f]" accesskey="f" value="" autocomplete="off" size=19></form></div>';
document.getElementById("searchInput2").onkeyup=function (){document.getElementById("searchInput2Suggest").style.position="fixed"}
});

It also adds a mini external-link button which opens the entered page in a new window (That way you can drag-and-drop pagenames into the bar and open them in a new window after clicking this button). This does not mean that you can open external links with the button, and it will open pages on the wiki you are on only (I used the external link image as it kinda shows a popout window). It obscures the "toolbar" header on enwiki beta, but not the links. Anyways, scrolling will move the search box, so the obscuring isn't permanent... Manishearth 13:43, 16 March 2010 (UTC)

Search Box / Navigation - why not try fixed postioning?

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

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

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

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

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

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

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

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

+1. Having the search box always available without scrolling would be an improvement to me. --Alex 23:08, 14 June 2010 (UTC)

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)

Miscellaneous comments

I like the new skin a lot! Two comments:

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

SharkD 16:54, 31 October 2009 (UTC)

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

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

If you decide to update the logo, please change the character which looks like र्वा (rva in Hindi) to वि (vi). Thx. Manishearth 08:12, 16 March 2010 (UTC)

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)

Move "Try/Leave Beta" links further left

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

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

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

Interwiki links

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

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

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

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

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

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

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

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

Question from JS developer

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

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

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

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

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

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

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

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)

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.