search

cwrc / HuViz

LOD visualization tool for humanities datasets
8 stars 1 forks source link

Non-Urgent Issues (per cmiya email) #55

Open smurp opened 8 years ago

smurp commented 8 years ago

Tweaks

cmiya commented 8 years ago

Two more things:

  1. What is the difference between Deactivate, Shelve and Retrieve? They all seem to perform the same function (sending nodes back to the Shelf).
  2. Help bubbles need to be updated to reflect new terminology (bubbles still read "Choose).
cmiya commented 8 years ago

@smurp Thanks for creating this issue, by the way!

smurp commented 8 years ago

To @cmiya in response to Simplifying the Way Predicates are Expressed in the Graph/Commands Tab

This whole gizmo is entirely abstract and entirely driven by the data and the ontology. To do other than let the tool show us just the very data being given we'd have to add another layer of complexity -- the show us THIS instead of the knowledge-driven-reality layer. The labels for Classes and Edges of the Selected Nodes and edge labels in graph are all just the actual IDs for those things as defined in the ontology and reflected in the orlandoScrape output but something which could be done is to show the rdfs:label (some other pretty attribute of either Class or Predicate instances, but I don't see any of those defined in the ontology. So, bottom line, it would be possible to provide alternative labels but it would just take doing two (or three) jobs:

smurp commented 8 years ago

@cmiya A single close-all button? What if the user closes the top window? Should the button the migrate to the next window? I'd suggest we stick with this scheme for the moment but check out https://fortawesome.github.io/Font-Awesome/icons/ for a choice of other icons. Though I'd say the bomb actually does a pretty good job of conveying the purpose. I'd argue for an icon vs the text close all too; so we don't compete for space with the label on the left side of that title bar, especially given that we've ambitions to put more on that line too.

smurp commented 8 years ago

Re the "command line initials". The identifiers which appear when one clicks on individual nodes are short little things like G, IC and so on. Note that the identifiers for the writers are their proper IDs: eg shakwi and atwoma. Those little cryptic ones are created automatically and sequentially by orlandoScrape.py to represent those entities in the XML version of Orlando which lack any existing well-formed identifiers. When we get named entity recognition (NER) integrated into all this then those likely more descriptive identifiers will be available to show instead. Generally sources of RDF other than Orlando have pretty to very good identifiers because they are generally composed for human comprehension. Automatically constructing those synthetic identifiers within orlandoScrape is doable but is a cost which should be weighed against benefit and considered in the context of its eventual replacement by NER.

cmiya commented 8 years ago

@smurp Yes, the "Close All" icon would float on the topmost window and migrate the next one if it is closed.

Something about the bomb symbol I just find off-putting. I like the idea of using THIS icon of the layered windows, but with an X in the centre - simple, but elegant: http://fortawesome.github.io/Font-Awesome/icon/clone/

If I create it in photoshop, could you use it? Or does it have to be one of the existing icons?

cmiya commented 8 years ago

Here's a few examples of Close All mods for Android: http://i.stack.imgur.com/RV3m5.png https://forums.motorola.com/posts/200d59fa5b

They're for closing multiple apps windows, but I think it's similar to what I was imagining for the Snippets. You could either float it or place it in the top left. Again, not a priority - but something to think about.

SusanBrown commented 8 years ago

I like that idea for an icon.

On Feb 6, 2016, at 12:25 AM, cmiya notifications@github.com wrote:

@smurp https://github.com/smurp Yes, the "Close All" icon would float on the topmost window and migrate the next one if it is closed. Something about the bomb symbol I just find off-putting.

I like the idea of using THIS icon of the layered windows, but with an X in the centre - simple, but elegant: http://fortawesome.github.io/Font-Awesome/icon/clone/ http://fortawesome.github.io/Font-Awesome/icon/clone/ If I create it in photoshop, could you use it? Or does it have to be one of the existing icons?

— Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-180690110.

smurp commented 8 years ago

@cmiya If you could provide a compact .png suitable for direct use as an icon I would be delighted to deploy it.

On Sat, Feb 6, 2016 at 9:31 AM, SusanBrown notifications@github.com wrote:

I like that idea for an icon.

On Feb 6, 2016, at 12:25 AM, cmiya notifications@github.com wrote:

@smurp https://github.com/smurp Yes, the "Close All" icon would float on the topmost window and migrate the next one if it is closed. Something about the bomb symbol I just find off-putting.

I like the idea of using THIS icon of the layered windows, but with an X in the centre - simple, but elegant: http://fortawesome.github.io/Font-Awesome/icon/clone/ < http://fortawesome.github.io/Font-Awesome/icon/clone/> If I create it in photoshop, could you use it? Or does it have to be one of the existing icons?

— Reply to this email directly or view it on GitHub < https://github.com/cwrc/HuViz/issues/55#issuecomment-180690110>.

— Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-180806516.

Shawn Murphy smurp@smurp.com (780) 903-2428 http://www.smurp.com

smurp commented 8 years ago

@cmiya I am not ignoring your question about the distinction between Deactivate, Shelve and Retrieve! It is just taking a while to compose the answer and create a little tutorial to really explain the heck out of it! :-)

