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