W3C home > Mailing lists > Public > public-web-notification@w3.org > June 2012

Re: Fail if icon fails? Re: Web Notifications

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 21 Jun 2012 13:48:32 +0200
To: "Anne van Kesteren" <annevk@annevk.nl>
Cc: "John Gregg" <johnnyg@google.com>, "Web Notification WG" <public-web-notification@w3.org>
Message-ID: <op.wf84e6kbwxe0ny@widsith-3.local>
On Thu, 21 Jun 2012 13:16:22 +0200, Anne van Kesteren <annevk@annevk.nl>  
wrote:

> On Thu, Jun 21, 2012 at 12:54 PM, Charles McCathieNevile
> <chaals@opera.com> wrote:
>> On Wed, 20 Jun 2012 15:39:48 +0200, Anne van Kesteren <annevk@annevk.nl>
>> wrote:
>>> We could introduce an event named "iconerror" if we think it's worth
>>> it. Dispatching events with other names is rather trivial.
>>
>> That's one approach. Doing that, and going through with the rest of the
>> notification is probably a good idea in practice.
>
> Discussing this a bit with James I agree we should display the
> notification. The icon is like the favicon for pages. It's not a
> critical resource, just there for entertainment.

I don't think so. The favicon, and even more this icon, does carry meaning  
- there are many cases where the URL isn't that informative, and isn't  
easy to understand at a glance, but the favicon is.

My instant use case is to have email notifications use the icons relevant  
to the filters where my email goes, so I remember which filters to look  
in. Which means I will hack up a way to combine the relevant icons - while  
in theory there are thousands of possible combinations in practise I  
basically get a couple of dozen which is easily manageable (but since i am  
likely to try slapping them together automagically on the server I am  
increasing the chance of it not actually loading...).

Using the icon to identify things often makes more sense than using text -  
it is more compact, faster to recognise, and can provide branding  
(something that commercial websites are often trying to do, and will abuse  
all markup to achieve if there isn't a nice way to do it). That's why they  
are ubiquitous.

Almost 2 decades of the img element shows that whatever we say about that,  
people will write things and absolutely rely on the image being there,  
rather than adding redundant text (even in the case below where I argue  
that there needs to be a mechanism for a text alternative). This is not  
good communication, but we can't really force people to be good  
communicators.

I frankly expect to see sites using pictures of words, a la the web of  
1999, because someone insists they have the right corporate fonts and  
colours in the notification.

> I think we should remove the event altogether.

Yeah, I think that would be OK, but see below...

> ... We can always introduce an event later on ...
>
>> Hmm. There's no way to provide a text equivalent to the icon. If it is
>> possible to display the notification without the icon, as I think it  
>> should be, then that becomes a bug. I can raise a seperate thread for
>> that if you like...
>
> It doesn't need it.

I don't know why you think it is unnecessary, so I will explain why I  
think it is.

The reason I think it is valuable is that good content will often not have  
equivalent redundant text for the icon where it is rendered, but will  
provide an equivalent for where it isn't. Think of icons in email apps,  
rich editors, banking applications and the like. If you have a rich icon  
set there is a text alternative that only renders if you turn off the  
icons or if the user asks for it (e.g. a tooltip on mouseover) because it  
is hard to guess what the icon means the first time you see it.

Obviously, if icons are used for information users who rely on voice  
output will need to have something to replace the icon.

cheers

Chaals

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Thursday, 21 June 2012 11:49:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 December 2012 14:48:28 GMT