Live data from Hacker News

Design annoyances

codefastdieyoung.com

11–20 of 30 posts

Re: Design annoyances

#11

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…

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.

Re: Design annoyances

#12

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 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.

Re: Design annoyances

#13

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…

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?

Re: Design annoyances

#14
post #7

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 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.

Re: Design annoyances

#15
post #7

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.)

Re: Design annoyances

#16
post #15
post #7

Earlier quoted context omitted.

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.

Re: Design annoyances

#18
post #9

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.

Re: Design annoyances

#20

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...

And OS X Lion's new "hidden" scrollbars.
Post reply on HN