[Clam-devel] Request for votes: Thinking on 'Connect to' feature

[Pau Arumí Albó]

El dv 13 de 06 de 2008 a les 19:50 +0200, en/na David García Garzón va
escriure:
> This days i've been using the annotator for connecting massive networks. 
> Definitely, the cut and paste feature is great for that (and it will be even 
> more usefull when the positions patch is applied).
> 
> But, the feature i feel hard to use is the new connect-to context menu. We are 
> substituting a hard-to-aim connecting interface with a hard-to-control 3 
> levels contextual menu. Most processing have just a single connectable port 
> so the last level is not that usefull but nagging.
> 
> Several alternatives to connection come to my mind:
> 
> A) Having 'Processing.port' pairs in the Connect-to submenu instead of two 
> levels of selection. This could be very populated but is faster to use.
> 
> B) A mid way 'Connect to' submenu that just contains processings. If the 
> processing just has one compatible port it just connects it. If it has more 
> than one port, a selection dialog appears to select the ports. Multiple 
> selection could be available, which might be also convenient.
> 
> C) A 'drag wire to processing' feature. Dragging a wire onto a processing it 
> would work as selecting such a processing in the previous option.
> 
> D) A 'Connect to...' context menu option, that opens a selection dialog with 
> all the compatible Procesing.Port options. Multiple selection also useful 
> here. The benefits of this one is that it is very easy to connect one port to 
> a lot of ports in different processings.
> 
> They all are easy to implement as most of the code is already there on the 
> current connect-to menu implementation. If Natanael is busy with other tasks 
> i could implement one or two of them.
> 
> Any strong feeling in favor of any of them? I specially like C and D.

I've given some thoughts on this and I don't think that the current
method is basically the most intuitive (though it still permits some
enhancement, more about this below)
IMO, choosing origin and then target is more intuitive than selecting a
pair on a (potentially large) set.
Allowing for multiple selections in one go I think it is not really
necessary: for small number of connections repeating a single connection
is good. For large number of connections: you probably need a
subnetwork. I think that having subnetworks will totally change how
users design complex networks.

So my proposal would be to use the current method of chained selections:
1. out port
2. target processing
3. in port

I propose two independent and simple enhancements -- I guess this would
be E)
- Remove the first "Connect to" and instead list all the out ports
(after a separation line and maybe a "Connect" title)
- Avoid the last in port choose if only one of the proper type exists.


Finally, I think that few users have this necessity now (basically for
the 3D audio stuff), while there are other missing features that are
might block many potential users (I'm thinking on: run-time error
handling, undo, accessible processing documentation, etc.)

P