2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>

When you paste an image into a Word / ODT file, it is not a link to that file on your hard disk. The use of links is also quite common in large Microsoft Word documents and has been for years. I am finishing a 160 page book with about 80 linked photographs and maps using Word 2003. Linked photos are essential in this case as the file size would otherwise be unworkable. You can insert, link or insert and link the objects and then at a later stage swap etc or otherwise edit their designations. There are numerous advantages to linking and there are few hassles. One interesting one is when you have all your images on a separate drive and forget to turn that on when you edit your main article. Heart attack material for a few seconds when you think you have lost all your photos.

I am familiar with the OpenOffice use of links and it is clearly modelled on that of Word.

Erik Halbert kaver@...1960...

On Oct 23, 2009, at 1:16 PM, Krzysztof Kosiński wrote:

That is the gist of what I'm saying. I don't want to remove link support, or make it harder to use. I want inexperienced users to stop breaking their documents.

Ah, Good!!!

We finally have a clear software requirement.

Problem: Inexperienced users are breaking their documents.

Proposed solution A: Change the "Import" command for all so that it embeds instead of links.

On Oct 23, 2009, at 1:23 PM, Steven M. Ottens wrote:

Jon A. Cruz wrote:

...

Problem: Inexperienced users are breaking their documents.

Proposed solution A: Change the "Import" command for all so that it embeds instead of links.

+1

Proposed solution B: Change the UI to clearly show the difference between linked and embedded images.

Proposed solution C: Add a popup that explains to a new user what linking vs. embedding is.

Proposed solution D: Allow a preference to "always embed"

Proposed solution E: all of B, C, and D

Steren wrote:

Problem: Inexperienced users are breaking their documents.

Proposed solution A: Change the "Import" command for all so that
it  embeds instead of links.

I did say +1 and I do believe that's the correct thing for casual users. Although I do agree that for a lot of users it makes sense to default this to 'link'. So make it fairly easy in the settings to change this behavior.

Proposed solution B: Change the UI to clearly show the difference
between linked and embedded images.

This is very tricky. As an interaction designer I know that there's no such thing as 'showing clearly'; the so called intuitive solution often is the commonly used one. Since there's not a clear common solution in this case (nor is it a common problem) it is difficult (but not impossible) to come up with a obvious metaphor.

Proposed solution C: Add a popup that explains to a new user what
linking vs. embedding is.

Personally I hate popups; they interfere with the workflow. Greater minds than me have written beautiful, but wishful, obituaries for the popup and I just want to adhere.

Proposed solution D: Allow a preference to "always embed"

I'd say a preference: 'always embed, always link, ask' or maybe even have preferences for copy-paste, import and drag 'n drop.

Proposed solution E: all of B, C, and D

Generally it is a bad idea to clutter your interface with several options to do the same thing.

Regards, Steven

Quoting "Steven M. Ottens" <steven@...2202...>:

This is very tricky. As an interaction designer I know that there's no such thing as 'showing clearly'; the so called intuitive solution often is the commonly used one. Since there's not a clear common solution in this case (nor is it a common problem) it is difficult (but not impossible) to come up with a obvious metaphor.

...

Thanks, this is exactly the type of participation I was hoping we'd get. Do you think you could help us get details and discussion going on the wiki?

http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management

I was wondering if Glib has a cross-platform inotify equivalent, and it does. This is what we need to implement external editing of embedded files. Just watch for file change events and update the embedded data whenever that happens. However, we need to at least partially move to GIO to make any use of this.

http://library.gnome.org/devel/gio/unstable/GFileMonitor.html

Regards, Krzysztof

On Oct 24, 2009, at 6:36 PM, Krzysztof Kosiński wrote:

2009/10/24 <Jon@...18...>:

...

Thanks, this is exactly the type of participation I was hoping we'd get. Do you think you could help us get details and discussion going on the wiki?

http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management

I added some of the ideas from this discussion to that page.

Thanks. The use cases there are a good start, but they are missing some critical information. You referenced several 'personas' in context, but did not spell out who these different users actually are. One of the key things is to have a complete, specific idea of named fictitious people referenced use cases (otherwise one could just say "a graphic designer" or "a software architect").

I've stubbed out some placeholders for the users that you can fill out with details. To get some idea of how to write a persona check the Marketing Scratchpad page on our wiki and its link to Wikipedia.

Thanks.

Krzysztof, could you *please* go in and fill out the details for the personas you invented?

http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management#Personas

Done, though I don't know how is this relevant. Do things like what those imaginary people do for a living, or how old they are affect the implementation of media management features? Even without this extra information, those use cases indicate pretty clearly that embedding on paste by default is a good idea.

Regards, Krzysztof

W dniu 23 grudnia 2009 20:15 użytkownik Jon Cruz <jon@...18...> napisał:

