Talk:Prototype/Archive 7

Fix 2nd- and 3rd-Level Heads

Currently, the 2nd-level heads are roman (i.e., nonbold) with a horizontal rule under them. The 3rd-level heads are the same size as 2nd-level and bold. (The heads on this page are not the same format as in the general Wiki articles.)

The problem is that the conventional method of indicating higher-level heads is to use larger sizes and boldface. But here, the two head levels are the same size, and the smaller one is bold rather than the larger. This can be confusing in trying to see how head levels are related.

I suggest making the 2nd-level heads bold and the 3rd-level heads roman and a couple of points smaller, to clarify the relationship between the levels.

Making Citations Easier

By far the most time I spend on Wiki articles is getting citation formats correct. Why do we have to do this? Instead of having the list of citation types at the bottom of the page, requiring scrolling down to use them, make it a floating, dockable palette in the left margin. When we click a cite type, instead of taking us to a page that shows the format, just open a dialog with the appropriate fields, which we can fill in. For example, clicking a book cite would open a box with fields for author, title, each of the other publication facts, and a blank field at the end for annotation. Fill in any or all, then click Save--the cite is inserted at the cursor location.

One of your strategic goals is to get more readers participating. Since you require citations, if you made creating them less onerous, you'd probably get more people willing to edit. It would also improve the consistency of citations, which are currently all over the place in terms of format.

Please alter Collapsible Tabs to hide the tab contents onload. Right now they are completely unusable without javascript

This is a common error made when creating expanding/collapsing FAQs. The more usable way to do so is to add a window onload event listener in the script that iterates over the questions and adds a display: none to the node style. That way if javascript is blocked, does not load or has some error, the FAQ still functions just fine. Instead right now the FAQ entries have display: none embedded in the HTML and are unviewable without javascript enabled. This is unfriendly and impairs usability. Given the ease of the fix, I hope you will consider this change.

Thanks for the comment. Vector does the rendering of the drop down menu which you're referring to, but the drop down action is handled with CSS. A :hover psuedo-class is used to change the display: none to a display: block when the user mouses over the menu. It's possible your browser does not support use of the hover psuedo-class on a div element, which may be the reason you're not seeing it functioning. CollapsibleTabs ( which only functions when javascript is enabled ) is a small bit of javascript code that enhances the Vector skin by checking for collisions of the two navigations on the top of the page and shifting menu items into the drop down when necessary to prevent overlaps. --Adam 15:06, 7 January 2010 (UTC)

Since some browsers may not support :hover on arbitrary elements (IE until 7, and IE8 in some modes, and maybe some older versions of other browsers), it seems like a more usable way to do it may be to have the CSS keep them expanded by default, and then use a Javascript "onload" (or similar) function to collapse them when the page is loaded, and add the appropriate "onclick" or CSS :hover stuff. --Aaron dub 19:55, 30 January 2010 (UTC)

Can we please tidy up and simplify the warnings on the edit page?

My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.

Currently, there are three sources of the warning text on the edit page: en:MediaWiki:Wikimedia-copyrightwarning sits between the edit window and summary box, en:MediaWiki:Wikimedia-editpage-tos-summary sits between the summary box and the edit tools, and en:MediaWiki:Edittools generates the edit tools, as well as a section of warning text that follows it. I feel this is unsightly, confusing, and unnecessarily hard to spot and read. I propose that these messages be merged -- the first two should be deleted, and the text from all three be merged into something I would call "en:MediaWiki:Editwarning" (or something similar) which would be placed immediately after MediaWiki:Edittools, and would contain all the most important warning text of the three old messages, and some new, equally important text that I feel is currently missing. Above is a mock-up of my idea (the code used to generate it can be found at en:User:Anxietycello/Interface) -- Anxietycello 15:13, 2 September 2009 (UTC)

I really like your proposal, Anxietycello. The multiple warning messages have always been bugging me. It is only sensible to put the same type of information in the same place and indicate that they are of the same type. Lecartia 10:15, 10 September 2009 (UTC)

Great proposal. 92.149.132.87 22:43, 10 September 2009 (UTC)

