Font Icon discussion continued

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Font Icon discussion continued

Justin Obara-3
At this weeks community meeting we had a follow up discussion about our research into font icons. I'll summarize, below, but our research is also being collected on the wiki. 


Please feel free to continue this thread by adding in new information, questions, and correcting any mistakes I may have made.

Thanks
Justin


Overview:
========

Pros:
  • Scalable (size, hi-dip screens)
  • Can modify with CSS (colour, shadows, etc.)

Cons:
  • Mono-tone
  • IE8 and IE9 do not support ligatures
  • Globally changing fonts could replace/remove icons
  • Adding/Modifying fonts not trivial, will likely need to rebuild the font family



Digging Into the issues:
==================

Mono-tone: 

Arash did some research into this. At the moment we are limited to mono-tone fonts; however he used some methods to create the appearance of gradient like effects through varying sized dots and/or lines. Another suggestion that came up during the meeting is to layer multiple font icons on top of each other to provide a richer presentation. Johnny provided an example of this http://conor.cc/posts/icon-stacks


Globally changing fonts:

Probably more of something to just be aware of and careful about when making changes. We were able to work around this in our UIO demo sprint through !important and specificity.


Adding/Modifying fonts:

We probably need to talk about this point some more, and how we will be breaking up fonts into families and etc. 


File sizes:

The more complex the icon the larger the size. In typical fonts individual characters are usually less that 1KB and the whole family around 100KB. Our font-icons are usually less that 5KB each. 


Ligature Support:

IE 8 and IE 9 don't visibly display ligatures, however the text itself is accessible. What this means is that it will not be rendered onto the screen, but an AT (assistive technology) would be able to read it.


Ligature vs PUA:

There are three basic methods for creating a font icon.

  • assign the icon to a common unicode character
  • assign the icon to a PUA (private use area) unicode character
  • assign the icon to a ligature (string of unicode characters)

PUA referes to the block of unicode characters reserved for 3rd party use. For example, Apple uses F8FF for their logo "".


In our testing we've found that font icons built on top of PUA characters are not read by an AT. This is probably because there is no real representation that they could use for it. 

***Note: the obstacle course used for testing had an issue with displaying PUA font icons in IE8. They typically work in IE8 and may be a result of the method used to dynamically inject them into the test***

Ligatures and common unicode characters like "a" do get read by screen readers. Since ligatures are created off of a strings of text, they become tightly coupled with it. Making things like localization difficult. Furthermore, they only seem to support a single word and not phrases. 

There are four basic issues with ligatures.

  • hard to localize
  • may need more than a single word to describe the icon
  • multipurpose icons may need a different description in different contexts
    • e.g. undo / reset / back
  • browser support (i.e. IE 8 and IE 9)


Accessibility:

The benefit here is the scalability and possibility to easily modify colours (for contrasts). However, there are questions about their interpretation by screen readers. We have both the issue of needing to provide less information and provide more. When the font icons are used in a purely presentational aspect, we wouldn't want the AT interpreting it for a user. On the converse, when they do hold meaningful information, we want to make sure that the AT is provided with a complete description. With ligatures we were finding that both of these cases could fail. The AT will read the text value, even in cases where it was for presentation only, and sometimes the ligature itself did not hold enough detail to describe the full meaning of the font icon.

We have been and continue to explore options for providing richer text alternatives. For example using things like aria-label, or encompassing the font icon with other text in a <label>. We can also make use of PUA based font-icons to avoid ligatures being read.


Further Discussion Points:
=====================

  • Continue researching and experimenting with text alternatives for the font icons
  • Continue investigating issues from the test around PUA's in IE8
  • Think about how we'll assemble and share font icons between components
  • Research the use of svg icons vs font icons
    • What are the download file size implications of representing "the same" icon as a SVG or font icon?
    • Emeddability/stackability - is it as easy to composite multiple different "icons" as SVG or font icons?
    • How does the use of SVG interact with ATs - are there special issues relating to focus, announcement by screenreader, etc?
    • Performance implications, especially on mobile devices - these are sensitive both to download costs as well as CPU costs during rendering - are either or both approaches viable on a low-capability smartphone?
    • Visual fidelity - does a page containing SVG elements appear "solid" as it is zoomed, or does the SVG content appear to "lag" the main page in rendering?


Current thoughts:
=============

When to use:

We had a good discussion in the channel today about font icons vs svg and also came up with a good summary of when you'd want to use a font icon. 

