Skip to content
Snippets Groups Projects
New issue look: Off

Review anchor styling site wide

    • Closed (moved) Issue created by Taurie Davis @tauriedavis

    Throughout the site we have a number of different styles for links. We need to review them and set some rules for when to use which styling in order to keep consistency.

    We also need to look into consolidating the style for the hover/focus/active state. See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4576

    The above MR needs a guideon how (in terms of design) and when apply a style for each state.

    Designs

      Child items ...

      2. Activity

      • Jacob Schatz Milestone changed to %8.12

        Milestone changed to %8.12

      • Chris Peressini Reassigned to @cperessini

        Reassigned to @cperessini

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        I compiled a list of most of the styles we use for text links as well as buttons. I left out where each one is used to make the images lighter but I can include it if anyone wants to see that information.

        Text anchors

        We (luckily) only seem to have a few approaches for anchors. The most common approach is just underlining the text and leaving the color intact. Other links don't add the underline (for example file names in the file tree), but since this style only shows up in a few places it seem to be more of an oversight than an actual design choice.

        Then we have links that turn blue on hover (like the ones in the Issue and Merge Request sidebars). These look nice but if we wanted to add more consistency we could do away with them. Their focus state is an underline, but I'd guess that was an implementation mistake.

        Lastly, we have links that both change their color and get underlined. I would suggest we remove the color change.

        All text links get wrapped in a glowy box on focus.

        text-anchors

        Buttons

        Buttons are a little more complicated. It seems that the default style should be a darker color on hover and focus and an added shadow on active. The problem is that for most non-white buttons the difference in color between the default and hover states is almost negligible, so we should work on making that more noticeable.

        Other buttons don't turn darker on focus, but I think that was a mistake in implementation, too.

        Hollow buttons get filled out on hover and focus and they get a shadow on active. They don't use the same colors for those states that the solid versions do.

        None of these buttons have the blue border on focus, which makes it very hard to tell when navigating a page with the keyboard. I propose we add it to all buttons and focus-able elements which will increase the accessibility of the site.

        button-anchors

        Other buttons

        These are buttons with styles that are very different from the norm. For example, the hamburger button changes its background on hover when the sidebar is collapsed, but changes the color of the icon itself when the sidebar is expanded.

        Navigation items largely don't have a differentiation between default and hover state. I think it'd be valuable to add one, for example making an unselected item look selected on hover. That would mean making the text black and showing the underline for First Level Navigation items, and turning the links blue for Second Level Navigation ones.

        other-button-anchors

        There's a lot that we can change in these styles, so I think we can all chime in to achieve the most consistent look.

        I look forward to your thoughts! @tauriedavis @hazelyang @dimitrieh @jschatz1

      • Jacob Schatz
        Jacob Schatz @jschatz1 ·
        Maintainer

        @cperessini can you tell us what needs to be done here to hand off to frontend?

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        @jschatz1 I'd say Frontend can get started by adding the blue glow to the focus state in all buttons. I think that'll be a great addition that doesn't need to wait for anything else. I think @alfredo1 wanted to solve that in !4576 (closed).

        Aside from that, we need to decide which styles we want to keep for text links and define better hover states for many buttons. The two main problems are that you can't tell that there's any difference in some buttons between default and hover, and others just behave inconsistently. I'll come up with some proposals but I'd like opinions from other designers because these are big style changes.

      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        @cperessini

        just to add my piece to this:

        links

        I like having text change color on hover as an extra indication.. Also so they remain in lign with mention links in for example issue text, those need the blue color to separate them from the body text.

        image

        Ideally I would have this for non mentions but with underline on hover and active as well: image

        buttons

        I also really dislike this button in the issue sidebar: image

        which is this row if I am correct: image

        They should be changed to normal buttons imo (no button should be gray from the start if hover states are the same color on other buttons). In that regard I think we should look if we can make the list of different buttons smaller. We should have a set of rules for when to apply which button, based on hierarchy (elements within elements)..

        None of these buttons have the blue border on focus, which makes it very hard to tell when navigating a page with the keyboard. I propose we add it to all buttons and focus-able elements which will increase the accessibility of the site.

        :thumbsup:

      • username-removed-408881
        username-removed-408881 @asumaran ·
        Contributor

        Since we are using Bootstrap, I think it would be relatively easy to restore the blue outline for the focus state on clickable elements. For some reason we overwrote the rule for focus and active states making them less accessible.

        Bootstrap handles those states correctly. We can later customize it with a consolidated pattern.

        Edited by username-removed-408881
      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        sidenote: Btw I have read in a customer critic document sid gave a while back that gitlab can sort of have the feeling of bootstrap.. which we are actually using... I think if we can get a bit away of this if we decide to adjust these styles to be a bit more gitlabby ;)

      • username-removed-711361
        username-removed-711361 @awhildy ·
        Contributor

        @dimitrieh Love the concept of moving towards feeling more 'gitlabby', though we need to figure out what that means. There should be a project where we design a couple key experiences, pushing what it means to be 'gitlabby'. That could help us understand what our target is, and then start making steps in the right direction with various details. I think #22192 (closed) is the right issue to capture these concerns.

        @cperessini The inventory above is super helpful. In the short term, I definitely want to solve the problem of not having a clear hover state for buttons (and any other clear usability concerns). Hopefully, those should be a pretty easy fix - and what I would like to complete with this issue. What needs to happen to do that? How can I help?

        @cperessini Afterwards, focusing on creating a consistent system for links and buttons all up would be fantastic. Let me know what you think, but I also feel like that work is also part of #22192 (closed).

        Thanks!

      • username-removed-711361 Milestone changed to %8.13

        Milestone changed to %8.13

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        @awhildy I think that making buttons darker for hover state is a good approach, it's just that right now it's too subtle. The problem with choosing new colors is that we're trying to cut down on the amount of colors we have in the app so we should find a solution that doesn't add even more clutter.

        There was some talk about applying the darken and lighten SCSS functions to a primary shade of the color. Those functions work by changing the luminosity value in the HSL spectrum, but Sketch only has the ability to work in RGB and HSB, so there really isn't a way for designers to work with those functions. Do you have any suggestions for this problem?

      • username-removed-711361
        username-removed-711361 @awhildy ·
        Contributor

        @cperessini Makes sense. I assume the concern with too many colors is more from a technical side (not wanting to keep track of too many color variables) vs. from a design side (cause visually using SCSS functions is the same as hardcoding a value).

        I would try using some web tool like this: http://colorizer.org/. Decide on both of the colors you want in Sketch (hopefully keeping the hue and saturation the same, and only tweaking the brightness). Then you can put both the primary and adjusted color into that tool, see what the HSL is for both, and what the difference is between the values. This may not be perfect, and you may need to double check how it looks when the dev codes it, but hopefully it should get you close enough. Do you think that would work?

      • Dimitrie Hoekstra Mentioned in issue #22192 (closed)

        Mentioned in issue #22192 (closed)

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        @awhildy Exactly, we have a variables.scss file with most GitLab colors and it's a mess, so we're trying to get that back under control.

        I think I'll use that, thanks! Saturation in HSB affects luminosity in HSL, so I'll have to do it the other way around: Create the colors in Colorizer and put them back in Sketch to see what they look like in context.

      • Dimitrie Hoekstra Mentioned in issue #22071 (moved)

        Mentioned in issue #22071 (moved)

      • Taurie Davis
        Taurie Davis @tauriedavis ·
        Author Developer

        Easy wins

        • Make all text links have an underline on hover
        • Make hover states on buttons more noticeable
        • Make sure all buttons turn darker on focus
        • Make hollow buttons match colors of filled buttons
        • Add blue border to buttons on focus

        Needs more thoughts

        • Text links that turn blue on hover vs. text links that do not have a color on hover
        • Hover states for navigation items that have no hover state
        • Basically everything in the "other buttons" section / @cperessini have you started on options for standardizing these? Would be happy to help, let me know where we are with that and if you need a second eye.
      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        @tauriedavis I want to get this in for 8.13 but there aren't any new developments since the last post, so feel free to jump in if you have the time :slight_smile:

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        I'll be working on it in the next few days so we can get it in.

      • username-removed-626804
        username-removed-626804 @pedroms ·
        Developer

        I totally agree with what everyone is saying here. Thank you a lot to @cperessini for making that inventory, it's very helpful.

        Thanks to @tauriedavis for synthesizing and putting some clear actionable items on the table. I'd add to your “Easy wins” list: change all gray buttons to white so they don't look disabled.

        Text links that turn blue on hover vs. text links that do not have a color on hover

        I'm very interested in discussing this. I think there are three types of links: primary, secondary and implicit.

        1. Primary links are the blue ones that underline on hover. Ideally, all links should mimic this pattern. Unfortunately, this would create a visually complex UI. So, we use this style for the most important ones, the ones we really want to highlight and draw attention to.
        2. Secondary links are less highlighted, mainly because of their function and context (e.g. “Edit” links on the sidebar, commit message links on the files view).
        3. Implicit links communicate their function through their placement, aligning with patterns that users have already learned (e.g. navigation, lists, footer).

        I'm mostly interested in the secondary links because they are not accessible today (they just don't look like links). From the top of my head, I see two approaches to solving this: either make them smaller and uppercase (like Material Design does for every action/button) or apply a subtle underline.

        Smaller and uppercase: I made a proposal in this comment. I guess it's more difficult for this to scale and be adapted to other contexts (e.g. commit message links on the files view).

        Subtle underline: Screen_Shot_2016-10-14_at_12.33.41

        Just wanted to get this out :smile:

      • username-removed-711361
        username-removed-711361 @awhildy ·
        Contributor

        Do we already have general guidance on when to use a button vs. when to use a link? I've seen some issues come up recently that are pushing to turn some links into buttons. While we all probably have a general gut feel for these things, I'm just wondering if there has been specific discussion about it. Thanks!

      • Taurie Davis
        Taurie Davis @tauriedavis ·
        Author Developer

        @awhildy I haven't seen any discussion surrounding when to use buttons styles vs link. There also isn't anything in the ui guide.

      • username-removed-626804
        username-removed-626804 @pedroms ·
        Developer

        @awhildy I guess it a lot of it depends on the context and the task at hand. Is the action (submit/navigation/trigger) very important for the users to accomplish the goal? If so, most likely it should look like a button. If not, maybe it could be styled as a link. I haven't come across a definitive set of guidelines that makes this a “black and white” decision — if you have, please share! :wink:

      • username-removed-711361
        username-removed-711361 @awhildy ·
        Contributor

        Very good points, @pedroms. I don't think there is ever going to be a comprehensive guide, but I do think it can be helpful to document some of our thoughts like the ones you have suggested. I'm working on pulling all of these kind of thoughts together to help build out more of our UI/UX style guide, and I suspect the conversation can continue there once I have built out more of the skeleton of it. Thanks much! I'll let you know if I ever stumble upon more definitive guidelines :wink:

      • username-removed-626804
        username-removed-626804 @pedroms ·
        Developer

        @awhildy Great, I'm looking forward to discussing these things in detail :thumbsup:

      • username-removed-711361 Mentioned in issue awhildy/pattern-library#31 (closed)

        Mentioned in issue awhildy/pattern-library#31 (closed)

      • username-removed-711361 Milestone changed to %8.14

        Milestone changed to %8.14

      • username-removed-711361 Mentioned in issue #23698 (closed)

        Mentioned in issue #23698 (closed)

      • username-removed-711361
        username-removed-711361 @awhildy ·
        Contributor

        In looking at #23698 (closed), I don't feel like our tab focus on buttons is clear and obvious enough. When I tab through UI such as the login form, the darkening of the button is very subtle and easy to miss. If I miss it, it isn't clear where the keyboard focus is. Thoughts on how we can address this? Thanks!

      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        This is a good candidate for ux meetup discussion ;)

      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        @awhildy shouldn't the focus everywhere be the blue halo.. even on green buttons etc

      • username-removed-626804
        username-removed-626804 @pedroms ·
        Developer

        @awhildy I agree. Either we come up with a different style or fallback to the original Bootstrap focus style (blue glow).

        @dimitrieh Good idea, I'll put it on the next weekly call agenda.

      • Dimitrie Hoekstra
        Dimitrie Hoekstra @dimitrieh ·
        Developer

        Just an extra idea here for the focus part of our anchors styling etc instead of going with the default bootstrap fading out halo, we could go with a flatter option like google material, where I got the idea from.

        image

        I don't say we should copy this style, but rather take some cues from it like so:

        image

        image

        or perhaps make it even color dependent :star2:

        image

        add to this micro animations, although this may be to much :smile: (didn't create an actual prototype, but to illustrate the movement ;) )

        2016-10-27_12.49.09

      • Annabel Gray Mentioned in issue #21302 (moved)

        Mentioned in issue #21302 (moved)

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        I created two meta issues so we can organize everything that we discussed on this issue and start taking action.

        #24062 (moved): [meta] Review text link styling throughout GitLab

        #24063 (moved): [meta] Review button styling throughout GitLab

        I didn't include tasks for the more complex ideas like the ones from @dimitrieh's last comment as I think we should focus on smaller stuff for now and leave those changes for when we act on #22192 (closed)

        Edited by Chris Peressini
      • Taurie Davis
        Taurie Davis @tauriedavis ·
        Author Developer

        Thanks @cperessini! This is a great step towards getting these implemented! :sparkles: Will there be sub issues for the task items?

        Edited by Taurie Davis
      • Dimitrie Hoekstra Mentioned in issue #24062 (moved)

        Mentioned in issue #24062 (moved)

      • Chris Peressini
        Chris Peressini @cperessini ·
        Developer

        @tauriedavis Yes, there will be sub issues, just didn't get around to creating them yet!

      • Chris Peressini Mentioned in issue #24129 (moved)

        Mentioned in issue #24129 (moved)

      • Chris Peressini Mentioned in issue #24146 (closed)

        Mentioned in issue #24146 (closed)

      • username-removed-711361 Milestone changed to %Backlog

        Milestone changed to %Backlog

      • username-removed-408881 Mentioned in merge request !7347 (merged)

        Mentioned in merge request !7347 (merged)

      • Chris Peressini Assignee removed

        Assignee removed

      • Felipe Artur moved to gitlab#5921

        moved to gitlab#5921

      • Felipe Artur
        Felipe Artur @felipe_artur ·
        Maintainer

        Hey! :wave:

        GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

        If you have any questions about all of this, please ask them in our dedicated FAQ issue.

        https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

        You can also find more information here:

        Frequently Asked Questions

        For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

        What will we do with the repository names?

        https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

        Why rename gitlab-ce to gitlab-foss?

        Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

        I created a merge requests for CE, and this got closed. What do I need to do?

        You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

        How does the licensing work in this new setup?

        Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

        Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

        No. Merge requests submitted to this project will be closed automatically.

        Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

        Yes.

        How will this affect users of GitLab CE using Omnibus?

        No changes will be necessary, as the packages built remain the same.

        How will this affect users of GitLab CE that build from source?

        Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

        Where can I see a timeline of the remaining steps?

        https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

        Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

        Yes, these changes will be synced to gitlab-foss automatically, several times per day.

      • Felipe Artur locked this issue

        locked this issue

      • Felipe Artur mentioned in issue gitlab#6867

        mentioned in issue gitlab#6867

      Please register or sign in to reply