Re: why are there no themes for galeon? and is galeon 1.3 cooler than 1.2, let's vote

On Fri, 2005-18-03 at 15:27 +0000, Nix wrote:
> On Tue, 15 Mar 2005, Adam Hooper wrote:
> I have real difficulty believing that there are *no* GNOME users of
> Galeon who ever want to close their web browser.

Okay, I didn't pick the best example, but I'll refute your argument in a
half-assed way to try and defend the *principle* of my statement that
"Quit" is a workaround for other problems.

Disclaimer: I am NOT arguing that Galeon should not have a "Quit"
action. I'm explaining what I mean when I say that not all feature
requests should be granted.

So, my argument: "close all web browser windows now" action doesn't
really make sense from a normal-user perspective.

> >     The simple fact is that users are trying to solve their *real*
> > issue (logging out and back in without destroying their session) by
> > coming up with a wrong solution.
> 
> How can you possibly tell that users would never want to close Galeon?
> Perhaps --- off the top of my head --- they're trying to
> 
> - free up memory for another job (Galeon is not small)

The problem here is that Galeon is not small.

> - cleanly disconnect all clients on a remote machine which is about
>   to go down and on which Galeon is running

In an ideal world, wouldn't they automatically get cleanly disconnected?
Every application should automatically do so.

> - vape a Galeon whose rendering thread has gone into an infinite loop
>   (there are still sites around that do this, alas, although I don't
>   run across them often anymore)

Then Mozilla should be fixed!

> - free up virtual desktops

Wouldn't a "close all windows on this virtual desktop" action in the
window manager make more sense?

> - or any of a million other reasons.

Don't get me wrong: I'm certainly not advocating the removal of Galeon's
"Quit" action. Hell, I even wrote an extension for Epiphany which *adds*
a Quit action (my use case: testing other extensions).

What I'm saying is that the Quit action is a workaround for other
problems, and so when a user says "I want a Quit button" a developer
should ask himself, "why?"

In the case of Galeon, the developers apparently decided (probably for
the reasons you list) that those other problems aren't going to go away
and so the Quit action should be implemented.

> > - Discover what it is the user *really* wants.
> > - Find a way to get the user what he wants in a painless manner, without
> > disturbing the experience for users who *don't* want it.

> This whole argument feels to me like a justification for ignoring any
> and all requests which you don't like the sound of, without needing to
> find an actual problem with the request; just say `you don't really want
> to do that' and ignore it. While you of course have the prerogative to
> do that, as do we all, some of us are actually fond of *listening* to
> users unless we have a good reason for saying `no'. We find it tends not
> to lose us users if we don't patronise the living daylights out of them.

Keep in mind I'm not a Galeon developer :). But when I listen on this
mailing list, I see several feature requests which either:

(a) have not been thought out.
(b) are already reported on Bugzilla.
(c) are in the mailing list archives already.

Of course, these don't mean 100% of the time that the mailing list
should not be used. But in many cases it's annoying to have to listen to
the same conversations again and again, with no new ideas being
introduced.

> > - Say "no" when he doesn't want to do something.
> 
> I wish I had your powers of telepathy. I'd have expected the user to
> know his own wants better than anyone else does.

I should have been more clear: I meant the developer needs to know how
to say "no" when the *developer* doesn't want to do something!

I imagine you took this list item as particularly arrogant of me and
indicative of my disrespect for users. It was nothing of the sort.

> Now we may disagree with the substance of a user's request, or think
> that we know a better way to do whateveritis than that which user has
> suggested, but we can't say that *the user* doesn't know what he wants
> unless we know that he's got one of a limited set of very severe mental
> disorders.

Nah, this is just miscommunication on my part. Let me explain by
example. I developed an ad-blocking extension for Epiphany. In the
course of developing it, I used *myself* as a user. The back-end was
straightforward enough to write, but when it comes to a user interface,
I simply have no clue what to do.

What's the problem? I don't know what *I* want. I know I want
*something*, but I just don't know what it is.

So when I say "the user doesn't know what he wants," I mean no offence.
I think of it as an extremely common situation, and in no way is it a
character flaw.

> > These tasks are incredibly difficult. Add to this the complication that
> > a massive proportion of the user-base doesn't even know how to give
> > feedback or make feature requests. In such a situation, it's impossible
> > for developers to know the best way to do things.
> 
> Agreed :( but that makes it all the more important that if a user *does*
> find some way to talk to us, that we don't blow him off with comments
> about we know what he wants to do better than he does, which *sound*
> fantastically arrogant whether or not they have a basis in fact.

Yeah, I'm like that. I apologize.

-- 
Adam Hooper <[email protected]>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCOw7c90GtBxQ61zARAkAwAKDCBaIAYA3jxfyz8PoSHKeiB1H7MQCfSMvL
YGsvtQeV+h6f/cwB7tDt1fI=
=iwM7
-----END PGP SIGNATURE-----