Item — HN Reader

Remember that this is Linux, where 29 out of 30 applications look like ass. And what's worse - the Linux guys strut it as a badge of pride! Riddle me that!

---

Edit: I'm not claiming that they're struting _this_ particular app as a badge of honor. I meant struting _bad designs_ as a desirable outcome, placing "functionality" over "design". Example: Gimp. Works fine, looks terrible.

1 comments

Because sometimes I just want to get shit done and don't care what it looks like.

Function and design don't have to be mutually exclusive, you know?

I have to wonder, if someone were to fire off a pull request with GUI improvements for aesthetics and UX, would the maintainers approve it, or refuse it?

Is there a precedence for this?

Yes, but sometimes I really just want to get shit done.

Right now I'm sitting here as Calibre converts a epub file to mobi and is going to automatically send it off to my Kindle. Calibre is really, really ugly and the work flow is terrible. But I don't care because it does what I want, can suck in a ton of different formats, and in the end I have a document sitting on my Kindle that I can read.

Assuming you're talking about the GIMP when you ask about precendence, at least there is a user interface designer since a couple of years (peter sikking, GIMP UI blog at http://blog.mmiworks.net/search/label/GIMP).

Most folks who drop by the GIMP developer mailing list with UI suggestions are not providing very high-quality feedback, is my understanding. Of course, the GIMP is a large project, and it's hard for "outsiders" to know where things are headed and how to fix things.

Most open source projects don't have the luxury of having a person dedicated to UI design, which of course can be problematic for modern "UI-intense" applications.

> I have to wonder, if someone were to fire off a pull request with GUI improvements for aesthetics and UX, would the maintainers approve it, or refuse it?

This model may work for one evening js libs, not serious opensource projects with a large userbase. You just don't fire off a pull request that turns the project upside down because you feel like it without any consulting, expecting it to be accepted right away because it's nice (even if it is). So the most probable scenario would be to reject it and invite you to engage in working on the project before you propose drastic improvements.