Brainstorming on GBK (April 15, 2015)

[Richard Bruskiewich]

1. Drop down menu to select alternate cytoscape.js graph layouts for concept map (default at the moment is 'grid')
2. User needs to be able to persist a concept map they construct (somewhere). Since we don't currently have user accounts and server-side session management, perhaps some kind of browser download is required(?)
3. The PMID 'Evidence' annotation for selected concept nodes could (and should?) perhaps be annotated somewhere (in the concept map?)
4. Users should be able to prune their concept maps (i.e. delete node graph mode?).
5. Users might wish to revisit concept nodes previously added to the concept map, by clicking(?) on the node and triggering a reload of the original explicit and implicit data tables (navigate graph mode)
6. Concept map edges need to be labelled with the relation predicates(?). Users might wish to turn such annotation on and off, at will?
7. A tabbed layout might help to stack the explicit and implicit data tables, to economize screen real estate. The data tables should continue to work ...
8. The "Discovery View" does largely work on an Apple iPad, but the JQuery Drag and Drop of the relation onto the concept map doesn't appear to work. Perhaps relation 'click node' would be better here? Otherwise, one needs to figure out how to make drag and drop work in the iPad (iPhone?) setting.
9. Are there any User Preferences to be managed? If so, can cookies be used or do we need to have user accounts and sessions on the server side?

[b]

On #3 - would be nice if this was attached to the corresponding edge so that a click there could bring it up.
#8 not a big concern right now. #9 lumps in with #2

I like all the other enhancement ideas. Suggest running with the UI changes in this rough order: 7, 4, 3, 1, 6, 5.
I might add a way to resize the table/graph areas.

In the interim an export to PNG option would be nice - must be some export options from cytoscape.js ? And then figuring out #2... I am sure that we are going to need user management on the server to make this effective. And, I also want to be able to track what people are clicking on in our database. And of course this leads into the whole social aspect of the site that we haven't even thought about.. e.g. comments, sharing etc. So lets leave that alone until we are all happy with the discovery view itself (unless you think it would make that more effective to have a logged-in user session to work with?)

[Richard Bruskiewich]

I just noticed another hidden user story (thought about previously, but now feels a bit more essential): what if in my exploration of one table (say, genes in the 'Implicitome'), I want to check if there are any corresponding 'SemMedDb' explicit relationships? How can the user get there? At the moment, short of starting a fresh search in the original search form, one cannot do this.

I can imagine several ways of achieving this (each with their possibilities):

1) I could automatically update both tables whenever I click a concept in either table. This may be easy to implement quickly and feels useful. The drawback is that independent explorations of each (explicit versus implicit) space would not be possible...

2) I could add a new search box in the page to allow searching of new concepts to link into the graph (including the last selected concept). This too would update both tables, but also give the possibility of adding fresh concepts ab initio to the map. However, these new concepts may be disjoint from the previous map(s) constructed.

3) I could (somehow) add a context-specific menu to give more options, including searching the "other" search space for hits.

[b]

I think (1) here is likely the best option. Keeping both tables in sync and focused on a specific concept will help keep the user from being lost and I bet will streamline software design.

Also gives a straightforward way to give context when user is navigating the graph. e.g. you click on a concept node in the graph and the relevant tables appear...

[Richard Bruskiewich]

Status of completion of this "aggregate" issue needs to be undertaken.