smurp commented 8 years ago

I just noticed this lightening bolt icon. Would it do? http://fortawesome.github.io/Font-Awesome/icon/bolt/

PS swapping in these 'font awesome' icons is super quick and easy, we should try to use them when we can, what with the large selection available

On Sat, Feb 6, 2016 at 11:54 AM, Shawn Murphy smurp@smurp.com wrote:

@cmiya If you could provide a compact .png suitable for direct use as an icon I would be delighted to deploy it.

On Sat, Feb 6, 2016 at 9:31 AM, SusanBrown notifications@github.com wrote:

I like that idea for an icon.

On Feb 6, 2016, at 12:25 AM, cmiya notifications@github.com wrote:

@smurp https://github.com/smurp Yes, the "Close All" icon would float on the topmost window and migrate the next one if it is closed. Something about the bomb symbol I just find off-putting.

I like the idea of using THIS icon of the layered windows, but with an X in the centre - simple, but elegant: http://fortawesome.github.io/Font-Awesome/icon/clone/ < http://fortawesome.github.io/Font-Awesome/icon/clone/> If I create it in photoshop, could you use it? Or does it have to be one of the existing icons?

— Reply to this email directly or view it on GitHub < https://github.com/cwrc/HuViz/issues/55#issuecomment-180690110>.

— Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-180806516.

Shawn Murphy smurp@smurp.com (780) 903-2428 http://www.smurp.com

Shawn Murphy smurp@smurp.com (780) 903-2428 http://www.smurp.com

SusanBrown commented 8 years ago

It’s cute but I think the idea Chelsa mentioned of receding boxes with Xes in them would be clearer.

On Feb 7, 2016, at 3:12 AM, Shawn Murphy notifications@github.com wrote:

I just noticed this lightening bolt icon. Would it do? http://fortawesome.github.io/Font-Awesome/icon/bolt/

PS swapping in these 'font awesome' icons is super quick and easy, we should try to use them when we can, what with the large selection available

On Sat, Feb 6, 2016 at 11:54 AM, Shawn Murphy smurp@smurp.com wrote:

@cmiya If you could provide a compact .png suitable for direct use as an icon I would be delighted to deploy it.

On Sat, Feb 6, 2016 at 9:31 AM, SusanBrown notifications@github.com wrote:

I like that idea for an icon.

On Feb 6, 2016, at 12:25 AM, cmiya notifications@github.com wrote:

@smurp https://github.com/smurp Yes, the "Close All" icon would float on the topmost window and migrate the next one if it is closed. Something about the bomb symbol I just find off-putting.

I like the idea of using THIS icon of the layered windows, but with an X in the centre - simple, but elegant: http://fortawesome.github.io/Font-Awesome/icon/clone/ < http://fortawesome.github.io/Font-Awesome/icon/clone/> If I create it in photoshop, could you use it? Or does it have to be one of the existing icons?

— Reply to this email directly or view it on GitHub < https://github.com/cwrc/HuViz/issues/55#issuecomment-180690110>.

— Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-180806516.

Shawn Murphy smurp@smurp.com (780) 903-2428 http://www.smurp.com

