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

[UX] Add "tags" to the modules page and in .info files #37

Closed
jenlampton opened this Issue Sep 10, 2013 · 117 comments

Comments

@jenlampton
Copy link
Member

jenlampton commented Sep 10, 2013

In order to group modules intelligently, let's debate whether we should use package, tags, or something else.

Here's a compromise to move forward on tags discussed during today's UX meeting:

  • Include tags[] in the .info file and display them on the modules page.
  • Remove additional UI fields for "Tags" and "Module Source".
  • Make it so that the search box includes the tags when doing a search.

And here are the follow-up issues:

  • #3146 Add checkboxes for module source: core/contrib/custom
  • #3147 Add a drop-down to browse by Tag
  • #3148 Alphabetize by module name and remove package groupings

Current PR screenshot:
screen shot 2019-01-01 at 11 14 49 am


PR by @docwilmot: backdrop/backdrop#900
PR by @docwilmot: backdrop/backdrop#1839
PR by @jenlampton: backdrop/backdrop#2110
PR by @docwilmot: backdrop/backdrop#2234
PR by @jenlampton: backdrop/backdrop#2293

Pipe-dream Screenshot - shows filters for keyword / tag / core vs contrib
screen shot 2018-04-29 at 10 26 49 pm

@c4rl

This comment has been minimized.

Copy link

c4rl commented Sep 10, 2013

I'm wondering if "package" is even useful? What if everything were just in alphabetical order?

@cafuego

This comment has been minimized.

Copy link

cafuego commented Sep 11, 2013

Group modules by the case insensitive version of whatever info file key you end up using.

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Sep 12, 2013

Packages definitely are not the best solution, and I'm open to any other ideas.

Packages are what's in there now, so it seemed the easiest thing to do (baby steps) would be first organize the modules by package, and "field" "translation" and "other" seems like a good place to start (based on the good work D8 has done already on this front). I'd also be fine with alpha order + search box, or some kind of smart tagging system, if we could come up with reasonable tags.

@cafuego

This comment has been minimized.

Copy link

cafuego commented Sep 14, 2013

I wonder if mirroring the general menu structure might be an idea. Structure modules, People modules, Content modules... and then optionally menu sub-items too. (eg: Web Services)

The module config or UI location would then match the category the user found the module in.

Cheers,

  • P.

On 12/09/2013, at 6:41, Jen Lampton notifications@github.com wrote:

Packages definitely are not the best solution, and I'm open to any other ideas.

Packages are what's in there now, so it seemed the easiest thing to do (baby steps) would be first organize the modules by package, and "field" "translation" and "other" seems like a good place to start (based on the good work D8 has done already on this front). I'd also be fine with alpha order + search box, or some kind of smart tagging system, if we could come up with reasonable tags.


Reply to this email directly or view it on GitHub.

@sun

This comment has been minimized.

Copy link

sun commented Sep 14, 2013

The architectural flaw is that every module may encompass multiple categories, but it can only expose itself in one category. Consequently, users are not able to find modules in the category they expected them to be.

By advancing on the single category pattern, the usability problem only becomes bigger. The result is a massive list of categories, which each contain a few modules only. In almost all cases, you expect a module to be in a different category.

The best architectural solution and recommendation I can provide is to Introduce tags[] in .info file to categorize modules by provided functionality:

  1. Remove package altogether.
  2. Remove the fieldsets/grouping altogether.
  3. Introduce tags (or keywords) to properly classify modules into topics.
  4. Expose a trivial, JS-driven instantfilter that allows you to drill-down the total list based on topics.

This means that a module can or will be exposed in multiple categories, but that is not a problem. Much rather, that is the proper answer to the original and primary usability problem and user story that all the futzing with categories and grouping is trying but failing to solve:

As a user seeking for particular functionality that I have in mind, I want to learn what feature options are available to me.

The key is that a user does not have a module name nor a package/category name in mind. If anything, a user has topical keywords for some functionality in mind. The user's intention is to drill down the list of available features, so as to see whether there is one available.

We can support the user in solving that problem by two discrete interface controls:

  1. A textual search (as implemented in D8).
  2. A keyword filter.

