[Inkscape-devel] Specification: Improved image properties dialog (0.48)

[Guillermo Espertino]

Hi:
I created a blueprint based on some ideas discussed in
https://bugs.launchpad.net/inkscape/+bug/172162

It's a specification of an improved image properties dialog that
(hopefully) would tackle some annoying aspects of image links management
in inkscape.
I've received valuable ideas from ~suv and Steren Giannini and the
specification is starting to look very good, so I'd like to propose it
as a feature for the next version of Inkscape.

The blueprint:
https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enhancements

I'd really love to know your oppinions about it, and get as many
suggestions, critics, ideas or questions you might come up with to make
it better.

Gez.

[Steren]

Hi,
I think a project aimed at improving image management in Inkscape would be
great for students fromEcole Centrale Lyon. If you think it's a good idea, I
could mentor a team of students that could work on this. (The same kind of
work than we've done in the past : LPE for groups, stacking and envelope 2
years ago and Spray tool last year).

Concerning the smart broken link feature:
Gez was worried about the time image path replacement would take. But in
fact, once the system has found the new paths, it is only a replacement of
XML attrributes. I think it doesn't cost computation time at all. Gez
mentioned computation time needed when ungrouping a large group of objects,
I think this is due to big XML manipulation. Here it's only an attribute
replacement. But I may be mistaken, someone can help us ?

I still want to discuss about the ID field. I don't think it is a good idea
to put it in "Image Properties". For me the user identify the image by
either a thumbnail or the path.
The ID field is already accessible in the "Object Properties" window. The
user case Gez mentioned that uses ID is web design (we can consider that for
artistic work, keeping all IDs meaningful is too much work). I think the
"Object Properties" window is sufficent and may be more the window to open
when doing web design.
So I would vote to remove ID from the top of Image properties. We can remove
it completely or move it to "show image details"

A last point to discuss is an Image manager. I described it in my initial
blueprint: http://wiki.inkscape.org/wiki/index.php/Image_links_manager
I think the enhancement of the image properties window is great. And I
wonder if an other window that regroups all the images currently in the
document can be useful. This is to discuss.

Steren.

[Rock Star]

Hi,

I really like the blueprint, but there's one more thing i'd add to it. Some
button for reseting the image size or width/heigh ratio.

In my work flow I usually have images linked and not embedded, because I
often change them in some external program like Gimp. However, it's not that
unusual that I have to change width/height ratio. Since (according to my
knowledge) Inkscape defines the size of the images by means of pixels, new
pictures, which have different w/h ratio are distorted and I have to correct
that manually. Hence, a button, which would reset the image size would be
most helpful.

Best regards,
Rok

P.S.: The first time I sent the mail I sent it only to Gez.

Post by Guillermo Espertino
I created a blueprint based on some ideas discussed in
https://bugs.launchpad.net/inkscape/+bug/172162
It's a specification of an improved image properties dialog that
(hopefully) would tackle some annoying aspects of image links management
in inkscape.
I've received valuable ideas from ~suv and Steren Giannini and the
specification is starting to look very good, so I'd like to propose it
as a feature for the next version of Inkscape.
https://blueprints.launchpad.net/inkscape/+spec/image-properties-dialog-enhancements
I'd really love to know your oppinions about it, and get as many
suggestions, critics, ideas or questions you might come up with to make
it better.
Gez.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Steren]

Post by Rock Star
I really like the blueprint, but there's one more thing i'd add to it. Some
button for reseting the image size or width/heigh ratio.

Hi,
Indeed, I also had this kind of issues (I was working with sponsors logos,
and had to change them for other sponsors).

But to reset the image size would be too much, reset the ratio is better
IMO.
Here is an example :
- The original image is 100x50 and is 200x100 in Inkscape.
- You edit this image in gimp and make it 400x100.
- What you want when you come back to Inkscape is an image that is 200x50 in
Inkscape.

So this button should keep one Inkscape dimension (say Width, or the bigger
or the smaller), and re-compute the other Inkscape dimension (say Height)
considering the new image dimensions.
What do you think ?

Steren

[Alexandre Prokoudine]

Post by Guillermo Espertino
I created a blueprint based on some ideas discussed in
https://bugs.launchpad.net/inkscape/+bug/172162
It's a specification of an improved image properties dialog that
(hopefully) would tackle some annoying aspects of image links management
in inkscape.

IMO, if you want to control size, you also need to choose
interpolation method that suits best.

Alexandre

[Guillermo Espertino]

I added Rok's suggestion to the specification.
About its implementation, I agree with Steren's idea: let's use a button
for matching original aspect ratio keeping the larger dimension and
modifying the smaller.
That would be the very useful to solve a very common situation: You
imported an image, then you want to crop it (for instance, you have a
sponsor logo with a lot of transparent space around and you want to get
rid of that empty space and leave the logo only).

Thanks for the feedback.

Gez.

p.s.: Steren, It'd be great if you could mentor a team of students to
work on this feature. It can be made in different stages and it doesn't
look too complicated to be finished in a short term.

[Oleg Koptev]

very small wish -
http://wiki.inkscape.org/wiki/index.php/Talk:Image_links_manager(boobaloo's)

[Alexandre Prokoudine]

Post by Oleg Koptev
very small wish -
http://wiki.inkscape.org/wiki/index.php/Talk:Image_links_manager(boobaloo's)

