How can I deal with too much blank space in a desktop application?

Question

Usually people are concerned with too much data/interface, and not enough screen real estate, but I'm in the opposite situation.

The desktop application I'm working on has several tabs for entering data and selecting options, and the final tab gives a summary of the data after it's been through some calculations.

One of my tabs is fairly complex, so I've set the application window size to 1024x768, in order to fit all the required GUI elements in. The problem is that a couple of other tabs are quite simple, and I'm left with too much blank space. I've tried two approaches so far:

• Initially the elements were clustered towards the top of the screen, but I didn't like the look of a huge blank space below it. Additionally, every tab has Save and Reset buttons at the very bottom of it, for consistency, and these buttons became too easy to miss when everything else was right at the top.
• I now have the elements spaced across the entire height of the window, but I don't like how spread out everything is.

I also still have a big space to the right. I've considered centering things, but I think that would look a bit odd for a desktop application.

Here is a screenshot of what I have at the moment:

One of my other tabs has essentially the same problem.

So my question is: How can I approach GUI layout when I have too much blank space and not enough elements to fill it?

Answer 1

If I understand your screenshot correct, then you have locations, which can have several buildings, which can have several rooms. But location is most upper level.

What do you think about have a tree view navigation on left with nodes of lower levels like building and rooms.

On right side you could have a properties view for its specific data and command buttons.

Its a master-detail pattern. But, you haven't all property data in one view, like you would have in a list view (what I guess you have right now). Still you have some blank space, but a vertical center line, for splitting left and right side, will lead the eye down to your buttons.

Answer 2

I don't see a problem leaving space below the content. Many applications/editors do it, Eclipse among others, and having this space in a window of static size is definitely better than having the window change sizes depending on which tab is selected. Changing windows in size with buttons moving across the screen will most likely only confuse and maybe irritate the user, in either case it will take away any potential feeling of appreciation of how efficiently you're making use of the window space.

However there are some other considerations I have. I would like to see you following the convention of having the button bar in the bottom right corner. This is the standard for Windows applications and it should be obeyed.

Furthermore, from my assumption I would assume that the "Reset" button will close the window and disregard all the actions the user has done in that view? Is that assumption correct? If I guessed right you really should change it. The simple indication of me feeling the need to ask if the "Reset" button does the same as a cancel button shows a lack in affordance. You should in this case switch the button text to "Cancel". But however, if it isn't a cancel button, and it does something else (loads previous settings from a configuration file? IDK) then you really should consider moving it. Because now it has the conventional mapping of a cancel button, which is to the right of the OK/Save/Confirm -button.

I've done a mockup for you to take some inspiration from. Just to display my idea, maybe you can take something from it. Good luck!

Answer 3

Maybe you have too many tabs. You could try combining the two sparse tabs into one, or put one sparse tab on each of the two remaining tabs, or maybe both sparse tabs on the simplest remaining tab, whichever makes most sense to your users (whichever puts the most similar controls together and would have a tab label that makes sense to your users.) Fewer tabs mean less navigation, which may be better too.

The other possibility is your complex tab is too complex. If users rarely need all that complexity (i.e., they usually take the defaults for most of the settings), then move some of less frequently used the controls from the complex tabs to one or more dialog boxes, and show only a summary of their settings in the main window. With this approach, maybe you can have no tabs. In a single pane you can have all controls for the two sparse tabs plus summary controls for the complex tab(s), and the summary tab can be eliminated.

Yet another possibility is that not everything belongs in one window. If the complex tab is the first or second thing the user works on, then maybe that should be a full-size primary window. From there, the users launch a small tabbed dialog (or wizard) to complete the remaining steps. Potentially the user can "initialize" the primary window with another small dialog at the beginning (like using an Open dialog). A primary window design would also open the possibility of letting the users save their work as they go (maybe as a "draft") while working on the primary window --always a good idea when there's complex work being done.

Answer 4

I like the TreeView navigation idea but I think it would have bad usability. I drew a wireframe for you to understand my idea better. It's kind of like TreeView but easier to navigate across many sites, buildings and rooms and it covers the empty space which you're concerned about. I call it "The Three-tier Architecture" and it follows OSX folder view.

I think the wireframe is pretty understandable.

The Breadcrumb

At the bottom I added a Bread-crumb view so users would have a better look of where and what they're navigating at.

Right Click

Each level would have a corresponding right click. Let's say if you're at a "Site" level then you'd see "Add site" or "Remove site" you won't see Add,remove buildings or rooms.

I hope you like this solution. It's easier to navigate and view and it reduces many clicks. You can add keyboard and mouse shortcuts to make it feel nice.

Answer 5

If I interpret the architecture of the screen correct, then it might be better to get rid of all of those groups and replace them with a TreeView control. That is, it looks like "Rooms" would belong to "Buildings" which would belong to "Sites". At the very least, it looks like "Rooms" and "Buildings" share a relationship.

Just have a ToolStrip bar:

Add Site | Add Building | Add Room | Edit | Delete

And then your TreeView:

Sites:
|--Site #1
|--Site #2
....|--Building #1
.......|--Room #1
....|--Building #2
|--Site #3
....|--Building #3

Which ever "node" is highlighted would be the item that gets edited or deleted.

This might create the opposite problem of filling in the space on the right side, in which case, you might be able to move the "properties" information of a selected node to the right side, sort of like a PropertyGrid.

Answer 6

The vertical space is the problem here I think. Is there a way to adjust the window height based on the tab selected?

Answer 7

Could you choose a different mechanism other than a drop down with a couple of buttons to present your Sites, Buildings and Rooms? Maybe a series of Grids -- Let the user edit/delete/add directly in the grid.

I also second Michael's comment that perhaps you should look to combine or otherwise reorganize your tabs and their contents.

Answer 8

As you have drop downs in all the four input regions, it would be natural to have them laid out horizontally rather than having all one below the other as now.

That way, you could rearrange the UI elements to distribute them better. You will still have blank space in the lower half, but it will then look more like a provision for the drop down.

Answer 9

Perhaps you could fit all 3 "Configure" sections side by side in the top third of the tab and have a graphic filling the bottom 2 thirds that updates according to what they select. Or of not a graphic, a text summary of everything they have done so far.

Answer 10

Most OS X applications handle this by simply resizing the preferences window so that it's the perfect size for each tab. If your "preferences" window is separate from the application, users shouldn't mind if it changes sizes on them. The motion should be fluid obviously, but this kind of behavior has never been jarring for me when done properly. Example: