I certainly agree with your reservations on using the DAG as *the* user-manipulated UI, but I don't think it's entirely black and white. There are often two types of artists, those who love DAGs, and those who hate DAGs -- and even the ones who love DAGs can sometimes hate them :-)

From a high-level point of view, I'm personally not happy with hiding the

flexibility a DAG-based UI provides in favor of a mostly linear interface. I think it would be very helpful to figure out the most important reasons artists have for disliking DAGs, and pointing out the reasons DAG-based UIs can be unwieldy (even if completely obvious). Maybe we can come up with a "middle" ground (though I hate to use the word middle) which really improves on both approaches :-)

I like your spreadsheet idea a lot -- but I have concerns that it would be trading one form of visual complexity for another. It's really hard to say without some prototyping, of course.

It's something to consider!

-shea

On 10/17/06, Ken Bateman wrote:

I've independently been thinking of a similar imaging core for the last month or
so. Of course, I think it's a good idea. Logically, behind the scenes, everything should be in the form of a DAG. But I think that a raw DAG does not
make up a part of a good user interface.

Spreadsheets are in essence a DAG for performing numerical calculations, and I
would suggest that the user interface should take the form of a spreadsheet
since this is a model familiar to many users. Some cells would contain source
rasters, other cells would contain paths, vector graphics, or masks (or even
references to other functions), some cells would contain a function that referred to other cells for inputs, some cells could contain labels or comments,
and most cells would be empty.

_______________________________________________ Gegl-developer mailing list
Gegl-developer-rmKnrA0qjLN8ewv5kxBBegeohdPTXOoP@public.gmane.org https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

On Tue, Oct 17, 2006 at 03:55:56PM +0000, Ken Bateman wrote:

I've independently been thinking of a similar imaging core for the last month or so. Of course, I think it's a good idea. Logically, behind the scenes, everything should be in the form of a DAG. But I think that a raw DAG does not make up a part of a good user interface.

Spreadsheets are in essence a DAG for performing numerical calculations, and I would suggest that the user interface should take the form of a spreadsheet since this is a model familiar to many users. Some cells would contain source rasters, other cells would contain paths, vector graphics, or masks (or even references to other functions), some cells would contain a function that referred to other cells for inputs, some cells could contain labels or comments, and most cells would be empty.

The spreadsheet user interface is most useful when the data naturally fits into arrays.
For many everyday applications, this is the case. I don't see it for graphics, unless you are actually talking about a mosaic.

If you ignore the conventional meaning of the word "cell" in the above, though, what you have is very like a programming language. The traditional UI for a programming language has been ASCII text.

For a different one try a tree structure with crossreferences to labelled branches. Something like that has been done for the scripting language in some popular war game -- I'm not sure I ever knew which.

-- hendrik

On Tue, 2006-10-17 at 17:31 +0000, Ken Bateman wrote:

However, I argue that the spreadsheet model is mentally accessible to a much larger user base, and it does not reduce or limit the sophistication of the underlying image core DAG. Spreadsheets provide an easy learning curve and an obvious data model. I have met many people who lack technical sophistication that can still create and use spreadsheets.

Please provide specific examples as to how one would represent image processing operations in a "spreadsheet model." Not something abstract, but something concrete. Posit a workflow and represent that workflow as a spreadsheet. It doesn't have to be code (though that would be nice) but it does have to be clear and unambiguous. Also please explain the statement that image processing operations naturally fit into arrays.

I'd also point out that LabView (another product that uses a graphical DAG to do operations) is so easy to use that Lego thinks 10 year old can do it (check out Lego Mindstorms NXT). Last I checked no one is adopting the "speadsheet model" to make things easier for people.

What about a connected widgets visualization? Like some sound studio software works with. Boxes with input/output 'plugs'/'sockets' connected by 'wires' -- boxes might be color coded (eg yellow for clone, blue for transform..)
click+drag on box to move, ctrl+click to clone. (click to rename?) click on socket, click again on opposite type of socket to connect. Click on connected socket to reconnect this end of the wire to a different socket.
Click (or ctrl-click?) on wire to disconnect both ends. Right-click (as in bauxite) to add nodes or do other misc ops. This model might be slower to navigate with many nodes though.

