Repository navigation
Start-up Behavior #872
Description
The problem
There are three competing factors we need to balance in our start-up behavior:
- Discoverability. Users who launch the next stable version of Atom should be presented with a clear reminder that this package exists. They shouldn't need to hunt around online to discover how to access it.
- Screen real estate. Especially for users who are downloading Atom for the first time and being presented with the Welcome panes, screen real estate is at a premium. Launching with the right dock expanded and the tree-view open by default squashes the Welcome panes and is visually overwhelming:
- Likelihood of use. When first launching Atom, users are more likely to need to interact with the tree-view right away to explore the current project than they are to perform a git operation. In the general case, they're likely to close the panel right away most of the time.
Our current behavior, introduced in #685, is to activate the git and GitHub tabs on the first run of any project. That achieves (1) but I think we all agree is a bit aggressive for (2) and (3).
Use cases
I believe we have two categories of users to consider:
- Existing Atom users who are upgraded to 1.18.0.
- Users downloading Atom 1.18.0 as their first Atom version.
We can probe atom.config.get('welcome.showOnStartup') as a proxy for detecting this.
Proposed solution
Here's what I'd like to implement:
If the Welcome panes are active default the git and GitHub tabs to off to account for (2). Record that the first launch has occurred in the package config. Rely on the Welcome guide section proposed below to account for (1).
If the Welcome panes are not active and auto-launch hasn't happened yet in this Atom install, default the tabs to "on" to aid (1), then record that the first launch has occurred.
If the Welcome panes are not active and auto-launch has already happened in this Atom install, default the tabs to "off" to account for (3).
🗒️ Note that this behavior only applies if deserialized project state is not present. If there is project state, the git and GitHub tabs will continue to respect their last serialized state.
🗒️ Detecting whether or not auto-launch has already happened requires a place to store project-independent, global state that's "owned" by the package. I've opened atom/settings-view#954 to address this. To accomplish this, I'm using a flag file in the Atom config directory.
Alternatives
A much simpler approach would be to introduce an explicit github.showOnLaunch setting to control whether or not the panels are displayed. This has the added advantage of consistency with the way the Welcome guide works. The downside is that it isn't as obvious as it is the Welcome guide - the Welcome panes include a checkbox to disable the setting directly in line, while users would need to hunt for ours. Also, I have a few questions with this:
- Do we default to "true" for (1)? If so, what do we do about (2)? First impressions are valuable.
- How do we interact with saved project state? Do we replace it entirely with the explicit option? Or do we only respect
showOnLaunchwhen no state is present? - Can we do both - use the behavior proposed above if
showOnLaunchisundefined, but respect it as always-true or always-false if explicitly set? Maybe we can makeshowOnLaunchan enum setting with three values: "always", "never", "only once"?
Other discoverability aids
We can aid package discoverability and user learning in a few other places within Atom:
- Add a section to the Welcome guide to introduce and display the git and GitHub tabs: "Version control with Git and GitHub" section welcome#62
- Add git and GitHub-relased tips to the background tips package: Include tips for the Git and GitHub package background-tips#30
/cc @kuychaco @BinaryMuse @simurai @nathansobo @lee-dohm @damieng for comments, feels, and feedback.
Activity
damieng commentedon May 25, 2017
One thing to bear in mind is that the very first launch there won't be a current project so problem 3 might not be as bad as you think. (Getting to it is covered by the first block in the welcome - open a project)
smashwilson commentedon May 25, 2017
Oh, is the tree-view hidden on first launch? What if the first launch is from the command-line with a project path?
damieng commentedon May 25, 2017
simurai commentedon May 27, 2017
Saw this tweet the other day and yeah, having the Git panel open makes things pretty crowded.
But I think your proposal should never show Welcome and Git panel at the same time, so it should be fine. 👍
Some more random thoughts:
1000x600or even more. I assume if your screen is smaller, it will just open at max width.smashwilson commentedon May 30, 2017
Huh, it certainly looks like it is.
I'm 👎 on putting a welcome state into the GitHub package itself... it feels too redundant with the actual Welcome pane to me. I prefer to present users with a single, as-unoverwhelming-as-possible, guided introduction to the things that they can do. The more we need to split user attention on that crucial first launch the less effective each will be.
The general "create repository" and "initialize repository" views could definitely stand to be more inviting, though. 🤔
Random associated thought: maybe we could add some controls to the tree view when no projects are present, some of which could relate to git operations? "Open existing project," "create new project," "clone project from a git repository."
Oh, I like this. I know @BinaryMuse has Thoughts ™️ on an overhaul for Atom's notifications system. Maybe this could be a part of that?
smashwilson commentedon May 30, 2017
Addressed by #875, atom/welcome#62, and atom/background-tips#30.