Plugin Library lo-fi sketch

[shannonbux]

Hey @KyleAMathews, @calcsam, and @fk (and others welcome as well!). Here's a lo-fi version of a possible plugin library. Thoughts? I'm concerned it's a bit crowded, and maybe too much like js.coach. Also included summary of the research for reference (so you know what pain points are and what Gatsby fans are experiencing w/ current plugin situation).

[KyleAMathews]

Looking good!

A few thoughts:

• It's totally fine to imitate design from another site/app. That's all I ever do :-)
• https://about.sourcegraph.com I believe has an API for searching for GitHub projects that depend on something. So for each plugin we could surface that information. GitHub might have added an API for this as well.
• It'd be great to highlight plugins which have official example sites
• Also starters
• It'd be cool too to list which gatsby APIs each plugin uses though I'm not sure this is useful for the plugin browser.

[shannonbux]

Thanks @KyleAMathews and would the sourcegraph thing be a way to search for / pull in all gatsby-related projects into the library? That would be cool. Any way we can streamline/automate this library would be awesome. P.S. What would be the goal of listing which gatsby APIs each plugin uses (i.e. would that be useful for Gatsby developers/contributors?)

[shannonbux]

AND @rdela looping you in here too. Would love to hear your thoughts on this potential plugin library design!

[KyleAMathews]

What would be the goal of listing which gatsby APIs each plugin uses (i.e. would that be useful for Gatsby developers/contributors?)

Yeah exactly. If you're trying to figure out how to build something, a useful pattern is to find other plugins that are similar and copy them.

[rdela]

Love it! Looked at Sourcegraph on my phone, Think we can get all we need straight from GH?

Last month, we made it easier for you to keep track of the projects your code depends on with the dependency graph, currently supported in Javascript and Ruby. Today, for the over 75 percent of GitHub projects that have dependencies, we’re helping you do more than see those important projects. With your dependency graph enabled, we’ll now notify you when we detect a vulnerability in one of your dependencies and suggest known fixes from the GitHub community.

https://github.com/blog/2470-introducing-security-alerts-on-github

Security notifications great thing to surface in index as well.

Are we ready to prototype?

@Redmega @hmeissner @rafacm @mlukaszczyk @flexzuu any of you have thoughts on comments so far or ideas on best approach to get something working to begin iterating on?

I was reading about Wade may be of interest for fast local offline search possibilities. @KyleAMathews did you have ideas on search implementation?

[KyleAMathews]

I already signed up for access for Algolia's search index of NPM https://blog.algolia.com/yarn-search-javascript-packages/

That should work really well for us.

[KyleAMathews]

Most security alerts wouldn't apply to Gatsby I'd guess since it's a dev/build tool and you generally don't build from unknown code/data.

[rdela]

Well we may have to wait for dependency graph and security notifications to get added into public API, I scanned quickly and did not see anything dependency or security related in the GH dev docs yet. So we may need to use Sourcegraph and Node Security Project or similar if we want those features right away.

[rdela]

Algolia NPM search looks amazing, there is an open issue for security alerts so I could add there or wait for someone else to either way, and later on if people do end up publishing enough client running code to warrant inclusion Shannon could do real tests with live side by side to see if or how people want it.

Seems we could get most everything we need from one source with them, including dependencies, wow.

Here are all our sources:

• npm registry, example for express: http://registry.npmjs.org/express
• npm download counts: the npm downloads endpoint
• Packages’ dependents: the dependents endpoint of npm (there’s no official documentation on that)
• Changelogs: a clever first resolved, first served list of calls to various ChAnGeloG files, like History.md’s express changelog
• GitHub Stargazers⭐️, commit activity: we get them on the frontend directly from GitHub using the browser of the person doing a search. This way we benefit from a larger rate limit on GitHub shared amongst all users. This is also what npm search does for opened issues on their detail pages.
• Browse view: we get this from the unpkg API, which gives us the files, folders and sizes for all published packages

[…]

Building on that we want to add new features like:

• Bundle size information like siddharthkp/bundlesize
• Advanced filtering with tags
• Anything YOU would like to see, let us know

Yarn: From Zero to 700,000 User Searches per Month - Milliseconds Matter

So is this something we are ready to start using? Or we are waiting for green light from Algolia?

[KyleAMathews]

We've already got a token so we just have to help Shannon finish the design then someone can start building.

[rdela]

Unreal, that is great news about the token. Shannon have you thought about how we should approach the mobile interface?

[shannonbux]

Ricky, that is a great question--I assumed people wouldn't be searching for plugins via mobile, but I could be wrong! I didn't even ask about that in interviews (classic greenie mistake). Do you think ppl will be searching via mobile a lot? If so, for a mobile interface I'd probably use the middle section of the desktop version as the main dashboard, and then the filters could be a screen that pops up and disappears when you need it to. And then when you click on a particular plugin, the list of plugins would disappear and you'd see an individual plugin's details page.

[rdela]

Occurred to me when I followed js.coach link on my phone. Phone interface there seems shrunken down, like it is zoomed out to me, and touch targets feel small.

