search

cwrc / HuViz

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

Improve Settings Organization #276

Open smurp opened 5 years ago

smurp commented 5 years ago

Background

The Settings tab has gotten very cumbersome.

It seems that there are different natural Groups of settings

There might also be different Levels of settings:

Other considerations

Also, there are settings which if changed during interactions with the graph can actually affect counts and connectivity (eg Geoname depth, greed and username) and hence merit inclusion in the scripts. Those affecting styling might merit inclusion in scripts too.

Questions

  1. Any suggested changes to the proposed Groups?
  2. Any suggested changes to the Levels (including, is this even worthwhile)
  3. Which settings should be included in scripts?
  4. Should we permit the saving of settings?
  5. Should the saved settings have names?
  6. Should it be the whole bunch or just the ones the user indicates?
  7. If we're supporting settings going into scripts, maybe scripts are the way the "saving" of settings could be handled too. Imagine scripts which just have some settings changes. Imagine a script calling another script, which maybe just pulls in some settings. Clearly, this approach opens up some powerful possibilities beyond just settings, ie scripts calling other scripts, but this sounds like a new issue.
  8. Are there aspects of the layout of chrome://settings/ which we can borrow?

Proposal

antimony27 commented 5 years ago

Ok, here’s my first attempt at a response @smurp , pretty full of questions

I’ve laid out what I think you mean by each of these Groups. Please correct me if I am wrong.

Layout - How the graph appears. Ingestion - How to get data into the graph. Sizing - Of the nodes? If so, I think this could go under Layout/ Ontological - Unclear on what this would include. Geonames - Will this always require its own username input? Are there other sites that we will have to do the same for? (Nice infobox on this, btw) Images - Is this just ‘Show images in nodes’ at the moment? name lookup - Unclear to me as well - is this “matching”? Styling - Is this different themes and boxed labels, etc? I feel like this could be part of layout, but could be different if there was a line drawn about the differences between the two. Captioning - Is this just title display? Sparql - Information about data drawn from Sparql end points and monitoring HuViz as it ingests this data Settings - How is this different from Layout?

My responses to your queries:

Any suggested changes to the proposed Groups? Yes, see above. I think this warrants a convo and have added it to Friday’s agenda. Any suggested changes to the Levels (including, is this even worthwhile) I think it might be worthwhile, but we’d need to be very clear about how these levels were represented. Which settings should be included in scripts? I need to know what this entails before answering this. Is it possible to save all? Do they all take the same amount of work? Should we permit the saving of settings? If this is possible at the level of the individual, then I think it’s a great idea. Should the saved settings have names? Ooh, this makes it sound like perhaps it would have to be a series of saved settings… which could get more complicated. Should it be the whole bunch or just the ones the user indicates? Depends on above. If we're supporting settings going into scripts, maybe scripts are the way the "saving" of settings could be handled too. Imagine scripts which just have some settings changes. Imagine a script calling another script, which maybe just pulls in some settings. Clearly, this approach opens up some powerful possibilities beyond just settings, ie scripts calling other scripts, but this sounds like a new issue. Definitely a new issue, but I did wonder if this was the best way to save the settings at the individual user level Are there aspects of the layout of chrome://settings/ which we can borrow? I don’t know, but would this limit us to being only used on Chrome?

smurp commented 5 years ago

Here is a use-case for combining the saving of settings into a script: https://github.com/cwrc/HuViz/issues/242#issuecomment-482148253

Scripts are soon going to be able to be loaded and run via a url, so settings in a script means links with fully rendered and specially laid out graphs (needing saved settings).

smurp commented 5 years ago

Layout - How the graph appears.

Ingestion - How to get data into the graph.

Sizing - Of the nodes? If so, I think this could go under Layout/

Ontological - Unclear on what this would include.

Geonames -

Images - Is this just ‘Show images in nodes’ at the moment?

name lookup - Unclear to me as well - is this “matching”?

matching

Styling - Is this different themes and boxed labels, etc? I feel like this could be part of layout, but could be different if there was a line drawn about the differences between the two.

Captioning - Is this just title display?

Sparql - Information about data drawn from Sparql end points and monitoring HuViz as it ingests this data Settings - How is this different from Layout?