Hear hear! 60.242.48.18 16:30, 16 September 2009 (UTC)

Agreed.HereToHelp (talk) 20:20, 16 September 2009 (UTC)

Glad you all like it! Now how would we go about getting this implemented? -- Anxietycello 21:54, 18 September 2009 (UTC)

Support A really big improvement. I guess to get this implemented you need to get the attention of one of the developers. I hope one of them comments on this.--Diaa abdelmoneim 23:01, 18 September 2009 (UTC)

Strong support, great improvement. 84.226.53.50 18:23, 19 September 2009 (UTC)

Support for change. 86.213.55.50 09:11, 22 September 2009 (UTC)

Would an admin be able to blank the first two MediaWiki pages, and create the proposed text box in the edittools page? That's be an temporary but immediate fix, and then a developer could go through the messages and complete the process..? Unless -- do admins have the right to delete and create MediaWiki pages? -- Anxietycello 17:34, 24 September 2009 (UTC)

Admins can edit it, but we should (1) finalize the prototype and (2) find an admin that knows exactly what they're doing, preferably with some sort of approval. These warnings have legal repercussions of which we should be mindful. You can ask on the talk page. HereToHelp (talk) 00:14, 14 October 2009 (UTC)

Support The message section in the prototype is still way too cluttered. -- JovanCormac 09:48, 5 October 2009 (UTC)

Support much more clear, I support, but first need to check the legal repercussions if any 217.23.3.241 17:25, 14 November 2009 (UTC)

Support - I'd introduce the change in two steps. First clean up the visuals as proposed here, but leave the text untouched (for legal reasons). Second rewrite the text for easier comprehension. --Plauz 15:49, 29 November 2009 (UTC)

Support It's a lot cleaner, and I won't have to scroll as far to get from the Edit pane to the submit buttons. 76.252.13.109 07:21, 1 December 2009 (UTC)

Support. Those small changes make a huge difference. Mahanga 05:32, 19 December 2009 (UTC)

Support I dont like when people repeat themselves, especially if it is on a webpage i see often. --Kirbylover4000 01:44, 10 January 2010 (UTC)

Alignment in galleries

Here is an example:

• 
  some text some text some text some text some text some text some text some text some text some text some text

It looks quite bumpy. I think it would be better to align the bottom of the pictures and to align the top of the text. --Rosentod 15:58, 3 September 2009 (UTC)

I think it's fine the current way. SharkD Talk 07:09, 27 November 2009 (UTC)

I don't see any difference with the normal wiki.

"Add section" link at the bottom of discussion pages

It would make sense to have an additional "Add topic" (or "Add section") after all the topics. I (and probably other users too) often read the discussions before posting in a discussion pages, so when it is time to post, I am at the bottom of the page. -W:User:Pgan002

Makes sense. Message boards have a 'Post reply' link at the bottom of a topic thread. Wikipedia should have a 'Add topic' Mahanga 05:34, 19 December 2009 (UTC)

Greater contrast difference on visited (wiki)links

Todays designs must be little "overcontrasted" - LCD screens have poor color reproduction and especially problems to provide contrast enough. At mine, this technical issue usually boils down to having problems with recognizing visited wikilinks (in general all visited links) from the normal ones.--Kozuch 15:54, 9 September 2009 (UTC)

I agree, it is definitely problematic for me either. I am even thinking about quit using beta just because of that. But since I love the other features, I don't quit. 84.227.56.157 21:10, 9 September 2009 (UTC)

I also agree "Kozuch". Contrast between new or visited links, while very important for users, is often overlooked by webmasters; and even on Wikipedia, is unsufficient in regular edition (where visited links are too less distinguishable from regular text), even worse in this beta. BTW the contrast of inexisting links, unique to Wikipedia (where they are red) is welcome. Michel Merlin 16:11, 15 October 2009 (UTC)

No good!

I have found the new toolbar to be not very good, it takes somewhat longer to load (I think) and is just one extra thing to deal with when using WikiEd. It slows down the editor loading and has a different form and parameters than Monobook. This will not be welcomed by browser bot operators. I don't like it either when editing by hand. They can always change back to the Monobook skin if they want. I think that there should be an option to turn off the advanced editbar. I do like its drop-down features though. So much for my 2 cents, but this is what I think. Sorry if I made anyone feel bad. Keep at it. Arlen22 00:39, 10 September 2009 (UTC)

