Feedback Goes Here

Tabbed Naviation and new Mock-up

I like the idea using tabs for navigation. However, there is one big fault on how they are arranged. The tabs "Page" and "Discussion" are on the same hierachy level. "Read", "Edit" and "View History" are one level below. What I mean is that the site discussion can be split up in "read", "edit" and "view history" as well as the site "page". So in my opinion the three 2nd level tabs should also be arranged beneath Page and discussion like in this mockup. The current solution that the used tabs are higlighted (e.g. Discussion and edit) is a rotten compromise and not very userfriendly because the real structure remains unclear. -- Eneas 08:11, 26 July 2009 (UTC)[reply]

Mockup of Babaco design eliminating some major usability problems in navigation

Just created a mockup based on the new babaco design. The main changes are (see also initial discussion):

Easy navigation on the left (pull down menu for each section)
User defineable toolbox in the sidebar on the left
Grouped actions that belong together:

on the top of the pages just actions that belong to the current page
in the left sidebar the navigation to other sites in wikipedia

Categories replaced from the bottom to the top
Other languages replaced from the sidebar to the top

--Eneas 12:57, 25 July 2009 (UTC)[reply]

Try moving the user links down for a little more room, and removing the print icon. HereToHelp 03:13, 10 August 2009 (UTC)[reply]

We kinda had the same discussion in the German Wikipedia some month ago. After this I developed this redesign that also uses tabs with submenus. Because it makes so much more sense. There are also a lot more ideas in this redesign how to clean up the site and make it more logical. All these can be found in this pdf (sorry had no time to transfer it the a wiki-site yet). Feel free to post them here and use my design ideas. --Christoph Knoth 22:47, 31 August 2009 (UTC)[reply]

Thank you Christoph for posting your view regarding the usability problems of Wikipedia. I agree definitely. Hope the usability team is going to consider these issues. Until now they haven't posted any comments on these topics. --Eneas 19:54, 1 September 2009 (UTC)[reply]

Toolbar Upgrades: Icons

The 3 points listed under "Approach" seem a bit schizophrenic:

Adapting Gnome-Icons
Monochrome and simple style
Gentle shiny style

These seem like 3 divergent approaches to me. "Monochrome and simple" is what we already have. "Adapting Gnome-Icons" is what was done in Acai. "Gentle shiny style" seems like something totally different from the other two. Personally, I think we should shoot for icons similar to the TinyMCE icons: http://tinymce.moxiecode.com/examples/full.php. Simple, recognizable, and attractive. The gnome icons often fit the bill, but occasionally are too fancy IMO. Colors are useful, so I don't know why we would want to restrict ourselves to monochrome. "Shiny"? Isn't that a bit 1998? Anyway, don't mean to sound too critical. You guys are doing a great job so far. FWIW, I used to be a designer for a web app company, so let me know if I can help. Kaldari 19:37, 30 July 2009 (UTC)[reply]

Those TinyMCE icons look to have been ripped straight from Microsoft, there could be copyright concerns. I think the proposed icons are very nice and professional looking. The wub 12:50, 4 August 2009 (UTC)[reply]

Sure they look good, but are they usable? Many of them don't seem very recognizable to me. The table icon, for example, looks more like a calculator. I didn't say we had to use the TinyMCE icons. I just said we should shoot for icons that were similar. I think adapting the Gnome icons was a good first step. I don't see why we need to abandon that work in favor of using a totally new set of shiny monochrome icons. Kaldari 18:32, 4 August 2009 (UTC)[reply]

Reverse video please

I and many other people (as witnessed by the green-on-black Monobook gadget) prefer green text on a black background in low light conditions, but with links white instead of blue (red is fine in reverse video.) Please make sure there is a corresponding gadget for Vector if at all possible and Babaco. If you can't find usability subjects willing to volunteer in the dark, please, think of the astronomers. Thank you. 99.22.93.63 17:48, 1 August 2009 (UTC)[reply]

I think that once we have icons and layout done, swapping colors (considering how tight colors are controlled) shouldn't be too hard. HereToHelp 03:15, 10 August 2009 (UTC)[reply]

Watch page

I use the watch feature extensively, and feel the current Babaco design is inferior in one aspect.

The watch page selection is no longer visible without a mouseover on the down arrow. This is fine for the not heavily-used selector, but having an indication of whether the page is watched or not is useful to me. It would be good to have a visible status message (maybe an icon, or text) saying that the page is watched. The current mechanism could be left for selecting watch and unwatch, but i don't like to have to do an extra mouseover to see if a page is watched or not.

