This question is a bit more subjective, but I'm hoping to get some new perspective. I'm so used to designing for a certain screen size (typically 1024x768) that I find that size to not be a problem. Expanding the size to 1280x1024 doesn't buy you enough screen real estate to make an appreciable difference, but will give me a little more breathing room. Basically, I just expand my "grid size" and the same basic design for the slightly smaller screen still works.
However, in the last couple of projects my clients were all using 1080p (1920x1080) screens and they wanted solutions to use as much of that real estate as possible. 1920 pixels across provides just under twice the width I am used to, and the wide screen makes some of my old go to design approaches not to work as well. The problem I'm running into is that when presented with so much space, I'm confronted with some major problems.
- How many columns should I use? The wide format lends itself to a 3 column split with a 2:1:1 split (i.e. the content column bigger than the other two). However, if I go with three columns what do I do with that extra column?
- How do I make efficient use of the screen real estate? There's a temptation to put everything on the screen at once, but too much information actually makes the application harder to use. White space is important to help make sense of complex information, but too much makes related concepts look too separate.
- I'm usually working with web applications that have complex data, and visualization and presentation is key to making sense of the raw data. When your user also has a large screen (at least 24"), some information is out of eye sight and you need to move the pointer a long distance. How do you make sure everything that's needed stays within the visual hot points?
- Simple sites like blogs actually do better when the width is constrained, which results in a lot of wasted real estate. I kind of wonder if having the text box and the text preview side by side would be a big benefit for the admin side of that type of screen? (1:1 two column split).
For your answers, I know almost everything in design is "it depends". What I'm looking for is:
- General principles you use
- How your approach to design has changed
I'm finding that i have to retrain myself how to work with this different format. Every bump in resolution I've worked through to date has been about 25%: 640 to 800 (25% increase), 800 to 1024 (28% increase), and 1024 to 1280 (25% increase). However, the jump from 1280 to 1920 is a good 50% increase in space--the equivalent from jumping from 640 straight to 1024. There was no commonly used middle size to help learn lessons more gradually.
To help focus the question a little bit, I had a project that was somewhat similar to Atlassian JIRA, an issue management system. There were about six different types of records the client wanted to keep, all of them could potentially be related to each other. Gathering data wasn't the core problem, although it did play a part.
The more important side of the problem was creating a system which would suggest potential relationships between the records, and helped the analysts recognize patterns in the reported incidents.
There were different types of analysts that focused on the different problem domains, and due to the nature of their exploratory type of work, they didn't know what they wanted. They just knew they had to make sense of a lot of data, draw correlations, and characterize classes of issues.
(Originally asked here: http://programmers.stackexchange.com/questions/45864/how-do-you-conquer-the-challenge-of-designing-for-large-screen-real-estate, but told that this might be more appropriate)
For the bounty: Stretch your minds a bit. The pat answer "Make everything bigger" has a limit to how useful the answer is. We are talking about users who have to make sense of a lot of data and find relationships between records. If I simply bump up the size on everything they are going to be very limited in what they can see on screen--particularly because the vertical is so constrained.