I am sure it takes longer to load. When the edit screen is loading you can't do anything than wait. It would be nice if it could be improved. HenkvD 17:52, 12 September 2009 (UTC)

You can just turn it off in your preferences, I don't remember the tab. --90.185.230.210 06:29, 13 September 2009 (UTC)

Demo feedback

When the pointer is at the top left of the edit box, and I click on the gallery button, nothing appears. But if I move the pointer somewhere else in the editing box, it works properly. I'm using Opera 9.64 with Vista. This problem does not appear in the Açai release. 84.227.159.176 22:26, 14 September 2009 (UTC)

new version text size

Some of the text seems to big, and other comments: n:Wikinews:Water_cooler/technical#Vector_problems_after_mediawiki_update (permalink). 129.173.163.62 01:46, 17 September 2009 (UTC) (user:Bawolff)

I find the text too small -- it is noticeably smaller than the text on the main site. A text-size control feature at the top of the page might be very helpful. (Not sure how it's implemented through CSS, but I've seen it on some other sites.) (Browser: Firefox ver. 3.5.7) (5 January 2010, user:RandySteer)

 RandySteer 23:11, 5 January 2010 (UTC)

Yes, please be careful to leave the main content font sizes alone. Doing so leaves the users in control, where it should be, for something so important to accessibility/usability. Especially today with the variety of device resolutions content is viewed on.

Add-ons do not work properly

You'll have to find a way how to integrate the special add-ons into the new look. On Huwiki for example, the upper tabline is extended with a button that can insert the most frequently used patrolling templates, making the life of patrollers and sysops easier. With the beta version it often works with errors. Same for the article rating tab, when you try to select a Wikiproject to rate the article, it collides with the article's coordinate template and have to switch out of Beta to be able to use the feature correctly. The extra buttons of Template Master and Cite are also gone if I use Beta. These are add-ons many users use, and for me, a sysop and patroller, are vital. Probably the creators of these add-ons can modify the srcipts according to the new skin, and it is not something the developers can solve, but just wanted to mention. --Teemeah 12:55, 18 September 2009 (UTC)

Hopefully some of these add-ons will be built into the skin. There was a mockup of a template selector somewhere, for instance…HereToHelp (talk) 20:11, 18 September 2009 (UTC)

Archiving

This talk page is seriously filling up, 114 threads, over 150kb long. Migrated a few templates from the English Wikipedia. Archive threads September 1 and before into six archives with twenty threads max in each. All past discussions are likewise searchable. ChyranandChloe 21:52, 20 September 2009 (UTC)

Thank you so much for organizing the talk page, it is much much more usable. --Shuhari 00:11, 7 January 2010 (UTC)

In text citations

There has been no simplification of the citation format. While I'm an experienced user (4.5 years/5000 edits), I tend to shy away from using it because it is tricky to use and takes a long time. The <ref> tags are fine, but the <refname {{cite... tags are a real pain in the neck, and I often get it wrong, needing several attempts in preview for a single ref. I avoid editing Featured Articles for this reason! You need to sort this out, particularly as FAs are the ones displayed on the mainpages. I suggest a dropdown menu item, with "type" of ref, then boxes for the relevant fields. 150.203.230.8 23:07, 20 September 2009 (UTC)

I should also add that this is of course going to be worse for a novice user. I remember that when I first started editing in early 2005, almost all of the markup used in the articles was wikilinks, and a little simple html style markup. It was clean and simple, and very easy to use. Most articles on popular subjects were shorter and simpler too. It's proliferated since then, such that an FA is almost unreadable in editing mode. Any usability initiative that fails to address this properly will not have a significant impact on making Wikipedia more usable (and as my above comment suggests, not just for new editors either). 150.203.230.8 23:17, 20 September 2009 (UTC)