The additional benefit of the proposed solution is that the alternative use-case and user story is inherently resolved by this, too:

As a goddamn user, can you please just simply show me everything that's there?

The removal of all enforced grouping turns the interface into a simple list that can be easily digested. This allows you to see and learn about all features that are available to you (to discover something you may not have thought of but might want to use).

Lastly, the concept also solves the power user case: If you already know the exact name of the module you want to enable or act on, simply scroll down the alphabetical list. No need for searching, filtering, discovering, probing, or whatnot.

The concept has been architecturally designed to allow contributed modules to come up with new tags/keywords, whereas the implementation ensures that only tags/keywords that are shared by more than one module are exposed to the user. This allows for flexibility and freedom, but one part of the design is certainly that core is supposed to lead with good examples that can be followed by contrib (reducing the amount of newly invented tags/keywords).

The only part in the proposal that is still debatable is the actual list of keyword names. E.g., whether to use short, lowercase, and more technical tags (à la "dev", "rest", "content", "field"), or whether to use longer, human-readable tag labels (à la "Development", "RESTful web service", "Content authoring", "Field type"), whereas the latter may obviously lead to unintended differences (due to typos, spelling, letter-casing, etc).

But all things combined, my confidence in this solution to be the ultimate answer hovers around 100%. ;)

@maxpearl

This comment has been minimized.

Copy link

maxpearl commented Sep 15, 2013

The drupal contrib module module_filter might be a good place to start for ideas with the UI. It's got nice JS collapsible fieldsets based on package, and a very usable filter.

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Mar 27, 2014

Module filter provides the search box - which is good!

Unfortunately it also provides vertical tabs - which is not great UX. Vertical tabs meant to hide things that are unimportant - things that can be skipped when on that page. Hiding things on the module page is sortof the opposite of what we want here, - everything in this list is equally important, we just need a better way to digest the fire-hose of information.

@jenlampton jenlampton changed the title Use "package" to intelligently group modules in field sets on modules page Modules page cleanup Jul 29, 2014

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Jul 29, 2014

See also #263 (closed as a dupe of this issue)

@jenlampton jenlampton changed the title Modules page cleanup Remove the by-package groupings from the modules page Aug 15, 2014

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Aug 15, 2014

I'm leaving this issue open to continue the modules page groupings discussion, but have moved the other, more general module page cleanup over to #300. And also, there's a PR there :)

@quicksketch quicksketch modified the milestones: 1.x-future, 1.0.0 Nov 24, 2014

@jenlampton jenlampton changed the title Remove the by-package groupings from the modules page [UX] Re-organize modules into more useful groupings on the modules page Dec 19, 2014

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Dec 19, 2014

We haven't come to a consensus about removing / replacing packages, but we do need to do some cleanup on the modules page. Right now the only module that's not in the "core" fieldset is "Views UI" which looks a little weird.

It will be nice to have a "views" fieldset here because there's a lot of contrib modules that would group nicely into it. But being the only core module on it's own doesn't make much sense.

Here's a proposed reorganization based on a combination of what we have in core now, and where contrib modules might like to add to these groups. Of course, if a contrib project still wants to add it's own packages, that's also fine.

modules-reorg

@docwilmot

This comment has been minimized.

Copy link
Contributor

docwilmot commented Dec 19, 2014

Of all the proposals I think @sun's proposal sounds the best option. No matter what package scheme you think up, it will degenerate into disarray eventually as long as developers are allowed to create their own packages. I think a simple alphabetical list with tags sounds excellent.
Failing that, unless there is some way to find which modules are core/non-core, I think it is simpler to leave all core modules in a big "core" fieldset as is traditional, rather than scattering them like this.

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Dec 19, 2014

...I think it is simpler to leave all core modules in a big "core" fieldset as is traditional, rather than scattering them like this.

...or "scatter" them like this and add a "core" tag to each one of them :)

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Dec 19, 2014

I intended my last comment to be a pun, but thinking about it I believe that it is not such a bad idea to provide a core/contrib/all switch that shows/hides modules. Core distinction does not have to be any special implementation such as a tag/flag or .info file entry since all core modules are kept under /core/modules and contrib under /modules we can take advantage of this architectural design.