This won't work, sorry. Double-click on any object with Selector tool
toggles rotation/skew mode. You don't really expect Inkscape to have
special cases for Selector, eh? :)

Alexandre

[Oleg Koptev]

heh, actually atm Selector HAVE 'special' cases like you say :)
let's try - If you double click (REAL double click - i.e. fast click)
the group - it will ungroup, and then - if you double click onto
vector object - it will switch to Node editing, isn't it? :)
The skew/rotation triggered by single click btw.

So why the raster image couldn't go to raster editor for some
transformation, like vector object do? This is very intuitive way I
think.

Post by Alexandre Prokoudine
This won't work, sorry. Double-click on any object with Selector tool
toggles rotation/skew mode. You don't really expect Inkscape to have
special cases for Selector, eh? :)
Alexandre

[Oleg Koptev]

Post by Oleg Koptev
If you double click (REAL double click - i.e. fast click)
the group - it will ungroup

for sure you will go into group instead of ungroupping the group.
sorry for tautology. but it didn't turn the sense imho.

[Krzysztof Kosiński]

Post by Guillermo Espertino
I created a blueprint based on some ideas discussed in
https://bugs.launchpad.net/inkscape/+bug/172162
It's a specification of an improved image properties dialog that
(hopefully) would tackle some annoying aspects of image links management
in inkscape.

I think that links are confusing for users not familiar with SVG, and
should be only created with explicit commands for image linking. By
default all images should be embedded. This is what users expect. For
example, import, drag and drop, opening or pasting an image should
embed it. A link should only be created if the user selects a command
named 'Insert Image Link'.

Of course, that doesn't mean we should make image links easier to use,
just that we should not default to creating them.

Regards, Krzysztof

[Alvin Penner]

Post by Krzysztof Kosiński
I think that links are confusing for users not familiar with SVG

I agree strongly. There are a significant number of bug reports that
have been complicated a great deal by the fact that users did not realize
that they were using links, they assumed the objects were embedded.

Post by Krzysztof Kosiński
Of course, that doesn't mean we should make image links easier to use,

just that we should not default to creating them.

I assume you probably meant : Of course, that doesn't mean we should make
image links less easy to use, just that we should not default to creating
them.

[Krzysztof Kosiński]

Post by Alvin Penner
I assume you probably meant : Of course, that doesn't mean we should make
image links less easy to use, just that we should not default to creating
them.

Exactly :)

Regards, Krzysztof

[Steren]

Post by Krzysztof Kosiński
I think that links are confusing for users not familiar with SVG

Indeed, I also share this opinion.

But for users comfortable with SVG and links, they should be able to use
Link on import.
I would propose to set a user preference : "Default behavior for image
insertion" that would be "Embed" by default and could also be "Link"

Steren

[Jon A. Cruz]

Post by Alvin Penner
I agree strongly. There are a significant number of bug reports that
have been complicated a great deal by the fact that users did not realize
that they were using links, they assumed the objects were embedded.

Post by Krzysztof Kosiński
Of course, that doesn't mean we should make image links easier to use,

just that we should not default to creating them.

What it comes down to is that you will confuse half the users,
depending on which way you default. That is, if you default to only
linking images you will confuse/annoy those who expect embedded.
However, if on the other hand you default to always embedding images,
you will confuse/annoy those who expect linked.

A simplistic approach of a solution is to merely switch the default.
However what generally happens in these cases (and specifically in
this one) is that you are seeing bug reports from those who don't like
the current behavior, but you see no feedback at all from those who
are happy with the current behavior. People really only speak up when
something bothers them. So you will make the second half of the users
happy at the expense of the first half.

Taking a step back to the higher level, this issue is really one of
confusion on what is happening. The program's behavior is not clear,
and thus people get confused. The real solution is to change the UI
and workflow to make it very clear to users what is going on. *Part*
of that solution is to allow a user to set the default behavior as
needed for that specific user. But a *prior* step is to clearly
communicate to the user what is actually happening, what those choices
are, etc.

BTW, we have looked at this issue for some time, and there are severe
consequences to making embed the default. We definitely need to
remember to keep those in mind as we make changes.

[Thorsten Wilms]

Post by Jon A. Cruz

Post by Krzysztof Kosiński

Post by Krzysztof Kosiński
Of course, that doesn't mean we should make image links easier to use,

just that we should not default to creating them.

What it comes down to is that you will confuse half the users,
depending on which way you default. That is, if you default to only
linking images you will confuse/annoy those who expect embedded.
However, if on the other hand you default to always embedding images,
you will confuse/annoy those who expect linked.

Indeed.

Having a switch in preferences would be bad, because the user has to be
aware o what it is set to. Also means you have to first go there if you
need to change it depending on project-specific needs.

An option in Import dialog would be better. Or even having 2 entirely
separate actions.

Of course that wouldn't answer what to do in the drag-and-drop case :/


As this issue affects all kinds of graphic and sound applications, I
have been thinking about a solution on another level. This would require
linking to objects via IDs, so you can move stuff around without
breaking links. Dependency tracking and automatic bundling once your
stuff leaves your system.

[Krzysztof Kosiński]

(Sorry, resending this to list - the Gmail interface defaults to a
private reply and I keep making the mistake)

