Mai Tai: General Discussion: UI Design

Joshua Marinacci	Posted: September 28, 2009 18:44 by Joshua Marinacci » Permalink
	This is a thread to discuss issues in the UI design, including ideas that will go into V2

Joshua Marinacci	Posted: September 28, 2009 18:45 by Joshua Marinacci » Permalink
	A test reply to see if I get messages.

lqd	Posted: September 28, 2009 18:54 by lqd » Permalink
	Test reply

pdoubleya

Posted: November 13, 2009 09:12 by pdoubleya

» Permalink

Hi Josh!

I just downloaded MaiTai and wanted to provide some very early, first-look UI feedback. This will include a number of issues I'm sure you're aware of.

First--I want to say I'm very impressed by what you have so far. This is much more, and a much better quality UI, than I would expect for a first code drop. Kudos.

Second, I won't list obvious UI bugs here, but will instead put those in the issue tracker.

This is a brain dump, and I almost hesitate to send it, because I think overall this is very impressive work, and it might come across as a bunch of negativity or whining. But I think I would use MaiTai once it's been polished up, which is saying something as I normally have 0 to do with UIs.

In no particular order, here goes

all elements/nodes labels in the node list on the left should use standard capitalization (lowercase might actually be cool as it would be different from what i expect). I think you're using Title Case for those composite nodes, but my first impression was "this is sloppy"
some sort of grouping of the nodes on the left may be nice. i am sort of tired of expandable tree views; maybe collapsing panes?
selecting nodes from the left list--i kept wanting to drag and drop instead of double-click
selecting nodes from the left list--adding a node (by double-click)==> new nodes should *never* overlap existing nodes in the grid, period
on the grid, i would like a visual identifier distinguishing composite nodes (Replicate in Space) from normal node types; a simple double-click could then expand them, replacing the edit button
on the grid, would it make sense to distinguish data pumps (e.g. which generate values constantly) from static nodes like Text View? i'm having a hard time on, e.g. "comet" visually identifying the source of the action, other than via the name "random generator"
i think freemind has an action/button where you can re-center a mind map after scrolling around--may be nice to re-center the screen, for example, via button click
clicking on the grid background sets the properties panel to an empty panel, but with Block:, Input and Output labels still there. rather, there should be some context switch of "i'm not editing any node properties right now"
"quit" probably shouldn't be right next to "new"
it's unclear to me given the way nodes are linked visually whether i am allowed to have outputs from two different nodes attach to a single input/property for another node. the UI lets me, but what does this mean?
in the properties pane, there's no indication that a property is linked already. in "comet" the Particle Generator's angle is receiving an output from Random Generator, but I am still allowed to edit the angle in the property view--what does this mean?
can i have multiple screen nodes? what would that mean? maybe, for the default case, there would be a single (ouput) screen, anchored on the right edge (middle, vertically) of the screen, or something like that, rather than a screen node.
for the screen(s), would like to see the inputs labeled somehow in the edit pane; right now it just reads input/delete, input/delete
would be nice if the bird's eye view control had mouse support, so i could drag the viewfinder where i wanted it
on opening an existing demo, i'd expect it to be centered at least vertically, and possibly with some node in the center as well, perhaps the screen? something to organize my view of the node graph when it appears on screen
a collapse button for nodes (showing only title) may be useful
node names/labels may be useful
in the node views (within the grid), the unlinked properties/attributes appear as empty (white) circles, and the properties with links are in red; i'm wondering if the unlinked properties could (optionally) disappear until a drag operation over the node, as currently they can take up a lot of vertical space in the node (e.g. for Text View). i just noticed the double-click action to collapse the unlinked properties, that's nice
why is there an FPS counter at the top of the screen?
the popout button for the preview pane doesn't change after popping out. should it?
add 1-2 points of inset *everywhere*; lots of crowding, needs to breath a little more
i think the color scheme is going in the right direction, but i find the contrast of the black text on the grey background makes the text hard to read; different shade of grey?
in the properties pane, what the heck are those checkboxes for?
in the props pane, i like the round slide control, but it's pretty darn small (esp the knob). not sure the best solution, though. one idea would be a UI effect like the keys on the iPhone KB--hover over the knob control, it "expands" (in the top layer) to a larger view, then shrinks again on mouse out

Just a lot of little nits. Very nice work, Josh (and contributors, if any)!

Patrick

Joshua Marinacci

Posted: November 16, 2009 22:24 by Joshua Marinacci

