Celestia UI redesign

[t00fri]

Chris,

I send you a mail to explain my points

Why do you have to discuss these things via PM with Chris?? Don't you think that some of us are also interested in your "points"?

Otherwise, I can as well get back to my other activities...of which there are plenty these days.

F.

[t00fri]

Chris,

...it's a question of general philosophy of the GL window. To me a major point is to preserve the integrity of this window. Dockable panels just interact too much with the GL view...

I previously emphasized strongly what Christophe is repeating here. I think this IS really a crucial point.

We should find a way to give more "automatic" priority to a largely unobstructed 3d display area. It is NOT enough that all these tool panels can be closed somehow. In other words , all tool panels should have a somewhat "transient" status.

But how to do it appropriately and in a flexible manner?

Perhaps a good and quick way to select one of these panels is via a pop-up listing, appearing when the right mouse button is pressed?

How about the saving policy on exit concerning the opening status of these tool panels?

One might even use a setting to customize such policies according to gusto or needs. "Educational users" might like to have more persistent panels with info text than the pure simulation guys?

I think tabbed panels are quite satisfactory in general.

Another widget type that is critical are toolbars. Since long non-editable toolbars will always offer a host of functions that many users don't want, toolbars must be composable and notably they should incorporate a GUI dialog for easy customization (dragging the desired toolbar icons over from a passive storage area to the active toolbar area, i.e. the proven AND familiar procedure)!

Some users, for example, would much prefer to replace those trivial toolbar icons for time-speed navigation by some space for bookmark icons or for some other less obvious function. I much prefer just hitting L K J <space> \ keys instead of spoiling my 3d canvas with YET another trivial toolbar .

etc.

F.

[ElChristou]

I do agree with Fridger, specially with his last lines...

So start making some UI mock-ups, then.

Chris, as I said to you via mail, with DW we have already done some serious thinking on the topic and our conclusion (taking in account many aspects) result in only one choice. (see this topic)

Now this is of course not compatible with your choice of dockable panels inside the GL windows which to me represent the destruction of the feeling of space... (imho, so precious to Celestia)

I do understand perfectly the reasons of such choice, I suppose that if I was a serious boy I would agree with it, but my artistic side just told me it's not a nice solution for Celestia.

Sorry to repeat the mail, but as I've said what I had to say, now I'll stay as spectator following the next steps.

[Chuft-Captain]

OK, I'll wade in with my 2CW:

I have no problem with them being dockable (eg. could be useful when designing/debugging addons) as long as they are also un-dockable for the times when you want to display the main GUI fullscreen.

CC

[chris]

Chris,

...it's a question of general philosophy of the GL window. To me a major point is to preserve the integrity of this window. Dockable panels just interact too much with the GL view...

I previously emphasized strongly what Christophe is repeating here. I think this IS really a crucial point.

We should find a way to give more "automatic" priority to a largely unobstructed 3d display area. It is NOT enough that all these tool panels can be closed somehow. In other words , all tool panels should have a somewhat "transient" status.

But how to do it appropriately and in a flexible manner?

Perhaps a good and quick way to select one of these panels is via a pop-up listing, appearing when the right mouse button is pressed?

Is that better than selecting a panel from the Views menu? It's easy enough to add an option to the right-click menu, but the Views menu (or Windows or Tools) seems like a more standard way of doing this. But, perhaps I'm missing the point here . . .

How about the saving policy on exit concerning the opening status of these tool panels?

That should already be working. The arrangement of the panels: whether they're visible, docked or undocked, locations, sizes--it's all saved and restored between runs of Celestia. If the default for a new installation of Celestia is to have these panels hidden, then someone could choose to use Celestia without ever seeing anything but the 3D window.

One might even use a setting to customize such policies according to gusto or needs. "Educational users" might like to have more persistent panels with info text than the pure simulation guys?

I think tabbed panels are quite satisfactory in general.

Tabbed panels such as the current Qt4 celestial browser, with tabs for deep sky objects, stars, and solar system? Or something more extensive? We could put all the tools into a single tab dialog. The disadvantage of this is that that it doesn't work so well if you want to have more than one tool open at a time. One thing that Qt4 does is automatic tab stacking of dockable widgets. If you drag one dockable widget on top of another, they'll overlay each other, and you can then tab between them. The problem I see with this is that it's a little unintuitive--more often than not, you end up resizing the dock.

