Visited links aren't purple anymore
Categories
(bugzilla.mozilla.org :: User Interface, defect)
Tracking
()
People
(Reporter: lizzard, Unassigned)
References
Details
(Keywords: regression)
In the new style today, visited links don't show as different than unvisited. The visited link contrast is very useful for me when I'm triaging through a long list of bugs.
Comment 1•6 years ago
|
||
I’ve changed the colour intentionally. The reasons are described in Bug 1531517.
Comment 2•6 years ago
|
||
Any chances to reconsidering this change, please?
For me, simple manual tester helping bug hunting and bug triaging, it's kinda massive obstacle which makes me less efficient and less productive.
Comment 3•6 years ago
|
||
This is not a regression because it’s an intentional change and the link style now matches markdown comments (and GitHub issues and whatever). But I understand it can be a problem and the answer here is probably Bug 1472450.
Comment 4•6 years ago
|
||
While I really appreciate all the good design work on Bugzilla please don't forget that Bugzilla is a productivity tool. Bugzilla has other requirements than an arbitrary website. After Bug 1531517 you now regressed another part of Bugzilla with the same change. I really need to be this clear and call it a regression because it makes it much harder for me to do by Mozilla related stuff (support, research for articles and testing Firefox).
To repeat what I already said in Bug 1531517 because the same applies here:
While I am not a big fan of :visited styles in general it's an important feature for certain websites likes search engines or bug trackers like Bugzilla. Bugzilla is a productivity tool and it should be all about efficiency for the users of the tool, that's much more important for a bugtracker than a color which looks good. With this change I no longer see which tickets I have already visited and I have to invest more time…
Please fix this regression.
No, Bug 1472450 is not a solution at all.
Comment 5•6 years ago
|
||
Bug 1472450 is a solution for this because it de-highlights all read bugs and highlights again when the bug has any updates. It may be difficult to imagine how it works unless you’re a regular user of GitHub, though.
Comment 6•6 years ago
•
|
||
Bug 1472450 is a solution for this because it de-highlights all read bugs and highlights again when the bug has any updates.
Nope. I wouldn't say that Bug 1472450 is not a solution if it wasn't true for me. It's not about updates but about visited bugs. It has nothing to do with updates at all, it's a completely different use case.
It may be difficult to imagine how it works unless you’re a regular user of GitHub, though.
I know GitHub very well, I am a regular user of GitHub. I use GitHub every day.
Comment 7•6 years ago
|
||
please reconsider rolling back this change. As a nightly tester and bugzilla user, this makes keeping track of visited bugs difficult.
Comment 8•6 years ago
|
||
I use the difference between visited/unvisit to identify "bugs which are not enough to Cc but I want to keep in mind".
It is useful especially in the list view of saved search.
If bugzilla can not accept reverting the default view of visited/unvisit links, please make an option in preferences.
I agree with the sentiment that the fix described in bug 1472450 is not a solution for this problem, both because it's a different use-case as Sören indicated, but also because I'm also interested in which bugs I've visited on pages outside of search results.
As a workaround/hack I have the following in my BMO userstyle:
a[href*="show_bug.cgi"]:visited {
color: blueviolet !important;
}
#this-bug:visited {
color: var(--link-text-color) !important;
}
Comment 10•6 years ago
•
|
||
Here are the instructions:
https://www.chevrel.org/carnet/?post/2018/01/10/User-Style-for-bugzilla.mozilla.org
Install for example https://addons.mozilla.org/en-US/firefox/addon/stylish/
and add that CSS. Let is apply to URLs starting with https://bugzilla.mozilla.org
EDIT: "Stylish" didn't work reliably for me, so I switched to "Stylus" - https://addons.mozilla.org/en-US/firefox/addon/styl-us/.
Thanks, Bryon!
I also added
body {
font-size: 14px;
font-family: Arial;
color: black;
}
since the new font FiraGo is not rendered properly and looks too small.
Comment 11•6 years ago
|
||
Something that worked before does not work anymore. From a user's (reporter's) view it is a regression. Keywords are set respective to their description.
Often I opened dependencies of bug 1386665 and bug 1386669 and the :visited color was crucial to not miss one. Even the behavior from attachment 8888950 [details] would be more helpful than the current one. ;)
Comment 12•6 years ago
•
|
||
Please do not add the UX keywords randomly… We have fixed a UX inconsistency issue with the new skin. Other keywords are not relevant.
Comment 13•6 years ago
|
||
"ux-consistency" doesn't only mean consistency with itself. Consistency to an other regression (bug 1531517) is a personal standpoint.
Behavior should be appropriate to the content and serve the user. You intentionally deactivated a built-in accessibility feature.
ux-consistency: User experience principle: in general software should be internally consistent with itself, and externally consistent with similar interfaces to leverage the user's existing knowledge.
Usual behavior of document browsing interfaces. You don't use native apps to process so much interconnected information as you do with a web browser. Examples of useful vs. not useful behavior: Bugzilla, Gerrit, Mediawiki vs. GitHub, Trac.
ux-discovery: User experience principle: users should be able to discover functionality and information by visually exploring the interface, they should not be forced to recall information from memory. (This is often the nemesis of ux-minimalism since additional visible items diminish the relative visibility of other items being displayed).
ux-userfeedback: User experience principle: interfaces should provide feedback about their current status. Users should never wonder what state the system is in.
Have I visited this bug before? Didn't I miss to click one?
Comment 14•6 years ago
|
||
Nowadays there are many web sites and web apps that don’t have a visited link state, so “ux-consistency” is also not applicable. It’s not a surprise because it’s pretty obvious that CSS :visited
is not so useful. (That’s not specific to Bugzilla)
However, given that this change affects people’s triage work right now, I’ll add a visited state back as part of Bug 1552885 at least until Bug 1472450 is implemented. Thanks for the feedback!
Comment 15•6 years ago
|
||
(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #14)
[...] However, given that this change affects people’s triage work right now, I’ll
add a visited state back as part of Bug 1552885 at least until Bug 1472450
is implemented. Thanks for the feedback! [...]
Thank you very much for reconsidering this change! \o/
Comment 17•6 years ago
|
||
(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #14)
I’ll add a visited state back as part of Bug 1552885 at least until Bug 1472450 is implemented. Thanks for the feedback!
Again: Bug 1472450 is not a replacement at all, it's something completely different. But thank you for reconsidering this decision. I really appreciate this. And thank you for all your work to make Bugzilla better.
Description
•