» Permalink

Thanks for the great feedback. Here's replys to most of your questions.

* all elements/nodes labels in the node list on the left should use standard capitalization (lowercase might actually be cool as it would be different from what i expect). I think you're using Title Case for those composite nodes, but my first impression was "this is sloppy"

Currently most blocks are specified in code. A few are in separate modules where the metadata is in XML. The app does no processing of the text, so if the capitalization is wrong then it's simply a typo. I think we should go with capitalization of the first letter of the first word, and lower for the rest.

* some sort of grouping of the nodes on the left may be nice. i am sort of tired of expandable tree views; maybe collapsing panes?

I agree. I just haven't figure out how the grouping should happen yet. All nodes are tagged, so really we need a list of tags/categories or a tag cloud. Tags are the underlying organization regardless of how we visualize it.

* selecting nodes from the left list--i kept wanting to drag and drop instead of double-click
Yep. Please file an issue on it.

Regarding the general positioning of new nodes. I agree that the current solution sucks, but I haven't figured out what's better yet. Should DnD be the only way? I really like navigating the list and adding nodes purely with the keyboard. What if new nodes stack with each block slightly down and to the right so that you can still see all of the titles?

# on the grid, i would like a visual identifier distinguishing composite nodes (Replicate in Space) from normal node types; a simple double-click could then expand them, replacing the edit button
# on the grid, would it make sense to distinguish data pumps (e.g. which generate values constantly) from static nodes like Text View? i'm having a hard time on, e.g. "comet" visually identifying the source of the action, other than via the name "random generator"

I agree we need more visual differentiators. Suggestions? Quartz Composer (QC) uses color and whether the corners of the block are rounded. I was hoping some of our more UI oriented people on the list could do some mockups. (hint hint remy!)

* i think freemind has an action/button where you can re-center a mind map after scrolling around--may be nice to re-center the screen, for example, via button click

Yes, though really we shouldn't have such a huge canvas. The canvas should be smaller and grow to accomodate the nodes you've added. QC does this.

* it's unclear to me given the way nodes are linked visually whether i am allowed to have outputs from two different nodes attach to a single input/property for another node. the UI lets me, but what does this mean?

One output can go to multiple inputs. An input can only be connected to one output, however. Anything else is a bug. Please file it with instructions to reproduce it.

* "quit" probably shouldn't be right next to "new" Smile

yep. i want to switch to a real menu once it's available in FX (using Swing menus have other issues. Quit should probably move to the other end of the toolbar. Can you file an issue on it?

* in the properties pane, there's no indication that a property is linked already. in "comet" the Particle Generator's angle is receiving an output from Random Generator, but I am still allowed to edit the angle in the property view--what does this mean?

Hmm. It used to be that the text fields of bound inputs were disabled. I must have broken that. Please file a bug.

* can i have multiple screen nodes? what would that mean? maybe, for the default case, there would be a single (ouput) screen, anchored on the right edge (middle, vertically) of the screen, or something like that, rather than a screen node.

Right now all of the screen nodes will stack, but that's a bug. Really you should have only one screen node per physical screen, and it shouldn't be deletable. Eventually there will be a concept of remote screens that you can configure, letting you talk to multiple screens at once.

* for the screen(s), would like to see the inputs labeled somehow in the edit pane; right now it just reads input/delete, input/delete

What should their labels be?

* would be nice if the bird's eye view control had mouse support, so i could drag the viewfinder where i wanted it

yep. please file an issue on that.

* on opening an existing demo, i'd expect it to be centered at least vertically, and possibly with some node in the center as well, perhaps the screen? something to organize my view of the node graph when it appears on screen

yep. please file an issue. it's supposed to remember the size and position of the window, but it doesn't right now.

* a collapse button for nodes (showing only title) may be useful

double click on the title of the node to hide it.

* node names/labels may be useful

you mean the ability to rename a node / input with a custom name? yep. please file.

* in the node views (within the grid), the unlinked properties/attributes appear as empty (white) circles, and the properties with links are in red; i'm wondering if the unlinked properties could (optionally) disappear until a drag operation over the node, as currently they can take up a lot of vertical space in the node (e.g. for Text View). i just noticed the double-click action to collapse the unlinked properties, that's nice

since we have the double click to collapse I'm not sure what you are asking for here. Some sort of auto-hide/unhide?

* why is there an FPS counter at the top of the screen?

to tell you the current FPS. It strives for 30fps, but can't always do it if you have a complex scene.