Shawn Murphy smurp@smurp.com (780) 903-2428 http://www.smurp.com — Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-180974199.

smurp commented 8 years ago

@cmiya Take at this tutorial as a worked response to the query about the Deactivate/Shelve/Retrieve distinction.

Meanwhile I think I'll break the Quick Start section out of the Help tab into a separate Markdown document for "easy" authoring and then integrate it back into the Help tab dynamically, so we can maintain such things in Markdown form in the source code, even with previewing right within GitHub. That way we could easily plunk the tutorial into one of the tabs too, if desired.

cmiya commented 8 years ago

I think I agree with Susan - the lightening bolt has other associations (low power, thunderbolt connection) and doesn't quite fit with what we want. But not to worry - I can create a new icon from the layered windows.

Let's make sure that we work together on the Quick Start. Remember that the purpose of the Quick Start is to be the most easy and accessible version of the steps - one that is created with the new and unexperienced user in mind. The full documentation will be in a separate section on DITA, with a link to it from the Help Tab.

cmiya commented 8 years ago

But for sure I think breaking it into a separate document makes sense. That's a great idea.

cmiya commented 8 years ago

I've looked over the tutorial and I understand the need for a Deactivate. Where I'm confused is why there has to be a separate button for Shelf and Retrieve.

You can, in fact, use BOTH buttons to send nodes in EITHER a hidden or discarded state back to the shelf. You can do this using the Sets Bar, which selects nodes to perform actions upon based on current status (Hidden, Discarded, Active, etc.) In other words, as you state "Retrieve does the job of pulling things from the Discarded set and placing them back on the shelf." That is correct. But you can also use retrieve to put hidden things back on the shelf (I have tested this and it works). The only thing Retrieve cannot do is re-shelve graphed/active nodes. But if Shelve can do this (and Shelf can also selectively shelve only discarded OR only hidden nodes) what does Retrieve do that Shelve cannot?

smurp commented 8 years ago

Maybe the use cases to look at are the ones involving not sets but classes. Retrieve Region. would shelve any discarded Regions but leave the Graphed ones untouched. Shelve means put on shelf. Retrieve means take out of discard bin. Depending on the SET/CLASS different effects can be achieved. I think I'd call Retrieve putting Hidden things (which aren't discarded) on the shelf a bug. Thanks for finding it. 

Label Region .
Activate Kent .
Hide Middlesex .
Discard Surrey .
# We have one Region in each (non-shelf) place. What will happen when we...
Retrieve Region .
# The hidden and discarded are shelved, the graphed is not shelved.
# In my opinion the Hidden perhaps should not be.

OK I've fixed this bug with https://github.com/smurp/huviz/commit/2d78d707e5b4f0a7e94034a3c7cebd2803d15b2f and its deployed over at http://alpha.huviz.dev.nooron.com/

Now let's test Shelve

Label Region .
Activate Kent .
Hide Middlesex .
Discard Surrey .
# We have one Region in each (non-shelf) place. What will happen when we...
Shelve Region .
# All three are shelved.
# And I think that is right because it doesn't offend the critically 
# important thing about the Discarded set, which is that 
# "The discarded are never pulled into the graph by the Activated."

This was hard stuff to devise and really there was no one to talk to about it because it was sooo tediously intricate.

Maybe the real issues to consider for clarifying how these things should work are definitions like:

On an entirely different thread I think these names:

should replace these ones:

cmiya commented 8 years ago

But here's the thing - if the goal is to shelve any discarded Regions but leave the Graphed ones untouched, why not just click Discarded -> Regions -> Shelve? Likewise, if the goal is to shelf only hidden Regions, why not click Hidden -> Regions -> Shelve? (*This currently WORKS in both cases by the way). Isn't the purpose of the Sets Container to be able to execute these type of actions? To me, adding a "Retrieve" function saves perhaps one step, but adds a whole other layer of unnecessary complexity. It also feels like it contradicts one of the main purposes of the Sets Container.

cmiya commented 8 years ago

Hide VS Discard is a whole other issue...

