Talk:Prototype/Archive 1

Comments

Please try and be constructive, but positive and negative comments are welcome.

• I think using a deeper blue colour for the ""page" and "discussion" button can make wiki more professional
• I think the search engine should be moved to left side bar,because this is important tool for navigation and has existed in long time ago. That is not user-friendly when the search engine move to the top on which we are used to find buttons to modify the entries,view the history,disscuss and read.However,the new skin is so nice and simple i feel,that is good.--59.149.180.91 00:12, 19 August 2009 (UTC)
• Way too much empty space at the top. There's too much of a gap between account information in the top right and the tabs/search. 72.78.180.166 19:22, 28 May 2009 (UTC)

Seconded: too much empty space at top. Screen space is always scarce, especially with browser toolbars eating chunks of it away (and many users would not know how to disable toolsbars). 82.171.96.212 00:55, 3 June 2009 (UTC)

Agree. Too much empty space at top between account info and toolbar. I'm using Firefox 3.0 on Ubuntu 9.04. Probably two much space between menu sections on the left-hand menu pane too. The rest of the beta is shaping up nicely. 146.155.21.158 19:15, 11 September 2009 (UTC)

• Right now, the headers on the left (eg "Interaction," "Toolbox") look like they are a part of the list above them because of the coloring. You may try colouring the boxes of the same items (header + list) as one box. 63.245.220.241 20:03, 28 May 2009 (UTC)
• The new skin looks very nice. Clearly separating article/discussion + read/edit/histor is great. But I find the left menu very hard to read. There is no information hierarchy, it's hard to see at the first look if something should be given more importance than something else. Of course defining a global information hierarchy, valid for all users, sounds difficult to do. But displaying all the items with the same style/size just makes this menu a long list that you dont even try to read. (NicDumZ) 136.187.37.189 06:03, 9 June 2009 (UTC)
• I'm not a specialist of MediaWiki, nor Wikipedia, but one thing I find annoying is the use of SansSerif fonts for the core text. On long texts, this makes eyestrain. I think for the content part, a Serif font family should be used. Richard Gill 19:53, 16 June 2009 (UTC)
  • The problem with font families is that they do not all support "other" languages well. Changing the font family will break our support for languages like Lingala.

Thanks, GerardM 06:55, 17 June 2009 (UTC)

• Why is no french version of prototype ? Otherwise what you have done is pretty nice -- Merimac ^{¿Chat with me…?¶} 17:11, 22 June 2009 (UTC)
• Great job! Do you know when this will be released? Miranda 03:30, 30 June 2009 (UTC)
• I love the toolbar, especially how there's a little "help" dropdown with a tip/cheatsheet About the vector skin, though, I don't like how the admin tools are hidden under that carrot – it makes it difficult for admins to do actions very quickly (especially ones that are done in quick succession)... but maybe that's the point :-) (it's mostly an (new) editor skin)? Cbrown1023 talk 21:17, 7 July 2009 (UTC)
• What we need is WYSIWYG type of editing expirience. Otherwise Google Docs will become predominant wiki-like colaboration tool.... simple is good!

Changes?

I see that the pototypes have the new Vector skin as the default and use MediaWiki 1.16alpha, but are there any other differences? --Michaeldsuarez 20:45, 28 May 2009 (UTC)

We are aiming to make the prototypes as similar to the software and configurations of the actual Wikipedia projects (as they will be upon deployment that is, which is why we are using 1.16). If there's a difference between them, we are either working on it or have not identified it yet, in which case you are welcome to discover such distinctions and let us know if you have some time. --Trevor Parscal 20:58, 28 May 2009 (UTC)

Missing smart ideas for new skin

