Should we convert from FA4 icons to FA5 icons?

[samreid]

From #81, I'd like to compare the FA5 icons to FA4. If FA5 icons are equally good or better, it would simplify our project to eliminate the FA4 approach. The first step will be to show a before/after comparing each icon. If the changes are nontrivial, then we will need to ask for designer recommendation. If we need to keep any of the FA4 icons, let's consider wrapping them in an approach like the FA5 approach, for simplicity.

[samreid]

I ran a quick (not exhaustive) search to find Font Awesome 5 icons that seemed like a close match (in name at least) to Font Awesome 4, here is the result. Leftmost column is font awesome 4. Columns to the right are options from Font Awesome 5.

For the ones with missing icons, I suspect there are alternatives, but perhaps they have different names. I'm seeing some icons that don't seem as nice in the Font Awesome 5, such as the scissors and the checkmark in the box (but I have recollection that we manually edited something about the checkmark in the box). If we have to keep around the Font Awesome 4 infrastructure, there may be diminishing returns on moving individual occurrences to 5. Still, it seem worth running past a designer to see if we want to choose any of the Font Awesome 5 icons to replace the Font Awesome 4 icons.

@arouinfar can you please take a look and make recommendations?

[arouinfar]

For the ones with missing icons, I suspect there are alternatives, but perhaps they have different names

That certainly seems like the case. Here are a few examples:

• edit :
  
• exclamation-triangle:
  
• sync-alt:
  

I'm seeing some icons that don't seem as nice in the Font Awesome 5, such as the scissors and the checkmark in the box (but I have recollection that we manually edited something about the checkmark in the box).

In general, I prefer Font Awesome 5 and would be fine with it being propagated to all sims. The only exception would be for the checkboxes, so it would be good to know if we are using Font Awesome or something different for that.

The older scissors do look nice, but the newer scissors are more consistent with other icons. The scissors alone are not enough reason to keep Font Awesome 4 around, in my opinion.

[samreid]

In the commit, I converted Blackbody Spectrum from Font Awesome 4 to Font Awesome 5. The main change was transforming the old code:

content: new FontAwesomeNode( 'camera', { maxWidth: BUTTON_ICON_WIDTH } ),

to the new code:

content: new Camera( { maxWidth: BUTTON_ICON_WIDTH, fill: 'black' } ),

There are 3 other occurrences of camera:

• Equality Explorer
• Graphing Quadratics
• Models of the Hydrogen Atom

Once those are converted, we can remove the camera data from sherpa/js/fontawesome-4/FontAwesomeIcons4_5.js

Adding to developer meeting to review this problem, and determine how to proceed. Should it be a chip away issue? Should each developer address their own sims, or should a central person make most of the changes and assign to responsible devs for review only?

[zepumph]

@samreid will create side issues on the conversion.

@samreid mentioned that specifying a maxWidth based on the current width would be a good general way to convert.

[zepumph]

This issue can be closed when all side issues for conversion have created.

[samreid]

There are 70 usages of FontAwesomeNode across 26 repos (one is an extend, the others are new FontAwesomeNode). There are only 28 FA_4_5 icons. So am I about to open 26 new issues? Maybe I should try converting one or two first to see if one person can just do them all and avoid the hassle of 26 new issues. But even if I do the conversions, would we want an issue anyways for the responsible developer to review?

UPDATE: What about one issue per responsible dev? And let's go one-by-one so we can iron out problems as we go instead of everyone running into the same problems at the same time. Perhaps I should start, then send it over to someone else.

Here's a quick list, which was easy to generate since responsible devs is machine-readable since https://github.com/phetsims/special-ops/issues/185. I should also mention that it was very convenient to have everything in one file.

@samreid
circuit-construction-kit-black-box-study
circuit-construction-kit-common

@jessegreenberg

• energy-skate-park

@jbphet