I imagine we're basically saying "Icon fonts are useful for relatively simple images that can be viably represented using one colour (or a few if we find that the stacking technique works) and which likely need to be highly responsive to resolution, size, and colour thumbing changes on the fly."

And "For complex images, icon fonts are not likely appropriate. The use of SVG or multiple resolution-optimized raster images is preferred in these cases."



How to use:

At yesterdays meeting, my recommendation on how we should approach using font icons was as follows.

  • Use PUA font icons, to avoid the various issues with ligatures
  • Provide a text alternative for non-presentational uses of font icons
    • use something like aria-label and etc.
  • Use class names as opposed to the data- attribute for adding the fonts
    • it will be hard to know what you are adding with the data attribute, particularly for PUA font icons
  • Font families for font icons should be applied as tightly as possible to the element which will hold it. Where possible, we should avoid mixing regular, non-icon characters with the ones which have icon representations.
    • good
      • <span class="addFont"> font icon </span>
    • bad
      • <div class="addFont> <span>font icon</span> other text </div>







_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Justin Obara-3
We've spent some time looking into the option of using SVG's. The results of this research can also be seen on the wiki.

Quick Summary:
  • As much as 10x the size of font icons
  • can handle complex graphics including multiple colours and opacities
  • no native IE8 support
  • can only modify colours with css if svg markup included in the page (not used as an <img> or background-image)



Formal Proposal Regarding Font Icons:
==============================

We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.

For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.


Guideline for using Font Icons:

  • Use PUA font icons
  • Provide a text alternatives for non-presentational uses
  • Add through CSS using classes
  • Apply the class to add the font icon to an element that will only contain the font icon
    • e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.



Please let us know what you think about this proposal and if you have any more questions or concerns.

Thanks
Justin



On 2013-04-18, at 3:17 PM, Justin Obara <[hidden email]> wrote:

At this weeks community meeting we had a follow up discussion about our research into font icons. I'll summarize, below, but our research is also being collected on the wiki. 


Please feel free to continue this thread by adding in new information, questions, and correcting any mistakes I may have made.

Thanks
Justin


Overview:
========

Pros:
  • Scalable (size, hi-dip screens)
  • Can modify with CSS (colour, shadows, etc.)

Cons:
  • Mono-tone
  • IE8 and IE9 do not support ligatures
  • Globally changing fonts could replace/remove icons
  • Adding/Modifying fonts not trivial, will likely need to rebuild the font family



Digging Into the issues:
==================

Mono-tone: 

Arash did some research into this. At the moment we are limited to mono-tone fonts; however he used some methods to create the appearance of gradient like effects through varying sized dots and/or lines. Another suggestion that came up during the meeting is to layer multiple font icons on top of each other to provide a richer presentation. Johnny provided an example of this http://conor.cc/posts/icon-stacks


Globally changing fonts:

Probably more of something to just be aware of and careful about when making changes. We were able to work around this in our UIO demo sprint through !important and specificity.


Adding/Modifying fonts:

We probably need to talk about this point some more, and how we will be breaking up fonts into families and etc. 


File sizes:

The more complex the icon the larger the size. In typical fonts individual characters are usually less that 1KB and the whole family around 100KB. Our font-icons are usually less that 5KB each. 


Ligature Support:

IE 8 and IE 9 don't visibly display ligatures, however the text itself is accessible. What this means is that it will not be rendered onto the screen, but an AT (assistive technology) would be able to read it.


Ligature vs PUA:

There are three basic methods for creating a font icon.

  • assign the icon to a common unicode character
  • assign the icon to a PUA (private use area) unicode character
  • assign the icon to a ligature (string of unicode characters)

PUA referes to the block of unicode characters reserved for 3rd party use. For example, Apple uses F8FF for their logo "".


In our testing we've found that font icons built on top of PUA characters are not read by an AT. This is probably because there is no real representation that they could use for it. 

***Note: the obstacle course used for testing had an issue with displaying PUA font icons in IE8. They typically work in IE8 and may be a result of the method used to dynamically inject them into the test***

Ligatures and common unicode characters like "a" do get read by screen readers. Since ligatures are created off of a strings of text, they become tightly coupled with it. Making things like localization difficult. Furthermore, they only seem to support a single word and not phrases. 

There are four basic issues with ligatures.

  • hard to localize
  • may need more than a single word to describe the icon
  • multipurpose icons may need a different description in different contexts
    • e.g. undo / reset / back
  • browser support (i.e. IE 8 and IE 9)