It makes sense to want to temporarily remove a node from a dataset. For instance, say I notice some of the data is flawed - certain nodes (like the node "1" in the Atwood dataset, which refers to the number of her children) should NOT be there. Rather than go back into the data, it is highly convenient to be able to immediately remove it from the dataset - in a way that is not permanent, but at least fixes the problem for the purpose of the Research session at hand. Likewise, if I am working with the Bronte dataset, but Emily is not relevant to my research question, it would be great to temporarily remove Emily from the dataset. Or if the Date nodes are not relevant, again temporarily remove them. If I need to remove entire subclasses or Classes (like Date), the discard bin is going to get pretty full pretty quickly. Also, I don't need to them to be in the bin, visible and ready to be called forth, because they're not relevant. This is where a "Hide" function (as I saw it) would be very useful.

Making a node invisible, to me, communicates that it is no longer in play. Why would I want to make a node invisible to the eye, such that I forget that it exists (except as recorded by the Sets tally), and yet have it still be in play so that it can suddenly appears in the graph? The only nodes that can be pulled into the graph by the Activated are Hub/central nodes. So again, what's the purpose of making the Emily node, for example, invisible to the eye - but yet still capable of being suddenly pulled in when connected nodes are activated? From the perspective of a literary researcher, why would I want to do that?

cmiya commented 8 years ago

To be clear, I understand the purpose of a Discard Bin. That makes perfect sense. But I am not convinced of the usefulness of the "Hide" function, as it stands. A function that temporarily removes nodes from the dataset is useful. A function that makes nodes "invisible to the eye, but still in play if a Hub node" is not useful, at least (as I see it) from a researcher's perspective.

smurp commented 8 years ago

Re Hide vs Discard

I find Hide useful when the node count is high and the nodes I want to see on the shelf for dragging into the graph are members of just a few classes OR there are some classes that are highly populous but not what I want to be activating. In the first case I want everything hidden except, say, one class shelved for dragging. In the second case I want one class hidden. Example: you want people on the shelf and their works invisible but available for graphing with their authors.

It is a peculiarity of the Orlando data and the small per-author datasets that there is a central hub or very small number of node that are connected highly and other nodes which have only a connection to a hub. These artificially constrained small extracts are not examples of https://en.wikipedia.org/wiki/Scale-free_network because the only connection of the vast majority of nodes is to one or a handful of authors and indeed non-authors can't be connected. This is to respond to "the only nodes that can be pulled into the graph by the Activated are Hub/central nodes".

ghost commented 8 years ago

Would a hidden node serve sometimes to keep other connected nodes as part of the graph, whereas discarding it would take any connected nodes out of the graph with it? I do find hiding nodes, and seeing what difference they make to the appearance of a graph quite useful, so I’m in favour of keeping this distinction.

On Feb 8, 2016, at 3:15 PM, cmiya notifications@github.com wrote:

To be clear, I understand the purpose of a Discard Bin. That makes perfect sense. But I am not convinced of the usefulness of the "Hide" function, as it stands. A function that temporarily removes nodes from the dataset is useful. A function that makes nodes "invisible to the eye, but still in play if a Hub node" is not useful, at least (as I see it) from a researcher's perspective.

— Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-181512504.

smurp commented 8 years ago

When I do this:

Label Region .
Label Settlement .
Activate Surrey .
Activate Broadstairs .
Discard Kent .
Discard London .

We're now in a position to clarify what "Discarded -> Regions -> Shelve" does.

With none of the pickers (Verbs/Sets/Classes) "engaged" (ie the current command is blank) then clicking on Discarded makes the command Discard ____ . and clicking on Region has no effect on the current command which remains Discard ____ . Then clicking on Shelve makes the command which actually gets run be Shelve Discard . which is just what happens, all the discards are shelved not just the Regions.

This needs explanation.

1) There is a bug (easily fixed, this feature wasn't protected by a test and got lost) -- When a set is engaged then engaging a class should disengage the set. eg ____ Discarded . should become ____ Region . when Region is clicked and that should actually be reflected in the removal of the hilighting of "Discarded" in the set picker, which isn't happening right now and I will fix.

2) Clicking Discarded when Region (or more motivatingly some complex selection of 20 different random nodes and classes) is selected should change ____ Region . to ____ Discarded . without damaging the selection and that is what we are seeing in this example. "If there is a set engaged then any selection (ie collection of selected nodes and/or classes) is ignored.". The motivation for doing this is so that one doesn't have to undo a large complex selection to be able to perform a command on a set.

