Re: how to indicate symbols that metamorph?

David,

yet another excellent response, thanks again.
I agree that we differ in whether it is possible or perhaps even  
desirable to include those issues outlined in SVG.

It's my belief that the decision taken to exclude ordinary people in  
the original process has resulted in distortions to the specification.
but we perhaps already agree on this?

What would be enormously helpful, in my consideration, is if you  
personally attempted to provide graphical renderings of your arguments  
as reduced testcases.
then we have a real prospect of tackling issues such as  
differentiating live from static icons.
and perhaps adding them to the test suite, a pity that examples like  
this and externalResourcesRequired are not present, or are they?

you might like to read the 'chalk proposal' and then view a rather old  
graphical representation:
http://www.peepo.co.uk/peepo2/authoringTool.html
It does feel as though it's time to update the peepo.com homepage to  
demonstrate some of the smaller advances.

regards



Jonathan Chetwynd

j.chetwynd@btinternet.com
http://www.openicon.org/

+44 (0) 20 7978 1764


On 26 Jul 2008, at 13:27, David Woolley wrote:

>
> Jonathan Chetwynd wrote:
>> 1. html adopted underline and font colour to indicate links.
>
> And, as soon as sufficient presentational control was made  
> available, designers rejected this standardisation.  I think that  
> was bad for consumers, but the designers love it.  For many years  
> now, you've had to play hunt the link.
>> What simple and general method could be agreed for SVG to indicate  
>> a symbol that metamorphs?
>
> You are treating SVG as though it were a non-verbal equivalent of  
> HTML.  It's not.  It is a much lower level tool.  User interface  
> conventiona can be built on top if it, but for designers working in  
> marketing or entertainment, behaving the same as the competitor, or  
> last year's model, is seen as something to avoid.  Where they do  
> adhere to conventions, they will be much more subtle than the  
> distinction between sunny and weather (and which is a problem for  
> older people, not just those with learning disabilities).
>
> Moreover, most people moving from HTML to SVG, for material with  
> textual content will be doing so precisely because it removes the  
> constraints on visual behaviour imposed by HTML.  (I don't think  
> that is a good thing, but it seems inevitable.)
>
> Such people want total control of the user interface (they will talk  
> of the "user experience"), so, for example, whilst they may well  
> want tooltips, they will want the tooltips to appear only where they  
> want them to appear, not as a browser reaction to accessibility meta  
> data.
>
> Where people are creating technical drawings, rather than marketing  
> material, they will use a technical drawing packages, probably one  
> for s specific application area, e.g. schematic capture for  
> electronics, rather than raw SVG tools.
>
> What I think you want is a language, that works at a similar level  
> of abstraction to HTML, but in terms of a language based on relative  
> position and movement, in 2 dimensions of low abstraction images,  
> rather than the static linear form of HTML and its typical use with  
> high abstraction words.
>
> You give me the impresssion that you have a problem in  
> distinguishing such a language from SVG and in actually specifying  
> the language in concrete form.  It's easy to talk about a language  
> that uses icons, position and movement, but much more difficult to  
> create and specify a good one.  It also requires skills that differ  
> a lot from those involved in designing a low level graphics language.
>
> My own view would be that it would be reasonable to discuss the need  
> for such a language on the SVG list, because it may  be the case  
> that people are using SVG when they would be better served by such a  
> language, e.g. because SVG does offer too much freedom for bad  
> design.  It is obviously legitimate to discuss any weakness in the  
> ability of SVG to represent the graphics and animation from such a  
> language.  However the details of such a language really needs its  
> own discussion group, as it at a very different level of abstraction  
> from SVG.
>
> Once you have such a language, you will, of course, have to fight  
> off the pressure to give it more and more control of visual  
> rendering, until ti starts to compete with SVG.
>
> -- 
> David Woolley
> Emails are not formal business letters, whatever businesses may want.
> RFC1855 says there should be an address here, but, in a world of spam,
> that is no longer good advice, as archive address hiding may not work.
>