* the popout button for the preview pane doesn't change after popping out. should it?

change to what?

* add 1-2 points of inset *everywhere*; lots of crowding, needs to breath a little more

yep. lots of ui polish is needed. I'm hoping to get some mockups of a new UI.

* i think the color scheme is going in the right direction, but i find the contrast of the black text on the grey background makes the text hard to read; different shade of grey?

yeah. please file an RFE.

* in the properties pane, what the heck are those checkboxes for?

Smile

very under documented. When you have a nested block you need to be able to specify that some inputs are exported to the higher level. The checkbox does this. There are some other things which must be done on each input as well. We should probably move all of that stuff into an action dropdown or right click menu.

* in the props pane, i like the round slide control, but it's pretty darn small (esp the knob). not sure the best solution, though. one idea would be a UI effect like the keys on the iPhone KB--hover over the knob control, it "expands" (in the top layer) to a larger view, then shrinks again on mouse out

ah. every nice. please file an RFE. I like it!

Thanks for you feedback Patrick. I really appreciate it. BTW, do you prefer forums or email lists?

davenz

Posted: November 19, 2009 22:15 by davenz

» Permalink

Ditto on the draggable "birds-eye"viewfinder.

Don't know if it was already noted, but personal preferences for the knob behaviour;

- although the natural expected behaviour for a knob is to rotate it, in software this is quite an unnatural gesture IMO - to have to make constant circular movements with the mouse. I use (or at least used to) quite a bit of DAW software, and it seemed the prevailing behaviour for the application GUI and plugins was for a mouse drag up or down on an onscreen knob to rotate it left/right.

- clicking on the marker on an onscreen knob seems to make it jump to value. Say for example the Comet sample; if I click on the properties for the Particle Generator, the original value for the Size parameter is 24.444. If I click on the marker for the knob controlling this parameter, it jumps to 4.631. I think knob behaviour should be to scale an existing value, not to jump when the knob is touched. This behaviour only really makes sense to me if the knob is controlling a fixed and marked set of values - e.g. 1 to 10 etc.

- when knobs are rotated such that a value is maxed or nixed out, the knob should 'bottom out'; by this I mean that if I rotate a knob such that the value reads 0, I shouldn't be able to continue rotating the knob. In the present GUI I can do this, and if I then want to increase the value I have to rotate the knob n number of times until eventually it goes above zero.

Perhaps switchable GUI behaviour for this stuff? Sorry if the explanation is a bit vague Tongue

Dave

Joshua Marinacci

Posted: November 20, 2009 05:27 by Joshua Marinacci

» Permalink

The draggable mini-view is on my list to be implemented soon.

The reason for the knob is to have a single UI control that can be used for both large and small value adjustments (by rotating close or far away from the axis), and to support infinite range. I still think it's a good idea (and in fact Quartz Composer uses them as well) but as you have discovered there are some downsides.

To avoid doing the circling gesture (which is easier on a trackball) you can use the mouse wheel, which also supports an infinite range. Just hover over the knob and use the wheel. You can also hold down the shift key change the value faster (it applies a multiplier to the additional value).

The position of the knob does represent an absolute value. Angles, for instance, go from 0 to 360 and the position reflects this. The challenge is that the range of each knob depends on the particular input line you are modifying, but all of the knobs look the same. You don't really know what a knob will do until you try it.

Because of these issues I'm considering a few changes:
* make the knobs grow and have a focus glow when you mouse over them. this will give you a larger target to use.
* give you the option to use spin boxes instead of knobs if you want.

davenz	Posted: November 19, 2009 22:17 by davenz » Permalink
	Also, I quite like the nascent grey colour scheme. Like Apple Logic, it's not particularly colourful - but is very easy to work on for extended periods of time.

Joshua Marinacci	Posted: November 20, 2009 05:27 by Joshua Marinacci » Permalink
	Thanks. I want to improve the UI by making it smoother and more rounded, but I plan to keep the overall dark to neutral scheme.

George Birbilis	Posted: December 08, 2009 13:22 by George Birbilis » Permalink
	why not use XML-based skins or SWING L&F (if you're using Swing) or something?

Joshua Marinacci	Posted: December 10, 2009 17:52 by Joshua Marinacci » Permalink
	Mai Tai is built in JavaFX so we'd use the skinning capabilities there. The next version of JavaFX will have improved CSS skinning, so we'll probably switch to that once it's released.