I feel your pain. I use refTools, which makes the process much simpler. I would like for this tool to be implemented as standard (in some form) to address the very problems that you mentioned. --HereToHelp (talk) 00:19, 21 September 2009 (UTC)

The beta could take some ideas from WikiEd.[1] One feature is syntax highlighting which makes it easier when sorting through the article, and another is to collapse the references like so.[2][3] Another idea would be the new refs= feature. For example you could name your references and have them all at the bottom now.[4] ChyranandChloe 22:55, 21 September 2009 (UTC)

All of those sound really useful. Can we start an informal "Good ideas list" so this stuff doesn't get lost? HereToHelp (talk) 23:10, 21 September 2009 (UTC)

(outdent) Done. If you want you can move the list to the top of the page, you're a step ahead of me. HereToHelp, can you upload a screenshot for reftools and then insert it into the list? Recommend w:Jing (software) if you need a program that'll do it for you.[5] ChyranandChloe 04:41, 22 September 2009 (UTC)

I really hope there's an option to move the watchlist back into the tabs

Having the watchlist hidden in a dropdown select causes pain

1. I frequently look at the top of a page to see if the page I'm on is watched or not. Usually I'm working on 20 or more pages at once in tabs and like to know at a glance if it's watchlisted or not.
2. Having the watchlist creates an extra mouse click. That extra click also causes pain in that sometimes I have several pages in browser tabs that I want to either watch or unwatch. I used to hover the mouse over the "Watch" link and do a click/Ctrl-tab sequence to quickly step through all of the windows.

Presumably there's some consensus to hide the watchlist in the dropdown but can a Preferences item be added to allow this to be shifted back into the tabs? I suspect if you are doing this you should also allow the Move function to be added to the tabs just in case there are people that needs to do many moves. Presumably some of the administrative functions are now hidden in the drop-down and those would need editor control too. Marc Kupper 00:55, 21 September 2009 (UTC)

I'm not sure where the "consensus" came from (or any consensus around here, for that matter), but I'm all for putting watch back in plain sight. (Keep in mind that some of the buttons may be moved around.) I think move and admin stuff will be hidden. HereToHelp (talk) 03:11, 21 September 2009 (UTC)

The most common admin tabs are Delete and Protect. If Protect gets put into the drop-down list I suspect many admins will be asking for it back as it shows the page's protection state. If a page is protected the tab says "Unprotect." I've sometimes run into pages where I spotted the protection was wrong as the tab is (or was) clearly visible. Marc Kupper 04:44, 21 September 2009 (UTC)

What about some sort of automatic, always correct system rather than the templates we have now? I think that keeping interfaces changes for admins/non admins would be a good thing (although I see your point). HereToHelp (talk) 23:13, 21 September 2009 (UTC)

These sound like defaults, for example to keep the "watch" out of the drop down. I think the skin should allow customization, one-size-fits-all doesn't always fit; it also saves the figuring over which button should or should not be hidden. ChyranandChloe 04:41, 22 September 2009 (UTC)

We're hoping to investigate two solutions:

• In general, we'd like the tab-bar to be more dynamically responsive to the screen resolution, so that more tabs become visible if space is available, and fewer become visible if it's not.
• For watchlists specifically, we want to look into a "star icon" type approach that's familiar from GMail, Firefox, and other apps. This would save space, allow us to always have the watch feature present, and make the watch state immediately obvious.--Eloquence 04:56, 22 September 2009 (UTC)

I've been using gmail and Firefox for one year and one year and a half respectively. Thanks for explaining me what the star actually means, 'cause I've been wondering what it is until now. I felt it was not important since it is so small and clueless. So I never really tried to use that star. 160.53.250.114 11:09, 22 September 2009 (UTC)

Case in point: I don't think that the star (or any icon) will work. Also, remember that watch is not available to anonymous editors. So the skin will have to change by privilege. I like the idea of each user being able to customize which buttons are shown to his/her liking.HereToHelp (talk) 00:08, 23 September 2009 (UTC)

That makes three things we want: (1) better defined defaults, (2) responsive to editing privileges and screen resolution, and (3) customization. The fourth concept is a "star icon", that is the icon would light up if the page is watch and remain either hollow or dimmed if the page is not; well right now if a page is "watched" the text simply changes to "unwatch", the reversed if the page is not watched. I think this fourth concept is not worthwhile discussed alone, there are two reasons for this: (1) without the text, and for new users, the idea of a star lighting up would be ambiguous; (2) if we had the text and the star, then why not cut the redundancy of the star. Now, with customization, then this could be something to our own choosing, and those who want it or something similar will get exactly that. ChyranandChloe 04:58, 23 September 2009 (UTC)

I really think think the watchlist needs to be a default tab for logged-in editors. I like the goal of being more responsive to screen resolution but this is a tab that one prefers to be seen on sight, rather than have to select to drop down. The Star icon sounds like a cool idea; as to concerns about not being intuitive, it is fairly standard as a bookmark icon and it would presumably have a tooltip popup. DoubleBlue 00:53, 1 October 2009 (UTC)

Two comments:

1. I have designed some basic* JavaScript that will move a tab out of the drop-down menu. I've only tested it in modern versions of Safari, but it's available at w:en:User:Nihiltres/vector.js, near the bottom (the moveActionOutOfMenu function). I've used it mostly for admin-specific usability enhancements like moving the delete button out of the menu whenever a recognizable deletion template is present on the page.

   *I am a newbie at JavaScript; I'm self-taught and my main motivation has been to add bits of JavaScript for use on Wikipedia, so "crude" is probably more accurate :)

2. A star is not necessarily the best symbol to use** for the idea of watching a page, given that we use stars to indicate Featured Articles. Generally, we should try to make sure that there is only one concept per symbol. Perhaps a better symbol would be an eye, a magnifying glass, or some other symbol indicating the general idea of observation. Of course, those are tricky in that there may be symbol conflicts with FlaggedRevs. Nihiltres 19:28, 3 October 2009 (UTC)

    **This assumes that using a symbol as opposed to a label is desirable in the first place. 19:36, 3 October 2009 (UTC)

Good point about the star and Featured. I think that binoculars might work, but I think that it would be too confusing as a default option. I have no problem with offering it with a slew of options to those willing to customize their skin - namely established editors. This means that the defaults can be more friendly to new editors. However, we should make customization as easy as possible, and supported natively (rather than ugly javascript add-ons). I (an probably a lot of others) don't need something as heavy as wikiEd but would like, say, syntax highlighting. And it should have an aesthetically pleasing user interface. This means both appropriate eye candy and simplicity, which are lacking from must add-ons. HereToHelp (talk) 01:41, 4 October 2009 (UTC)

Watchlist compatibility with Opera Mini browser

Hi.

I exclusively use the Opera Mini 4.2 web browser for JAVA MIDP 2.0 enabled phones (in the more efficient "Mobile view" mode) for reading and contributing to the English Wikipedia. When I try the Beta layout, the "Watch" link disappears from the bottom of the page (the page menus have always appeared there due to the browser ignoring most CSS in Mobile View) when reading an article. This, I guess, is the only major problem I've had with the Beta layout.

Apparently the link is hidden behind some control, according to the above report? Is it using AJAX or something else like that? Because if my phone browser can't read the page properly, then screen readers for visually-impaired users would also have difficulty, and thus this is a more general accessibility issue.

41.157.10.75 06:17, 21 September 2009 (UTC) (En:User:Zyxoas)

You're right, the "watch" is hidden under a drop down, see discussion above. ChyranandChloe 04:41, 22 September 2009 (UTC)

The drop down is either not properly displayed or not available. This is an accessibility issue and needs to be rectified.

41.157.10.70 15:29, 22 September 2009 (UTC) en:User:Zyxoas

Slideshow

the slideshow is not functioning! -- 217.255.124.29 15:21, 22 September 2009 (UTC)

easy customization

It shouldn't be a good idea to change the font-size in "#bodyContent" from the default of browsers. When the size is properly configured in browsers (and it should be), the changed size is too small. If some people want the Vector skin to change the size, it should be customized without customizing CSS.

I also want the following can be chosen easily:

