W3C home > Mailing lists > Public > public-svg-ig@w3.org > July to September 2008

authoring tools [was RE: sockets ]

From: Dailey, David P. <david.dailey@sru.edu>
Date: Sun, 7 Sep 2008 09:47:01 -0400
Message-ID: <1835D662B263BC4E864A7CFAB2FEEB3D015255B9@msfexch01.srunet.sruad.edu>
To: "Jonathan Chetwynd" <j.chetwynd@btinternet.com>, <public-svg-ig@w3.org>
Cc: <dsr@w3.org>

Hi Jonathan,
 
The charter of our group puts within our scope: "report back their findings to the SVG WG, in such areas as Accessibility, Authoring Tool Requirements, etc." So your comments about accessibility and authoring tool requirements seem quite timely.
 
As a point at which, perhaps to begin our discussion of Authoring Tool Requirements, I would point to Dave Raggett's presentation at SVG Open 2008: "SVG, layered user interfaces and end to end models."[1] I was unable to attend his presentation, and have not myself digested what he says, but the abstract alone is worth reading. It presents, I think, a perspective for approaching these topics that exhibits far more careful thought on the subject than most of us (certainly than I) have given it.
 
For me, the questions of what would an SVG authoring tool do, look like and feel like, have always been a bit unclear. On the one hand we have the WYSIWG approaches exemplified by Inkscape and its competetors (like Illustrator and the others). On the other hand we have full-blown XML editors like oXygen.  I am somewhat embarrassed to admit that for 9 years, I've used Allaire Homesite (they were later bought by Macromedia) to create most of my HTML, SVG and JavaScript, simply because it has been available in my classrooms and labs. Firebug in FF and Dragonfly in Opera are things I've played with but not really mastered, since, perhaps they are too rich. (I am also limited in what I can use since it has to be accessible to undergraduate students with a minimum of time for familiarization-- I'd love recos for solutions, btw).
 
The point is, that what folks mean by "authoring" SVG varies considerably as a function of what sort of SVG they are authoring. I was very struck in my recent re-acquaintance with Inkscape, how full and rich it has become -- the interface provides a class of what we might call "user primitives" like mouse actions to intersect two curves (as a very simple example) that would be very painful to code by hand with markup.* But I need JavaScript, runtime preview in multiple browsers, styled markup, and -- just occasionally, a wysiwyg drawing tool to plop real content into an enviroment otherwise dominated by script. Another user will have very little need for the script-intensive enviroment, or even the markup-intensive environment used by someone like me. 
 
While I might have lots of end-user things to say about my own needs in an SVG authoring environment, I really hope that folks like Dave R. and others who have high level experience in this area will find the time to help structure the important conversations to follow. It seems clear from what I glean from both Dave's paper and from what I see happening in Inkscape, that declarative authoring methods are on the advance, much to the joy of all who understand them. SVG will be fundamental I think to the development of its own authoring tools. 
 
As I see it, SVG is better than Flash or Silverlight or HTML or speech or text or gesture since it provides an opportunity to expand the bandwidth of human communication. The others (because of limitiations on either licensure or fundamental metaphor) just can't go there. The proper authoring tools, are hence, not going to be easy to make. They will be rich, spatial, temporal, semantic, graph theoretic, and declarative -- that much is clear.
 
With regards to accessibility, I think outlining the basic issues that we as a group can address (including ARIA and how best to enable the entry of metadata into SVG) in the wiki, may be a productive step. Are there other ways to proceed that make more sense?  Among the things that Christophe Strobbe's presentation at SVGOpen conveyed was the sense that accessibility is not a "special" interest but a central interest. As all of us age and as all of us change the platforms on which we view content, accessibility issues follow us. I know the SVG WG is well-populated by strong advocates, but the energy of this group can help them define a set of achievable objectives.
 
David
 
[1] http://svgopen.org/2008/papers/59-SVG_layered_user_interfaces_and_end_to_end_models/

 
* I would strongly suggest we all take a look at the Inkscape package with an eye to things that perhaps belong in a future spec of some sort -- like drawing primitives.
________________________________

From: public-svg-ig-request@w3.org on behalf of Jonathan Chetwynd
Sent: Sun 9/7/2008 4:14 AM
To: public-svg-ig@w3.org
Subject: Re: sockets


Doug, 

Thank you once again for your lengthy and considered response.


I am concerned by comments such as

"I'm confident that any problems that are being discussed now will be 
resolved to the satisfaction of the browser implementors. "

which show little appreciation of the needs of end users, as discussed at length by me elsewhere. for instance as a requirement to include them and their representatives in the spec process.

regarding "The SVG IG is meant to drive future functionality of SVG"
this is specifically why I raised this issue.

much of the past and current drive is towards extending SVG's graphical functionality.
However whilst features such as filters which may be relatively easy to implement it is apparent that there uses for people with learning disabilities may be more limited. The evidence in languages that use iconic symbols is that they are not used.

I am concerned that my efforts to encourage creation of a reduced spec or microformat is not being encouraged, in fact being either ignored or discouraged.

communication is a two way process.
This means there is a need for simple and easy to use authoring tools
but also real-time communication and
people with learning disabilities will benefit from multi-user games, as they also promote communication.
xmlhttprequest is not the default method currently used for these games and it would be helpful to include sockets whether tcp, websocket or other at the earliest opportunity.

It is evident that the current specs have not produced a generally adopted and popular authoring tool, in the past decade.
nor a range of such tools.

Almost all the online games, teaching resources and communication aids I know of that have been produced for people with learning disabilities use flash.
there is a reason, and the svg wg might be well advised to consider this.

regards

my logo <http://www.openicon.org/> 

Jonathan Chetwynd

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

+44 (0) 20 7978 1764


as you will know I am reducing my email contributions, delayed responses can be expected.
Received on Sunday, 7 September 2008 13:48:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 14 April 2009 16:29:30 GMT