On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:
> W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <jon@...> 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).
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..."
"...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
* 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
>> 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.
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.
Remember, Microsoft is the epitome of bad user interaction. So most anything they present will be discounted.
> Another informative blog post.
> 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
> 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.