Post by Jon A. Cruz
A simplistic approach of a solution is to merely switch the default.
However what generally happens in these cases (and specifically in
this one) is that you are seeing bug reports from those who don't like
the current behavior, but you see no feedback at all from those who
are happy with the current behavior.

I don't want just to flip the default, I want to change the behavior
of the existing commands (import and paste) so that it follows
intuition, and add new commands that explicitly expose the link
behavior (see below).

Post by Jon A. Cruz
BTW, we have looked at this issue for some time, and there are severe
consequences to making embed the default. We definitely need to
remember to keep those in mind as we make changes.

What are those issues?

Note that the current behavior is wrong on many levels:
- For pasting, we create a PNG file in the same directory as the
edited file with a crazy name like
inkscape_pasted_image_20091023_144102.png  and link it.
- For importing via drag-and-drop, we embed.
- For importing via the dialog, we make a link.
The defaults are inconsistent, and the paste case is completely bogus
because 1. It attempts to write to the directory where the doc is
located, which may not be permitted (the directory and the doc might
be read-only); 2. It creates a crazy filename; 3. It breaks when the
user relocates the document. More importantly we cannot create links
to things that might not even be in a file (like pasting pixels from
GIMP).

Therefore we should default to embedding on paste and DnD, and have 2
import commands: Import, which embeds, and Link Image, which creates a
link. Note that this will make Import behavior consistent across all
formats. When importing SVG or other vector formats, we never create a
link.

Regards, Krzysztof

[Jon A. Cruz]

Post by Krzysztof Kosiński
I don't want just to flip the default, I want to change the behavior
of the existing commands (import and paste) so that it follows
intuition, and add new commands that explicitly expose the link
behavior (see below).

But you are missing the most IMPORTANT point here.

You are thinking of *your* intuition. There is roughly half the user
population who's intuition is the *opposite* of yours.

That is the tricky part. For some problems there is a common/unified
solution, but for this one there is not.

[Jon A. Cruz]

Post by Krzysztof Kosiński
- For pasting, we create a PNG file in the same directory as the
edited file with a crazy name like
inkscape_pasted_image_20091023_144102.png and link it.
- For importing via drag-and-drop, we embed.
- For importing via the dialog, we make a link.
The defaults are inconsistent, and the paste case is completely bogus
because 1. It attempts to write to the directory where the doc is
located, which may not be permitted (the directory and the doc might
be read-only); 2. It creates a crazy filename; 3. It breaks when the
user relocates the document. More importantly we cannot create links
to things that might not even be in a file (like pasting pixels from
GIMP).

I agree, especially for pasting. Someone reworked the code in an
"interesting" way that breaks down under many scenarios. This is just
one of them.

Post by Krzysztof Kosiński
Therefore we should default to embedding on paste and DnD, and have 2
import commands: Import, which embeds, and Link Image, which creates a
link. Note that this will make Import behavior consistent across all
formats. When importing SVG or other vector formats, we never create a
link.

However... I don't think the "Therefore" actually quite matches. Among
other issues, a drag-n-drop is actually a complex paste operation (and
thus shares paste code). So I think the code is doing a few things you
don't expect.

Also for the import case, embedding will break things for many, many
users. We've looked at that a few times.

The good solution is to create a "media manager" that handles things
like images, linked css files, ICC profile files, etc. Things can then
be worked out with the UI and perhaps a "Publish" menu/command that
does things a bit more explicitly than "save as" or "export".

You're on the right track about things. I think we just need to get a
solution that is comprehensive and throughout the entire program and
not just fix smaller bugs one at a time.

[Steren]

Post by Jon A. Cruz
The good solution is to create a "media manager" that handles things
like images, linked css files, ICC profile files, etc. Things can then
be worked out with the UI and perhaps a "Publish" menu/command that
does things a bit more explicitly than "save as" or "export".

This is a point I raised in my first post to this thread, I asked for
feedback but didn't get any. I did a few days ago (before starting initial
discussion with Gez) a blueprint for an Image Manager. (find it here
http://wiki.inkscape.org/wiki/index.php/Image_links_manager note that it
doesn't take into account all the remarks and things we've said since). This
Image manager can be extended to "Media Manager".

My discussion with Gez made me question the utility of such a window. We
need your opinions.

Steren

[Krzysztof Kosiński]

W dniu 23 października 2009 17:18 użytkownik Jon A. Cruz

Post by Jon A. Cruz
You are thinking of *your* intuition. There is roughly half the user
population who's intuition is the *opposite* of yours.

You say that 50% of people prefer linking and 50% prefer embedding. I
am certain this is not true. Most people expect the image to stay in
place. When you send an email attachment, it is not a magical link to
the data on your computer. When you paste an image into a Word / ODT
file, it is not a link to that file on your hard disk. When you paste
SVG elements from another document, they do not magically become a
link to that second document.

Post by Jon A. Cruz
However... I don't think the "Therefore" actually quite matches. Among other
issues, a drag-n-drop is actually a complex paste operation. So I think the
code is doing a few things you don't expect.

Drag and drop is currently not related to pasting, because drag and
drop is implemented in src/interface.cpp, and pasting in
src/ui/clipboard.cpp. They don't use the same code path. In fact the
import code is simpler, because imported / dragged items are put into
a group. Not sure if that's what you meant.