Bottom line @antimony27 I think it is easier to try out some groupings and then review. It will be super easy to make changes to this, so it is actually much faster to iterate on the real thing than to try to talk about it. It really will just amount to a little label on each setting as to which group it goes in.

I think it might be worthwhile, but we’d need to be very clear about how these levels were represented.
Yes, I think it will be slightly tricky to figure out what goes at each level too. Trying a first pass and reviewing will again be the answer I think

Which settings should be included in scripts? I need to know what this entails before answering this. Is it possible to save all? Do they all take the same amount of work? I think it is less about work (it will all be pretty automatic and data driven (because the settings are in a big data-structure which is easily read and changed). I think the real issue is whether there are settings which people will want to have cosmetic preferential control over which would be better to leave out of scripts. This is in contrast to settings which govern how the system actually works. Perhaps the latter are settings which must be in the scripts.

Should we permit the saving of settings? If this is possible at the level of the individual, then I think it’s a great idea. These things would be per-user by default.

Should the saved settings have names? Ooh, this makes it sound like perhaps it would have to be a series of saved settings… which could get more complicated. This is where being able to save some settings together as a script with a name ties in. Two birds, one stone

Should it be the whole bunch or just the ones the user indicates? Depends on above. We do already have ways to edit which commands make it into a script. This could just work with settings too.

If we're supporting settings going into scripts, maybe scripts are the way the "saving" of settings could be handled too. Imagine scripts which just have some settings changes. Imagine a script calling another script, which maybe just pulls in some settings. Clearly, this approach opens up some powerful possibilities beyond just settings, ie scripts calling other scripts, but this sounds like a new issue. Definitely a new issue, but I did wonder if this was the best way to save the settings at the individual user level I think what this really amounts to is figuring out how this looks on the settings page... What is the UX for triggering the saving of settings?

Are there aspects of the layout of chrome://settings/ which we can borrow? I don’t know, but would this limit us to being only used on Chrome? I was just meaning that the layout of the chrome://settings page might be something we emulate, not that we tie ourselves to the use of Chrome

Some of these things tie into https://github.com/cwrc/HuViz/issues/283

SusanBrown commented 5 years ago

Shawn, many thanks for these replies. You were going to go ahead and do a quick pass at a reorg and then get our feedback on it. If that’s still the plan, is there any part of this on which you need a response first? On Apr 15, 2019, 3:37 PM -0400, Shawn Murphy notifications@github.com, wrote:

Layout - How the graph appears.

Ingestion - How to get data into the graph.

Sizing - Of the nodes? If so, I think this could go under Layout/

Ontological - Unclear on what this would include.

Geonames -

Images - Is this just ‘Show images in nodes’ at the moment?

name lookup - Unclear to me as well - is this “matching”?

matching

Styling - Is this different themes and boxed labels, etc? I feel like this could be part of layout, but could be different if there was a line drawn about the differences between the two.

Captioning - Is this just title display?

Sparql - Information about data drawn from Sparql end points and monitoring HuViz as it ingests this data Settings - How is this different from Layout?

Bottom line @antimony27https://github.com/antimony27 I think it is easier to try out some groupings and then review. It will be super easy to make changes to this, so it is actually much faster to iterate on the real thing than to try to talk about it. It really will just amount to a little label on each setting as to which group it goes in.

I think it might be worthwhile, but we’d need to be very clear about how these levels were represented. Yes, I think it will be slightly tricky to figure out what goes at each level too. Trying a first pass and reviewing will again be the answer I think

Which settings should be included in scripts? I need to know what this entails before answering this. Is it possible to save all? Do they all take the same amount of work? I think it is less about work (it will all be pretty automatic and data driven (because the settings are in a big data-structure which is easily read and changed). I think the real issue is whether there are settings which people will want to have cosmetic preferential control over which would be better to leave out of scripts. This is in contrast to settings which govern how the system actually works. Perhaps the latter are settings which must be in the scripts.

Should we permit the saving of settings? If this is possible at the level of the individual, then I think it’s a great idea.

Should the saved settings have names? Ooh, this makes it sound like perhaps it would have to be a series of saved settings… which could get more complicated. This is where being able to save some settings together as a script with a name ties in. Two birds, one stone

Should it be the whole bunch or just the ones the user indicates? Depends on above. We do already have ways to edit which commands make it into a script. This could just work with settings too.

If we're supporting settings going into scripts, maybe scripts are the way the "saving" of settings could be handled too. Imagine scripts which just have some settings changes. Imagine a script calling another script, which maybe just pulls in some settings. Clearly, this approach opens up some powerful possibilities beyond just settings, ie scripts calling other scripts, but this sounds like a new issue. Definitely a new issue, but I did wonder if this was the best way to save the settings at the individual user level I think what this really amounts to is figuring out how this looks on the settings page... What is the UX for triggering the saving of settings?

Are there aspects of the layout of chrome://settings/ which we can borrow? I don’t know, but would this limit us to being only used on Chrome? I was just meaning that the layout of the chrome://settings page might be something we emulate, not that we tie ourselves to the use of Chrome

Some of these things tie into #283https://github.com/cwrc/HuViz/issues/283

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/cwrc/HuViz/issues/276#issuecomment-483388813, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAhUoL6IhTTbaPPDxK8LNH9P1UoB4LVaks5vhNT_gaJpZM4cYCkY.

smurp commented 5 years ago

@wolfmaul Could you improve the styling of the newly grouped settings?

First thing is probably the business about the label. It should be on the left rather than the right. I've pulled the input out of the label for greater flexibility AND linked them together with the for attribute.

Just a light styling to pretty it up a bit would be nice too, though let's get feedback from @SusanBrown and @antimony27 before going nuts on that. Maybe something a bit like chrome://settings if you want any suggestion.

smurp commented 5 years ago

Hey @wolfmaul about the Groupings. I would suggest we not do an accordion styling of the Groups on the theory that to explore them it requires a user clicking on each Group to peek inside. @SusanBrown and I had a brief conversation about that and we might end up going that way, but can we try something more like chrome://settings to see how being able to scroll to explore works?

Oh heavens, so sorry. There appears to be a vertical scroll bar on the whole page now. Not sure why. Might have to do with the Settings.

SusanBrown commented 5 years ago

Definitely a great improvement!

I have only really glanced at it in trying to do something else but initial impression is that making it clear what the titles of the things are and having them on the left immediately above the bar that relates to them would be a big help, with the gloss on what they do to the right and less prominent perhaps. I do find the length and the amount of scrolling a little overwhelming but am willing to wait on the accordion question until we are further along; I get your point, Shawn, that the current approach involves less clicking (but more scrolling and less prospect).

the other things is that the red or orange text is virtually unreadable on my laptop. can we swap it out for something distinct but darker like green or blue?

smurp commented 5 years ago

I know, what an eye-sore right? :-) This is before the layout has been prettied by Wolf! I made it work and now he is making it beautiful.

I've replaced the red and orange letters with a yellow background to indicate under construction

Note that there is a Setting up in General to render the Settings as an Accordion. Haven't solved the problem of turning the accordion off again when that checkbox is unchecked though... Also, that might never be worth doing :-)

@wolfmaul

On Wed, 17 Apr 2019 at 05:28, Susan Brown notifications@github.com wrote:

Definitely a great improvement!

I have only really glanced at it in trying to do something else but initial impression is that making it clear what the titles of the things are and having them on the left immediately above the bar that relates to them would be a big help, with the gloss on what they do to the right and less prominent perhaps. I do find the length and the amount of scrolling a little overwhelming but am willing to wait on the accordion question until we are further along; I get your point, Shawn, that the current approach involves less clicking (but more scrolling and less prospect).

the other things is that the red or orange text is virtually unreadable on my laptop. can we swap it out for something distinct but darker like green or blue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cwrc/HuViz/issues/276#issuecomment-483923147, or mute the thread https://github.com/notifications/unsubscribe-auth/AAF47Z2IBFWN3HESNJC6TYTPQ2KNRANCNFSM4HDAFEMA .

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

smurp commented 5 years ago

@SusanBrown It is worth looking at now from a layout perspective. @wolfmaul has done a lovely job.

There are still these issues:

Optional issues, pending @SusanBrown input. Should we do this stuff?

SusanBrown commented 5 years ago

This is a huge improvement! Thanks to both you and Wolf!

Haven't explored with any thoroughness but one thought: adjacent edge labels should go in Labels and not General section

Love the captions option (maybe I just hadn't seen it before).

Quite intrigued by some of the stuff in red!

smurp commented 5 years ago

@SusanBrown Adjacent edge labels has been moved to Labels