Replies: 13 comments
|
Middle click (mousewheel press) is another shortcut by default to open a link in a new tab. That being said though I'm wondering if there's others with similar feedback that might justify rolling back the changes to right clicking that side bar because it's pretty bad UX. |
|
I'd be happy to make a proper feature request for reversion (or an option in Settings for everyone to decide for themselves whether they'd prefer the Companion right click menu or the browser's). Though I'd have to wonder how much feedback is needed for something that's being called "pretty bad UX". Obviously, I'm far from the only one using the program, but the bulk of the new menu seems like it'd be just as at home as Settings options. Everything except "Expand all" and "Collapse all" feels like something that could be a global setting in the Settings section, as they don't seem like they'd need to be changed particularly often. |
|
@MikeDFWM any modifier key with the click will give you the system menu. Maybe it could be better documented, or some way to merge the two. Not sure how easy the latter is. |
What I was thinking was that it would be beneficial to have a global setting/flag: "Use system right-click/context menu" or "Use Companion right-click/context menu", then the user can decide based on their preferences/needs and Companion would override the system or not, based on the status of that flag. I'm, again, happy to make a proper, non-discussion based Issue post if it's something worth considering or looking into. |
|
@MikeDFWM Adding a "prefer system menu" option is easy and I agree it's a good idea. You can still get both menus, but just choose which one opens on click vs. modifier-click. I'll push a PR and am happy to discuss it further as well -- here or there or in an issue. And of course in my way of thinking, the natural place for this option is in the context menu itself! As to the UX question that Jeff (@thedist) raises, I try to use web-versions of popular apps such as Slack for guidance. Here's what right-click on the sidebar does if you open Slack in your browser (i.e. not the desktop app, though it works the same there too):
You can see things that look like settings, and more importantly, right click in their sidebar doesn't bring up the system menu. (And their trapdoor to the system menu is strictly the alt key, so I'm a bit more lenient there.) Other apps preserve the system menu and some, like Trello do it either way depending on where you are, so I'd say that there's no single truth here. FWIW, the only thing I consider "set-and-forget" for my own Companion use-case is removing the help items, which are now more easily accessible from the header help menu, but putting it in the context menu raises awareness of the option for now. (I almost never open Companion links in another tab or window, and in the end, middle-click or ctrl-right-click just takes a few repetitions for me to get used to.) My preference for sidebar width-mode tends to change with window size, which in turn depends on what else is going on at the time -- and it's worth noting that the "width toggler" is already in the bottom-left corner of the sidebar, so the main thing that that section of the context-menu is doing is making it more convenient/visible and adding a new width mode. (It took me months to notice and realize what the little icon in the bottom-left even did: aside from being dim, it didn't seem to do anything when you clicked on it -- something I changed in 4.3, though.) Yet another way to look at the "settings" question is: In general, I find the settings pages difficult to access -- it usually requires several clicks and clutters the sidebar -- and by the same token, it makes it difficult for users to discover their options. Tucking simple settings in a context menu helps raise awareness of the options and also makes it much easier to try out different options to see what works best for you while you are working, i.e. without breaking your workflow. |
One of the issues here is that such apps try to maintain a consistent experience between both their web version and desktop app, with often the desktop app being the primary product from which other versions are built off of, so it's somewhat an apples to oranges comparison with Companion.
Yes, it varies greatly as to when and where this sort of thing is done and why appropriate care should be taken in the design. For example it's not uncommon for the sites that have their own context menus to have been doing that from day 1, as opposed to having years of users familiar with functionality being one way, and then changed on them. Additionally there are tradeoffs to be considered as to if the value added by the context menu outweighs the downsides, disruption to established usage patterns. As an example of this there's Youtube, it doesn't use custom context menus for it's navigation menus to traverse the various sections of the site in part because it was already established that using right click would bring up the standard browser right click menu, but also the value added in being able to collapse menus through a context menu is minimal compared to the number of users who right click and open in new tab or window as despite there being shortcuts for those actions a significant portion of users go through the right click menu. An example of where Youtube did add a custom context menu is when right clicking on a video player, as the value added by the capabilities in that menu exceed what would otherwise be there (as there's no opening in a new tab/window and one of their forms of mitigation was that 1 right click brought up the custom context menu, a 2nd right click would remove it and show the standard browser menu instead. Other examples include Google Mail which also has menus with content that can be collapsed/expanded but remains with the default menu because the value of that outweighs something to collapse/expand everything, but in other services such as Google Sheets the value of custom context menus far outweighs the downsides due to the functionality added. Another example more closely related to Companion would be Bitfocus Buttons, where it to does use custom context menus but on elements where it adds value such as renaming tags where there would be no opening in new tab/window, and leaves the left menu with the default browser menu.
There are ways to provide the options of collapse/expand menus and things of that nature without needing to send a user through a settings page. Such as a simple button in the menu that when clicked brings up all those options that you currently have in the context menu. Such as on Facebook where if you go to a group page like the Companion group, there's a Also by saying your tucking these settings in a context menu helps raise awareness of the options without breaking your workflow, consider all the users whose workflow involves right clicking to open in a new tab/window which was the established behaviour for years and now has additional steps. Finally, the default right click menu is not just about opening new tabs/windows, there are a lot of accessibility functionality in that menu often used by those with accessibility issues such as screen reader controls, text to speech, translation tools, all of which now have additional steps for those users all for being able to expand/collapse the menu there rather than a |
Another 'problem' with using the settings is that almost everything there currently is an application settings, but these menu items are browser stored preferences. Not necessarily a problem, just a question of making sure it is clear to the user that they behave differently. Maybe there should be a 'UI settings' section to make discovering some of these things easier, but at the same time I expect that most users wont go looking for that and will end up using whatever defaults we define.
I don't agree with this. I think that will be very easy to toggle and leave the user unable to figure out how to undo it. I have had this issue in other software before, either misclicking or wondering what something did and then having to google to figure out how to undo it (especially hard if you dont know what you clicked) I have some alternate pitches;
|
This would be my suggestion to keep everything in one clearly defined place. Generally speaking, I look to the documentation for the underlying functionality of the program, not the UI. "Settings" is the obvious place to look for settings, in my opinion. Adding a "UI Settings" page, with a description that they change on a per-browser basis, would make the most sense to me.
My concern on this would be that there's already a cog and "Settings" option in the sidebar. I can see having two that do different things leading to some confusion. |
|
So I'm unsure what the consensus is on what to do here, other than agreeing that it should change. I see 4 paths forward:
As I said earlier, I am not a fan of 2. But I am tempted by doing both 1 and 3. (or maybe 3 & 4) But I am not certain on this, so don't know how to progress on this. It would be nice to adjust this in a patch release soon, but as 4.3.2 is likely to be released within the next few days, it may be getting a bit late to change this under the claim of it being a bug |
|
I think 4 could work, as that makes the button to show controls for hiding/showing/collapsing the menu always accessible, and would also mean that the proper right click functionality on the menu could be restored. I'm not a fan of settings options to control right click functionality, I don't think many users would notice it being a thing and would stick with whatever is default. 1. might also be suitable but it's still leaves an inconsistent experience for users who have been utilizing a certain right click usage for years and now might think it's been replaced and not realise it's dependent on what area of the menu you right click. |
|
My perspective is that the average user of any program generally sticks with the defaults until/unless they feel a deliberate need to change them. If/when that happens, "Settings" strikes me as a perfectly obvious and valid place to look. As I mentioned, I did it myself. If a second "settings" option is created, even if it's only represented by a cog, I'd recommend at least adding an option there to go to the full "Settings" page, so anyone following an older tutorial (of which there are many for Companion) that tells them to click "Settings" isn't confused where the rest of the options are when they reflexively click the first settings option they see. But, again, that's just my perspective. |
|
It sounds like we all want to maximize the chance that users are able to benefit from this new functionality, which is great! That said, I'm not really in a space to think about this too deeply now, so perhaps my response reflects that: It seems to me that all of the alternatives mentioned so far have drawbacks as well as possible advantages, which in turn depends on guessing the users' preferred modes of behavior. My inclination is therefore to give the current design a chance for now, especially considering that we've already introduced it, which means that any change at this point may confuse those who are already using 4.3. |
One of the key points is that new functionality is great, but not at the cost of impairing existing workflows and negatively impacting usability and accessibility, which this update has done.
Only 15% of users are on 4.3, so I think it would be more beneficial to make any changes now while there adoption rate is low, and perhaps then the 85% of users who aren't on 4.3 by the time they upgrade we'll already have a more appropriate menu in place. |
Uh oh!
There was an error while loading. Please reload this page.
I generally right click the sidebar, then select to open the relevant page in a second tab, so I can have, for example, buttons and variables open at the same time to swap between them as needed.
4.3.0 now overrides the default browser right click menu.
Is there an option somewhere in Settings that I overlooked to get back the browser menu or otherwise enable easy tabbing without duplicating the tab or having to remember to hit Ctrl every time I click?
All reactions