search

mxstbr / postcss.parts

A searchable catalog of PostCSS plugins —
http://postcss.parts
MIT License
46 stars 11 forks source link

Group by categories by default #12

Open ai opened 9 years ago

ai commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

ai commented 9 years ago

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 commented 9 years ago

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

ai commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

ai commented 9 years ago

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 commented 9 years ago

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

ai commented 9 years ago

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

mxstbr commented 9 years ago

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

ai commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

mxstbr commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

Ah didn't think of 2), good idea combining the two! :+1:

Will start soon™

mxstbr commented 9 years ago

@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 commented 9 years ago

You can cover git URL to HTTP

tmpvar commented 9 years ago

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 commented 9 years ago

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