This page was originally at Cytoscape_3.0/MiniRetreatTwo/DanielsQuestions I only left there the questions that were discussed and mostly settled since then on that page. The rest I moved here, for further pondering. Feel free to edit, I don't want to claim ownership just because it is linked below my personal page.
Contents
Questions about usecases (considering existing features):
client/server boundary?
When doing "web rendering"/"Cytoscape light" where will the client/server boundary be? Between the viewmodel and the model? or between the viewmodel and view?
NodeDecorators or NodeRenderers?
Currently (in 2.6.x) custom graphics are done as a sort of 'NodeDecorators' instead of NodeRenderers. This could be simply a workaround, NodeDecorators being easier to fit into the 2.6.x implementation. Considering actual usecases, which would be a better match? If NodeRenderers would be allowed to be composed, ie. having multiple renderers that draw on top of each other, what kind of uses would that be helpful for? Would those usecases be better implemented by a single, customizable NodeRenderer?
VisualProperty Categories?
VisualProperties are currently grouped into three categories: there are Node, Edge and Global VisualProperties. Should these categories be fixed? I.e. instead of each VisualProperty being one of these, should we allow a general 'category' field, which would allow, say having a 'Group' or 'Metanode' category?
Are categories needed at all? (I think yes, to allow vizmapper gui to be more user-friendly) Are there any need for them apart from making the vizmapper gui easier to navigate? Would some other mechanism be better for organizing them?
What events are needed in the viewmodel layer?
For example, most of the vizmapper gui should be using VISUALSTYLE_CHANGED (to signal that the VisualStyle of a given GraphView was changed to another one) and VISUALSTYLE_MODIFIED (to signal that a given VisualStyle was edited) events (which were not available in 2.6.x). Are these two events enough or would there be more needed?
Immutable VisualStyles
mentioned on Molecular_Interaction_Maps (search for "customizable"), and in general I think it would be useful to ensure consistency: VisualStyles could have a 'dontEdit' flag, and the vizmap user interfaces should ask for confirmation before allowing editing. (Totally prohibiting editing would be bad, this is more about avoiding accidental edits. Or is there a usecase for a real non-editable VisualStyle; and how would that be edited? 
)
For example VisualStyles read from xgmml files might have this dontEdit flag set.
Questions about possible new features:
Allowing not one-to-one Mappings in vizmap?
Currently the vizmap layer supports only one-to-one mapping between attributes and VisualProperties. I think this years "Implementing Boolean Logic into the Display of Visual attributes" Summer of Code project was aimed at relaxing this restriction.
Would supporting many-to-many Mappers be needed? (Many attributes to one VisualProperty, or one attribute to many VisualProperty) How would the GUI used for editing these look like? How would it be possible to both edit a many-to-many mapping _and_ to allow seperate mappings to each underlying, atomic VisualProperty?
Allowing many-to-many Mappers might also allow 'composite VisualProperties': Currently some VisualProperties, like EDGE_WIDTH and EDGE_DASH, or NODE_COLOR and NODE_OPACITY are actually editing different aspects of the same underlying, native object (a java.awt.Stroke and a java.awt.Color) (For example, using this aspect a more intuitive gui could be possible.) It might be nice if these would be stored in the vizmapper in one place, ie. if the implementation would also reflect this more closely.
Note that this is one place where design decisions made in the viewmodel layer will have HCI aspects: where forcing some structure in the viewmodel might affect what kind of interfaces are possible. We should be carefull not to close the door on exciting possiblities, even if we don't yet take advantage of those possiblities.
direct manipulation vizmap GUI?
Does the current (or any planned) vizmap / viewmodel API constrain (or make more difficult) writing direct manipulation-like vizmapper gui? (I.e. click on node and set 'nodes of these types should all be green'. Note that this is different from the VizMapperByPass, since in this case a Mapping is defined, and not a DiscreteMapping-like exception.)
Tune cytoscape event loop to underlying toolkit
Fitting the event firing loop to the event-handling loop of the underlying graphical toolkit might be usefull for improving user experience. For example (althought strictly speaking it is not an event-handling issue), redrawing (re-rendering) the network only at most once between repaints (or instead of redrawing it, just set a 'redraw on next repaint' flag). I might be completely misguided here, but would the event firing framework need special tricks to make sure it plays nice with the event-handling of the underlying graphical toolkit?
(One example where I seen such issues is in http://ipython.scipy.org/moin/ where the read-eval-loop of the python prompt needs to know about the event loops of the graphical toolkits to play nice with them. This, however might be a 'scripting interpreter' issue and might not affect event-firing.)
edge anchor ports
Currently edges are routed to somewhere on the boundary of the node. Should it be possible to define a few number of points on the node and enforce that all edges (or certain edges) can only terminate there? (This might be needed, for example, for molecular interaction maps)
How would such a thing be supported?
Note that this also brings up another question: Apart from forcing the edge to end at an anchor point, should it be possible to allow anchor points to have special graphic? (This would mean that NodeRenderers would need to be given some information about the edges)
edges ending at edges?
Would it be possible to support 'edge ending at edge' in a non-hackish way? (see [Molecular_Interaction_Maps/EnzymaticStimulation] FIXME ) The hackish workaround, of course, is to add a placeholder node on the edge, and set the graphics of it to be unobtrusive, and set edge-ends accordingly. But would it be possible to handle this in a native way, without such workarounds?
Drawing one node in several places
A proposal to support "one node in several places" (look for 'constant nodes' on the Molecular_Interaction_Maps page) natively:
(this is somewhat similar to the previous 'edge ending at edge', but in this case I think the following could work quite nicely):
The idea is that this could / should be done entirely in the presentation layer, without affecting any layers below: thus it wouldn't mess up topology-using algorithms that only use the model layer, for example. The idea is to allow layout algorithms to create multiple positions for a node: i.e. to allow them to specify that 'I want to place this node here, there and over there'. Then, they would route edges to the closest one, as appropriate.
For the layout algorithms, there are two possiblities:
- the list of nodes which are allowed to be shown in multiple places are fixed externally. (To conform to whatever convention is used for MiM views.)
- the layout algorithm itself figures out which nodes to show in multiple places (trying to minimize the number of such nodes, of course)
Changes needed for this:
- make the x and y nodepositions to optionally be lists
some API changes for CyLayouts to allow list of nodes that can appear multiple times.
- some gui changes will be needed: for example 'create another view of this node' action somewhere.
unifying vizmapper and Attribute batch editing?
Should the possibility of unifying vizmapper (Attributes -> VisualProperty mapping) and the batched editing features of the DataPanel (Attributes -> Attributes mapping) be explored? VisualProperties, especially if they are made pluggable are very similar to Attributes (the biggest difference being that the object types are different).
Explicit support for syncing
I think having explicit support for syncing different instances of model, viewmodel layer objects should be explored:
As described in my e-mail to cytoscape-staff on Oct 27, there will be usecases where synchronizing the views of the same object won't be as simple as 'use a shared instance of the foo layer object, but separate instances of the bar layer object, and it will synchronise everything magically'. In some cases it will be needed to synchronise state between two instances of a class. (For example, VisualStyle, but not layout of two GraphViews.) This, of course, can be done by doing this synchronisation 'manually': writing the needed event handlers and such. However, explicit support for this might be better: it might allow implementations of the given object (in our example, GraphView) to optimize for such uses (for example, they could use a common object to store that part, 'getting synchronisation for free' again, or optimize event-handling). In addition, it would be a great help for people implementing synchronized views of data and avoid reinventing the wheel every time such is needed.
For example, inte the viewmodel one could have a method like
thisGraphView.syncWith(thatGraphView, someVisualProperty)
tospecify that the values of the given VisualProperty are to be synced. (The implementation of .syncWith could require that the networks of the two GraphView is the same object, and maybe event that the two GraphView objects are instances of the same implementation. In this case, the GraphView implementation could use the same column-like object instance to store the values, thus getting MVC-like automatic synchronising)
.syncWith() would sync in both directions, depending on usecases another method that syncs only in one direction might also be useful.
Note that this does not necessarily have to be part of the GraphView API, it might be enough if, say, the default GraphView implementation has such extra methods. (But in that case, how can plugin writers who want to use this functionality ask for such a hypothetical SyncableGraphView to be used for a given network?)
On the other hand, the 'manual syncing' can be allways done in any GraphView implementation, so requiring that the GraphView implement that might be acceptable, if bloating all GraphView implementations is not too big a problem.
Changing MDI design?
An aspect to consider about presentation: currently the stand-alone Cytoscape program has an MDI design. This has some drawbacks, for example is less useful on multiple monitors, or see bug no.1931. If using a 'single document interface' (http://en.wikipedia.org/wiki/Single_document_interface) is considered for 3.0, that would mean that the current 'there is one editor, one vizmap editor for all networks' view would explicitly change to a 'each editor, vizmap panel belongs to one network view' setup. For example, the whole idea of having a 'global current VisualStyle' is obviously wrong, but I for one didn't realize this until I considered the 'each editor, vizmap panel belongs to one network view' setup.