It seems you're suggesting that there should be support for commands like:

Shelve all Discarded Regions .

Let's figure out how to do that too.

By the way I think the user experience is really suffering for not having #36 (continuous preview in current command) implemented because then the user would get to see the full command before it is run. It will be great when they can see the command which IS running and the commands which DID run too.

smurp commented 8 years ago

@susanirenebrown

Yes exactly, hiding nodes (without discarding them) keeps them available for being pulled into the graph but out of the way.

smurp commented 8 years ago

I think it would be good if there was visual feedback (other than just what is appearing in Current Command) for those situations where the fact that a Set is engaged is "dominating" whatever selection exists in the Class picker. Something like the whole Class picker being slightly greyed out perhaps.

cmiya commented 8 years ago

Ah, I see what you're saying. When the bug is fixed, clicking a Set will disengage the Class - so both cannot be engaged at the same time. But why is that necessary? I suppose if you were executing the command in reverse (Shelf -> Region OR Shelf -> Discarded) then it would execute automatically without you being able to take the next step. But as long as it's in the correct order, it would be nice to be able to combine a Set and Class type together (as in the example, Discarded -> Region -> Shelf) to execute a Command. In other words, select whatever combination of Set + Class type is required before proceeding to select the Verb. Once you've chosen the Set + Class type these stay engaged, so you can execute any combination of Verbs in sequence until you move onto the next group. This seems more intuitive to me than creating an extra Verb button as a workaround.

cmiya commented 8 years ago

Although, of course, the changing state of nodes presents another interesting quandary when using the Sets to execute commands. For example, say there are some nodes in the Discard bin. Clicking Discarded (in the sets container) --> Retrieve (or Shelve, which still works at this point) places discarded bins back on the Shelf. So the nodes are no longer in a Discarded state. BUT Discarded is still engaged/highlighted/visible on the Current Command Line - albeit in a frozen state, referring to nothing, and having no effect when combined with any verbs. The fact that you can click on empty Sets and attempt to command them by combining them with verbs (to no effect) is what's confusing. Perhaps empty Sets should be unclickable - and Sets automatically disengage when nodes transform into a new state.

cmiya commented 8 years ago

@smurp @SusanBrown Thanks for the clarification re: hidden. I think that makes sense - out of the way, but still able to be pulled in. Like clearing away a workspace and putting certain objects to the side.

It's a bit unusual because the Discarded nodes are actually more removed, incapable of being pulled in - but physically more visible/close at hand (i.e. able to be clicked and dragged). Whereas the Hidden nodes are physically invisible/not close at hand (not able to be clicked/dragged), but actually still part of the graphing process, capable of being pulled in.

The case I was describing earlier - removing irrelevant or "faulty" nodes so that they are neither visible, nor capable of being pulled in - seems like a step up from discarded, perhaps a different function entirely.

smurp commented 8 years ago

I've just deployed https://github.com/smurp/huviz/commit/b84e526d4530e7501c503997f04c34b3c79d44be to both alpha and beta.

cmiya commented 8 years ago

I think we should clear this from the milestone as the remaining issues are enhancements that can be left until after testing to sort out.

ilovan commented 8 years ago

I agree - can you please create separate issues for each of the remaining items on the list and label them appropriately? Thanks

On Tue, Feb 23, 2016 at 11:30 PM, cmiya notifications@github.com wrote:

I think we should clear this from the milestone as the remaining issues are enhancements that can be left until after testing to sort out.

— Reply to this email directly or view it on GitHub https://github.com/cwrc/HuViz/issues/55#issuecomment-188101376.

Mihaela Ilovan

Project Manager Canadian Writing Research Collaboratory University of Alberta 4-20 Humanities Centre Edmonton, AB Canada T6G 2E5

780-492-7803 ilovan@ualberta.ca

antimony27 commented 6 years ago

@cmiya Can you confirm that the smaller tasks in this issue were separated out as Mihaela suggested? If so, can we close this ticket?