Proposal: Fine tune tabs in workbench

Issue #294 open
Anonymous created an issue

I love workbench - its absolutely great, so why not make it even better. Right now a double-click on the list of repos on the left is required to open multiple repo tabs. Then one can switch between tabs with a single click. Some functionality is duplicated. (list on the left requires a double click, while tab-list requires a single-click).

The proposal:

Get rid of horizontal tabs bar, to save space. Handle single-click on the repo list on the left to switch between repos.

Comments (13)

  1. Adrian Buehlmann
    • changed status to open

    An interesting idea.

    Problems I see though:

    • Currently, you can have multiple tabs open for the same repo (use "open" from the context menu in the repo registry)
    • The repo registry can be hidden
    • In the future, we might add different kinds of tabs
  2. Anonymous

    Yes. These problems need to be considered, before any design changes to the GUI. Regarding the first problem, I do not see any functional reason to open the same repo in 2 tabs.

    Maybe a smaller change first then. Just handle a single-click event and open a tab (the same as a double click event now). Right now everything in the workbench including tabs need a single-click. The only exception is the "Repository registry". I frequently single click a repo just to find out, that it was only selected (selection has no attached functionality AFAIK, other than highlighting the repo). On the other hand someone might attempt a double-click on the tabs because of this inconsistency in the design.

    Anyway I hope that this proposal will be at least considered, because it is an easy change to implement and improves consistency of the interface.

  3. Thomas D.

    Imho, this is one of the most confusing daily workflow breakers in THG. I just can't convince my brain to double-click on an explorer-style tree item just to see it, nor to understand the fact that a selected AND focused tree item isn't shown, but some other bold printed tree item is. The entire behaviour around this is weird and not useful. I have never seen such behaviour and ambiguous UI states anywhere else in my entire history with software.

    Proposal 1 (fast bandaid fix)

    As a minimal fix, as reporter already suggested, please hook up the current double-click behaviour routine to the single-click event. Maybe that's just one line of code...

    FTR: Current double-click behaviour (Proposal: do the same for single-click)

    • first double-click on repository A will open it in a new tab
    • contextual "open" on repository A will open another tab for A, next to the currently selected tab
    • subsequent double-clicks on repository A will go to the first tab having A (from left to right in tab row)

    Proposal 2 (full fix)

    Let's get this entire weirdness sorted out and normalized.

    • Single-click in the Repository Registry tree must update the right side (revision list) to simply show the selected repository, without any clutter of new tabs. We have no reason to assume everyone wants tabs, and they don't add much value for the default layout, just confusing duplication of UI as reporter mentioned. Btw I doubt that many multi-registry users would ever want to hide the Repository Registry tree.
    • Don't open anything in tabs unless user has explicitly requested that
      • context menu: 'open in a new tab' (that would probably suffice; just rename 'open')
      • if we believe it's a frequent action, we could make double-click open another instance of the repository in a new tab, every time it's double-clicked (as 'go to' is now covered by single-click)
    • Add option to show tab header even when there is only one tab, for added clarity (as known from internet browsers and many other tabbed UIs), probably defaulting to 'true'

    Actually, that still sounds simple enough to be very doable. Please do it asap. Tia.

  4. Thomas D.

    I missed one aspect in Proposal 2: - When multiple tabs are open, including potentially multiple tabs for multiple instances of the same repository: I'd guess we could do something like double-click does now: single-click in repository list should go to an existing instance (tab) of the repository (as opposed to changing the repository shown in the current tab - would that be useful?). Maybe we should go to the last tab with an instance of the repository, as that is more likely to be the most recently used instance.

    @Yuya Nishihara, can you comment on my proposals of my previous comment and this comment, or invite someone with UX powers in thg to comment?

  5. Thomas D.

    Imho the current summary of this issue is not very actionable, and this is so deviant from any known default behaviours that I would consider this a bug, not a proposal/RFE. I wonder if we could re-open my issue #4994 to implement the bandaid fix for single-click to be the new double-click (without any other behaviour/UI changes), as described in my Proposal 1 above.

  6. Sylwester Zarębski

    I see problems with above suggested changes for selection:

    • using RightClick menu - it selects repository under cursor. This RightClick selection should not ever open repository in tab,
    • keyboard navigation - every cursor up/down select repository.

    Also even Proposal 1 i see this as serious change which break my workflow and is counter-intuitive for me - i'm used to see SingleClick as Select and DoubleClick as Open - the same as Explorer list of files or programs.

    Proposal 2 is even more breaking change, because i mostly have open more than 1 repository and it will be often when i could accidentally replace current opened repository because of changed open - with no way to bring it back, which leads to having history of opened repositories in tab and so on...

    Please, keep it simple - or make options to choose work style, eg: Enable single click for repositories list, Disable multiple tabs etc.

  7. Thomas D.

    @Sylwester Zarębski, thanks for your feedback on the proposed changes.

    I see problems with above suggested changes for selection: * using RightClick menu - it selects repository under cursor. This RightClick selection should not ever open repository in tab,

    Yes, right-click will select only while the context menu is open, and must not trigger anything else. If you ESCape from context menu, there'll be no change of selection, so no change in repository view. Pls check Windows 10 Explorer to see this behaviour in action.

    • keyboard navigation - every cursor up/down select repository.

    No, keyboard selection must not trigger anything unless you press ENTER to confirm your selection. Again, pls see Windows 10 Explorer behaviour.

    Also even Proposal 1 i see this as serious change which break my workflow and is counter-intuitive for me - i'm used to see SingleClick as Select and DoubleClick as Open - the same as Explorer list of files or programs.

    I believe to most users, the current workflow is interrupting and counter-intuitive (hence this bug), because it is NOT like Windows Explorer behaviour. Please note that in Windows Explorer folder tree list, single click DOES open the folder in the folder view on the right, to allow for fast and easy navigation. Double-click is only applicable in the folder view where multiple selection is allowed and selected items can be worked on.

    Proposal 2 is even more breaking change, because i mostly have open more than 1 repository and it will be often when i could accidentally replace current opened repository because of changed open - with no way to bring it back, which leads to having history of opened repositories in tab and so on...

    Please be more specific, proposal 2 has several aspects. I think you wouldn't like it that double-click opens a new tab every time (not only first time) - we can change that aspect of my proposal and keep the existing behaviour (btw, "with no way to bring it back" can never happen with my proposal). With that minor change, I don't see how my proposal could break any of your workflows because the double-click behaviour would not even change.

    But I don't see why anyone would prefer to be forced into double-click when the same result can be achieved with a single click, without any other losses or compromises in terms of behaviour. Because there's no reason to left-click-select a repository in the list other than to show it, there's nothing else you can do with a click-selected repository, apart from contextual actions for which you would right-click, not left-click. And for keyboard selection, we don't update the repository view whilst you're navigating, so no breaking changes here either.

    Please, keep it simple

    Yes, that's exactly what we're trying to do. Needless and pointless double-clicks aren't simple.

    or make options to choose work style, eg: Enable single click for repositories list

    I don't think that's needed as we're not even touching the traditional workflows.

    Disable multiple tabs etc.

    Also not needed imo. I think an option to show tab header for single tab or not is sufficient.

  8. Sylwester Zarębski

    Comparing to Explorer do not have much sense, because Explorer do not have MDI interface at all - it is SDI only, and THG is opposite - it is MDI.
    Better compare is with editors like VSCode which opens temporary tab on SingleClick and permanent tab on DoubleClick.

    Proposal 2 has two changes in fact:

    1. Single click open - it should be optional to choose it or not.
    2. Single tab management - like above, it should be optional.

    I'm used to DoubleClick because i have many large repositories which opens few seconds and mistake at clicking it could cost my time. Now i do not care to SingleClick because it do not have any consequences, when SingleClick only select repository. I have also a habit to sometimes LeftClick before RightClick (because Explorer sometimes do not register properly RightClick on file/folder to select it and show wrong context menu) and above changes will also affect my work. Thus need for option.

  9. Thomas D.

    Comparing to Explorer do not have much sense, because Explorer do not have MDI interface at all - it is SDI only, and THG is opposite - it is MDI.

    Yes, THG is currently forcing MDI on everyone even when we don't need it.

    Better compare is with editors like VSCode which opens temporary tab on SingleClick and permanent tab on DoubleClick.

    Bottom line: VSCode allows both SDI and MDI, and defaults to SDI on single-click. I like the VSCode behaviour much better than the current THG behaviour - and I think it's very close to what I suggested (one notable difference: First double-click will open file permanently in existing tab, then next single-click opens in a new tab so as to preserve the double-clicked tab. That's looks like better behaviour than mine because it ensures that every double-clicked element will permanently keep its own tab.)

    Proposal 2 has two changes in fact: Single click open - it should be optional to choose it or not.

    Is it optional in VSCode? I think not. There's actually no good reason to make this optional, as you can always use double-click for the "permanent/own tab" behaviour.

    Single tab management - like above, it should be optional.
    

    Dito, making that optional just adds maintenance burden, but no real benefit, as you can always double-click to open a repository in its own dedicated tab.

    I'm used to DoubleClick because i have many large repositories which opens few seconds and mistake at clicking it could cost my time.

    So you can just continue to double-click and nothing relevant will change for you.

    Now i do not care to SingleClick because it do not have any consequences, when SingleClick only select repository.

    Again: What do you want to select a repository for?

    I have also a habit to sometimes LeftClick before RightClick (because Explorer sometimes do not register properly RightClick on file/folder to select it and show wrong context menu)

    We certainly shouldn't preserve clumsy application behaviour in THG because of personal dubious habits based on alleged bugs in Windows Explorer (and I have never experienced that bug - any reproducable steps?).

    and above changes will also affect my work. Thus need for option.

    If you'd just refrain from your non-standard behaviour of single-left-clicking before right-clicking, and otherwise continue to double-click as you did before, you won't be affected. But for many other users, defaulting to single-click (also to switch between multiple tabs) will be a significant increase in ux-efficiency (call it convenience), and avoid the current confusing UI states where a selected AND focused item is NOT shown.

    Depending on circumstances, that's also a case of UX-error-prevention: My personal use case is having two repositories with an identical patch queue, one for a local flat install, and another one for the official source of Mozilla Thunderbird. I often switch back and forth between the two, and with the current UI it's very hard to tell which one is active, as THG's current way of bold-print to mark the active item while allowing another selected and focused item to be inactive is unheard of (non-standard).

    I would like to encourage others to try VSCode SDI/MDI behaviour and offer some feedback here if we could have something like that to improve THG and make it more agile.

  10. Sylwester Zarębski

    Yes, THG is currently forcing MDI on everyone even when we don't need it.

    And I would like to keep as it is, and do not change it. When someone want another behaviour, make it optional. Otherwise it change my habits, which "makes me angry" ;-).

    Bottom line: VSCode allows both SDI and MDI, and defaults to SDI on single-click. I like the VSCode behaviour much better than the current THG behaviour - and I think it's very close to what I suggested (one notable difference: First double-click will open file permanently in existing tab, then next single-click opens in a new tab so as to preserve the double-clicked tab. That's looks like better behaviour than mine because it ensures that every double-clicked element will permanently keep its own tab.)

    Editors like VSCode are always MDI and only has a notion of temporary opened file and any temporary file goes permanent tab on any file change. Temporary opening repository (temporary tab) makes no sense for me, because any operation on that repository have to go permanent tab.

    Again: What do you want to select a repository for?

    It is not about select repository. It is about to NOT open repository when accidentally SingleClicking it.

    We certainly shouldn't preserve clumsy application behaviour in THG because of personal dubious habits based on alleged bugs in Windows Explorer (and I have never experienced that bug - any reproducable steps?).

    It is not "clumsy", but current THG standard, which is good for me and i want to stay like that. Also i do not want to anyone change my habits, because someone do not feel current behaviour good.

    Depending on circumstances, that's also a case of UX-error-prevention: My personal use case is having two repositories with an identical patch queue, one for a local flat install, and another one for the official source of Mozilla Thunderbird. I often switch back and forth between the two, and with the current UI it's very hard to tell which one is active, as THG's current way of bold-print to mark the active item while allowing another selected and focused item to be inactive is unheard of (non-standard).

    I do not see any problem, because You can exactly see which repository is opened by repository name on tab (also You can set custom repository name). If You do have hundreds of repositories (like me) using repository registry to see which one is opened/current, is useless.

  11. Thomas D.

    Editors like VSCode are always MDI and only has a notion of temporary opened file and any temporary file goes permanent tab on any file change. Temporary opening repository (temporary tab) makes no sense for me, because any operation on that repository have to go permanent tab.

    Good point. It certainly depends on scenarios and workflows whether SDI may make sense for THG users or not. So admittedly, allowing (not forcing) SDI as in my proposal 2 may not be needed. We're not here to force SDI into THG, the main issue of this bug is to eliminate a useless double-click which adds exactly nothing over a single click doing the same. So my proposal 1 still stands, just make single-click do exactly the same as double-click does now.

    Again: What do you want to select a repository for?

    It is not about select repository. It is about to NOT open repository when accidentally SingleClicking it.

    I think "accidentally single-left-clicking" is a pretty unlikely scenario for the majority of users. There's nothing you can do with the selection on the left (except getting the context menu for which right-click is sufficient), so there's no reason to left-click except the intention of doing something with that repository for which it should normally be shown. Again, your accidents can't be a reason to preserve an inefficient UX where everyone needs to double-click without any benefit over just single-clicking.

    We certainly shouldn't preserve clumsy application behaviour in THG because of personal dubious habits based on alleged bugs in Windows Explorer (and I have never experienced that bug - any reproducable steps?).

    It is not "clumsy", but current THG standard, which is good for me and i want to stay like that. Also i do not want to anyone change my habits, because someone do not feel current behaviour good.

    Fortunately, the world does not rotate around you... This is about UX principles and convenience for the majority of users, and if we're doing my proposal 1, you're losing absolutely nothing worth keeping of the existing behaviour. You can just continue to use double-click as before. Only your "accidental single-left-clicks" on a repository will now show that repository, which isn't harmful and certainly not a reason to force everyone else into double-click where one click can suffice. I'm against making that optional because it doesn't help anything, and is harder to implement, i.e. making this change harder to get.

    I do not see any problem, because You can exactly see which repository is opened by repository name on tab (also You can set custom repository name).

    Yes, but that doesn't change the fact that the left side of the UI is in a highly confusing UI state with one bold-printed item which isn't selected but shown, and one selected AND focused item which is NOT shown. Show me ONE popular application which has the same ambiguity in tree selection (except while keyboard-navigating the tree).

    If You do have hundreds of repositories (like me) using repository registry to see which one is opened/current, is useless.

    Accepted, but apart from hundreds of repositories probably being an edge case, more importantly it's no reason against having single-left-click do what double-click does now (per my Proposal 1), which is one click less for everyone every time when using the repository registry, and ensures a clear, unambigous and reliable UI state in the repository registry . The fact that you personally don't look at the repository registry doesn't mean that everybody must put up with the current UX confusion just so that you can have your "accidental single-left-click" without the pretty insignificant consequence of just showing the repository. We'd actually help you to get rid of that habit of accidental clicks, which is generally not recommended as a modus operandi for software. ;-)

  12. Sylwester Zarębski

    Did You do any statistics about "majority of users"? If not, i call this bullshit, because majority of users had no problem with DoubleClick behaviour for years.

    Discussion goes to nowhere, I said my opinion which is want to stay at current behaviour and vote for no change or optional eventually.

  13. Log in to comment