Looks good otherwise, though! Cheers, —Fudoreaper 21:50, 3 August 2009 (UTC)[reply]

Thanks Fudoreaper. You are not alone - in the latest beta, we have made the watch/unwatch visible again in the tabs (as a star). --Parul Vora 01:03, 24 November 2009 (UTC)[reply]

[edit] links and [show] links - right vs left

Hi. I've always been slightly confused/irritated by the way we put both the subsection [edit] links on the right, and the [show] links in templates on the right. I hypothesize that this leads to readers not noticing the [show] links, and thereby missing all that material.

I tried to summarize it (plus the related details) at en:Template talk:Navbox/Archive 8#Why is View Discuss Edit on the left, instead of the right? in June 2008, but I don't think I was understood. Perhaps the usability team might understand what I was getting at?

(Feel free to move this thread, if there is a more appropriate location for this idea/concern. Thanks.) Quiddity 18:38, 4 August 2009 (UTC)[reply]

I agree. The usability team had some nice thoughts about the edit button on the Acai designs, but those improvements were not included in the release. I wonder why ? I do believe File:Design-SectionEditLinks-2.pdf is a great idea.

Concerning the Navbox, I guess the usability team cannot change it. The [show] button is created in w:Mediawiki:Common.js, and it's content depends on the editors. It doesn't seem to be related to the skin ? However, it would be great to replace the [show] button by the usual icon, have the button near to the title, and move "v d e" to the right.

Capital cities of the Member States of the European Union

v d e

Capital cities of the Member States of the European Union

v d e

Example of content: Amsterdam · Athens · Berlin · Bratislava · Brussels · Bucharest

89.217.199.175 23:06, 6 August 2009 (UTC)[reply]

Exactly! Good ideas, and I'm happy to be understood.

Hopefully this is something within the team's purview - or if they are unable to implement some of the ideas (for whatever reasons, technical to practical), hopefully they can issue a list of "suggested changes" collating them.

Thanks again. Quiddity 00:36, 7 August 2009 (UTC)[reply]

drow shadow

Just an idea, might look nice to have a dropshadow for the actions menu. I like the one this website has on it's blue bar menu for instance. Not sure if it would work, but might be worth to test out. 82.75.218.92 00:14, 6 August 2009 (UTC)[reply]

please rework the toolbox

the current toolbox is inconsistent in so far that it contains site wide links and page specific functions like "what links here" and "related changes", "printable version" and "perma link". Why are these page specific functions on a different location that the page history? history or citation, both are meta information about the same page, they shouldn't be at two different places in the skin. --84.152.126.4 23:38, 6 August 2009 (UTC)[reply]

I agree definitely. See also my mockup on the top of the page --Eneas 10:49, 13 August 2009 (UTC)[reply]

Search and special characters

Sometimes it would be useful to input special characters which aren't on keyboard in searchbox (especialy on Wiktionaries) so it would be useful to have special characters inputbox there as well as it is in edittoolbar. --85.70.157.249 08:42, 9 August 2009 (UTC)[reply]

What users were able to, had trouble to, and often did not know how to

Babaco Designs#Discussion contains the following text :

* Users were not able to easily identify the timeline of discussions

* Users had trouble knowing where to contribute to the discussion

* Users often did not know how to, that they should, or simply forgot

Could we have more details on this survey ? Which users ? In which country ? How many people were they ?

Teofilo 11:38, 17 August 2009 (UTC)[reply]

See here--Juxn 08:46, 23 September 2009 (UTC)[reply]

Discussion pages & freedom

What you propose is perhaps not very different from what has been used for 4 years on the French language Wikipedia, with straight lines separating different people's messages and an alternance of two colours (light yellow and darker yellow) : see fr:Wikipédia:Le Bistro for example.

This design was chosen freely 4 years ago by the French speaking community. However, I don't think this sort of things should be decided and imposed by the Wikimedia Foundation (or by the Stanton Foundation) to all language communities. Please Let wiki communities choose freely to opt in or opt out.

Teofilo 11:57, 17 August 2009 (UTC)[reply]

Thanks Teofilo - all of our features + releases are opt-in only at the moment.

