Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance UI to allow some filter dropdowns to be hidden #306

Closed
frankiejarrett opened this issue Mar 8, 2014 · 7 comments
Closed

Enhance UI to allow some filter dropdowns to be hidden #306

frankiejarrett opened this issue Mar 8, 2014 · 7 comments

Comments

@frankiejarrett
Copy link
Contributor

In an effort to free up more real estate on the Stream Records screen, I would like to propose that we think about hiding most of the dropdown filters by default (Connectors, Context and Actions).

screen_shot_2014-03-07_at_7_52_05_pm

  1. These controls would be available as a toggle.
  2. The preference could be stored as user meta for the current user, so if they always want the controls visible, no problem.
  3. The additional dropdowns will be show automatically if one of the Connector, Context or Action links is clicked.

screen_shot_2014-03-07_at_8_00_38_pm

I think this would give things a lot more breathing room and make the records screen less overwhelming for folks who don't often utilize these controls.

/cc @shadyvb @jonathanbardo @powelski @westonruter Your thoughts?

@jonathanbardo
Copy link
Contributor

I think author and connectors are the most important in the UI. We are really missing real user data on for this kind of decisions. We currently don't know for sure how users uses our plugin.

@frankiejarrett
Copy link
Contributor Author

@jonathanbardo Thanks for chiming in. Yeah you might be right that Connectors is also important since it could really be considered the top-most level of record categorization.

Yeah not knowing what users are actually doing is the struggle with something like this, and why it's more of an open question/suggestion rather than a requirement. This is a problem I'm sure many other thousands of plugin authors are facing as well.

The motivating factor behind proposing that the toggle value be saved as a user preference was to circumvent anyone being upset about the controls permanently changing, and instead, just giving them this as an option to save space if they want to.

@shadyvb
Copy link
Contributor

shadyvb commented Mar 10, 2014

  • I think we should let users choose what filters they're using, through Screen Options.
  • I really think we need to put some analytics into the plugin to measure how people are using our plugin. This can be put in an opt-in additional plugin that users would install to help us improve Stream. We should also state the purpose/methodology of analytics quite clear so people would understand. Example of such analytics would be mainly user/screen options, and frequency of feed access ( if enabled ), some kind of click heat map maybe ?

@frankiejarrett
Copy link
Contributor Author

@shadyvb Are you suggesting that perhaps dropdown filters should be tied to which columns are selected in Screen Options?

To you second point, I agree this should be done at some point. I'm just not entirely sure when yet. First we need to decide what info we need, how to get it and what the incentive is for the user besides "being nice". We can discuss this more somewhere else, not in this issue.

@shadyvb
Copy link
Contributor

shadyvb commented Mar 11, 2014

@fjarrett I wasn't suggesting that, although that seems nice, but you would still want to skip some filters but keep their columns visible. What i was suggesting is to create a new option set to manage filters visibility.

@frankiejarrett
Copy link
Contributor Author

@shadyvb Oh nice! I like your idea for new options. Creating an issue that now and closing this one.

@frankiejarrett
Copy link
Contributor Author

Replaced by #329

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants