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

I work as a web developer and as a KDE user, I really tried to make the sites work in konqueror. But as soon as one starts to use AJAX, you pretty much lost.
Konqueror does not support XSLT nor XPath (https://bugs.kde.org/show_bug.cgi?id=55420). Both work in any other mayor browser, both are a W3C standard (http://www.w3.org/TR/xpath and http://www.w3.org/TR/xslt) since 1999. Not to use XSLT or XPath in AJAX requests is not an option (at least not for us).

I tried to use a javascript XSLT/XPath lib (http://code.google.com/p/ajaxslt/) for konqueror. But the lib is not complete, has lots of bugs, is magnitudes slower then the native XSLT/XPath support in the other browsers. After spending lots of time on konqueror, I finally gave up.

I think many other developers have the same problem with Konqueror and AJAX. And as far as I am concerned this is really a problem with konqueror and not of the developers.


By fabian_ at Tue, 06/30/2009 - 15:02

The real problem with web browsing in KDE is that its own web browser gets no support by uninvolved KDE developers. This is no particular problem of KHTML, but also affects Konqueror and most importantly the WebKitPart. Developers who like Konqueror and/or KHTML tend to contribute, and Konqueror/KHTML are far from dead as a result. Developers who don't like those instead use Firefox, completely ignoring KDE's own efforts. What's needed is developers who so far only wrote about perceived shortcomings and at best poked the WebKitPart to actually give more support to Konqueror and KHTML/WebKitPart, scratch their itch and implement what they want instead using Firefox and keeping complaining. Or they could be working on integrating Firefox better with KDE, so that particular shortcoming get resolved. Instead we are staying in an endless loop of some people regularly publicly voicing shortcoming without doing anything about it, while the only effort in that area, the WebKitPart, shows how important such effort is to everyone. Not so much it seems.


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

...that KDE is an open source project. And that is is made by a group of enthusiastic people who make great software in their spare time.

That said I've have to agree with Will completely. The problem is IMHO the gap between developers and users. I'm a software developer for my proffession, and me too am not glad if I get some criticism from the users. The usual conversation between a developer and a user (warning: highly exaggerated :-) goes like this:

user: "your software can not be used in daily work because it does not work properly".
dev: "yeah... uhhh... but do you know how many design patterns are being used?"
user: "uhh... design what?"
dev: "you don't have knowledge of software do you? Go away."

(this sort of things happens on more places in KDE: in Kopete for example you can't configure a GoogleTalk account. Developer answer: "yeah, but that's just a Jabber account!" Try to explain that to my mother!)

Back to the topic. Although I am a great KDE fan and I *LIKE* it a lot, these issues are potentially dangerous to KDE. And personally I think it's time to realize that the KDE community is being populated by developers, users and who ever feels him/herself at home with the KDE community.

So yes. I don't use konqueror. Why? Do I like Firefox in KDE? Hell no! Every time I see the file dialog I'm getting all frustrated. But there's just one thing Firefox does well: rendering web pages. That's it's main functionality, and that it performs *way* better than Konqueror.

So please... please: create a simple, fast, light-weighted web browser (now we've got the great Dolphin *remove* the 'konqueror-can-do-anything' stuff), based on webkit, that will put KDE back were it belongs.

Finally to the KHTML/Konqueror developers: guys, you are doing a hell of a job. Let's not forget where Apple found the basis for webkit. The complete KDE community should be thankful to your years of dedicated hard work you've all put in.


By dirtyharry at Tue, 06/30/2009 - 18:02

Just thought about another problem.

Developing a state-of-the-art web browser takes a lot of resources. In order to gain these resources, you need a large user base. Firefox is easy to install on the three major operating systems and therefore gets developers from all these systems. Konqueror on the other hand is limited to KDE. I know there are Windows and Mac ports of KDE, but it's not like they were actually used by regular people like Firefox is.

Firefox is now almost as big with respect to number of lines of code as KDE is. Moreover, it is dead simple to extend - which is probably one of the most important things about a web browser nowadays. The thing is, is Konqueror is to compete with Firefox, it has to get strong on the extensions front too, and provide its own framework.

Not caring too much about the rendering engine (as soon as Webkit gets ready to fully replace KHTML) and focusing more on user interface and extendability may be one way to refocus resources.


By gnurou at Wed, 07/01/2009 - 03:24

Please sir, I'd like to see your talk "User-Centred: Shaping the KDE 4 Desktop", where is it on teh web?

I'd like to suggest that regardless of what web engine KDE picks, Firefox integration is important. Firefox users considering a switch to Linux is the biggest potential source of KDE users. Although, as a two-month old Kubuntu user I haven't really noticed any lack of integration between the Firefox browser windows I live in and the nice enough KDE panel strip and Kickoff menu below them ;-). Until Kubuntu enables and/or explains all this Nepomuk/Strigi/semantic goodness, lack of integration isn't apparent to me.

userbase.kde.org currently has redundant bad non-answers to Firefox integration with KDE in General KDE FAQs and General KDE Problems, each pointing to a *different* broken link :-(.

(Typed in Firefox 3.6a1pre nightly 64-bit build on Kubuntu 9.04.)


By skierpage at Wed, 07/01/2009 - 05:13

In my opinion it's by far not just KHTML which is the problem. In fact, when I finally switched my desktop to KDE4 a couple of months ago I noticed a huge improvement in the number of pages supported that didn't work with KDE3 anymore e.g Google Maps. Of course there is still room for improvement in the HTML renderer area and it may be just my usage pattern and frustration tolerance (in terms of KDE) that I only occationally need Firefox.

However, I don't think a switch to WebKit would magically solve it all. At least to the same amount I see the problem in the bits surrounding the actual renderer. Konqueror (talking only about the webbrowser here) seems more or less unmaintained in the KDE4 cycle.

- There are long lasting annnoying bugs: for example a crashing and basically unusable bookmark editor or I get a crash recovery dialog on every KDE startup even though everything seems fine.
- There is missing polish: for example the dropdown URL-bar history is a lot better in Firefox as you can actually read the page title there, the crash recovery is not exactly smart, or it's currently mostly in the dark why a certain plugin is chosen and how you can change it (I can sometimes guess what the mimetype might be, my mom for sure can't...)
- There is an improvable user interface: e.g. now that dolphin is the default file browser, the default web browser i.e. Konqueror still carries around all that filemanager cruft in it's interface. Or a more powerful and comfortable history browser.
- There are really advanced new features waiting: like a lot of things seen in the Crome browser like independent tabs and what not.

This were just random examples from the top of my head. But this shows for me, that there is a lot more to do than simply replacing the rendering engine. And there doesn't a lot of progress here. Actually it asks the question, whether it's fixable in Konqueror or whether it's about time for the post Konqueror era and start from scratch or "adopt" another browser (Rekonq and Arora are usually named here)? It might take time and it will surely hurt a lot of people, me including, but perhaps it's the way to go ...


By psychotron at Wed, 07/01/2009 - 12:20

Pages