Refined-github: Add some options

[derimagia]

I noticed that you have an "against options" thought for this project. What's the reasoning for not adding options out of curiosity? Just so that it's a more simple interface?

Main thing I want to disable/enable sometimes is that usually I want the "Hides other users starring/forking your repos from the newsfeed" feature enabled, but sometimes I want to quickly look at it (and then disable it afterwards again). If I added a button to do this would it be likely be accepted? Or do you just not want global options that isn't in the github UI?

[sindresorhus]

Because options lead to bloat and people don't know what they want. That being said, ability to show starred/forks by others seems to be a common request. Maybe we could put a button somewhere in the dashboard UI. It would have to be very subtle though. Or maybe a keyboard shortcut to toggle it.

[paulmolluzzo]

I see a few possible issues with options:

1. Once we add an option we might get requests for other variations of the option to be supported, expanding each one. For example with this issue, we currently hide when someone pushes a branch but not pushes a tag or repo, so should we add independent options for each of the 3 variations? Another example, we hide tool tips so should we have an option for hiding each type of tooltip? What about toggling the display of the comment toolbar and having display options based on PR/Issue/Commit? (This is kind of a strawman argument, I admit.) Still there's that old adage "Give a mouse a cookie..."
2. This kind of extends the first: The current implementations don't always have those options easily separated. We hide a bunch of stuff on the dashboard but the CSS is short handed for brevity, so we'd have to separate all this stuff when building options. If we currently reuse CSS selectors we might have to repeat stuff with more specificity so we can apply granular options.
3. JS options are even more intertwined and harder to separate, and again, some are in different places that we might want to have "display on pages like..." Type options.
4. Defaults. If we make "show/hide new branches" an option, what's the default? I don't want to have to check/uncheck stuff that was originally "correct". And these defaults need to persist updates of course.

Also, looking ahead, what's going to be the rule on new features? Everything needs an option to be added that toggles the feature?

And this doesn't even get into non-Boolean options.

From what I can tell from times this is brought up people want to toggle one, _maybe_ two options. The easiest solution is just clone the repo, modify the one or two lines of code, and install from your local.

Ok, rant over. Sorry.

[derimagia]

I agree we don't want to over-bloat it with options, but maybe subtle ways to disable/enable the big features completely would be the best compromise.

If there's a button on the page then to do an action, they screw it (Like the copy button) - they don't get an option to remove the button. But for things like hiding information that for some people is useful then that's a bit different than faster horses. But I completely agree with you two.

In terms of defaults I don't think that's an issue - I feel like there already is defaults in it.

What other options have you been getting feature requests for?

[DrewML]

What other options have you been getting feature requests for?

@derimagia Here are some semi-recent requests for feature toggles:

• Request for toggles on multiple features
• Unhide comment box toolbar
• Unhide starring/forking notifications in dashboard
• Request for toggles on multiple features
• Request for toggles on multiple features

[DrewML]

I should also note that there are some basic instructions in the readme to workaround some features you may not prefer. In this case, the "Hides other users starring/forking your repos from the newsfeed" feature is implemented with CSS, so you can use a third party extension to override it.

I understand that solution may not be ideal, but it's a cost trade-off - the work to implement (and then maintain) feature toggles on our end gets expensive (and leads to lots of bikeshedding) fast.

[sindresorhus]

Just to be clear. If we were to do this, it would only be for toggling stars in the news feed using a keyboard shortcut. I would not accept anything else. Still not sure it's worth doing, but it's the one thing keeping a lot of people away from using this, they keep telling me in private and on Twitter.

[paulmolluzzo]

Starring repos are not hidden, just FYI. They were actually made larger. Maybe they're just overlooking it because they expect the smaller style?

[paulmolluzzo]

See #55

[sindresorhus]

@paulmolluzzo Stars on your own repos are hidden in the news feed. That's what people want to see.

[paulmolluzzo]

@sindresorhus oh, I see!

[fregante]