Here, let me explicitly point out the link to you http://en.wikipedia.org/wiki/Persona_%28marketing%29

It says that user personas are created based on actual survey or interview data. Isn't me or you inventing them "cargo cult marketing"?

To do this correctly, we should ask people from here: http://www.inkscapeforum.com/ and create personas that correspond to the answers.

Regards, Krzysztof

On Wed, 2009-12-23 at 21:10 +0100, Krzysztof Kosiński wrote:

W dniu 23 grudnia 2009 20:15 użytkownik Jon Cruz <jon@...18...> napisał:

...

Here, let me explicitly point out the link to you http://en.wikipedia.org/wiki/Persona_%28marketing%29

It says that user personas are created based on actual survey or interview data. Isn't me or you inventing them "cargo cult marketing"?

It says in most cases, not all.

To do this correctly, we should ask people from here: http://www.inkscapeforum.com/ and create personas that correspond to the answers.

Not a bad idea in general, however we would need to create a survey to achieve this. I don't think users of inkscapeforum alone will represent a wide enough group of different types of users. So, perhaps we create an online survey and announce on the forums, the user-list, deviantart, twitter, and our website.

The question then becomes, what if people overwhelmingly respond?

Cheers, Josh

On Wed, 2009-12-23 at 12:35 -0800, Jon Cruz wrote:

On Dec 23, 2009, at 12:22 PM, Joshua A. Andler wrote:

...

Not a bad idea in general, however we would need to create a survey to achieve this. I don't think users of inkscapeforum alone will represent a wide enough group of different types of users. So, perhaps we create an online survey and announce on the forums, the user-list, deviantart, twitter, and our website.

The question then becomes, what if people overwhelmingly respond?

What generally happens in these cases is that you don't get much useful information. That is, the online poll tends to get misinformation and more of what people think the poller wants to hear.

So if you ask Age, Occupation, Hobbies/Interests, Is your use of inkscape related to occupation, hobbies/interests, both, or neither? What have you used Inkscape for?, How long have you been using it for? Have you used other vector graphics software?, If so, sow long have you used vector graphics software for?, etc... that people are going to intentionally give us bad info? What do they think we want to hear by those types of questions? That everyone is a 35yr old graphic designer who has 17 years of experience with vector software and 3yrs w/ inkscape?

Remember, users will lie. Well, rather they will say what they think is *how* to get what they want, not the *why* of what they're actually trying to get.

We're not asking them what they want. So they have no reason to lie. We state the purpose of the survey... we need to know more about our userbase and what uses people are finding for inkscape.

