[rekonq] quit vs. close

Pierre Rossi pierre.rossi at gmail.com
Fri Aug 19 17:20:01 UTC 2011


On Fri, Aug 19, 2011 at 17:20, Andrea Diamantini <adjam7 at gmail.com> wrote:

> On Friday 19 August 2011 11:14:36 Thomas Zander wrote:
> > On Friday 19 August 2011 10.35.37 Andrea Diamantini wrote:
> > > > So, in short, it doesn't make sense to me, and from experience I
> > > > know
> > > > that it doesn't make sense to a lot more people
> > >
> > > It seems to me you are suffering the same problem you see in my
> > > workflow.
> > > In  fact I sincerely trust that the quit = close window habit comes
> from
> > > the multitasking design of konqueror.Let's expose the problem in this
> > > terms: if we add the quit action at the
> > > end  of the rekonq menu (in the same way Firefox or Chromium do) the
> > > quit
> > > action now will close one window, while in Firefox and Chrom*, the same
> > > will close the whole app.
> >
> > Thats why I wrote this at the end of my last email ;)
> >
> > > > Being consistent and predictable is important for user satisfaction.
> > > > If
> > > > you can't be consistent with everyone else, make sure you go with
> > > > the
> > > > 'safe' ones so losing work is cut to a minumum.
> >
> > reusing the behavior of firefox and chromium looses more user-data than
> > reusing the behavior of other KDE apps.
> >
> > Also, firefox and chromium were designed for Windows first, where both
> > virtual desktops and activities are not present.  The concept of running
> > remote X applications is even unique to Linux.
> >
> > > And I'm quite sure this make sense to a lot of more
> > > people of the ones used
> > > to  dolphin/konqueror behavior.
> >
> > At the cost of hurting the ones that are used to the KDE interaction
> model.
> > The alternative is that those used to Firefox have to press Ctrl-Q the
> same
> > amount of times they have windows open.  Which is not exactly painful, is
> > it? I mean, if you put a lot of time into opening 10 rekonq windows, how
> > much of a pain is it to close those 10 windows too?
> > I'd say its worth the time when this means the user will avoid loosing
> > windows that were not meant to be closed.
>
> You are probably not used a lot to read all bugs reported against rekonq. I
> can just say that for people using a browser is a really common experience
> in
> every OS they use.
> And their experience is basically based on Firefox behavior. That's the
> road,
> you can't do nothing about this.
>
> > Bottom line still is that rekonq is a KDE application, behaving similar
> to
> > other KDE applications makes a lot of sense.
>
> Yes, it makes sense for me too. But this cannot be a "forced model",
> otherwise
> it can be always applied against decisions like menubar, webkit/khtml, the
> development itself of rekonq...
>
> > Anyway, I've done as much as I can in defending the usability side as I
> see
> > it, any decision you make is fine with me :)
>
> Let me joke a bit, it seems you "pushed" your vision a bit too much ;)
>
>
> IMHO, the question is not closed. I'd like to hear again Felix and the
> other
> opinions about what it is better to do.
>
>

Indeed, that seems to be a trickier issue than I first thought... In the
light of activities and all that, I felt the KDE approach (Quit == Close the
current window) was better. And I still think it might be, considering it's
the safest bet in terms of usability, while not being in the way too much (I
don't like to rely on dialogs for such things that much). I think most
people who want to quickly get rid of all their Rekonq windows (and fire a
new build for instance) will most likely use killall, so even if the 'quit'
approach is that taken by other major browsers, I'm not in favor of aligning
on that one.

More feedback from everybody reading this would definitely be a plus. Maybe
we could also ask usability-gurus in KDE, if anybody knows some, please
invite them over ! :)

Cheers,
--
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/rekonq/attachments/20110819/1c9e0f81/attachment.html>


More information about the rekonq mailing list