Your opinion that "Messages" (I'd rather call them "warnings") should be collapsible

I think you are missing the point of why warning messages are there in the first place.

Yes the purpose of warning messages is to "distract users from the content", as you put it. Sometimes problems are so serious, that users should be grateful that they have been distracted away from a specific page.

For example, when a page contains a copyright violation warning. For example when the page contains a "non neutral/ article is biased" warning.

If a message is truely useless, the good attitude is to edit the page and remove it.

If a message is here for a useful purpose, the good attitude is

to read it
to solve the issue
to remove it after you have solved the issue.

Making warning messages collapsible somehow promotes a kind of "this is not my business, other people will work on the problem and solve it" way of thinking. But what we want on wikis is that users feel concerned and work on the pages in order to solve problems when problems occur.

You are thinking of users as passive consumers. But users on wikis should be thought as being empowered and responsible.

Teofilo 12:34, 17 August 2009 (UTC)[reply]

Do not worry. This collapsible option will be easy to use, so the reader will be able to decide whether to read the messages or not, as he wishes.

Some readers (or probably many readers) do not want to read too many warnings. They know they are on Wikipedia anyway, so they will be cautious. If they want to read the warnings, they will uncollapse the warnings.

I support the collapsible warnings, the readers will be more at ease with this option. Dodoïste 09:42, 20 August 2009 (UTC)[reply]

Ranking system for message type? & freedom

I would be extremely disappointed if the Wikimedia Foundation imposed its views rather than let language communities choose freely what kind of warning messages they want to use.

On the French Wikipedia, warning messages are divided into 3 ranks ("serious", "moderate", and "information") but this was chosen freely by discussion, consensus, vote : see fr:Wikipédia:Prise de décision/Changement de style des messages d'avertissement.

Teofilo 12:43, 17 August 2009 (UTC)[reply]

A general review

A section by section review (with questions) of the proposed improvements, compiled by {{Nihiltres|talk}} 05:22, 20 August 2009 (UTC) I'll add some more on the "Beyond Babaco" changes later.[reply]

Tabbed navigation

The closed tabs seem good for usability, though the open tabs are prettier, in my humble opinion. (I hope that the open tabs will remain a skin option (or separate skin) with the introduction of the Babaco release…)
The orange "selected" colour in the current tab preview (identified as #E5902E in the palette) does not pass a contrast analysis test. According to an analysis program, it has a contrast ratio of 2.4:1 with the off-white #F9F9F9 (for comparison, the WCAG recommends that large text have at least 4.5:1). For some colour-blind people, the ratio can be even lower. This is not good, especially given that the orange is intended to be a highlight for an active element.
The dark-grey text (#666666) on the blue tabs (#BCE4FC) also does not pass the contrast analysis test. According to the analysis program, it has a contrast ratio of 4.3:1, which is slightly below the suggested value of 4.5. For smaller text, this becomes more of a problem, but this isn't as big a deal as the orange, which even I find hard to focus on in the current mock-up.

Layout

I find this section somewhat unclear. Would you make the explanation more descriptive, please?
I worry that a right-hand navigation bar would sacrifice a lot of screen space. Mightn't it be too wide on small screens, too tall, or require some other modification?
What will this right-hand bar be used for? Is there an idea of a purpose for it yet, or is it merely a spacing design, so far?

Colour scheme

This looks relatively nice and cheery.
Can the number of greys be practically reduced? (Just asking … can it be made simpler without sacrificing some distinction? "No" is a perfectly good answer.)
- Can the meaning of some of the labels be clarified? "Lines" and "Boxes" is very vague.
Contrast checking is generally a good idea, for text-related colours at least. For example, of the grays, only the #373737 "officially" passes a contrast test with the orange #E5902E. Minor adjustments can make a big difference.

Toolbar upgrades

I have nothing to say here; I like what I've seen so far for the buttons, and interactivity and dialogs are great so long as they're compatible with all JavaScript-capable browsers and, well, feasible. I'd love to see something like the FCKeditor eventually, though.

Thank you for your review. Which programm did you use fot the contrast analysis test?--Juxn 19:05, 10 September 2009 (UTC)[reply]

Dialogs for Inserting and Edit Links

I really like the direction that the design is going with one exception: the use of dialog boxes for inserting and/or editing links. Whilst this makes perfect sense in a WYSIWYG environment, the use of dialogs is somewhat intrusive and inconsistent with the way that other formatting options work. Dialogs work well for operations that involve several steps, such as uploading an image file, or the selection of complex options, but the basic linking syntax is sufficiently simple that users pick it up fairly quickly, and the introduction of a dialog box merely adds another level of interaction and complexity that is (IMO) out of place in a wiki. Using the latest dialog, for example, creating a link now takes three clicks instead of one.

Of course, users don't have to use the dialogs, but it is useful to be able to type or copy and paste a section of text and then use the buttons to add the relevant markup around the selected text. This is how most of the other toolbar buttons work and represents a good balance between ease of use and helping novice users to learn how to use wikitext. No doubt many novices would prefer the use of a dialog box since they are unfamiliar with the markup syntax, but I'm concerned that adopting this as the default model for link entry is in danger of sacrificing ease of use for ease of learning. Whilst both are important, I think the toolbar should be optimised for frequent use and efficiency, rather than making it as easy as possible for novices at the cost of adding extra interaction and complexity for everyone else.

I suspect that the best way of making it easier to edit wiki text would be to introduce full WYSIWYG editing, in which case dialogs would be used exclusively for link creation and editing. In the meantime, I think it's best not to mix the two editing models and to stick with the old web link/internal link buttons (although perhaps reversing the order). Another possibility might be to offer both these buttons and an advanced 'link options' dialog which offers drop-down selection of namespaces, category links, sub-pages, headings etc. allowing users to make use of the full range of linking options. However, this would be very much a power-user feature, and not the standard way of adding or editing links, which should be kept as simple and streamlined as possible.

-- Philoscoffee 09:41, 25 August 2009 (UTC)[reply]

Places and actions

I'll start by saying how much better Babaco is than Acai, in every way - I'm really looking forward to it reaching public beta stage and think it will be very well received. I think it is worth considering, regarding the top navigation, whether it would be logical to differentiate actions and places. Hence, Edit not being a visual tab, but a clickable button, whereas "Article" is a place and therefore a tab. w:User:Pretzels

When is the release date for Babaco ?

The Babaco release seems to be extremely userfriendly. I am organising large-scale educational activities with Wikipedia, and I am preparing tutorials to make it easy for teachers. Surely Babaco would make it really easier.

I agree! 18.85.49.46 02:01, 18 September 2009 (UTC)[reply]

Could you tell me the approximate release date for Babaco ? This way I could know if I should wait for the Babaco release to prepare my tutorials, or if I should prepare them with Açai. Thanks. Yours, 160.53.250.111 10:22, 2 September 2009 (UTC)[reply]

Hehe, that's a good question. I actually find Acai a bit less friendly than bog-standard old-MW, but am looking forward to using Babaco in introductions myself. 18.85.49.46 02:01, 18 September 2009 (UTC)[reply]

approximately end of september...hopefully ;)--Juxn 08:47, 23 September 2009 (UTC)[reply]

Thanks for the answer. :-) 160.53.250.113 10:05, 23 September 2009 (UTC)[reply]

Accessibility, W3C and usage of color

Hello. It's about the accessibility of the link dialog box. As explained in W3C's techniques for WCAG 2.0, we must ensure that information conveyed by color differences is also available in text.

When inserting a link, a box appears. In that box, there is a coloured square that indicate wether the article exist (green) or not (orange). This information is not clear for regular users (at first, I was wondering what it meant), and is not accessible for screen readers users. That makes two good reasons to add some text, like " this article exist", or "this article exist". Thanks. 84.227.181.52 19:20, 12 September 2009 (UTC)[reply]

"Messages"

Template messages such as "Orphan", "Expand", "Cleanup", so on are templates on the English Wikipedia, not necessarily a part of the skin. To change these usually you'd go through either the w:WP:VPT or on the template's talk page such as w:Template:Orphan. ChyranandChloe 03:49, 20 September 2009 (UTC)[reply]

Icons

Another proposed set of icons. The bottom row would normally be hidden.

I have posted this image of my ideas for icons on the Opinion Icons page and received minimal response. So I posted it on this project page and they were removed by an anonymous user (who I'm sure is a good-faith user from another wiki, I'm just not sure who). Somewhere, there emerged the idea to use GNOME icons, and that was that. If there was a lengthy community discussion, I missed it, and would appreciate a link to it. If not, I feel that my icons have been unduly dismissed. They are uniform, simple (vector is a very uncluttered skin, GNOME icons have frills), and unique to Wikipedia, giving us our own look and feel. There were created a vector graphics (no relation to the skin name), which means that they can be resized, edited, and localized easily. I am not insisting unilaterally that we use my icons. I am, however, asking for an explanation as for why the GNOME icons are so entrenched. If there is no good reason, I would like to discuss the merits and limits of each set, and for people to realize that an alternative exists. If a community discussion decides in favor of GNOME, that's fine - but to the best of my knowledge no such discussion has occurred. Let's have it now. HereToHelp (talk) 14:46, 23 September 2009 (UTC)[reply]

Please remember this page has been marked with Template:Internal. If you added this set of icons with the approval of the Usability Initiative, I guess that's okay. If not, it is probably not te appropriate place to add it. :-) Yours, 160.53.250.111 15:25, 23 September 2009 (UTC)[reply]

Fair enough, I had no prior "approval". I'm trying to figure out where such approval comes from, that's all. HereToHelp (talk) 15:35, 23 September 2009 (UTC)[reply]

ok - hi again. I am sorry if you got the impression that we unduly dismiss your ideas. By the way: The revert today was from a usabilityteam member, who forgot to log in. The essential problem with your icons is, that some are not comprehensible for new users (because they use wiki-syntax). But this is excactly our mission: We want to improve the editing process for new users. Secondary we decided to use GNOME icon-set - as long as the icons they have are comprehensible - because they are on a good, professional level and opensource. So why reinventing the wheel? --Juxn 18:25, 23 September 2009 (UTC)[reply]

(Disclaimer: Prior conversation.) I think the source of our friendly disagreement lies in the question of who uses the toolbar. In my experience, new editors do not create tables, or redirects, or galleries, or references. They usually don't even italicize text. The proof is in the pudding - almost all anonymous contributions are letters, numbers, spaces, commas, and end-of-sentence punctuation.

I agree that there are difficult concepts to convey graphically, like signatures and links. I agree that we should make editing more intuitive, but I think the new help menu does an excellent job. We also need to consider our established users, to whom r^[1] means reference more than a book does. (And many of our sources are online anyway.) As we've seen elsewhere, customization is an important part of the wiki. So why not offer editors a choice?

If nothing else, I like my icons for their aesthetic appeal. Vector is very careful with its use of color. I think that introducing new colors, drop shadows, 3D letters, and so on from GNOME detracts from the unified feel of the new skin. I'm more than happy to try to render a globe or chain with the style I have used. But even if the default needs to be friendly to new editors (if those editors really use the toolbar), I would like a version more conducive to experienced editors to be available, and for stylistic consistency to be followed. Thank you for your explanation and patience, HereToHelp (talk) 19:25, 23 September 2009 (UTC)[reply]

Babaco - internal links: dialogue box

I have two comments regarding the dialogue box I've tested:

first, when one enters in the dialogue box the link to the article (Tito) and the displayed text (Tito3), the software should create the link [[Tito]]3, not [[Tito|Tito3]].

there should be a possibily to turn off the dialogue box. --193.2.99.14 11:57, 29 September 2009 (UTC)[reply]

Navigable TOC when reading

I love those new features.

Still, I wish there was a TOC on the right when reading long pages. I use the TOC to find the section I want to read, then I may want to use the TOC again, to find another section I would like to read. I am obliged to return to the top of the page, and return to the article afterwards, and so on and so forth. A navigable TOC always on the right would be really helpful. Dodoïste 15:43, 3 October 2009 (UTC)[reply]

Do you mean that you want a TOC to appear on the right when you're reading the article, as opposed to when you're editing it. --Mephiles602 09:29, 11 October 2009 (UTC)[reply]

Do you mean as opposed to "when I'm editing it"? :D

Precisely, thanks. :-) Dodoïste 19:00, 3 October 2009 (UTC)[reply]