In my opinion the prototype has just some cosmetically changes regarding to the current monobook skin. Until now I can't see any big improvements or overwhelming smart ideas. There are still too many confusing links in the sidebar. Why don't you investigate in three or four main sections (like for example in this mock up that considered the site map of the German Wikipedia)? In the German Wikipedia a site map with three main sites for a much easier navigation already exists. The problem is that until know the structure cannot bee seen in the sidebar.
Furthermore it is essential that links with the same "task" are arranged for Wikipedia user groups (readers, editors, admins,...). For example "Printable version", "Permanent link", "Cite this page", "Create book" should be put together to a certain area for readers.
Moreover certain areas should have clear objectives. For example: sidebar -> navigation on Wikipedia-site (articles, portals, about Wikipedia, help,...); area above article -> editing and further details on current article.
I hope that it will be more investigated in clear structures on Wikipedia. In my point of view it's essential that there are as little links as possible for navigation and editing. The challenge to fulfill this task is a very smart creation of groups that guide Wikipedia users to the site or function that they are looking for. --86.32.14.79 11:54, 31 May 2009 (UTC)

Thanks so much for your feedback. We could not agree with you more about a new structure and categorization of the navigation links in the left sidebar. We would love to address all of the issues at once, but we are taking them on one by one. Definitely check back in over the next few months as we hopefully get to addressing the left navigation. --Parul Vora 22:41, 30 June 2009 (UTC)

Different icon for thumbnails

Currently, we have this icon as symbol for "click here to enlarge the picture". In a discussion at commons-l where this and other posts were written, it was said, that we might need a better icon for this. I guess this project could be the right place to do it. --Flominator 13:53, 1 June 2009 (UTC)

Some concerns

1. Drop-down menus do not work on mobile devices like my iPod Touch, which do not have the "hover" feature. This greatly impairs usability on mobile devices. While I realize that there's technically a mobile site, one can't edit from it yet. I commented on this (among other things) back when the new skin was only a mock-up, but didn't hear anything back.
   • Why is the "New section" link for discussion pages hidden in the action menu?
2. The scripted addition of the note to view the mobile version breaks in an ugly way on a mobile browser.
3. When a page for a tab (e.g. a talk page) doesn't exist, the blue gradient of an inactive tab clashes with the red of a redlink. (purely aesthetic, but still a consideration)
4. Can advanced users easily customize the tabs and drop-down menu items?

Thanks, Nihiltres 04:52, 3 June 2009 (UTC)

From Scratch?

I have a small question,,, why is the beta an empty project and not just connected to the actual wikipedia database,, (or at least an old stable version) that people can just work on it instead of doing everything from scratch??

I assume that should lead to faster testing results, and we'll be able to start measuring differences we'll have when moving the actual thing into the new version from now... Koraiem 12:08, 3 June 2009 (UTC)

We're busy importing content into the prototypes right now; the English and Arabic prototypes already have a lot of content imported. --Catrope 16:54, 5 June 2009 (UTC)

Add the ability to customize the buttons easily

The new Vector skin is visually appealing. But I'm forced to agree with the writer above that the changes from the present monobook skin are mainly cosmetic. That would fine if cosmetics were the main factor preventing usability. However, my impression is that this skin will not enhance the usability dramatically. Such incremental improvements are disappointing given the number of people working on this project.

I agree with the goal of eliminating clutter and restricting the buttons to the minimum needed for the beginner. Speaking as someone who's edited Wikipedia for years, including Featured Articles, I've never used most of the buttons in the lefthand column of Wikipedia. However, the buttons I choose to ignore – such as "Recent changes" and "Random page" – may well be essential for other users. Have you taken statistics on how often these buttons are clicked by recently registered users? I recommend that you make the portlets in the left-hand column customizable, so that each user can decide what functionality to include in them. Newcomers might be given a small standard set of, say, 7 buttons, e.g., "Help", "Main Page", "About Wikipedia", "Community portal", "Upload file", "PDF version", and eventually the "Create a book" portlet.

The same is true for the 23 buttons at the top of the editing box. Have you taken statistics to see how often they're used? My impression is that most editors don't use them. The XEB extension allows you to customize these buttons and to add forms for the more complicated tasks, such as inline citations; see, e.g., en:User:MarkS/extraeditbuttons.js. Again, I encourage you to make it easier to customize these buttons, and to give newcomers the bare minimum, e.g., "New section", "New subsection", "Add wikilink", "Add external link" , "Add file", "Add inline reference" and possible "Re-use existing reference". A form that connects Diberri's tool with the inline citation creator would be excellent.