The main (and only?) flaw of a tree-view visualization that is obviously a DAG is lack of detailed visual grouping, which is addressed by the above model.

On 10/17/06, Ken Bateman wrote:

I've independently been thinking of a similar imaging core for the last month or so. Of course, I think it's a good idea. Logically, behind the scenes, everything should be in the form of a DAG. But I think that a raw DAG does not make up a part of a good user interface.

The current user interface used in the prototype GUI of GEGL is an abstraction above the DAG that is a tree with clones. This allows expressing all DAGs that have sources (one output) filters (one input and one output), composers (two inputs and one output). This is the interface model I used in bauxite[1] , with the added ability to make some of the nodes in this tree be embedded graphs I think you have the best of both worlds. It shold also be noted that one of the operations in GEGL at the moment is the "layer", which is a composition of over (or another compositing operator), translate and opacity.

Spreadsheets are in essence a DAG for performing numerical calculations, and I would suggest that the user interface should take the form of a spreadsheet since this is a model familiar to many users. Some cells would contain source rasters, other cells would contain paths, vector graphics, or masks (or even references to other functions), some cells would contain a function that referred to other cells for inputs, some cells could contain labels or comments, and most cells would be empty.

Such a user inteface does not lend itself well to a user that wants to do image manipulation in the manner traditionally done by users of GIMP, an application that does something along these lines is nip2[2] the interface of the vips projects.

1: http://pippin.gimp.org/bauxite/ 2: http://www.vips.ecs.soton.ac.uk/index.php?title=Nip2

/OEyvind K.

On Oct 17, 2006, at 9:15 PM, neota-s8PdfxpoPdHk1uMJSBkQmQ@public.gmane.org wrote:

What about a connected widgets visualization? Like some sound studio software works with. Boxes with input/output 'plugs'/'sockets' connected by 'wires' -- boxes might be color coded (eg yellow for clone, blue for transform..) click+drag on box to move, ctrl+click to clone. (click to rename?) click on socket, click again on opposite type of socket to connect. Click on connected socket to reconnect this end of the wire to a different socket.
Click (or ctrl-click?) on wire to disconnect both ends. Right-click (as in bauxite) to add nodes or do other misc ops. This model might be slower to navigate with many nodes though. The main (and only?) flaw of a tree-view visualization that is obviously a DAG is lack of detailed visual grouping, which is addressed by the above model.

That is precisely the model used in labview, much sound studio software (like ProTools), high end compositing tools (like Shake), high end 3d modeling tools, etc. It is a DAG. Yes, it is color coded, but there is no rule that says a DAG can't be color coded. My real point, which I was going to get too, is that for every example of people using a spreadsheet model (1, really) I can point out why it's use is eventually discouraged, and point out 5 other examples where is DAG interface is used in the real world.

I have to say that the Shake UI is one of the most approachable ones I have seen. You can put someone in front of it and in 10 mins they can get something going. It may not be the prettiest in the world, but it reallly focuses the user.
Contrast that to the Toxik interface which just looks wonderful but has a very high entry point for new users ...

my $0.02

Piotr

On 10/18/06, Daniel Rogers wrote:

On Oct 17, 2006, at 9:15 PM, neota-s8PdfxpoPdHk1uMJSBkQmQ@public.gmane.org wrote:

What about a connected widgets visualization? Like some sound studio software works with. Boxes with input/output 'plugs'/'sockets' connected by 'wires' -- boxes might be color coded (eg yellow for clone, blue for transform..) click+drag on box to move, ctrl+click to clone. (click to rename?) click on socket, click again on opposite type of socket to connect. Click on connected socket to reconnect this end of the wire to a different socket.
Click (or ctrl-click?) on wire to disconnect both ends. Right-click (as in bauxite) to add nodes or do other misc ops. This model might be slower to navigate with many nodes though. The main (and only?) flaw of a tree-view visualization that is obviously a DAG is lack of detailed visual grouping, which is addressed by the above model.

