Github: Discoverability

[smashwilson]

I'd like to start a conversation about possible ways that we can improve discoverability of the git and GitHub features in Atom.

This is what we have in place presently:

(1) The welcome package includes buttons to open the Git and GitHub tabs, and a nudge referencing the status bar tile:

(2) The hints that cycle when no panes are open in the workspace center includes mentions of the keyboard shortcuts:

(3) The status bar tiles themselves are always visible:

(4) The package's initial state. The first time that Atom is opened with the GitHub package installed, if the Welcome package is not shown, the right dock is opened with the Git and GitHub tabs present. Each time a new project is initialized, the Git and GitHub tabs are opened in the right dock but the right dock itself is not expanded.

(5) The "Packages" menu includes a "GitHub" entry, with the keyboard shortcuts listed:

But our feeling is that these are not sufficient:

The GitHub tab is even more hidden: you have to know about the keyboard shortcut or the command palette entry to get to it.

Soon, thanks to @annthurium, we'll have access to metrics that we can use to validate this hypothesis, and measure the impact of any changes that we make to improve this 😁 Before we even have a baseline, though, I'd :heart: to start collecting ideas and brainstorming about different ideas we could explore.

The real trick is going to be threading a needle between letting users know that the package exists and how to get to it, without being obnoxious and annoying users who know about it but don't choose to use it.

/cc @annthurium
/cc @simurai
/cc @sguthals

[annthurium]

thanks for starting this conversation, @smashwilson !

The first step is knowing what our baseline usage numbers are, which will happen in the next release.

The next step would be to instrument all these entry points separately, so we can see where users are actually coming from.

Wacky idea: since this is essentially a growth problem, we could do an a/b experiment. For example, randomly but deterministically put UUIDs into 2 buckets in a way that's repeatable. That way we can try showing the GitHub package more aggressively, but have a control for "are we annoying our users too much." Might be more work than it's worth, just putting it out there as an idea.

it would also be GREAT to do some UXR around the discoverability of this feature. We should definitely do that.

I would include marketing / developer education here as well. For example, having a video on one of our educational channels to explain how to use the GitHub package would be a great first step. While it's harder to measure how much that kind of thing impacts your actual numbers (you can't exactly use a utm referrer, lol) it seems to be a piece of the puzzle that's currently missing.

...maybe I'm biased because I was an Atom user for years, and I didn't even know about the Git / GitHub integrations before I started working here.

[smashwilson]

Wacky idea: since this is essentially a growth problem, we could do an a/b experiment. For example, randomly but deterministically put UUIDs into 2 buckets in a way that's repeatable.

This would be really cool 😄

We could also likely use this as an excuse to introduce the infrastructure for feature flags while we're at it - the flag's default value would just be determined by your bucket rather than whatever other controls we want to have 🤔

it would also be GREAT to do some UXR around the discoverability of this feature. We should definitely do that.

👍 @sguthals was just talking with me about putting the wheels in motion here. I'd guess that discoverability would be one of the first results we'd get out of that.

[simurai]

Some more random ideas:

Status-bar

1. Change the status-bar tile from 2 files to Git (2).
   
2. Also have a GitHub status-bar tile.
   

Tool-bar

Since the status-bar could get crowded, have more a tool/nav bar:

• Bundle tool-bar or implement something similar.
• Implement the Persistent Controls for Docks proposal.

This is much bigger in scope also more Atom's responsibility. Atom IDE and other packages would also benefit.

Onboarding

@donokuda also mentioned that there could be some sort of "onboarding". For example an occasional "hey, you're using Git in your project but haven't used the Git tab yet... just a friendly reminder, in case you didn't know". But yeah, hard to find a balance between being useful vs annoying.

SEO

There is a documentation and a product page with videos, but for some reason, when searching on Google for something like how to commit in atom, both don't show up on the first results page. Your case might be different?

Some re-wording and cross-linking might help.

Marketing

Atom's release tweets already include the GitHub package, but there could still be the occasional promo tweet. Maybe packaged as "Pro tip", like "Forgot to commit something? You can amend by right-clicking on the last commit. + gif". Or retweet other people's tweets. On the other hand, we have been very light tweeters. Not sure if we want to change that.

Soon, thanks to @annthurium, we'll have access to metrics that we can use to validate this hypothesis, and measure the impact of any changes that we make to improve this

👍 Agreed to wait until we have some numbers first. A/B also sounds fancy.

[annthurium]

@simurai that is an excellent point about SEO.

I worked on SEO at Pinterest for awhile, so doing a SEO audit of our documentation is totally something I'd be happy to handle. Especially since a lot of SEO improvements end up improving accessibility too!

[annthurium]

Okay so, based on the user research we've been conducting, I feel good about the icon changes. Going to close this out for now, but we can open additional issues for discoverability improvements as things come up.