Too many target="_blank"s? #9613
Replies: 6 comments 5 replies
-
|
I'm happy for it to be consistent. I think it was discussed, but changing based on feedback isn't bad. :) I'm just not comfortable enough with the new UI layer to make the change, but I have no issues with that being changed. |
Beta Was this translation helpful? Give feedback.
-
|
I Agree, we are currently evaluating go, and it is really annoying |
Beta Was this translation helpful? Give feedback.
-
|
Hello @chadlwilson @arvindsv (and everyone) I vaguely remember the debate between "Opening Links in current tab vs new tab", when we were re-designing the dashboard, and here are some points why we picked opening links in new tab: The current dashboard brings in alot of information, such as jobs in stage(s), currently building agent, stage history, vsm, etc. And all this additional information is related to the current context of pipeline/stage/job we are viewing. If we choose to open the clicked link in the current tab, its impossible today to go-back to the previously visited state on dashboard (by using browser back button) from the visited link (Eg: Visiting a job console log of previous stage history from stage information pane). To make sure that the context isn't lost, we chose to open the links in new tab. We also discussed as it might not be consistent with the rest of the application opening links in the current tab. We understand that its a different DX experience, however, it was a conscious decision made based on the use-case of the current dashboard. Having said that, there is no strong argument to keep this behaviour, If the dashboard is used as a starting point to visit these links and the dashboard is never revisited, I am fine opening the links in current tab. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the input. I think the philosophy here would just be to return control to the user. I agree it's annoying to lose context, however the current setup makes the choice for the user rather than allowing them to do it with a middle click / long click which would be their normal approach on most other sites in order to achieve this. That's not so nice on an Apple trackpad due to no middle click mapping (without separate software for say a three finger click) and having to do a CMD + click but that is the same challenge across the rest of the web too. It would require a bit of re-programming of muscle memory for folks which does give me pause for thought though. |
Beta Was this translation helpful? Give feedback.
-
Yes, we can never make everyone happy. :) However, with the change to return control, as you said, ones who like the current behaviour have a (usable, standard) workaround. That makes me feel alright about the proposed change. |
Beta Was this translation helpful? Give feedback.
-
|
I wanted to explore if there was an easyish way to feature toggle it in case it creates user rage, but aside from whether it's worth the effort - haven't got myself familiar enough with the approaches for doing UI/view-specific feature toggles (that don't just use the toggle to return something off a specific API) to see whether that's relatively easy to do. |
Beta Was this translation helpful? Give feedback.
-
|
@chadlwilson - We have done UI feature toggles in the past. The approach we've taken is:
|
Beta Was this translation helpful? Give feedback.
-
|
I would also really welcome back this control. I'm not enraged, as Chad may have feared (the other person certainly was), but I am rather irate about having to juggle a bunch of tabs now. What was meant to reduce context loss has in fact only shifted context for me, away from a couple pages of gocd, to a dozen tabs. Feels like I'm worse off. For tabs, given page titles and how they are abbreviated, the tab titles/headers aren't particularly useful to navigate back to where I want to go. There's no indication of tab recency (other than tab ordering) and partial title. Build numbers are not visible in the tab titles. Back and forward buttons are useless with new tabs/windows.
So, after more than 5-6 tabs, I tend to just close ALL the tabs, and start from scratch from the dashboard again. I've done a good amount of pipeline work today, and cleared my tabs a few times already. I would like to thank Chad for the PR, and really wish it could be merged. |
Beta Was this translation helpful? Give feedback.
-
|
I'm kind of okay with just merging the PR as-is but my preference would be to add a user preference that allows reversion to the new tab approach, at least for the dashboard and places without proper deep linking or client side routing support. Want to volunteer to figure out some mithril JS? 😅 |
Beta Was this translation helpful? Give feedback.
-
|
I decided to merge the PR in #10520 basically "as is" for GoCD If people would like a feature flag or user preference to go back to the <= |
Beta Was this translation helpful? Give feedback.
-
|
On Thu, Apr 25, 2024 at 6:56 PM Chad Wilson ***@***.***> wrote:
I decided to merge the PR in #10520
<#10520> basically "as is" for GoCD
24.1.0 with no feature flag or user preference to go back to the previous
behaviour as it felt more effort than worthwhile. YOLO? Did another
run-through of all of the places and tried to make the visual indication of
whether you are going to get a new tab as consistent as possible.
If people would like a feature flag or user preference to go back to the
<= 23.5.0 behaviour, I'm open to follow-up PRs. Otherwise lets try a
scream test.
I used to enjoy this convenience, but I realised since this bug was filed
that I am used to the default behavior all across the web. So, I'm
personally OK with whatever you choose to do. In other web apps, we do open
a link in new tab for side-by-side viewing and comparison, etc.
… —
Reply to this email directly, view it on GitHub
<#9613 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAF5JGXYTARUNKTB5Q7GLOLY7DOMHAVCNFSM5CNXKFR2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSMRSGM4DEOA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
As the, err, "direct" suggestion in #9526 notes, it's a bit irritating for some users that GoCD forces many links into a new tab. Personally I agree with the sentiment.
After upgrading to the version which introduced these great dashboard-driven "Stage Overview" and "Jobs List Widget" overlays, I observed that this quickly became the main way folks interacted with the pipelines, and found myself doing so. But when you want to drill deeper to the specific job, the user interaction experience is inconsistent, and sometimes I'd find myself in a sea of tabs when I intend to just pop in and out.
Forced to new tab
Middle-click to new tab
The Job Console Log I found is by far the most frequently used link, however I feel it would be more consistent if we reverted to what I feel is the standard Web semantics of allowing the user to control whether it is a new tab or not., especially with tools designed with more experienced users in mind.
This would also make it a little more consistent when interacting with jobs as displayed in Stage Details (albeit with the extra inconsistency of a direct link on the job name, rather than the distinct Job Console Log icon):
What do we think about returning control to the user, especially around this particular overview? It's a relatively trivial change I believe, but might require some slight re-programming of user instinct. Was this discussed when introducing the awesome new overlay thingies?
Beta Was this translation helpful? Give feedback.
All reactions