Bullseye
you are in savethegaywhale || msc || discussion
5 Discussion
The review of literature established that SVG, despite having been a W3C standard since 2001, has, compared to the established Flash, failed to make a significant impact as media for the delivery of interactive vector graphics on the Internet. The design and development process and subsequent evaluations sought to establish the reasons for this. This section develops these findings and attempts to glimpse into the future of SVG.
Developing SVG is, in principle, straightforward. Only a text editor is required, although Neumann and Winter (2001) suggest that the role of a text editor in SVG is better suited to corrections and additions rather than development. However the development of 'Bullseye' has demonstrated that for applications involving interactivity (or any degree of complexity), it is necessary to have programming skills in JavaScript and SVG. In addition there appears to be flaws in the language and limitations caused by the DOM. It has further been demonstrated that of the main GUI based development environments available, only EvolGrafix's XStudio 2 could be considered for the development of an application in SVG similar to 'Bullseye'. Furthermore, the W3C open standard of SVG (World Wide Web Consortium (1), 2003) has been shown as poorly implemented by developers of SVG viewers (World Wide Web Consortium (6), 2003). The evaluation of plugins has shown that the open standard is not only not fully implemented, but (in the case of ASV3 & ASV6) also have features that are out with the standard, further complicating matters for developers.
Whilst it is the case that SVG can be developed making use of techniques such as cut'n'paste (a simple method to reuse code), provided the there are no copyright issues, in a text editor (which can be had at zero cost), the specialist knowledge needed effectively inhibits development. The most effective GUI (Xstudio 2) development environment is immature compared to Macromedia Flash equivalent and costs £345 compared to £389 . It seems unlikely that developers will consider the difficulties of developing in SVG compared to Flash is worth any financial saving.
It is important to place these difficulties in context. The aim of any GUI development environment for SVG is to produce the human readable file, in a format specified by the W3C open standard, to be rendered by a viewer. This 2 stage process is inherently more complicated than the single stage binary compilation that Flash undertakes. Nor are Macromedia (Flash is a proprietary format) constrained by the need to comply with an open standard.
Whilst SVG's text based nature has a number of potential advantages, these are marginalised by the fact that so few users have access to an SVG viewer. It has been demonstrated that users who have no plugin or a plugin that is not suitable for the feature set of the file that is attempting to load are presented with confusing or no error messages. Users in this simply do not investigate the cause of the difficulties and cease the activity. Many developers recognise the de facto primacy of ASV3 (and that its natural successor is ASV6) by including a link to the Adobe Systems (2003) website on web pages where they have placed SVG images. Therefore, it is proposed, that developers need to be more proactive in this area by more explicitly accepting the status of AVS3 and including an 'auto-install' script, which installs ASV3 (subject to user agreement) automatically. Such a script is provided by Adobe Systems (2003), although it is limited in that it merely checks that the SVG mime types are supported and does not check the viewer version for suitability. This level of assistance is available to (and the norm for) Flash users and such user friendly features are an essential prerequisite to wider distribution of SVG viewers.
The review of literature established the importance of download times; however no one in the Internet based evaluation rated the download time for either application as 'poor', it was always 'good' or 'satisfactory'. This suggests that vector graphics (at this level of complexity) in both formats are suitable for Internet use in this respect. Nevertheless, it has been observed in the development process and in the Internet based evaluation that the computer specifications can be significant to the quality of client side rendering. Whilst the propriety Flash player interprets a compiled binary, an SVG viewer interprets plain text before the rendering process begins. The additional complexity of this process is reflected in the increased size of an SVG viewer download compared to the Flash player (2.3Mb versus 0.5Mb). The result is that the Flash application operates smoothly on a platform equivalent to the baseline specification given in appendix 4 (500MHz CPU), whereas the SVG application requires the revised appendix 4 specification (1GHz CPU). However some users in the Internet based evaluation with high specification (2GHz CPU) computers felt that the quality of the moving graphics in SVG was marginally smoother than in the Flash application. It can be argued that that Moore's law (Moore, 1965), which states that as technology advances bringing reduced costs per component, the technology can justify the increased complexity and costs of more components per circuit. Moore asserts that the sustainable increase of the latter is in the region of a factor of 2 per year. This thesis is often simplified to the idea that CPU speeds will double every year. Post (Post G, 1999) develops Moore's (1965) argument and concludes that businesses should replace their computers every 36 months. The 1GHz CPU first became available in the year 2000, therefore, following the logic of Post (1999), all businesses that bought personal computers before 2000 should have replaced them by now. To what extent this logic is reflected in the purchasing of the world is debatable (and Post does not consider the domestic personal computer market), but it does suggest that hardware related problems with SVG are of a temporary nature.
In sections 3.1 and 3.2 criteria were outlined against which the applications were to be compared. It is useful to summarise the results of the evaluations by listing how each format performed against the criterion, this is done in table 7 below.
|
Criteria |
Flash | SVG |
| Useable: | Yes. | Yes, although slightly more client side resource may be required. |
| Flexible and extensible: | Yes, use of library objects and ActionScript permit this. | Yes, by placing objects within <defs> and <g> tags. Also use of JavaScript supports this. |
| High cohesion and Low coupling: | Yes, the use of library objects facilitates this, knowledge of ActionScript is useful. | Yes, with efficient scripting, but knowledge of format is essential as the current GUI development environments are of limited assistance. |
| Availability: | Yes, plugin widely distributed, otherwise a 0.5Mb download. | Poor plugin distribution and 2.3Mb plugin download is a restriction. |
| Accessibility: | Easy to get correct plugin, meaningful error messages if no or incorrect plugin installed. | Accessibility severely impaired by poor error messages from early plugins. |
| Bandwidth: | A low bandwidth format. | A low bandwidth format. |
| Speed of client side rendering: | Good. | Potentially slower as text rather than binary format. |
| Functionality: | As expected. | Problems related to the DOM and a programming bug. |
| User experience: | Good, overall superior to SVG. | Good, but can be reduced by difficulties with plugin. |
Table 7: Summary of performance against key criteria.
The summarised results of performance against criteria in table 7 reflect the fact that Flash is a mature technology compared to SVG.
It might be considered that a limitation of this project is that it has tested
SVG against a particular range of features in which Flash has been found to be superior.
Future work comparing interactive vector graphic formats on the Internet might extend
to developing server side interaction such as the booking system discussed in the
review of literature. A minor project might be to examine if there is an effect,
as Winter (2004) suggests, on the performance of a Flash application used prior
to an SVG application and vice versa, if there is, it could influence how certain
aspects of evaluation in projects of this type are undertaken. Other work could
be extending this project to include comparing Flash and SVG on small devices such
as Mobile phones and PDA's.