Another widget type that is critical are toolbars. Since long non-editable toolbars will always offer a host of functions that many users don't want, toolbars must be composable and notably they should incorporate a GUI dialog for easy customization (dragging the desired toolbar icons over from a passive storage area to the active toolbar area, i.e. the proven AND familiar procedure)!

Some users, for example, would much prefer to replace those trivial toolbar icons for time-speed navigation by some space for bookmark icons or for some other less obvious function. I much prefer just hitting L K J <space> \ keys instead of spoiling my 3d canvas with YET another trivial toolbar .

That toolbar is intended for novice users--an experienced user can hide it by unchecking it in the view menu. Is that sufficient?

--Chris

[chris]

I do agree with Fridger, specially with his last lines...

So start making some UI mock-ups, then.

Chris, as I said to you via mail, with DW we have already done some serious thinking on the topic and our conclusion (taking in account many aspects) result in only one choice. (see this topic)

Now this is of course not compatible with your choice of dockable panels inside the GL windows which to me represent the destruction of the feeling of space... (imho, so precious to Celestia)

As I've stated, with dockable panels, you have the choice of using them inside the main window or undocked. I much prefer having the solar system docked when using it. When not simply exploring, I use the browsers for many operations, and I find it much more convenient not to have to shuffle windows around. Lack of space is generally not a problem because I run at 2560x1600 resolution.

I do understand perfectly the reasons of such choice, I suppose that if I was a serious boy I would agree with it, but my artistic side just told me it's not a nice solution for Celestia.

There are serious users of Celestia that we need to accommodate, and I think that dockable panels do just that without compromising your use of Celestia. How are undocked panels different than dialogs?

Sorry to repeat the mail, but as I've said what I had to say, now I'll stay as spectator following the next steps.

No need to be just a spectator . . . I welcome your UI recommendations, even though I happen to disagree with you on this one.

--Chris

[t00fri]

...
We should find a way to give more "automatic" priority to a largely unobstructed 3d display area. It is NOT enough that all these tool panels can be closed somehow. In other words , all tool panels should have a somewhat "transient" status.

But how to do it appropriately and in a flexible manner?

Perhaps a good and quick way to select one of these panels is via a pop-up listing, appearing when the right mouse button is pressed?

Is that better than selecting a panel from the Views menu? It's easy enough to add an option to the right-click menu, but the Views menu (or Windows or Tools) seems like a more standard way of doing this. But, perhaps I'm missing the point here . . .

Well the argument would be that a user who is generically "at work" with the mouse coursor in the 3d canvas can instantly activate any of these pannels with a right mouse click. Hence with my proposal, the mouse movements and menue search efforts, respectively, are minimized.

How about the saving policy on exit concerning the opening status of these tool panels?

That should already be working. The arrangement of the panels: whether they're visible, docked or undocked, locations, sizes--it's all saved and restored between runs of Celestia. If the default for a new installation of Celestia is to have these panels hidden, then someone could choose to use Celestia without ever seeing anything but the 3D window.

This I am aware of, Chris. The new aspect was to CUSTOMIZE the saving policy! Hence the "educational guys" could be made happy with every pannel being saved upon exit (as it happens now) while the "simulation fans" would enjoy restarting with a 3d canvas that has NO open tools initially. But these guys could QUICKLY open one of them with a right mouse click, if desired...

Tabbed panels such as the current Qt4 celestial browser, with tabs for deep sky objects, stars, and solar system? Or something more extensive? We could put all the tools into a single tab dialog. The disadvantage of this is that that it doesn't work so well if you want to have more than one tool open at a time. One thing that Qt4 does is automatic tab stacking of dockable widgets. If you drag one dockable widget on top of another, they'll overlay each other, and you can then tab between them. The problem I see with this is that it's a little unintuitive--more often than not, you end up resizing the dock.

Here I have no definite opinion yet. But as a start we could assume the present scheme.

Another widget type that is critical are toolbars. Since long non-editable toolbars will always offer a host of functions that many users don't want, toolbars must be composable and notably they should incorporate a GUI dialog for easy customization (dragging the desired toolbar icons over from a passive storage area to the active toolbar area, i.e. the proven AND familiar procedure)!

Some users, for example, would much prefer to replace those trivial toolbar icons for time-speed navigation by some space for bookmark icons or for some other less obvious function. I much prefer just hitting L K J <space> \ keys instead of spoiling my 3d canvas with YET another trivial toolbar .

That toolbar is intended for novice users--an experienced user can hide it by unchecking it in the view menu. Is that sufficient?

--Chris

NO toolbars might very well be sufficient for you and me, for example.

