Hi,

I am the maintainer of Kwave, a sound editor for KDE, which is a SDI application since it's earliest start. Recently the discussion about the "GUI style" (or however it is called) came up, to offer the user the possibility to swith to "MDI" style. Additionally I see the possiblity of a "tabbed" design, like in Kate and other programs.

Unfortunately I was not able to find some guidance about this topic in the KDE HIG.

My question: are there any guidelines from the designer's point of view?

Some "preferences" or some kind of "general rules"?
Something like do not use ... - prefer ... instead,
or ... is out of fashion, new applications should use ... ?

thanks,
Thomas

My suggestion is that if there's a really really good reason to use the same window to house multiple "docs", use tabs to maintain consistency with most other modern KDE and non-KDE applications. But without a good reason, I suggest sticking with SDI and take advantage of the common workspace functions (window manager) to let the user navigate between multiple "docs".

Yes, we probably need something in the HIG. Thomas, Heiko?

The HIG on tabs says "Use tabs [...] to manage multiple documents", so there's that, but indeed we have no HIG saying when to use tabs and when to use SDIs or traditional MDIs (i.e. windows within a window). And yes, it would make sense to write one.

The choice between SDI and MDI comes down to with how many documents users usually work at the same time. Tabs in browser have became so successful because they came at a point in time where people started to often have several websites open at the same time, cluttering their taskbars if each was in a separate window. The same goes for Kate, which is geared towards programmers, who often have several files open in parallel.
Traditional MDIs may come in handy in image manipulation programs, where multiple images have to be viewed at the same time for comparison or easy copy & paste.

For example in office applications, however, people usually focus on a single document (maybe one more for reference, but hardly ever a dozen of them at the same time).

So, since you probably know your users and their tasks with KWave better than we do, you know the answer better than us: Do KWave users often work with several files at the same time, or is it usually just, say, no more than three? If they have several fiels open at the same time: Do they need to see them all at once, or is it okay to switch between them using tabs?

As Andrew said, for a few documents, the window management does all you need with an SDI. If people have lots of files open at the same time, however, all the "chrome" around the display of each document becomes annoying, and a classical or tabbed MDI would be helpful.

From the KDevelop world I can say that tabs work quite well as long as you're sure all tabs will fit in the tab bar. As soon as there's a significant chance you will get scroll buttons they are very very bad and a list like kate has it by default is much better. So if you're sure your users don't need more than maybe 8 or something documents open at once, tabs are a good choice I think. But I guess that is sort of obvious.

colomar wrote:...but indeed we have no HIG saying when to use tabs and when to use SDIs or traditional MDIs (i.e. windows within a window). And yes, it would make sense to write one.

Your posting is almost guideline-ready
Despite from the fact that I think tabs are a good solution I'd like to add the idea to use a stacked and scrolling layout similar to kdenlive. For instance, if I want to merge two waveforms it makes sense to align them by frames. But that depends all on the use cases. The advantage of tabs is the option to fast switch between them which makes a visual pattern comparison possible.

Thanks a lot for your suggestions and your advice

Unfortunately I don't have any kind of reliable statistics, but I guess that most users may have "some few" files open at a time, most of them probably only one at a time, which is an argument for using tabs.

However, the comparison with image manipulation programs is quite good, I think MDI has the advantage over tabs that one could easily work with drag&drop between multiple (sub)windows. So as there is no such thing as a "do not use MDI" rule and MDI was not officially declared a deprecated feature, I will add the possibility to switch the GUI to MDI (or SDI, per default).

BTW: any idea how the menu entries should be named?
"Options" / "Graphical Interface Type" / Single Document Interface (SDI)
"Options" / "Graphical Interface Type" / Multiple Document Interface (MDI)

=> is the term "Graphical Interface Type" the right one ?

thomas.eschenbacher wrote:Unfortunately I don't have any kind of reliable statistics, but I guess that...

Would you like to ask users? UX group supports you in those questions. PM me if you are interested in a survey.
About text: I'm not sure that normal users neither know what MDI and SDI is nor what they do with this option. What's about "Open new files in tabs" according to browsers?

In KWave's case, it might indeed make sense - as Heiko suggested - to simply stack the files vertically instead of allowing to move and resize each in its own window. It could make sense to just play with both options and see what feels better.

As for the menu: I'd just use Options -> "Open files in the same window (MDI)"

Well, some "vertical stacking"... that sounds like a non-standard way to me, and I would prefer conforming to well known standards, so I would use standard MDI behavior for the first approach, without any restrictions. IMHO moving/resizing each open file within it's own window might make sense. Maybe I add some "auto stack windows vertically" setting somewhere later, I will put it on my TODO list...

Thanks for the menu text, your version should be much easier to understand. As I want to put that setting into a sub menu (with exclusive selection / radio buttons), what about this?

Settings / Open Files in... / Same Window (MDI)
Settings / Open Files in... / Separate Window (SDI)

thomas.eschenbacher wrote:Well, some "vertical stacking"... that sounds like a non-standard way to me, and I would prefer conforming to well known standards, so I would use standard MDI behavior for the first approach, without any restrictions. IMHO moving/resizing each open file within it's own window might make sense. Maybe I add some "auto stack windows vertically" setting somewhere later, I will put it on my TODO list...

Sure, that's completely fine!

Thanks for the menu text, your version should be much easier to understand. As I want to put that setting into a sub menu (with exclusive selection / radio buttons), what about this?

Settings / Open Files in... / Same Window (MDI)
Settings / Open Files in... / Separate Window (SDI)

What's the rationale behind putting it in a submenu?
It works, though, and the extra step to enter the submenu isn't a problem because people probably won't change it often.

colomar wrote:What's the rationale behind putting it in a submenu?
It works, though, and the extra step to enter the submenu isn't a problem because people probably won't change it often.

Hm, I gave it a try, but it did not look good, looked a bit "messed up" among the other entries in the menu.