On the other hand, observing users "in the wild" at trade shows or conventions is a good opportunity to conduct such surveying (and, yes, I've confirmed this with many usability professionals)

I agree on the observing users piece. However, it is again limiting w/ *where* you recommend surveying because most people I know have never attended a trade show or convention. Better yet, I personally know a small and diverse group of Inkscape users, none have ever been to a trade show or convention. They're now left out.

Cheers, Josh

I can see how those details are important when considering a big change in the behavior of the application. However, the main point of this specification is to fix a bug (images disappear when sending the SVG to somebody else). The gist of the solution is to embed on pasting by default, and the only remaining discussion is how to expose the link functionality. Am I right?

Regards, Krzysztof

On Dec 23, 2009, at 11:30 AM, Krzysztof Kosiński wrote:

I can see how those details are important when considering a big change in the behavior of the application. However, the main point of this specification is to fix a bug (images disappear when sending the SVG to somebody else). The gist of the solution is to embed on pasting by default, and the only remaining discussion is how to expose the link functionality. Am I right?

No.

You're seeing the trees but not the whole forest.

To restate, you're seeing a single concrete manifestation of a problem and crafting a solution that solves only that specific manifestation, but both leaves other manifestations in place *and* creates new manifestations.

Instead of a one-off small localized "band-aid" patch at one point, let's solve the whole problem in one simple pass. Or one might illustrate it with the comparison of you grabbing onto the tail of an elephant and saying "a snake! let's grab a snare pole and get rid of it" while I'm saying "No, it's an elephant; just ask his mahout to have him step away"

On Dec 23, 2009, at 12:52 PM, Krzysztof Kosiński wrote:

W dniu 23 grudnia 2009 21:17 użytkownik Jon Cruz <jon@...18...> napisał:

...

No. I've been conducting surveys for years now, and from many different groups. These include complete computer novices, some who have been graphic designers, some who have not.

In that case, what is the point of me making up the personas when you have real-world data? You should write them, and based on that I can then adjust the use cases.

The point was that you said you had use cases and invented those personas. I can't determine where those fit with our overall ones unless you spell out what you were thinking for each of those. Remember, we can't read your mind.

On Dec 23, 2009, at 1:14 PM, Jon Cruz wrote:

You seem to be addressing "attached files get lost", and address it with "never attach files, always link them".

Oh, sorry. I meant to say "always embed them"

On Dec 23, 2009, at 1:47 PM, Krzysztof Kosiński wrote:

...

Another one is "I have a common image placed for background, and now my directory jumped from 100MB to 20GB and can't fit on my thumb drive any more".

20GB uncompressed SVG file would have to contain 5GB of images.

Ah, but you missed what I said.

A "common image placed for background". Think a few dozen SVG files with a single large PNG placed in each. (Yes, a real-world scenario I've seen)

W dniu 23 grudnia 2009 23:11 użytkownik Jon Cruz <jon@...18...> napisał:

Now here is the elephant you are not seeing. This is *all* link management. For example you say the links that are pasted don't work:

Solution A: Since pasted links are broken, don't link images. Solution B: Since pasted links are broken, fix the pasting of links.

(which solution sounds like proper software engineering?)

The question is moot because the second solution is unimplementable. We cannot "fix the pasting of links" because when we paste pixel data, for example copied from GIMP, there is no file we can link to.

The "common background" thing is a legitimate use of links, but pasting is not an obvious way to do this. When you're pasting something, you do not create links to the original, you make copies of the thing you're pasting. Why you want links, contrary to how every other application works, is completely beyond my comprehension.

And I personally never see an image in the documents folder linked.

???

So, as we refine this and get more of the details on the problems you personally are seeing, it sound more and more like you are being adversely affected by misbehaving pasting/linking. If we fix that, then most of those use cases will be solved... with no need to resort to embedding.

The problem will not be solved by proper linking, it will be made worse (not to mention that it cannot be consistent with the behavior for pixel data as outlined above). Let's go back to the e-mail case. Let's say I paste 3 images from 3 different folders into my document. Now I want to send this to another person. Instead of having all the images in the document's directory, I now need to look for those files around the filesystem, and moreover the links will be broken on the other person's system, because they likely point to different directories.

You can propose some magic code to fix those links but what if the person I'm sending to doesn't have Inkscape and won't be able to run this link-fixing code?

What exactly is wrong with embedding that makes you refer to it as some kind of last resort measure?

Regards, Krzysztof

W dniu 24 grudnia 2009 18:49 użytkownik Jon Cruz <jon@...18...> napisał:

Therefore a simple solution would include just placing a file "PastedImage001.png" in current SVG document's image location.

This is what happens now (only the name is different), and it is what causes broken documents when sending over email. I have received a document broken because of missing pasted images at least once. So it's not a solution, it is the problem. Users will still only send the SVG, and be surprised by broken images, because they didn't remember creating any links.

OK. What I'm trying to point out here is that I don't see the program behavior you do.

You did not answer the critical part of the question, which is "Why you want links, contrary to how every other application works". I remember an earlier response along the lines of "it's more SVG", which I find irrelevant to the non-expert user. The expert user which values "SVG purity" will be more than capable of finding the appropriate options for linking.

To reiterate, I do not want to remove link support. I only want the user to be aware of the fact that he is creating a link, with the action being described as "Create Link" not "Paste". Otherwise he will end up with broken documents.

...

You can propose some magic code to fix those links but what if the person I'm sending to doesn't have Inkscape and won't be able to run this link-fixing code?

This is more of a non-issue. Once we have the use cases page filled out it should become clear. In the meantime hints are "web archive" and "Web page, complete".

Providing a different save mode that includes all linked documents in an archive is interesting, and an useful feature in its own right, but I think it does not address the e-mail case: the user doesn't know he created a link, so it will not occur to him to use the provided save mode. He will just send the bare SVG, like he does with OO.o documents. Finally I don't think many non-expert users think of an Inkscape image as a web page.

I keep stating many reasons, but you continue to ignore them.

If I remember correctly, the arguments against embedding on paste were: 1. SVG gets large, 2. editing the original image externally does not change the display. In my opinion neither is as severe as unexpectedly broken documents. Furthermore, both are fixable.

1 is a minor problem that can be solved by suggesting the user to save in SVGZ if the file is larger than X MB. We should address the problem of large SVGs even when we decide against embedding.

2 is IMO solved appropriately for now: the "edit externally" link is grayed out for embedded images. Editing an embedded image is not trivial, but it can be done using temporary files. I highly doubt your earlier statement that users expect to see the changes in Inkscape after editing the original images, because no other application they can paste images into creates links on pasting.

Regards, Krzysztof

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

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

Here are some points to consider. 1. Wikipedia doesn't count as "SVG for the Web", because it doesn't use any Web-related features of SVG. Submitting an image with links to external media to Wikipedia would result at best with a misrendering and at worst the image would be rejected for security reasons (I didn't test it). 2. SVG has Web-related features, but it is a general purpose format that is often used outside of the Web context, for example for GIS data, in mobile applications, and on the Linux desktop (icons). 3. "Inkscape is a general purpose vector editor" doesn't equal "Inkscape should not have Web-oriented features". It only means that the Web-oriented features should be available for users that explicitly want them.

1. you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
2. 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.

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.

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.

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.

Regards, Krzysztof

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.

...

1. you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
2. 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.

On Dec 27, 2009, at 4:10 PM, Krzysztof Kosiński wrote:

Yes. The group that only knows raster editors is not trivially small. Photoshop is general knowledge and gets quipped about in Hollywood movies (e.g. Casino Royale), and Windows includes a simple raster editor. Corel DRAW and Adobe Illustrator are not general knowledge, and the only system that I know that comes with a vector program preinstalled is Ubuntu Studio. I expect more of the new users of Inkscape to be familiar with raster graphics than with either vector graphics or SVG.

Yes... but you're missing a bit of the big picture here.

Most people don't "use Photoshop" nowadays. Instead they "use CS3" or "use CS4". Especially users who pirate software (the more common Windows-centric user base, etc.)

On Dec 27, 2009, at 4:10 PM, Krzysztof Kosiński wrote:

...

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.

I cite from the reporter's description: "Make a copy of that bitmap as a bitmap (Alt+B) [I do this for editing images in order to keep the original image unchanged]". We can deduce two things from this report:

1. The default behavior is inconvenient in this case. The user wants

to edit his local copy and leave the original unchanged. What he wants is actually an embedded image that can be edited externally through a tempfile.

Exactly. You're again confirming what I've been saying.

2. This expectation comes from knowing Inkscape behavior. Even if a

program does something completely unintuitive but predictable and documented, users will learn this over time. The fact that an established user can predict documented program behavior doesn't convey much useful information.

Actually from a usability standpoint it conveys quite a lot of useful information.

That is the crux of the matter. You're missing out on these "big picture" issues.

...

(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 )

This is about the initial path where the import dialog opens, not about linking vs embedding, see above as well. Sorry but not convinced in the slightest, try again.

Now my turn. These bugs are closely related to linking by default.

https://bugs.launchpad.net/inkscape/+bug/167026 (Images not transmitted over Inkboard, because they are links to files that don't exist on the other side; Inkboard doesn't work any more, but it's still related)

Nope. Not a blocker. In fact, that is easily addressed by correcting behavior and *keeping*linking. In fact, it will make things easier since you won't have as much bloat being sent over the wire at runtime.

Yes, this is a very good use case (did you make sure it's covered in the wiki). But no, it does not prove embedding is the only solution. This only proves that this use case needs to be explicitly addressed.

In fact, if you have some users with Inkboard and several common images, it creates a *far* more usable experience if Inkscape does not exchange any bytes for those shared images. As I look over this, it actually strengthens my opinion that we need to support "linking *plus* media management".

https://bugs.launchpad.net/inkscape/+bug/171085 (User moved files around, did not expect breaking his SVG documents) https://bugs.launchpad.net/inkscape/+bug/169108 (Bitmap copy in an image that wasn't saved yet tries to create a file in Inkscape's install dir, causing a permissions issue when the directory is not writable)

Guess what? This one actually cries out *explicitly* for proper linked media management. As the user requests in that report: "... simple right click on a "broken image" and then be able to update the path for all the images that are in selection?"

I believe that is exactly what I pointed out would solve use cases you added initially. This appears to be the "Sara" use case, and would be solved by the "Sara" solution.

https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG with image links to a website, surprised by broken images. Read the first comment, because the reporter misuses the word "embedded". Apparently linking by default is sometimes confusing even in the Web context!)

Nope. Not a blocker either.

*IF* you had done a scan of bugs with the "big picture" in mind, you would see that related issues come up with an *unsaved* document not having a fixed location. We need to address that issue overall and then guess what? This bug can get fixed by a different bug getting fixed. Kill two birds with one stone.

IMPORTANT: The third bug highlights why your proposed / existing solution to pasting pixel data by storing a pasted image in the document's folder is completely wrong. If the document wasn't saved yet, there is no such folder! We end up saving to some arbitrary location, which is completely unexpected.

But... we are doing that somewhat already. I have looked into the scenario a lot, and there are many things we can do to improve user experience.

The *KEY* here is that we have several interacting issues, and we want to solve the overall experience. We don't want to break one thing here to fix another thing over there.

I acknowledge that bug reports only highlight problems with the existing implementation, and do not highlight problems with the proposed changes, so you are at a disadvantage.

...

No, it is neither bulletproof nor idiot-proof.

How? How in the world is it possible to break an embedded image? (Provide an example.)

I have. Since you don't care to actually address that, it is clear you really are more interested in arguing rather than in fixing.

***PLEASE***

** Update the wiki with use cases and personas

** Come into the chat room like the other developers

Both of these can significantly improve communication and help solve problems.

We also need to consider the worst severity event for each solution. I cannot imagine a situation where temporarily not being able to edit an image externally (the embedded image can be extracted) is more serious than not having it at all, because somebody did not know to send it.

Very good points. Did you include them on the Wiki yet???

The first situation happens when the user still has full access to all data, so fixing the "problem" is as simple as finding the link option. In the second situation the user is missing a piece of data and fixing the problem is impossible without contacting the sender of the broken document.

Again, I distill a key point for the requirements here. "Must solve the problem will full access to data is available"

Please make sure that is covered in the wiki.

Embedding by default might not be completely problem-free, but at least it does not create problems that cannot be addressed within the application (missing data). I acknowledge that no solution is completely idiot-proof, just as there is no absolute safety or absolute security, but some solutions are more resistant to inexperience than others.

A simple fix that addresses this includes what others have proposed. The first time a potentially confusing situation is encountered we just notify the user so that it won't be a surprise. Simple users can choose their most helpful setting, but non-simple users can get the more beneficial one. Also we should include the "don't show me this again" option that is so common in many programs.

Did you ensure this has made it's way onto the wiki?

...

Have you tried?

Yes, I did it to examine how an embedded image's XML looks like. Maybe it wasn't lightning fast, but gedit handled it OK. That was on a 1.1GHz computer with 1GB of RAM, so not a powerhorse by any measure. Digression: the aforementioned average Joe who will use the default will never open the file in a text editor! Anyone who wants to hand edit his document will have no problem overriding the default and creating links.

Ah, but then we have the problem you've already pointed out. User A create artwork and hands it off to user B. User B then suffers the pain.

That is a "meta problem" describing several you've seen and pointed out already, but it applies equally well in this case.

Personally I've had problems trying to edit files with embedded data using emacs and others. Some have gotten so bad as to make emacs unusable on them. (That's quite a feat BTW)

Also, you mention the system you tried to edit on, but what about the size and number of embedded images? We will need to collect up info on ranges so that we can set proper cutoffs or warnings, much like we had to do with our preview dialog. And just like with the preview dialog, if we don't have good details on how certain values are chosen, we will see problems as we go and things change.

On Dec 27, 2009, at 5:16 PM, Jon Cruz wrote:

The *KEY* here is that we have several interacting issues, and we want to solve the overall experience. We don't want to break one thing here to fix another thing over there.

BTW, I just pruned this from the Wiki: "The solution must involve combining raster data with the SVG, so that they reside in the same file."

The reason is that the statement is really taking an opinion and a mistaken assertion at that. There are several different implementations we could choose between to solve the problem, so we'll need to be able to list them out so we can consider them well.

(In fact, I've even written code to bundle things into MIME multipart many times, so that is a completely viable option for solving an "e-mail problem".)

On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:

W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <jon@...18...> napisał:

...

2. This expectation comes from knowing Inkscape behavior. Even if a

Nope. Not a blocker. In fact, that is easily addressed by correcting behavior and *keeping*linking. In fact, it will make things easier since you won't have as much bloat being sent over the wire at runtime.

If the protocol is Jabber, we must base64 encode the image anyway. No gain from linking, and a few complications (the URI has to be different on both sides). http://en.wikipedia.org/wiki/Jabber#Weaknesses

But did you finish reading that paragraph you cite?

The limitation is for *in-band* data transfer. There standard ways that Jabber does *out-of-band* file transfers. This is common for most any instant messaging protocol.

*HOWEVER* you missed the main point. If linked images already exist on both sides, then there is no need at all to exchange them.

And if a linked image does not exist on one side, it is easy to transfer that image once and only once, and for *any* sessions that those systems engage in, including editing many different SVG files in a collaborative manner.

...

As I look over this, it actually strengthens my opinion that we need to support "linking *plus* media management".

This is my opinion as well! But better media management and the default paste/DnD behavior are not the same.

Again, this is exactly where you are not seeing the forest for all the trees.

...

Guess what? This one actually cries out *explicitly* for proper linked media management. As the user requests in that report: "... simple right click on a "broken image" and then be able to update the path for all the images that are in selection?"

Was the user aware of the fact that images can be embedded in the SVG? I think not many users are aware of this because this feature is very poorly discoverable. Also consider that in the email case there is no way to fix the document once the incomplete document is sent - better media management won't help.

Please look over what has been said... even by you in this last paragraph.

Let me try to spell it out for you:

"Was the unser aware..." "...poorly discoverable..." "...no way to fix... once ... is sent..."

Those all call out as signs of a usability issue. There are a few approaches. These include: * It is tricky, so don't do it at all and * It is tricky, so make it clear and simple

Right now the media management is poor in that it does not convey things to users and users get surprised. We *need* to address it so that it is not surprising. Actually that is what you are doing when you suggest to *always* embed images:

Problem: some users are confused by linking vs. embedding of external media assets. Solution: never link external media assets, only embed them. This results in 100% consistent behavior.

That proposed solution *is* better media management. It probably is not the best way to improve it, but it is doing just that. So your assertion that "better media management won't help" is false.

...

I believe that is exactly what I pointed out would solve use cases you added initially. This appears to be the "Sara" use case, and would be solved by the "Sara" solution.

So, what is the "Sara solution"?

Please go back and read things again. Or drop into the chat room like the other developers and users. That *REALLY* helps with communication.

...

https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG with image links to a website, surprised by broken images. Read the first comment, because the reporter misuses the word "embedded". Apparently linking by default is sometimes confusing even in the Web context!)

Nope. Not a blocker either. *IF* you had done a scan of bugs with the "big picture" in mind, you would see that related issues come up with an *unsaved* document not having a fixed location.

The last bug is not related to the default save location, it was related to users not aware of links. Only the 2nd bug was related to the Sara case.

Yes. But my point is that taken in a "big picture" view (i.e. the forest, and not just the trees) a single solution *can* solve both. Taken in the localized view (i.e. trees, and not the forest) it can't.

I see you changed the descriptions of the bugs I mentioned to describe your solutions, which I think are not addressing the fundamental problem, which is: average Joe doesn't know what a link is, and will not benefit from any advantages they might give. Links can only hurt him, by breaking his documents. Embedded images can't, and they are only a very minor nuisance for more advanced users, who will find the commands to create links and will know what they do.

No.

You are the one who changed the *one* description away from the descriptive end-user problem and instead to describe the bug in terms of the proposed solution as you see it. I just put it back.

In particular, the "embed on save as" option will be ineffective, because the unsophisticated user will not know he has to choose it. If we default it to on, then it is completely equivalent to embedding on paste/DnD, but the latter has the advantage of being simpler to implement and not modifying the document when saving (which is a very important conceptual consideration).

No. This is where you are just not getting it. That is also why we *NEED* to have things spelled out clearly in the wiki. A comprehensive solution that solves the whole problem in its entirety will address that.

What you are proposing is a micro-fix that solves things for one group of users at the *expense* of another group. That is the main problem there.

Finally, I see you want to fix each bug with a different and specific solution, while the very simple change of embedding by default on paste and DnD + providing "embed/link" radio buttons in the import dialog would solve them all in one go.

No. You are seeing that completely wrong.

First, "embed" will not solve 100% of things for 100% of people as you claim. Just ask the people on IRC. Or re-read these threads.

More importantly is that again you are incorrectly stating my intent. The key thing is that I do *NOT* want to fix each bug with a different and specific solution. You are the one doing that.

My intent, on the other hand, is to collect up *all* facets of this problem *overall* and then solve them in a comprehensive manner. When combined together, a *few* changes can solve many, many problems.

Look again. "Always embed" may fix some of the use cases you added to the wiki, but it will piss off Sara with her use case.

...

A simple fix that addresses this includes what others have proposed. The first time a potentially confusing situation is encountered we just notify the user so that it won't be a surprise. Simple users can choose their most helpful setting, but non-simple users can get the more beneficial one.

The default for this dialog box would have to be embedding, so it's equivalent to my solution, but with an extra nuisance of a dialog box.

This may or may not work, depending on which user you have. That is critical to grasp. It might solve things for user A, but break things for user B. We need to cover all cases.

Moreover it disregards a well known fact that users don't read message boxes, even if they say "WARNING, CLICKING CANCEL WILL DESTROY YOUR COMPUTER"; this is particularly true for unsophisticated Windows users, which this solution targets. So your solution does not match the target persona (Charlie). What was the point of writing all the stuff on the wiki if you just ignored it?

Not true. At least not the way you state.

Different users look at things to different degrees, and there have even been good presentations and research done on just this point. Go review the work Michael Terry has been doing, especially what he presented at LGM.

Here's a Microsoft account of how dialog boxes are ineffective at informing the user or prompting him to make a choice. http://blogs.msdn.com/oldnewthing/archive/2003/09/01/54734.aspx

Remember, Microsoft is the epitome of bad user interaction. So most anything they present will be discounted.

Another informative blog post. http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html

I also don't like things like "don't show this again" boxes. How do I change the setting I'm asked for later? Even if it's written in the dialog box I'm disabling, I might forget what it said. We should avoid them if possible (and my solution does avoid them).

...

Ah, but then we have the problem you've already pointed out. User A create artwork and hands it off to user B. User B then suffers the pain.

When we look at the case for this perspective, embedding is an obvious winner. In the "Charlie" case, embedding significantly decreases the pain for B. (In fact that was my primary reason to propose it in the first place.)

With linking, it is likely that user A would not send all the needed data. User B would have to contact A, explain to him that he has image links in his document, and prompt him to send them. Then user A might have trouble remembering where is the image he pasted (for example if he DnDed it from a 10000+ photo collection which have camera-given names like "DSC_2657.JPG"), and the whole matter drags out; then user A blames it on Inkscape and never uses it again. User B can text edit the document, but loses a lot more time getting the missing data, and then has to cope with proprietary CDR or AI files user A is sending him.

With embedding, user B has to extract the images before text-editing the document, but he does not need to contact user A and explain anything. We slightly inconvenience the user B, but still do better than in the linking case. User A is completely satisfied.

Again. PLEASE, PLEASE actually enter these use cases you keep coming up with into the wiki.

...

Also, you mention the system you tried to edit on, but what about the size and number of embedded images? We will need to collect up info on ranges so that we can set proper cutoffs or warnings, much like we had to do with our preview dialog.

Definitely could help. My image wasn't very large (a few hundred KB). On my main desktop, which has 6GB of RAM, opening a file containing a large JPG photo (several MB) is effortless; gedit uses 32.9MB for this, so I suppose it's perfectly possible on a modest machine. I'll follow up with more tests later.

Thanks. A table in the Wiki will be of immense value. Also we should check it on a few editors, not just gedit. Notepad comes to mind right off hand.

...

(In fact, I've even written code to bundle things into MIME multipart many times, so that is a completely viable option for solving an "e-mail problem".)

This is irrelevant because we have absolutely no control over how the e-mail is sent, that's why I added that requirement. If you want to invent a new container format that uses MIME multipart, then a more standards compliant and more space-efficient way is just to use embedding. Or you can submit a proposal for SVG 2.0 to include your new container format.

No, it is relevant. There are many ways to get things packaged and sent, and you might be surprised at how the various mail programs behave.

Also... I *HAVE* cited existing container formats, but you keep ignoring such information so I'll will stop now.

Oops, now I see that I confused the names of personas, that's why some of my previous reply was wrong.

I'll try to add more material to the wiki now rather than post here, to prevent the exponential growth in the amount of content that is appearing in this thread.

Regards, Krzysztof.

On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:

Also consider that in the email case there is no way to fix the document once the incomplete document is sent - better media management won't help.

As I was refining the Wiki details, I did a quick listing of some of the types of external asset we might need to support. This is under one of the points on "Issues"

http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management#Issues

Is there any reason to say the need to embed these is any different than that with images in an <image> element? <image> elements to PNG, JPEG, SVG and other images. ICC color profile files (.icc, .icm, etc.) CSS stylesheet files (.css) Cursor files (.cur, .csr) GIMP palette files (.gpl) SwatchBook files (.swb) Script files (.js) WebFonts TrueDoc™ Portable Font Resource (.pfr) Embedded OpenType (.eot) PostScript™ Type 1 (.pfb, .pfa) TrueType (.ttf) OpenType, including TrueType Open (.ttf) TrueType with GX extensions Speedo Intellifont

Second, am I missing any from that list?

On Dec 26, 2009, at 6:13 PM, Krzysztof Kosiński wrote:

2 is IMO solved appropriately for now: the "edit externally" link is grayed out for embedded images. Editing an embedded image is not trivial, but it can be done using temporary files. I highly doubt your earlier statement that users expect to see the changes in Inkscape after editing the original images, because no other application they can paste images into creates links on pasting.

And now this is a point where you really go off from the real world.

1) you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.

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

On Sat, 2009-12-26 at 18:59 -0800, Jon Cruz wrote:

...

1. you might highly doubt users behave that way... but I have

*observed* users behave that way again and again and in many different contexts.

<user view> Linking: Years ago, using a page layout application, the images were linked, and I had to remember to include the original files when sending the layout file. Really no big deal. Linking is the way the web works, so it's easy to understand. It makes sense to me not to include binary data in a text based XML file format such as SVG.

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 - which in my view, is one of the key features of SVG for future-proofing and digital archiving. </user view>

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?

Or perhaps a warning on save that can be turned off by expert users?

'you have pasted / inserted an external bitmap image in this file, would you like to save as compressed svg with media'?

- Donna

2009/12/24 Krzysztof Kosiński wrote:

for pixel data as outlined above). Let's go back to the e-mail case. Let's say I paste 3 images from 3 different folders into my document. Now I want to send this to another person. Instead of having all the images in the document's directory, I now need to look for those files around the filesystem, and moreover the links will be broken on the other person's system, because they likely point to different directories.

File - Collect for output.

This is how this has been solved for years :) Even in Scribus.