But again my point was different. I strongly feel that ONE long CUSTOMIZED toolbar should be enough for almost everyone. Hence in this case, the canvas would not be overly cluttered with toolbars, of which half the users only care for a few items!

BUT...everyone must easily be able to customize his/her toolbar with the proven & familiar GUI dialog. KDE has it as a standard, so Qt4 probably has this also in prefabricated form. Just reread what I was writing initially. I don't think I need to repeat the remaining arguments again.

F.

[ElChristou]

...As I've stated, with dockable panels, you have the choice of using them inside the main window or undocked. I much prefer having the solar system docked when using it. When not simply exploring, I use the browsers for many operations, and I find it much more convenient not to have to shuffle windows around. Lack of space is generally not a problem because I run at 2560x1600 resolution.

That's perhaps why we don't see the same things; one good point to define before building any UI is what is our basic/default resolution. I'm not sure of this but actually 1024 is still the norm, no? Have you tested the Qt version on a 1024?

[chris]

...As I've stated, with dockable panels, you have the choice of using them inside the main window or undocked. I much prefer having the solar system docked when using it. When not simply exploring, I use the browsers for many operations, and I find it much more convenient not to have to shuffle windows around. Lack of space is generally not a problem because I run at 2560x1600 resolution.

That's perhaps why we don't see the same things; one good point to define before building any UI is what is our basic/default resolution. I'm not sure of this but actually 1024 is still the norm, no? Have you tested the Qt version on a 1024?

I use it all the time on my MacBook, which is (I think) 1440x900. But, the variety of screen resolutions at which people run Celestia underlines my point: there needs to be a choice for widget layout in Celestia, and that's exactly the point of dockable panels.

--Chris

[dirkpitt]

Dockable panels might be good, but how about tabbed interfaces too? (e.g., the long-forgotten supertab experiment)

Echoing Fridger's sentiments, I personally like Adobe's approach. Hitting the tab key in Photoshop for example instantly hides/shows all tool palettes. Very simple and effective.

[Chuft-Captain]

That's perhaps why we don't see the same things; one good point to define before building any UI is what is our basic/default resolution. I'm not sure of this but actually 1024 is still the norm, no? Have you tested the Qt version on a 1024?

A specific resolution should never be a consideration in UI design. -- It should always be designed to be independent of resolution.

choice

That's the key word alright!

[ElChristou]

That's perhaps why we don't see the same things; one good point to define before building any UI is what is our basic/default resolution. I'm not sure of this but actually 1024 is still the norm, no? Have you tested the Qt version on a 1024?

A specific resolution should never be a consideration in UI design. -- It should always be designed to be independent of resolution...

Right, but it must "work" on all resolution. A UI designed/working on 1024 will work on a larger screen. The contrary won't be true. It's why choosing a base resolution is useful. It's the same procedure for web design...

[ElChristou]

choice

That's the key word alright!

In absolute, yes.
In practice, it depends on what you really want to show/express.

Taking Celestia as example:

To me the most precious thing about Celestia from a graphic point of view is it's GL window, synonyme of space (space here must be seen as the notion of distance). This (again to me) must be preserved at all cost because it's THE (graphical) particularity of Celestia.

If you take this point as base, you will end in front of a dilemma:

- You give all the freedom (choice) possible to the end user giving him the possibility of the best AND the worst. (see image below)

- You limit the possibilities to avoid the worst (but you must work harder to give the best - more complicated at level of design)

***

This shot is the worst possible thing (to me, related to the notion of space) a end user can do with the actual Qt UI. So the basic question is do we want this to happen?



***

To resume, what would be nice before starting to build the UI would be to have some precise idea of what we want Celestia to show, to transmit.

Note: Whatever the consensus will choose is not important to me; the above is to be sure all aspect (not only practical ones) will be taken in account...

[selden]

ElChristou,

Most modern graphics cards have two separate outputs, which can drive two separate displays with completely different information on them. Relatively inexpensive displays (lcd or crt) are available.

Un-dockable (tear-off) menus can be moved to the secondary display, while the primary display contains only Celestia's 3D window, completely unobstructed.

Is this functionality available on your Mac?
I've certainly seen people dragging windows from a Mac laptop screen onto a secondary display when using a projector for a public presentation.

[ElChristou]

ElChristou,

Most modern graphics cards have two separate outputs, which can drive two separate displays with completely different information on them. Relatively inexpensive displays (lcd or crt) are available.

