User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Nowadays most screens are wide and high-resolution, but when a typical web page loads it leaves on the sides huge empty areas. I understand that designers don't want their content to be messed up on different devices, but isn't it a violation of user experience (and on mouse's scroll wheel)?
In which aspects Wikipedia pages are worse than other websites?
It depends. Too many characters in a web page will harm the readability of your text. If your web page is mainly text, will be difficult for your user to read.
However there are sites that uses all the space available, allowing a nice reading experience. In some cases, there isn't enough content to fill the sides of the screen so they use blank space at the sides.
In my opinion, is preferable to make user scroll than forcing him to read a wide block or text.
Historically they made sense like that. Now we have responsive design.
In theory you can have your site cover all screen sizes, however time, scope and analytics may suggest it's not always worth it.
Also, information is harder to digest when spread too wide so design and information architecture come into the picture even more.
It depends on the page content.
If the content is volume-based (lots of images for example) then making the most use of the whole screen could be a good thing as, arguably, user will be able to see more items at any one time. (Although this approach may also run into 'Choice Paralysis'.)
However, if the content is mainly text (like Wikipedia) then we have to think about readability. Optimum reading line length is somewhere between 45 and 75 characters - somewhere between 7 and 14 words per line (http://baymard.com/blog/line-length-readability). If the lines are longer they become more difficult to read as the end of the first line moves further away from the start of the next line - The reader finds it more difficult to move smoothly from one line to the next.
A site may choose to use a narrower layout to avoid this.
As for scrolling, most users expect it and don't even notice that they're doing it (http://uxmyths.com/post/654047943/myth-people-dont-scroll). (I'm sure I've seen a study that even said that younger users actively leave pages that don't scroll... but I can't find that right now.)
While it may fit to sites that always printed in columns, e.g. newspapers, it's one of the worst hyped UX designs ever almost anywhere else, IMHO:
It's a waste of 50+% of the (here 24") screen estate I, you, my company, all of us paid for.
It's against one of the original main design goals of HTML: Dynamic rendering at the user agent.
I.e. send the requested information to the UA just simply marked up and let the decision how to present it be made there. Depending on the user agent's (default) settings, depending on the user's adaptions to the defaults according to her/his personal preferences.
Years passed...all was good..."If it ain't broken, don't fix it!" was respected...but...somewhen...in a moonless storm-cloudy night...with bloodcurdling howl...
Wall street aficionados with their marketing and sales geeks took over worldwide. Relatively narrow-minded: Money! At all [others'] costs! Narrow minds give birth to narrow columns, apparently.
Potentially unprofitable artists, graphics designers, developers, etc. and all their bosses joined in. Understandably, they have to pay their bills.
It began to be a no-brainer. Sometimes in double sense.
Things it was never intended for to handle were thrown onto the whole Internet but it made it! Genius design guys, from the very beginning! Hats off! To some R.I.P., sadly.
Later on Divitis broke out.
Things were done just because they can be done.
... and much more I'm a bit tired meanwhile to say over and over again ... maybe next time ...
I fervently hate narrow, fixed-size column especially at sites, including SE, where programming is a topic, where code is entered/displayed in almost every posting.
When in a list here at SE I'm limited to 88 chars code, 70 in edit mode, at 100 % view size (with my setting):
1 2 3 4 5 6 7 8 9 0
123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789 123456789
See SO: Output the console text of a Jenkins job that my Job is running for a real-life example. (It's even worse there. You even have to scroll vertically inside the [main] content.)
70? 88? Really? Apart from that the latter is a Nazi code the now ancient punch cards introduced in the 1890s (yes, 1...8...no typo) had 80 columns already. That's not that much of an advance.
And we have 20+" widescreeen monitors in every kid's room and modern GUI IDEs nowadays.
Do I have to mention that wasting 50+% of my horizontal space AND forcing me to scroll horizontally in the very same moment is a really @§$%&#!...a really bad idea?
Dont' ask me, don't remind me of the dozens of – first Greasemonkey, then Tampermonkey – userscripts I wrote to make such pages comfortably read-/writeable. And how often I had to adapt them because DOMs change frequently. (See, for instance, JANITOR – Java API Navigation Is The Only Rescue which I stopped maintaining with Java 16, we are at 19 now, since I had to adapt it with almost every of the newer versions. )