Alexandre

Alexandre Prokoudine wrote:

On 10/23/09, Krzysztof Kosiński wrote

...

You say that 50% of people prefer linking and 50% prefer embedding. I am certain this is not true.

And I am certain that you never run a survey on that :) As a matter of fact both embedding and linking are equally valid in desktop publishing world.

As a user I do have use-cases for both linking and embedding. But it would be nice if it would be clear to me if the image is linked or embedded and when it's linked, how it's linked. I use dropbox a lot to work between different computers and somehow when I move from windows to OS X or linux the link is gone, whilst the linked image is sitting right next to the SVG file.

So for me it doesn't really matter what's the default approach as long as it is clear what is happening.

On a side note, Krzysztof does have a point that many users who are not used to the DTP world are most likely baffled by the linking principle. So a little help there is not a bad idea.

regards, Steven

2009/10/23 Alexandre Prokoudine <alexandre.prokoudine@...400...>:

And I am certain that you never run a survey on that :) As a matter of fact both embedding and linking are equally valid in desktop publishing world.

Again: I do not claim that links are useless, or that less than 50% of people ever use links. We can play with words but the fact remains that a new user expects the document to be self-contained. In other words, if you don't know what you want, you most certainly don't want a link, because your document will break as soon as you move files around or send it to someone else. If you want a link, you should say that you want a link.

Regards, Krzysztof

Good. I see we're arriving at a consensus :)

2009/10/23 Jon A. Cruz <jon@...18...>:

Well... yes....

But a new user also expects his files to not increase in size by 33%. A new user also expects SVG to be small.

Possible solution: prompt about saving in SVGZ when there are many images (for example, over 500kb of image data).

A new user also expects that when he edits an image in his "document" that the changes will show up.

If you mean allowing to edit an embedded image in an external program, I admit that it will be challenging. Here are possible solution: 1. Create a temporary file and wait until the program closes. Might not be doable cross-platform. 2. Display a modal dialog that says "click OK when you're done editing". Ugly. 3. Hybrid link: embed an image but watch an external file for changes. When the linked image changes, update the embedded copy. When the linked image disappears, drop the link and only keep the embedded portion.

W dniu 23 października 2009 22:23 użytkownik Steren <steren.giannini@...400...> napisał:

2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>

• For import : Put a drop-down menu in the import dialog, on "Embed" by

default.

+1

• For copy/paste : embed, the user will the use the "Image properties" if he

wants to create a Link

+1

• For Drag and drop : Ask every time the user if he wants to create a Link

or to embed. Allow hom to tick a box that says "always use this choice" (this property can also be reach in the userpreferences)

+1 - if it's for files dragged from Explorer/Nautilus. DnDing something that is not a file on the hard disk should always embed (it doesn't make much sense to do otherwise).