You might consider collapsing the interwiki links into a drop-down menu, and also offering the ability to translate them into English on the English Wikipedia, and likewise on the others. I wrote a rudimentary script to do the latter task, which you're welcome to borrow from.

Finally, is this the best venue for offering suggestions? Do you even want outside opinions? Proteins 14:42, 8 June 2009 (UTC)

My mockup, want to provide some ideas

Article Wikipedia

History of article Wikipedia

Eliminating clutter on talk page, compare with current Wikipedia talk page

So, after reading through the other posts, I want to give some ideas to improve the usability on Wikipedia. I created some mock-ups that are based on screen shost of the new vector skin. The main focus was on the arranging of the links and toolbars and not the layout (there could be some further improvements by a specialist). The main changes are:

• In the navigation bar on the left, the links were reduced and only the main sections of Wikipedia remain there. When you click on one of the main sections, you can see additional links. For example when you click on browse:
  • > Browse (or even Contents)
    • Portals
    • Random Article
    • Featured Content
    • ....
  • > Community Portal

This will make the structure of Wikipedia more clearly and will also show new users the full range of possibilities on Wikipedia.

• Another perhaps good feature would be an individual toolbox ("My toolbox") in the lefthand sidebar. Some links like "Upload file", "Recent Changes" are in the default settings but everything can be customized by the user. It would be nice if there would be an easy way to edit them and also the possibility to add also external links (toolserver, etc.). An option to choose default links for readers and another one for writers or admins would be great.
• The area above the article gives additional information of the related article itself and show further actions (Read, Edit, History). To show that there are two different sites (article and discussion) on each page there are two tabs to switch between them. Furthermore some useful functions like print or cite are grouped together (perhaps "create pdf" could be added there).
• Nearly no one of my friends (all of them use Wikipedia) don't know that each site can be in different categories. It's quite useful to browse within categories because you can easily find related articles. Therefore I put them also on the top of the article.
• In my opinion adding the other languages to the top of the article completes this section quiet good.
• As I know there are some functions or icons (sighted version, geographical coordinates, excellent articles,...) that also needs an area above the article. I'm not sure which one of them should be hiden in the area that is usually invisible and can be displayed when you click on the big "more arrow". But I think a good arrangement can be found to make everybody happy.

I hope that my ideas can help you a bit and I would be very glad when some of them will be implemented. --Eneas 14:09, 9 June 2009 (UTC)

Excellent work! I really like the second line under the "Article" and "Discussion" tabs, where you list "read", "edit",..., "Other languages". The Category listing may not be clear to newcomers, however. Perhaps preface them with a boldface heading Categories? That could be a drop-down menu as well. Proteins 12:10, 10 June 2009 (UTC)

A few other minor suggestions. I'd put the Search box just below the logo in the lefthand column, followed by the links "Help", "Browse", etc. I'd move the Signpost from the Toolbox to underneath Community Portal. Speaking for myself, I'd also eliminate "Special pages" and "Recent changes" as default buttons, since I believe they're not that important for newcomers, especially on a wiki the size of the English Wikipedia. Perhaps each Wiki can choose its own set of default newcomer buttons? Proteins 12:15, 10 June 2009 (UTC)

BTW, the Talk and History pages are great, too. I like what you did with the header templates on the Talk page. The "More" element on the article and history pages confused me, however; what does it do? Proteins 12:19, 10 June 2009 (UTC)

Article Wikipedia with some minor changes regarding to first mock-up above

Thank you for your comments. I agree with you that the category listing could be a bit unclear but I didn't want to put a heading there. The thing is that in my opinion the category names are more useful than a heading with a pull down menu. However, my idea was to point out some possibilities in arranging things and not to provide a "final draft". As you have already mentioned, just a few links are used regularly by newcomers and perhaps also by people who edited Wikipedia for years. So it has to be found out what links are important and put those links to the correct places. All other links could be hidden in drop-down menus like the "big more-arrow" in the second line under the "Article" and "Discussion" tabs.