Whoops. I've corrected my typo. --Mephiles602 09:29, 11 October 2009 (UTC)[reply]

Behavior when changing text attributes

When selecting text in the editor and using one of the buttons to change a text attribute (e.g. "Bold"), the text attribute is changed, the text deselected and the cursor moved to the end of the former selection.

This behavior is highly unusual for an editor and therefore user-unfriendly.

What should happen is that the attribute is changed, but the text remains selected so other attributes can be set for it. Also, the toolbar buttons should reflect the attributes of the currently selected text, i.e. "toggle" according to the state of an attribute, just like it happens in every other editor on the planet. This has nothing to do with WYSIWYG, and should be implemented regardless of whether the editor will one day become WYSIWYG or not. -- JovanCormac 11:14, 5 October 2009 (UTC)[reply]

Opinion on the dropdown

Overal I like the Vector-skin a lot. Here a few things I'd like to point out as "Keep"'s in no particular order:

Search op top-right, that's were we expect it.
All page-related/-depending navigation/tools in the top-navigation
All site-wide navigation on the left-column
Right-navigation (Read, Edit, Watch etc.) automaticly puts items in the dropdown if it doesn't fit in the page-width.

It's this last point that I'd like to point out a few annoyances about.

In/out of dropdown

Firstly, it only puts items out of the dropdown, if their origin is out of it. All buttons that are dynamicly added or user-specific (such as Delete, Rename, Block etc.) are stuck inside the dropdown.