Proposed solution B: Change the UI to clearly show the difference between linked and embedded images.

+1

Proposed solution C: Add a popup that explains to a new user what linking vs. embedding is.

Taking into account the Windows conditioning to click "OK" on everything without reading it, especially if "OK" is the only choice, the popup is likely to be dismissed without looking at it.

FYI, there are UI and Free Desktop conventions to allow a user to have a "choose" action on drop.

AFAIK the convention in X/Gnome/KDE is middle button drag which is HARD to do on some wheel mice, so I think we shouldn't rely on it too much. The Windows convention of right button drag is better in this respect.

2009/10/23 Jon A. Cruz <jon@...18...>:

Inkscape is targeting being the "best SVG editor" out there. Note that it is not the "best vector editor". This is a subtle yet important point that was actually involved in the project's formation.

Embedding images in data: URLs is a valid SVG feature. I think there is no conflict between those goals in this particular case.

2009/10/23 Steren <steren.giannini@...400...>:

Concerning Solution B: Notice that the current UI show a difference : in the status bar, "Embedded" or the path of the image are written. But I'm ok to say that it's not clear enough. In this status bar, I would propose to not talk about *Image* but to always talk about *Embedded Image* or *External Image*

What about Image and Link to Image? Just like 'Clone of' right now. We might have different kinds of links in the future.

Regards, Krzysztof

On Oct 23, 2009, at 1:23 PM, Steren wrote:

• For Drag and drop : Ask every time the user if he wants to create

a Link or to embed. Allow hom to tick a box that says "always use this choice" (this property can also be reach in the userpreferences)

FYI, there are UI and Free Desktop conventions to allow a user to have a "choose" action on drop.

-----Original Message----- From: Jon A. Cruz [mailto:jon@...18...] Sent: vrijdag 23 oktober 2009 22:24

Oh, and please keep one point in mind.

Inkscape is targeting being the "best SVG editor" out there. Note that it is not the "best vector editor". This is a subtle yet important point that was actually involved in the project's formation.

Is this true? It makes me sad reading it. :-/

-Johan