Design annoyances
codefastdieyoung.comList mysteriously leaves out "gratuitous headshot of author"
Yes, he's been on a pretty consistent self-promotion tour with the blog and the twitter.
That's what you do with a blog and 'the twitter'.
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...
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.
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.)
My problem with wave’s scrollbars was that whatever code they had to do scrolling was dramatically slower and glitchier than native scrollbars.
I think the problem most people had with Wave's scrollbars is that they didn't indicate the height/length of the document very well. The Canonical design above has solved this by retaining the visual indicator.
And OS X Lion's new "hidden" scrollbars.
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?
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.
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.
If you have a wide monitor that displays 1200px or more and the fixed width is 800px, it becomes ugly as it gets bigger. The header needs a maximum-width.
The problem there is the fixed width, not the header. People on big monitors shouldn't have to downsize their windows so that the content doesn't look goofy, that is back-assword.
I think the point of it is that you usually don't need a full-width header, so why mess up the alignment of elements on the page by using one?
No, the point is (or should be) that fixed width on a web page is almost always wrong. It will be either too big, or too small.
It is simply astounding the number of web pages that have poor appearance because the 'designer' never tested them on a different size monitor, or with different size fonts.
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.
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.)
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.
I always have vertical scrollbar visible, and for the exact reason of having the same window width between the pages. This is purely a matter of visual polish. There are very few sites where the polish does not matter (or matters less than "not messing with browser defaults), so yes, it is a necessity.
"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.
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%).
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! :)
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.
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 :-(.
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.
There's no reason the logo couldn't be aligned with the content, while still allowing the header banner to be full width.