• font-family in "#content" (if sans-serif is recommended, it can be warned so)
• background-color configured as white in the skin (since contrast is too strong for me, I changed them to #fcfcfc in my custom CSS, but "li.selected" doesn't seem to be changed without customizing JS) --KAWASAKI Hiroyuki 04:36, 27 September 2009 (UTC), modified 04:59, 27 September 2009 (UTC)

beta at other wikis

I'm currently working out a new encyclopedia in wikipediastile and think the beta is actually not bad. But can I - and if I can - how can I insert the new way of editing and textwriting in the new encyclopedia? I would like to try it out. But there's no link on the top like in the normel wikipedia. Can anybody help me?

Our beta only runs on wikis operated by the Wikimedia Foundation. Other wikis may or may not choose to run our beta, that's their choice. There's nothing you can do about that other than to push them to add our beta. --Catrope 23:35, 20 November 2009 (UTC)

Feature suggestion

Hi! It would be great, if a wiki could customize the characters at the "Special scharacters" insert. I really miss the ellipses, endash, and so on. And when one insert a new table, it would be great if one could choose a style, too (like "prettytable").Glanthor Reviol 09:38, 3 October 2009 (UTC)

Proposal: Introduce a "Reading Mode"

The usability initiative appears to be all about improving usability for editors so far. I propose to do another step and improve reading experience as well. See the following mockup of a "Reading Mode" feature:

All UI elements not directly related to reading are gone, the Wikipedia Logo retreats to the top, language navigation is done using a combo box. Users can conveniently switch to and back from the reading mode at any time with a single click.

This gains a gargantuan amount of screen real estate (20+ percent at a typical resolution) and removes all elements that can possibly distract from reading.

The reading mode is superior to both PDF creation (much easier and faster access) and the printable version (better layout, navigation is still functional) currently used on Wikipedia. -- JovanCormac 10:52, 5 October 2009 (UTC)

We want to encourage people to edit, not just read Wikipedia. We don't need something that places an extra divide between the outward-facing encyclopedia and the inward-facing community. That's the reason that cleanup templates on pages have been around for so long: they encourage people to edit, tell them that they can help with a specific problem on a specific page. In any event, the current design is quite amenable to reading: vertical space isn't at a premium and the sidebar provides nice negative space once the navigation links run out. I don't see a particular advantage in this idea. If you're really concerned about screen space I'd suggest maybe some JavaScript to (voluntarily) tuck away the sidebar when it's not in use, but a "reading mode" doesn't sound like a good idea. Nihiltres 20:14, 7 October 2009 (UTC)

I was afraid that someone would be thinking like this. This is a really dangerous sentiment IMO, albeit a common one. Wikipedia is an encyclopedia, as the "big guys" on WP never get tired of telling everyone. It can be edited, but 90% of users aren't interested in that, as statistics show. Most people just want to read it, because that's what an encyclopedia is for. Editing is an option, not a duty. Showing "Edit" links all over the place with no way to turn them off is not encouraging users to edit themselves, it's practically compelling them. I know people personally who find the many links to be distracting, and would prefer to just read. Having all the extra links visible for everyone all the time just to "preserve the project spirit" has the potential of slowing down the growth of Wikipedia over time. -- JovanCormac 21:18, 7 October 2009 (UTC)

I strongly support Nihiltres' POV: the value of Wikipedia is that it's been read and edited by The People, so anyone who happens to know something that would gain from being added or updated, immediately knows he really can do that edit at once. Of course most people (like me, or Nihiltres, or JovanCormac, or else) spend 95% of their time reading, not writing; most people are reasonable, so the one frantically editing everything may be a danger in a few ones' minds and fears, not in reality. It's against openness, efficiency and progress to divide the society into "readers" and "writers"; everyone should be seen as both.Michel Merlin 17:14, 15 October 2009 (UTC)

JovanCormac, why do you say that "all the extra [edit] links visible for everyone all the time […] has the potential of slowing down the growth of Wikipedia"? My understanding has always been that Wikipedia content is added by editors, not readers. :) Wikipedia can always, always use more editors, and that's a significant amount of what this Usability Initiative has been about—making it easier for people to contribute to Wikipedia. Nihiltres 16:18, 17 October 2009 (UTC)