Accessibility:

The benefit here is the scalability and possibility to easily modify colours (for contrasts). However, there are questions about their interpretation by screen readers. We have both the issue of needing to provide less information and provide more. When the font icons are used in a purely presentational aspect, we wouldn't want the AT interpreting it for a user. On the converse, when they do hold meaningful information, we want to make sure that the AT is provided with a complete description. With ligatures we were finding that both of these cases could fail. The AT will read the text value, even in cases where it was for presentation only, and sometimes the ligature itself did not hold enough detail to describe the full meaning of the font icon.

We have been and continue to explore options for providing richer text alternatives. For example using things like aria-label, or encompassing the font icon with other text in a <label>. We can also make use of PUA based font-icons to avoid ligatures being read.


Further Discussion Points:
=====================

  • Continue researching and experimenting with text alternatives for the font icons
  • Continue investigating issues from the test around PUA's in IE8
  • Think about how we'll assemble and share font icons between components
  • Research the use of svg icons vs font icons
    • What are the download file size implications of representing "the same" icon as a SVG or font icon?
    • Emeddability/stackability - is it as easy to composite multiple different "icons" as SVG or font icons?
    • How does the use of SVG interact with ATs - are there special issues relating to focus, announcement by screenreader, etc?
    • Performance implications, especially on mobile devices - these are sensitive both to download costs as well as CPU costs during rendering - are either or both approaches viable on a low-capability smartphone?
    • Visual fidelity - does a page containing SVG elements appear "solid" as it is zoomed, or does the SVG content appear to "lag" the main page in rendering?


Current thoughts:
=============

When to use:

We had a good discussion in the channel today about font icons vs svg and also came up with a good summary of when you'd want to use a font icon. 

I imagine we're basically saying "Icon fonts are useful for relatively simple images that can be viably represented using one colour (or a few if we find that the stacking technique works) and which likely need to be highly responsive to resolution, size, and colour thumbing changes on the fly."

And "For complex images, icon fonts are not likely appropriate. The use of SVG or multiple resolution-optimized raster images is preferred in these cases."



How to use:

At yesterdays meeting, my recommendation on how we should approach using font icons was as follows.

  • Use PUA font icons, to avoid the various issues with ligatures
  • Provide a text alternative for non-presentational uses of font icons
    • use something like aria-label and etc.
  • Use class names as opposed to the data- attribute for adding the fonts
    • it will be hard to know what you are adding with the data attribute, particularly for PUA font icons
  • Font families for font icons should be applied as tightly as possible to the element which will hold it. Where possible, we should avoid mixing regular, non-icon characters with the ones which have icon representations.
    • good
      • <span class="addFont"> font icon </span>
    • bad
      • <div class="addFont> <span>font icon</span> other text </div>








_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

colinbdclark
Hi Justin,

This is a helpful summary. Can you elaborate on the means by which we should all be providing text alternatives for font-based icons, just so I'm clear?

Colin

---
Colin Clark
http://fluidproject.org

On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:

> Formal Proposal Regarding Font Icons:
> ==============================
>
> We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.
>
> For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.
>
>
> Guideline for using Font Icons:
>
> • Use PUA font icons
> • Provide a text alternatives for non-presentational uses
> • Add through CSS using classes
> • Apply the class to add the font icon to an element that will only contain the font icon
> • e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.
>
>
>
> Please let us know what you think about this proposal and if you have any more questions or concerns.
>

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Valles, Heidi-2
hi Colin,

I'm looking into the best way of doing this. Will report back shortly!

best,
heidi



On 2013-04-23, at 12:28 PM, Colin Clark wrote:

Hi Justin,

This is a helpful summary. Can you elaborate on the means by which we should all be providing text alternatives for font-based icons, just so I'm clear?

Colin

---
Colin Clark
http://fluidproject.org

On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:

Formal Proposal Regarding Font Icons:
==============================

We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.

For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.


Guideline for using Font Icons:

• Use PUA font icons
• Provide a text alternatives for non-presentational uses
• Add through CSS using classes
• Apply the class to add the font icon to an element that will only contain the font icon
• e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.



Please let us know what you think about this proposal and if you have any more questions or concerns.


_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work


_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Valles, Heidi-2
hi!

I've tested some different ways of adding visually hidden descriptive text to a font icon. 

This seems to be the way to go:

            <div class="icon-music" aria-label="This is a music note" role="img"></div>

