Best UI design principle for an app with several windows?

I’d like to get your POV about how you design a desktop app with several (in my case it will be 12) windows that should each be accessible via the same way. I’m not sure what the latest “standard” is for something like, so I looked around and found several examples that I’d like to list up here. Please feel free to add your own examples via screenshots:

The classic menu bar:
x

x
x
x
x
x
The toolbar:
x

x
x
x
x
x
Apple’s dock (it’s like a toolbar but at the botton, maybe animated as you go over it?:
x

x
x
x
x
x
Custom tab panel (or the normal tab panel in Xojo:
x

x
x
x
x
x
Microsoft surface tile design (guess especially good for touchscreens):
x

x
x
x
x
x
This question is in reference to the one I asked a bit earlier, on how the different windows are seamlessly displayed (see link here:

Also, what do you think about going away from the standard (like Apple’s UI HI Guideline) of NOT having a menu bar additionally to navigate? Would a new design confuse the user too much or will eg a Microsoft Surface tile design be familiar to the new generation of mobile app users (remember, we’re talking about designing a desktop app here!)?

Thanks in advance for your comments and ideas,

Andreas

FWIW I had one my app rejected last year from the Mac App Store for not having a Window menu. It was not really necessary because I provided prominent buttons to switch windows, but the reviewer cited the HIG.

as Michel said, remind the HIG and don’t move too far away from it if you do not want your Apps look alien or being rejected. Keep also in mind that users have different approaches to navigate through apps. For instance i am using keyboard a lot and hate to lose focus of controls or the lack of menus or shortcuts. try to put everything into the menus and let only the recent used or most used functions in your toolbars left (or make it customizable).

The shown register view is kinda old school and doesn’t fit into current Mac OS or iOS design schemes.

To view it from scientific view try to measure the click paths through our apps, how far (in pixels) a user has to move cursor or mouse to get certain tasks done. is he/she distracted by a lot of icons or unneeded information? believe me, it’s hard to keep an interface clean and uncluttered but in the end you will be rewarded for this.

Design a workflow and the rest will follow. And do the window menu.

Sounds too easy, doesn’t it? Seriously, how are your users supposed to work in the application? Write down how your users typically and untypically would interact with your app. When in doubt, observe your users either with the app or with a prototype (computer OR paper).

To summarise what I hear so far (hope more will get their view in):

  • menu is a standard and needs to be in every desktop app (two reasons, users are used to it and Apple HI guidelines)
  • panel is old-school
  • toolbar is ok

That leaves currently no comments on Apple’s dock and the Microsoft Surface tiles

I do think there are a lot more desktop app developers here, please get your view in. Besides, the app doesn’t have to be for Mac OS only, it surely should be for Windows as well

Andreas

The dock can display additional information, like it’s doing something special. But it can’t be used with navigation. Some applications like Rapidweaver use a tile-like design when nothing else is visible. This helps getting new users started.

[quote=123447:@Beatrix Willius]Design a workflow and the rest will follow. And do the window menu.

Sounds too easy, doesn’t it? Seriously, how are your users supposed to work in the application? Write down how your users typically and untypically would interact with your app.[/quote]
Morning Beatrix,

early morning riser, right? It’s 7:38am in Germany :wink:

I should have given more info about the desktop app. Each window is a single module by itself, supported by a Financial window, a Setup/Admin window and an Analytics window. The rest like I said are windows where different modules (functionalities of the backend app) are being monitored and can be changed.

The desktop app is the frontend app, it’s communicating with a node.js backend app and receives summarised data from the node.js app directly from a NoSQL database. So there will be a lot of charts on the individual screens, showing performance figures over time.

There is no workflow in such a sense as there is an order to how the user has to go through the windows. Actually some windows aren’t even enabled for all users (like the Admin/Financial window) as it applies only to special groups. Users might be assigned to only 1 or 2 modules (windows) and will alternate between them. Other users might switch between the Analytics windows and the Financials window.

The main purpose is for monitoring a 24/7 live app and perform A/B tests which will lead to small changes in the setup of the different modules, all the while keeping an eye how the financials/main KPI’s are affected, supported by analytics.

Hope that makes it a bit clearer from a workflow perspective, thanks for that remark (should have given that info earlier on but you reminded me)

Don’t ask a Mac user what he thinks about Windows Metro “Design” (cough) scheme… :slight_smile:

But regardless any UI discussion: Grab a piece of paper and a pencil, make use of simple scribbles… think about your users and you can graphically assist them in fulfilling tasks. Think about your grandparents (or anybody else without knowledge in computers) : Would they be able to get into your app?

Haha ja very early here in Germany :wink:

When it is kinda monitoring app, showing a lot of charts and graphs I woulnd’t waste valueable screen space for huge tiles a la Metro. Think about it…

[quote=123454:@Tomas Jakobs]Haha ja very early here in Germany :wink:

When it is kinda monitoring app, showing a lot of charts and graphs I wouldn’t waste valueable screen space for huge tiles a la Metro. Think about it…[/quote]
Noted (as we say over here in Asia), I kind of like it for the idea that Beatrix pointed out. To guide your new users through the app, like Rapidweaver seems to do (checked it only quickly). It’s the kind of hand holding screen which can be turned off by a little checkbox in the lower left corner that says “never show again”.

But you are right in that it represents a totally different scheme (ahem) and is more suited for web users and touch screens where it’s pretty normal that a new page is being displayed (and the one with the tiles/metro design is vanishing completely) and the user than has to press the back/return button (or use the corresponding key) to get again to the overview screen with the tile/metro scheme.

We use two levels of toolbars at the top of the screen — top one with icons, lower one without — works well.

Hmh, not sure I understand how it will look. Do you mean the lower one has only text in it or what is in the second, lower toolbar? Could you provide a screenshot to explain better?

Also, if I might ask, what is the purpose of providing two toolbars under each other? It’s taking quite some retail space I suppose

This is how our two-toolbar menu looks:

Thanks @David Cox for posting a screenshot, as they say “A picture says more than a thousand words”.

What is the idea behind using two toolbars and in this app’s case, what tasks did you put into the second, lower toolbar and what was your train of thought to go with two in the first place?

I have to say this is something I have never seen been, how do your users react to it? Still thumbs up for coming up with such a new idea!

The top toolbar has the major sections and for each major toolbar item we have a minor toolbar that is displayed. The minor toolbar then controls what functions the user can perform within the window. If you have a massive number of options, it simplifies the GUI choices to just those applicable. Some of the minor toolbar items pop-down such as Export to PDF/CSV/XLS/Tab…

@David Cox now I understand, so it displays a certain hierarchy in the toolbars, like the Xojo example toolbar (called ToolbarExample) uses a drop down button to further display contextual menu points (like for the toolbar push button Charts it displays then Line, Pie, Bar etc as submenus so to say.

That makes it so much clearer now. So we have another new UI design to choose from. What do others think?

[quote=123448:@Andreas West]To summarise what I hear so far (hope more will get their view in):

  • menu is a standard and needs to be in every desktop app (two reasons, users are used to it and Apple HI guidelines)
  • panel is old-school
  • toolbar is ok

That leaves currently no comments on Apple’s dock and the Microsoft Surface tiles[/quote]

I would not use the Apple Dock to drive an app. That would be awfully confusing for the user. The dock is here to launch apps and open documents and users get accustomed to that behavior. In a way, the dock is nothing else than a bottom toolbar dedicated to launching programs. You could very well create a toolbar animated the same way. I am not quite sure it brings anything useful beyond cuteness, though.

Microsoft tiles are what welcomes the user in a Windows RT (surface), but also in Windows 8 and 8.1 apps. From what we know of Windows 9, they are still there, but the question remains as if they will be the fault, or if they will only appear in the new Start menu.

I think they are pretty cool. And could be implemented on a Mac without major issue. In a way, they are not quite alien to the Mac universe. The iBook metaphor is very close to that, and the icon view in the finder, though smaller, has some similarities.

Implementation of tiles seems pretty easy. Bevel buttons or canvas, and you are in business. Planning navigation may prove a bit more complex, as tiles do take a lot of real estate. As noted, they are great for touch screens, and I would think for visually impaired users as well. Now, how do you marry tiles and what follows ? After clicking a tile, where do you land ? If it is in the regular windowed environment, it may feel odd. If like the Windows 8 Metro interface, you get to a full screen with controls and other tiles, then you may find some coherence.

The most important, besides providing the standard menu that reassures users, is to conceive your tiles to be intuitive enough and not too numerous. Basically, they are a graphical menu, and should not overwhelm the user with too many choices. But well applied, it can be very nice.

It goes without saying that they will be perfect in a Windows app, where users are already familiar with that interface.

I wonder whether you really want your app to use several windows. If you do then there will have to be a windows menu; it is what Apple requires and what your users will expect. That doesn’t mean you couldn’t provide alternatives on top of that, keyboard shortcuts being an obvious choice. Or maybe tiles, if you believe your users would love these.

A toolbar or a row of tabs, on the other hand, are for navigating between different views within a single window. Using these interface elements for switching between different windows would be seriously confusing. So again I wonder whether you really want to have several windows or whether switchable views within a single window would do the job just as well – in that case a toolbar or tabs would become an option again. Obviously it depends on whether you need several views to be visible at the same time; also when the views would be very different sizes it might be better to use different windows.

You know, Michael, I should have read again the OP :

The big question is indeed whether the 12 windows should be displayed simultaneously, or as usual, closed and opened according to navigation. Twelve windows open at the same time is untenable. Windows opened according to which tile is clicked, though poorer, is not without similarities with a toolbar or the options in the Windows menu.

Now what the OP did not explain is the navigation after the initial selection with all the choices discussed. Will it be only hierarchical, as the Window menu does where you have to come back to change window, or transversal, with buttons or other means that conduce to other windows, or conditional, where the content input by user opens or close windows ?

I got an app rejected once because it lacked a “Window” menu. I had never thought of putting one since the app could only have one window and didn’t handle documents. The HIG was cited.

So, following the HIG, even when it doesn’t make sense, as long as your app is not broken by it, it’s good sense. If your app can’t work within the HIG (for example, a game with a custom UI) then Apple might be willing to let it go, but for most cases the HIG is law.