Group by categories by default

[ai]

Right now, when I open index of postcss.parts, I will see long list.

Long list is bad for reading. Because it is boring. For example, you can look to Play Market or iTunes. Instead of long list of films, thay hve grouped blocks on index.

So my suggestion:

1. Put categories on index.
2. When user will input a text in search box, show a list.

[ai]

@mxstbr BTW, it is a main reason why I still support plugins list in README.md.

If this issue will be fixed and @himynameisdave will move all plugins from README.md to its awesome postcss-plugins I can remove my list.

[mxstbr]

That's very true, and a very good idea!

I was waiting for github metadata in postcss-plugins, and then sort them by stars and/or by last time the plugins were updated, but this is a great solution.

[mxstbr]

@ai have a look now, is this a bit like what you imagined? 😃

[ai]

Very close :-).

But extra click is not good for this task. It should be closer to Play Market when you just can stop scrolling, because interesting content goes and goes :-)

[mxstbr]

@ai Sorry, I don't understand - can you take a picture/a video of what you mean?

[ai]

Right now I am in the way, so I try to explain in text.

Open PostCSS README. You will see category title and plugin list below, next category title and plugins list below.

This way is much better solve "what interesting I can add to my project" use case:

1. It is much interesting to read, instead of just big plugins list (user will read more plugins).
2. Scrolling is much easier, that clicking. So user will see more categories that in last UI.

[mxstbr]

Ah, I understand now.

That's very true, but the problem for me is that the postcss-plugins list assigns several tags/categories per plugin, which would mean the list isn't exclusive, a plugin could be in three different categories.
If I showed each plugin for each category in one massive list, the problem is that there would be repetitions of plugins which isn't optimal. (Also, the way the list is structured currently makes it awkward to sort by tag) That's why I made it the way it is now.

Pinging @himynameisdave, what do you think? I think @ai is right that it's nicer for "strolling", but based on the data I get from postcss-plugins I'd just leave it how it is now.

[ai]

What if on index we will show only most popular 10 plugins per category with "Show more"?

If we will have some popular plugin with 2 categories, we will show plugin only in "first 10" of first category and in the second we will hide it under "Show more"?

[mxstbr]

We don't have a way to sort by most popular at the moment, because I don't get GitHub data yet...

[ai]

Hm, it is not cool :-/ users can search in current Markdown file by browser search.

Maybe you can use http://npmsearch.com/ ? Also it will save you from static list repository. Because of course we should automatically load plugins from npm by postcss-plugin keyword.

[mxstbr]

That could work, but then we'd loose categorisation again... (because npm doesn't categorise the plugins AFAIK)

[ai]

Plugin developers can set plugin categories by special postcss-* npm categories.

[mxstbr]

Yes, but they aren't standardised like the ones in the Readme. :(

[ai]

We can change standard in Plugin Guidelines.

As temporary solution (until all developers will add special categories), we can use some whitelist JSON plugin > categories and all new plugins will go to Other category.

[mxstbr]

That's basically what I'm doing already: https://github.com/mxstbr/postcss.parts/blob/master/js/stores/AppStore.js#L11-L29

That's an okay solution, but not an optimal one because it requires trust in the developers to not mess up the categorisation. Hmm...

[ai]

We can also have black list for bad developers :-). I think it is problem, because right now developers do not mess with Plugin Guidelines rules.

[mxstbr]

So basically the optimal solution is one long list with Category headers, showing 10-20 most-starred/-downloaded/-used plugins and a "Show more..." link, right?

I'll look into npmsearch when I have some free time, maybe we can really do it with a category whitelist.

[ai]

Yeap. At least iTunes and Play Market uses this UI.

[mxstbr]

@ai npmsearch now has API docs, which means I can use it! (Thx @tmpvar )
What do you say about using that for now, making the default order based on popularity and leaving out the categories for now? You could then tell plugin authors to categorise their plugins in one main-category and however many sub-categories they see fit.
As soon as that is adopted we can then fully switch to the categories + show more idea.

[ai]

I see migration plan in:

1. Take plugins list and popularity order from npmsearch, but uses current design.
2. Uses first category from postcss-plugins and change design to latest suggestion above.
3. If everything will be nice, add extra rule to Plugin Guidelines. Announce it by Twitter. Change postcss-plugin-boilerplate script. Force all plugins to use special categories by issues. (anyway everyone is lazy right now, because of the holiday mood)

What do you think?

[mxstbr]

Ah didn't think of 2), good idea combining the two! 👍

Will start soon™

[mxstbr]

@ai There now is a first implementation in the branch npmsearch, but there are problems regarding the data integrity. Especially the links to the repository are very flaky, sometimes being ssh:// links, sometimes being git:// links and sometimes simply https:// links.

@tmpvar is this anything you can combat, or is that just in the nature of npmsearch?
If not, we might have to only request the name and the rating from npmsearch, match that to the corresponding plugin from postcss-plugins and then take the link from there, but that sounds incredibly unreliable...

[ai]

You can cover git URL to HTTP

[tmpvar]

use homepage instead of repo - npm-normalize should do this work for you (https://github.com/solids/npm-normalize/blob/master/index.js#L92-L122)

[tmpvar]

ok, it looks like there are still some getting through, will raise an issue on npm-normalize

http://npmsearch.com/query?q=dom&fields=name,homepage,repository&pretty=true