Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
Maybe it's time to revisit this requirement: "every tab has Save and Reset buttons at the very bottom of it, for consistency". If they were next and back buttons for navigation I could see the consistency being justified, but here they are buttons for saving the data as displayed in the view. –  Erics Dec 22 '11 at 5:47
maybe in a pop-up if it is a one-page setting –  Naoise Golden Dec 22 '11 at 11:24
The form is huge, is it possible to subdivide any of the other form pages into separate steps? Smaller pages would be easier to organize effectively as well, and would make the first page (likely) less intimidating, though there will appear to be more steps. –  Ben Brocka Dec 22 '11 at 12:35
Are these problems theoretical, or have you observed them in your users? That is, have you seen them fail to notice the Save button or react very negatively to the aesthetics? I'm not saying the current design is fine, but it's important to know what's at stake so that the cure isn't worse than the disease. –  Michael Zuschlag Dec 22 '11 at 14:19
Looking at your screen shot, am I to understand that this tab is for creating lists of sites/buildings/rooms and then the users provide details/relations for each on the next tab? –  Michael Zuschlag Dec 22 '11 at 14:30
show 1 more comment

10 Answers

up vote 4 down vote accepted

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.

share|improve this answer
I think this is what I'm going to end up doing. You are correct that sites have buildings, which have rooms, creating a tree structure. I think I'll change it so that the data is presented as such, with Add/Remove/Edit buttons at the right, which affect the currently selected node. –  Cam Jackson Jan 2 '12 at 23:34
Wait a minute, TreeViews usually are harder to use then what you have now. Are you really sure implementing a treeview would be an Usability advantage? –  Barfieldmv Jan 3 '12 at 7:09
add comment

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.

share|improve this answer
I like your suggestions, but I'm not sure they would really work for me. The problem is that there's a definitive flow from one tab to the next. The data is quite hierarchical, and changing data on one tab can have significant consequences for data on the next tab. So each tab kind of represents a discrete stage of the data entry process. –  Cam Jackson Dec 22 '11 at 4:57
@Cam Is dividing the complex tab not practical then? So it becomes two separate tabs, and then all of the tabs are smaller? There may not be a clear reason for the break, but that should not matter if it is done carefully. –  Schroedingers Cat Dec 22 '11 at 9:14
@Cam If there's a definite flow, you probabably don't want tabs, but a wizard. See ux.stackexchange.com/questions/3121/… for a similar question. It doesn't necessarily solve your problem, except that wizards traditionally have simple steps per page, which can make Dr. Schroedinger's suggestion all the more apt. –  Michael Zuschlag Dec 22 '11 at 14:06
@Cam more. That there's a sequence of input also gives me an idea for "yet another possibility" that I've added above. –  Michael Zuschlag Dec 22 '11 at 14:12
@SchroedingersCat Good suggestion. I could perhaps divide the next data input tab into two, but the final 'Summary' tab has a similar space requirement and kind of has to stay as it is. It presents a very high-level summary at its bottom (3 dollar figures), a detailed breakdown at its left, and a list of assumptions/caveats in the data at the right. The data and its inherent assumptions must be on the same page, to cover my arse. I don't want users complaining that they used a dollar figure for some purpose, not realising the assumptions that had gone into calculating it. –  Cam Jackson Jan 2 '12 at 23:27
show 3 more comments

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!

enter image description here

share|improve this answer
My guess was that the Reset button would reset the current view to the original values, but not close/quit. –  Erics Dec 22 '11 at 11:17
@Erics you might be right. But in that case I think it should be displayed elsewhere. And if it is resetting of all settings then where is the cancel button? I don't want to be forced to press save when I don't want any changes to be made. And assuming that the user in this case should press the standard window X doesn't feel correct either. –  AndroidHustle Dec 22 '11 at 11:36
The Reset button undoes all of the changes, resetting the data to the state it was in after the last save. Perhaps I'll change the text and/or location of the buttons, something to think about. –  Cam Jackson Jan 2 '12 at 23:20
add comment

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.

share|improve this answer
This is called [Miller Columns](en.wikipedia.org/wiki/Miller_columns). –  dnbrv Mar 6 '12 at 22:35
add comment

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:

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

share|improve this answer
Yep, you've understood everything correctly, and I think that your suggestion is what I'm going to do. Or I might place the buttons at the right instead of the top, not sure yet. Unfortunately, FrankL beat you to this suggestion though! –  Cam Jackson Jan 2 '12 at 23:40
add comment

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

share|improve this answer
Possibly, but I think it would be too distracting to the user to have the window changing size all the time. –  Cam Jackson Dec 22 '11 at 4:53
Not necessarily. When a window changes size in a way that reveals more stuff as a response to the user's action, it's not distracting. It's a system response that gives them info as they need it. –  Todd Sieling Dec 22 '11 at 4:56
On windows though applications are often "maximised" to fill the full screen. –  Erics Dec 22 '11 at 5:44
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
By the way, I wonder why you have the "Add Something" Button under the drop down. What happens to it when the list is displayed? –  Kris Dec 22 '11 at 11:09
Laying everything out horizontally is a possibility, I might have to try it and see how it looks. As for the button positioning, I'm not sure. I just felt like the Add should be separate from the Edit and Delete buttons, and because the added thing will appear in the next drop-down below, putting the button below seemed sensible? To be honest, I'm not really happy with the button layout. –  Cam Jackson Jan 2 '12 at 23:37
add comment

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.

share|improve this answer
add comment

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:

Adium's File Transfer window Adium's Advanced window

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.