Post by Jon A. Cruz
Also for the import case, embedding will break things for many, many users.
We've looked at that a few times.

For who, and in what cases? You sometimes say that a proposed solution
will cause 'important issues for many users', but don't say what those
issues actually are.

Post by Jon A. Cruz
The good solution is to create a "media manager" that handles things like
images, linked css files, ICC profile files, etc.

This would be great to have, along with UI improvements to enable
using common styles. The image links manager proposed in this thread
is a good start, and could be extended to Still, I think this is
orthogonal to what the defaults are.

Post by Jon A. Cruz
Things can then be worked
out with the UI and perhaps a "Publish" menu/command that does things a bit
more explicitly than "save as" or "export".

I think that "Publish" is a stupidity cloned from Corel Draw. Why
should saving a PDF be completely different from saving any other
file? Moreover the name is misleading: you are actually not
'publishing' anything in the sense of showing it to the outside world.
You are only saving a file. A better name is "save standalone
document" or something like this, but I don't see a difference between
this and Export.

Regards, Krzysztof

[Steren]

Post by Krzysztof Kosiński
When you paste an image into a Word / ODT
file, it is not a link to that file on your hard disk.

Actually, OpenOffice.org is sometimes using Links, I'm not an expert but I
used it in the past.
Try out with OpenOffice.org :
- Create a document

[Krzysztof Kosiński]

(unintended private email, again... -_-)
W dniu 23 października 2009 21:37 użytkownik Steren

Post by Steren

Post by Krzysztof Kosiński
When you paste an image into a Word / ODT
file, it is not a link to that file on your hard disk.

Actually, OpenOffice.org is sometimes using Links, I'm not an expert but I
used it in the past.
- Create a document
- Insert > Picture >

[kaver]

2009/10/23 Krzysztof Kosiński <***@gmail.com>

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
***@comcen.com.au

[Krzysztof Kosiński]

W dniu 23 października 2009 22:08 użytkownik kaver

Post by kaver

Post by Krzysztof Kosiński
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.

Yes, you can have links in Word documents. Yes, they are useful,
sometimes indispensible. But you never get them if you don't say that
you want them! If you don't say that you want a link, you get an
embedded image! 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.

Regards, Krzysztof

[Jon A. Cruz]

Post by Krzysztof Kosiński
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.

[Steven M. Ottens]

Post by Jon A. Cruz
Problem: Inexperienced users are breaking their documents.
Proposed solution A: Change the "Import" command for all so that it
embeds instead of links.

+1

[Jon A. Cruz]

Post by Jon A. Cruz
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]

Post by Jon A. Cruz
Problem: Inexperienced users are breaking their documents.
Proposed solution A: Change the "Import" command for all so that it embeds
instead of links.
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

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*

[Steven M. Ottens]

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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

[Alvin Penner]

this may already have been answered somewhere, but my question is: Can the
embedding process be made to be totally reversible? I mean, you may start
out with a link, change your mind to embed and then go back to a link. Can
this be done in such a way that there are no redundant or duplicate links
and you get back the original file size before embedding?

[J***@joncruz.org]

Post by Steven M. Ottens
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

[Krzysztof Kosiński]

Post by J***@joncruz.org
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.
Regards, Krzysztof

[Krzysztof Kosiński]

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

[Jon Cruz]

Post by Krzysztof Kosiński
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

Well... inotify is a nice idea, but has some significant use issues.

But more importantly that is only one way to do such code. There are
many other ways to do it. And most significant is that Inkscape
already has such code and is doing such watching and updating.

[Jon Cruz]

Post by Krzysztof Kosiński

Post by J***@joncruz.org
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.

[Jon Cruz]

Post by Jon Cruz

Post by Krzysztof Kosiński
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.

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

It's been two months now, and having half-done personas is blocking progress. Among other things we have teams of students who are going to work on this and two potential commercial groups (one with Scribus in Europe, another in Brazil) looking to move here, so we need to have things pinned down as well as we can before they start hashing out designs and implementations.

We also need to get these settled out so that we can unify things with the overall personas we're building up at http://wiki.inkscape.org/wiki/index.php/Marketing_Scratchpad#User_Personas

If you don't have time, let us know so that we can go in and guess at a cleanup.

Thanks.

[Krzysztof Kosiński]

Post by Jon Cruz
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

[Joshua A. Andler]

Post by Krzysztof Kosiński

Post by Jon Cruz
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?

Age & occupation gives one an idea of how well they may adjust to
change. Generally speaking, younger and less "formal" people adjust much
more easily. Not joking, the attorney that I used to work for didn't
know that in Windows that you can MOVE the windows around the screen...
and she was a computer user since the 3.1 days. She couldn't work that
change into how she operates a computer.

Occupation helps determine what type of expectations they may have going
into something. My old co-workers expected things to work how they
expected them to work (which was all different, seemingly based on
position).

It gives an idea of their potential level of experience with this type
of software. A 20 year old construction worker has much less experience
than a career 50 year old graphic designer when it comes to a graphics
application. The same goes for if it was a 20 year old graphic designer
vs a 20 year old construction worker. It should also be noted that this
is also why side interests and hobbies matter... that 20 year old
construction worker may have been a graphics hobbyist for a long time.

I can keep going, but I hope this is illustrating the point well enough.