@docwilmot

This comment has been minimized.

Copy link
Contributor

docwilmot commented Dec 19, 2014

...or "scatter" them like this and add a "core" tag to each one of them :)

GitHub should have "like" buttons.

But seriously, an alphabetical list with an link to optionally "group by tags" gives the best of both worlds. Plus with the fast filter utility, we add the options to "search by module name" or "search by tag".
Win win and win.

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Dec 22, 2014

We don't have the time to add a new organization method like "tags" for 1.0.0. But we can certainly evaluate that for 2.x.

Since that seems to be what this issue is mainly about, I've moved my reorg suggestion over to #494

@jenlampton jenlampton changed the title [UX] Re-organize modules into more useful groupings on the modules page Replace the by-package groupings from the modules page with something more like "tags" Dec 22, 2014

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Oct 19, 2018

@herbdool yep: backdrop/backdrop#2293 (comment) 😄

I tested by searching for "content", also "mail". Neither brought up all the modules with those tags.

Other than that I like the simple change.

...not sure which modules you were referring to by "all the modules with those tags".

@herbdool

This comment has been minimized.

Copy link

herbdool commented Oct 20, 2018

@klonos I took another look and I can't recreate the issue I noticed.

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Nov 8, 2018

@jenlampton I have pulled your changes and tested locally. When trying to enable the devel module (manually installed by copying and extracting under /modules - not via the Project Installer). I got this:

screen shot 2018-11-08 at 11 37 44 pm

...wondering if it has to do with https://github.com/backdrop/backdrop/pull/2293/files#diff-2a3910dbb693d734a6867b68d5c83656R524

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Nov 8, 2018

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Nov 8, 2018

@jenlampton I have tested this twice already:

  1. cloned your fork: https://github.com/jenlampton/backdrop
  2. switched to the 37-module-tags branch
  3. started fresh installation
  4. first thing to do is install devel module and then try to enable it from the UI
@klonos

This comment has been minimized.

Copy link
Member

klonos commented Nov 9, 2018

...I have tested the same, but this time tried installing devel via the Project Installer. There was no message about enabling additional (already enabled) modules. So this is limited to installing "manually" by copying things into /modules dir. I hope that this helps.

@docwilmot

This comment has been minimized.

Copy link
Contributor

docwilmot commented Dec 7, 2018

i listened to the design meeting yesterday where we (again) spoke about tags in project info files. i started off with the PR for that issue long ago, just to reiterate why i'm not bothering. what we need is project module to be modified to use tags, which means reading info files after webhooks fire for new releases, and creating new fields on project nodes to match these new tags. THEN we can use these fields to add to module search, and THEN add it to the Intaller Server module to broadcast these new fields to client websites Installer modules. So really, adding tags to core will not help with any of this. worse we've decided not to actually expose tags to the module page UI, meaning no incentive for contrib to use tags anyway.

we need @quicksketch and @jenlampton to create the changes on Backdrop CMS and project module first, otherwise this will stay in limbo.

my thoughts

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Dec 9, 2018

Thanks for taking the time to post this status summary @docwilmot, it really helps 👍

...even if we don't end up having the time to implement all the prerequisites for this to happen in 1.12.0, I would still like to see an instant core/contrib/custom toggle added to the modules page.

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Dec 10, 2018

we need @quicksketch and @jenlampton to create the changes on Backdrop CMS and project module first ...

I think we may have a chicken and egg problem here. I've been holding off on any changes to Backdrop CMS or project module because there's no data to work with. This issue adds the data, which will unblock those issues.

... the prerequisites for this to happen in 1.12.0 ...

There are no prerequisites for this to happen in 1.12.0. It all has to get done, and this seems like the simplest place to start :)

@docwilmot

This comment has been minimized.

Copy link
Contributor

docwilmot commented Dec 10, 2018

Well, actually, not really @jenlampton. Firstly, core modules dont get packaged as contrib releases do, so this PR wont help. Secondly, suppose you got into the Project module changes and needed some contrib modules to test it, we can easily create some dummy modules with tags for test purposes, or I can certainly add tags to some of the ports I've done; theres about 50 of those. So we have enough chickens.

I think the process needs to be:

  • get done the changes in Project module that detect tags (and maybe other .info file metadata at the same time, see backdrop-ops/backdropcms.org#100)
  • determine the mapping that we need for displaying fields with those tags on the main site
  • update project browser server to serve that data
  • update Installer to use that data
@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Dec 10, 2018

But none of those changes solve any of the UX issues with the admin/modules page search, and this issue does (though it is only a small step forward -- it's what we have consensus on, so we should start here).

Plus, this issue is what sets the official "Tags" we'll use on all the contrib projects, so this would be helpful if it came before (or at least at the same time) as contrib.

Anywho -- my point was only that there are no prerequisites for this to happen in 1.12.0. And that still stands :) It still all needs to get done eventually.

@docwilmot

This comment has been minimized.

Copy link
Contributor

docwilmot commented Dec 11, 2018

Yes, agreed there is no reason not to finish this issue, only that I've realised it accomplishes little in the end.
I'm hoping though that my point is clear, that to actually start categorizing our projects, the points I raise above make sense.

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Dec 11, 2018

that to actually start categorizing our projects, the points I raise above make sense.

Yes, fair enough. The good news though is that neither changing backdropcms.org or project module needs to be held up on backdrop release milestones :)

@docwilmot

This comment has been minimized.

Copy link
Contributor

docwilmot commented Dec 12, 2018

@jenlampton I've had think. How about you study backdrop-ops/backdropcms.org#100 and actually create the fields on the project nodes to store this data. Once that happens you could leave those fields hidden from the front end until you find the time to actually create a proper front end UI. Meanwhile, the rest of us can continue looking into how to modify borg_github to fill those fields with data on project release events, and also to serve that data to Project Browser Server and Installer; since it would also be invisible to site installations until we update Installer in a new Backdrop core release, we can also test to our hearts content.

I had a look at the code for project module. Unless I'm mistaken, to populate your fields we'd need to implement hook_github_project_validate_release() with code like:

  $project_node->field_project_tags[LANGUAGE_NONE][0] = array('value' => 'user experience');
  $project_node->field_project_tags[LANGUAGE_NONE][1] = array('value' => 'views');
  $project_node->field_project_documentation_url[LANGUAGE_NONE][0] = array('value' => 'github');
  $project_node->field_project_maintainers[LANGUAGE_NONE][0] = array('value' => 'jenlampton');
  etc

If @quicksketch can verify this, I'd happily PR after you @jenlampton have created those fields.

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Jan 1, 2019

@klonos I've pushed a new PR that addresses most of the comments you left on the last one, and the problem you reported is also fixed :) Your comment about required modules actually steered me in the correct direction! Thank you!

Updated PR: backdrop/backdrop#2293

@klonos

This comment has been minimized.

Copy link
Member

klonos commented Jan 1, 2019

Thanks @jenlampton I have tested the PR sandbox (although it could use a refresh), and I have also left a couple of comments in the PR. Other than than RTBC from me 👍

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Jan 1, 2019

Comments addressed, new sandbox created, and ready for a final (?) review: backdrop/backdrop#2293

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Jan 1, 2019

Pushed an updated PR, tests should be passing now: backdrop/backdrop#2293

@jenlampton

This comment has been minimized.

Copy link
Member

jenlampton commented Jan 2, 2019

Rebased, and pushed an updated PR.

@quicksketch

This comment has been minimized.

Copy link
Member

quicksketch commented Jan 2, 2019

PR looks good. Minor feedback: backdrop/backdrop#2293 (review)

@quicksketch

This comment has been minimized.

Copy link
Member

quicksketch commented Jan 2, 2019

I've merged backdrop/backdrop#2293 into 1.x for 1.12.0. Thanks everyone! It's a trimmed down implementation with just tags and adding that into the filter search. This sets us up for having tags as part of Project Browser while also exposing this data into the Backdrop UI.

@jenlampton jenlampton referenced this issue Jan 15, 2019

Open

1.12.0 release checklist #3473

21 of 30 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment