[dev team] Proposed Sidebar Replacement for Windows

[bgannin]

Hi everybody,

Let me start by once again reiterating our intent to improve Sourcetree by listening to your feedback. One of the top issues for Windows, SRCTREEWIN-7176, focuses on the removal of the bookmarks sidebar/treeview. Jens Schumacher, our Head of Product, summed up your well articulated frustrations with the current implementation:

• difficult to get the status of repositories at a glance

• lack of current context (disambiguating similar repos)
  
• hard to quickly locate repositories, especially when organization matters 
  

Starting from these functional requirements we set out to explore what pattern(s) might work best. We put all the options on the table and evaluated the pros and cons of each. 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. Some came with renewed performance concerns, others had a lack of information density and/or persistent visibility, and many lacked cohesion with either Windows, Atlassian, or Sourcetree for Mac.

In the end we settled on the following set of changes to offer the best balance for all our users:

 

• tear-off tabs - separate out any repo tab into its own window, or the "New" tab with its bookmarks list, similar to Visual Studio (pictured above)
  • addresses side by side, always visible needs for particular repositories and all local repos
• reactive layout for the "New" tab to adjust to all sizes
  • addresses visibility of content
• push/pull options in contextual menu for items in the local repos list
  • addresses ability to keep repos up to date without opening them in a tab
• richer tooltips for tabs to show the bookmark name and path
  • addresses ability to determine which tab is which
• better highlight bookmark naming and automatically resolve the same name as "Repo", "Repo_2", "Repo_3", etc.
  • addresses ability to determine which tab is which
• sorting options in "New" tab - by name (current), modified, recently updated
  • addresses at-a-glance access to recent changes across all local repos

As you might suspect this is a non-trivial amount of work to accomplish. It also requires revisiting certain fundamental assumptions in the Sourcetree for Windows architecture, especially around focus and state, and we want to make sure we get that right. The quality bar for this experience is high and we're committed to delivering a modern, flexible UX you'll be happy to use every day.

We've put this feature on the roadmap for later this year after we wrap up the current projects in flight. As we ramp up work on this we'll be sure to share more information. This isn't set in stone though - post your constructive feedback about our proposed direction in this discussion. We're listening and we'll keep the conversation going! (please keep it positive and encouraging) 

Thank you for your enthusiasm, input, and patience.

Brian Ganninger
Product Manager, Sourcetree 

Update: check out this comment for a visual preview and clarifications

[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.

[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)

[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?

[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.

[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?

[jens]

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

[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.

[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.

[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?

[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.

[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.

[Deleted user]

I agree

[Terry Holmes]

This is exactly what I would like to see Jared! Especially points 2,3 & 4.
If this is re-instated/implemented, I will move from v1.5.2 (indications are that the performance improvements are worth it).

[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.

[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. 

[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.

[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.

[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".)

[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.

[dave_at_clearbox]

Yep that would be handy.

[Ashley Wilson]

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

[bgannin]

We're working on these currently.

[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.

[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.

[Ashley Wilson]

+1 for the open sourcing idea!

[bgannin]

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

[Filip Jirsák]

From the SourceTree 1.x I miss the most the tree arrangement of repositories. Flat folder structure is insufficient for me. For example I want folder for opensource projects and subfolders in it for projects where I am maintainer, another subfolder for Spring projects, another folder for other opensource projects etc. I have many repositories cloned and it's a problem for me to find something in a flat structure of folders.

[Jared Thirsk]

+1

[josefsabl]

Exactly 

[Deleted user]

+1

[rconix]

+1

[Michael]

+1

[Terry Holmes]

+1

[iPMz’ Nliz]

Wow amazing great job

[bgannin]

Greetings everybody,

Thank you for your feedback and comments, we're reading each and every one of them and discussing amongst the team. I'm back today to share a more visual update about the tearable tabs proposal and to hopefully clarify any questions that have come up so far.

• behavioral model matches Visual Studio's but without the ability to dock a window as a sidebar/palette in another window
• a menu bar is only present in the first, or 'primary', window; it doesn't follow the 'New' tab or move to any other windows
• tabs open in the currently focused window, not the ‘primary’ window
• window docking with edge snapping will be fully supported

Here's a mockup (not final) of what this all looks like together:

And here's the prototype from our tech spike in action:

While it's not pictured we're also considering how to incorporate at least one more level of folders in the 'New' tab's local repositories list for more advanced groupings while retaining our original goal of a simpler experience more akin to the modern Windows one.

Cheers,

Brian Ganninger
Product Manager, Sourcetree

[Michael]

That looks slightly more promising, what would be great is if that 'New Tab' with the repo listing was simply docked to the left and always visible and not a tab itself (which seems odd anyway)..you could double-click on a repo to open it in a tab, it would essentially be like the old SourceTree and what most of us are looking for.

This does give me hope that it's at least heading in the right direction though. :)

[stijn]

Hi Brian,

Thanks for the update

A question: is it possible you're fighting the underlying UI framework here, or is there another reason it is not possible to have docking? Just asking because I'm wondering about that, and because having docking ability would pretty much solve all requests regarding 'bring the old sourctree back'.

Alternatively, if the above makes it, does it also persists window layout/open tabs in between program launches? That would be close enough (as in: one could always keep the 'new tab' open to get the reposittory overview and then next to it a window with just repository tabs, which would visually match the old ST).

[Ashley Wilson]

It does seem like the team is desperately trying to work around a decision that they made (or was made for them), rather than delivering a commonly used UI paradigm of a docked panel. Trying too hard to give users a sidebar that they have been clamouring for, without calling it one.

Anyway, "window docking with edge snapping" sounds close enough to a docked panel, except it will have its own window and tab controls. If those tab controls are hidden when the "new" "tab" is the only thing in that window when it's snapped to the primary window, and "tabs open in the currently focused window, not the ‘primary’ window" no longer applies in that case, this will finally let them get away with a sidebar without having a sidebar.

Again, that's a whole lot of effort to have a sidebar without calling it a sidebar. Team, are you guys being held hostage to a mandate from superiors to not give a sidebar that users are asking for? Do you guys need help? We could make an online petition. Blink twice if this is close to the truth :|

[scottgoddard]

Hi Brian

This seems like it would meet all my requirements and allow me to switch from V1.* at last. It is unfortunate that this has been such an unnecessarily long and frustrating process but at least it seems like we are on the final straight now.

Scott

[Black Hat]

First thoughts based on those mock-ups...

a menu bar is only present in the first, or 'primary', window; it doesn't follow the 'New' tab or move to any other windows

This is going to be really confusing. Apart from the menu, the windows look identical to each other, and I can see myself looking for the menu on a window that's not the "primary" window.

The Repository and Action menus (currently) apply to the selected tab. To use those menus, I have to find the primary window, which could be on another monitor, or maybe it's even been minimized. That's a big usability problem.

I like the icons for each repository. 👍 That'll really help with quickly locating a repo, but where do the icons actually come from?

While it's not pictured we're also considering how to incorporate at least one more level of folders in the 'New' tab's local repositories list for more advanced groupings

So, it'll sort of be like.... a tree view? 😉

A few asides:

• I really hope that while you're doing this work with new tabs and windows, that you fix the usability issues around dragging the window while it's maximized (see SRCTREEWIN-6983, which for some reason is Resolved even though it's still a bug).
• Have you heard of AvalonDock?
• That large row height in the commit list seems detrimental to usability. I agree that each row could do with a bit more padding than what is currently used in Sourcetree, but based on my calculations, the row height in your screenshot reduces the number of rows I can see on screen by about half. 🙁

[bgannin]

@Black Hat I wouldn't infer too much from the screenshots beyond the sidebar, and even then keep in mind that it's a mockup for this discussion, not the final product.

[Black Hat]

The exact same mockup with the larger row height was posted to the SourceTree blog over a year ago. In fact, the only difference I can see is the badges in the toolbar and tabs. That seems to indicate to me that there's a commitment to the larger row height. Or maybe you just found that old image, stitched them together in Paint and added some badges. ¯\_(ツ)_/¯

https://blog.sourcetreeapp.com/2017/05/18/windows-2-0-gets-a-fresh-look/

https://blog.sourcetreeapp.com/files/2017/05/after.png

But anyway, moving on...

What's the plan for the Repository and Actions menus if there's no menu bar on secondary windows?

And as others have said, it's seems like you're trying to make a sidebar without actually making a sidebar. If I understand this correctly, the intent is to be able to drag the "new tab" tab out to a new window, dock it to the edge of the screen and treat that as a sidebar.

Based on what you've said here as well as what you confirmed in @scottgoddard's comment here, that means when we do drag this "new tab" out to a new window and treat it as a sidebar, if we then double-click on a repository to open it, it will open in the _sidebar's_ window, and then we need to drag that repository tab out of that sidebar window and into the other window.

The "tearable" tabs seems like a really convoluted hack to create a sidebar that's not actually a sidebar.

window docking with edge snapping will be fully supported

Unless I've misunderstood what you mean, this is just natively supported by Windows. Today I can already snap SourceTree to the edge of my screen. Is this what you're referring to, or did you mean something else?

P.S. You may want to rethink calling them "tearable tabs" before someone decides to call them "terrible tabs" 😁

[Terry Holmes]

Certainly looks like an evasion.  It's weird, but it'll do.

[NDE-Agentur]

These are realy lame excuses. Please just get the work done and bring back the sidebar. There is nothing to bla bla about that. Running 2.x i cant even measure any performance improvents that could be lost. and even if there are performance improvements they are useless as a cant use the software anymore. maybe its running faster. but now i have to check all my repos manually. Get it?

[NDE-Agentur]

Why don't you just bring back the old Panel 1:1 and let users decide if they want to use?

I mean - all this talking, you could have done it twice in this time. 2x is not any faster than 1x. And even if - you would admit that manually checking and struggling around with tab navigation is really time consuming.

Just bring it back an everybody is happy. And if someday you have a genius new idea let people choose.

I don't understand why you take years for such a simple but so important thing.

[nofishonfriday]

Agreed with https://community.atlassian.com/t5/Sourcetree-discussions/dev-team-Proposed-Sidebar-Replacement-for-Windows/m-p/844400#M641

It seems you're trying hard to give users something kinda sorta like a sidebar as close it can get without it actaully being a sidebar (what users including me request)

I wonder why that is ?

[NDE-Agentur]

@nofishonfriday

Because obviously there is a very stupid and arrogant person on top of that team.

[Dwight Holman]

Interesting and sad to see debate (and users) still raging on this.

I liked the old 1.x SourceTree because it had a clean UI and some great usability improvements over Tortoise. IMHO the UI did not need to be any simpler. You only needed to resolve (or manage) the performance issues.

The 2.x versions are overly simplified. Remember your target audience are software developers that regularly use tools with complex UIs - like the Visual Studio UI you posted earlier on. Sadly I see the GitKraken team are also using lists instead of trees. I'm sure you are smart enough to watch what others are doing and look for ways to do things better and differently.

As a professional software developer that tree of projects is my natural environment. It is not a list.

Atlassian the only way you will win back a significant number of these users is to reinstate a TREE view that provides a way for the developers to navigate their SOURCE projects. I think even one that does not visualise the pending incoming/outgoing changes would be an improvement. If it works quickly and effectively, lots of developers who are using (or switching to) other tools might consider SourceTree.

The Windows Explorer still has a tree view control basically the same as introduced in the original File Manager. For competent (technical) users this is the right solution for the problem - a list view is not.

[bgannin]

Hi folks,

Rather than proceed down a path that didn't meet your needs we went back to the drawing board. The final result is a more modern interpretation of the sidebar that returns the functionality you know and love. We previewed it today in a blog post and I started a new discussion here on Community for us to continue the conversation. Please join in there.

Cheers,

Brian Ganninger
Principal Developer, Sourcetree