That is precisely the model used in labview, much sound studio software (like ProTools), high end compositing tools (like Shake), high end 3d modeling tools, etc. It is a DAG. Yes, it is color coded, but there is no rule that says a DAG can't be color coded. My real point, which I was going to get too, is that for every example of people using a spreadsheet model (1, really) I can point out why it's use is eventually discouraged, and point out 5 other examples where is DAG interface is used in the real world.

-- Daniel

I had played around with DAG usability and layout before, and I'm pretty sure there is no better way to represent the data while retaining the same flexibility. I did come up with a somewhat good compromise though, which I haven't implemented but I think would work for many DAG topologies. Here's an illustration showing a standard DAG layout, and a 'block' layout of the same graph below it:

http://upvector.com/aux/misc/dagvis_block.png

I'm pretty sure there are a few cases where this would not work, but I am thinking of implementing it for usability testing. What do you guys think? Easier or worse? (I know, I don't like the black dots either ...)

-shea

On 10/19/06, Piotr Stanczyk wrote:

I have to say that the Shake UI is one of the most approachable ones I have seen. You can put someone in front of it and in 10 mins they can get something going. It may not be the prettiest in the world, but it reallly focuses the user.
Contrast that to the Toxik interface which just looks wonderful but has a very high entry point for new users ...

my $0.02

Piotr

On 10/18/06, Daniel Rogers wrote:

On Oct 17, 2006, at 9:15 PM, neota-s8PdfxpoPdHk1uMJSBkQmQ@public.gmane.org wrote:

What about a connected widgets visualization? Like some sound studio software works with. Boxes with input/output 'plugs'/'sockets' connected by 'wires' -- boxes might be color coded (eg yellow for clone, blue for transform..) click+drag on box to move, ctrl+click to clone. (click to rename?) click on socket, click again on opposite type of socket to connect. Click on connected socket to reconnect this end of the wire to a different socket.
Click (or ctrl-click?) on wire to disconnect both ends. Right-click (as in bauxite) to add nodes or do other misc ops. This model might be slower to navigate with many nodes though. The main (and only?) flaw of a tree-view visualization that is obviously a DAG is lack of detailed visual grouping, which is addressed by the above model.

That is precisely the model used in labview, much sound studio software (like ProTools), high end compositing tools (like Shake), high end 3d modeling tools, etc. It is a DAG. Yes, it is color coded, but there is no rule that says a DAG can't be color coded. My real point, which I was going to get too, is that for every example of people using a spreadsheet model (1, really) I can point out why it's use is eventually discouraged, and point out 5 other examples where is DAG interface is used in the real world.

-- Daniel
_______________________________________________ Gegl-developer mailing list
Gegl-developer-rmKnrA0qjLN8ewv5kxBBegeohdPTXOoP@public.gmane.org https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

_______________________________________________ Gegl-developer mailing list
Gegl-developer-rmKnrA0qjLN8ewv5kxBBegeohdPTXOoP@public.gmane.org https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

On 10/23/06, Shea McCombs wrote:

I had played around with DAG usability and layout before, and I'm pretty sure there is no better way to represent the data while retaining the same flexibility. I did come up with a somewhat good compromise though, which I haven't implemented but I think would work for many DAG topologies. Here's an illustration showing a standard DAG layout, and a 'block' layout of the same graph below it:

http://upvector.com/aux/misc/dagvis_block.png

I'm pretty sure there are a few cases where this would not work, but I am thinking of implementing it for usability testing. What do you guys think? Easier or worse? (I know, I don't like the black dots either ...)

I do not quite see how user interaction with this block graph would be, one of the main issues I have with free form graph editing interfaces is that the need to continously rearrange the graph easily takes a lot of time for the user. A solution I have experimented with was to use automatic graph layouting for that, thus making the only thing the user really had to be concerned with be the connections between the nodes. That seemed to work reasonably well, but for most common I think the workflow will be more streamlined with the tree w/clones approach allowing editable graphs to be embedded as some of the filters in the tree.