Un-dockable (tear-off) menus can be moved to the secondary display, while the primary display contains only Celestia's 3D window, completely unobstructed.

Is this functionality available on your Mac?
I've certainly seen people dragging windows from a Mac laptop screen onto a secondary display when using a projector for a public presentation.

Of course Selden! I do use 2 screens, one full screen, one for panels.
Now this is the optimum solution but still a particular case. In the case of designing a UI we must start from the worst config, not the better. Just like for 1024 vs 2560, we cannot take a 2 (or more!) screen as basis!

Again, I'm not in favor or not of any system, the ONLY point I'd really like to see is the preservation of the notion of space given by the actual version...

[ElChristou]

Chris,

I send you a mail to explain my points

Why do you have to discuss these things via PM with Chris?? Don't you think that some of us are also interested in your "points"?

Sorry Fridger, I miss this post.

The mail to Chris was to remember him the SuperTab experiment we do with DW on osX a time ago and as I wanted to send him the test app, I done this by mail. No secrets here!

[chris]

Dockable panels might be good, but how about tabbed interfaces too? (e.g., the long-forgotten supertab experiment)

I like tabbed interfaces, with some caveats:
- Putting every panel into the same tab box prohibits using more than one tool at a time. This is ok in many cases, but not always.
- There are differences in how the various panels will be used: a tool panel like the star browser will tend to be used often and for an extended period of time, whereas the preferences dialog will be accessed only infrequently and for a brief time (and the preferences dialog I'm describing here is for constellations in Latin, coordinate display, etc., not often used controls like turning orbits on and off.)

Echoing Fridger's sentiments, I personally like Adobe's approach. Hitting the tab key in Photoshop for example instantly hides/shows all tool palettes. Very simple and effective.

This is an excellent idea. Tab is currently used for auto-complete, but I'm sure there's another suitable key.

--Chris

[chris]

Another widget type that is critical are toolbars. Since long non-editable toolbars will always offer a host of functions that many users don't want, toolbars must be composable and notably they should incorporate a GUI dialog for easy customization (dragging the desired toolbar icons over from a passive storage area to the active toolbar area, i.e. the proven AND familiar procedure)!

Some users, for example, would much prefer to replace those trivial toolbar icons for time-speed navigation by some space for bookmark icons or for some other less obvious function. I much prefer just hitting L K J <space> \ keys instead of spoiling my 3d canvas with YET another trivial toolbar .

That toolbar is intended for novice users--an experienced user can hide it by unchecking it in the view menu. Is that sufficient?

--Chris

NO toolbars might very well be sufficient for you and me, for example.

But again my point was different. I strongly feel that ONE long CUSTOMIZED toolbar should be enough for almost everyone. Hence in this case, the canvas would not be overly cluttered with toolbars, of which half the users only care for a few items!

BUT...everyone must easily be able to customize his/her toolbar with the proven & familiar GUI dialog. KDE has it as a standard, so Qt4 probably has this also in prefabricated form. Just reread what I was writing initially. I don't think I need to repeat the remaining arguments again.

I tend not to use the time toolbar, but I'm actually quite fond of the guides toolbar right now. There aren't key shortcuts (on the Windows version) for enabling and disabling the various object orbits, and the toolbar is much faster to use than the view options dialog.

I'm not convinced that we should have one toolbar instead of several. The time toolbar seems like a very natural collection of actions. But, I agree that we should allow the toolbars to be customized. It doesn't seem to be as easy as I'd hoped--Qt4 doesn't offer customizable toolbars as a built-in widget type, so we'd have to write quite a bit of custom code. But maybe I'm missing something . . .

--Chris

[ElChristou]

- Putting every panel into the same tab box prohibits using more than one tool at a time. This is ok in many cases, but not always.

Apart the case of the info panel when could we need various panes simultaneously?

Concerning the info panel, could it be possible to have a auto-refresh function at object selection? (in both browser and GL windows)

[chris]

- Putting every panel into the same tab box prohibits using more than one tool at a time. This is ok in many cases, but not always.

Apart the case of the info panel when could we need various panes simultaneously?

Perhaps for drag and drop between tools? Suppose that I have the orbit plotting tool open and want to select an object to plot. I could either type in the object name or drag it from the solar system browser. Perhaps the eclipse finder could work in a similar way.

Concerning the info panel, could it be possible to have a auto-refresh function at object selection? (in both browser and GL windows)

Yes, this would be possible. The info panel needs a lot of work, btw--it is intended more as a placeholder to demonstrate some of the extended information that we could show.

--Chris