Cheers,
Josh

[Krzysztof Kosiński]

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

[Joshua A. Andler]

Post by Krzysztof Kosiński
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?

This is one small part of a larger piece of their project though. If
they apply these personas to their entire project it could help them to
produce more consistent and usable UI design choices. I'm assuming this
relates to the French students' "better image management" project which
addresses a bit more than this.

Cheers,
Josh

[Jon Cruz]

Post by Krzysztof Kosiński
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"

[Krzysztof Kosiński]

Post by Jon Cruz
You're seeing the trees but not the whole forest.

The third paragraph was unnecessary, because I understand metaphors.
What I don't, is how they apply to the situation at hand. What is the
forest?

How would fixing the image pasting issue create new problems? I cannot
imagine a situation under which the current behavior is the desired
one.

Post by Jon Cruz
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.

Regards, Krzysztof

[Jon Cruz]

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

[Jon Cruz]

Post by Krzysztof Kosiński

Post by Jon Cruz
You're seeing the trees but not the whole forest.

The third paragraph was unnecessary, because I understand metaphors.
What I don't, is how they apply to the situation at hand. What is the
forest?
How would fixing the image pasting issue create new problems? I cannot
imagine a situation under which the current behavior is the desired
one.

No, it actually was necessary, since we are seeing that problem.

The elephant metaphor is also a very common one, and used often in software development.
http://en.wikipedia.org/wiki/Blind_men_and_an_elephant

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

As has been pointed out before, that's only half the problem. You get one set of users happy at the expense of the other set.

One of the newly created problem there would be "Hey! I keep editing this in GIMP, but my changes never show up". 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". There are more, but I'll try to get those cleaned up and on the wiki now that I can see which ones are covered there and which are not.

Oh, and to explain what the "forest" problem actually is. The big-picture is more of "user gets confused by our handling of external media". When phrased that way, we see your preferred solution turns into "Make Inkscape never support external media", which now appears to be both a solution and a problem and no longer merely a solution.

Also once the big-picture is seen in that phrasing, we can see that we need to support CSS files, ICC files, Palette files, *other* SVG files and many others, and not just have a solution for images and only images.


I think the 'meta-fix' here is to try to address "help users not be surprised by behavior with external assets." For one set of users, losing attached files is surprising. However, for another set of users having SVG files bloat hugely, lose shared results, etc. is surprising. Let's address a single unified solution that will solve the whole problem, not one that fixes part at the cost of another part.

[Jon Cruz]

Post by Jon Cruz
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"

[Krzysztof Kosiński]

Post by Jon Cruz
One of the newly created problem there would be "Hey! I keep editing this in
GIMP, but my changes never show up".

Pasting an image into Inkscape does not allow you to edit it and have
the changes show up in the document - it is not the original image
that is linked, it is the copy in the document's folder. The feature
you don't want to break does not actually exist. Moreover people have
no such problems with apps like OpenOffice.org which embed by default.

Post by Jon Cruz
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.

Post by Jon Cruz
When phrased
that way, we see your preferred solution turns into "Make Inkscape never
support external media"

The links made through pasting are useless. They point to images with
bogus filenames. If this is the only way to create a link to an image,
then we do not actually support links.

Post by Jon Cruz
Also once the big-picture is seen in that phrasing, we can see that we need
to support CSS files, ICC files, Palette files, *other* SVG files and many
others, and not just have a solution for images and only images.

Those other files are not directly related to this problem because you
do not paste them into documents. We can address link management
separately.

Regards, Krzysztof

[Jon Cruz]

Post by Krzysztof Kosiński

Post by Jon Cruz
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)

[Jon Cruz]

Post by Krzysztof Kosiński

Post by Jon Cruz
One of the newly created problem there would be "Hey! I keep editing this in
GIMP, but my changes never show up".

Pasting an image into Inkscape does not allow you to edit it and have
the changes show up in the document - it is not the original image
that is linked, it is the copy in the document's folder. The feature
you don't want to break does not actually exist. Moreover people have
no such problems with apps like OpenOffice.org which embed by default.

Post by Jon Cruz
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.

Post by Jon Cruz
When phrased
that way, we see your preferred solution turns into "Make Inkscape never
support external media"

The links made through pasting are useless. They point to images with
bogus filenames. If this is the only way to create a link to an image,
then we do not actually support links.

Post by Jon Cruz
Also once the big-picture is seen in that phrasing, we can see that we need
to support CSS files, ICC files, Palette files, *other* SVG files and many
others, and not just have a solution for images and only images.

Those other files are not directly related to this problem because you
do not paste them into documents. We can address link management
separately.

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

In this case I think we're seeing a side effect of the ad-hoc way image pasting was changed. For clipboard operations, many data "flavors" are offered. Someone changed the code to take all image types that could be found, in the order they happen to be in the system. (It is drawing from those supported by GdkPixbuf and from our import extensions). The refinement needs to be to order things to look for preferred data flavors first. And a few of those data flavors are proper links that can be used.

And I personally never see an image in the documents folder linked. Thus your experience does not apply to my use cases. However I will *not* say that since I never see a problem it would mean that you are never seeing one.


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.

And then other use cases will clearly need to have different solutions applied. For example, the one you have for "Sara" would be solved by Inkscape noticing that those files are missing and popping up a search dialog to locate one of them (the rest will most often be found by using the base path of the first one manually located).




