Pages that serve no purpose but to disparage or threaten their subject or some other entity. These are sometimes called "attack pages". This includes legal threats, and biographical material about a living person that is entirely negative in tone and unsourced, where there is no neutral version in the page history to revert to. Both the page title and page content may be taken into account in assessing an attack. Articles about living people deleted under this criterion should not be restored or recreated by any editor until the biographical article standards are met.
Preview:
This page may meet Wikipedia’s criteria for speedy deletion. The given reason is: It is a very short article providing little or no context (CSD A1), contains no content whatsoever (CSD A3), consists only of links elsewhere (CSD A3) or a rephrasing of the title (CSD A3). Please consider placing {{subst:empty-warn|Talk:Prototype/Archive 4}} ~~~~ on the User Talk page of the author.
I am so sick and fucking tired of never being able to find the damn correct template for an action I know exists. I've never paid much attention to the interface but this is certainly one of the area that needs improvement, I've designed the above mock up to sort of fit into the new tool bar. Dispenser16:50, 24 July 2009 (UTC)[reply]
After the "save" button is pressed, the user is brought back to the article in reading mode, without any information on whether his edit was successful or not. And the user might have a hard time to figure out his edit was successful, especially if he made a minor change. So we do need to display a message to inform the user. I suggest something like the following box:
Your edit has been saved.
I forgot to say that mw:Extension:EditSimilar is stable and can be used to produce such message. You only need to empty the content of MediaWiki:EditSimilar-Categories, and then configure $wgEditSimilarAlwaysShowThanks. The thanks message can be adapted to a edit-succesful message. Or you could as well built it from scratch, that is up to you.
I beg to differ, we don't need anything like that. That looks absolutely hideous. If you hit Save, it will be saved. If it doesn't check your computer. Lady Aleena05:30, 7 August 2009 (UTC)[reply]
"Your edit has been saved." ? There is a similar box after modifying your preferences. However, some users may want to know exactly how an article will look after saving it, so it should be disable-able. HereToHelp (talk) 01:00, 4 September 2009 (UTC)[reply]
How easy would it be to color-code wiki code in the editing window, a la emacs? This could be used either to identify different wiki code elements, or simply to make all code elements a different color from plain text, to make it more obvious to technophobes what is what. After reading over the comments from the user feedback study, it seems like this would greatly lower the barrier to entry. 96.255.47.1114:37, 27 July 2009 (UTC)[reply]
WikEd already does this, but it doesn't update as you type. It probably could be done with a more sophiced parser, but the usability team seems to be hellbent on WYSIWIG. But their criticism of WikEd is valid, contentEditable is never fast enough, alternatives such as Bespin is interesting but doesn't work in IE. There implementation of rich editors in flash, but the MediaWiki flocks don't really like flash, due to its proprietary past. Dispenser11:37, 28 July 2009 (UTC)[reply]
We will be working on syntax highlighting and content folding (folding of complex structures such as template calls and tables) in the Citron release. --Catrope08:58, 31 July 2009 (UTC)[reply]
OH GOD! Please no! WYSIWYG is bad bad bad. There are such things as help pages for Wikicode, send newbies to read them. Get the newbies used to reading help pages, and maybe we wouldn't have so many of them making mistakes. WYSIWYG never works well. There is always those things that screw everything up with one little click. Show newbies how to write Wikicode manually. Give their brains something to do. I ditched the edit buttons soon after I got to Wikipedia. I will never use a WYSIWYG editor for it either. Lady Aleena05:41, 7 August 2009 (UTC)[reply]
Couldn't disagree more. Check the usability study. Newbies find our help pages useless. Newbies are the most important editors, because (1) they do most of the damage (2) they provide the most content (3) they will probably not stay long enough to learn our byzantine markup language (4) "oldbies" will stay around long enough to learn to use our editor. --- 67.201.96.202:22, 8 August 2009 (UTC)[reply]
I am not against syntax highlighting, but maybe only during a preview. Normally when I am typing something, when things change color all of a sudden, it is jarring. Lady Aleena05:41, 7 August 2009 (UTC)[reply]
I think colour-coding would be superb for usability (and even in non-preview, sorry to disagree with you Lady Aleena)--Bedales9400:04, 8 August 2009 (UTC)[reply]
I have just seen that Project Halo (an extension related to Semantic Mediawiki) has a syntax highlighting editor feature. The developers (www.onotprise.de) have obviously got a lot of fancy AJAX-type features built into their software, so I don't know how easy it would be to take just this part out and re-use it for regular Mediawiki, but it's a thought and proves it has been made to work. I'd need to examine it more closely to see what the limitations of it are. Bedales9423:16, 16 August 2009 (UTC)[reply]
Wasted space
There appears to be about one line of empty white space at the top, moving the actual article text further down than in Monobook. This makes it much less convenient to read on a small screen. There is also too much interface stuff at the bottom, below the article. Otherwise, I like the new look. --Apoc240010:31, 3 August 2009 (UTC)[reply]
Under the advanced drop down, there's an option to specify headings. The headings start at one and end at five. I see two problems with that. The first, HTML lets you go to a sixth level heading (although articles rarely go beyond the fourth). The second, Heading 1 is generally reserved for the title of the document, not for sections; for editors unaware of this, we might see some header problems in terms of the English Wikipedia's WP:LAYOUT. ChyranandChloe04:44, 4 August 2009 (UTC)[reply]
We received the warning about the use of Level 1 heading at several feedback forums, so Level 1 heading will be removed from the drop-down in the next deployment.[2] It can happen as early as this week. Thanks. --Shuhari23:09, 4 August 2009 (UTC)[reply]
Header is too large
A large gap between the top and the tabs in the current layout.
The header at the top is too large...I liked it before. See the image. (On a side note, I can't seem to upload here...is this going to be fixed, or is permanently for admins only?) Smallman12q00:20, 7 August 2009 (UTC)[reply]
My concern is about vertical real estate. Already now screen hardware expands horizontally and shrinks vertically. I personally prefer to have as much vertical page length visible for content. For instance in this edit window there are 75mm above the page title (OS, browser, header) -- KlausFoehl11:47, 10 August 2009 (UTC)[reply]
Special characters
The English Wikipedia offers "enhanced editing toolbar" at the bottom of the screen. While the new editing tool bar from the beta has most of the symbols of that of the enhanced editing tool bar, several are missing; and those that are missing turns out to be the ones I use. Those symbols are: – — … ‘ “ ’ ” ° ? ' ˜ ? = = ± - × ÷ ? ? · § ChyranandChloe03:23, 7 August 2009 (UTC)[reply]
Added them, thanks. They should be live on the prototype wikis very shortly; deployment on Wikipedia will take a little longer. --Catrope18:20, 9 August 2009 (UTC)[reply]
Complaint Dept
Is this where I piss and moan that I can't get Twinkle to work and then you guys tell me that I should write an article instead, cuz it doesn't need Twinkle. Law04:24, 7 August 2009 (UTC)[reply]
I am sorry to say that this whole idea makes me uneasy. I think that Wikimedia projects are easy to use without too many goodies. Sure, I have a few javascripts that make my editing life a bit easier for repetitive tasks, but some of these changes are not for the better in my opinion. I may repeat what has already been said above, but there aren't section headings for each issue.
Page tabs
Please choose a side for them, splitting them up like that makes mousing to them a wrist ache. I mean, I don't get why the tabs in monobook are spaced unevenly as they are now, but at least they are all kind of grouped together. A cosmetic issue is that they don't have caps on them, they just sort of fade to the top. That just looks weird.
Read/Edit tabs
I would not mind them all that much if there were less redundancy. When one is reading a page, one does not need a read tab. When one is editing a page, one does not need an edit tab. Now, if one is reading a page, an edit tab makes sense; if one is editing a page, a read tab makes sense.
The very idea of these "redundant" tabs is to show people where they are. Right now, the "Discussion" and "Edit" tabs are white for me, which tells me I'm editing a discussion page. For power users it's usually obvious where they are and where they can go, but for newbies it's not. --Catrope18:06, 9 August 2009 (UTC)[reply]
Right shifting tabs
I am not happy with the function tabs shifted to the right. I like them all on one side, preferably left. It wouldn't be such a shock to the system.
Hidden function tabs
It is very important to not hide functions with a down arrow being the only way to access them. The function to Add topic, while only on talk pages, is a very important function and should be seen at all times. The new topic screen is better, especially for new users, so that they can get used to adding things to the wiki in small bits. Also, it is far less likely that there will be an edit conflict when two newbies are adding their thoughts on a subject. Watch needs to be seen too, though move not so much. New users should stay away from that for a short time before they start moving things around.
I agree with your distinction, although it might be possible to override it with a prefernce. I saw a mckup that I really liked where read/edit/history were below article/discuss, because both of those have r/e/h modes. HereToHelp12:05, 11 August 2009 (UTC)[reply]
Edit window buttons
They are too intrusive. When they were small and all on one line, they were all right. (I have had them turned off for so long, I had forgotten about them until now. I didn't even remember what they looked like until I turned them back on and took a look.)
When they are turned off, there is the loss of the ability to insert special characters with a click which, on monobook at least, is under the edit window in its own menu.
Missing wiki markup
{{}} - insert template
{{{}}} - insert variable parameter
[[Category:]] - insert category
#REDIRECT [[]] - insert redirect
{{DEFAULTSORT:}} - insert DEFAULTSORT magic word
<nowiki></nowiki> - insert unwikified text
<!-- --> - insert unprinted comment
<span class="plainlinks"></span> - insert plainlinks for external links
Annoying navigation pop-up
I just found an annoying navigation pop-up. I was going to go back a page in another tab, and I got this annoying pop-up that tells me that all of my changes will be lost if I navigate away. If that is true, then that is a drastic change to the way things work. Currently, I can navigate away from an edit window to go back to look at something in an article in situ, then navigate back forward to the edit window where all of my changes are still there. If that has been taken away in this new skin, then Wikimedia will become a pain to edit. There are times when I only need a quick look at how things are where even opening a new tab in my browser would be overkill.
This only works on browsers that support it. Most (all?) versions of Internet Explorer don't support this and really do throw away your changes when you navigate away. Based on other comments, the pop-up has been reworded slightly to say you may lose your changes, and can be disabled in your preferences (both of these not live on Wikipedia yet, hopefully they will be soon). --Catrope18:24, 9 August 2009 (UTC)[reply]
New unordered list bullets
I like them. I think they are prettier. I just noticed them in a preview of this post.
Edit summary box
It is way too short. Please return it to its original length. Some edit summaries I write tend to even go longer than the current box, that box drives me nuts. (But for those who know me, what doesn't?) :)
Why the move? It was just fine where it was. It is now in the way of my user links above it. The new placement looks clunky and sprawled out. Where it is in monobook, it is nice, compact, and makes sense where it is.
Spacing at top
I don't know why, but that space aggravates me. Tighten it up please.
Edit window in general
It looks like a word processor. I would rather a link to the help page on wikicode than all of those images cluttering up my screen. When I first started out, I had more trouble when using the buttons than when I turned them off and typed in all of my wikicode manually with the help page in another window/tab. I really don't need those missing wiki markup links, but they are nice to have down at the bottom when I am feeling particularly lazy (especially when typing DEFAULTSORT).
I agree that Wikimedia projects need to be more usable, but not in this direction. Some cosmetic changes to make the text more visible to the visually challenged would be a step in the right direction. Has the color scheme been tested anywhere? There are people who might have trouble clicking in the right places, so sure bigger buttons might be a good idea for them. Keep the menus and functions tight for the rest of the users. That would put more article on a page. Lady Aleena05:06, 7 August 2009 (UTC)[reply]
I also disagree with the movement of the search box. I don't find that it makes any sense up there. Is searching related to the tabs nearby? Is it related to my watchlist or my preferences? No, it's related to the site. It belongs over on the left. As has been said here before, raising it up to just below the logo might be appropriate. Where it is now is silly. (Also there's a HUGE wasted space there. Please stop visually bloating Wikipedia ;_;) - BalthCat07:44, 11 August 2009 (UTC)[reply]
Tabs
I use JS to customize WP a lot. So When I started using Beta, I was shocked to see that my tabs were pushed into a little down arrow menu, and disappeared on special pages. For example, I made a tab so that I could quickly patrol a page, but It got hidden, which defeats the purpose of a tab. Also, I want to be able to show tabs on Speciual pages. I really like the way the tabs are split in tweo, but I wish there was a way to choose if a tab is shown on top or in a menu. Thanks, 59.183.159.11006:26, 7 August 2009 (UTC)[reply]
Feedback
Lots of editors do repetitive tasks. adding an extra stage (by having to click advanced to find some buttons) will irritate established users. Can you get around this? It isn't clear to me. Also, until the gaget reftools is avaliable I will never ever use this. Citation is way to important for Wikipedia. Sabine's Sunbird06:50, 7 August 2009 (UTC)[reply]
Once you've opened the "Advanced" tab, it should stay open. Is that not working for you?
Integrating an improved citation workflow into the standard toolbar is definitely one of the improvements the team is hoping to make in one of the next releases.--Eloquence00:07, 8 August 2009 (UTC)[reply]
Are you sure you wantto navigate away?
Please make this feature optional, it is probably good for newbies, but for power users it is rather annoying, and modern browsers retain the text anyway, so you can simply navigate back/reopen the tab. --Tgr08:46, 7 August 2009 (UTC)[reply]
I agree it would be nice to have an option to disable it. I would also suggest making the default action "cancel". With the default action as "OK", it's likely that users will accidentally click through what's initially a scary pop-up warning (alertbox panic behavior).--Eloquence00:51, 8 August 2009 (UTC)[reply]
I added an option to disable it, I'll poke Brion to get it deployed. I agree that the default action should be "Cancel", but unfortunately the dialog is generated by the browser and we have no control over it. --Catrope16:47, 9 August 2009 (UTC)[reply]
Thanks for adding the option. :-) BTW, currently the EditWarning does not trigger after the user has submitted a preview, and not yet made any new changes. (Presumably because the textarea starts in an unchanged state.) Not sure there's a trivial way to change this? Perhaps by submitting a state indicator alongside the edit contents ...--Eloquence00:46, 12 August 2009 (UTC)[reply]
Search box size is too small
Problem description:
See the attached picture.
Test using the search box on commons:, with the AJAX suggestion tool : you can't read the whole name which you are searching or typing
Under the "help" tab, Cite.php spans (i.e. <ref>) are called "references". I can't help but point out that these are actually "footnotes" or "end notes" not "references". I realize this mis-usage has a long history in Wikipedia and Wikimedia, but it has always bothered me. ---- CharlesGillingham03:21, 8 August 2009 (UTC)[reply]
I agree. It would be nice to have the two separated out with references using "<ref>" and foot/end notes using something else and directing to another section, if desired. — AjaxSmack 00:09, 13 August 2009 (UTC)[reply]
Ambiguous image captions in category pages on Commons
You can see that with the new beta, it is no longer clear which caption belongs to which picture, whether the picture above the caption, or the picture below the caption.
Contrary to the way most edit boxes work in modern browsers, the edit boxes in Vector lose all my changes when I hit the back or forward button. This was especially annoying when I was hitting "back" to try to salvage my text from an edit conflict, instead of hunting for it in the big huge slow box. What I had written was simply gone.
Another use case where you want to keep your text is when you want to take a quick look at the article page again.
(BTW, as a developer, I understand the annoyance factor of posting bugs in a forum instead of in a bug tracker. Let me tell you that I tried. After something like 10 minutes, Bugzilla is still asking me to Please Stand By.)
Try with Google Chrome : it can fully remember the contents of the edit box, without having to fully refresh the page from the site, when the site actually does not know what you have still not submitted to it. As a bonus, this ensures that you won't submit a form twice (you don't get the infamous warning asking you if you want to resubmit the last form that led to the page you are going back to). It can even remember your current edits it your PC hangs and reboot, or if you accidentally close the tab or window (which can be restored).
May be you'll have lost the session with the wiki server, but WikiMedia is smart enough to allow you to restore a new session by keeping also the data you've just submitted after restoring the window/tab: MediaWiki will ask for your confirmation, but you'll have lost nothing (not like in IE or even in Firefox). Verdy p07:18, 15 August 2009 (UTC)[reply]
Font size too small
Sign and and droped it out because the font size was reduced to a ridiculously small size. Any idea if the font size can be resized while in Beta? 68.63.139.9901:46, 9 August 2009 (UTC)[reply]
Same for me. When I enter in beta, the font size its very, very small (impossible to read for me). When exit from beta, the size is correct again. --Furado23:36, 10 August 2009 (UTC)[reply]
Overall line color
This comment would be specific to Vector skin. This skin uses blue as the main color. In my opinion, the line color in content part of page (box, table, section underline) should be changed to blue line, too. One of the reason I have been favored in monobook is its consistent color (gray). Vinhtantran03:13, 9 August 2009 (UTC)[reply]
Nice design. Besides, in order not to waste screen space, the side bar should be collapsable, like the new "show options/hide options" switch on Google . Teofilo08:47, 16 August 2009 (UTC)[reply]
It's a nice job what you've done with the edit toolbar, but it can be even better with a WYSIWYG interface. You can leave the option of switching from WYSIWYG to Wiki source-code with a menu or a button, so that new users can easily edit Wikipedia without having to pass through a Wiki-code tutorial first. -ArkBlitz19:04, 9 August 2009 (UTC)[reply]
Acai is only the first release of three (the other two being Babaco and Citron), so more improvements are coming. A full WYSIWYG editor for wikitext is not currently planned because of the huge technical difficulties associated with it, but more improvements to the editing experience are in the works. --83.119.125.2719:46, 9 August 2009 (UTC)[reply]
,_from_Robert_N._Dennis_collection_of_stereoscopic_views.jpg){kind=link}