After I created the mockups I was asking myself if the links in the the "new second navigation line" shouldn't be arranged on other pages. For example, when we look at the discussion page we can see the "To do list for Wikipedia, Wikiprojects,..." in the extended area of the second line. Perhaps those links are more useful in the extendable "More-area" of the article page and should be put there. Also the page statistics from the "History" page could be put in the mentioned box of the article page. Furthermore it would be possible to put in there links to related help pages. Besides this we have to think about the placement of the icons of sighted versions, excellent articles, geographical coordinates, protected pages and so on. The area above the article pages shouldn't be overloaded as well. As you can see the "more-boxes" open a wide range of possibilities. However, it's very important that the arrangement of those links is very clear, structured and also well-thought-out. On the other hand too much information decrease usability and is contra productive. --Eneas 17:29, 10 June 2009 (UTC)

BTW, just uploaded another mock-up that considered some of your ideas. --Eneas 19:14, 10 June 2009 (UTC)

Hello, Enea. Your suggestions are well thought of and it is great to see them in mock-ups. Both Vector and the new toolbar are still evolving, so I would love to incorporate ideas in the future design. Thanks again for the great design suggestions and mock-ups. --Shuhari 21:12, 12 June 2009 (UTC)

@ Enea: I love you Idea! Thanks a lot for this very well outview, on what is possible at wikipedia. The current Prototyp Design looks very nice, but i don´t think that it is helpfull to increase the usability level for new users. In my opinion, that are only cosmetic changes. Thanks, --91.115.90.244 15:12, 14 June 2009 (UTC)

This is really great. (agreed with the anon above that it is far more than cosmetic, which is nice). What about the interlanguage links? Those are also extremely important and often overlooked. Sj 05:59, 21 July 2009 (UTC)

The interlanguage links are arranged on the right beneath the search button. When the focus of these links should be raised it would be better to place them next to the categories. --Eneas 16:35, 21 July 2009 (UTC)

Userfriendliness in Editing is Key

Hello,

I never edited wikipedia but I installed a wikimedia wiki to assess it as a note taking tool and collaborative work at work and at home.

I came to the conclusion, which seems to be shared even by some among you to a certain extent, that wikimedia due to its lack of userfriendliness could not be used professionnally in the current state because editing required a significant knowledge of html (or its wikimedia subset) which can not be considered as largely widespread or be part of what some has named digital literacy.

It thus required learning it, and of course if we want wikimedia to be used by anyone even for taking notes, this is learning something not related to their main business and they may not have time for that.

This is why, even though I was enthused by its collaborative capability I felt it was impossible to ask people at my job to edit a wiki like they would do for a word processor document, it is already not easy to ask people to take time to document what they do, with the current userfriendliness of wikimedia, and the additionnal time required to edit, they would have drop out documenting.

To be shared widely, I think wikimedia editing should be made as simple as word processors (which use is definitely part of digital literacy) and also featurewise rich enough.

I think among the mandatory userfriendliness features it should be possible simply to :

• choose the color of the text
• choose the font
• choose the size
• introduce the possibility to outline with several colors
• offer the possibility of foot notes
• offer the possibility of comments

all that in a simple maneer (agnostic to html)

I don't know if all that is already included in the scope of your project but I think it is very important for people using widely wikimedia in their home or professionnal projects and therefore be sufficiently familiar with the edition possibilities that they feel no obstacle to one day editing wikipedia when they feel they can contribute.

When I saw the news of this initiative I welcomed it very much, please make it really user friendly this is key (think of the market share taken by the iphone even with a very late release date compared to other phones, it mainly amounts to its user friendliness and ease of use... think about it).

I read that important amount of money was dedicated to this excellent initiative. I think this is annother reason to reach for a real ease of use in order to maximize the impact of this investment and also because in general this kind of opportunity does not come twice.