So, thanks. I think we have just discovered that you have at least one system that is exposing major bugs in our clipboard implementation. Before anything else it is probably quite important to fix those.

[Krzysztof Kosiński]

Post by Jon Cruz
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.

Post by Jon Cruz
And I personally never see an image in the documents folder linked.

???

Post by Jon Cruz
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

[Jon Cruz]

Post by Krzysztof Kosiński
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.

No, not at all. Just because you can't see the solution doesn't mean that others can't.

In my observations and in various testing, the case you mention of pasting raw image data straight from a drawing program is a minority case. If you happen to do that most of the time, just be aware that you are a user who could be in the minority.

However... you are wrong that there is no file we can link to. In fact, in one of your earlier mails you complained about the location the pastefile was located at. Therefore a simple solution would include just placing a file "PastedImage001.png" in current SVG document's image location. (note that in the simple case this would be the location of the SVG file being pasted to, but not in other cases)

Post by Krzysztof Kosiński
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.

Post by Jon Cruz
And I personally never see an image in the documents folder linked.

???

OK. What I'm trying to point out here is that I don't see the program behavior you do. Most likely it is due to me using things differently. Or it might be a difference of operating systems. Whatever the case, the key point is that I myself (notice that I'm not projecting my experience to be the universal one) do not see the problem you describe encountering.

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

No, it will be solved. And as for the pixel data case, that is an edge case. We shouldn't have the main uses dominated by an edge case's behavior. Four of the five use cases currently on the wiki fall square in the main case (as opposed to edge cases).

The rest of that paragraph sounds like a good use case. Can you please be sure it gets into the wiki page for them? That's really the place to raise and answer such concerns.

Oh, and what you describe is covered by the combinations of changes/features that I've been working out to fix the situations. It fits squarely in the "big picture" problem, and will be solved by the "big picture" solution.

Post by Krzysztof Kosiński
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".

Post by Krzysztof Kosiński
What exactly is wrong with embedding that makes you refer to it as
some kind of last resort measure?

I keep stating many reasons, but you continue to ignore them. This makes me believe you are not so interested in fixing Inkscape as you are in continuing an argument. Since this seems to be hard for you to track, I'll try to get the wiki page on use cases filled out with these details as soon as I have time. (bit busy with family these couple of days)

[Krzysztof Kosiński]

Post by Jon Cruz
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.

Post by Jon Cruz
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.

Post by Jon Cruz

Post by Krzysztof Kosiński
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.

Post by Jon Cruz
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

[Jon Cruz]

Post by Krzysztof Kosiński
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.

Actually I think this one point is a bit of a misleading argument.

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.

Now... one has to remember that this is initially a *web* graphic format. So we really should compare to *web* document programs.

If you look at HTML and various web tools, you will see the exact same non-embedded behavior.

More importantly, if one looks to the *web designer* community, you will see the average user is not surprised by linked images, and in fact is more often expecting them.

So we might also have to say "Non-web users will be confused." This point might be one of the better differentiating ones.

[Krzysztof Kosiński]

Post by Jon Cruz
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

Post by Jon Cruz
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.

Post by Jon Cruz
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.

Post by Jon Cruz
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.

Post by Jon Cruz
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.

Post by Jon Cruz
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

[Alexandre Prokoudine]

Post by Krzysztof Kosiński

Post by Jon Cruz
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

FYI, linking was discussed in GIMP dev list and actually does make
sense in many cases.

[Jon Cruz]

Post by Krzysztof Kosiński

Post by Jon Cruz
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"

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński

Post by Jon Cruz
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 )

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

[Krzysztof Kosiński]

Post by Alexandre Prokoudine
FYI, linking was discussed in GIMP dev list and actually does make
sense in many cases.

[Jon Cruz]

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

[Jon Cruz]

Post by Jon Cruz
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.

What straw-man? You say that Inkscape should be an SVG editor at the
expense of average Joe usability. I say that Inkscape should be
average-Joe-useful at the expense of rather abstract "SVG purity"
(abstract, because embedded images are 100% SVG compliant). I don't
see where's the misrepresentation. Do you claim that links are more
intuitive for the casual user? The question was very simple. If you
decline to answer it then I have reason to believe the answer is not
favorable to you.

Ah, but that is *EXACTLY* the straw-man I was talking about.

I never said "at the expense of average Joe usability". You tried to put those words in my mouth so that you could knock them down. That is the classic straw-man argument.

Since you are arguing against something *different* than what I'm actually saying, the argument you make is invalid.

[Jon Cruz]

Post by Jon Cruz
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
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.

