| |||||||||||||
GNOME and the way forwardGNOME and the way forwardPosted Aug 18, 2005 17:09 UTC (Thu) by hp (subscriber, #5220)In reply to: GNOME and the way forward by dskoll Parent article: GNOME and the way forward
The most obvious form of the tradeoff is that you have two very different lists of requests and priorities from the different users, and you have to allocate developer time between working on one list vs. the other. No way around that. The only world without tradeoffs is one with infinite resources.
Another easy-to-understand tradeoff is that lots of people here seem to be requesting the UNIX behavior _by default_ and all defaults are a tradeoff vs. the other possible defaults.
Some other tradeoffs are mentioned in http://ometer.com/free-software-ui.html for example
It's tough to really have a feel for why there are tradeoffs until you've worked on the software for a while and seen how a design is done and how the maintenance issues unfold over time.
But while we can nitpick I don't see how some of these tradeoffs are arguable. There's obviously only finite developer time, and there's obviously only one set of default settings.
(Log in to post comments)
GNOME and the way forward Posted Aug 18, 2005 17:32 UTC (Thu) by dskoll (subscriber, #1630) [Link] The only world without tradeoffs is one with infinite resources. Agreed. So when a developer does all the work for you, and presents you with working code that does something useful for UNIX geeks, why not include it? Apparently, the Evo. developers just ignore such submissions unless it fits into their view of the world. But while we can nitpick I don't see how some of these tradeoffs are arguable. They are absolutely arguable. The kinds of things I'm looking for, and other UNIX geeks are looking for, are things like standard X cut/paste behaviour, ubiqitous support for external editors and adherence to long-established UNIX software traditions. These are all easy to implement (in fact, some of them take effort not to implement), and have been implemented quite successfully by KDE. They also don't affect newbies who don't want or care about them -- just don't use an external editor if you don't want to, for example. Use ^C/^V if you want for cut-and-paste. If Gnome wasn't planned right from the start to permit these kinds of things easily, then as I said before, it's badly designed.
GNOME and the way forward Posted Aug 19, 2005 1:49 UTC (Fri) by hp (subscriber, #5220) [Link] An initial patch is very much not "all the work for you." Any practicing software developer can tell you that at least 80% of the work is maintenance, not the patch. I don't know a thing about Evo external composer and haven't read the bug, but I can easily imagine the poor maintainer having to work around some complicated external editor mess when implementing features, and having to endure endless bug reports about how external Emacs doesn't quite work in various ways, or vim changed how it works and Evo needs adapting, and so forth.It could easily be a major time sink.
As it happens I've already written this argument down too: http://ometer.com/features.html
On the "it would be easy if it weren't badly designed" comment, I don't know where you get Magic Programming Silver Bullet(tm) with no tradeoffs or costs, but if you have it by all means come design things for us!
In the end I think most people who flame passionately about a small feature miss the simple point that there are hundreds of people flaming passionately about hundreds of small features. The maintainer is seeing the hundreds, and you are seeing the one.
Maintainers need some way to prioritize that.
GNOME and the way forward Posted Aug 19, 2005 2:00 UTC (Fri) by dskoll (subscriber, #1630) [Link] > An initial patch is very much not "all the work for you.
The Gnome-vim guy is maintaining his patch, and even maintaining a patched version of Evo on his download site. If he can do it, so can the Evo developers, so that they can cease to be the *ONE AND ONLY* UNIX mail client that lacks external editor support.
> I can easily imagine the poor maintainer having to work around some complicated external editor mess
Software that makes invoking an external editor a "mess" is badly designed.
> As it happens I've already written this argument down too: http://ometer.com/features.html
But IMO, the GNOME developers ignore an important point you make in that article:
"In the presence of good rationale, maintainers should be willing to change their mind often."
OK. Let me follow your article about just this one feature (external editor support where possible.) You want a rationale that:
"Does not apply to all possible features."
OK.
"Contains facts or empirical data rather than speculation."
Every other significant UNIX MUA supports this feature. 80% of the developers I have ever worked with have used this feature.
"Demonstrates that you've done your homework on alternative solutions to the same problem."
The alternative would be to rewrite users' favourite editors within GNOME.
"Demonstrates that you know what the root problem actually is; what motivates the feature? How else could it be approached?"
The root problem is that many people are most efficient editing text in their favourite text editor.
"Demonstrates that you're thinking of all users in the big picture, instead of just yourself and people like you."
All users who like their favourite text editor will benefit. Those who don't care won't be hurt.
"Improves things for a large percentage (50%?) of users, or makes the impossible possible for a smaller percentage (5%?). "Easy things easy, hard things possible.""
I believe this feature request covers the 5%.
"Shows that the feature is genuinely important enough to be worth maintaining some extra code."
One developer is already maintaining the extra code in his own free time.
Happy?
> In the end I think most people who flame passionately about a small feature [...]
I'm not just flaming about one small feature (although it is highly irritating). It's the *combination* of small misfeatures, bad design decisions, and (mostly) incredibly haughty attitude of the developers that has soured me on GNOME. I have to agree with some of the other posters here; the 1.4->2.0 transition really marked a significant decline in GNOME's usability and quality.
GNOME and the way forward Posted Aug 20, 2005 0:52 UTC (Sat) by sandmann (subscriber, #473) [Link] Here is a fact you people might want to consider: Nobody actually *likes* the unix mail programs with their external editors. Their combined market share is perhaps 2%.
If you try to say that those 98% of all people just need to get used to the unix way and put up with meaningless preferences like "path to external editor", then you need to reconsider who the arrogant twit is ...
GNOME and the way forward Posted Aug 20, 2005 3:24 UTC (Sat) by dskoll (subscriber, #1630) [Link] Here is a fact you people might want to consider: Nobody actually *likes* the unix mail programs with their external editors. Their combined market share is perhaps 2%. If you are talking about market share of all e-mail programs, you're probably right. If you are talking about market share of all e-mail programs that run on UNIX, you are completely wrong. Evolution is the only UNIX-based e-mail program I can think of that does not support an external editor, and I'd be amazed if it has more than 25% market share among UNIX e-mail programs.
GNOME and the way forward Posted Aug 25, 2005 9:16 UTC (Thu) by k8to (subscriber, #15413) [Link] I've been using email for decades now, and have been through a huge range of email programs: mailx, eudora, pine, elm, a variety of wonky BBS-based acess methods, whatever the mail was on our VMS systems, pegasus mail, yahoo mail, gmail, and I've pretty much always come back to elm, and more recently mutt. It's just better at getting the job done. Despite significant experience with all the others, I really quite like it.
And you know I'm editing this web form in gvim too. A feature the mozilla people have had requested since it started without ever being satisfied.
Thanks for calling me a nobody.
GNOME and the way forward Posted Aug 25, 2005 13:03 UTC (Thu) by zdzichu (subscriber, #17118) [Link] There is not need to put this preference in Evolution.There is already Prefered Application submenu in preferences. Default editor could be put there.
HP's "Good UI" article. Posted Aug 18, 2005 17:38 UTC (Thu) by dskoll (subscriber, #1630) [Link] Regarding http://ometer.com/free-software-ui.html
There's no such thing as a universally "good" UI. That's like saying yellow is a "good" colour. The only definition of a "good" UI that counts is: A good UI lets the user get things done quickly, easily, accurately and with a minimum of fuss. By that definition, a good UI for me is the Nirvana of a Bash prompt, whereas for others, a good UI might be Windows 3.1 (because that's what they're used to, dammit!) So trying to design an objectively good UI is doomed to failure. The best we can do is design a UI that's "OK" by default, but that lets individual users tune it until it becomes their personal "good" UI. The way GNOME is going, we'll all be using an OK-by-default UI without the ability to make it a good UI.
|
|||||||||||||