Difference between revisions of "Talk:Prototype"

From Wikimedia Usability Initiative
Jump to: navigation, search
(Location of the search box: new section)
(What do you think of the beta enhancements?: comment)
Line 254: Line 254:
== What do you think of the beta enhancements? ==
== What do you think of the beta enhancements? ==
How do the beta enhancements work for you? [http://techblog.wikimedia.org/2009/10/usability-beta-enhancements/ Tech Blog Post] --[[User:Shuhari|Shuhari]] 01:32, 27 October 2009 (UTC)
How do the beta enhancements work for you? [http://techblog.wikimedia.org/2009/10/usability-beta-enhancements/ Tech Blog Post] --[[User:Shuhari|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. [[User:Nihiltres|Nihiltres]] 23:06, 27 October 2009 (UTC)
== Location of the search box ==
== Location of the search box ==

Revision as of 23:06, 27 October 2009

Prototype discussion

Accessories-text-editor.svg Please be specific about which wiki, language preference, browser and operating system you are using when reporting bugs. Ideally bugs should be reported using the Wikimedia Foundation's bug tracking tool.
Internet-group-chat.svg This is a general page to discuss the Vector skin and the Beta project.
Edit-undo.svg To discuss the current icons, go here. To talk about the current toolbar, go here.
Applications-development.svg You can find the current list of open bugs for our project on bugzilla here.


Ideas list (add your own!)

  1. Syntax highlighting similar to WikiEd.[1] - Archived discussion 1 - Archived discussion 2 - SourceForge project with live demonstration
  2. Collapsible references similar to WikiEd.[2][3]
  3. Simplify edit page warnings. Mockup
  4. Template selector. Discussion and mockup
  5. "Edit saved" message. Discussion and mockup
  6. Document-sharing services such as Google Docs.
  7. Easier navigation Discussion and mockup
  8. Interwiki links. Discussion and mockup
  9. Login-area constantly available at the top (like ubuntuusers; practical for Secure Login. what dedects it automatically
  10. Nice image galleries like the Lightbox
  11. Change photo edit facility, which is easy to use
  12. Fixed positioning for Nav / Search Box - so it's always on the page as you scroll - Talk:Prototype/Archive 8#Search Box / Navigation - why not try fixed positioning?, link to my custom prototype css
  13. Leave wiki exactly as it was - it was obviously successful - why change it?
  14. How about adding a "shake" for random feature for iPhones!
  15. The cursor should already be in the search box when you access Wikipedia as well as stay in there while reading articles. This would be much more comfortable and user-friendly!
  16. Bookmark articles without adding to watch-list - for favourites and research subjects, with personal folders or tags. Essential for the heavy reader, such as myself.


Archive 1 Archive 2 Archive 3
Archive 4 Archive 5 Archive 6
Archive 7 Archive 8 Archive 9

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. 22:43, 10 September 2009 (UTC)
Hear hear! 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. 18:23, 19 September 2009 (UTC)
Support for change. 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)

Alignment in galleries

Here is an example:

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)

"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

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. 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. -- 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. 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). 01:46, 17 September 2009 (UTC) (user:Bawolff)

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)


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)

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. 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). 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.[4] One feature is syntax highlighting which makes it easier when sorting through the article, and another is to collapse the references like so.[5][6] Another idea would be the new refs= feature. For example you could name your references and have them all at the bottom now.[7] 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.[8] 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. 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


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. 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. 15:29, 22 September 2009 (UTC) en:User:Zyxoas


the slideshow is not functioning! -- 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?

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:

Mockup Reading Mode.png

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)

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


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


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

Capturer accès au clavier en.PNG

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)

Feature missing in the link dialog

Feature missing in link dialog.PNG

Hello. 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)

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)

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). 20:43, 20 October 2009 (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)

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"?

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)