Automatically update package/project/tool submission categories in form from permitted categories csv

[Bergam0t]

https://github.com/hsma-programme/decision_intelligence_atlas/blob/main/.github/ISSUE_TEMPLATE/1-new_package_project_tool_submission.yml

In this we specify the categories that users can select from a dropdown.

Would be good to automatically pull this from somewhere rather than having to remember to update it manually when new categories are added.

[amyheather]

Agreed - now, if it doesn't have a relevant category, it won't get displayed.

Although, I do wonder if we might want to consider a simpler approach? So instead of having the set of categories ("analysing and improving", "automation of reporting") that always divide them, making it more open?

So instead, everything is all just there in one big list of things, and people explore it purely using "order by", "categories" sidebar, and "filter"? I'm maybe leaning towards that - simpler to maintain, and makes it more customisable for people viewing.

Also helps avoid the issue of things being across multiple categories so appearing duplicated.

[amyheather]

Although, related issue is keeping the list of possible categories in the issue template up-to-date, as that is manually maintained also... in which case, there may be argument for CSV or similar, if the issue template can base it off that.

[Bergam0t]

It's a tricky one!

I wonder if maybe the (auto-updating via a github action) csv is the way to go for managing the issue template side only. Then I think you might have a point with the general layout - I went for that to try to make it simpler to navigate, but the burden for maintenance is going to be a lot higher, I think. Maybe it would level out after a while once we had a decent set of headers defined, but unsure, and I think you're right that having some tools appearing under multiple headers may be unintuitive.

Maybe what's needed is an upgrade to the category filters like in quarto-dev/quarto-cli#12667 - so that multiple categories can be selected simultaneously, which I think may be important for users who only work in a single language. Ideally I'd separate out the languages into their own separate filter type, but I'm not sure that's possible. For now, the layout does at least mean you can filter by a language and then look at things under the different headers, navigating via the table of contents.

It would perhaps be quite nice (depending on the number of categories we end up with) to be able to repeat the filters at the top of the page, maybe as larger buttons that increase the visibility of them to users.

[amyheather]

Agree with everything. Definitely worth exploring that GitHub issue linked above. It got me thinking, I wonder if there also any custom possibilities with divs. I haven't played with quarto blog posts and filtering before this, so I don't know how applicable it is, but for des_rap_book I did make a button at the top of each page where users could toggle between seeing Python or R content.

The page then updated via javascript - https://github.com/pythonhealthdatascience/des_rap_book/blob/main/scripts/language-selector.js - which all pages had thanks to importing with include-after-body in _quarto.yml

<script>

function setLanguage(lang) {
  // Store the selected language in localStorage
  localStorage.setItem('preferredLanguage', lang);

  // Update button active state
  document.querySelectorAll('.language-button').forEach(btn => {
      btn.classList.remove('active');
      if (btn.textContent.toLowerCase() === lang || (lang === 'both' && btn.textContent.toLowerCase() === 'both')) {
          btn.classList.add('active');
      }
  });
  // Show/hide the appropriate content
  if (lang === 'python') {
      document.querySelectorAll('.python-content').forEach(el => el.style.display = 'block');
      document.querySelectorAll('.r-content').forEach(el => el.style.display = 'none');
  } else if (lang === 'r') {
      document.querySelectorAll('.python-content').forEach(el => el.style.display = 'none');
      document.querySelectorAll('.r-content').forEach(el => el.style.display = 'block');
  }
}

// On page load, set the language based on localStorage or default to Python
document.addEventListener('DOMContentLoaded', function() {
  const lang = localStorage.getItem('preferredLanguage') || 'python';
  setLanguage(lang);
});

</script>

The buttons were made with a bit of CSS - https://github.com/pythonhealthdatascience/des_rap_book/blob/main/styles/language-selector.css

.language-selector {
  margin-top: 5px;
  margin-bottom: 5px;
  margin-left: 25px;
}

.language-button {
  padding: 8px 16px;
  margin-right: 8px;
  background-color: #f0f0f0;
  border: 1px solid #ddd;
  border-radius: 4px;
  cursor: pointer;
}

.language-button:hover {
  background-color: #e0e0e0;
}

.language-button.active {
  background-color: #2596be;
  color: white;
}

However, I was always writing in my quarto files like -

::: {.r-content}

Show this if R button is clicked!

:::

::: {.python-content}

Show this if Python button is clicked!

:::

[Bergam0t]

I wonder if a simpler workaround for now - inspired by what you were saying about about Python and R - is actually to switch the headers to R, Python, PowerBI, Tableau and Julia instead. Maybe another one for 'web-based tools' or something like that.

Overall, there will be significantly fewer language options and they're not likely to substantially change over time - additions would I think be relatively few and far between, so maintenance becomes easier.

There will be some things that appear in more than one place (e.g. DES RAP book) but that might not be so unintuitive.

This then removes the burden of adding languages as a filterable category in addition to the main icon-based tag (which I haven't actually documented and is a pain).

Then still explore the previously linked code snippet for adding in multi-select of categories.

From what I can see, tweaking how the 'categories' are dealt with to do what I'd ideally like (multiple filter types with tickboxes to multiselect, bit like an online shop) is somewhere between 'really difficult' and 'practically impossible' at present. Not helped by the fact that 'filtering' is a different thing entirely in Quarto listings so tricky to search for!

[amyheather]

Interesting suggestion...

That would resolve #28, as would remove the language icons from the cards in that case.

And you're right - often, people are looking for a particular language - and that is indeed more static and "easier" too to categorise things, as it's more black and white than "is this automation of report" or "demand forecasting" or "improving performance", which can often be a lot blurrier, with more projects falling into multiple categories.

I think it sounds a good idea!