I was imagining more or less what Shannon articulated more clearly than I could have. I think what she suggests would work much better and give our interface more breathing room on small screens.

How should we start turning these into browse-able prototypes?

[shannonbux]

Awesome! I can probably get most of the desktop version done by next Wednesday afternoon and have a clickable prototype, and then I will definitely need more feedback on functionality and look and feel. I'm thinking it would be best to get that done and then address mobile after that? @KyleAMathews thoughts on doing mobile first or desktop first?

[rdela]

Also maybe we rename https://github.com/gatsbyjs/gatsby/projects/1 Road to 2.0? …and merge these todos? Or start 2nd one so when other issues come in we can coordinate them with roadmap there?

[KyleAMathews]

Previous issue on this #56

[dardub]

What will the test story be like for community plugins? Can / do we need to display version compatibility?

[KyleAMathews]

What do you mean by "test story"?

[dardub]

@KyleAMathews I mean, what is the process like to verify a community plugin does not break with new gatsby releases?

[KyleAMathews]

Ultimately the responsibility is on the plugin maintainer.

One thing we can do to help out is once I finish the new example site testing tools is that community plugin maintainers can add example sites for their plugins so that the plugin will be tested on every PR to core.

[dardub]

Ya, I think it would be nice if we could show the last gatsby version the plugin passes for. Just thinking about wordpress ecosystem and how frustrating it can be downloading plugins that don't work anymore.

[KyleAMathews]

Yeah totally — perhaps what we could do is highlight plugins which have an example site and say something to the effect that "this plugin is tested against the latest Gatsby" or whatever. I agree that anything we can do to vet plugins will make the ecosystem much more robust and ease a lot of friction around trying/using plugins.

[shannonbux]

Like these ideas. I'm creating a clickable prototype by the end of today. @KyleAMathews, I read the previous issue about starters. Do ya'll think it makes sense to search for starters sort of within the same library?
Also, I am looking at a couple other examples of plugin websites that are cool. Microsoft's Visual Code Studio extension library and Sketch Plugin Library. What do you all think of the more visual nature of the plugins (i.e. they all have some sort of icon or something?). If we did include starters with the plugin library, I think the visual emphasis might be awesome.

[dardub]

I like the basic approach of Visual Studio site since it highlights featured and popular plugins but still put's the search at the forefront compared to Sketch where I don't even see a search available.

Edit: What I don't like about VS is that to browse more information about a plugin you have to navigate back and forth between the details page and search results. Which is not a problem with Shannon's wireframe.

[Redmega]

@dardub Sketch needs you to click on "See all" to get the search. Definitely not optimal.

[KyleAMathews]

@shannonbux we can't rely on icons as almost no plugins will have icons. I do like the emphasis on search (though search should start as soon as the user starts typing).

We do want a faceted search however so it's easy to filter/browse by narrowing down scope.

Including starters does make a lot of sense now that you mention it. We're basically creating a marketplace so why not put all addons to Gatsby in one place. One stop shopping :-D

On that note, looking at big software marketplaces would also be a good source for inspiration e.g. Android, iOS, the Mac app store, etc.

[shannonbux]

Great ideas. Also, can you all help me out with some use cases for mobile? I assume most developers aren't trying to install plugins via mobile devices, so what do we need mobile for? Just browsing, sharing URLs w/ people, following updates?

[shannonbux]

Ok everyone. Here's a very basic prototype. The tasks you should try to accomplish here are 1) Try to see more details on the "gatsby-image" plugin. 2) Filter to see only CMS plugins. 3) Then try to get back to the first page you see. I need lots of feedback! https://marvelapp.com/766i07a

[Redmega]

In the "Stuff about the plugin" section, can't we just show the plugins' README.md? Would require less work as it would be up to the plugin authors to keep it up to date.

[shannonbux]

Ok everyone. I've got an updated prototype that is missing some things still. I know it's not perfect (I think everything is too big on it right now). Right now I need feedback on 3 things:

1. When you select a plugin, is it clear that it's selected?
2. When you select a plugin, is it clear that the information on the right side of the screen is related to the plugin that you selected?
3. What seems to be the most important thing on the page? In other words, where do your eyes get drawn to? Do you think something else should be most important?

OK, here's the prototype link: https://marvelapp.com/2f83767

[shannonbux]

After you've clicked thru the prototype in my comment above this one, here are also a few alternative ways of making it clear that a plugin is selected. Lmk if you like one of these better than what's in the prototype:

[dardub]

I like the changes Shannon!

1. Yes
2. A little, some type of small animation could help show content is changing
3. My eyes are drawn to the list of plugins, search bar is more important

The third proposal is interesting, I like that the title is purple to match the selected plugin. It ties the two together.

[shannonbux]

ok, new prototype that matches GatsbyJS.org's existing style much better! Would love feedback on "filters" and "sort by" and whether the options that appear in those drop-down menus make sense. https://marvelapp.com/3388h43

