[dev team] Proposed Sidebar Replacement for Windows

[bgannin]

@jerone vw It's not about remote services per se (although yes, we can easily see the network stress on Bitbucket Cloud)… it's also about BTF networks with complex requirements. Yes, we've had extensive dialogues with folks who had to abandon Sourcetree until we alleviated this specific problem.

I would ask that rather than start from a place of criticality you give us the benefit of the doubt about these things and that we are making balanced and well reasoned choices.

[jerone vw]

@bganninHave you been contacted by those "various environments"? For example, did Microsoft (VSTS) or Github contact you about the refresh-interval being to often and stressing their servers? Because how would you know that you are exceeding the network and server loads?

[dave_at_clearbox]

@bgannin Completely understand. The "real time" comment was more about whether the user had to somehow "refresh the page" to get an updated status for all repositories in the list as opposed to the status of repositories in the list updating by itself in the background. Additionally, the ability to manually request a refresh of the status of a repository would be useful.

[bgannin]

@jens @David Clark There are performance considerations when it comes to "updating in real time" as we've alluded to in responses. This will necessitate a 'refresh interval' of some kind (as there was in 1.x) that allows us to respect network and server load for various environments. Just wanted to make sure expectations and limitations are clear.

[bgannin]

We don't have any plans for open-sourcing any versions of Sourcetree. Let's nip this topic in the bud please.

[Ashley Wilson]

+1 for the open sourcing idea!

[Michael]

If the only suggested change is tear-off tabs and not to include the side-bar that made SourceTree source tree then I'll admit this is extremely disappointing.  I've been using version 1.x ever since 2.0 came out because it was severely lacking in managing multiple repos and had no visibility at all into the work being done by myself and others.

I'll keep an eye on this in hopes that this will change, I myself have seen these "performance" issues as unfounded since 1.x, most development machines (or my laptop I guess in my case) can handle it just fine.  Maybe in 3.0. :(

Just to post another potential solution...what if the latest 1.x version was open-sourced?  Let the community use what they like and improve it from there.

[Jared Thirsk]

These represent some of my as yet unsaid fears as well.

Wireframes and/or clarification would help me too. I am trying to understand this "New" tab and am not sure I understand what is going on or why, or what differentiates it from a side bar (that could be a detachable/collapsible/closable pane). FWIW, this is what's going through my confused head, whether I have the facts right nor not, using Visual Studio as a reference point:

1. Take the 'Solution Explorer' pane, which you could say is the "New document pane" of Visual Studio, and rename it to "New". Ok, this would be confusing to me, but I don't really care what it is called.
2. Give the Solution Explorer the ability to tear it off into a separate window. Fine -- this exists already and I actually already use this in my multi-monitor setup in VS. Working with multiple windows can be a bit of a pain (I frequently have to rearrange it), but for me it's worth it, even though I suspect for most users it is not.   The Solutions Explorer pane can also be docked in the center as a full screen "new tab" though I have never seen it used this way.
3. Eliminate the ability to make Solution Explorer a dockable pane -- it must be a document tab that either takes the full window, or a torn off window. This seems like a needless restriction that would make Solution Explorer unwieldy and inconvenient for most VS users with no upside.   Likewise, forcing the side bar of Sourcetree 1.* to be its own window would serve no purpose.  It would need I need to position two windows instead of one -- all pain, no gain to force this restriction on users.
4. I can't tell if you are trying to get rid of the tree capability (and replace it with some kind of sort) and I haven't used whatever new tab is in 2.* long enough to know what's going on there. If so, this would be like replacing the Solution Explorer tree with a flat list, making it impossible to organize, and have a predictable visual representation of where to look for things. Sure, on average there are more files than repos so the analogy is often different, but some people have 100 repos and need to be able to organize them in order to have a mental handle on things.  If I reinstall Sourcetree on a new computer, I may want to be able to look at it and know that I have successfully added all repos I want to Sourcetree.

I don't need to always have a repo open, but I may always want to start with an organized overview of my repos (a toggle to filter it to ones with pending changes or pulls could be a nice UX addon). So here are requests for the "New tab":

• Make the "new tab" dockable to the side of the window, since having two windows when only one is required seems like clumsy UX. This would bring us full circle to side pane -- which for reasons that have yet to be made clear by Atlassian is something that you find unsavory. Can you help me understand more?

I am glad Atlassian brought up the Visual Studio example, because it gives users full power in choosing how to dock both document panes and other panes. Options include: Pinned and unpinned (auto-collapse) "sidebar" panes, full screen (tabbed) document, torn off document. I don't see how this wouldn't make everybody happy if the 'new tab'/ repo tree view pane was like this.  Sure, the Windows 10 control panel looks sparse and spartan, but you don't see the Visual Studio team going with this trend for the sake of it, since they recognize their users are driven by power and productivity.  They can ride the trends a little more on their Start Page, which is more of a superfluous bonus before the user has chosen to do anything, but not at the expense of any of the really important features like the Solution Explorer (their "master view".)

[Ashley Wilson]

This sounds like a less useful replacement for the source tree, you know, the one the app is named after? Unless the window can be split vertically into tabs so that the "new" tab can be essentially become a sidebar, it's not usable as a "dashboard", to keep an eye on without having to switch to it. At that point though, if all this gymnastics is being done to essentially bring back the sidebar, why not just have a sidebar?

Some people like multi-window apps, like Gimp can be. I'm not one of those people. It's quite common in IDEs to have multiple panels/toolbars/sidebars, so the developers who use SourceTree would be quite familiar/used to the concept. We also have large monitors so that there isn't an issue with the screen real-estate, or even with performance because dev-spec machines are powerful enough to run multiple VMs and what not. If there exists a performance issue with displaying things at once, that's an issue with optimisation - the solution is not to remove useful things, it's to fix performance bugs or tweak the display logic.

[Deleted user]

I agree

[Anders Viden]

Thank you for this opportunity to give our feedback.

As most comments above point out, the 'at a glace' feature is the most critical. A rough sketch or mockup of how the new tab would address that would be very helpful in telling if it's a sufficient replacement of the old tree view.

Another concern of mine is about your comment "committed to delivering a modern, ... UX". Unfortunately, 'Modern' seems to mean a sparse layout, as in the current new tab of version 2.x. This might be good for tablets and finger navigation, but in a traditional desktop environment, sparse means more scrolling and scrolling makes it hard to get that instant overview we all seem to miss.

As Jon Espen Carlsen mentions above as the top positive of the old sidebar: "At a glance overview on a very limited screen-estate."

Your initiative to address our concerns gives me hope, but I will not delete the last 1.x installer just yet.

[Ashley Wilson]

Yes, I agree, a visual would help us users a lot in giving useful feedback.

[jens]

@David Clark the "New" tab will be updated in real time to reflect changes. 

[dave_at_clearbox]

Is the torn off "New" tab updated in real time? That is, as developers make updates to repositories, is the floating "New" tab updated to reflect those changes? Or do we have to open and tear off a new "New" tab each time to see if repositories have been updated. Does the "New" tab reflect hierarchy of repositories? Folders? Anything that is currently available in the 1.* repository panel?

[dave_at_clearbox]

Yep that would be handy.

[jerone vw]

Can you post some wireframes how this will work, because me and others are still confused how this will fix "see the status of all my repositories in one place"-issue.

[bgannin]

Please see Scott Goddard's summary… you don't need to open a ton of tabs, just the "New" tab, torn off into its own window, and sort by "Most Recently Updated" to have roughly the same experience for all local repos.

[bgannin]

This is an accurate (and excellent) summary 👍

Ideally we'll remember your tabbed layout (as we do the open repo tabs) and restore on each launch. Docking as an explicit act isn't in the cards most likely, but you'll be able to achieve the effect.

[codenesium]

Thank you for looking at this issue!

I agree with the other posters.

"'Can I see the status of all my repositories in one place?' ... If these changes do not address that, they are a non-starter."

I want to see there are pending changes at a minimum. I want to be able to quickly look at all of my repositories (30+) and see that I have changes in 3,7 and 30. Then I want to click a repo and have it open in a tab to the pending changes or the history I don't care. 

I'm not understanding the tear off tabs. Why is that different than the tabs we have now? The problem with the tabs now is there is only one row and they hide long repo names.

Can you describe in more detail what the main performance problem is? I assume it's querying git to detect changes. Maybe we can help come up with a solution. Jared has lots of good suggestions. 

I'd hate for you to do work that doesn't accomplish what we've been complaining about. We do appreciate your work. More mockups and dialog would be good so we can clarify your suggested fix. 

[Jon Espen Carlsen]

Atlassian Team, again thank you for reaching out and that you're taking your time to have this dialogue with us.

I do agree with David, Jared and Scott on some of the concerns above here.

I'll try to be quick to the point in the intro here, I may later add a bit more to shed light on how and why we choose to use SourceTree 1.x with Treeview sidebar.

You're failing to reach the goal:

1. Overview at a glance.

Let me add: "Overview at a glance at a later point in time".

Tabs & Toasts gives us 'notification & insight' at the 'Now' point in time.

# Positive attributes with the 1.x sidebar:
- At a glance overview on a very limited screen-estate.
- Didn't require us to 'keep tabs open' to track what personal workload we have to wrap up later.
- Facilitated overview at a glance at a later point in time
- Tracking 'what do I have available at my disposal' to consume.

I can tell you about what kind of audience, workflow and more later if you are interested. But this is not projects or programming teams.

Think of them as 'IT datacenter operational staff, support staff' which consumes a lot of content directly. As many as 100+ in our organization, while 20% of these also contributes to changes.

Changes may be 70-80% customer environment & platform configuration, while 20-30% may be modules for PowerShell.

---------

# A bit of reflection on the Tab vs change-awareness.
Tabs may be compared with 'documents'
- You may have changes in a tab/document.
- You may have to work on 10-20 at a time-period (day, week or more).
- It doesn't mean your work is finished even if the Tab (document) is NO longer open.

More work is required to finalize documentation for the Repo, CMDB updates and internal articles.

Again the old side-bar facilitated us tracking these changes at a later point in time.