We support you in this well inspired initiative it is an opportunity to make the needed and decisive difference !

Hoi, the key thing with every new application is that you appreciate what the application is about. Given that MediaWiki, the name of the software, is intended for collaborative editing, you have to look at what it is that you need as such. Several of the comments that you make are a bit bewildering. It is ok that you have to learn about what it is that the software does, MediaWiki is not a text processor, expecting all the attributes of a modern text processor may give the impression that it is a text processor.

It is possible to have different text sizes et al in Wikipedia. However it is not used that often because you are looking for a consistent look and feel. The point, MediaWiki is used professionally and teaching what is special about the software is important. This usability initiative should make many things more intuitive but it should not take away the notion that this is not text processing. Thanks, GerardM 11:45, 15 June 2009 (UTC)

Comments and a suggestion

After using the English prototype site, I'm very impressed. I'm glad we're finally moving away from the put-everything-in-a-box design. I also think the new editing interface is a nice improvement (without being too radical). The only thing that threw me off was I couldn't immediately figure out what the icons for the bold and italic functions were for (those 3-D embossed lowercase 'a's) Perhaps they are a bit too fancy. I would prefer the standard bold and italic icons used by WordPress, TinyMCE, etc. They are much easier to recognize. Kaldari 21:24, 15 June 2009 (UTC)

I also think that the icons are not chosen very well. I would use something like [1] for reference, too. Also, it is important for the toolbar to remain customizable. The integrated help OTOH is great; maybe it could even include an equally terse summary of policies? And the context-dependent signature link was a much needed addition. Just don't forget to enable it for the project namespace. --Tgr 15:43, 16 June 2009 (UTC)

Copyvio

Hello,

the prototype contains copyrigt violations. For example the article EU-Parliament is a copy of the German article without a list of authors or anything else. Its a pity that even we don't respect our own licence and policy. --77.0.37.63 10:51, 21 June 2009 (UTC)

This wiki is for testing purposes only, and is rather confidential because there are very few readers. So on my opinion, copyright is not a priority here. Please do not disturb the developers for such copyright details, which are not the purpose of this usability initiative. Try to provide feedback about usability instead. Thanks. :-) Dodoïste 17:30, 21 June 2009 (UTC)

Yeah, I always knew even Wikimedia doesn't care about the licence. As if it would be soooo complicated to properly import the articles, but how cares. --77.0.47.31 18:58, 22 June 2009 (UTC)

:-) Maybe they could simply add: "The authors can be found at http://en.wikipedia.orge/wiki/{{PAGENAME}}" in MediaWiki:Copyright ? Dodoïste 20:17, 22 June 2009 (UTC)

More suggestions for consideration

Hi, good work, thanks for making those changes in the edit-window buttons so quickly! I like the drop-down menus especially.

More suggestions on the edit-window buttons: You have "Lists" and "section headings" listed under "Formatting buttons", which is not intuitive to me and, I suspect, to others. You may want to put those under a separate heading. You also forgot to include one type of Mediawiki list: the discursive list ; and :, corresponding to <DL>, <DT> and <DD> tags in HTML.

A related problem that comes up for visually-impaired Wikimedians is that most other editors aren't careful about where they put the spaces between the list elements, effectively breaking one list into lots of one-element lists. The many lists makes it very hard to follow with a screen reader - try it yourself! That's especially annoying when you go to discussions with >8 participants, e.g., FAC on the English Wikipedia, where they use colons (discursive lists) for indentations. Could you make it so that editors have to do more work to create a separate list? I know it's not directly related to your mandate but accessibility to the blind is part of usability, right? You might want to consult User:Graham87 on the English Wikipedia, or look over the scripts he asked me to write to make his editing easier.