P.S. I don't know how to use layered images in Marvel, so just a fair warning: my "filters" and "sort by" drop down menus are acting weird and I'm troubleshooting that right now.

[rdela]

So these are my comments on last one

When you select a plugin, is it clear that it's selected?

totally, more so in first one I think

When you select a plugin, is it clear that the information on the right side of the screen is related to the plugin that you selected?

yes, more so in first one I think

What seems to be the most important thing on the page? In other words, where do your eyes get drawn to? Do you think something else should be most important?

pre-selection: Gatsby logo/Welcome!
post-selection: Plugin title

I made this last night, kind of a fusion of Gatsby site and early prototypes, have 2x version as well. This was before you added updated version, which I like the look of filter and sort menus and animating down effect despite Marvel weirdness! I used these two icons from Noun Project
Sort by Landan Lloyd https://thenounproject.com/search/?q=sort&i=1300795
Checkbox by Curve, FR https://thenounproject.com/parmentiers.joseph/collection/check-checkbox-approved/?oq=checkbox&cidx=2&i=535238

[shannonbux]

Nice @rdela , I like the filter and sort icons! And the simplified area above the plugins on the left. What did you build it with? Sketch? I can share files of that if you want to not have to build stuff from scratch

[rdela]

@shannonbux That is Photoshop but want an excuse to work more with Sketch and to explore https://github.com/airbnb/react-sketchapp – bring em on! email me?

[Haroenv]

Oh a small note, there should be a “search by Algolia” somewhere in the UI because it’s a community project, thanks

[rdela]

Like the way Yarn does this (below results pager, above footer): https://yarnpkg.com/en/packages?q=gatsby-plugin&p=1

Search by Algolia - read how it works.

Thanks @Haroenv

[rdela]

About to send the Sketch file back to Shannon, but thought I would share these PNG exports of my attempt to incorporate last round of thoughts.

In addition to the Noun Project icons mentioned above, this design I am calling “Purple Fusion” has a little icon on the landing page I made with EmojiOne notebook with decorative cover version 2.2, which is what I had installed, it has since changed colors in version 3+.

Landing Page

(Library) Home – UPDATED: fixed off-center logo + Welcome text 📝

First Selection

Second Selection

Third Selection

Fourth Selection

[rdela]

Safe to assume differences in text styles (purple/no border-bottom links, no background highlight on code etc.) are not changes I am proposing to current styles but things that I deemed unimportant to review and/or were too difficult or time-consuming for me to reproduce easily in Sketch.

[shannonbux]

I like the illustration! It's fun to feel like there is some personality here. One thing I've noticed is that almost every UX designer wants a visually appealing landing page and a less cluttered search tool, and almost every developer I've gotten feedback from doesn't mention those things and mostly just wants the relevant data about plugins to be easily discoverable. So, all of this is just saying that I like the landing page and it will take some real-life testing to see if it helps or hinders developers using the tool. And very understandable about fonts. We can just refer to standard Gatsby fonts for consistency. If you send me this file, I'd be happy to turn it into a prototype for one last round of feedback. My goal is to get this ready for coding by mid-January.

…

On Thu, Dec 28, 2017 at 7:51 PM, Ricky de Laveaga ***@***.***> wrote: Safe to assume differences in text styles (purple/no border-bottom links, no background highlight on code etc.) are not changes I am proposing to current styles but things that I deemed unimportant to review and/or were too difficult or time-consuming for me to reproduce easily in Sketch. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3003 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ae9o2qWQ4vwY2NaRU49I5-LXUbPr0gi1ks5tFFO4gaJpZM4QoFZw> .

[shannonbux]

Hey all! Here is a checklist for this issue to show how far we are in the UX process (artifacts from all finished items are found earlier in this issue). Please feel free to contribute by either moving down the checklist or suggesting changes to the checklist!

• Do a comparable product analysis (sort of SWOT, even though they are not competitors)
• Creative brief
• empathy map based on user interviews
• jobs to be done
• 10x10 sketches, get feedback, 10x10 sketches, get feedback
• Lo-fi prototype, get feedback
• Mid-fi prototype, get feedback
• Confirm that the solid purple selected state view is best (what do profile cards look like when selected vs. unselected?)
• Create grid system template
• Align everything with template
• Decide which data about each plugin we want to display on each profile card vs. page
• Design hover states for data and the process for producing the stats
• Get feedback on a new prototype
• Implement feedback
• Give it to developers to code
• Reach out to all plugin creators to encourage them to finish ReadME files
• Finish and post blog post announcing the plugin search tool (Shannon has primary responsibility of this one)

[arafalov]

I am a bit late to the party, but if the Algolia-based search does not work out, I would be happy to assist with Apache Solr version. It has to be hosted somewhere, obviously and is not - without some security hardening - exposable to the network directly (similar to say postgress...).

But I would be happy to teach anybody involved in this project Solr concepts and help doing the field and search mapping.

[Haroenv]

Hey @arafalov, feel free to contribute to the search service itself with Algolia at https://github.com/algolia/npm-search, or let me know if anything is missing 👍