Hacker News new | past | comments | ask | show | jobs | submit login

what "some people" argue is irrelevant here. Who are "some people" anyway? "Apple provides entirely too many user options" is not in any way the argument I've made. My argument is that having this specific option is a mistake. If you want the generalised form of that argument, it is:

1. this, and other "preferences" are not arbitrary or meaningless. They have real consequences (even if the only real consequence is minor annoyance)

2. the presentation of too many choices is in fact, a real and well documented anti-pattern in UI-design. Too many choices is cognitive overload. Programmers like choices. programmers like power. but ordinary mortals don't care what colour their window title bars are, as long as the colour doesn't get in the way of their job.

3. Given the above, it is the UI designer's responsibility to be very opinionated about what the defaults of a system should be, and what should be configurable as a choice. (the fewer choices the better, generally, from a design perspective.)

4. as a corollary to that, I am aware that "some people" are uncomfortable about Apple's lack of configuration options. Those people are not designers, and should not ever be put in the position of designing a UI. Or you end up with a monstrosity like the desktop linux ecosystem. It's essentially an argument from ignorance of the research.




>My argument is that having this specific option is a mistake.

That's a belief. I don't see any argument here. Why is it a mistake?

Perhaps modern users, not tied to a legacy of scrollbars, could not care less about them? Perhaps 95% of users (with the exception of hackers) not even use them or notice them when they are there?

>Those people are not designers, and should not ever be put in the position of designing a UI.

Whereas you are? And we should take your opinion on scrollbars over Apple designer's one, because?


"Designers" should never be put in a position of designing a UI. Claiming the mantle of "designer" usually seems to reveal a preference for static aesthetics over functional utility.

Nearly every time I see someone talking about "design" in the realm of user interfaces, or about making software "beautiful", they're invariably attempting to use concepts applicable to media intended for the presentation of information to a viewer in the context of an interface intended to facilitate dynamic interaction between a functional tool and the user, and it always seems to make the software more limited, less productive, and more frustrating to use.

A user interface is about exposing software functionality and enabling users to maximize their efficient use of their tools. Optimizing a UI to look good in a screenshot means not optimizing the UI to provide efficient access to the functionality of the application, and not optimizing the flexibility of the application for users to adapt it to their own priorities and work styles.

This trend of attempting to exercise top-down control over user experience needs to end, and software developers need to start paying attention to what users are actually trying to do with the products they build, instead of deferring to inappropriately-applied theoretical models offered by visual designers.


Design is how it works. Not how it looks. How it looks is properly called "style".

If you have found a "Designer" who is overly concerned with how it looks and not so much how it works, the conclusion to reach is that you have found a bad designer, not that all "designers" are concerned only with aesthetics.


If "design" is meant to refer to how things work rather than how they look, then it's clear that the majority of people talking about "design" with respect to software UIs are using the term incorrectly.

People who call themselves "designers" in this context, and at the present moment, generally are prioritizing screenshot aesthetics over functional utility, and we're getting worse software because of it.


Well you're not wrong about that. The word "design" and "designer" is vastly misunderstood by everyone, including many of the people who go around calling themselves "designers". It's like the problem the programming industry has with people applying to jobs, calling themselves "programmers", and who can't code the most basic things.

Except, that in the case of the designers, since the person giving the interview also does not know what design actually entails, they get hired.

The situation has led to actual designers inventing a new title to give themselves "UX", which I predict will also quickly get watered down to mean basically nothing.

It's kind of really sad. and frustrating.

Another problem is a real designer, calling themselves a designer, gets hired by an organisation that has the wrong idea about what a designer does, and so gets pigeonholed out of any important decision making processes, and only is allowed to be involved at the very end of the process.

A very good designer can get around this, but they often don't have much power in the organisation to do anything about this pigeonholing.


See argument upstream- in summary, autohiding scrollbars:

Pros:

  Looks tidier sometimes
Cons:

  Causes frustration and confusion.
My question is: whose lives have been significantly improved by the addition of this feature? why does it exist?

> Whereas you are?

yes

> And we should take your opinion on scrollbars over Apple designer's one, because?

because I am right and Apple is wrong.

On top of that, the reaction to my position is so weird. Oh Zen, if you had your way we would be FORCED by your tyrannical fascist ways to look at ugly scrollbars ALL the time instead of just some of the time. :(


>because I am right and Apple is wrong.

A, ok then. Case closed.


We actually like to give choices so we don't have to make decisions. Making decisions without seeking like an arrogant asshole is difficult.


yeah, designers/programmers need to learn to spine-up, and make decisions instead of just leaving everything up to the user, even if it's just better defaults, and leaving a .ini file around for the people who desperately need to change something.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: