search

Raku / modules.raku.org

Source code for modules.raku.org - Raku module listing
https://modules.raku.org/
Artistic License 2.0
27 stars 27 forks source link

Tag page is a wall of text #107

Open sjn opened 6 years ago

sjn commented 6 years ago

Hei folks,

Please consider the following page.

http://modules.perl6.org/tag/RASPBERRYPI

This page (as of 2018-06-24) shows a wall of text (made of tags) followed by a short list of modules. Can someone please make it a little less wall-like? :)

Suggested solutions:

Thanks! :)

JJ commented 6 years ago

El dom., 24 jun. 2018 a las 23:12, Salve J. Nilsen (< notifications@github.com>) escribió:

Hei folks,

Please consider the following page.

http://modules.perl6.org/tag/RASPBERRYPI

This page (as of 2018-06-24) shows a wall of text (made of tags) followed by a short list of modules. Can someone please make it a little less wall-like? :)

Suggested solutions:

  • moving down the tag list below the modules
  • only showing the current tag this list represents
  • removing the tag list entirely
  • a combination of these

Any preference? It would probably make sense to remove the tag list...

JJ

stmuk commented 6 years ago

Or don't display only tag with 1 occurrence (most of them!) or a similar low number.

I notice the presence of RAPBERRY!

JJ commented 6 years ago

El lun., 25 jun. 2018 a las 11:08, Steve Mynott (notifications@github.com) escribió:

Or don't display only tag with 1 occurrence (most of them!) or a similar low number.

I notice the presence of RAPBERRY!

That's the nanocomputer all musicians choose!

sjn commented 6 years ago

My preference (fwiw) would be

  1. Make sure context of the page is kept obvious (it's a page listing all modules tagged with a specific tag)
  2. Make sure the useful content is show early and prominently (put it on top)
  3. Hide information that may be useful but isn't directly relevant to the current page, but make sure that this information can be revealed and that it's obvious to the reader that "we hid something from you here, click to show it"

And as a related issue - probably worth it's own ticket - find a way for people to help authors pick relevant tags (e.g. avoid tpyos), so the tag list doesn't become unnecessary long.

zoffixznet commented 6 years ago

Or don't display only tag with 1 occurrence (most of them!) or a similar low number.

👍

I notice the presence of RAPBERRY!

There's a normalizer file for that. Just need to add more things to it: https://github.com/perl6/modules.perl6.org/blob/master/tag-aliases.json

Suggested solutions

The quick-fix would be to leave low-count tags hidden on that page, some as how they're hidden on https://modules.perl6.org/ I think the code right now expands them if the selected tag is a low-count one, but it should instead not do that and only show the selected one.

That doesn't solve the problem for the long term though, when we get more modules. And that entire tag list is probably a nightmare for screenreaders.

bazzaar commented 6 years ago 
That doesn't solve the problem for the long term though, when we get

more modules. And that entire tag list is probably a nightmare for screenreaders. Why not take the whole tags system out of the hands of the module authors, and move it to the perl6 documentation domain. Then we could have a hierachial tag system, which would enable the reader to burrow down through well thought out categories and find logically grouped modules. Furthermore, then we could have two tag systems :

zoffixznet commented 6 years ago

Why not take the whole tags system out of the hands of the module authors, and move it to the perl6 documentation domain. Then we could have a hierachial tag system, which would enable the reader to burrow down through well thought out categories and find logically grouped modules. Furthermore, then we could have two tag systems : - Purpose (for the application of) - Code Feature (for the programming reference of) Both would be under the stewardship of the community, and that would enable every module to be properly tagged in quick order. bazzaar

I think you're overestimating the amount of available volunteers willing to do this manual labour on a regular basis. Consider, for example, that no one bothered to add new tag aliases to fix duplicate entries, which is a lot simpler to do.

Though, we could define that using / in a tag is equivalent to creating a nested tag, so say, tagging with web/API and web/framework would create group web and two tags in it, API and framework. And it would also be helpful to create a list of tag options for authors to pick from—even if there are currently no modules under a particular tag.

And instead of having to maintain the tags, as I understand you propose, those volunteers could just go through the list of modules who aren't using standardized tags and submit PRs to module authors to switch to standardized tags (and the site would either hide low-count tags entirely or only show them on a separate page)

sjn commented 6 years ago

Let's remember that tags are there to increase findability of modules, and that's it. Adding complexity or layers doesn't help with findability, neither does offloading the job to "the community".

The best tags are the ones that help people find the correct software despite them using a "different" vocabulary to describe what they need.

So, how improve the situation?

I'd like to suggest a few things one can do just before publishing:

bazzaar commented 6 years ago

I would argue that it is the "category scheme" that increases the findability of modules, but for what purpose? As a developer I might be interested in how a certain programming feature is coded, as a user I might be interested in finding the module to do a certain job. The category scheme(s) and purpose thereof is/are what we could agree on. The prescribed individual tags should be generic, and intuitive in a hierachial way, and consistent with the particular category scheme. Spelling mistakes / duplicates should be obvious easy to fix, given the prescribed generic tags. Aliases may not be at all necessary. I don't see it (the category scheme / tagging system) as being that onerous to maintain, it's a task that a newbie could provide input on, and the likelyhood is that once the (new) module authors see the system working, they will probably supply the tags (chosen from the prescribed category scheme(s)) anyway. The problem at the moment (admittedly from my somewhat-peripheral perspective) is that authors see the tag system as, "something extra to do for something that doesn't work" (ie. aid findability for a purpose). Of course I'm happy to be proved wrong, and I'm open to other approaches. I think the main thing to agree is "what system for searching for modules (and code) do we want", the rest should follow. ----Original message---- From : notifications@github.com Date : 25/06/18 - 13:18 (BST) To : modules.perl6.org@noreply.github.com Cc : barryfoxbat@btinternet.com, comment@noreply.github.com Subject : Re: [perl6/modules.perl6.org] Tag page is a wall of text (#107) Let's remember that tags are there to increase findability of modules, and that's it. Adding complexity or layers doesn't help with findability, neither does offloading the job to "the community". The best tags are the ones that help people find the correct software despite them using a "different" vocabulary to describe what they need. So, how improve the situation? I'd like to suggest a few things one can do just before publishing: Do a keyword check before uploading a new release. Are there any similar keywords? (hint of typos) Suggest keywords based on what people have actually been searching for, before they found your module (this might require some cooperation from e.g. the metacpan guys, or a cleverer way of keeping track of searches at modules.perl6.org) Remind the developer that keywords are for helping other users find your software — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread. {"@context":"http://schema.org","@type":"EmailMessage","potentialAction":{"@type":"ViewAction","target":"https://github.com/perl6/modules.perl6.org/issues/107#issuecomment-399931576","url":"https://github.com/perl6/modules.perl6.org/issues/107#issuecomment-399931576","name":"View Issue"},"description":"View this Issue on GitHub","publisher":{"@type":"Organization","name":"GitHub","url":"https://github.com"}} {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/perl6/modules.perl6.org","title":"perl6/modules.perl6.org","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/perl6/modules.perl6.org"}},"updates":{"snippets":[{"icon":"PERSON","message":"@sjn in #107: Let's remember that tags are there to increase findability of modules, and that's it. Adding complexity or layers doesn't help with findability, neither does offloading the job to \"the community\". \r\n\r\nThe best tags are the ones that help people find the correct software despite them using a \"different\" vocabulary to describe what they need.\r\n\r\nSo, how improve the situation?\r\n\r\nI'd like to suggest a few things one can do just before publishing:\r\n\r\n- Do a keyword check before uploading a new release. Are there any similar keywords? (hint of typos)\r\n- Suggest keywords based on what people have actually been searching for, before they found your module (this might require some cooperation from e.g. the metacpan guys, or a cleverer way of keeping track of searches at modules.perl6.org)\r\n- Remind the developer that keywords are for helping other users find your software"}],"action":{"name":"View Issue","url":"https://github.com/perl6/modules.perl6.org/issues/107#issuecomment-399931576"}}} { "@type": "MessageCard", "@context": "http://schema.org/extensions", "hideOriginalBody": "false", "originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB", "title": "Re: [perl6/modules.perl6.org] Tag page is a wall of text (#107)", "sections": [ { "text": "", "activityTitle": "Salve J. Nilsen", "activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png", "activitySubtitle": "@sjn", "facts": [ ] } ], "potentialAction": [ { "name": "Add a comment", "@type": "ActionCard", "inputs": [ { "isMultiLine": true, "@type": "TextInput", "id": "IssueComment", "isRequired": false } ], "actions": [ { "name": "Comment", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueComment\",\n\"repositoryFullName\": \"perl6/modules.perl6.org\",\n\"issueId\": 107,\n\"IssueComment\": \"{{IssueComment.value}}\"\n}" } ] }, { "name": "Close issue", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"IssueClose\",\n\"repositoryFullName\": \"perl6/modules.perl6.org\",\n\"issueId\": 107\n}" }, { "targets": [ { "os": "default", "uri": "https://github.com/perl6/modules.perl6.org/issues/107#issuecomment-399931576" } ], "@type": "OpenUri", "name": "View on GitHub" }, { "name": "Unsubscribe", "@type": "HttpPOST", "target": "https://api.github.com", "body": "{\n\"commandName\": \"MuteNotification\",\n\"threadId\": 349517171\n}" } ], "themeColor": "26292E" }

JJ commented 6 years ago

El lun., 25 jun. 2018 a las 13:54, bazzaar (notifications@github.com) escribió:

That doesn't solve the problem for the long term though, when we get more modules. And that entire tag list is probably a nightmare for screenreaders. Why not take the whole tags system out of the hands of the module authors, and move it to the perl6 documentation domain.

While a priori I could agree on a purely technical basis, and although basically it's the same people here and there, the documentation domain has enough work as it is. Adding any kind of additional burden would be kinda hard. So let's tackle

Then we could have a hierachial tag system, which would enable the reader to burrow down through well thought out categories and find logically grouped modules.

Furthermore, then we could have two tag systems :

  • Purpose (for the application of)
  • Code Feature (for the programming reference of) Both would be under the stewardship of the community, and that would enable every module to be properly tagged in quick order.

Tags are encoded in the META6.json file, which I am not sure can do that.

JJ commented 6 years ago

El lun., 25 jun. 2018 a las 14:11, Zoffix Znet (notifications@github.com) escribió:

Why not take the whole tags system out of the hands of the module authors, and move it to the perl6 documentation domain. Then we could have a hierachial tag system, which would enable the reader to burrow down through well thought out categories and find logically grouped modules. Furthermore, then we could have two tag systems : - Purpose (for the application of) - Code Feature (for the programming reference of) Both would be under the stewardship of the community, and that would enable every module to be properly tagged in quick order. bazzaar

I think you're overestimating the amount of available volunteers willing to do this manual labour on a regular basis. Consider, for example, that no one bothered to add new tag aliases to fix duplicate entries, which is a lot simpler to do.

Totally agree.

Though, we could define that using / in a tag is equivalent to creating a nested tag, so say, tagging with web/API and web/framework would create group web and two tags in it, API and framework. And it would also be helpful to create a list of tag options for authors to pick from—even if there are currently no modules under a particular tag.

And instead of having to maintain the tags, as I understand you propose, those volunteers could just go through the list of modules who aren't using standardized tags and submit PRs to module authors to switch to standardized tags (and the site would either hide low-count tags entirely or only show them on a separate page)

That could work.