Site-wide Link Design Update (Aug-2020)

[nelsonni]

The default web design standard for links is that they be shown as blue text, which becomes a darker blue and underlined on hover (to suggest that mouse actions such as clicking are possible on that text). The Nielsen Norman Group (of Nielsen's 10 Usability Heuristics fame) has a good article, "Guidelines for Visualizing Links", that discusses design best practices for links.

There are currently several different link visualization designs being used throughout the EPICLab.github.io site, including:

• Button links that change text color when the mouse is hovered.
  

• External links that adhere to the default blue text that changes color and underlined on hover.

• Document links that do not indicate clickability until you hover, at which point a link icon appears.

We need to develop a unified standard for how we visually communicate links throughout the website. This issue is an expansion of some discussion found in #26.

[audreyau]

Do we plan to add individual pages for all the news articles? If not, I will take away the links...

so that it looks less misleading. However, the normal font for the news heading makes it seem trivial so...

I think we should make them bold.

Haha I understand the article you sent now. It's confusing to know what is a link when the EPICLab site has inconsistent link formatting. I think having links in blue would be the most obvious to users, but it makes the site seem too conventional. They would also make the Publications Page very hard to read due to the abundance of links.

I looked at the STRUDEL Lab's website, and they made their links in red. When a user hovers over a link, the red color becomes slightly more saturated. I like how that design goes along with their website aesthetics and how it doesn't involve bold text, which can then be used for key points and big ideas.

Amy X. Zhang's website has the links in bold. For her website design, it works well, and when a user hovers over the links, they turn a bright yellow, indicating an obvious link. However, since the publication titles are in bold, I thought they'd have links too, which they didn't. So bold links might be misleading.

For our People Page, the links are quite confusing since all the people have their names in bold, but only certain names have links. However, if we were to make the names with links in different colors, I think that would be even worse since the design would be very inconsistent.

Underlined links are nice, but they might be too messy. Should we just do a mix of all of them?

[nelsonni]

I would like to have a single design for all links (which are defined by <a href=""> tags in HTML), such that we can defined this design in CSS in similar fashion to this:

a:link {
  color: #547599;
  text-decoration: none;
  cursor: auto;
}

a:hover {
  color: #547599;
  text-decoration: underline;
}

a:visited {
  color: inherit;
  text-decoration: underline;
}

As reference, the CSS Default Values Reference. Although that W3School site doesn't include actual values for those CSS defaults, it does indicate which fields are set. And at least in Firefox, the default link color is #0056b3 (I updated my example above to a color that is closer to the color palette of the rest of the EPICLab website).

[audreyau]

I've removed the link icon that pops up for publications/people and created the CSS code, but for some reason, the links don't change color. They remain black. Also, later on, should we label the publications that have won awards?

[nelsonni]

It would be easier to diagnose the indicated problem if you commit your changes to the changes branch and push it up to GitHub, because I could pull your code down and directly examine it. There are two changes that need to happen for removing the popup icons that appear on hover next to a link:

1. Remove the following CSS rules from full-width-pics.css:

   .name-box .site-link #popup {
     font-weight: bold;
     font-size: 18px;
     color:white;
   }
   
   .name-box .site-link:hover #popup {
     font-weight: bold;
     font-size: 18px;
     color: black;
   }
   
   .name-box .site-link:hover {
     color: black;
     font-weight: bold;
     font-size: 1rem;  
     line-height: 1.5;
   }

2. Remove all instances of the following from both publications.html and people.html:

   <i class="fas fa-link" ID="popup"></i>

The property that is directly setting the link text to be black is color rule on full-width-pics.css#L452:

   .site-link {
     font-size: 1rem; 
     font-weight: bold; 
     line-height: 1.5;
     color: black;
   }

I think adding something to signify awards would be appropriate, but not as part of this issue. If you want to suggest it in a new issue, we can discuss how to design such a feature.

[audreyau]

I've committed my changes and tried to do all the changes you sent, but the links still remain black. Do I need to make a separate class for them?

[nelsonni]

I looked into the code and figured out the problem. The following CSS rule in full-width-pics.css was supposed to allow the text color to be inherited from the a:link (color: #547599;), but was actually inheriting from body (color: #212529;):

a:visited {
   color: inherit;
   ...
}

I pushed d22c4c6 to resolve the issue.

[audreyau]

Awesome! It works great! Do we want to keep all links blue? Even the publication names and names of people?
Also, the visited links don't seem to change colors.

[nelsonni]

Since both a:link and a:visited share the same color, there won't be any visible difference between which of those CSS states are active at any given time. We could change that, but I think it's a worthy simplification since we're allowing titles (for people, publications, and research areas) to be links. I doubt anyone wants to visually manage which links they have (or have not) visited as they explore the website.

I think we can go ahead and use this current color palette for now. Perhaps later on we can do an accessibility evaluation to determine whether this coloring is appropriate for color-blindness and/or screen-readers, but for now it appears to work.

[audreyau]

Sounds good! I won't send out a pull request yet because it would include the research pages, which aren't ready yet. For Usable Privacy & Security, I couldn't find any publications, so should I just leave the list blank?

[nelsonni]

There are publications for the Usable Privacy & Security research area, and one of them is actually a VL/HCC 2017 short paper:

Kaaz, K.J., Hoffer, A., Saeidi, M., Sarma, A. and Bobba, R.B., 2017, October. Understanding user perceptions of privacy, and configuration challenges in home automation. In 2017 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) (pp. 297-301). IEEE.

I'll have to ask Mahsa for any additional papers in that area. She will also be the point person for providing a description of that research area.

[nelsonni]

I'm not recommending it, since it's not a simple process. But there is a way of creating a new branch (based off of your changes branch) and either using git squash techniques or git cherry-pick to revise the history of commits to only include those commits that relate to the link redesign. But for now, just include those changes in the same PR that you submit for #26.

[audreyau]

git squash didn't work for the commits I created. I'll probably just create a single PR for both issues #26 and #27. If I git cherry-pick the commits for the site-wide links and create a PR for them before making a PR for the research pages, I'm scared that the research page PR will overwrite the site-wide link changes.

[nelsonni]

Like I said, there is a bit more of a learning curve than we really need to tackle right now. So go with the combined PR.