Re: [Inkscape-devel] Specification: Improved image properties dialog (0.48)
W dniu 23 października 2009 17:18 użytkownik Jon A. Cruz <jon@...18...> napisał:
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.
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.
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.
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.
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
2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>
When you paste an image into a Word / ODT file, it is not a link to that file on your hard disk.
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 - Insert > Picture > From File - in the dialog, select an image and tick "Link", then Open A dialogpops-up asking you If you are sure you want to link it. See capture attached to this email. You can choose to ask again when you will be linking your next image or you can say "I know what I am doing" by ticking something. Then you can edit these Links with Edit > Links. This opens a window that inspired me for the "Image Links Manager" proposal.
So this leads us to say that we are not the only one having issues for an understandable-by-everyone linking strategy.
On 10/23/09, Krzysztof Kosiński wrote:
You say that 50% of people prefer linking and 50% prefer embedding. I am certain this is not true.
And I am certain that you never run a survey on that :) As a matter of fact both embedding and linking are equally valid in desktop publishing world.
Alexandre
Alexandre Prokoudine wrote:
On 10/23/09, Krzysztof Kosiński wrote
You say that 50% of people prefer linking and 50% prefer embedding. I am certain this is not true.
And I am certain that you never run a survey on that :) As a matter of fact both embedding and linking are equally valid in desktop publishing world.
As a user I do have use-cases for both linking and embedding. But it would be nice if it would be clear to me if the image is linked or embedded and when it's linked, how it's linked. I use dropbox a lot to work between different computers and somehow when I move from windows to OS X or linux the link is gone, whilst the linked image is sitting right next to the SVG file.
So for me it doesn't really matter what's the default approach as long as it is clear what is happening.
On a side note, Krzysztof does have a point that many users who are not used to the DTP world are most likely baffled by the linking principle. So a little help there is not a bad idea.
regards, Steven
2009/10/23 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
And I am certain that you never run a survey on that :) As a matter of fact both embedding and linking are equally valid in desktop publishing world.
Again: I do not claim that links are useless, or that less than 50% of people ever use links. We can play with words but the fact remains that a new user expects the document to be self-contained. In other words, if you don't know what you want, you most certainly don't want a link, because your document will break as soon as you move files around or send it to someone else. If you want a link, you should say that you want a link.
Regards, Krzysztof
2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>
When you paste an image into a Word / ODT file, it is not a link to that file on your hard disk. The use of links is also quite common in large Microsoft Word documents and has been for years. I am finishing a 160 page book with about 80 linked photographs and maps using Word 2003. Linked photos are essential in this case as the file size would otherwise be unworkable. You can insert, link or insert and link the objects and then at a later stage swap etc or otherwise edit their designations. There are numerous advantages to linking and there are few hassles. One interesting one is when you have all your images on a separate drive and forget to turn that on when you edit your main article. Heart attack material for a few seconds when you think you have lost all your photos.
I am familiar with the OpenOffice use of links and it is clearly modelled on that of Word.
Erik Halbert kaver@...1960...
On Oct 23, 2009, at 1:03 PM, Krzysztof Kosiński wrote:
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.
W dniu 23 października 2009 22:08 użytkownik kaver <kaver@...1960...> napisał:
2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>
When you paste an image into a Word / ODT file, it is not a link to that file on your hard disk.
The use of links is also quite common in large Microsoft Word documents and has been for years.
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
On Oct 23, 2009, at 1:16 PM, Krzysztof Kosiński wrote:
That is the gist of what I'm saying. I don't want to remove link support, or make it harder to use. I want inexperienced users to stop breaking their documents.
Ah, Good!!!
We finally have a clear software requirement.
Problem: Inexperienced users are breaking their documents.
Proposed solution A: Change the "Import" command for all so that it embeds instead of links.
2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>
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)
On Oct 23, 2009, at 1:03 PM, Krzysztof Kosiński wrote:
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".
On Oct 23, 2009, at 1:01 PM, Steven M. Ottens wrote:
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.
On Oct 23, 2009, at 1:23 PM, Steven M. Ottens wrote:
Jon A. Cruz wrote:
Problem: Inexperienced users are breaking their documents.
Proposed solution A: Change the "Import" command for all so that it embeds instead of links.
+1
Proposed solution B: Change the UI to clearly show the difference between linked and embedded images.
Proposed solution C: Add a popup that explains to a new user what linking vs. embedding is.
Proposed solution D: Allow a preference to "always embed"
Proposed solution E: all of B, C, and D
On Oct 23, 2009, at 1:23 PM, Steren wrote:
- For Drag and drop : Ask every time the user if he wants to create
a Link or to embed. Allow hom to tick a box that says "always use this choice" (this property can also be reach in the userpreferences)
FYI, there are UI and Free Desktop conventions to allow a user to have a "choose" action on drop.
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*
Good. I see we're arriving at a consensus :)
2009/10/23 Jon A. Cruz <jon@...18...>:
Well... yes....
But a new user also expects his files to not increase in size by 33%. A new user also expects SVG to be small.
Possible solution: prompt about saving in SVGZ when there are many images (for example, over 500kb of image data).
A new user also expects that when he edits an image in his "document" that the changes will show up.
If you mean allowing to edit an embedded image in an external program, I admit that it will be challenging. Here are possible solution: 1. Create a temporary file and wait until the program closes. Might not be doable cross-platform. 2. Display a modal dialog that says "click OK when you're done editing". Ugly. 3. Hybrid link: embed an image but watch an external file for changes. When the linked image changes, update the embedded copy. When the linked image disappears, drop the link and only keep the embedded portion.
W dniu 23 października 2009 22:23 użytkownik Steren <steren.giannini@...400...> napisał:
2009/10/23 Krzysztof Kosiński <tweenk.pl@...400...>
- For import : Put a drop-down menu in the import dialog, on "Embed" by
default.
+1
- For copy/paste : embed, the user will the use the "Image properties" if he
wants to create a Link
+1
- For Drag and drop : Ask every time the user if he wants to create a Link
or to embed. Allow hom to tick a box that says "always use this choice" (this property can also be reach in the userpreferences)
+1 - if it's for files dragged from Explorer/Nautilus. DnDing something that is not a file on the hard disk should always embed (it doesn't make much sense to do otherwise).
Proposed solution B: Change the UI to clearly show the difference between linked and embedded images.
+1
Proposed solution C: Add a popup that explains to a new user what linking vs. embedding is.
Taking into account the Windows conditioning to click "OK" on everything without reading it, especially if "OK" is the only choice, the popup is likely to be dismissed without looking at it.
FYI, there are UI and Free Desktop conventions to allow a user to have a "choose" action on drop.
AFAIK the convention in X/Gnome/KDE is middle button drag which is HARD to do on some wheel mice, so I think we shouldn't rely on it too much. The Windows convention of right button drag is better in this respect.
2009/10/23 Jon A. Cruz <jon@...18...>:
Inkscape is targeting being the "best SVG editor" out there. Note that it is not the "best vector editor". This is a subtle yet important point that was actually involved in the project's formation.
Embedding images in data: URLs is a valid SVG feature. I think there is no conflict between those goals in this particular case.
2009/10/23 Steren <steren.giannini@...400...>:
Concerning Solution B: Notice that the current UI show a difference : in the status bar, "Embedded" or the path of the image are written. But I'm ok to say that it's not clear enough. In this status bar, I would propose to not talk about *Image* but to always talk about *Embedded Image* or *External Image*
What about Image and Link to Image? Just like 'Clone of' right now. We might have different kinds of links in the future.
Regards, Krzysztof
Steren wrote:
Problem: Inexperienced users are breaking their documents. Proposed solution A: Change the "Import" command for all so that it embeds instead of links.
I did say +1 and I do believe that's the correct thing for casual users. Although I do agree that for a lot of users it makes sense to default this to 'link'. So make it fairly easy in the settings to change this behavior.
Proposed solution B: Change the UI to clearly show the difference between linked and embedded images.
This is very tricky. As an interaction designer I know that there's no such thing as 'showing clearly'; the so called intuitive solution often is the commonly used one. Since there's not a clear common solution in this case (nor is it a common problem) it is difficult (but not impossible) to come up with a obvious metaphor.
Proposed solution C: Add a popup that explains to a new user what linking vs. embedding is.
Personally I hate popups; they interfere with the workflow. Greater minds than me have written beautiful, but wishful, obituaries for the popup and I just want to adhere.
Proposed solution D: Allow a preference to "always embed"
I'd say a preference: 'always embed, always link, ask' or maybe even have preferences for copy-paste, import and drag 'n drop.
Proposed solution E: all of B, C, and D
Generally it is a bad idea to clutter your interface with several options to do the same thing.
Regards, Steven
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?
-----Original Message----- From: Jon A. Cruz [mailto:jon@...18...] Sent: vrijdag 23 oktober 2009 22:24
Oh, and please keep one point in mind.
Inkscape is targeting being the "best SVG editor" out there. Note that it is not the "best vector editor". This is a subtle yet important point that was actually involved in the project's formation.
Is this true? It makes me sad reading it. :-/
-Johan
Quoting "Steven M. Ottens" <steven@...2202...>:
This is very tricky. As an interaction designer I know that there's no such thing as 'showing clearly'; the so called intuitive solution often is the commonly used one. Since there's not a clear common solution in this case (nor is it a common problem) it is difficult (but not impossible) to come up with a obvious metaphor.
Thanks, this is exactly the type of participation I was hoping we'd get. Do you think you could help us get details and discussion going on the wiki?
http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management
2009/10/24 <Jon@...18...>:
Thanks, this is exactly the type of participation I was hoping we'd get. Do you think you could help us get details and discussion going on the wiki?
http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management
I added some of the ideas from this discussion to that page. Regards, Krzysztof
I was wondering if Glib has a cross-platform inotify equivalent, and it does. This is what we need to implement external editing of embedded files. Just watch for file change events and update the embedded data whenever that happens. However, we need to at least partially move to GIO to make any use of this.
http://library.gnome.org/devel/gio/unstable/GFileMonitor.html
Regards, Krzysztof
On Oct 29, 2009, at 7:42 AM, Krzysztof Kosiński wrote:
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.
On Oct 24, 2009, at 6:36 PM, Krzysztof Kosiński wrote:
2009/10/24 <Jon@...18...>:
Thanks, this is exactly the type of participation I was hoping we'd get. Do you think you could help us get details and discussion going on the wiki?
http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management
I added some of the ideas from this discussion to that page.
Thanks. The use cases there are a good start, but they are missing some critical information. You referenced several 'personas' in context, but did not spell out who these different users actually are. One of the key things is to have a complete, specific idea of named fictitious people referenced use cases (otherwise one could just say "a graphic designer" or "a software architect").
I've stubbed out some placeholders for the users that you can fill out with details. To get some idea of how to write a persona check the Marketing Scratchpad page on our wiki and its link to Wikipedia.
Thanks.
On Oct 29, 2009, at 9:33 AM, Jon Cruz wrote:
On Oct 24, 2009, at 6:36 PM, Krzysztof Kosiński wrote:
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, 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
On Dec 23, 2009, at 11:01 AM, Krzysztof Kosiński wrote:
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)
On Wed, 2009-12-23 at 20:01 +0100, Krzysztof Kosiński wrote:
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
I can see how those details are important when considering a big change in the behavior of the application. However, the main point of this specification is to fix a bug (images disappear when sending the SVG to somebody else). The gist of the solution is to embed on pasting by default, and the only remaining discussion is how to expose the link functionality. Am I right?
Regards, Krzysztof
On Wed, 2009-12-23 at 20:30 +0100, Krzysztof Kosiński wrote:
I can see how those details are important when considering a big change in the behavior of the application. However, the main point of this specification is to fix a bug (images disappear when sending the SVG to somebody else). The gist of the solution is to embed on pasting by default, and the only remaining discussion is how to expose the link functionality. Am I right?
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
W dniu 23 grudnia 2009 20:15 użytkownik Jon Cruz <jon@...18...> napisał:
Here, let me explicitly point out the link to you http://en.wikipedia.org/wiki/Persona_%28marketing%29
It says that user personas are created based on actual survey or interview data. Isn't me or you inventing them "cargo cult marketing"?
To do this correctly, we should ask people from here: http://www.inkscapeforum.com/ and create personas that correspond to the answers.
Regards, Krzysztof
On Dec 23, 2009, at 11:30 AM, Krzysztof Kosiński wrote:
I can see how those details are important when considering a big change in the behavior of the application. However, the main point of this specification is to fix a bug (images disappear when sending the SVG to somebody else). The gist of the solution is to embed on pasting by default, and the only remaining discussion is how to expose the link functionality. Am I right?
No.
You're seeing the trees but not the whole forest.
To restate, you're seeing a single concrete manifestation of a problem and crafting a solution that solves only that specific manifestation, but both leaves other manifestations in place *and* creates new manifestations.
Instead of a one-off small localized "band-aid" patch at one point, let's solve the whole problem in one simple pass. Or one might illustrate it with the comparison of you grabbing onto the tail of an elephant and saying "a snake! let's grab a snare pole and get rid of it" while I'm saying "No, it's an elephant; just ask his mahout to have him step away"
On Dec 23, 2009, at 12:10 PM, Krzysztof Kosiński wrote:
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.
To do this correctly, we should ask people from here: 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.
On Wed, 2009-12-23 at 21:10 +0100, Krzysztof Kosiński wrote:
W dniu 23 grudnia 2009 20:15 użytkownik Jon Cruz <jon@...18...> napisał:
Here, let me explicitly point out the link to you http://en.wikipedia.org/wiki/Persona_%28marketing%29
It says that user personas are created based on actual survey or interview data. Isn't me or you inventing them "cargo cult marketing"?
It says in most cases, not all.
To do this correctly, we should ask people from here: http://www.inkscapeforum.com/ and create personas that correspond to the answers.
Not a bad idea in general, however we would need to create a survey to achieve this. I don't think users of inkscapeforum alone will represent a wide enough group of different types of users. So, perhaps we create an online survey and announce on the forums, the user-list, deviantart, twitter, and our website.
The question then becomes, what if people overwhelmingly respond?
Cheers, Josh
On Dec 23, 2009, at 12:22 PM, Joshua A. Andler wrote:
Not a bad idea in general, however we would need to create a survey to achieve this. I don't think users of inkscapeforum alone will represent a wide enough group of different types of users. So, perhaps we create an online survey and announce on the forums, the user-list, deviantart, twitter, and our website.
The question then becomes, what if people overwhelmingly respond?
What generally happens in these cases is that you don't get much useful information. That is, the online poll tends to get misinformation and more of what people think the poller wants to hear.
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)
W dniu 23 grudnia 2009 21:15 użytkownik Jon Cruz <jon@...18...> napisał:
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.
W dniu 23 grudnia 2009 21:17 użytkownik Jon Cruz <jon@...18...> napisał:
No. I've been conducting surveys for years now, and from many different groups. These include complete computer novices, some who have been graphic designers, some who have not.
In that case, what is the point of me making up the personas when you have real-world data? You should write them, and based on that I can then adjust the use cases.
Regards, Krzysztof
On Wed, 2009-12-23 at 12:35 -0800, Jon Cruz wrote:
On Dec 23, 2009, at 12:22 PM, Joshua A. Andler wrote:
Not a bad idea in general, however we would need to create a survey to achieve this. I don't think users of inkscapeforum alone will represent a wide enough group of different types of users. So, perhaps we create an online survey and announce on the forums, the user-list, deviantart, twitter, and our website.
The question then becomes, what if people overwhelmingly respond?
What generally happens in these cases is that you don't get much useful information. That is, the online poll tends to get misinformation and more of what people think the poller wants to hear.
So if you ask Age, Occupation, Hobbies/Interests, Is your use of inkscape related to occupation, hobbies/interests, both, or neither? What have you used Inkscape for?, How long have you been using it for? Have you used other vector graphics software?, If so, sow long have you used vector graphics software for?, etc... that people are going to intentionally give us bad info? What do they think we want to hear by those types of questions? That everyone is a 35yr old graphic designer who has 17 years of experience with vector software and 3yrs w/ inkscape?
Remember, users will lie. Well, rather they will say what they think is *how* to get what they want, not the *why* of what they're actually trying to get.
We're not asking them what they want. So they have no reason to lie. We state the purpose of the survey... we need to know more about our userbase and what uses people are finding for inkscape.
On the other hand, observing users "in the wild" at trade shows or conventions is a good opportunity to conduct such surveying (and, yes, I've confirmed this with many usability professionals)
I agree on the observing users piece. However, it is again limiting w/ *where* you recommend surveying because most people I know have never attended a trade show or convention. Better yet, I personally know a small and diverse group of Inkscape users, none have ever been to a trade show or convention. They're now left out.
Cheers, Josh
On Dec 23, 2009, at 12:52 PM, Krzysztof Kosiński wrote:
W dniu 23 grudnia 2009 21:17 użytkownik Jon Cruz <jon@...18...> napisał:
No. I've been conducting surveys for years now, and from many different groups. These include complete computer novices, some who have been graphic designers, some who have not.
In that case, what is the point of me making up the personas when you have real-world data? You should write them, and based on that I can then adjust the use cases.
The point was that you said you had use cases and invented those personas. I can't determine where those fit with our overall ones unless you spell out what you were thinking for each of those. Remember, we can't read your mind.
On Dec 23, 2009, at 12:52 PM, Krzysztof Kosiński wrote:
W dniu 23 grudnia 2009 21:15 użytkownik Jon Cruz <jon@...18...> napisał:
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.
W dniu 23 grudnia 2009 22:14 użytkownik Jon Cruz <jon@...18...> napisał:
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.
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.
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.
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
On Dec 23, 2009, at 1:47 PM, Krzysztof Kosiński wrote:
Another one is "I have a common image placed for background, and now my directory jumped from 100MB to 20GB and can't fit on my thumb drive any more".
20GB uncompressed SVG file would have to contain 5GB of images.
Ah, but you missed what I said.
A "common image placed for background". Think a few dozen SVG files with a single large PNG placed in each. (Yes, a real-world scenario I've seen)
On Dec 23, 2009, at 1:47 PM, Krzysztof Kosiński wrote:
W dniu 23 grudnia 2009 22:14 użytkownik Jon Cruz <jon@...18...> napisał:
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.
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.
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.
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.
W dniu 23 grudnia 2009 23:11 użytkownik Jon Cruz <jon@...18...> napisał:
Now here is the elephant you are not seeing. This is *all* link management. For example you say the links that are pasted don't work:
Solution A: Since pasted links are broken, don't link images. Solution B: Since pasted links are broken, fix the pasting of links.
(which solution sounds like proper software engineering?)
The question is moot because the second solution is unimplementable. We cannot "fix the pasting of links" because when we paste pixel data, for example copied from GIMP, there is no file we can link to.
The "common background" thing is a legitimate use of links, but pasting is not an obvious way to do this. When you're pasting something, you do not create links to the original, you make copies of the thing you're pasting. Why you want links, contrary to how every other application works, is completely beyond my comprehension.
And I personally never see an image in the documents folder linked.
???
So, as we refine this and get more of the details on the problems you personally are seeing, it sound more and more like you are being adversely affected by misbehaving pasting/linking. If we fix that, then most of those use cases will be solved... with no need to resort to embedding.
The problem will not be solved by proper linking, it will be made worse (not to mention that it cannot be consistent with the behavior for pixel data as outlined above). Let's go back to the e-mail case. Let's say I paste 3 images from 3 different folders into my document. Now I want to send this to another person. Instead of having all the images in the document's directory, I now need to look for those files around the filesystem, and moreover the links will be broken on the other person's system, because they likely point to different directories.
You can propose some magic code to fix those links but what if the person I'm sending to doesn't have Inkscape and won't be able to run this link-fixing code?
What exactly is wrong with embedding that makes you refer to it as some kind of last resort measure?
Regards, Krzysztof
On Dec 23, 2009, at 5:57 PM, Krzysztof Kosiński wrote:
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)
The "common background" thing is a legitimate use of links, but pasting is not an obvious way to do this. When you're pasting something, you do not create links to the original, you make copies of the thing you're pasting. Why you want links, contrary to how every other application works, is completely beyond my comprehension.
And I personally never see an image in the documents folder linked.
???
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.
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.
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".
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)
2009/12/24 Krzysztof Kosiński wrote:
for pixel data as outlined above). Let's go back to the e-mail case. Let's say I paste 3 images from 3 different folders into my document. Now I want to send this to another person. Instead of having all the images in the document's directory, I now need to look for those files around the filesystem, and moreover the links will be broken on the other person's system, because they likely point to different directories.
File - Collect for output.
This is how this has been solved for years :) Even in Scribus.
Alexandre
W dniu 24 grudnia 2009 18:49 użytkownik Jon Cruz <jon@...18...> napisał:
Therefore a simple solution would include just placing a file "PastedImage001.png" in current SVG document's image location.
This is what happens now (only the name is different), and it is what causes broken documents when sending over email. I have received a document broken because of missing pasted images at least once. So it's not a solution, it is the problem. Users will still only send the SVG, and be surprised by broken images, because they didn't remember creating any links.
OK. What I'm trying to point out here is that I don't see the program behavior you do.
You did not answer the critical part of the question, which is "Why you want links, contrary to how every other application works". I remember an earlier response along the lines of "it's more SVG", which I find irrelevant to the non-expert user. The expert user which values "SVG purity" will be more than capable of finding the appropriate options for linking.
To reiterate, I do not want to remove link support. I only want the user to be aware of the fact that he is creating a link, with the action being described as "Create Link" not "Paste". Otherwise he will end up with broken documents.
You can propose some magic code to fix those links but what if the person I'm sending to doesn't have Inkscape and won't be able to run this link-fixing code?
This is more of a non-issue. Once we have the use cases page filled out it should become clear. In the meantime hints are "web archive" and "Web page, complete".
Providing a different save mode that includes all linked documents in an archive is interesting, and an useful feature in its own right, but I think it does not address the e-mail case: the user doesn't know he created a link, so it will not occur to him to use the provided save mode. He will just send the bare SVG, like he does with OO.o documents. Finally I don't think many non-expert users think of an Inkscape image as a web page.
I keep stating many reasons, but you continue to ignore them.
If I remember correctly, the arguments against embedding on paste were: 1. SVG gets large, 2. editing the original image externally does not change the display. In my opinion neither is as severe as unexpectedly broken documents. Furthermore, both are fixable.
1 is a minor problem that can be solved by suggesting the user to save in SVGZ if the file is larger than X MB. We should address the problem of large SVGs even when we decide against embedding.
2 is IMO solved appropriately for now: the "edit externally" link is grayed out for embedded images. Editing an embedded image is not trivial, but it can be done using temporary files. I highly doubt your earlier statement that users expect to see the changes in Inkscape after editing the original images, because no other application they can paste images into creates links on pasting.
Regards, Krzysztof
On Dec 26, 2009, at 6:13 PM, Krzysztof Kosiński wrote:
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.
On Dec 26, 2009, at 6:13 PM, Krzysztof Kosiński wrote:
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)
On Dec 26, 2009, at 6:13 PM, Krzysztof Kosiński wrote:
2 is IMO solved appropriately for now: the "edit externally" link is grayed out for embedded images. Editing an embedded image is not trivial, but it can be done using temporary files. I highly doubt your earlier statement that users expect to see the changes in Inkscape after editing the original images, because no other application they can paste images into creates links on pasting.
And now this is a point where you really go off from the real world.
1) you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
2) Many many many programs out there *do* paste links. They might be more common with workflows different than the workflows you personally use... but that does not mean they do not exist.
On Dec 26, 2009, at 6:54 PM, Jon Cruz wrote:
And now this is a point where you really go off from the real world.
- 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.
On Sat, 2009-12-26 at 18:59 -0800, Jon Cruz wrote:
- 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
Sent from my iPhone
On 27 Dec 2009, at 03:41, Donna Benjamin <donna@...2182...> wrote:
On Sat, 2009-12-26 at 18:59 -0800, Jon Cruz wrote:
- 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.
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
-- 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
W dniu 27 grudnia 2009 03:46 użytkownik Jon Cruz <jon@...18...> napisał:
What you pointed out was a specific program of a very specific type (MS Word) and a clone of that same program. Thus those really don't even count as two as far as behavior goes.
Other programs include GIMP and other raster editors - maybe this example is more convincing, because
Now... one has to remember that this is initially a *web* graphic format. So we really should compare to *web* document programs.
I think this is in fact our main point of contention. You think of Inkscape as web graphics editor, while I think of it mainly as a general-purpose vector graphics program that uses SVG. For you using SVG as the output format is the goal, for me it's merely an advantage. The correct default depends on how we answer this question. This is where your survey data could help. How many users use Inkscape as a general purpose vector editor, compared to the number of people who use it as a web editor?
Here are some points to consider. 1. Wikipedia doesn't count as "SVG for the Web", because it doesn't use any Web-related features of SVG. Submitting an image with links to external media to Wikipedia would result at best with a misrendering and at worst the image would be rejected for security reasons (I didn't test it). 2. SVG has Web-related features, but it is a general purpose format that is often used outside of the Web context, for example for GIS data, in mobile applications, and on the Linux desktop (icons). 3. "Inkscape is a general purpose vector editor" doesn't equal "Inkscape should not have Web-oriented features". It only means that the Web-oriented features should be available for users that explicitly want them.
- you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
- Many many many programs out there *do* paste links. They might be more common with workflows different than the workflows you personally use... but that does not mean they do not exist.
Please mention examples! There are indeed several programs that do paste or import links, but we must also consider how they relate to Inkscape. Video editing programs almost always use links, but I don't think this is relevant for a vector editor. The other example you mentioned is web design tools, see above.
Instead I would say a better solution is: "Make the UI convey link vs. embedded constantly and consistently so the user is never surprised."
This would require everyone to understand the difference between a link and an embedded image, and the concept of a link between two files. There might be lots of potential Inkscape users that don't understand the link concept (not to say that they wouldn't understand it if explained, just that they never used it). In this respect, embedding is bulletproof and idiot-proof.
2009/12/27 Donna Benjamin <donna@...2182...>:
Bundling the file together with the linked images the way ODF does makes some sense for file storage and transportability - but embedding the file, by UUencoding or Base64 or something doesn't make sense to me, because it can't be edited with a text-editor
SVG with embedded images can be edited in a text editor. The image element will have a very long URI, but it should not be a problem for a decent editor.
What does the SVG standard suggest? What's wrong with the current 'save as' compressed svg with media (*.zip) option... perhaps some documentation or asking heathenx to do a screencast on this topic would help those users who are unfamiliar with this standard practice?
SVG doesn't define any compression methods or container formats, but the de facto standard is SVGZ (a single SVG file compressed with gzip). SVGZ is opened directly by many vector applications. The ZIP archive requires decompression, and as said before the user is not aware that he should choose this option before sending the file to a friend.
More screencasts and more documentation can't hurt, but it's better if basic features of a program do not require explanations - this is called usability :) So we have a dilemma: we either adapt pasting so that average Joe, who doesn't bother watching screencasts or reading docs, doesn't break his documents, or try to teach him that SVG images are more like web pages, and the images should be external. The former has a better chance of success.
Regards, Krzysztof
On 12/28/09, Krzysztof Kosiński wrote:
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. From what I remember, it was decided to get back to that after moving to GEGL and new file format.
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?
Then you really have to phrase the question correctly, because as already observed earlier, not for everyone who uses Inkscape as a vector editor embedding is an expected default option.
- 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
For example, SVG in GIS is rather in Web context :)
Actually, I quite like the suggestion to show a simple dialog to ask whether an image about to be imported should be embedded or linked to. We use a similar dialog in Luminance HDR (ex-Qtpfsgui) for drag'n'dropped images to ask if user wants to create a new HDR file from them or whether a user wants to open them as existing HDR files (makes sense or RAW photos).
Then, again, changing embedded/linked IMO should be done from Object Properties dialog.
Alexandre
On Dec 27, 2009, at 1:55 PM, Krzysztof Kosiński wrote:
W dniu 27 grudnia 2009 03:46 użytkownik Jon Cruz <jon@...18...> napisał:
What you pointed out was a specific program of a very specific type (MS Word) and a clone of that same program. Thus those really don't even count as two as far as behavior goes.
Other programs include GIMP and other raster editors - maybe this example is more convincing, because
Aha. So here we have another specific use case, and a more general rule that might be derived from it:
"Users who only know bitmap editors might get confused"
Now... one has to remember that this is initially a *web* graphic format. So we really should compare to *web* document programs.
I think this is in fact our main point of contention. You think of Inkscape as web graphics editor, while I think of it mainly as a general-purpose vector graphics program that uses SVG.
Not quite. I don't call it a "web" program per se.
However... one *KEY* point on Inkscape is that it *IS* supposed to be first and foremost an SVG editor, not a general purpose vector graphics program. That was some of the main reason to fork Inkscape in the first place, and has been explicitly stated.
*HOWEVER* this is not the problem disconnect. I'm looking at this from the view of general graphics use. I've used many myself, have worked with professional artists, new artists, casual users, businessmen trying to through things together, etc.
For you using SVG as the output format is the goal, for me it's merely an advantage. The correct default depends on how we answer this question. This is where your survey data could help. How many users use Inkscape as a general purpose vector editor, compared to the number of people who use it as a web editor?
Not really. You've got a bit of a straw-man argument set up there, and phrasing a question in that manner won't really gain us useful information.
- you might highly doubt users behave that way... but I have *observed* users behave that way again and again and in many different contexts.
- Many many many programs out there *do* paste links. They might be more common with workflows different than the workflows you personally use... but that does not mean they do not exist.
Please mention examples! There are indeed several programs that do paste or import links, but we must also consider how they relate to Inkscape. Video editing programs almost always use links, but I don't think this is relevant for a vector editor. The other example you mentioned is web design tools, see above.
Publishing tools also do this. There are a whole slew of those.
*HOWEVER* instead of taking wild guesses and disputing that end users actually behave this way, you really should heed reality.
Here's a bug an actual end-user reported just the other day https://bugs.launchpad.net/inkscape/+bug/499252
It has a very good use case described, and also shows that the user is *expecting* image linking.
(Oh, and another somewhat recent one where the user not only expects the linking, but dislikes the details of where linked things are https://bugs.launchpad.net/inkscape/+bug/441179 )
Instead I would say a better solution is: "Make the UI convey link vs. embedded constantly and consistently so the user is never surprised."
This would require everyone to understand the difference between a link and an embedded image, and the concept of a link between two files. There might be lots of potential Inkscape users that don't understand the link concept (not to say that they wouldn't understand it if explained, just that they never used it). In this respect, embedding is bulletproof and idiot-proof.
No, it is neither bulletproof nor idiot-proof.
And the latter will get us into big trouble. Any seasoned software engineer can tell you... once you invent an idiot-proof program, the world invents a better idiot.
A better approach is to clearly pin down actual users that you are afraid of. Define who they are and how they see things and then it will be easy to craft a solution to support them.
2009/12/27 Donna Benjamin <donna@...2182...>:
Bundling the file together with the linked images the way ODF does makes some sense for file storage and transportability - but embedding the file, by UUencoding or Base64 or something doesn't make sense to me, because it can't be edited with a text-editor
SVG with embedded images can be edited in a text editor. The image element will have a very long URI, but it should not be a problem for a decent editor.
Have you tried?
Aside from all the other issues, with some of the larger images one will often find things very painful to try to edit a large file.
And when we're talking about a 33% increase on top of an already multi-megabyte asset, things get slow very quickly.
What does the SVG standard suggest? What's wrong with the current 'save as' compressed svg with media (*.zip) option... perhaps some documentation or asking heathenx to do a screencast on this topic would help those users who are unfamiliar with this standard practice?
SVG doesn't define any compression methods or container formats, but the de facto standard is SVGZ (a single SVG file compressed with gzip). SVGZ is opened directly by many vector applications. The ZIP archive requires decompression, and as said before the user is not aware that he should choose this option before sending the file to a friend.
More screencasts and more documentation can't hurt, but it's better if basic features of a program do not require explanations - this is called usability :) So we have a dilemma: we either adapt pasting so that average Joe, who doesn't bother watching screencasts or reading docs, doesn't break his documents, or try to teach him that SVG images are more like web pages, and the images should be external. The former has a better chance of success.
Again, you are pushing a false dichotomy.
The third, and probably much better choice, is to just make Inkscape seamlessly support the common end user scenarios.
We just need to get the actual use cases out there defined. *Then* it becomes much easier to see good solutions. Guesses often don't help, and guess that have been seen to go counter to actual observed data are harmful.
2009/12/27 Alexandre Prokoudine <alexandre.prokoudine@...400...>:
FYI, linking was discussed in GIMP dev list and actually does make sense in many cases. From what I remember, it was decided to get back to that after moving to GEGL and new file format.
But was it discussed as a feature, or as the default for pasted and imported images? This is a critical piece of information, because this is a debate about defaults, not about features. As said before I don't want to remove the ability to link images, only label it more clearly and not use it by default when pasting, importing and DnDing.
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"
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.
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.
Those goals are not conflicting, if we recognize that people who want SVG-specific features are more likely to be power users and explore the software for options. If we wanted to be a 100% pure SVG editor, then the XML editor should always be displayed under the canvas (like the messages box in IDEs), and all features that use sodipodi: or inkscape: namespaces should be removed. Embedding images is actually more "pure" SVG than editable spirals and live path effects.
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.
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.
Here's a bug an actual end-user reported just the other day https://bugs.launchpad.net/inkscape/+bug/499252 It has a very good use case described, and also shows that the user is *expecting* image linking.
I cite from the reporter's description: "Make a copy of that bitmap as a bitmap (Alt+B) [I do this for editing images in order to keep the original image unchanged]". We can deduce two things from this report: 1. The default behavior is inconvenient in this case. The user wants to edit his local copy and leave the original unchanged. What he wants is actually an embedded image that can be edited externally through a tempfile. 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.
(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) 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) 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!)
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.
I acknowledge that bug reports only highlight problems with the existing implementation, and do not highlight problems with the proposed changes, so you are at a disadvantage.
No, it is neither bulletproof nor idiot-proof.
How? How in the world is it possible to break an embedded image? (Provide an example.)
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. 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.
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.
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.
Regards, Krzysztof
On Dec 27, 2009, at 4:10 PM, Krzysztof Kosiński wrote:
Yes. The group that only knows raster editors is not trivially small. Photoshop is general knowledge and gets quipped about in Hollywood movies (e.g. Casino Royale), and Windows includes a simple raster editor. Corel DRAW and Adobe Illustrator are not general knowledge, and the only system that I know that comes with a vector program preinstalled is Ubuntu Studio. I expect more of the new users of Inkscape to be familiar with raster graphics than with either vector graphics or SVG.
Yes... but you're missing a bit of the big picture here.
Most people don't "use Photoshop" nowadays. Instead they "use CS3" or "use CS4". Especially users who pirate software (the more common Windows-centric user base, etc.)
On Dec 27, 2009, at 4:10 PM, Krzysztof Kosiński wrote:
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.
On Dec 27, 2009, at 4:10 PM, Krzysztof Kosiński wrote:
Here's a bug an actual end-user reported just the other day https://bugs.launchpad.net/inkscape/+bug/499252 It has a very good use case described, and also shows that the user is *expecting* image linking.
I cite from the reporter's description: "Make a copy of that bitmap as a bitmap (Alt+B) [I do this for editing images in order to keep the original image unchanged]". We can deduce two things from this report:
- The default behavior is inconvenient in this case. The user wants
to edit his local copy and leave the original unchanged. What he wants is actually an embedded image that can be edited externally through a tempfile.
Exactly. You're again confirming what I've been saying.
- This expectation comes from knowing Inkscape behavior. Even if a
program does something completely unintuitive but predictable and documented, users will learn this over time. The fact that an established user can predict documented program behavior doesn't convey much useful information.
Actually from a usability standpoint it conveys quite a lot of useful information.
That is the crux of the matter. You're missing out on these "big picture" issues.
(Oh, and another somewhat recent one where the user not only expects the linking, but dislikes the details of where linked things are https://bugs.launchpad.net/inkscape/+bug/441179 )
This is about the initial path where the import dialog opens, not about linking vs embedding, see above as well. Sorry but not convinced in the slightest, try again.
Now my turn. These bugs are closely related to linking by default.
https://bugs.launchpad.net/inkscape/+bug/167026 (Images not transmitted over Inkboard, because they are links to files that don't exist on the other side; Inkboard doesn't work any more, but it's still related)
Nope. Not a blocker. In fact, that is easily addressed by correcting behavior and *keeping*linking. In fact, it will make things easier since you won't have as much bloat being sent over the wire at runtime.
Yes, this is a very good use case (did you make sure it's covered in the wiki). But no, it does not prove embedding is the only solution. This only proves that this use case needs to be explicitly addressed.
In fact, if you have some users with Inkboard and several common images, it creates a *far* more usable experience if Inkscape does not exchange any bytes for those shared images. As I look over this, it actually strengthens my opinion that we need to support "linking *plus* media management".
https://bugs.launchpad.net/inkscape/+bug/171085 (User moved files around, did not expect breaking his SVG documents) https://bugs.launchpad.net/inkscape/+bug/169108 (Bitmap copy in an image that wasn't saved yet tries to create a file in Inkscape's install dir, causing a permissions issue when the directory is not writable)
Guess what? This one actually cries out *explicitly* for proper linked media management. As the user requests in that report: "... simple right click on a "broken image" and then be able to update the path for all the images that are in selection?"
I believe that is exactly what I pointed out would solve use cases you added initially. This appears to be the "Sara" use case, and would be solved by the "Sara" solution.
https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG with image links to a website, surprised by broken images. Read the first comment, because the reporter misuses the word "embedded". Apparently linking by default is sometimes confusing even in the Web context!)
Nope. Not a blocker either.
*IF* you had done a scan of bugs with the "big picture" in mind, you would see that related issues come up with an *unsaved* document not having a fixed location. We need to address that issue overall and then guess what? This bug can get fixed by a different bug getting fixed. Kill two birds with one stone.
IMPORTANT: The third bug highlights why your proposed / existing solution to pasting pixel data by storing a pasted image in the document's folder is completely wrong. If the document wasn't saved yet, there is no such folder! We end up saving to some arbitrary location, which is completely unexpected.
But... we are doing that somewhat already. I have looked into the scenario a lot, and there are many things we can do to improve user experience.
The *KEY* here is that we have several interacting issues, and we want to solve the overall experience. We don't want to break one thing here to fix another thing over there.
I acknowledge that bug reports only highlight problems with the existing implementation, and do not highlight problems with the proposed changes, so you are at a disadvantage.
No, it is neither bulletproof nor idiot-proof.
How? How in the world is it possible to break an embedded image? (Provide an example.)
I have. Since you don't care to actually address that, it is clear you really are more interested in arguing rather than in fixing.
***PLEASE***
** Update the wiki with use cases and personas
** Come into the chat room like the other developers
Both of these can significantly improve communication and help solve problems.
We also need to consider the worst severity event for each solution. I cannot imagine a situation where temporarily not being able to edit an image externally (the embedded image can be extracted) is more serious than not having it at all, because somebody did not know to send it.
Very good points. Did you include them on the Wiki yet???
The first situation happens when the user still has full access to all data, so fixing the "problem" is as simple as finding the link option. In the second situation the user is missing a piece of data and fixing the problem is impossible without contacting the sender of the broken document.
Again, I distill a key point for the requirements here. "Must solve the problem will full access to data is available"
Please make sure that is covered in the wiki.
Embedding by default might not be completely problem-free, but at least it does not create problems that cannot be addressed within the application (missing data). I acknowledge that no solution is completely idiot-proof, just as there is no absolute safety or absolute security, but some solutions are more resistant to inexperience than others.
A simple fix that addresses this includes what others have proposed. The first time a potentially confusing situation is encountered we just notify the user so that it won't be a surprise. Simple users can choose their most helpful setting, but non-simple users can get the more beneficial one. Also we should include the "don't show me this again" option that is so common in many programs.
Did you ensure this has made it's way onto the wiki?
Have you tried?
Yes, I did it to examine how an embedded image's XML looks like. Maybe it wasn't lightning fast, but gedit handled it OK. That was on a 1.1GHz computer with 1GB of RAM, so not a powerhorse by any measure. Digression: the aforementioned average Joe who will use the default will never open the file in a text editor! Anyone who wants to hand edit his document will have no problem overriding the default and creating links.
Ah, but then we have the problem you've already pointed out. User A create artwork and hands it off to user B. User B then suffers the pain.
That is a "meta problem" describing several you've seen and pointed out already, but it applies equally well in this case.
Personally I've had problems trying to edit files with embedded data using emacs and others. Some have gotten so bad as to make emacs unusable on them. (That's quite a feat BTW)
Also, you mention the system you tried to edit on, but what about the size and number of embedded images? We will need to collect up info on ranges so that we can set proper cutoffs or warnings, much like we had to do with our preview dialog. And just like with the preview dialog, if we don't have good details on how certain values are chosen, we will see problems as we go and things change.
On Dec 27, 2009, at 5:16 PM, Jon Cruz wrote:
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.
On Dec 27, 2009, at 5:16 PM, Jon Cruz wrote:
The *KEY* here is that we have several interacting issues, and we want to solve the overall experience. We don't want to break one thing here to fix another thing over there.
BTW, I just pruned this from the Wiki: "The solution must involve combining raster data with the SVG, so that they reside in the same file."
The reason is that the statement is really taking an opinion and a mistaken assertion at that. There are several different implementations we could choose between to solve the problem, so we'll need to be able to list them out so we can consider them well.
(In fact, I've even written code to bundle things into MIME multipart many times, so that is a completely viable option for solving an "e-mail problem".)
W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <jon@...18...> napisał:
- 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 management. As the user requests in that report: "... simple right click on a "broken image" and then be able to update the path for all the images that are in selection?"
Was the user aware of the fact that images can be embedded in the SVG? I think not many users are aware of this because this feature is very poorly discoverable. Also consider that in the email case there is no way to fix the document once the incomplete document is sent - better media management won't help.
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.
On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:
W dniu 28 grudnia 2009 02:16 użytkownik Jon Cruz <jon@...18...> napisał:
- This expectation comes from knowing Inkscape behavior. Even if a
Nope. Not a blocker. In fact, that is easily addressed by correcting behavior and *keeping*linking. In fact, it will make things easier since you won't have as much bloat being sent over the wire at runtime.
If the protocol is Jabber, we must base64 encode the image anyway. No gain from linking, and a few complications (the URI has to be different on both sides). http://en.wikipedia.org/wiki/Jabber#Weaknesses
But did you finish reading that paragraph you cite?
The limitation is for *in-band* data transfer. There standard ways that Jabber does *out-of-band* file transfers. This is common for most any instant messaging protocol.
*HOWEVER* you missed the main point. If linked images already exist on both sides, then there is no need at all to exchange them.
And if a linked image does not exist on one side, it is easy to transfer that image once and only once, and for *any* sessions that those systems engage in, including editing many different SVG files in a collaborative manner.
As I look over this, it actually strengthens my opinion that we need to support "linking *plus* media management".
This is my opinion as well! But better media management and the default paste/DnD behavior are not the same.
Again, this is exactly where you are not seeing the forest for all the trees.
Guess what? This one actually cries out *explicitly* for proper linked media management. As the user requests in that report: "... simple right click on a "broken image" and then be able to update the path for all the images that are in selection?"
Was the user aware of the fact that images can be embedded in the SVG? I think not many users are aware of this because this feature is very poorly discoverable. Also consider that in the email case there is no way to fix the document once the incomplete document is sent - better media management won't help.
Please look over what has been said... even by you in this last paragraph.
Let me try to spell it out for you:
"Was the unser aware..." "...poorly discoverable..." "...no way to fix... once ... is sent..."
Those all call out as signs of a usability issue. There are a few approaches. These include: * It is tricky, so don't do it at all and * It is tricky, so make it clear and simple
Right now the media management is poor in that it does not convey things to users and users get surprised. We *need* to address it so that it is not surprising. Actually that is what you are doing when you suggest to *always* embed images:
Problem: some users are confused by linking vs. embedding of external media assets. Solution: never link external media assets, only embed them. This results in 100% consistent behavior.
That proposed solution *is* better media management. It probably is not the best way to improve it, but it is doing just that. So your assertion that "better media management won't help" is false.
I believe that is exactly what I pointed out would solve use cases you added initially. This appears to be the "Sara" use case, and would be solved by the "Sara" solution.
So, what is the "Sara solution"?
Please go back and read things again. Or drop into the chat room like the other developers and users. That *REALLY* helps with communication.
https://bugs.launchpad.net/inkscape/+bug/415374 (User uploaded an SVG with image links to a website, surprised by broken images. Read the first comment, because the reporter misuses the word "embedded". Apparently linking by default is sometimes confusing even in the Web context!)
Nope. Not a blocker either. *IF* you had done a scan of bugs with the "big picture" in mind, you would see that related issues come up with an *unsaved* document not having a fixed location.
The last bug is not related to the default save location, it was related to users not aware of links. Only the 2nd bug was related to the Sara case.
Yes. But my point is that taken in a "big picture" view (i.e. the forest, and not just the trees) a single solution *can* solve both. Taken in the localized view (i.e. trees, and not the forest) it can't.
I see you changed the descriptions of the bugs I mentioned to describe your solutions, which I think are not addressing the fundamental problem, which is: average Joe doesn't know what a link is, and will not benefit from any advantages they might give. Links can only hurt him, by breaking his documents. Embedded images can't, and they are only a very minor nuisance for more advanced users, who will find the commands to create links and will know what they do.
No.
You are the one who changed the *one* description away from the descriptive end-user problem and instead to describe the bug in terms of the proposed solution as you see it. I just put it back.
In particular, the "embed on save as" option will be ineffective, because the unsophisticated user will not know he has to choose it. If we default it to on, then it is completely equivalent to embedding on paste/DnD, but the latter has the advantage of being simpler to implement and not modifying the document when saving (which is a very important conceptual consideration).
No. This is where you are just not getting it. That is also why we *NEED* to have things spelled out clearly in the wiki. A comprehensive solution that solves the whole problem in its entirety will address that.
What you are proposing is a micro-fix that solves things for one group of users at the *expense* of another group. That is the main problem there.
Finally, I see you want to fix each bug with a different and specific solution, while the very simple change of embedding by default on paste and DnD + providing "embed/link" radio buttons in the import dialog would solve them all in one go.
No. You are seeing that completely wrong.
First, "embed" will not solve 100% of things for 100% of people as you claim. Just ask the people on IRC. Or re-read these threads.
More importantly is that again you are incorrectly stating my intent. The key thing is that I do *NOT* want to fix each bug with a different and specific solution. You are the one doing that.
My intent, on the other hand, is to collect up *all* facets of this problem *overall* and then solve them in a comprehensive manner. When combined together, a *few* changes can solve many, many problems.
Look again. "Always embed" may fix some of the use cases you added to the wiki, but it will piss off Sara with her use case.
A simple fix that addresses this includes what others have proposed. The first time a potentially confusing situation is encountered we just notify the user so that it won't be a surprise. Simple users can choose their most helpful setting, but non-simple users can get the more beneficial one.
The default for this dialog box would have to be embedding, so it's equivalent to my solution, but with an extra nuisance of a dialog box.
This may or may not work, depending on which user you have. That is critical to grasp. It might solve things for user A, but break things for user B. We need to cover all cases.
Moreover it disregards a well known fact that users don't read message boxes, even if they say "WARNING, CLICKING CANCEL WILL DESTROY YOUR COMPUTER"; this is particularly true for unsophisticated Windows users, which this solution targets. So your solution does not match the target persona (Charlie). What was the point of writing all the stuff on the wiki if you just ignored it?
Not true. At least not the way you state.
Different users look at things to different degrees, and there have even been good presentations and research done on just this point. Go review the work Michael Terry has been doing, especially what he presented at LGM.
Here's a Microsoft account of how dialog boxes are ineffective at informing the user or prompting him to make a choice. http://blogs.msdn.com/oldnewthing/archive/2003/09/01/54734.aspx
Remember, Microsoft is the epitome of bad user interaction. So most anything they present will be discounted.
Another informative blog post. http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
I also don't like things like "don't show this again" boxes. How do I change the setting I'm asked for later? Even if it's written in the dialog box I'm disabling, I might forget what it said. We should avoid them if possible (and my solution does avoid them).
Ah, but then we have the problem you've already pointed out. User A create artwork and hands it off to user B. User B then suffers the pain.
When we look at the case for this perspective, embedding is an obvious winner. In the "Charlie" case, embedding significantly decreases the pain for B. (In fact that was my primary reason to propose it in the first place.)
With linking, it is likely that user A would not send all the needed data. User B would have to contact A, explain to him that he has image links in his document, and prompt him to send them. Then user A might have trouble remembering where is the image he pasted (for example if he DnDed it from a 10000+ photo collection which have camera-given names like "DSC_2657.JPG"), and the whole matter drags out; then user A blames it on Inkscape and never uses it again. User B can text edit the document, but loses a lot more time getting the missing data, and then has to cope with proprietary CDR or AI files user A is sending him.
With embedding, user B has to extract the images before text-editing the document, but he does not need to contact user A and explain anything. We slightly inconvenience the user B, but still do better than in the linking case. User A is completely satisfied.
Again. PLEASE, PLEASE actually enter these use cases you keep coming up with into the wiki.
Also, you mention the system you tried to edit on, but what about the size and number of embedded images? We will need to collect up info on ranges so that we can set proper cutoffs or warnings, much like we had to do with our preview dialog.
Definitely could help. My image wasn't very large (a few hundred KB). On my main desktop, which has 6GB of RAM, opening a file containing a large JPG photo (several MB) is effortless; gedit uses 32.9MB for this, so I suppose it's perfectly possible on a modest machine. I'll follow up with more tests later.
Thanks. A table in the Wiki will be of immense value. Also we should check it on a few editors, not just gedit. Notepad comes to mind right off hand.
(In fact, I've even written code to bundle things into MIME multipart many times, so that is a completely viable option for solving an "e-mail problem".)
This is irrelevant because we have absolutely no control over how the e-mail is sent, that's why I added that requirement. If you want to invent a new container format that uses MIME multipart, then a more standards compliant and more space-efficient way is just to use embedding. Or you can submit a proposal for SVG 2.0 to include your new container format.
No, it is relevant. There are many ways to get things packaged and sent, and you might be surprised at how the various mail programs behave.
Also... I *HAVE* cited existing container formats, but you keep ignoring such information so I'll will stop now.
On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:
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.
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.
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.
On Dec 28, 2009, at 9:37 AM, Krzysztof Kosiński wrote:
Also consider that in the email case there is no way to fix the document once the incomplete document is sent - better media management won't help.
As I was refining the Wiki details, I did a quick listing of some of the types of external asset we might need to support. This is under one of the points on "Issues"
http://wiki.inkscape.org/wiki/index.php/Improved_Media_Management#Issues
Is there any reason to say the need to embed these is any different than that with images in an <image> element? <image> elements to PNG, JPEG, SVG and other images. ICC color profile files (.icc, .icm, etc.) CSS stylesheet files (.css) Cursor files (.cur, .csr) GIMP palette files (.gpl) SwatchBook files (.swb) Script files (.js) WebFonts TrueDoc™ Portable Font Resource (.pfr) Embedded OpenType (.eot) PostScript™ Type 1 (.pfb, .pfa) TrueType (.ttf) OpenType, including TrueType Open (.ttf) TrueType with GX extensions Speedo Intellifont
Second, am I missing any from that list?
W dniu 28 grudnia 2009 19:53 użytkownik Jon Cruz <jon@...18...> napisał:
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 :/
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
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.
participants (13)
-
unknown＠example.com -
Alexandre Prokoudine -
Alvin Penner -
Diederik van Lierop -
Donna Benjamin -
John Cliff -
Jon A. Cruz -
Jon Cruz -
Joshua A. Andler -
kaver -
Krzysztof Kosiński -
Steren -
Steven M. Ottens