Re: how to indicate symbols that metamorph?

David,

in addition, In realise I should perhaps have added...

that's one of the primary reasons for developing a microformat.
something smaller, that is SVG, and enables actual practice to help  
development.
after a decade there is afaik no simple and easy to use SVG authoring  
tool.

yet I think you already agree that the demonstration of copy and paste  
with <use> remote presents queries that may only be resolved through  
extensive testing.
rather than cogitation...

there are numerous other 'usability-accessibility' issues that could  
have been grasped, had users authoring requirements been considered  
and included from the first.

and as I say a stab at anwsering the subject graphically, might be  
appreciate by all...

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.
>