It would defintily cause me to switch full-time to Vector (I can live with the few bugs present in vector) if the sysop tools weren't forced in a dropdown, even on a with a wide window:

So a big request to let dropdown-items move out of the dropdown if space allows it. Krinkle 22:24, 12 January 2010 (UTC)[reply]

Just like the normal items (eg. View history) are forced into the dropdown when space doesn't allow it;
non-default items (like Move, Delete, Block etc.) should move out of the dropwdown when space does allow it.

What would happen if there is place for some of these actions, but not for all? Would that seperate the actions, like Move and Delete is outside and everythink else is inside the dropdown? I guess that would be confusing. Or we could say: If there is place for all actions = put them outside the dropdown, if not = use the dropdown for all. What do you think?--Juxn 16:53, 13 January 2010 (UTC)[reply]

That sounds about right to me Krinkle 02:01, 24 January 2010 (UTC)[reply]

Hide/Seek Bug

Second thing is a small one. When resizing the window smaller, it seems "Read" and "Edit" aren't subject to going into the dropdown. Neither do they keep their position forcing a scrollbar. No, instead they hide behind "Page" and "Discussion". This is not a feature request, but a bug report in my opinion. I take it it's not made like that on purpuse.

And now that I'm here I'd like to point out there are quite a few scripts flying around Wikipedia of which one in particular added extra top-nav buttons by JavaScript (such as "Google", which'd google the selected phrase (used for copyvio checks)) and some other buttons. It seems this ability either changed or is missing. It would be very handy if this ability can be added back in and/or documented how the new version works (ie. adding buttons to the nav, that play along with going in-and-out of the dropdown appropiatly).

Greetings, Krinkle 22:24, 12 January 2010 (UTC)[reply]

Editor not usable on iPhones!

I recently tried the Babaco sandbox on my iPhone and I tried the editor, but we can not even focus the textbox. What we might have to do is test for mobile devices and use a normal editor for them. Here's a quick test in JavaScript:

var agent = navigator.userAgent.toLowerCase();
var phones = new Array("blackberry","nokia","iphone","symbain","nec","samsung","sony","nintendo"); //nintendo is for Wii and DSi consoles
            //iPhone also covers iPod Touch
for (var i=0;i<phones.length;i++) {
if (agent.indexOf(phones[i])<0) {
//we're on a mobile or limited device, disable advanced editor here
break;
} else {
//we're on a pc, load the advanced editor here
break;
}
}

Thanks. Kirbylover4000 17:38, 19 January 2010 (UTC)[reply]

I second this concern. I often make small changes from my iPod, and the system should try to fail gracefully if it's not supported by the local hardware/software. Failing to a completely unadorned text box would be quite convenient for the iPod and iPhone, in fact, due to the way that their OS handles text boxes. Nihiltres 21:04, 20 January 2010 (UTC)[reply]

I'm not sure how iPhone/iPod Touc/iPad editting should be handled, perhaps with a completely separate interface or app to be designed down the fline, but I agree we need a good way to contribute from these devices. HereToHelp (talk) 01:08, 2 March 2010 (UTC)[reply]

I think a seperate app is not a bad idea, but should by no means be required. Apple's mobile browsers in iPhone/iPad systems are very close to Safari and thuss WebKit. So making it compatible with Safari/Chrome might fix the issue. Especially on the iPad I think a 'less advanced' version is not a good idea. It has a good size display and browser and is capable of doing the 'real' thing. So why not make use of that ? The iPhone/iPod/other mobile browsers however might profit from a less-advanced version due to the screen-size. Krinkle 17:16, 25 March 2010 (UTC)[reply]