Coding Phase - Week 6 Report

Last Week

  • Remove 11ty and Astro completely
  • Support Mustache partials
  • Implemented dynamic routing in customized generator
  • Working on the PR regarding the media field in manifest.json of plugins

This Week

  • Write CI scripts to build the site on Github Pages every 30 minutes
  • Implement search feature
  • Continue to refine UI

looking forward to the update demo :slight_smile:

1 Like

I updated the demo in my personal repo since the pr hasn't been merged yet and the main repo is empty now. :smiley:

1 Like

mobile looks good :slight_smile:

would it be possible that the plug-in in click on shows basic information inline?
Can add a button to install it directly from that overview?

Sounds great, that can be done with a popover.

looking forward to a prototype :slight_smile:

I'm afraid I've lost track of everything.

  • Are the categories fixed to the valid categories or do they build up dynamically according to what the plugin maifest files provide?
  • The topic preview images has only been discussed, but not yet implemented/specified?
  • Is it planned to show the tags of the plugins on the page ?

thanks for asking!

Category fields are fixed to

const allPossibleCategories = ['appearance', 'developer tools', 'productivity', 'themes', 'integrations', 'viewer', 'search', 'tags', 'editor', 'files', 'personal knowledge management'];

And the homepage is generated dynamically based on the plugin categories field inside the manifest which can only contain the categories inside allPossibleCategories.

Do you mean screenshots or the ones PackElend mentioned above? If it's screenshots, I am working on adding a screenshot field to the manifest file. You can see the PR in the main codebase. If you are talking about the hover overview on homepage, then yes, it hasn't been implemented yet.

There is no plan to show tags on the homepage, but they will be shown on the detail page of each plugin. And it will also be used by the search feature.

just thinking out loud, could we switch to GitHub-label approach.

As a first step, we could simply store a JSON on GH which contains this array, to avoid code changes if categories are changed.

how does the user know, that tags are taken into account?
There should be an options to filter by tags easily / well seen by user.

This is built into the joplin/webpack.config.js at dev · laurent22/joplin · GitHub in the plugin generator. So I think it might not be up to us to maintain it. But in case of future changes, I could fetch this piece of code and extract the allPossibleCategories variable dynamically.

Filter by tags is not really a practical idea to me since the tags are not predefined and there can be tons of tags meaning the same thing which can simply create chaos. And also I don't think users really need to know about this. Users don't know what's the tags of a plugin beforehand, so they can not match it on purpose. My thought is that adding this to the search is just to build relevance, it works as keywords, which means users can reach this plugin when they search the tags of the plugin.

This depends on how you manage them, it applies for the tags used here in the forum as well.
There could be managed and unmanaged tags, I don't know yet.

From a user perspective point of view, I would like to know how the search function is working and how can I influence it at glance.
Wondering why certain things appear although I may have not asked for them, is not an ideal UX :).

I'll discuss it with the mentors

You are right, but the difference between the tags in forum and the keywords in manifest is that, in forum, a regular user cannot add new tags but in manifest everyone can describe their plugin with their own keywords. It made managing tags very difficult since these fields are maintained by plugin developers.
I've thought about filtering and sorting plugins by tags and categories, but under the UI post, laurent suggests that we don't need a complex 'advanced search' and they also suggest removing the category filter next to the search bar, so I think laurent probably doesn't want this? And also, the field in manifest is named keywords instead of tags, so it might be less strange for it to directly play a role in the search. Anyway, we can continue this discussion under the UI post. If most users think filters for categories and keywords are necessary then I'm happy to bring these back.

it depends on how you configure it, there are discourse forums where you can add tags on your own

that is something we have to discuss in the community (in the long term).


it is discussed.
You can put a file in containing the categories.
Please create a separate PR which does this. It shall include the modification of the plug-in template as well.

Do you mean putting a JSON file containing categories under and we include this JSON in plugin manifest templates?

yes to both, we want to place is separately to maintain it more easily

1 Like