< Blogs - MANIK.IN >    


Konqueror II
Konqueror I
GPLisation of fonts
Distributing a Distro
Back to Blog Index


Web Log _

Perspective and Skinning for Konqueror -III

Manik Chand Patnaik
Tue July 04 06:55:40 2006

Did You miss the earlier sections of this discussion? if so, you can read them here (Part 1) and here (Part 2). As a hint, The first part introduces to the issue and Part2 exposes similarities through a graphical comparison.

For people who want to know more about differences rather than similarities, kindly open the menu items. The majority of differences lie there. and of course! in the configuration dialog boxes.

Now the Q/A begins: OK I got the point of similarities but it is the question of why before how. I still don't get the point why Konqueror should look like any other crappy app at the first instance?

Let me answer, but before that let's know what are the modes of interaction with the browser? The Browser Interface.

Interface is the face of the application to the outer-world. The user interacts with the browser through the following interfaces:-

  1. Toolbar Buttons
  2. Address Bar
  3. These two are the most common places, a user will visit for navigation while browsing. All other interface elements should be treated as secondary modes of interaction while browsing. Toolbar buttons are mostly customisable.

  4. Shortcuts
  5. Gestures
  6. These two are quickies for quick access. Mostly configurable.

  7. Side bars
  8. Generally used for History and Bookmarks as these tend to be represented as lists. Some implement media playing controls here for easy access (IE and Konqueror).

  9. Menu access

    As it is not convenient to pull down menus during browsing, menus tends to be special and advanced user's controls. Most of the special commands are accessible only through menus. They are important but destined to be used less. Many of the frequent use menu items are associated with shortcuts which further minimises their usage for experienced users.

Now comes the answer to your why?

Because people get accustomed to their favourite application's interface layouts. Though obvious controls like the back and forward buttons are easily accessible as they are prominently placed, the compatibility problems arise mostly in menus, shortcuts, shortcut menus and gestures.

Is this situation so very frustrating?

The answer is both yes and no. Most crossing over from the other-side of the fence initially feel the pinch but if he/she stays over for some time, the program, be it Konqueror or Opera will soon feel comfortable. The question here is not about the capabilities of IE, Opera, FFox or Konqueror but the interface design of these applications.

Don't you think the engine is more important than the steering and pedals?

In every car you will find the steering and brake pedals at the same place. The build quality and feel may be different but the interface is the same. In Browsers the situation is quite different and These dissimilarities form the superficial line of barrier for people crossing over. After all these years of using browsers I am very sure that browsing frustrations are mostly related to poorly designed sites, bandwidth, site server issues and media support rather than rendering issues. (Sometimes setting the browser to identify like the competition results in preferential rendering on several websites. This situation is fast changing with the increasing popularity of FFox and the deployment of web-frameworks which make web-deployment so easy that few get the impetus to venture into customising their site to look good on a specific browser)

However there is a broader issue which lies beneath. The case of customisability and configurability.

Every user's desktop reflects his/her preferences and work patterns. So also the hardware and the applications in use. The placement and feel of the interface elements may not be comfortable for all and sundry So, here comes the real issue:

The issue of tying a predefined interface to an application.

It is sure that all the products under our perview are tied to their respective interfaces. So, there is no flexibility of adopting a new interface without meddling with the source code to make the program adopt a different interface. This is the realm of no Interface designer. It is the programmer's stronghold. As the interface choices of users would vary too much and too wild, the programmer would stick to a single standard interface for developing his application. Ultimately the user has to adjust him/herself with the interface, not the other way round. This fundamentally limits the productivity of the user consequently limiting the usability of the application. Be it a browser, File Manager or PIM, it does not matter.

We will look into available solutions and available sample implementations in the next part of the article ...

- - - - - This Article is under GNU FDL with title as FC text. Contact Author for any queries.

      Site Design and Content ©2005,2006 Manik Chand Patnaik. All rights reserved. Contact webmaster for any usage related queries.