Works great with different screen readers/browsers. A little strange with NVDA in firefox - it wasn't reading the label until role="img" was added. Now it says "graphic, this is a music note" - perfect! VoiceOver says "this is a music note, image"

A more real-life example, for UI Options, might be:

            <div class="icon-indicator" aria-label="Arrow indicating current theme" role="img"></div>

best,
Heidi



On 2013-04-23, at 1:22 PM, Valles, Heidi wrote:

hi Colin,

I'm looking into the best way of doing this. Will report back shortly!

best,
heidi



On 2013-04-23, at 12:28 PM, Colin Clark wrote:

Hi Justin,

This is a helpful summary. Can you elaborate on the means by which we should all be providing text alternatives for font-based icons, just so I'm clear?

Colin

---
Colin Clark
http://fluidproject.org

On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:

Formal Proposal Regarding Font Icons:
==============================

We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.

For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.


Guideline for using Font Icons:

• Use PUA font icons
• Provide a text alternatives for non-presentational uses
• Add through CSS using classes
• Apply the class to add the font icon to an element that will only contain the font icon
• e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.



Please let us know what you think about this proposal and if you have any more questions or concerns.


_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work


_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

colinbdclark
This seems pretty sensible. Which ATs did you test with, out of curiosity?

Colin

---
Colin Clark
http://fluidproject.org

On 2013-04-25, at 4:11 PM, "Valles, Heidi" <[hidden email]> wrote:

> hi!
>
> I've tested some different ways of adding visually hidden descriptive text to a font icon.
> https://dl.dropboxusercontent.com/u/4345316/pua-test/pua-icons.html
>
> This seems to be the way to go:
>
>             <div class="icon-music" aria-label="This is a music note" role="img"></div>
>
> Works great with different screen readers/browsers. A little strange with NVDA in firefox - it wasn't reading the label until role="img" was added. Now it says "graphic, this is a music note" - perfect! VoiceOver says "this is a music note, image"
>
> A more real-life example, for UI Options, might be:
>
>             <div class="icon-indicator" aria-label="Arrow indicating current theme" role="img"></div>
>
> best,
> Heidi
>
>
>
> On 2013-04-23, at 1:22 PM, Valles, Heidi wrote:
>
>> hi Colin,
>>
>> I'm looking into the best way of doing this. Will report back shortly!
>>
>> best,
>> heidi
>>
>>
>>
>> On 2013-04-23, at 12:28 PM, Colin Clark wrote:
>>
>>> Hi Justin,
>>>
>>> This is a helpful summary. Can you elaborate on the means by which we should all be providing text alternatives for font-based icons, just so I'm clear?
>>>
>>> Colin
>>>
>>> ---
>>> Colin Clark
>>> http://fluidproject.org
>>>
>>> On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:
>>>
>>>> Formal Proposal Regarding Font Icons:
>>>> ==============================
>>>>
>>>> We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.
>>>>
>>>> For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.
>>>>
>>>>
>>>> Guideline for using Font Icons:
>>>>
>>>> • Use PUA font icons
>>>> • Provide a text alternatives for non-presentational uses
>>>> • Add through CSS using classes
>>>> • Apply the class to add the font icon to an element that will only contain the font icon
>>>> • e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.
>>>>
>>>>
>>>>
>>>> Please let us know what you think about this proposal and if you have any more questions or concerns.
>>>>
>>>
>>> _______________________________________________________
>>> fluid-work mailing list - [hidden email]
>>> To unsubscribe, change settings or access archives,
>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>
>> _______________________________________________________
>> fluid-work mailing list - [hidden email]
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
> _______________________________________________________
> fluid-work mailing list - [hidden email]
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Justin Obara-3
I think heidi tested with NVDA and VoiceOver. I tried it with Jaws 14 on Chrome, FF, IE 8, IE 9 and IE 10.

Thanks
Justin
On 2013-04-26, at 10:45 AM, Colin Clark <[hidden email]> wrote:

