Studio Interface Suggestions


#1

(first off, thanks for the update. Looking forward to the 2.4 patch, and dev, should dev be a part of that.) Oh, and this is all just my opinion.

Thought it might be a great time to suggest potential interface changes/improvements, and start a thread for others input.

  1. Since this application had an origin of character animation and speed, I thought I would look at what “slows me down” when I go to use this app, and focus on speed and ease of use.

a. The main thing that i am noticing about where the interface bogs me down, is, when a “list” block precedes another more important block. Re-arranging block order should or might be an easy cut and paste code change. Often times, I am spending too much time moving and resizing the block divider. Parameters, buttons, tabs and settings should precede the item list, or feature lists, or whatever lists as usually you can keyboard (arrow keys) through lists anyway. Let the lists block for a given tab, always flow down to the bottom and autosize, rather than struggling with autosizing your parameter setttings. Examples of good flow, would be CUSTOMIZE, PLAY, COMPOSE, EDIT. The “poorer” layouts for me, are RENDER, where I find myself always moving BASIC PROPERTIES, SHADER, SPLINE around (due to how it autofits), with some conflict with the materials list. Here, the materials list takes more screen dominance than it should. Try putting the materials list below so the parameters are more static. I realize that this wont affect people who work mostly with nodes.

b. Rapid navigation of the interface, is cluttered down by the above, being forced to resize block arrangements, and lack of some needed default hotkey assignments. I suggest considering these hotkey options.

-F1, F2, F3, F4 are FANTASTIC ways to flip between world and tab/block groups. I think this is one of studio’s nicer idea’s and should be extended.
-F6 toggles between graph editor and dope sheet. Which is excellent. I think another key, should toggle between “graph editor taking 1/3 of verticle screen” and “back to just the dope master.” I dont think that key should switch wether the graph/dope is being displayed, just the amount of screen space that selection is currently taking up. This would eliminate more mouse dragging of dope/graph block resizing. Resizing with the mouse is really slow. You could even have two settings for this key, like a “shift” to make the graph more prominent.

Doing the above, might not take a lot of programming effort, and could really speed up workflow I suspect.

I would love to hear others comments and suggestions.

-Garin


#2

I do remember sort of bringing this idea up before, although not this descriptively.

I do realize that one of the replies was “my monitor is set to show a greater amount of pixels, so I never have to resize windows or blocks and wouldnt need this.” (or something similiar to that.)

As features and attributes of messiah studio grow, I suspect that eventually everyone would want the kind of layout I mentioned in the previous post. Let the “list” blocks rest on the bottom of the window and flow naturally, keep the parameter fields above and less movable. This will be easier for newbies to work with too. The arrow keys already offer pretty fast hotkey access to “list” elements.

Thanks again pmG for sending out another update.

-Garin


#3

Also in this vein of suggestions:

  • dual-monitor flexibility
    (right now you are basically limited to lining up the item-list partition between monitors, discussion eventually leads to dockable windows…)

  • the very keen suggestion to integrate key-type buttons into the transform or the curve editor panel. Right now the “open-panel-adjust-return-to-transform” is a bit bothersome. I find myself using the alt-scrub tcb tweaking method more than its good for.

Also:
I still find the key selection methods unintuitive… I’d rather be able to select channel keys, tweak tcb just for those, NOT have to set channel setting and then key or range and then tweak…

Taron? Fred?


#4

Those would indeed be good.

I wouldnt mind floating windows, that can all go away/return with a tab key like in lightwaves layout. Hotkeys bringing up whole window panes of info without a lot of resizing would likely just be as fast. I just keep envisioning the display shifting up, sliding back down, to the side, etc, and returning to your current workspace a la 1, 2, 3, 4 style.

I just now noticed the other, older thread that mentioned interface stuff, with some nice UI mockups. Lots of field info access in one window is definately good, rather than hunting around a lot.

Quite a while ago, Thomas mentioned “and if you have a horizontal equivalent to F1, F2 and F3 that allows to show or hide the panels, I would vote strongly for this “Animation Powerhouse” idea.” That probubly summed up what I was trying to say, and with fewer words!

Who knows. These ideas have been floating around for some time. Maybe when dev comes out everything will click into place. . .


#5

I personally find that I’m constantly going through all the top set of tabs, setup, animate, render etc… It’s nice to have everything in it’s place but it can sometimes feel like I’m being slowed down by that. I’m not sure of how to improve that but it’s a little issue that I have.

Another thing that is niggling at me is the material section. When clicking on a material & getting the basic material properties, it bugs me that you have to drag the property window upwards to view it all…why can’t it scroll?..maybe something like Max’s tool system where you can expand everything & then scroll up & down or drag through it?


#6

Its interface design completely ripped hard on Messiah. They’ve done away with tear off interfaces, its there but its not the focus. Quick keys switch what mode you are in. I.e Editing, effects etc.

I hope that Messiah goes that route of giving their users an option to tear off windows and put them on second monitors, I think they are really listening you should all should keep requesting it.


#7

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.