Post by Jon Cruz
(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.

Post by Jon Cruz
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?

Post by Jon Cruz
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.

[Jon Cruz]

Post by Jon Cruz
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.

I've done some base testing with current trunk, and I'm not seeing this.

That is, When I try pasting into an unsaved document things get placed in an expected location and the same one used when "Save" or "Save as..." is chosen.

So if anyone is still seeing issues, please record exactly how this is happening (OS, trunk or .47, preference checked or unchecked, etc.) into the wiki.

Thanks.

[Jon Cruz]

Post by Jon Cruz
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".)

[Krzysztof Kosiński]

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

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.

Guess what? This one actually cries out *explicitly* for proper linked media
"... 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.

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

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.

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.

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

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.

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

I don't recall this example being mentioned, please repeat it. I think
it's not possible unless you go into the XML editor, but using the XML
editor you can also break linked images, or any other element for that
matter.

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.

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?

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

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.

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.

Re-read this statement. It doesn't exclude solutions other than mine.
Other solutions that are compatible with it are saving to a ZIP
archive by default and embedding on save. It is a necessary
requirement, because if there is more than one file, someone will
inevitably not send one of them.

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

Regards, Krzysztof.

[Jon Cruz]

Post by Krzysztof Kosiński

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.

Post by Krzysztof Kosiński

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.

Post by Krzysztof Kosiński

Guess what? This one actually cries out *explicitly* for proper linked media
"... 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.

Post by Krzysztof Kosiński

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.

Post by Krzysztof Kosiński

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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński

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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński
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.

Post by Krzysztof Kosiński

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.

Post by Krzysztof Kosiński

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

[Krzysztof Kosiński]

Post by Jon Cruz
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.

Oops, sorry. I didn't read it to the end :/

Post by Jon Cruz
Solution: never link external media assets, only embed them. This results in
100% consistent behavior.

Now you are using a straw man, because that was not my solution. It
was: embed by default on paste and DnD and provide embed/link radio
button in the import dialog, which is initially set to embed. "By
default" means the behavior could be changed to always link on
paste/DnD, by going to the prefs dialog. Further improvements could
include making embed/extract actions better discoverable, and several
other improvements that you mentioned, but even this small change
could fix the missing data problem, which is the most severe. I stated
at least twice that I have completely no issue with comprehensive link
support, as long as it is kept out of sight of the clueless.

Embedding doesn't break anything for user B, only introduces a minor
inconvenience (he has to extract the images, turning them into links).
It doesn't preclude B from using links, or A learning about them some
time in the future, but it avoids the broken document that discourages
them to learn more about Inkscape.

Regards, Krzysztof

[Krzysztof Kosiński]

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.

[Jon Cruz]

Post by Krzysztof Kosiński
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.

I'm glad you're finally seeing that there are subtle nuances coming in here. That is the key.

Post by Krzysztof Kosiński
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).

Aha! I'm glad you managed to bump up against a couple of the trees there, but again you missed seeing the forest.

I'm well aware of the limitations of dialog boxes. However, you stumbled across the facts that:

1) the more likely a user is to be confused by embedding, the more likely he is to ignore dialogs.
2) when properly crafted, a dialog can 'force' a type of user to make the type of choice a designer wants.

Those can combine with many other subtle factors. One of the simplest combinations is to have a dialog and set the "Bloat all my documents" radio button as default. Anyone who reads "Bloat all my documents" will want to change that, but others (who ignore things) won't.

The actual way to implement things is not quite that simple, but it is a good illustration.

Post by Krzysztof Kosiński
What was the point of writing all the
stuff on the wiki if you just ignored it?

Again, this is a false argument.

The *point* of getting stuff in the wiki is so that it is recorded in an easy to access manner, and can be reviewed and edited by all.

Cyclical refinement is one main factor. And actually you were the one who are ignoring it. I just haven't had time to reconcile all the use cases you have, your personas and the other personas.

But... that is being worked on as we go.

And to answer your rhetorical question directly, the point is to get information onto the wiki and *then* reconcile it, simplify it, and see what patterns emerge.

[Jon Cruz]

Post by Krzysztof Kosiński
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?

[Jon Cruz]

Post by Krzysztof Kosiński
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.

And I'd say here that we have two issues, one good and one bad.

The analysis is good: "users unaware of linking are surprised by the behavior"

The solution is not so good: "Change default behavior to *not* link, plus add a notification only at creation time"


Instead I would say a better solution is: "Make the UI convey link vs. embedded constantly and consistently so the user is never surprised."

(Oh, one general non-Inkscape use case to check behavior is launch a web design program, copy some images from Finder/Explorer/Nautilus and then paste into the web program. Voila! links and not embeddings)

[Jon Cruz]

Post by Krzysztof Kosiński
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.

[Jon Cruz]

Post by Jon Cruz
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.

Oh, and I would take this opportunity to point out that one of these "contexts" I mentioned is our Jabber/IRC chat room.

You *really* should show up there more. First to be able to talk with other developers in more real time, and second to be able to keep in tune with common end user needs and diversity.

[Donna Benjamin]

Post by Jon Cruz

Post by Jon Cruz
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

[John Cliff]

Sent from my iPhone

Post by Donna Benjamin

Post by Jon Cruz

Post by Jon Cruz
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?

most insightful solution I've seen suggested yet.
This is primarily a user expectation problem, ie we're not doing what
a portion of our userbase is expecting, and we're not communicating
what is happening either. One screencast will probably do more to help
this issue than anything, as it will help inform the artistic, but not
necessarily web centric users without screwing up other peoples
workflows or expectations.

Post by Donna Benjamin
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

Also a pretty good idea if disableable

Post by Donna Benjamin
--
Donna Benjamin Libre Graphics Day miniconf LCA2010
Co-organiser Wellington Convention Centre, New Zealand
http://libregraphicsday.org Monday, 18th January 2010
---
---
---
---------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast
and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Inkscape-devel mailing list
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