From the second Commons video on usability, I noticed that the infoboxes, inline references, templates, etc. in the edit window were especially daunting to new users. A wall of weird text! A wall from which you can hardly pick out the article's prose. I recommend that, when a typical user opens the edit window, those elements be collapsed into show/hide buttons labeled "Ref1", "Infobox", etc. Making them hidden by default means less clutter for the average new editor, but anyone who wishes to edit those elements can click on them to show them and then edit them. Alternatively, you could make them different colors, as done by the Gadget wikEd, but I think the show/hide approach is much better, because it makes the edit-window version of the article closer to the normal article.

Let me just push again to reduce the number of buttons, particularly in the left-hand column, but allow users to add/subtract/move buttons to suit their own needs. I believe that the present LH-column clutter is confusing and distracting, and also that most of those buttons are little used by most Wikipedians for most of their lifetime on Wikipedia. Again, drop-down menus for the interwiki links and categories, as described above, would be a win.

Perhaps this is asking too much, but your "ref" edit button doesn't distinguish between inline citations (<ref>) and footnotes (<ref group="note">, for example). Both are important elements of the best articles. You also might want to make it standard to give names to inline citations (<ref name="Smith_1979">), so that they can be re-used easily. I'd love to have the option of a fill-in form like the one used in the XEB extension, especially if it links to something like Diberri's tool. The latter would be a tremendous help for scientists who would like to add inline citations to their articles but don't have a lot of free time to edit. Speaking from experience, adding 150 inline citation templates can be half the time I spend in bringing an article up to Featured-Article class. Make that one task more efficient and you make the whole FA process more efficient. Think about it.

Hoping that these suggestions are helpful, and keep up the good work, Proteins 13:25, 24 June 2009 (UTC)

Still more suggestions on the edit-button bar

Hi,

After playing some more with the prototype, a few more ideas occurred to me.

• The Help ("cheatsheet") dropdown menu is great, but again you left off the discursive list (; and :). Perhaps you should at least mention indentation with the colon, since it's so common on Wikimedia projects? Practically every section of every Talk page has them on the English Wikipedia.

• Again under the Help menu, I notice that you don't include ALT text in your example of a Figure caption. I understand that that's simpler for newcomers, but it's disappointing that we don't encourage accessibility for the visually impaired.

• The Heading dropdown menu is likewise great, except that Level 1 shouldn't be listed, since it messes up the Table of Contents (see en:User:Proteins/MoS_Nightmare for an illustration). The levels might be more intuitive for newcomers if the dropdown menu showed the levels more as they might appear in the article, e.g., with larger bolder fonts for the higher levels. (See the "What you get" column of the "Headings" section of the Help dropdown menu.) Bonus points: you should never allow the user to add a heading level that is more than one level lower than the present level, e.g., you shouldn't allow the user to add a H4 heading in the middle of an H2 section. That's a barrier to accessibility for the visually impaired and a major headache for the Manual of Style.

• I would demote the boldface and italics edit buttons to the "Formatting" dropdown menu. That seems like the most natural grouping. For another thing, these two typefaces are not used that often in Wikipedia articles. Boldface is usually used once per article, in repeating the article title in the first sentence of the lead. Unless the article is being created from scratch, that sentence has usually been written already; therefore, most editors in most situations will never need the boldface button. The most common use of italics is in the inline citations (journal names), which are handled already by the citation templates. Thus, it's relatively rare that editors need to introduce italics.

• Perhaps also under Formatting, you might add something for striking out text? That's also common practice on Wikipedia; for example, at FAC, one strikes objections as they are met by the nominator of the article.

• Again, I would promote the "Headings" dropdown menu to the first (leftmost) position on the edit-button bar. I would discourage the use of external links by putting that one last. Lists seem less important than references (at least on Wikipedia) so you might put the three types of lists under the "Insert" dropdown menu.

Hoping these new suggestions are helpful, Proteins 18:27, 24 June 2009 (UTC)

Upper gradient

I like the new design, js help in edit mode is great idea. I however don't particularly like the upper part of the skin. There is (at least for me in FF3) too much space above the navigation tabs, and gradient that fades to white far before the top of the page does not look very well. Goran Obradovic. -- 147.91.1.42 07:59, 26 June 2009 (UTC)