• expression-exchange (see Update to newer font-awesome icons expression-exchange#154)
• projectile-motion
• sun

@pixelzoom

• balancing-chemical-equations
• equality-explorer
• fourier-making-waves
• function-builder
• graphing-lines
• graphing-quadratics
• models-of-the-hydrogen-atom
• natural-selection
• reactants-products-and-leftovers
• scenery-phet
• unit-rates
• vector-addition

@jonathanolson
area-model-common
build-a-molecule
collision-lab
mobius
proportion-playground
scenery

@zepumph
joist (see phetsims/joist#707)
ratio-and-proportion ( phetsims/ratio-and-proportion#379)

[zepumph]

I only had two, so I just created my own issues in my own repos.

[pixelzoom]

Before we start converting, several "code review" things:

• Many (most?) of the class names under sherpa/fontawesome-5/ don't follow PhET naming convention. They are view components (Nodes) but look like model names. For example Camera (the example that @samreid used above) doesn't particularly look like a "view" name, I would expect CameraNode. I'm not suggesting that these names necessarily need to change (though that would be my preference). We could also just acknowledge that something different (and therefore potentially confusing) has been done with naming these classes. And if everyone is OK with that, move on.

• Making each FANode subclass define PATH_DATA and SHAPE seems unnecessary, and unenforceable. Why not implement FANode like this? :

class FANode extends Path {

  /**
   * @param {string} svgPath
   * @param {Object} [options]
   */
  constructor( svgPath, options ) {
    assert && assert( typeof svgPathData === 'string' );
    
    const shape = new Shape( svgPath );
    super( shape, options );
    
    // @public (read-only)
    this.svgPath = svgPath;
    this.shape = shape;
  }
}

Subclasses would look like:

const SVG_PATH = '...';

class Camera extends FANode {

  /**
   * @param {Object} [options}
   */
  constructor( options ) {
    super( SVG_PATH, options );
  }
}

export default Camera;

• With the above implementation change, consider renaming FANode to SVGPathNode. Because there's nothing here that's specific to FA, and it can be used with any SVG path. (This also make FANode useful - it's current implementation is somewhat useless, serving only as a place to park documentation.)

If you choose not to make the above changes:

• In each FANode subclass, PATH_DATA and SHAPE are missing visibility annotations.

• The requirement that each FANode subclass has PATH_DATA and SHAPE is not enforced, and not even described or documented (that I could find).

• PATH_DATA is poorly named. It's not data passed to Path, it's the SVG path passed to Shape (see Shape.js for terminology). Recommended to rename to SVG_PATH.

• FA is all about rendering an SVG path. It's unacceptable that "SVG" and "svg" appear only once in the entire implementation, and it's in modulifyFontAwesomeIcons.js.

• By choosing to "Export the raw path data in case more complex usage is necessary" by using statics like PATH_DATA and SHAPE, you risk something changing that data and affecting all instances of a FANode subclass.

Assigning to @samreid for response.

[pixelzoom]

4/22/21 dev meeting:

@samreid hasn't had a chance to review my feedback. Porting to FA5 is on hold.

[samreid]

I’d also like the name to reflect the style, so that there are no collisions if importing regular/AddressBook and solid/AddressBook. How should we name them? Some possibilities:

• RegularAddressBookNode / SolidAddressBookNode
• RegularAddressBookFANode / SolidAddressBookFANode
• FontAwesomeRegularAddressBookNode / FontAwesomeSolidAddressBookNode
  etc.

What do you recommend?

[samreid]

The migration is going really well. There are a few occurrences left. @jonathanolson can you please do the remaining joist ones? I wasn't sure how to test them easily.

• expression exchange @jbphet
• geometric optics @veillette
• joist @jonathanolson
• projectile-motion @jbphet

After these are done, please reassign to @samreid to delete FontAwesomeNode, font-awesome-4-5.html and FontAwesomeIcons4_5.js. We will need to keep checkEmptySolidShape.js and checkSquareOSolidShape.js for now since it is used by checkboxes.

[veillette]

I have handled the case for geometric optics.

[jbphet]

I've taken care of expression-exchange and projectile-motion. I left "sun" unchecked above because I'm not sure what we're going to do about the checkboxes. @samreid said above:

We will need to keep checkEmptySolidShape.js and checkSquareOSolidShape.js for now since it is used by checkboxes.

Have we looked at squareRegularShape and checkSquareRegularShape and ruled them out?

[zepumph]

I completed phetsims/joist#707, and just did a global search for FontAwesomeNode. The only spot left besides minor doc updates is:

https://github.com/phetsims/circuit-construction-kit-common/blob/988610bb9ec03677fbef2436758fab095f05bdef/js/view/ReverseBatteryButton.js#L44-L55

• @samreid can you take a look and see if those hard coded strings need any work?
• I believe that we can delete FontAwesomeNode at this time.

[samreid]

Thanks to everyone for pulling together on this issue. I've removed FontAwesomeNode and its icons. The last thing is about the checkboxes which will be decided in #84. sherpa/font-awesome-4 looks like it has many usages in website things, so it cannot be deleted at this time. Closing.