--------

# Positive attributes with Sourcetree for our organization
- No programming experience is needed to consume what's published and made available with Bitbucket & Sourcetree.
- Allows us onboarding new staff and introduce them to our version control & processes easily with a easy to understand GUI.
These are key decision factors for IT-operational staff on what tooling we chose.

[scottgoddard]

Thank you, Atlassian Team, for finally taking this issue seriously.

<quote>Before getting into what we're leaning towards I'll touch on a few of the concepts we discussed and why they didn't survive to the final round.

1. bring back a revised version of the sidebar
   
2. add push/pull toast notifications with an improved "New" tab experience
3. create an expanding tab bar similar to the one found in Edge, potentially combined with the "set aside" overlay

Ultimately each of these failed to deliver on our goals in one way or another.</quote>

<quote>

• sorting options in "New" tab - by name (current), modified, recently updated
  • addresses at-a-glance access to recent changes across all local repos

</quote>

The way I read it is:

• The 'Sidebar' is STILL dead.
• The 'New' tab, which has some features of the sidebar, will be improved and will hopefully become an "at a glance" status view of all repositories.
• Tear-off tabs will allow this 'New' tab (or Treeview, as I shall think of it!) to be placed outside the main window and resized to allow it to display at the same time as the main window.

If this tear off tab's open status, position and size is persistent, then that will probably meet my (and probably quite a few others) needs. However, if I have to set it up again each time I open SourceTree, this would be 'sub-optimal' to say the least.

Ideally, I would like to be able to dock this window as a bar onto the side of the main window, but I don't know what you would call such side docked bar?

[Jared Thirsk]

Atlassian, thank you for engaging your users and putting thought into the most reasonable way forward.

I share David's sentiment: "'Can I see the status of all my repositories in one place?' ... If these changes do not address that, they are a non-starter."

Regarding the side bar, what are your concerns with it?  Is it performance?  If so, are there ways to allow users to eliminate any unwanted burdens on system resources?  I am not sure I understand the bottlenecks or how it all works under the hood, but how about these:

1. Users can collapse (unpin) a side bar, or close it, and later reopen it, similar to how users can do the same to the Solution Explorer in Visual Studio.
2. Polling interval can be set in settings.  Or it could be auto-adjusted by the application to target a certain system load, or a certain total elapsed time for a full poll.
3. Polling can be entirely disabled in settings.  There could be an indicator "last updated 30 minutes ago" with a refresh button inline or in a toolbar.  Visual Studio has refresh buttons in both Solution Explorer and Team Explorer.
4. Polling could be disabled for collapsed folders.  Users could be given a tip to "move repos to folders and collapse them while not in use to avoid scanning them"
5. Instead of the git status counters of additions/deletions/untracked/etc., or commits ahead/behind, a lot of users may simply care about 'I have changes I didn't push to the server, so if my computer dies now I may lose that work forever'.  Other users may want to be alerted "my coworker pushed something new -- I don't want to work on an outdated codebase so I had better pull the new code ASAP."  So allow users to enable/disable additional options for these simplified use cases: "uncommitted files tracking: presence of any uncommitted files, or full counters", "unpushed changes: presence of any unpushed files (committed or not), or number of commits", "pull available tracking: on/off (perhaps per repository)"  Once a repo is marked as 'has unpushed local changes', there is no need (not practically, for 99% scenarios) to fully rescan it until there is another commit.  Once a repo is marked as 'there are new changes from the server', there is no need to check the server until a user does a fetch.
6. Use file system watchers to avoid polling the disk if there is no disk activity under that tree.  If there is, debounce.
7. Don't update the panel while the window is a) minimized, or while it is b) not focused.

[stijn]

Is it possible you (or I) misunderstand what is going to get implemented? From the description (layout similar to VS, "separate out any repo tab into its own window, or the "New" tab with its bookmarks list") and screenshot it seems the tree can always be visible and repositories can be shown next to it or can be undocked. So that would actually be adressing the primary concern? And would be pretty neat overall.

(also lol @ the VS screenshot using the default toolbar of which I bet > 90% of buttons have never been used)

[dave_at_clearbox]

The key consideration was "Can I see the status of all my repositories in one place?". This was offered in SourceTree 1.* and is not available in SourceTree 2.*. This is the key source of complaint and indeed was the "source tree" in SourceTree.

If these changes do not address that, they are a non-starter. Displaying this information under the "new" tab option is pointless - if I already have the repository open in a tab, I don't need or want to open it again. Nor do I want to have to cycle through my 50 open tabs to determine which ones have been updated. Additionally, the fact the status can be displayed in the "New" tab indicates the status information of which repositories have been updated is already available somewhere in the system, but hidden under the "New" tab. Why not just display it in a panel that can be displayed permanently at a User's discretion?

Once I can see the status of all my repositories we can move on to things like "Can I determine what repository I'm actually looking at?" which cannot be done at the moment because the tabs are too small when lots are open and then thirdly "Can I tell which tab to select to display a repository?" which I currently cannot do for the same reason.

It seems the suggested changes address the secondary concerns, but fail to address the primary concern.