Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Whoopdeedoo, you've got a degree! Congratulations! I got a C in German when I was 16 but I don't brag about it.

No, you only brag about how idiotic a) programmers that design custom UIs and b) designers in general are compared to you. Anyway, my point, which apparently went whoosh wasn't to brag (lotsa people have CS degrees), it was to show that even people trained in CS can find iTunes OK --unlike your implication that it is objectively crap for ignorant idiots.

>What would help an obese person, and anyone else trying to break a habit in the long term is education, not taking away their free will. If an obese person understands what causes his sugar cravings, why eating sugary food makes him fat and that eating sugar will spike his blood sugar levels and then cause them to crash which will then cause yet another craving, he will stop eating it and lose weight.

I don't see this "educate them" thing working wonders in the US. Plus it's not about taking away his "free will", just his junk food. He can still "will for it" it as much as he likes. It's not like badly made food with lots of additives, preservatives, second rate ingredients, sodium and saturated fats is a constitutional right.

>To address the other points you made, programmers do not like customized UI's. That's something which designers come up with because they are a) not aware of standards and the implications of breaking them and b) take orders from management who are advised by marketing on how to make the product memorable.

You'd be surprised. I'm a programmer. So is Will Shipley. So are tons of other, er, programmers that happen to like customized GUIs. Being a programmer is orthogonal to liking customized GUIs.

>Besides, OS X is possibly the worst example of a customizable UI, save Gnome/GTK. Almost none of it is customizable by design. I swear, Apple products are completely brain damaged.

A UI being "brain damaged" is also orthogonal to it being non customizable. You write as if there were no engineering and UI tradeoffs in a customizable UI. There are, and they are very real --telephone support costs from people accidentally switching their UI to some other style is an obvious example.

Also consider all the code needed to implement the "fluid GUI" you mention, with menus that can be shown as ribbons, regular toolbars or what have you by user choice. More code: more bugs, more costs, more complexity.

>Just as the implication that programmers can't design is idiotic and preposterous, not that anyone would ever claim such a thing. Nonetheless, they completely suck at it. Just as designers can think but completely suck at that.

This again implies that only the programmer's job has thinking involved in it. Which is as far from the truth as it can be. But check me response below for more:

>But that's exactly what happens even with web UI's - the programmers define the structural elements - e.g. this is a button, this is a list - and the designers skin those widgets. You can't paint a structure which doesn't exist!

In 1996 maybe. It's 2012. It hasn't been done like that for ages. If anything, with modern UX emphasis, it has got to the opposite: the designers design all the structure, interactions and functionality and the backend programmers have to implement it. But in the best web shops it's 50-50.




>unlike your implication that it is objectively crap for ignorant idiots.

I intended to communicate that it's crap in general.

>It's not like badly made food with lots of additives, preservatives, second rate ingredients, sodium and saturated fats is a constitutional right.

I believe that it is everyone's right to do what they want to their own bodies. Education lets people make the right decisions. Rules take away a person's right to make decisions. Maybe it's a constitutional right where you live or maybe not, but the law is not in line with common sense much of the time anyway.

>Also consider all the code needed to implement the "fluid GUI" you mention, with menus that can be shown as ribbons, regular toolbars or what have you by user choice. More code: more bugs, more costs, more complexity.

We're on the same page with more code being more costly but I'd argue that that's exactly what we're doing with the current customized UI's! By implementing this stuff at the library level instead of tens of thousands of implementations of custom UI's at the application level, we, in effect, reduce the amount of code. Since the population using the implementation increases, there is more testing and any bugs get squashed more quickly.

>There are, and they are very real --telephone support costs from people accidentally switching their UI to some other style is an obvious example.

That's the issue I have with this approach - everything comes down to business costs. In other words, the utility that something has to a small segment of society (the company) becomes more important than the utility it has to everyone else. This, to me, suggests an organizational structure which is broken by design.

>This again implies that only the programmer's job has thinking involved in it.

I'll concede this point and rephrase it - programmers are good at abstraction and saving work in the long run. This needs to be utilised more often than it currently is, particularly in terms of design.

I'm quitting smoking so I apologise for the tone of some of these posts.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: