JUN
30
2009

User-Centred: Stop Continual Web Failure

KDE needs as an entire project to support a Web browser that everyone can use in 2009. That's the simple message behind this blog entry and my talk at LinuxTag on Saturday.

If you need any more motivation to go out there and make that happen, read on.

I have to admit that as a KDE user for the past ten years and a developer for 8 years, I'm writing this blog on Firefox right now. What do 95% of desktop users actually do after they log in? They consume content. That means they use Firefox, use Firefox, use Firefox, use Firefox, and while they are at it they may listen to music using Amarok. Unless you are reading this in lynx, you know what users are doing - webmail, social networking, youtube, microblogging, editing online documents, uploading to their photo collection, using intranets.

Anything else they do using a fat local app is pretty much incidental nowadays - using at best, what we used to call 'utilities' to patch their system or change the volume level.

If a desktop or an operating system doesn't have a well integrated web experience, users have no reason to stick around.

Details. KDE always has been network-transparent environment. Our apps can just as easily pull content from a web server as load it from the hard disk or save it back to an FTP site. But Firefox has a completely separate network layer. Passwords, cookies, sessions are all separate and insulated from KDE and have to be managed separately if you want to use KDE apps, which is hassle.

File associations are managed in most Firefox versions by GVFS now, which means that if you have any g* apps installed, they will be Firefox's first pick to open links to movies, PDFs, and music files you click. If you are a curious user who installed the whole distro DVD, if every time you view a PDF in KDE, Evince shows up, why bother logging into KDE?

Firefox bookmarks are separate and completely ignored by all KDE's cool semantic technologies like Nepomuk. They could be indexed, sure, but since we're the integrated Free Desktop environment, why do lists of bookmarks have to be glued to the app they came from? KDE should have a single Bookmarks app letting users see where they currently are in all their content - Web stuff, documents, podcasts, videos, even Konsole sessions.

And many other smaller integration points break. Try 'Set as Background Image' for example. Firefox saves downloaded files in one directory. Chances are it isn't part of the fancy Places list in the KDE file dialog - another wasted opportunity.

I have nothing but respect for the KHTML developers. They do an amazing job with very few resources, creating fast, efficient code. But although KHTML is 'pretty good' that is just not sufficient for real world users. I tried a selection of modern sites with trunk on Saturday and the majority of them had rendering or ajax errors that provoke a WTF reaction among anyone not very close to the KDE project. The blame for this is almost certainly with the site developers, but a reality check says that they will never test for KHTML and never fix it.

So I suggest, as strongly as I can, that KDE gets behind a widely used web engine that works, puts it in Konqueror, integrates Rekonq, and makes it all work as well with the rest of KDE as Konq+KHTML did. I don't think this even changes anything for the KHTML developers - the same tiny subset of KDE users will continue to choose to use Konq+KHTML, but the majority will be able to have a web experience that strengthens KDE, rather than weakening it.

By not having an integrated browser that anyone uses, KDE is on the same path to irrelevance that Microsoft started when they ignored the World Wide Web in the mid 90s. Apple gets it, Microsoft now gets it, GNOME gets it. Yet KDE continues to look away from this unsightly hole in its portfolio.

Comments

+1 to this Will.

I completely, completely agree with all of the above. I hate using Firefox but I just can't afford to use Konqueror when almost every site I use regularly that has any Ajax is broken. Amora or Rekonq needs to get integrated ASAP.

Great post and hopefully others will agree.


By Mike Arthur at Tue, 06/30/2009 - 10:09

I attended the talk and very much agree with your message.


By Dominik at Tue, 06/30/2009 - 10:27

I keep trying Konqueror because I want an integrated experience and in part out of a sense of loyalty that I'd rather use KDE first. Every time I do I remember the cool features it has but every time I find myself slipping back to firefox because it is just easier. The web just works.

Not only would giving Konqueror first-class webkit support have direct impact in terms of real-web-compatability but it could reinvigorate the project and lead to a greater possability of creating a really awesome browser.

And there is no doubt that with the technologies in KDE there is room for greater desktop integration and unique and powerful functionality.

It's not a defeat for KDE technology to move on in this way but a massive opportunity.


By maninalift at Tue, 06/30/2009 - 10:31

Dear Bille,

as much as you have some points, what does your public moaning* help? Besides pissing off the KHTML developers once again (well, I would be)?
Somebody has to do it. Convince your payroll writer to allow yourself to spend some resources on this, adding a KDE layer to e.g. Chrome or whatever. You are KDE, too. :)

(And I personally rather would help out the KHTML developers, it looks much more fun to have more control about the code, and isn't it for fun what most of us are doing?)

* You once complained about a moaning of mine, so we are on pair now ;)


By frinring at Tue, 06/30/2009 - 10:36

I think it's necessary to moan a bit to build a consensus to solve this problem. I'm willing to put my weight behind it (been hacking on NetworkManager-kde4 only for too long) but several people have been going it alone in this area already and we still don't have a Konq that just works. My opinion is that this area is so important that we need to try and get the KDE project moving together to fix this rather than our usual technique of relying on virtuous Brownian motion.

* Ok, you have a moan in hand now ;).


By Will Stephenson at Tue, 06/30/2009 - 16:21

As I wrote in a separate post, the problem is that the moan to code ratio is too much on the moan side. Konqueror is easily extendable and adaptable. A WebKitPart already exist. But virtually nobody touches these areas despite all the moaning. There seems no use in declaring the need for a new project of establishing a "solid web browser" with a track record like this.


By Na at Tue, 06/30/2009 - 17:18

Will, you'd totally rock if you could turn your attention to WebKit and better integration in Konqueror. Maybe you can even turn the current KHTML API into a Phonon-like wrapper, so that people can switch between KHTML and WebKit (maybe even Gecko if anybody cares to port it) globally.
Personally, I don't use Konqueror at all, but KHTML continues to annoy me in other apps that render HTML -- most notably Akregator. Using the build-in browsing feature is such a chore.


By kamikazow at Wed, 07/01/2009 - 07:57

A "real-life" browser is sorely missing from KDE. Even when running 4.3 off openSUSE's factory repo's, I always run konqueror first wishing it to work flawlessly with *common* sites. I can notice the spectacular speed improvements and stability and support for standards. However, thereafter it all goes downhill as an end-user experience. I have to constantly fake Firefox's user-agent or worse, Opera's and even IE's! Some of it is obviously due to lack of support from the target website but one wonders why konqueror (KHTML) has not been successful where its spin-off, Safari, is counted among the leading browsers.

I have tried rekonq too but it suffers from issues like font size etc which puts one off. Arora is probably the best bet we have for a Qt/Webkit based browser. It is actually the one I prefer over everything else out there.

Konqueror maybe the ultimate swiss-army knife of developers but it has completed failed as a browser of the masses -- which is the segment KDE4 is targeting at the moment. Frankly, Konqueror should have provided equal (if not switched completely) support of Webkit rather than a broken one at the moment.

As a KDE-lover since its early 2.0 days, I have to but agree with you, mate! Its high time this issue is brought out openly and discussed frankly.


By kanwar.plaha at Tue, 06/30/2009 - 10:40

I actually switched from Opera to Konq/KHTML as my primary browser for the first time at 4.2.2 and I'm reasonably happy with Konqueror - mostly the KDE integration of course - kwallet, kget, kmplayer, nice KDE file dialog, file associations, etc. etc. It also has fast startup, and a few nice features and plugins.

I do have to fall back to Firefox on occasion, usually for wordpress admin interface or home banking.

I'm not sure KHTML needs to be replaced. But I do think it's highly unfortunate that we have 3-5 KDE/Qt webbrowsers competing for users and contributors, so it would be great if some sort of compromise could be found, and everybody (or at least most people) could pull in the same direction - whether that'd be khtml, webkit or gecko...


By cb400f at Tue, 06/30/2009 - 11:35

I strongly agree. The current user experience (for the non-kde-devs people) is really unpleasant.

I tried to defend the KHTML choice for *years* with my friends but it's not possible anymore:
some of them use Firefox (heavy and zero-integrated), some of them moved to GNOME.

Failing to handle this problem now will weaken KDE and allow others to say "the only desktop environment with a broken browser".
Admitting that we have a problem is the first step towards a solution, thanks Will !!


By Enrico Ros at Tue, 06/30/2009 - 12:56

Pages