On Dec 27, 2009, at 1:55 PM, Krzysztof Kosiński wrote:
W dniu 27 grudnia 2009 03:46 użytkownik Jon Cruz <jon@...18...> napisał:
What you pointed out was a specific program of a very specific type (MS Word) and a clone of that same program. Thus those really don't even count as two as far as behavior goes.
Other programs include GIMP and other raster editors - maybe this example is more convincing, because
Aha. So here we have another specific use case, and a more general rule that might be derived from it:
"Users who only know bitmap editors might get confused"
Now... one has to remember that this is initially a *web* graphic format. So we really should compare to *web* document programs.
I think this is in fact our main point of contention. You think of Inkscape as web graphics editor, while I think of it mainly as a general-purpose vector graphics program that uses SVG.
Not quite. I don't call it a "web" program per se.
However... one *KEY* point on Inkscape is that it *IS* supposed to be first and foremost an SVG editor, not a general purpose vector graphics program. That was some of the main reason to fork Inkscape in the first place, and has been explicitly stated.
*HOWEVER* this is not the problem disconnect. I'm looking at this from the view of general graphics use. I've used many myself, have worked with professional artists, new artists, casual users, businessmen trying to through things together, etc.
For you using SVG as the output format is the goal, for me it's merely an advantage. The correct default depends on how we answer this question. This is where your survey data could help. How many users use Inkscape as a general purpose vector editor, compared to the number of people who use it as a web editor?
Not really. You've got a bit of a straw-man argument set up there, and phrasing a question in that manner won't really gain us useful information.
- you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
- Many many many programs out there *do* paste links. They might be more common with workflows different than the workflows you personally use... but that does not mean they do not exist.
Please mention examples! There are indeed several programs that do paste or import links, but we must also consider how they relate to Inkscape. Video editing programs almost always use links, but I don't think this is relevant for a vector editor. The other example you mentioned is web design tools, see above.
Publishing tools also do this. There are a whole slew of those.
*HOWEVER* instead of taking wild guesses and disputing that end users actually behave this way, you really should heed reality.
Here's a bug an actual end-user reported just the other day https://bugs.launchpad.net/inkscape/+bug/499252
It has a very good use case described, and also shows that the user is *expecting* image linking.
(Oh, and another somewhat recent one where the user not only expects the linking, but dislikes the details of where linked things are https://bugs.launchpad.net/inkscape/+bug/441179 )
Instead I would say a better solution is: "Make the UI convey link vs. embedded constantly and consistently so the user is never surprised."
This would require everyone to understand the difference between a link and an embedded image, and the concept of a link between two files. There might be lots of potential Inkscape users that don't understand the link concept (not to say that they wouldn't understand it if explained, just that they never used it). In this respect, embedding is bulletproof and idiot-proof.
No, it is neither bulletproof nor idiot-proof.
And the latter will get us into big trouble. Any seasoned software engineer can tell you... once you invent an idiot-proof program, the world invents a better idiot.
A better approach is to clearly pin down actual users that you are afraid of. Define who they are and how they see things and then it will be easy to craft a solution to support them.
2009/12/27 Donna Benjamin <donna@...2182...>:
Bundling the file together with the linked images the way ODF does makes some sense for file storage and transportability - but embedding the file, by UUencoding or Base64 or something doesn't make sense to me, because it can't be edited with a text-editor
SVG with embedded images can be edited in a text editor. The image element will have a very long URI, but it should not be a problem for a decent editor.
Have you tried?
Aside from all the other issues, with some of the larger images one will often find things very painful to try to edit a large file.
And when we're talking about a 33% increase on top of an already multi-megabyte asset, things get slow very quickly.
What does the SVG standard suggest? What's wrong with the current 'save as' compressed svg with media (*.zip) option... perhaps some documentation or asking heathenx to do a screencast on this topic would help those users who are unfamiliar with this standard practice?
SVG doesn't define any compression methods or container formats, but the de facto standard is SVGZ (a single SVG file compressed with gzip). SVGZ is opened directly by many vector applications. The ZIP archive requires decompression, and as said before the user is not aware that he should choose this option before sending the file to a friend.
More screencasts and more documentation can't hurt, but it's better if basic features of a program do not require explanations - this is called usability :) So we have a dilemma: we either adapt pasting so that average Joe, who doesn't bother watching screencasts or reading docs, doesn't break his documents, or try to teach him that SVG images are more like web pages, and the images should be external. The former has a better chance of success.
Again, you are pushing a false dichotomy.
The third, and probably much better choice, is to just make Inkscape seamlessly support the common end user scenarios.
We just need to get the actual use cases out there defined. *Then* it becomes much easier to see good solutions. Guesses often don't help, and guess that have been seen to go counter to actual observed data are harmful.