

Design annoyances - sghael
http://codefastdieyoung.com/2011/03/design-annoyances/

======
idlewords
List mysteriously leaves out "gratuitous headshot of author"

~~~
jsavimbi
Yes, he's been on a pretty consistent self-promotion tour with the blog and
the twitter.

~~~
Stormbringer
_That's what you do_ with a blog and 'the twitter'.

------
beaumartinez
Number three is interesting, especially if we consider what Canonical have
done recently with Unity and moved scrollbars _outside_ the window[1],
freeing-up the screen real-estate that they permanently occupy.

[1] [http://design.canonical.com/2011/03/introducing-overlay-
scro...](http://design.canonical.com/2011/03/introducing-overlay-scrollbars-
in-unity/)

~~~
ryanf
It's interesting how reminiscent that design is of Google Wave's much-
criticized scrollbars: the position indicator following the thumb, the page-
up/page-down buttons, and the minimalist appearance when not in use. I wonder
if Wave's design was just ahead of its time.

~~~
ugh
I think that the problem with Wave's scrollbars wasn't so much that they were
bad, they were non-standard. Scrollbars are OS territory, individual webapps
should probably not try to reinvent them. (I would argue that they should only
ever try to reinvent them when they provide something substantially better and
when the standard OS implementation is lacking.)

~~~
jacobolus
My problem with wave’s scrollbars was that whatever code they had to do
scrolling was dramatically slower and glitchier than native scrollbars.

------
billswift
Most of these have been pretty well known or obvious, which is why those that
do them have little excuse. But I disagree strongly that #1 is a problem. Some
things, like the header in his example, usually should be full width. While
others, especially columns of text should be of a fixed maximum width to
improve readability. Who cares about blank bars to the sides of the screen? Or
at least, who cares as much as they do about struggling to read too wide
columns of text?

~~~
ugh
I think the problem is that things don’t line up when you mix full width and
fixed width. It’s not supposed to be an endorsement of either full or fixed
width.

~~~
bigiain
Agreed. I think the fundamental underlying error is not having a reason why a
particular elements is fixed or full width.

If you can answer the question "why did you go with a full width header and a
fixed width body?", you're probably OK (unless that answer is something like
"well, the theme I downloaded from themeforest was fixed width, but the client
insisted I use their old header in the new design, so I just mashed it into
the template...")

Like most "design errors", I think what the author of e article is ranting
about is designs that aren't fully though out - if you've asked yourself the
questions "fixed or full width, or both?", "what sized fonts should the forms
have?", "how much of the site it going to be long enough to scroll, and do the
scroll bars behaviour need to be considered in the design?", then you won't
have made these errors, or at least will have good reasons why they are not
"errors" but behaviours you chose.

------
Gorm-Casper
I'm curious what others think about #3 (The vertical scrollbar). Traditionally
it's considered messing with the defaults of the browser, and wasting precious
screen space; but I hear from more and more (graphical) designers that they'd
like me to stop the page from jumping by doing exactly this.

~~~
stellar678
I think it's mostly just the usability perspective, like was mentioned in the
article. If you don't force the vertical scrollbar and this causes elements
that should be in a static position to move, you've got a frustrating
usability issue. (Like on sites that have forward/back buttons that jump
around so you can't repeatedly click the same button. How frustrating.)

~~~
Stormbringer
That's not the usability perspective. Usability would be "don't mess with the
semantics of the controls". E.g. if you're going to make something that looks
like a button, it should do everything that buttons do.

Having the sidebar always on so as to avoid the bounce is not a usability
thing. Usability would suggest that you leave the defaults the heck alone. In
this case though, it is a pretty minor infraction.

Rather, it is an _aesthetics_ thing. They've decided the default behaviour is
'ugly', and they've decided to override it to make it look better. In this
case they've decided that prettiness trumps usability.

------
powertower
"body {min-height:101%;}" will work much better than "overflow-y: scroll".

Unlike the latter it's CSS2 (vs CSS3) and also works without bugs.

~~~
davej
In practice this isn't true. As it turns out, the browsers that don't support
overflow-y (certain versions of IE) happen to display a vertical scrollbar by
default anyway.

Adding 'min-height: 100%' to the body will actually add a few pixels of empty
space which the user can scroll to (confusing and ugly); whereas "html {
overflow-y: scroll; }" will insert a placeholder for the scrollbar, the
scrollbar itself will be grayed out. This is much better behavior in my
opinion.

Also "html { overflow-y: scroll; }" is self-describing (i.e. the real goal is
to add a vertical scrollbar to the html, not make the minimum height of the
body 101%).

------
stephenhuey
I'm certainly more likely to feel like I'm signing up for something magical
when I'm faced with big pretty happy-looking form elements! :)

------
true_religion
The reason for #1 is because fluid layouts can force text lines to stretch on
wide screen monitors. As such, the line becomes harder to read.

~~~
acon
You can always combine a fluid layout with a max-width for your text. Besides
its not the width of the monitor that matters, its the width of the windows
and I like my windows narrow, thank you very much. I used to be able to do
this, but then they went and broke Readability :-(.

~~~
true_religion
Interestingly, in the actual example he uses that isn't a fixed with element.
Look at the Heroku.com site, its the div with id "accordion". That space to
the left of it is created because of the padding of the surrounding div (which
is fluid width), and the margin of the accordion div.

Its sister element with id "rightelement" is actually fixed width, but I don't
see the issue there since the majority of its contents are image elements and
not text.

\---

That said, I agree with you set a max-width for text only enclosures, and a
min-width for enclosures that have image elements.