[Alexandre Prokoudine]

Post by Krzysztof Kosiński
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

[Jon Cruz]

Post by Krzysztof Kosiński
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.

Please, please, *PLEASE* read the information that was linked to! Yes, all that is not only relevant but highly critical and all carefully explained there.

Here, let me explicitly point out the link to you

http://en.wikipedia.org/wiki/Persona_%28marketing%29

(and, no, we are not nearly done so we can't address the conclusion yet)

[Krzysztof Kosiński]

Post by Jon Cruz
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

[Jon Cruz]

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

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.

Post by Krzysztof Kosiński
http://www.inkscapeforum.com/
and create personas that correspond to the answers.

That won't work. There you have a very specialized subset of potential users. You might be able to get one or maybe two personas from that pool, but nothing near what one would get from querying people at SVG Open or such.

[Joshua A. Andler]

Post by Krzysztof Kosiński

Post by Jon Cruz
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.

Post by Krzysztof Kosiński
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

[Jon Cruz]

Post by Joshua A. Andler
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.

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.

As Mark Shuttleworth recently pointed out, you need to have users sit down, then STFU
http://humanfactorsblog.org/2009/09/25/stfu-usability-protocol/


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)

[Joshua A. Andler]

Post by Jon Cruz

Post by Joshua A. Andler
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?

Post by Jon Cruz
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.

Post by Jon Cruz
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

[Alexandre Prokoudine]

Post by Krzysztof Kosiński
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.

Alexandre

[Krzysztof Kosiński]

Post by Alexandre Prokoudine
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

[Jon A. Cruz]

Post by Krzysztof Kosiński
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.

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.

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

There are many many expectations. And the implementations to serve a
lot of them are actually conflicting.

[Krzysztof Kosiński]

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

Post by Jon A. Cruz
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).

Post by Jon A. Cruz
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

Post by Jon A. Cruz
- For import : Put a drop-down menu in the import dialog, on "Embed" by
default.

+1

Post by Jon A. Cruz
- For copy/paste : embed, the user will the use the "Image properties" if he
wants to create a Link

+1

Post by Jon A. Cruz
- 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).

Post by Jon A. Cruz
Proposed solution B: Change the UI to clearly show the difference between
linked and embedded images.

+1

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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.

Post by Jon A. Cruz
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

[Steren]

Post by Krzysztof Kosiński
a new user expects the document to be self-contained.

This is too vague to be valid. For example, when I started Inkscape (as a
new "Inkscape user"), I was glad to see that it was links. This was because
of my previous experiences.
As Jon said earlier, there is no solution that fits everyone. We just have
to make it clear for everyone when it's Link and when it's embedded.


Here is what I propose :

- For import : Put a drop-down menu in the import dialog, on "Embed" by
default.
- For copy/paste : embed, the user will the use the "Image properties" if he
wants to create a Link
- 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)

[Jon A. Cruz]

Post by Steren
- 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.

[Jon A. Cruz]

Post by Krzysztof Kosiński
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.

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.

So we do need to remember to target people trying to "create SVG
files" or "create SVG artwork" a little more when it come in conflict
with "create general vector graphics".

[J***@ewi.utwente.nl]

-----Original Message-----
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

[Diederik van Lierop]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 10/23/2009 09:52 PM, Alexandre Prokoudine wrote:
<blockquote
cite="mid:***@mail.gmail.com"
type="cite">
<pre wrap="">On 10/23/09, Krzysztof Kosiński wrote:

</pre>
<blockquote type="cite">
<pre wrap="">You say that 50% of people prefer linking and 50% prefer embedding. I
am certain this is not true.
</pre>
</blockquote>
<pre wrap=""><!---->
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.

Alexandre</pre>
</blockquote>
<br>
Of course it all depends on your audience. Linking might be common
practice in desktop publishing, but it don't think the average office
worker is used to that concept. IMHO embedding should be the default,
such that our office worker can easily email his document to a
co-worker without bothering about links, whereas our skilled graphical
designers can decide to link their high resolutions bitmaps into the
SVG for maximum flexibility if they need or want to. They will find
their way with Inkscape anyway.<br>
<br>
Just my €0.02<br>
<br>
Diederik<br>
</body>
</html>

[Steven M. Ottens]

Post by Alexandre Prokoudine

Post by Krzysztof Kosiński
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

[Jon A. Cruz]

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

Bingo!!!

I think you hit the nail on the head right there.

Thanks for your input.

[Valerie]

Just a small note on user cases:

The lowest common denominator of Joe Schmoe out there (that can
be expected to use Inkscape) is probably the Windows user who's
only familiar with 2 programs: an internet browser and Microsoft
Word. That's it.

He's neither a webpage designer nor a raster graphics master.
He's the type who (very regretfully) takes 2 MB photos,
sends them as is to you by email, and doesn't even know (nor care)
that he's doing it wrong (unfortunately, this is also about 90%
of the people I've worked with...).

Such a person's notion of copy/paste is:
- Copy text. Paste in Word file.
- Copy image. Paste in Word file.
- If the image is modified, delete the original image and paste
the new one in.
- They don't expect anything they've pasted in to disappear when
they move the file around or send it to their family/friends/boss.

(and yes, that level of user may come to use Inkscape. I often
use Inkscape to do charts for work, it's handy)