Rekonq default

[Eike Hein]

On 02/20/2010 06:17 PM, Aaron J. Seigo wrote:
> the lack of a menu bar, or the lack of a status bar?

The lack of the menu bar was foremost on my mind, 'cause
that creates problems with keyboard navigation and so on.

I don't think a status bar is mandatory as far as the HIG
is concerned, but it sure is useful to show the action de-
scriptions as one hovers menu actions. I suppose one could
do that with Rekonq's popup status bar as well though.

Anyhow ... in general, also on other app platforms,
there's this trend to see it as a-ok for the browser to
diverge from the normal platform UI standards since it's
in some sense a platform unto itself. Who knows, maybe
that's even a correct conclusion to make, but it's some-
thing that our HIGs would need to be augmented to address
head-on, otherwise the divergence strains their credibi-
lity. Just like the credibility of Apple's HIG is strain-
ed every time Apple decides to ignore them and just do
something different because they feel like it.

I think our HIG is really important to the KDE SC's iden-
tity as an app platform - we're not just a set of libs,
we're a user experience with its own set of conventions -
and we should really take care to manage that responsi-
bly and not lose cohesion.

At the same time we also shouldn't be afraid to evolve
our interfaces, of course. It's a fine line to walk.

The reason Konq vs. Rekonq causes me to wax philosophi-
cally here is because Konq has historically been a show-
case for many of our technologies and one of the key
apps to establish our user interface conventions, and
any replacement would possibly send a similar "this is
an example of how to do a KDE app" signal.

Put in another way: Rekonq's UI is obviously heavily
inspired by Google Chrome. Google Chrome has extreme-
ly poor UI integration into any of the platforms it
currently supports. I don't think Google minds that
very much, since they're a web company and the plat-
form they care about promoting is the web itself.

That's not the case for us. We're interested in pro-
viding great support for the web as part of the KDE
user experience, sure - heck, we need to, that's the
market reality - but if we want to maintain our re-
levance as an UX we have to do that in a way that
conforms with our conventions or what's the point
of there being a KDE web browser in the first place?

Thus I see it as far more important that our default
browser stays true to KDE's interface conventions
than that it is similar to the flashy new browser
of the day.


> you can't turn a swiss army knife into a chef's knife. nor would you want to. 
> you can't turn a chef's knife into a swiss army knife either. nor would you 
> want to.
> 
> it's not whether konqueror is good enough, imho, it's about the fundamental 
> design goals. both konqueror's and rekonq's are valid, imho, as they are for 
> different use cases. no amount of working on konqueror will change that 
> without pissing off everyone who relies on konqueror's design.

Perhaps. I have to admit that I see Konqueror mainly
as a web browser today, and would be happy if its
mission were redefined as such. It was important to
reassure our users that Konq's file management prow-
ess wouldn't just disappear as we introduced Dolphin,
lacking many advanced features initially. It was un-
derstandable that trust in Dolphin wasn't there yet
at the time: It was new and unproven. But I think it
has proven itself by now, and I've seen many stead-
fast Konqueror holdouts switch to Dolphin over time.

I think the desire for Konqueror to be a file mana-
ger is far less today than it was back when we first
introduced Dolphin, thanks to all the improvements
Dolphin has seen. I think we should reevalutate whe-
ther to focus Konq more strongly on browsing alone.


-- 
Best regards,
Eike Hein