the gradient in general distracts me from the buttons and text. And the turquoise color of the buttons, far more than the color of the separating lines, doesn't look good on my laptop with ff. Sj 05:57, 21 July 2009 (UTC)

Problem with the headings and lists

When you select the text == Foo == and then select level three from the headings dropdown, you get ===== Foo ===== instead of the expected === Foo ===. The effect of the list buttons on multi-line selections is also not what one would expect. --Tgr 08:00, 26 June 2009 (UTC)

Treatment of "Headings" in editbox buttons

Thanks for making those changes, but I'm not sure that "Advanced" is descriptive enough?

My main suggestion, though, is to promote the Headings dropdown menu to the main line, say next to the add image button. Also, as suggested above, you should remove the Level 1 option, or at least add safeguards. Proteins 15:58, 27 June 2009 (UTC)

Footer and alerts

div#foot with license and copyright info looks much better with monobook skin. See http://www.picamatic.com/show/2009/06/27/08/39/4149639_1280x275.png for real MediaWiki site.

Also, EditWarning alerts (like any other javascript alert) are very annoying and should not be used by default. --85.141.235.251 16:50, 27 June 2009 (UTC)

LaTeX next to Special Characters

Hi,
like the Special Characters Menu, there should be a similar menu for Math/LaTeX markup as used by texvc and BlahTex. The supported LaTeX commands should be grouped by their use ("greek symbols", "arrows", "integrals", etc.).

See Help:Displaying a formula for a reference of commands.

— MovGP0 21:43, 30 June 2009 (UTC)

Line breaks

For complex (multiline) inserts like gallery or table implicit line breaks can help to recognize easily what has been inserted with one click. After all manually inserted galeries or tables markup seldom flow inline with other text. Erik Zachte 03:39, 2 July 2009 (UTC)

 The following candy bars have a good taste to price ratio. <gallery>
 File:Example.jpg|Caption1
 File:Example.jpg|Caption2
 </gallery>Of these the following also have a high tooth decay factor. {| class="wikitable" border="1"
 |-
 ! header 1
 ! header 2
 ! header 3
 |-
 | row 1, cell 1
 | row 1, cell 2
 | row 1, cell 3
 |-
 | row 2, cell 1
 | row 2, cell 2
 | row 2, cell 3
 |}Consume at own risk.
 

Better

 The following candy bars have a good taste to price ratio. 
 <gallery>
 File:Example.jpg|Caption1
 File:Example.jpg|Caption2
 </gallery>
 Of these the following also have a high tooth decay factor. 
 {| class="wikitable" border="1"
 |-
 ! header 1
 ! header 2
 ! header 3
 |-
 | row 1, cell 1
 | row 1, cell 2
 | row 1, cell 3
 |-
 | row 2, cell 1
 | row 2, cell 2
 | row 2, cell 3
 |}
 Consume at own risk.
 

A simple yet powerful way to increase intuitiveness. --Shuhari 06:44, 2 July 2009 (UTC)

Vector and toolbar impressions

• From @huntster1701 on Twitter: "I don't see anything about Vector that I actually like. Sidebar font too big, all scripts appear broken. Monobook for me."

• My view: Obviously the functionality issues are bugs (I filed a bug report about problems with show/hide templates), but in terms of look and feel, my biggest complaint is link color. I prefer more contrast between visited and unvisited links, which I think monobook does well. The tabs and sidebar I think I could get used to, and might come to prefer.

• The editing toolbar looks good in terms of style; it's an instant relief from the standard eyesore version. I think the meaning of the bold and italic buttons might not be very clear to many users; it would make more sense to me if it used a b for bold and an i for italic, rather than two a's. The signature icon is too small to make sense of; I would never figure it out without reading the mouse-over text or just by process of elimination.--71.235.240.19 05:02, 2 July 2009 (UTC)

I cannot reproduce show/hide template function on my FF3/Ubuntu9.04. Will keep looking into it. --Shuhari 06:46, 2 July 2009 (UTC)