FreeUKGen / Systemwide

repository for issues that affect all systems within the Free UK Gen portfolio
0 stars 0 forks source link

Investigate and recommend how to implement a change of font on websites #64

Closed Captainkirkdawson closed 4 years ago

Captainkirkdawson commented 5 years ago

In story systemwide 40 the Trustees approved the change in font from Source Sans Pro 'Light' to 'Regular' on websites. This story intends to investigate how to proceed with minimal breakage to the websites.

Captainkirkdawson commented 5 years ago

Our brand face is defined in app\assets\stylesheets\FreeUKGenealogy-Core-Frontend\styles\scss_vars.scss: $brand-face: "Source Sans Pro", "Helvetica Neue", Helvetica, Arial, sans-serif; There are a number of variations of Source Sans Pro varied by font-weight or font-style.

// Source Sans Pro Bold 700 6 @font-face { 7: font-family: "Source Sans Pro"; 8 font-weight: bold; 9 font-style: normal; .. 16 } 17
18: // Source Sans Pro Normal 400 19 @font-face { 20: font-family: "Source Sans Pro"; 21 font-weight: normal; 22 font-style: normal; .. 29 } 30
31: // Source Sans Pro Normal 400 Italic 32 @font-face { 33: font-family: "Source Sans Pro"; 34 font-weight: normal; 35 font-style: italic; .. 42 } 43
44: // Source Sans Pro Light 300 45 @font-face { 46: font-family: "Source Sans Pro"; 47 font-weight: lighter; 48 font-style: normal;

The font-weight is defined in many different places in the styles and code depending upon the desire at that point.

In summary: We use Source Sans Pro. We do USE normal (Regular) unless specified elsewhere. We lighten or bolden where needed according to need and design layout. There appears to be NO General setting of font-weight: lighter in our apps.

So bottom line is we already use Source Sans Pro Regular!!!!!!!!!!!!!!!

@richpomfret @PatReynolds I can demonstrate this if you want to see it BEFORE I vanish

Captainkirkdawson commented 5 years ago

Deeply puzzled In email @PatReynolds wrote FWIW, I am proposing that we use Regular _only_ on the FreeUKGen site, and NOT on any multi-modal site until there has been a thorough review of ways of solving the issue of visibility, with the costs of implementation of solutions (in resource time, etc.) before making the decision to do that. The research is not a high priority at the moment. Yet we have on freebmd Use 'Regular' version of Source Sans Pro font#93 Backlog with latest comment We will need to do this sooner rather than later and lead on BMD2. At previous freebmd scrum I had been asked and assigned the task Can basic font be set by application in multimodal? On freereg Implement Source Sans Pro Regular as basic font#2019 Incoming On freecen Implement Source Sans Pro Regular as basic font#731 Incoming Based on posted conclusions above all these stories should be closed. Perhaps a new story , if one does not exist in accessibility along the line of thorough review of ways of solving the issue of visibility At this point stories about implementing Regular' version of Source Sans Pro are wild goose solutions

PatReynolds commented 5 years ago

Systemwide #90 opened 9 days ago (?at FreeBMD2 meeting?? - FreeBMD2#93 is in backlog and Phase 2. I don't understand @richpomfret comment of 16 Spt - a meeting I could not attend). Maybe added to the wrong story?

Captainkirkdawson commented 5 years ago

Summary following discussion with @PatReynolds and @Vino-S

  1. It is possible to make the selection of font application dependant with a small number of changes.
  2. All three apps currently use Source Sans Pro as their main font.
  3. There are multiple sources for Source Sans Pro. Google, Adobe, uncle Tom Cobley and all ie 100+ versions
  4. We are using the versions provided by the original designers.
  5. They provided us with bold, normal (regular), light and italic (font-weight: and font-style)
  6. The specific version used is the last version specified in the CSS ie. there are multiple levels of definition. The last loaded CSS definition is used.
  7. Different fonts occupy different space on the screen. Hence a change in font can change layout in forms and tables
  8. The font-color specified in the apps is #444.
  9. Accessibility is determined by both colour and font. Both need to be considered at the SAME time.
  10. @Vino-S noted that the lighter font is specified to be used in headers, footers and some parts of tables and forms
  11. While we have both normal and lighter fonts they both appear to be the same in the text of a form even though the developer tools show that the initial html font specification has not been overridden. They both appear to be the lighter version. Hence do we have a bug in our code/assets?
  12. MVP for FreeBMD2 should not attempt to solve the accessibility issue.
Captainkirkdawson commented 5 years ago