> This seems pretty sensible. Which ATs did you test with, out of curiosity?
>
> Colin
>
> ---
> Colin Clark
> http://fluidproject.org
>
> On 2013-04-25, at 4:11 PM, "Valles, Heidi" <[hidden email]> wrote:
>
>> hi!
>>
>> I've tested some different ways of adding visually hidden descriptive text to a font icon.
>> https://dl.dropboxusercontent.com/u/4345316/pua-test/pua-icons.html
>>
>> This seems to be the way to go:
>>
>>            <div class="icon-music" aria-label="This is a music note" role="img"></div>
>>
>> Works great with different screen readers/browsers. A little strange with NVDA in firefox - it wasn't reading the label until role="img" was added. Now it says "graphic, this is a music note" - perfect! VoiceOver says "this is a music note, image"
>>
>> A more real-life example, for UI Options, might be:
>>
>>            <div class="icon-indicator" aria-label="Arrow indicating current theme" role="img"></div>
>>
>> best,
>> Heidi
>>
>>
>>
>> On 2013-04-23, at 1:22 PM, Valles, Heidi wrote:
>>
>>> hi Colin,
>>>
>>> I'm looking into the best way of doing this. Will report back shortly!
>>>
>>> best,
>>> heidi
>>>
>>>
>>>
>>> On 2013-04-23, at 12:28 PM, Colin Clark wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> This is a helpful summary. Can you elaborate on the means by which we should all be providing text alternatives for font-based icons, just so I'm clear?
>>>>
>>>> Colin
>>>>
>>>> ---
>>>> Colin Clark
>>>> http://fluidproject.org
>>>>
>>>> On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:
>>>>
>>>>> Formal Proposal Regarding Font Icons:
>>>>> ==============================
>>>>>
>>>>> We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.
>>>>>
>>>>> For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.
>>>>>
>>>>>
>>>>> Guideline for using Font Icons:
>>>>>
>>>>> • Use PUA font icons
>>>>> • Provide a text alternatives for non-presentational uses
>>>>> • Add through CSS using classes
>>>>> • Apply the class to add the font icon to an element that will only contain the font icon
>>>>> • e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.
>>>>>
>>>>>
>>>>>
>>>>> Please let us know what you think about this proposal and if you have any more questions or concerns.
>>>>>
>>>>
>>>> _______________________________________________________
>>>> fluid-work mailing list - [hidden email]
>>>> To unsubscribe, change settings or access archives,
>>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>>
>>> _______________________________________________________
>>> fluid-work mailing list - [hidden email]
>>> To unsubscribe, change settings or access archives,
>>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>>
>> _______________________________________________________
>> fluid-work mailing list - [hidden email]
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
> _______________________________________________________
> fluid-work mailing list - [hidden email]
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

colinbdclark
In reply to this post by Justin Obara-3
Hi Justin,

On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:

> Formal Proposal Regarding Font Icons:
> ==============================
>
> We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.
>
> For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.
>
>
> Guideline for using Font Icons:
>
> • Use PUA font icons
> • Provide a text alternatives for non-presentational uses
> • Add through CSS using classes
> • Apply the class to add the font icon to an element that will only contain the font icon
> • e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.
>
> Please let us know what you think about this proposal and if you have any more questions or concerns.

This proposal seems quite sensible to me. It sounds like you and Heidi have found a reasonable and viable way of labelling font icons. Given this, I think they'll be a valuable addition to our design toolbox.

+1.

Colin

---
Colin Clark
http://fluidproject.org
_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Cheetham, Anastasia-2
In reply to this post by Valles, Heidi-2

On 2013-04-25, at 4:11 PM, Valles, Heidi wrote:

> This seems to be the way to go:
>
>             <div class="icon-music" aria-label="This is a music note" role="img"></div>
>
> A more real-life example, for UI Options, might be:
>
>             <div class="icon-indicator" aria-label="Arrow indicating current theme" role="img"></div>
>

Heidi, this looks nice and simple. Could you show us the associated CSS that would be required?

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                        OCAD University

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Justin Obara-3
Hi Anastasia,

Here's the link to the css file that Heidi used for her test page.

To highlight the important parts.

1) We need to import the the font icons we want to use.

@font-face {
font-family: 'fontawesome';
src:url('font/fontawesome.eot');
src:url('font/fontawesome.eot?#iefix') format('embedded-opentype'),
url('font/fontawesome.woff') format('woff'),
url('font/fontawesome.ttf') format('truetype'),
url('font/fontawesome.svg#fontawesome') format('svg');
font-weight: normal;
font-style: normal;
}

2) We will setup classes to apply the font to an element

