Managing multiple windows in one application

Question

I am developing a desktop application to create, arrange and read blocs of sounds, via a grid interface like this :

Each bloc of sound is of different nature and has its own panel to control its parameters (with sliders, spinners, etc). My first approach was that, when a user clicked a bloc, its parameter panel would appear in the main window, to the right of the grid, reducing the grid's width. When another bloc was clicked, the panel was replaced by the one relative to the bloc clicked.

I later realised I wanted it possible to manipulate several bloc panels at the same time, without having to constantly click on the desired bloc. So my new UI approach was to have a seperate window for each panel, and now each time a bloc is clicked, its parameter windows (there are actually several windows for a single bloc) appear in the top left of the screen. I can move them around, hide them (by clicking on the red cross, or clicking elsewhere on the grid), and when I click the bloc again they appear at the same position on the screen as I left them, which is cool.

The only problem really is that the first time a bloc is clicked, its windows appear on top of each other, in the top left corner of the screen. Before getting my head into where to show them the first time, I wanted to know if there were better UI approaches to my problem.

Thanks.

Answer 1

Two solutions I had in mind:

• If you estimate your users will open many such param windows:
  Open the params window inline. Make the rows higher to begin with, or expand them if you need to, but have each param window beneath its block. This will keep them associated so the user is clear on what they're working on.

• If you think just a few will be opened (let's say 3):
  You can create the association (between block and param window) with colors, or other means.
  Then you can combine the two approaches you've suggested:

  • Open a panel to the right of the main grid, but split it to several sections, each containing the info and parameters for one selected block.
  • Moreover, each of the sections (you can regard them as "docked windows") can have a pop out button (rectangle with an outward arrow to the top right) so it can float around as your second suggestion.
  • Popping out and docking panels is a well known paradigm, and I'm personally not fond of having tons of windows floating around. They tend to get in the way of the items you need to choose on the main panel.

Answer 2

I strongly suspect that as your application matures you will find you want to put some very common controls on the left of the tracks.

Once you have controls there at all, it is very natural to access other controls that affect the audio from there too, but with the user able to choose when to have them visible.

You are also likely to find that some of your audio blocks will have 'compound' effects - for example you'll want the controls for 'risset drum' followed by the controls for 'reverb'. That argues strongly for using width rather than height, so placing the extra controls in a wide but not very tall control under the track they control is good.

We've found that screen real estate is at a premium in Audacity. So I'd offer a toggle control on the panel at the side to show/hide the additional controls, and a toggle control on that additional panel to select between appearing over the tracks below it or displacing them downwards.

Answer 3

By using a new window for each block, things could get out of hand really fast when editing multiple blocks. (for example when editing 5+ blocks at a time)

A solution would be to use only one settings window at a time, and when a user selects multiple blocks, make editable only the fields that are safe to edit.

For example if you have name/start/end/volume (lame example) the name field will become blank and readonly and you could multiple edit start/end/volume. Of course you could leave the name editable too and it will put the same name on all blocks.

This is similar to how editing id3 tags works in winamp/wmp, etc.

*edit: some wrong wording