everbeek
commented
9 years ago Closed everbeek closed 9 years ago
everbeek
commented
9 years ago everbeek
commented
9 years ago Created last two ideas that I will do into new cases.
I'm in a hurry, so I will add the notes me and Cassie each took, and I can sort, interpret, and priorize them later.
From Cassie's Notes: -
no way to identify the parent on first view (the relationship isn't clear)[fixed made vertical tree layout the default] -can we do something about the hover popups...like a delay?[fixed] -it's critical that the default layout is appealing and appropriate (familiar?)[made tree default for path to root] -switch order of filters in side bar...ontologies first, concepts second? ontologies open on top.[fixed] -popup link opens in the same tab as opposed to a new window...which is evil![fixed] -interesting info for popup: concept name, def, synonym, ontology acronym (click acronym to go to the link)[fixed] -in popup, compress link[fixed] -don't display scroll bar by default...use max height[fixed] -bookmarking of a vis' moment in time would be more valuable than the long list of breadcrumb links[own issue 392] -with undo, you don't need the confirmation for refocussing[fixed] -keep the sidebar open all the time? space is such an issue. is there a way to choose to open/close it? use a button to keep it open or go away? cookies? pin it? dock it?[fixed] -just have a back arrow (and typical computer keyboard shortcuts?)[fixed] -layer arcs on top[disagree, will look cluttered] -Ray likes hide nodes as opposed to remove...but that conflicts with "hidden nodes" and removing them[revisions to button wording might do it...] -look for literature on how to deal with different edge types[not much. One group looked at overlapping vs side-by-side renderings of graphs with two arc types. Otherwise this work on "simultaneous graphs" was very disappointing. Bipartite graphs are a special case that always use a dual partitioned layout. The problem of layouts that highlight both variability in arc types as well as expressing relatedness through proximity seems unsolvable for the general case of n-partite graphs.] -arc colors? would this help?[revised arc colors...but possibly for the worse. Property relation arcs get their ontology color. The default is_a and part_of arc types were made darker, very dark indigo and forest green. Mapping arcs are still dashed grey.]-
different symbols on arcs for different relationship types[fixed see #385]-tool tip, perhaps a MORE or SHOW DETAILS option on the dropdown list. [this would work great with a fixed location tool tip] -need the concept of visual momentum [would require significant changes to graph populating code. But possible. See #491]
Uncertain about: -is the concept of node expansions too complex? -a horizontal tree viz that puts all is-a's in one area and part-of's in another...it would be nice to have a way to distinguish these as well as parent/child...all on different levels -a way to indicate the most ideal layout for the situation? -does everything have to be on the screen at one time? would zoom be more appropriate? when we get to a certain level of complexity, do we need to show "everything" at once? -ontologies all have varying levels of granularity...the ability to zoom in a level would be great [see #490] -the clearest indication of relationship is to have related things close to each other...too many arcs would start to confuse the graph -try an implementation of what the user can expand for a given node (too many rest calls preloaded) -ajax call available to display all info in a modal way?
From Eric's notes:
-
Ontology filter section above Concepts.[fixed that part] -default layout should be horizontal tree probably[fixed; given nodes have labels horizontally, I think vertical tree is better] -tool tip: clickable link better than fully rendering the URL. Include: Definition, Synonyms, Ontology Acronym (as link), Actual concept name (link to homepage). Also, check the main NCBO view UI for REST call that can grab this sort of stuff, for a modal view[fixed] -filter checkbox sections should not default to scrollbar minimum height.[make the open ones take up extra space, or not? Not. I like it the way it is. Will show and get feedback.] -given undo, refocus node requires no confirmation.[fixed] -change breadcrumb trail to forward and back buttons (maybe with browser style drop down to show the breadcrumbs)[see #393] -keep menu open once it is opened, use a toggle button to keep it up. Use cookie to see if user has ever opened and closed the menu, hide it if they have a couple times. Fade or slide it out on toggle.[fixed] -consider putting tool tip details in the menu rather than using popups.[fixed, still using tooltips]-
edge colors don't contrast enough, alter arrows for types (equals sign, a triangle, another for composite)[fixed, see #385] -in September, make use of the property listing REST call to find only the officially supported composition relationship attributes, remove the SNOMEDCT has_a as a hard coded relation. Had to do with OWL_class labels or something.[done in another issue] -is there a layout solution for different edge types? What is the best way to integrate that information into layouts?[I think Elena and me have sorted out some things with regard to mappings, since those should generally be separated from a central layout, but composition might matter too. Look for papers on this. Looked, found nothing helpful, as noted above in Cassie's version of this note.]-refocus functionality gave idea of visual momentum. Better to fade out other nodes and animate the refocussed node to center as other nodes are faded in or otherwise added (shot out from center node?) [would require significant changes to graph populating code. But possible. See #491]
Uncertainty about these... -contextual zoom (I think this is a Protege feature) [see #490] -pre-fetch counts for expansions (very asynchronously) -provide users hints that they should change layouts when certain expansions happen -is there a specific use case for expanding isa and mappings both a lot?