@richpomfret @PatReynolds @Vino-S At this point I am convinced there is an issue with the font we are loading. The following are 3 screen shots a) is font-weight: normal font-style: normal normal normal.JPG b) is font-weight: lighter font-style: normal lighter normal.JPG c) lastly font-weight: normal font-style: italic normal italic.JPG

There is NO DIFFERENCE between a) and b) Clearly c) is different in 2 aspects style and weight Hence my conclusion that we have a problem with the font we are using as normal normal. It is not and it is nothing to do with our css or use of css

Captainkirkdawson commented 5 years ago

@richpomfret @PatReynolds @Vino-S The designers originally used fonts from Foundry we requested that they use an open source. So they switched to Open Sans Pro https://github.com/FreeUKGen/Core-Frontend The versions we are using today are those versions they provided 5 years ago. Our expertise back then was minimal

Captainkirkdawson commented 5 years ago

@PatReynolds @richpomfret @Vino-S We have been using the fonts and font delivery mechanisms provided to us by the system layout designers over 6 years ago. They were not ruby/rails experts and neither were we at that time. Since then we have not touched that code. Well a great deal has changed in the way in which fonts can be delivered and it is clear that much of what we were doing went against the evolving standards and recommended approaches.

So rather than try to manipulate and tweak what we were given I said how would we deliver a Source Sans Pro font today. Well the easiest way is to adopt the google font delivery approach with the Source Sans Pro font. ie no change to the basic font but using a different approach that eliminates our own delivery of fonts and simplifies our code base and gets use away from issues with rails assets pipelines.

So to cut to the chase test3 for both cen and reg are running a branch that uses that approach. There remain a number of CSS refinements to be made but the basic applications are running. Would you please take a moment to look at the websites and see it we are on the right track.

It is important that you use a clean set up to run these test sites. The BEST approach is to open an INCOGNITO window in Chrome; PRIVATE window in Firefox and PRIVATE BROWSING in Safari.

Captainkirkdawson commented 5 years ago

Sample difference screen shots Old search seach old.JPG New searchsearch new.JPG old results result old.JPG new results result new.JPG old login login old.JPG new login login new.JPG old landing page landing page old.JPG new landing page landing page new.JPG

Captainkirkdawson commented 5 years ago

An audit of test3 by chrome lighthouse test3 audit.JPG

AlOneill commented 5 years ago

Very interesting. Text certainly looks bolder, and so easier to read. In identically-sized windows, the CEN Birth Place survey notice has the lines breaking in exactly the same place on t3 and live, i.e. width of text blocks appears unaffected by font change.

This is confirmed by comparing search results tables. I am surprised. This is very encouraging!

Captainkirkdawson commented 5 years ago

@AlOneill this setup uses a font-style of normal with a font-weight of 200 for light and 400 for regular or normal The font-weights of 600 semi bold and 700 bold do line break in different places. Hence do not anticipate an issue between use of 200/400. We could have used 300 for lighter. Then the differences are more subtle

richpomfret commented 5 years ago

Indeed, I echo that is very encouraging indeed! TY @Captainkirkdawson for reviewing this in-depth and discovering how we previously implemented the fonts (the history is fascinating too). I've placed this 'in test' over on FC for now, although if there are further tweaks and updates then perhaps we can now created new stories based on our new understanding.

Captainkirkdawson commented 5 years ago

@PatReynolds @richpomfret @AlOneill @DeniseColbert Which font weight should we use for lighter and bold? The one most people use is 300 or we can use a lighter one at 200. Currently I deployed 200 on the test3's but the change is trivial to make. We do not want both 200 and 300, time for initial loading of a page increases with each font in an app. The recommendation is 4 fonts; italic(normal), normal (400), bold (700 or 600), lighter(300 or 200) 400 or normal is 400.JPG 300 is 300.JPG and 200 is 200.JPG Going the other way 600 is 600.JPG and the usual 700 is 700.JPG

My personal preference is to use 300 as light the 200 version is just too light and 600 as bold it seems less strident than 700 yet is clearly bolder than 400.

PatReynolds commented 5 years ago

Agreed: 400, lighter =300, bolder =600

richpomfret commented 5 years ago

I think we're all in agreement with you @Captainkirkdawson with your suggestions.

PatReynolds commented 5 years ago

Need examples of italic. Normal is to be as suggested, =400, light = 300, bold = 600.

Captainkirkdawson commented 5 years ago

@PatReynolds italic is italic.JPG

AlOneill commented 5 years ago

Proposed italic (emphasis) looks to be relatively lighter, but perhaps that is inevitable.