Being developers, everything would ideally be an option (hey, after all you're the one suggesting small focused modules instead of large frameworks 😜), but that's probably not necessary.

I understand @paulmolluzzo's concerns, but at the same time... I'm missing out on some great features because refined-github hides too much stuff (I do use that _Clone in GitHub Desktop_ button almost daily)

I would start with the most requested boolean options in the new options view in chrome://extensions. Perhaps someone already took care of creating an auto-UI builder for it? (i.e. schema in, auto-saving form out)

Probably the hardest part would be making the CSS togglable, as you said, but once we have an API for that, adding options would be pretty easy.

---

The suggestion of forking the repo leads to inevitably missing out on the new features and the annoying _"you're running a developer extension, disable it?"_ popup every so often in Chrome.

[hkdobrev]

I like @bfred-it's general direction of thinking, but his language implies a lot of options in the future. I am _for_ having options, but only if we try to constrain them to the most important things. For example about hiding actual features that might be useful.

E.g. I don't use GitHub Desktop at all, but when working with more junior people or for example designers who might work with code and GitHub daily, but use more basic Git features and use GitHub Desktop and the clone buttons all the time, they might find this extension useful only if they can still see the Clone to Desktop buttons.

What do you think? Do you have a list of GitHub features in mind that we actually prevent people from using and we could provide options for them?

From the top of my head:

• GitHub Desktop buttons
• File upload buttons
• Subscribe to your feed RSS link
• Blog and broadcast links

[octref]

• Adding a page with a list of checkboxes, one for each feature to Chrome's Option View.
• Split each feature into its own css and js.
• Load each feature using the preference.

Is this really hard to do?

[fregante]

@octref it's not as easy as it seems and that's not the point.

By the way I created the options manager I was talking about, but I ended up leaving out the UI generator.

[octref]

@bfred-it

OK, a few points:

• Forking and loading the extension to Chrome will
  
  
  
  • Lead to user fragmentation
  
  
  • Show popup for "Disable developer mode extensions"
  
  
• Suggesting people to fork and change the setting
  
  
  
  • People using GitHub don't necessarily understand JS/CSS/Chrome extension dev well
  
  
  • I don't see a flag/option in code for disabling features. I need to spend time to understand the code and change it.
  
  
• Users who are bothered enough to install this extension to improve their GitHub experience are probably nitpicky, and they can't/won't use it even if they disagree with only one point
• Only features the maintainer like could be added

How about:

• Splitting each feature into its own GitHub project/module, each having a index.js and index.css.
• Let user specify the list of features they want, and this extension will download each from the GitHub repo
• The repo itself could be

features.forEach((f) => {
  injectJS(f.js)
  injectCSS(f.css)
})

The codebase will also be more maintainable. I believe small, focused module is also @sindresorhus 's philosophy.
Not-loading unused features also reduces bloat.

OK I realize this is no small amount of work. And this repo is standardjs-ish, but I like a few features but not others. Specifically I have all the font in the CSS installed but I prefer GitHub's default font.

[sindresorhus]

@octref Think of this extension more like iOS than Android. We favor a complete and opinionated experience. That might not work for everyone, and that's ok. I'm open to adding an option for fonts and whether to "hide stars on your own repos in the newsfeed", but not much more. This project is MIT licensed, so anyone are free to build something more modularized for their own liking, but it's not gonna happen here.

[hkdobrev]

My opinion regarding options is more about things working together. If you have options it is harder to make all possible cases work well. Everybody would have a different combination of options which will hide some elements or add buttons. We have already adjusted some things so things work well together with other extensions.

Let's say the extension is removing a panel from a page. And if we were to introduce an option whether to remove or keep that panel. Then another feature which adds some new buttons or change something will need to deal with that panel as well. Basically options will dramatically increase the surface area of testing and maintaining the extension.

[sindresorhus]

@bfred-it Did you ever extract your options stuff into a reusable module?

[fregante]

I haven't but I can next week if you want

[fregante]

Here you go: https://github.com/bfred-it/webext-options-sync

This is the first part of what I had build. It's pretty small and self-contained. You can see it use in my github-clean-feed extension:

• Defaults definition (+ migrations)
• Usage in content.js
• Form autosave/autoload in options.js

OptDom, the options form generator, will come as a separate plugin since it's not strictly necessary.