Packages - User Experience

#1

Packages Listing and Discoverability

Hello, I was wondering what were the plans considering packages listing and discoverability for Atom. Coming from Sublime with its PackageControl plugin and website, I found the discoverability a bit annoying on here.

I will list the advantages that I think PackageControl has compared to Atom’s way of listing packages, and maybe that will give you ideas.

PackageControl - Pros

  • List more packages per screen.
    It seems to me that, for Atom packages, too much information is shown to users on the index page, and each package takes too much space. I feel that only the name of the package and a short description should be necessary. Then, on the page of the package, more details could be shown.
    Right now, only ~6 packages can be viewed per screen. PackageControl can display around 10-11 per screen, and 15 packages + 10 labels on its landing page.
    Note: this is maybe more of an issue on my monitor (1080p, 23’).

  • Easily visible ‘Popular’ labels (aka. tags) to guide search quickly.
    Examples:

    • Snippets
    • Color scheme
    • auto-complete
    • text manipulation
    • formatting
    • Etc.

  • A ‘Popular’ category instead of a ‘Featured’.
    I think it is a better idea, because it…

    • lists the most useful packages according to users.
    • isn’t limited in number (currently for Atom, only 6 packages are featured).

  • Provides clear, separate labels for language syntaxes, color schemes, and interface themes.
    There’re exceptions, but most of the better packages followed unofficial guidelines to help differentiation.

Final note

I hope that these notes gave you ideas, or perhaps you already had them in mind, but I would like to know what you think.

Package Choosing
Advanced Packages/Themes Search
#2

It does support tags. They come from package.json, which apparently no one knew about. They are starting to catch on now as they are seen in the listing. I added them to my latest project.

#3

It’s already there, called “trending”.

#4

Not really, or I don’t think so.

In PackageControl, there are treading packages (recent, relative increase in installs), and Popular (from top most to lowest number of installs).

#5

Yes. My complaint is based on discoverability of tags. There are no list of populars tags at the top of the page. You have to check the tags applied on existing packages in the order of whichever list.

#6

I think this is a very valid point. Although the tools are in-place (keywords (or tags), etc.), they aren’t necessarily apparent at first. For example, in the search field you can type: keyword: awesome to search for packages with the tag “awesome”, but there there’s nothing that indicates to a user that this is even possible (you just have to figure it out).

Anyways, just my 2 cents :wink:

#7

Oh, you mean like this?

#8

As I’ve stated before, download count is a poor proxy for popularity.

#9

However download count is a great proxy for the compound effect of age, popularity and active development. :wink:

The fact that we can’t separate the causes is unfortunate but it does not make it less of an indicator for social proofing - the various mixed causes are all generally good things.

And separate from the absolute merit of download count as a metric, it’s probably the best available.

#10

I disagree, you’re still assuming that a download is necessarily a positive thing.

The fact that we can’t separate the causes means that we can’t use it effectively as a comparator.

  • Package X has 5,000 downloads – 5,000 people downloading it and using it every day
  • Package Y has 20,000 downloads – 20,000 people downloading it and uninstalling it

Oh, I understand that people will continue to insist on using it this way. Of course, that just means that nobody needs to spend any effort to find a better metric.

#11

yes. Any example of download being a negative thing ?

#12

Downloading a package and uninstalling it, as I stated in my previous message.

Also, I would assert that downloading a package twice, once for new features and a second time because there was a bug in the new features, is not better than downloading a package once for new features without bugs. (And many would consider worse.) Nor is it as good as downloading twice for new features without bugs.

As Jeff Atwood stated in his blog post Because Reading is Fundamental:

If I have learned anything from the Internet, it is this: be very, very careful when you put a number next to someone’s name. Because people will do whatever it takes to make that number go up.

So should we be incentivizing raw download counts? Or something else? Like quality packages that do useful things?

Sorting by stars is an option too. And since stars are a signifier of “liking” or “being interested” in something* … might be a closer approximation of “popularity”, depending on your definition.

* Or in the case of Atom, wanting an easy way to install a package.

#13

Github people know exactly how many users actively use each package. The analytics give them that info. So it would be easy to attach a number to a listing that is accurate and meaningful. Someone should post a request on Atom/Atom.

#14

No, they don’t. Here is the list of what is tracked by the metrics package:

Not all packages have commands or use commands for their primary functionality. My status-bar indicator packages are two examples of such packages, not even counting themes or language packages. Also, the metrics package can be disabled.

#15

That’s weird. I thought they listed number of active packages in their talk at codeconf.

#17

To my recollection, they listed a number of packages created for Atom, a number which is available to everyone on the main packages page:

Screen Shot 2015-11-21 at 12.52.54 PM.png1706×332 24.9 KB

#18

Then the feature request should include collecting that also. That would be really useful when searching packages. A ratio of usage to downloads would be particularly telling.

Also, I would really like to know if my package is being used or not. If not then I’d just kill it instead of taking the trouble to support it.