/Øyvind K.

Shea McCombs writes:

I had played around with DAG usability and layout before, and I'm pretty sure

there is no better way to represent the data while retaining the same flexibility. I did come up with a somewhat good compromise though, which I haven't implemented but I think would work for many DAG topologies. Here's an illustration showing a standard DAG layout, and a 'block' layout of the same graph below it:

http://upvector.com/aux/misc/dagvis_block.pngI'm pretty sure there are a few

cases where this would not work, but I am thinking of implementing it for usability testing. What do you guys think? Easier or worse? (I know, I don't like the black dots either ...)

-shea

On 10/19/06, Piotr Stanczyk

wrote:

I have to say that the Shake UI is one of the most approachable ones Ihave

seen. You can put someone in front of it and in 10 mins they canget something going. It may not be the prettiest in the world, but itreallly focuses the user.

Contrast that to the Toxik interface which just looks wonderful buthas a very

high entry point for new users ...my $0.02PiotrOn 10/18/06, Daniel Rogers <

daniel-UBMMxy9UFTLLJb+sv484WNi2O/JbrIOy@public.gmane.org> wrote:>> On Oct 17,

2006, at 9:15 PM, neota-s8PdfxpoPdHk1uMJSBkQmQ@public.gmane.org wrote:>> > What about a connected widgets visualization? Like some sound

studio software works with. Boxes with input/output> > 'plugs'/'sockets'

connected by 'wires' -- boxes might be color> > coded (eg yellow for clone, blue for transform..)> > click+drag on box to move, ctrl+click to clone. (click to rename?)

click on socket, click again on opposite type of socket to connect.> >

Click on connected socket to reconnect this end of the wire to a> > different socket.> > Click (or ctrl-click?) on wire to disconnect both ends.

Right-click (as in bauxite) to add nodes or do other misc ops.> > This

model might be slower to navigate with many nodes though.> > The main (and only?) flaw of a tree-view visualization that is

obviously a DAG is lack of detailed visual grouping, which is> > addressed

by the above model.>> That is precisely the model used in labview, much sound studio> software (like ProTools), high end compositing tools (like Shake),

high end 3d modeling tools, etc. It is a DAG. Yes, it is color> coded, but

there is no rule that says a DAG can't be color coded. My> real point, which I was going to get too, is that for every example

of people using a spreadsheet model (1, really) I can point out why> it's

use is eventually discouraged, and point out 5 other examples> where is DAG interface is used in the real world.>

--> Daniel> _______________________________________________> Gegl-developer

mailing list> Gegl-developer-rmKnrA0qjLN8ewv5kxBBegeohdPTXOoP@public.gmane.org

https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer> _______________________________________________Gegl-developer mailing list

Gegl-developer-rmKnrA0qjLN8ewv5kxBBepoBm9RaG5CyOSlZSvpQR6E@public.gmane.org:// lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

-- Shea McCombshttp://www.upvector.com/------If you're a cowboy, and you're

dragging a guy behind your horse, I bet it would really make you mad if you looked back and the guy was reading a magazine.

On Mon, Dec 18, 2006 at 12:40:05AM +0000, Piotr Stopniak wrote:

Shea McCombs writes:

I had played around with DAG usability and layout before, and I'm pretty sure

there is no better way to represent the data while retaining the same flexibility. I did come up with a somewhat good compromise though, which I haven't implemented but I think would work for many DAG topologies. Here's an illustration showing a standard DAG layout, and a 'block' layout of the same graph below it:

http://upvector.com/aux/misc/dagvis_block.pngI'm pretty sure there are a few

cases where this would not work, but I am thinking of implementing it for usability testing. What do you guys think? Easier or worse? (I know, I don't like the black dots either ...)

What if the graph isn't planar? The dag on top of that page can be drawn with crossing lines, but it's not clear how to make rooms cross.

The black dots, though, could just be doorways connecting rooms.

-- hendrik