.icon-glass, .icon-music, .icon-search, .icon-envelope, .icon-heart, .icon-star, .icon-user, .icon-film, .icon-th-large, .icon-ok, .icon-remove, .icon-camera, .icon-time, .icon-road, .icon-download-alt, .icon-print {
	font-family: 'fontawesome';
	speak: none;
	font-style: normal;
	font-weight: normal;
	font-variant: normal;
	text-transform: none;
	line-height: 1;
	-webkit-font-smoothing: antialiased;
}
3) We will inject the content (PUA unicode value) into the markup. In this case the :before pseudo-selector is used. However, we could have used :after or just applied it straight to the element.

.icon-music:before {
	content: "\e001";
}
That's all done with CSS, no javascript needed. 

I think that's what you were looking for.
Hope that helps.
Justin

On 2013-04-26, at 12:46 PM, "Cheetham, Anastasia" <[hidden email]> wrote:


On 2013-04-25, at 4:11 PM, Valles, Heidi wrote:

This seems to be the way to go:

           <div class="icon-music" aria-label="This is a music note" role="img"></div>

A more real-life example, for UI Options, might be:

           <div class="icon-indicator" aria-label="Arrow indicating current theme" role="img"></div>


Heidi, this looks nice and simple. Could you show us the associated CSS that would be required?

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                       OCAD University

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work


_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Cheetham, Anastasia-2

On 2013-04-26, at 1:04 PM, Justin Obara wrote:

> 2) We will setup classes to apply the font to an element
>
> .icon-glass, .icon-music, .icon-search, .icon-envelope, .icon-heart, .icon-star, .icon-user, .icon-film, .icon-th-large, .icon-ok, .icon-remove, .icon-camera, .icon-time, .icon-road, .icon-download-alt, .icon-print {
> font-family: 'fontawesome';
> speak: none;
> font-style: normal;
> font-weight: normal;
> font-variant: normal;
> text-transform: none;
> line-height: 1;
> -webkit-font-smoothing: antialiased;
> }

I'm guessing it would make sense to define a single class for this, that would be used for anything that wants to be that font? That way, if we add a 'character' to the interface, we wouldn't have to add its unique class name to this list.

> 3) We will inject the content (PUA unicode value) into the markup. In this case the :before pseudo-selector is used. However, we could have used :after or just applied it straight to the element.
>
> .icon-music:before {
> content: "\e001";
> }

To do this, we'd need to know the PUA unicode value of the character we want, right? Is that something that's easy to determine by someone who didn't create the font? Does it require any special software to examine the font file?

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                        OCAD University

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Justin Obara-3

On 2013-04-26, at 1:11 PM, "Cheetham, Anastasia" <[hidden email]> wrote:


On 2013-04-26, at 1:04 PM, Justin Obara wrote:

2) We will setup classes to apply the font to an element

.icon-glass, .icon-music, .icon-search, .icon-envelope, .icon-heart, .icon-star, .icon-user, .icon-film, .icon-th-large, .icon-ok, .icon-remove, .icon-camera, .icon-time, .icon-road, .icon-download-alt, .icon-print {
font-family: 'fontawesome';
speak: none;
font-style: normal;
font-weight: normal;
font-variant: normal;
text-transform: none;
line-height: 1;
-webkit-font-smoothing: antialiased;
}

I'm guessing it would make sense to define a single class for this, that would be used for anything that wants to be that font? That way, if we add a 'character' to the interface, we wouldn't have to add its unique class name to this list.

Yes we could do that. So we would just have to have two classes applied. 1) to setup the font 2) to inject the content.
The creator of iconmoon also suggested an alternative, but notes it will take longer to process.
[class*="icon-"]
In this case it finds all elements that have a class starting with "icon-" and sets up the font for it. This way you don't have to have two classes, or the long list of class names in the stylesheet. However, it would also make using icons from different font families more difficult.


3) We will inject the content (PUA unicode value) into the markup. In this case the :before pseudo-selector is used. However, we could have used :after or just applied it straight to the element.

.icon-music:before {
content: "\e001";
}

To do this, we'd need to know the PUA unicode value of the character we want, right? Is that something that's easy to determine by someone who didn't create the font? Does it require any special software to examine the font file?

Actually the style sheet used here is either the one generated by icomoon or derived from it. The \e001 is the actual PUA unicode. You can see a list of others here http://jrgraphix.net/r/Unicode/E000-F8FF . The stylesheet generated from Icomoon makes it pretty clear what is what, so the person creating the font should either setup our stylesheet or pass along the generated one to the person who will.

It will probably be a bit clearer by running through the icomoon app. 

