What are multiple windows good for?

As a matter of fact, on an usability course at my university, it was stated that child windows are in fact designed for showing the same data from multiple viewpoints. It was said that such applications are in practice rare, but a cad program is definitely one of them.

I agree that there’s a kind of conceptual point of putting views of the same object to the same window, but then the inconsistent viewhandling issue is back again. Child windows can be thought of as viewpoints inside one window, only with a unified user interface.

-Ilkka

Well, the way I view it is like this: according to the currently dominant UI paradigm, you have multiple document interfaces - where typically you have one document per window. Microsoft changed this slightly, but opening up new instances of the app for each new document. The window then contains a document view - which, for a cad program can be full perspective or split into viewports - or configurable (as max is). But max isn’t mdi - you can only work on one file at a time (at least to version 4 this was the case).

Well, I guess we could go on with this forever, but I’m afraid I still can’t agree with you.

You should never have multiple documents inside one window, mdi or not. It’s just some old program centric thinking (this is my program and these are the documents inside it). Very understandable from programmers, but in general people tend to think data- or object centric. Imagine two documents on a desk, if you put the other one away, the other still stays there. That’s why Microsoft opens a new window for every document.

Of course these are difficult issues which should be solved through testing, not reasoning, but in this case the guidelines seem clear to me (the famous last words of a user-interface designer). Don’t let the stupid name, multi document interface, fool you.

-Ilkka

I’m gonna have to disagree with JustHanging. The tabbed MDI interfaces of Mozilla and Opera are much better than IE’s interface. I switched my sisters over to Mozilla and they can’t live without the MDI now (not to mention mouse gestures).

The problem with MDI in the past was that it was implemented poorly. The tabbed interface makes it blatantly obvious that there is more than one document open. Blatantly obvious is good. In the past you would have to do a bunch of tom-foolery with menus to switch between MDI documents.

When I have friends over they ask, “Do you have the internet? I want to check my webmail.” Of course I don’t “have the internet”. I have a connection to the internet. Rather than being pedantic, I open up Mozilla for them. To most users, the browser is the internet. And each tab is some page/site on the internet. With IE, my dad never really uses more than one browser window. How can you have more than 1 internet? That’s impossible.

So it is not really “old program centric thinking”. It’s that users are used to the Windows way. Which is unfortunate, because they have made it easy for the user to get up and going, but very difficult for them to learn to become efficient and multitask.

]Mmm, no that is something that would be known as a “hack” on the Mac, obviously, but the spec for wglMakeCurrent on the little known “Microsoft Windows” system makes it clear that sharing render contexts between windows is perfectly legal and handled elegantly.

My apologies

from the way you describe the way the Mac OS handles windows (you give it a bitmap for it to display, while you render into that bitmap?) sounds pretty limiting to me - a backward step?..no clipping to overlapping windows means more rendering to do which won’t even be seen, unless the occluding window is moved.

Possibly less rendering, actually, since moving windows requires no extra rendering on the part of the application. It also allows for things like true transparency in windows, since the window server has all the necessary information to recomposite, without requiring the application to re-render. It also means that the compositing step can be handled on the graphics card, which would otherwise be idle most of the time.

It’s a good job that my renderer is designed for MS Windows only…

Sounds like it

Originally posted by PK:

The problem with MDI in the past was that it was implemented poorly. The tabbed interface makes it blatantly obvious that there is more than one document open. Blatantly obvious is good. In the past you would have to do a bunch of tom-foolery with menus to switch between MDI documents.

Absolutely and Microsoft is now moving back towards tabbed MDI, check out studio 7 for example.

Originally posted by JustHanging:
Marcus, I wouldn’t leave the child windows out if I was you. They are, in terms of usability, considered propably the best option for applications like modelling programs, where data is examined from several viewpoints.

I see your point, but then I’m facing this problem:

GLFW is a multi-platform API. If I expose “child windows” through the API, I need to decide between A) Use the platform specific child window paradigm (which isn’t even defined for some platforms), and B) Make a strict and platform independent definition of what a child window is, and implement it exactly the same way for all platforms.

To me, B) is the most appealing solutions. Not only is it a stronger API specification, it also means that the GLFW user knows exactly what behaviour to expect from his program, regardless of which platform it is running on.

So, should it be A or B? If B, what should the exact specification of a child window be?

Originally posted by OneSadCookie:
Possibly less rendering, actually, since moving windows requires no extra rendering on the part of the application. It also allows for things like true transparency in windows, since the window server has all the necessary information to recomposite, without requiring the application to re-render. It also means that the compositing step can be handled on the graphics card, which would otherwise be idle most of the time

Sounds good - when will MS Windows be changing over to this method? I wouldn’t have thought it would be difficult to change to this way of doing things, even keeping the existing paint handling messages, etc.
I’m being practical, Macs are not practical in the simulation market.

Yeah, you might be right. Take my words as coming from an educated kid with no real experience. I still think the way things should be handled, in general, is to have the documents (models, texts, whatever) there, and when you open a document, around it are the tools to manipulate it. That is, a program. And all documents should be handled independently of each other. Web browsers don’t really fit in this analogy, since there isn’t much to manipulate.

As for Marcus’ question, I really don’t know. It depends on how big the differences are between different systems. But since you have to do some default thing for systems that don’t support child windows, I guess you might as well go with B. Altough it would stink to have non-windows type windows in a windows enviroment. On the other hand, programmers propably prefer B, and they are your target audience…

Child windows are windows that belong to the client area of the parent window, but I don’t know if it’s a sufficent definition.

-Ilkka

I guess this is where we get to the nutpicking, but I have to add…

Having given PK:s example some more thought, if there’s only one internet like PK says, then the different pages can be seen as different views of it. In that sense Mozilla uses MDI exactly the way I said it should be used. Apparently your sisters have proven this a good solution.

Anyway, sorry for being a pain in the ass, I just can’t help myself. I find usability very interesting, almost as interesting as graphics. I’m gonna go now, have a nice weekend.

-Ilkka