There'll come a point in the very near future (one could argue it's already here) where people who don't have highly specialized knowledge have very little to add to Wikipedia. Already, in the stastistics, one can clearly see the shift from exponential to logistic growth, with estimates showing that within 3 years, the English Wikipedia will basically have reached its maximum number of articles. From that point on, making Wikipedia grow will mean getting new readers, not new editors, and one way to accomplish that is by making it possible to switch to an interface that caters specifically to readers. -- JovanCormac 08:22, 18 October 2009 (UTC)

I actually agree with both sides. We want to recruit editors, but at the same time, having two interfaces would benefit both mostly-readers and mostly-writers. The mostly-readers interface (that I would call "simple", not "reading" interface) would be focused on reading (with a clean interface not cluttered by tools mostly used by regular participants) but could offer a more proeminent incentive to start editing (maybe something like a big, red, blinking visible "You can improve this page" button that regular editors don't need). On the other hand, the mostly-writers interface (that I would call "advanced", not "writing" interface) could use a lot of links and shortcuts that are most useful to regular participants, who are used to this heavy interface anyway. The advanced interface would actually look a lot like the current interface. This would be a win-win solution in my view. guillom 20:18, 17 October 2009 (UTC)

guillom, I really like your ability to see both sides. As an option, we could Advanced interface Standard and make it default. Advanced, to me, implies that we have optimized it beyond the current interface, doing things that are impossible with a one-size-fits-all interface. Which would be great, but it looks like those things are being integrated into the current interface, and actually getting easier to use (template selectors, dialogue boxes, syntax highlighting). I'm worried the term Advanced would be off-putting.HereToHelp (talk) 22:32, 17 October 2009 (UTC)

I meant "advanced interface" as "interface for advanced users". Links like "What links here", "related changes", "special pages" (in the toolbox), or "(cur) (prev)" (in the history) are particularly incomprehensible; they're typically things that the seldom user doesn't need and that are only useful in case of an "advanced" use of the website. Perhaps "advanced" is not the good word here, because it seems to mean two different things to you and me :) But you get the idea. guillom 06:48, 18 October 2009 (UTC)

Guillom, I like your POV here. Having different views (think "Simple", "Standard", "Advanced") is a reasonable way to go. My concern is mainly the elimination of the invitation to edit. As long as it's clear to users that they can edit, be bold, et cetera, I am quite happy. I'd like a simple mode too, but the key distinction is between simplification and obfuscation. I am fine if people get a reading mode as long as that reading mode does not distance them from the editing mode! I think I'm going to mock up a few ideas on how it could work, and play with hiding the sidebar. Those would be some of the key changes. Nihiltres 19:17, 18 October 2009 (UTC)

I took a few minutes and coded up a really basic implementation of a script to hide the sidebar. It doesn't use fancy sliding animations like the toolbar, or anything, but it does give extra space for reading or editing. Ideally, this sort of thing would be implemented through the software, but as is JavaScript is great for live comparison mockups. Look in the mess that is w:en:User:Nihiltres/vector.js, at the bottom, to find the script. It's really simple; crude, even, but effective. Didn't need to think much about it past looking for what needed to move how far. Nihiltres 21:19, 18 October 2009 (UTC)

I couldn't get it to work. It does nothing for me. -- JovanCormac 08:43, 24 October 2009 (UTC)

Are you using Internet Explorer? I know that it won't work in Internet Explorer (tested with IE8) as written, (no idea why :/ ) though it works perfectly for me in Safari on Mac OS and Firefox on both Mac OS and Windows. Note that you have to select the "Toggle sidebar" option in the Vector drop-down menu even when it does work—I'd like to add some sort of cookie-based setup for the setting to be remembered, but I don't know quite enough JavaScript to do that, yet. Nihiltres 18:55, 24 October 2009 (UTC)

Addendum: noting this revision, you have to include the earlier-defined functions expandSideBar() and collapseSideBar(). That might also cause the failure of the script, since that code in your vector.js page will produce a button that does nothing. Nihiltres 19:04, 24 October 2009 (UTC)