Select one or more fonts, and click the "font" button at the bottom of the page. By default it will use PUA unicodes. Click the "Download" button and take a look at the css file provided. You should see that it breaks things out like the stylesheet for this demo, making it easy to know which code goes with which icon. There is also a sample index.html page provided to help with this.

Thanks
Justin

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                       OCAD University

<winmail.dat>


_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Cheetham, Anastasia-2

Thanks for the information, Justin. Comments in-line.

>> I'm guessing it would make sense to define a single class for this
>
> Yes we could do that. So we would just have to have two classes applied. 1) to setup the font 2) to inject the content.
> The creator of iconmoon also suggested an alternative, but notes it will take longer to process.
> [class*="icon-"]
> In this case it finds all elements that have a class starting with "icon-" and sets up the font for it. This way you don't have to have two classes, or the long list of class names in the stylesheet. However, it would also make using icons from different font families more difficult.

I think having two classes would be fine. We seem to be pretty accustomed to using multiple classes where necessary.

So that might look like:

    <div class="fontawesome-icon icon-music" aria-label="This is a music note" role="img"></div>

Then

    .fontawesome-icon {
        font-family: 'fontawesome';
        speak: none;
        ...
    }
    .icon-music {
        content: "\e001";
    }

>> To do this, we'd need to know the PUA unicode value of the character we want, right? Is that something that's easy to determine by someone who didn't create the font? Does it require any special software to examine the font file?
>
> Actually the style sheet used here is either the one generated by icomoon or derived from it. The \e001 is the actual PUA unicode. You can see a list of others here http://jrgraphix.net/r/Unicode/E000-F8FF . The stylesheet generated from Icomoon makes it pretty clear what is what, so the person creating the font should either setup our stylesheet or pass along the generated one to the person who will.
>
> It will probably be a bit clearer by running through the icomoon app.
> http://icomoon.io/app/

I'm thinking more about the workflow of someone trying to use a font that's already been created. Say, for example, Arash creates a beautiful font full of icons for the Video Player and someone has to modify the current stylesheet to use the new font. It sounds like Arash will provide them with the font and the generated stylesheet. The person would simply look up in the generated stylesheet for the "play" icon (for example), and use the associated PUA unicode they find in the updated Video Player CSS. Does that sound about right?

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                        OCAD University

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Justin Obara-3

On 2013-04-26, at 2:03 PM, "Cheetham, Anastasia" <[hidden email]> wrote:

>
> Thanks for the information, Justin. Comments in-line.
>
>>> I'm guessing it would make sense to define a single class for this
>>
>> Yes we could do that. So we would just have to have two classes applied. 1) to setup the font 2) to inject the content.
>> The creator of iconmoon also suggested an alternative, but notes it will take longer to process.
>> [class*="icon-"]
>> In this case it finds all elements that have a class starting with "icon-" and sets up the font for it. This way you don't have to have two classes, or the long list of class names in the stylesheet. However, it would also make using icons from different font families more difficult.
>
> I think having two classes would be fine. We seem to be pretty accustomed to using multiple classes where necessary.
>
> So that might look like:
>
>    <div class="fontawesome-icon icon-music" aria-label="This is a music note" role="img"></div>
>
> Then
>
>    .fontawesome-icon {
>        font-family: 'fontawesome';
>        speak: none;
>        ...
>    }
>    .icon-music {
>        content: "\e001";
>    }
>

That looks about right, although we'll likely be using a custom icon rather than one from fontawesome like we have here, but the idea sounds good.


>>> To do this, we'd need to know the PUA unicode value of the character we want, right? Is that something that's easy to determine by someone who didn't create the font? Does it require any special software to examine the font file?
>>
>> Actually the style sheet used here is either the one generated by icomoon or derived from it. The \e001 is the actual PUA unicode. You can see a list of others here http://jrgraphix.net/r/Unicode/E000-F8FF . The stylesheet generated from Icomoon makes it pretty clear what is what, so the person creating the font should either setup our stylesheet or pass along the generated one to the person who will.
>>
>> It will probably be a bit clearer by running through the icomoon app.
>> http://icomoon.io/app/
>
> I'm thinking more about the workflow of someone trying to use a font that's already been created. Say, for example, Arash creates a beautiful font full of icons for the Video Player and someone has to modify the current stylesheet to use the new font. It sounds like Arash will provide them with the font and the generated stylesheet. The person would simply look up in the generated stylesheet for the "play" icon (for example), and use the associated PUA unicode they find in the updated Video Player CSS. Does that sound about right?

I think so. If you are saying, we have a font already, and want to add one more icon to it. We'd need to create new font files. Then update the css to include the style which will inject the PUA for the new icon.

>
> --
> Anastasia Cheetham     Inclusive Design Research Centre
> [hidden email]           Inclusive Design Institute
>                                        OCAD University
>
> <winmail.dat>

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Cheetham, Anastasia-2

Ok, I had a brief conversation with Justin to clear up some confusion I had around this. I was, in fact, misunderstanding how this would work. The reality is:

The font file comes with a generated stylesheet that would need to be included in the header of the document. That generated stylesheet defines the class names for the individual font icons (e.g. "icon-music") and all the necessary CSS.

So as the person who simply wants to *use* the font icons in the interface, what I need to do is look inside the generated CSS file to find out what the class name is, and simply add that class name to the <div>. I don't actually have to write any CSS.

This sounds like a lovely plan! +1 :-)

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                        OCAD University

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Jess Mitchell-2
It also sounds like an opportunity to write a bit of documentation that says just this!

Jess


On Apr 29, 2013, at 10:07 AM, "Cheetham, Anastasia" <[hidden email]> wrote:

>
> Ok, I had a brief conversation with Justin to clear up some confusion I had around this. I was, in fact, misunderstanding how this would work. The reality is:
>
> The font file comes with a generated stylesheet that would need to be included in the header of the document. That generated stylesheet defines the class names for the individual font icons (e.g. "icon-music") and all the necessary CSS.
>
> So as the person who simply wants to *use* the font icons in the interface, what I need to do is look inside the generated CSS file to find out what the class name is, and simply add that class name to the <div>. I don't actually have to write any CSS.
>
> This sounds like a lovely plan! +1 :-)
>
> --
> Anastasia Cheetham     Inclusive Design Research Centre
> [hidden email]           Inclusive Design Institute
>                                        OCAD University
>
> _______________________________________________________
> fluid-work mailing list - [hidden email]
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Justin Obara-3
In reply to this post by colinbdclark
With the positive responses to the proposal I've now closed off the research jira (FLUID-4934: http://issues.fluidproject.org/browse/FLUID-4994) and created a new set of jiras around converting our existing icons to font icons (FLUID-4994: http://issues.fluidproject.org/browse/FLUID-4994).

I've also update our research page on the wiki.
http://wiki.fluidproject.org/display/fluid/Research+the+viability+of+using+icon+fonts+in+UI+Options

Thanks for all the feedback and help with the research.

Thanks
Justin

On 2013-04-26, at 11:03 AM, Colin Clark <[hidden email]> wrote:

> Hi Justin,
>
> On 2013-04-23, at 12:24 PM, Justin Obara <[hidden email]> wrote:
>
>> Formal Proposal Regarding Font Icons:
>> ==============================
>>
>> We should use font icons for relatively simple images that can be represented using a single colour, or a few colours in cases where stacking is appropriate, and which need to be responsive to resolution, size, and colour changes on the fly.
>>
>> For complex images, or those that do not require the responsiveness listed above, we should make use of either svg or raster images as appropriate.
>>
>>
>> Guideline for using Font Icons:
>>
>> • Use PUA font icons
>> • Provide a text alternatives for non-presentational uses
>> • Add through CSS using classes
>> • Apply the class to add the font icon to an element that will only contain the font icon
>> • e.g. <span class="addFont"> font icon </span> where "font icon" would be the actual font icon displayed.
>>
>> Please let us know what you think about this proposal and if you have any more questions or concerns.
>
> This proposal seems quite sensible to me. It sounds like you and Heidi have found a reasonable and viable way of labelling font icons. Given this, I think they'll be a valuable addition to our design toolbox.
>
> +1.
>
> Colin
>
> ---
> Colin Clark
> http://fluidproject.org

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
Reply | Threaded
Open this post in threaded view
|

Re: Font Icon discussion continued

Cheetham, Anastasia-2
In reply to this post by Jess Mitchell-2

On 2013-04-29, at 10:17 AM, Jess Mitchell wrote:

> It also sounds like an opportunity to write a bit of documentation that says just this!


Indeed - that's partly why I wanted to make sure I fully understand what's needed :-)

--
Anastasia Cheetham     Inclusive Design Research Centre
[hidden email]           Inclusive Design Institute
                                        OCAD University

_______________________________________________________
fluid-work mailing list - [hidden email]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work