Hi, I did a fresh install of the 0.42 autopackage from http://www.inkscape.modevia.com/ap/inkscape-0.42.x86.package on my Mandriva 2005 LE. I found the following strange behaviour: - I create a new drawing with a circle. - Duplicate the circle and resize it (the width of the stroke resizes also) - Now if I select the second circle and try to set the stroke width to 1 pt by clicking on the up and down arrows of the width field in the Fill and stroke dialog it only increases the width both clicking the up or down arrow. The increment is also not one by one, but it is a geometric increment: 4,1 -> 6,5 -> 10,4 -> 16,6 -> 20, etc
I hope you can reproduce this.
On 7/26/05, Lucas Vieites <lucas@...212...> wrote:
or down arrow. The increment is also not one by one, but it is a geometric increment: 4,1 -> 6,5 -> 10,4 -> 16,6 -> 20, etc
Fixed in CVS, thanks for reporting
Hey, we got a mention on the Xarax TalkGraphics list.
http://talkgraphics.com/groupee/forums/a/tpc/f/44419488/m/8051060431
Eobet's note included....
...Currently, I have to admit that the program is utterly unusable, but still it displays potential for some extremely nice features. For example, not only does it have elliptical fills (something which Xara was alone in having a few years back), but you can link nodes in a fill between objects! Also, you can choose to put the stroke inside, or outside the object itself (though that feature is still very undeveloped, and needs to be expanded in order to be useful)...
Not mentioned is the fact of the 0.42 release but the timing suggests that this is what is being talked about.
Erik
On Wed, Jul 27, 2005 at 11:48:57PM +1000, Erik wrote:
Hey, we got a mention on the Xarax TalkGraphics list.
http://talkgraphics.com/groupee/forums/a/tpc/f/44419488/m/8051060431
Eobet's note included....
...Currently, I have to admit that the program is utterly unusable, but still it displays potential for some extremely nice features. For example,
I wonder why he describes it as "utterly unusable"?
I hate it when users throw around complaints without any tangibly useful ideas to consider. Maybe they don't understand that since Inkscape is an open source project, they can get much more intimately involved in helping define the project direction than they ever could with commercialware...
Bryce
On 7/27/05, Bryce Harrington <bryce@...260...> wrote:
On Wed, Jul 27, 2005 at 11:48:57PM +1000, Erik wrote:
Hey, we got a mention on the Xarax TalkGraphics list.
http://talkgraphics.com/groupee/forums/a/tpc/f/44419488/m/8051060431
Eobet's note included....
...Currently, I have to admit that the program is utterly unusable, but still it displays potential for some extremely nice features. For example,
I wonder why he describes it as "utterly unusable"?
I could not understand this either. Worst of all, I can't respond to it, even though I registered - the site won't let me, displaying "Please wait" forever. Anyone had more luck with that site?
On Wed, 27 Jul 2005, Erik wrote:
Date: Wed, 27 Jul 2005 23:48:57 +1000 From: Erik <kaver@...68...> To: bulia byak <buliabyak@...400...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Possible bug in 0.42
Hey, we got a mention on the Xarax TalkGraphics list.
http://talkgraphics.com/groupee/forums/a/tpc/f/44419488/m/8051060431
Eobet's note included....
...Currently, I have to admit that the program is utterly unusable, but
Oooh harsh. At first I was going to try and rationalise his criticisms but I got the current release of Inkscape running and I had trouble sleeping last night as a result.
Frankly the usability of Inkscape has gotten worse even if the functionality has increased. To some extent it is because of the increased funtionality that Inkscape is more cluttered and difficult to learn.
The edit menu has a massive twenty one, count 'em 21 items. I doesn't take an expert to know there are problems even I can see Inkscape has serious usability issues. There are many other superficial problems like this some of which I have already pointed out but were ignored. The Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
If developers were to read through the Gnome Human Interface guidelines, especially anyone touching the User Interface and make lots of minor changes based on it Inkscape could be improved quite a lot but more radical changes may be needed if you really want to satisfy the mass market.
Between them Adobe Illustrator and Macromedia Freehand effectively dominate the market and mindshare for vector graphics applications and Inkscape is a very different application. I still seriously believe that we must at least match the behaviours that both Illustrator and Freehand share in common and that requires changing a lot of the keybindings and menu structure. Inkscape has gotten a lot bigger and will only get even bigger so a menu restructuring will be needed anyway soon enough.
I am sorry to say I am dissapointed by Inkscape 0.42 which in some ways has taken steps backward in terms of usability, so much so that I am very reluctant to comment on it just yet. I'm mildly upset my previous advice was ignored, even if solutions I suggest are not always ideal it is particularly disappointing when people miss my point (even if I didn't make it all that clearly) and to see nothing done to address the problems that prompted me to make the suggestions in the first place.
If you are sure you want to hear criticisms about the current user interface, are mature enough not to take it personally and are interested in doing something about my suggestions then please let me know. I haven't had that much time to poke and prod Inkscape over the last few months and I really dont have the time now but I will try and find the time to explain the problems I see.
I wish I had something more constructive to say (the gradient and tiled clones features are certainly cool although a little awkward at first) but there isn't anything wrong with Inkscape that cannot be fixed if you really take a long hard critical look at it.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
The edit menu has a massive twenty one, count 'em 21 items.
22 here, and I wonder how we could reduce this amount by half.
One way would be creating Just Another Menu, say, Actions and move alle duplicate/clone stuff over there. That would give as 16 menu items with 2 patterns related menu items looking alien.
I doesn't take an expert to know there are problems even I can see Inkscape has serious usability issues. There are many other superficial problems like this some of which I have already pointed out but were ignored. The Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
Already discussed and mockuped.
Alexandre
Alexandre Prokoudine wrote:
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
I doesn't take an expert to know there are problems even I can see Inkscape has serious usability issues. There are many other superficial problems like this some of which I have already pointed out but were ignored. The Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
Already discussed and mockuped.
Alexandre
Do anyone still have my old mockup somewhere? Not sure myself where I put it, but I can probably find it if I look around a bit. It would be nice if this one could go in 0.43, because as pointed out, the current preferences dialog are in need for some love. I know there were some .glade file done by someone, but if I recall correctly, it was decided for Inkscape not to use glade. - Andreas
On 7/28/05, Andreas Nilsson <nisses.mail@...563...> wrote:
this some of which I have already pointed out but were ignored. The Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
Already discussed and mockuped.
Alexandre
Do anyone still have my old mockup somewhere? Not sure myself where I put it, but I can probably find it if I look around a bit. It would be nice if this one could go in 0.43, because as pointed out, the current preferences dialog are in need for some love. I know there were some .glade file done by someone, but if I recall correctly, it was decided for Inkscape not to use glade.
http://ramnet.se/~nisse/diverse/temp/inkscape_new_prefs_mockup2.png
Alexandre
On Thursday 28 July 2005 11:52, Alexandre Prokoudine wrote:
http://ramnet.se/~nisse/diverse/temp/inkscape_new_prefs_mockup2.png
Alexandre
Might I suggest a different approach to preferences?
It's probably not GNOME- HIG–compliant, but I think it would be best to have application-level defaults and application-level preferences, with document-level overrides.
So, for instance, the document preferences dialog would have, instead of a normal boolean checkbox, a tri-state checkbox, which allows using the the application preferences, or overrriding them with a new value. Similarly, the application preferences dialog would allow you do stick with the defaults in inkscape itself, or override them.
This would have a number of advantages:
* An upgrade to inkscape that introduces new preferences or new defaults for usability reasons would not be 'lost' by upgraders who have saved different choices on specific items.
* If a user had deliberately chosen a feature they liked, even if it was already the default, it would remain even if an upgrade changed that default for everyone else.
* Sharing documents for collaboration would be easier, since you wouldn't be sharing all of your personal preferences in the document, but just what is important for that document itself.
* Code-duplication would be reduced, since the document-preferences and application-preferences would be virtually identical. With clever architecture, it might be also/instead possible to use the same preferences for tool dialogs/panels/rollups in the main window.
Lee Braiden wrote:
This would have a number of advantages:
- An upgrade to inkscape that introduces new preferences or new defaults for
usability reasons would not be 'lost' by upgraders who have saved different choices on specific items.
- If a user had deliberately chosen a feature they liked, even if it was
already the default, it would remain even if an upgrade changed that default for everyone else.
I think the preferences change after an upgrade is a non-issue: the application wide preferences are kept in ~/.inkscape/preferences.xml and are not affected by upgrade or even uninstall. Also, document level preferences are kept inside the document so not affected by upgrade.
- Sharing documents for collaboration would be easier, since you wouldn't be
sharing all of your personal preferences in the document, but just what is important for that document itself.
Here I can't follow you: is about more or less preferences to be saved inside the document?
- Code-duplication would be reduced, since the document-preferences and
application-preferences would be virtually identical. With clever architecture, it might be also/instead possible to use the same preferences for tool dialogs/panels/rollups in the main window.
I am not so sure about the reduction of code-duplication, as in the most cases application and document preferences are disjunct groups, for example why save inside the document (and bloat the file) settings like the default number of corners in a star or display style of gradient cues?
On Thursday 28 July 2005 12:43, Nicu Buculei wrote:
I think the preferences change after an upgrade is a non-issue: the application wide preferences are kept in ~/.inkscape/preferences.xml and are not affected by upgrade or even uninstall. Also, document level preferences are kept inside the document so not affected by upgrade.
Well, if the preferences save anything that has not been changed from its default setting, and then those preferences are re-loaded en-masse later, in a new version, thereby overriding different defaults, that creates problems. You can't change anything, without changing EVERYTHING. But I'm not certain as to whether Inkscape actually makes this mistake.
Here I can't follow you: is about more or less preferences to be saved inside the document?
It's about saving only what is helpful at a certain level, and allowing the rest to be inherited from a higher level.
I am not so sure about the reduction of code-duplication, as in the most cases application and document preferences are disjunct groups, for example why save inside the document (and bloat the file) settings like the default number of corners in a star or display style of gradient cues?
Well, let's say a team is working on a certain document, with lots of similar elements. You may want to be able to specify in the document itself that a default rectangle should have a certain rounding to the corners, without everyone having to manually specify that or copy it from existing items. It would be much easier to simply create a new rectangle according to the team's pre-chosen settings, if the document specified those settings.
Likewise, it would *not* be preferable to have another team member's choice of magnification or window size affecting your working environment, just because they are working on the same document.
Andreas Nilsson wrote:
Alexandre Prokoudine wrote:
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
I doesn't take an expert to know there are problems even I can see Inkscape has serious usability issues. There are many other superficial problems like this some of which I have already pointed out but were ignored. The Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
Already discussed and mockuped.
Alexandre
Do anyone still have my old mockup somewhere?
After Alan's message I looked in the most obvious place and is not there: http://inkscape.org/cgi-bin/wiki.pl?PreferencesDialog
On Thu, 28 Jul 2005, Alexandre Prokoudine wrote:
Date: Thu, 28 Jul 2005 14:01:59 +0400 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: Inkscape Harsh Criticisms [was Re: [Inkscape-devel] Possible bug in 0.42]
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
The edit menu has a massive twenty one, count 'em 21 items.
22 here, and I wonder how we could reduce this amount by half.
Inkscape 0.40 had a relatively flat menu structure which did a good job of exposing all the functionality that was already there.
Inkscape 0.42 has a lot more functionality and I think we need to create some submenus for certain things. Inkscape needs to shed its skin to allow room to grow. Rather than get into specifics just yet I urge you to look at other software and do that competative analysis, particularly Adobe Illustrator and Macromedia Freehand. If you think it is annoying how I keep bringing it up just wait until a mainstream graphics magazine reviews Inkscape and you can bet they will have something pretty similar to say. Keep in mind that generally menus should not exceed 15 items, and should have at least 3 items (this guideline is flexible but a good rule of thumb).
One way would be creating Just Another Menu, say, Actions and move alle duplicate/clone stuff over there. That would give as 16 menu items with 2 patterns related menu items looking alien.
It doesn't take an expert to know there are problems even I can see Inkscape has serious usability issues.
We shouldn't be surprised when users are critical of Inkscape, the bug tracker is far from empty. Of course you should be proud of how far Inkscape has come. It seems like I have to play Devils Advocate and try to point out problems but I would really prefer if everyone could take a step back, forget what they have already learned and try to take a fresh look at Inkscape. Why is that there? If I am were an artist trying to create something would I want really want to see feature X or are implementation details I don't need to see being exposed?
this some of which I have already pointed out but were ignored. The Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
Already discussed and mockuped.
Great. I guess this is the usual problem of managing expectations. There are parts of Inkscape we all know are not as good as they could be but the general public doesn't know that. I think previous releases have been a lot more careful about saying which features we know still need a lot more work.
I can say with confidence Inkscape is by far the best Cross Platform, Open Source, Gtk based, Scalable Vector Graphics editor! Unfortunately users inevitably rush to compare Inkscape against their own specific requirements and although some of their points may come across as "different is bad" there is always something we can learn from criticism even if it is sometimes difficult to hear it.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
The edit menu has a massive twenty one, count 'em 21 items.
I have a feeling everyone is looking at me. Hey guys, I think I already explained it: menus (top menus and right-click menu) are NOT my domain. I'm just not interested in them because I don't use them. EVERYONE is welcome to come and rearrange them in any way imaginable. Hey, rearranging top menu items is as easy as rearranging single lines in interface.cpp. Where are your patches?
Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
What is BY FAR most important to _me_ is that all options have meaningful descriptions and tooltips, and on copyediting them I spend a lot of my time. The rest (what? pretty icons? anyway, whatever you like) can be handled by anyone who's motivated to do it.
I am sorry to say I am dissapointed by Inkscape 0.42 which in some ways has taken steps backward in terms of usability
Such as? Please be specific.
Hi all,
I think this is a good thread, but please work to keep the discussion constructive. This thread has a provocative title, and is going to encourage some (welcome and hopefully useful) criticism of Inkscape's usability.
Also, note that one of Inkscape's key principles is "Patch first, discuss later". By this we mean that it's always easier to express and argue an opinion on the mail list, but we feel it is much, much more productive to demonstrate ideas through code contributions, mockups, and documentation.
Thus, if you are passionate about your ideas for improving usability, please consider submitting patches if you can. If you cannot, then of course share your ideas here on the list, but please avoid arguing over points, and I'd also caution against building up your expectations that someone will implement the ideas, even if you're right. ;-)
In the end, remember that Inkscape is a community-driven project and is still in heavy development. We're not going to achieve perfection overnight, and need to accept that there are still many flaws, but by cooperating and each putting in some time in various areas, we can make some very good improvements.
I'm actually looking forward to this thread, because we've not had critical discussions about the interface for a while, and as has been pointed out, we've grown so much lately that we definitely need it.
Bryce
On Thu, 28 Jul 2005, bulia byak wrote:
Date: Thu, 28 Jul 2005 14:41:52 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: Inkscape Harsh Criticisms [was Re: [Inkscape-devel] Possible bug in 0.42]
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
The edit menu has a massive twenty one, count 'em 21 items.
I have a feeling everyone is looking at me. Hey guys, I think I already explained it: menus (top menus and right-click menu) are NOT my domain. I'm just not interested in them because I don't use them. EVERYONE is welcome to come and rearrange them in any way imaginable. Hey, rearranging top menu items is as easy as rearranging single lines in interface.cpp. Where are your patches?
Fair point but that only goes so far, I really dont have the time to work on every project I see a problem with even if I would like to help.
The menus were but one example.
Inkscape Preferences dialog is a candidate for the User Interface Hall of shame.
What is BY FAR most important to _me_ is that all options have meaningful descriptions and tooltips, and on copyediting them I spend a lot of my time. The rest (what? pretty icons? anyway, whatever you like) can be handled by anyone who's motivated to do it.
That is condescending and dismissive. There are serious structural problems in the layout. In one situation you can get three levels of Tabbed dialogs which is frankly insane but Alexandre has worked on this and hopefully his work can be put into practice.
Please do try to read through the Gnome Human Interface Guidelines even reading a little of it might help give a sense of some of the underlying concepts. A good book on user interface design would probably be more pleasant to read though and just as informative.
I am sorry to say I am dissapointed by Inkscape 0.42 which in some ways has taken steps backward in terms of usability
Such as? Please be specific.
How long have you got?
Keep in mind you did ask and I did warn you ...
I dont have time to list everything. I'm not an expert either so sometimes all I can do is vaguely point at a problem without necessarily being able to offer a solution.
If the Inkscape developers cannot step back and see most of the problems themselves things will only get worse again. Reread my previous mail and see if you can guess which misfeatures I was trying to point out, try and find a prominant feature that is more about debugging than about artwork and never should have been left visible in a release build.
My previous comments about getting rid of parenthesis from menu item(s) was ignored.
Vacuum Defs is still weird. I don't have all the answers but a way to "define styles" and treat defs similarly to predefined styles.
I know a lot of my suggestions will amount to looking at the competition and seeing what they do which is why I encourage others to do the same. I suppose I should look at XaraX too and try and get some insight into where Bulia is coming from but I think Adobe Illustrator and Macromedia Freehand are by far the most important to take a look at.
Other miscellanious quibbles, fairly raw and unfiltered:
need a submenu "View, Zoom" (short version, long versions will require a little more thought and reorganisation)
keybindings are not configurable, forces developers to try and hardcode defaults for everything cannot please everyone.
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience. of course I'd love to have both but it doesn't make for a great default approach.
using the commands bar/options bar for both the tool defaults and changing the properties of the current object is weird (therefore harder to learn) and I still dont particularly like it.
the tools: node tool doesn't include any labels in the Commands bar would help if some of the items were labelled. same goes for the Zoom tool, too many similar icons are hard to disambiguate and text would help. text to the right of some of
retangle tool "Not rounded" inconsistent should be Reset, other tools labelled default should be renamed to Reset (use a verb not a noun).
freehand/draw bezier/text tools have nothing on the command bar. colour picker has only one item. seriously rough edges, sanding smoothing painting and polishing required.
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
"Help, About memory" is not a useful user (artist not developer user) feature should at the very least be hidden from release builds (this is what I was referring to earlier).
Help About Inkscape. I'd prefer if this were simply Help, About like most Gnome programs. Stock items make less translation work. I strongly recommend implementing the standard GtkAbout dialog. The standard dialog provides version and contact information that can be easily cut and paste out of the dialog. The inkscape about dialog does not. use the standard dialog, make work then make it pretty later.
Rulers are ugly. Turn them off by default. Sure there is a small discoverability penalty but Inkscape is not for techincal drawing and we dont leave the grid on by default either.
The word metadata is jargon and we should not need to use it in the user interface. I've complained before about the Document preferences dialog, I think we need to do a split between the "Page Setup" and the File Properties (aka metadata). read the HIG, text should generally be left aligned (sometimes top left) it isn't in this dialog.
Group Ctrl+G, Ungroup Ctrl+U. Isn't Ctrl+U being used elsewhere for Unicode input? using Ctrl+Shift+G would be more consistent with the HIG anyway.
think as a new user: "How is a Path not an Object?" is suspect they aren't and a reorganisation will effectively merge most of this back into the Object menu. dont have a copy of Illustrator available to check against unfortunately.
Fill and Stroke, Swatches, Object Properties are all palettes/docks and should probably be under view rather than Object.
The Layer menu includes a lot of "Layer, something Layer" which is redundant.
having a top level select menu might help sort out some of the imbalance in the Edit menu but it may only serve to move the problems around. The tool "Edit, Find" in many ways similar to Select by ...
"Help, Keys and Mouse" doesn't make sense, needs a better label.
...
...
you did ask ...
dont say I didn't warn you ...
More later. It is difficult to turn my brain off and be hypercritical about everything. It can be quite tiring and a little depressing especially when I start feeling I'm being ignored. Being able to look back and say "I told you so" doesn't motivate me to continue making suggestions (which combined with exams is why I've been fairly quiet recently).
I hope others can learn to cast a critical eye on Inkscape because if it sucks to be the only one playing devils advocate, and it is not my goal to be the designated jerk but keep in mind I'm trying to give useful feedback but sometimes I have to tap into my "inner troll" to do it and it makes me really crankey. Arguing on the internet just makes everyone involved a loser and it is not my idea of fun. I dont have time (or expertise but it is effectively the same as time) to implement most/any of this even providing as much nitpickign as I do requires a fair amount of effort without so much as a footnote in the Thanks file for it.
If you want me to keep doing this you really have to keep asking. Inviting the Gnome usability team and the Open Usability group to take a go at reviewing Inkscape might be a good way to hear a different point of view from mine for a change.
Oh and if you could get Inkscape into Garnome[1] I'd be a lot more likely to build it occasionally and perhaps others would too.
Sincerely
Alan Horkan
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
In one situation you can get three levels of Tabbed dialogs which is frankly insane but Alexandre has worked on this and hopefully his work can be put into practice.
I wish I was that good man, but I'm not :) It's Andreas Nilsson
concepts. A good book on user interface design would probably be more pleasant to read though and just as informative.
I encourage you to read http://www.martianrock.com/?p=107 first :)
need a submenu "View, Zoom" (short version, long versions will require a little more thought and reorganisation)
nice point
keybindings are not configurable, forces developers to try and hardcode defaults for everything cannot please everyone.
Will be implemented by our gtkmm wizards. I remember myself showing Bryce screenshot from Audacity and/or Scribus where it is implemented and I remember him agree to go that way.
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience.
true
freehand/draw bezier/text tools have nothing on the command bar.
true
colour picker has only one item.
what else would you like to see there? ;)
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
Yes, I even I translate it simply as "License" into Russian :)
"Help, About memory" is not a useful user (artist not developer user) feature should at the very least be hidden from release builds (this is what I was referring to earlier).
Not really. Please remember that Inkscape hasn't reached 1.O yet and users are supposed to use things like these to help developers. Or do you prefer to wait for gnome/kde system monitor to start just to make sure Inkscape isn't eating all the memory?
Help About Inkscape. I'd prefer if this were simply Help, About like most Gnome programs. Stock items make less translation work. I strongly recommend implementing the standard GtkAbout dialog. The standard dialog provides version and contact information that can be easily cut and paste out of the dialog. The inkscape about dialog does not. use the standard dialog, make work then make it pretty later.
I remember discussion when a GIMP like About dialog was suggested to be used.
Rulers are ugly. Turn them off by default.
Excuse me? How are users supposed to add guidelines? :))))
The word metadata is jargon and we should not need to use it in the user interface.
Uhm, not really jargon.
Fill and Stroke, Swatches, Object Properties are all palettes/docks and should probably be under view rather than Object.
Yes
"Help, Keys and Mouse" doesn't make sense, needs a better label.
I would move it to 'Manuals' (or whatever it's in English) submenu.
Alexandre
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
Hey, rearranging top menu items is as easy as rearranging single lines in interface.cpp. Where are your patches?
Fair point but that only goes so far, I really dont have the time to work on every project I see a problem with even if I would like to help.
This wasn't directed to you personally. Other people have expressed their issues with the menus, and I myself agree that the Edit menu has become unwieldy. Let's fix it!
a lot of my time. The rest (what? pretty icons? anyway, whatever you like) can be handled by anyone who's motivated to do it.
That is condescending and dismissive.
Sorry if it sounded like that. I just said the same as Bryce - everyone works on what interests him/her.
In the below responses to your comments, note that I'm not speaking on behalf of all Inkscape developers. I only express my opinion.
My previous comments about getting rid of parenthesis from menu item(s) was ignored.
I see no problem in that whatsoever. It's not new in 0.42 anyway.
Vacuum Defs is still weird. I don't have all the answers but a way to "define styles" and treat defs similarly to predefined styles.
This was already discussed. You didn't convince me and, as far as I remember, others. It's not new in 0.42.
need a submenu "View, Zoom" (short version, long versions will require a little more thought and reorganisation)
May be a good idea, but personally I'm ambivalent. You gain a shorter menu but you lose an extra click. Don't know which wins.
keybindings are not configurable, forces developers to try and hardcode defaults for everything cannot please everyone.
In what way is this a regression in 0.42? Everyone agrees this should be done. It's just not done yet.
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience. of course I'd love to have both but it doesn't make for a great default approach.
Already discussed, I'm not convinced, not a regression in 0.42.
using the commands bar/options bar for both the tool defaults and changing the properties of the current object is weird (therefore harder to learn) and I still dont particularly like it.
Already discussed, I'm VERY MUCH not convinced (I think it's one of the best things in our UI), not a regression in 0.42.
the tools: node tool doesn't include any labels in the Commands bar would help if some of the items were labelled. same goes for the Zoom tool, too many similar icons are hard to disambiguate and text would help.
May be a good idea. Can you make a specific proposal?
retangle tool "Not rounded" inconsistent should be Reset, other tools labelled default should be renamed to Reset (use a verb not a noun).
Disagree, I think this was already discussed. The labels say what this button does SPECIFICALLY. "Reset" tells me nothing and will likely scare me away.
freehand/draw bezier/text tools have nothing on the command bar. colour picker has only one item.
Sure, we're working on it. Lots of ideas on what to put there. Just wasn't ready in time for 0.42.
seriously rough edges, sanding smoothing painting and polishing required.
Such as?
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
Not my area - Peter, can you comment?
"Help, About memory" is not a useful user (artist not developer user) feature should at the very least be hidden from release builds (this is what I was referring to earlier).
Maybe we'll hide it for 1.0 when we patch all leaks. For now it's useful to those who can use it, and pretty nonobtrusive for others.
Help About Inkscape. I'd prefer if this were simply Help, About like most Gnome programs.
OK with me
Stock items make less translation work. I strongly recommend implementing the standard GtkAbout dialog. The standard dialog provides version and contact information that can be easily cut and paste out of the dialog. The inkscape about dialog does not. use the standard dialog, make work then make it pretty later.
Some people were planning to do just that for 0.43.
Rulers are ugly. Turn them off by default.
???????
Can you share your definition of "ugly" please?
To me they're perfectly OK, not worse nor better than in any other vector app.
The word metadata is jargon and we should not need to use it in the user interface.
Nope, it's a well-defined term.
I've complained before about the Document preferences dialog, I think we need to do a split between the "Page Setup" and the File Properties (aka metadata).
OK with me, if anyone makes a patch I won't object.
read the HIG, text should generally be left aligned (sometimes top left) it isn't in this dialog.
I like the current alignment better. Any other opinions?
Group Ctrl+G, Ungroup Ctrl+U. Isn't Ctrl+U being used elsewhere for Unicode input?
Yes, so what? Lots of keys have different meanings in text tool when editing text. That's normal.
using Ctrl+Shift+G would be more consistent with the HIG anyway.
Why can't you simply try it? or look up in the reference? We DO have Ctrl+Shift+G for ungrouping and always did.
think as a new user: "How is a Path not an Object?"
Makes sense, please propose a specific reorganization.
Fill and Stroke, Swatches, Object Properties are all palettes/docks and should probably be under view rather than Object.
No. We had them all under "Dialogs" before and everyone loathed this. It does not matter what they "are"; what matters is what they DO and what they apply to. From that viewpoint, they would make much more sense in a Selection menu if we had it, not in Object.
The Layer menu includes a lot of "Layer, something Layer" which is redundant.
Agree, redundancy may be reduced here
having a top level select menu might help sort out some of the imbalance in the Edit menu but it may only serve to move the problems around. The tool "Edit, Find" in many ways similar to Select by ...
Comments make sense, please propose a specific reorganization.
"Help, Keys and Mouse" doesn't make sense, needs a better label.
It explains what it is. What do you propose?
about everything. It can be quite tiring and a little depressing especially when I start feeling I'm being ignored.
Please don't feel that way. At least I always pay attention to what you say and try to give specific responses, even if I disagree with you. As you can see from above list, I agree with some of your proposals though not all.
And almost none of your complaints are new for 0.42, which surprises me because you started by claiming that we have deteriorated in usability in this release.
I hope others can learn to cast a critical eye on Inkscape because if it sucks to be the only one playing devils advocate
Well, you're far from the only one. We had a lot of discussion with Kevn Wixson for example, and this resulted in a lot of improvement in the Node tool, and as far as I remember most if not all of his criticisms were resolved satisfactorily. So if nobody supports some of your criticisms, well... maybe it's because people like Inkscape the way it is? :)
If you want me to keep doing this you really have to keep asking. Inviting the Gnome usability team and the Open Usability group to take a go at reviewing Inkscape might be a good way to hear a different point of view from mine for a change.
Sure, what do we do to make this happen?
Oh and if you could get Inkscape into Garnome[1] I'd be a lot more likely to build it occasionally and perhaps others would too.
Anyone knows what needs to be done for this?
On Thu, 28 Jul 2005, bulia byak wrote:
Date: Thu, 28 Jul 2005 17:21:42 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: Inkscape Harsh Criticisms
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
Hey, rearranging top menu items is as easy as rearranging single lines in interface.cpp. Where are your patches?
Fair point but that only goes so far, I really dont have the time to work on every project I see a problem with even if I would like to help.
This wasn't directed to you personally. Other people have expressed their issues with the menus, and I myself agree that the Edit menu has become unwieldy. Let's fix it!
Releases happen, users criticise. Without a prominent list of Known bugs or Top 10 things we wish were fixed already criticism should be expected and the response be were working on it, which is essentially what has happened after my rant.
In the below responses to your comments, note that I'm not speaking on behalf of all Inkscape developers. I only express my opinion.
My previous comments about getting rid of parenthesis from menu item(s) was ignored.
I see no problem in that whatsoever. It's not new in 0.42 anyway.
I didn't have much time over the past few months and 0.41 and 0.42 merged together for me. I guess because removing the parenthesis was such a simple incidental thing to correct I had hoped someone would do it as part of another change.
I wish I could make all developers understand the learning curve required to get a full build enviroment up and running and then to provide patches (and monkeying around with a relatively locked down network makes it even less pleasant and time consuming for me to get much of anything done). I'm usually okay about filing bug reports but the effort required for a casual user to go out of ones way and provide feedback to a program is actually quite a lot and past experience has trained most user not to even try. I guess I have been spoiled by other programs which have bug-buddy or other automated response systems and gotten even lazier. I guess it is all too easy for me to forget you all have your own work to do but the so much work gets done on Inkscape it is hard to believe you are all only working on it part time :)
Vacuum Defs is still weird. I don't have all the answers but a way to "define styles" and treat defs similarly to predefined styles.
This was already discussed. You didn't convince me and, as far as I remember, others. It's not new in 0.42.
I dont have a better a solution unfortunately, it is still weird and confusing. Expect others to keeping point it out until someone can come up with a better way.
need a submenu "View, Zoom" (short version, long versions will require a little more thought and reorganisation)
May be a good idea, but personally I'm ambivalent. You gain a shorter menu but you lose an extra click. Don't know which wins.
We have several ways of accessing Zoom and something has got to give. I think it is time to try and put some clean structure back into the menus so there is room to grow. Zoom is by far the easiest and most obvious contender. Inkscape also has a hell of a lot of Zoom options more than most programs but yet doesn't have menu items for the standard "Zoom In" "Zoom Out" (more generic and flexible. A sumbmenu creates the room needed to provide a variety of preset Zoom perecentages like other programs do, an alternative approach is to only have a few menu items for Zoom and put the rest under a "Zoom..." dialog.
I was sceptical of Zoom Next, Zoom Previous but it is a feature OpenOffice.org has and it works reasonably well, however the zoom level should (like the rulers, grid, and other parts of the view) should be seperate from the main undo stack.
The most valuable mnemonic is the one you last used, so what I'd like to see would be something like
_View _Zoom _Zoom In Zoom Out --- other zooms ... --- 25 % 50 % 100 % 200 %
etc
keybindings are not configurable, forces developers to try and hardcode defaults for everything cannot please everyone.
In what way is this a regression in 0.42? Everyone agrees this should be done. It's just not done yet.
The reason I mention it is because there is such a variety of reasonable expectations for what keys should Zoom. Gnome users expect both Ctrl++ and Ctrl+= to Zoom In, Ctrl+- to Zoom Out and Ctrl+0 to Zoom 100. Other users will want single letter keybindings.
These are all quite reasonable but the inability to configure them causes a knock on effect of other problems. It is a rare case to be able to identify the root of the problem so I thought it was worth mentioning. Not specific to 0.42 I know but it is all about the expectations.
This mail is long enough already, which is why I changed the subject line and created a seperate thread for this.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
most programs but yet doesn't have menu items for the standard "Zoom In" "Zoom Out" (more generic and flexible.
I remember a person on Jabber who complained about the lack of these in the menu because he was used to using them from the menu in other programs. This surprised me to no end. So once we have the submenu we can add these commands to make him happy :)
I was sceptical of Zoom Next, Zoom Previous but it is a feature OpenOffice.org has and it works reasonably well, however the zoom level should (like the rulers, grid, and other parts of the view) should be seperate from the main undo stack.
Yes, of course it has nothing to do with undo stack.
On Fri, 29 Jul 2005, bulia byak wrote:
Date: Fri, 29 Jul 2005 13:21:31 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Zoom Zoom Zoom [was Re: Inkscape Harsh Criticisms]
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
most programs but yet doesn't have menu items for the standard "Zoom In" "Zoom Out" (more generic and flexible.
I remember a person on Jabber who complained about the lack of these in the menu because he was used to using them from the menu in other programs. This surprised me to no end. So once we have the submenu we can add these commands to make him happy :)
it is hard to get used to doing things differently
I was sceptical of Zoom Next, Zoom Previous but it is a feature OpenOffice.org has and it works reasonably well, however the zoom level should (like the rulers, grid, and other parts of the view) should be seperate from the main undo stack.
Yes, of course it has nothing to do with undo stack.
I tested and someone managed to convince myself it was getting included in the undo stack on closer inspection it wasn't.
"All work and no play" ... make crazy :(
- Alan
Sorry if it sounded like that. I just said the same as Bryce - everyone works on what interests him/her.
In the below responses to your comments, note that I'm not speaking on behalf of all Inkscape developers. I only express my opinion.
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience. of course I'd love to have both but it doesn't make for a great default approach.
I'll have to write seperate mail suggesting keybindings we should other keybindings we should rationalise to reduce the learning curve for former Illustrator/Freehand users, they have quite a few keybindings in common we could probably also use.
Already discussed, I'm not convinced, not a regression in 0.42.
Not a regression I admit...
using the commands bar/options bar for both the tool defaults and changing the properties of the current object is weird (therefore harder to learn) and I still dont particularly like it.
Already discussed, I'm VERY MUCH not convinced (I think it's one of the best things in our UI), not a regression in 0.42.
... but a certain category of user which I fall into is never going to be satisfied with behaviour substantially different from what they are familiar with. I just feel these are things that Inkscape would be slated for if reviewed by a mainstream Graphics magazine. Myself I'll probably get used to it eventually.
maybe it will grow on me, maybe I will be proven wrong but it is radically different and I'd be very surprised if it works.
(Having said that the selection behaviours Freehand uses are pretty weird but it makes the Selection tools very powerful allowing you to break apart shapes and in effect use the boolean operations implicitly. If that doesn't make much sense nevermind, or try out Freehand or Flash and you might get a sense of what I mean.)
the tools: node tool doesn't include any labels in the Commands bar would help if some of the items were labelled. same goes for the Zoom tool, too many similar icons are hard to disambiguate and text would help.
May be a good idea. Can you make a specific proposal?
Think Priority text, like on a standard toolbar.
I suppose at least Add Remove(Delete/Merge/???) should be labelled.
A single label to help group the three corner/node types might be enough rather than needing to label everything, at least for now.
rectangle tool "Not rounded" inconsistent should be Reset, other tools labelled default should be renamed to Reset (use a verb not a noun).
Disagree, I think this was already discussed. The labels say what this button does SPECIFICALLY. "Reset" tells me nothing and will likely scare me away.
The layout of the commands bar could benefit from some tweaking, I'm not sure what exactly would be best. (It would really help if I had access to Illustrator and Inkscape side by side but I dont believe I do, might be able to work something out with the multimedia students though.) I took a bunch of screenshots of the Photoshop toolbars which I should dig up for reference and make sure are mentioned in the Wiki.
(If the first space on the Commands bar showed the currently active/selected Tool like how Adobe Photoshop does this would make it easier to keep track of what was going on and for anyone who wanted to turn off the toolbox to make more space but it seem unlikely that users would actually want to do that in practice except on extremely cramped displays.)
I guess I'd prefer something like this (would all be on the Command bar as one line:
Recangle X [ ] Y [ ] Height [ ] Width [ ]
[/] Rounded Corners X Radius [ ] Y Radius [ ]
This information is currently included in the main selection tool but something about not having with the Rectangle tool where you need it doesn't seem quite right. (So I'm suggesting adding it to the rectangle tool, not necessarily suggesting touching the Select too just yet)
(Must look at the Commands bar for zoom too).
freehand/draw bezier/text tools have nothing on the command bar. colour picker has only one item.
Sure, we're working on it. Lots of ideas on what to put there. Just wasn't ready in time for 0.42.
It is just a bit of an eyesore. If I ever see dead space I ask myself if there is a problem and I'd be surprised if someone reviewing inkscape missed that these tools were incomplete.
Again it is the whole management of expectations, and it is important to try and head off criticism by warning users things are incomplete and planned to be worked on.
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
Not my area - Peter, can you comment?
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface. It will probably need to be mentioned in the documentation anyway but the license is important to Free Software Evangelists not to users who want to draw stuff. Distributors should read the Licensing information, users shouldn't need to worry about it and windows users have already been required to agree to the License in the installer. (And users do not need to agree to the GPL just to use the software, only if they wish to redistribute modified versions.)
This particularly hit a nerve because the GIMP harasses users with inane questions the first time you run it, including displaying the License. There are better places for evanglism than this.
And to have a menu label steal the promiment position at the end of the list and then to have a five word label is not at all aesthetically pleasing to put it politely. (Sorry the more I do this the more hypersensative I get to these anomolies.)
"Help, About memory" is not a useful user (artist not developer user) feature should at the very least be hidden from release builds (this is what I was referring to earlier).
Maybe we'll hide it for 1.0 when we patch all leaks. For now it's useful to those who can use it, and pretty nonobtrusive for others.
grumble, mumble, mumble. fair enough I suppose but I prefer how Mozilla hides away this kind of thing in a Debug menu and if the effects menu can be hidden I'd prefer to have a hidden Debug menu for this sort of thing.
Help About Inkscape. I'd prefer if this were simply Help, About like most Gnome programs.
OK with me
Stock items make less translation work. I strongly recommend implementing the standard GtkAbout dialog. The standard dialog provides version and contact information that can be easily cut and paste out of the dialog. The inkscape about dialog does not. use the standard dialog, make work then make it pretty later.
Some people were planning to do just that for 0.43.
Rulers are ugly. Turn them off by default.
Can you share your definition of "ugly" please?
Not pretty. If Inkscape were all about Techincal graphics maybe but rulers add visual noise and complexity for new users, and other software I have encountered turn them off by default leaving a clearer cleaner more pleasant default look. Off course uses can turn them on as needed, just as they turn the grid on as needed. Frankly I just think it looks better, keeps things simpler and is worth the small discoverability penalty.
To me they're perfectly OK, not worse nor better than in any other vector app.
Some apps colour them the match the page, others to match the widgets. I'm not sure myself which is best.
Thankfully the rulers on the same level as the page and thankfully Inkscape has avoided the bevelling other software has on their rulers which may look pretty but makes it slightly more awkward to line things up with the rulers as quickly and as precisely.
The word metadata is jargon and we should not need to use it in the user interface.
Nope, it's a well-defined term.
I disagree but I'll leave this one for another day. Look at how other programs do this.
I've complained before about the Document preferences dialog, I think we need to do a split between the "Page Setup" and the File Properties (aka metadata).
OK with me, if anyone makes a patch I won't object.
read the HIG, text should generally be left aligned (sometimes top left) it isn't in this dialog.
I like the current alignment better. Any other opinions?
I've rearrange a few dialogs to use left aligned text and it is substantially more readable. English and other European languages left align text, the only time we do otherwise is for decorative effect not readability. There are a few cases where it may look odd at first but sometimes it requires a few other minor layout adjustment to get things to look right.
The Metadata tab of the Document preference dialog, is disproportionately tall compared to the other Tabs, splitting in two tabs might help (but as part of any Page Setup, Document Properties split that would probably happen anyway).
Group Ctrl+G, Ungroup Ctrl+U. Isn't Ctrl+U being used elsewhere for Unicode input?
Yes, so what?
Okay crap reason, you called my bluff.
using Ctrl+Shift+G would be more consistent with the HIG anyway.
Why can't you simply try it?
Not the point.
or look up in the reference? We DO have Ctrl+Shift+G for ungrouping and always did.
my bad.
Both Freehand and Illustrator use Ctrl+Shift+G would be better if it were the one shown by defualt, we may want to use Ctrl+U for something else later. (I dug up a bunch of keybinding reference cards on Adobe/Macromedia more on that later.)
think as a new user: "How is a Path not an Object?"
Makes sense, please propose a specific reorganization.
Brain melting, implosion immanent. Please see Adobe Illustrator, Macromedia Freehand, and pray to $DEITY for inspiration. Help wanted.
Fill and Stroke, Swatches, Object Properties are all palettes/docks and should probably be under view rather than Object.
No. We had them all under "Dialogs" before and everyone loathed this. It does not matter what they "are"; what matters is what they DO and what they apply to. From that viewpoint, they would make much more sense in a Selection menu if we had it, not in Object.
I'll avoid this for another while.
The Layer menu includes a lot of "Layer, something Layer" which is redundant.
Agree, redundancy may be reduced here
Minor details, part of the endless tweaking...
having a top level select menu might help sort out some of the imbalance in the Edit menu but it may only serve to move the problems around. The tool "Edit, Find" in many ways similar to Select by ...
Comments make sense, please propose a specific reorganization.
I'm basically wondering if the time has come for a full menu for Select like Adobe Illustrator which would incidentally help slim down the Edit menu but Macromedia Freehand makes me wonder if there might be a better way.
"Help, Keys and Mouse" doesn't make sense, needs a better label.
It explains what it is. What do you propose?
I was particularly on a roll with that one, talk about minor details. The menu lable tells you it is going to be something about keys and mouse, but what? I guess on balance I'd be happier with "Help, Keyboard Shortcuts"
Please don't feel that way. At least I always pay attention to what you say and try to give specific responses, even if I disagree with you. As you can see from above list, I agree with some of your proposals though not all.
Disagreeing with you so often is a lot of hard work but I suppose it keeps me honest.
And almost none of your complaints are new for 0.42, which surprises me because you started by claiming that we have deteriorated in usability in this release.
I got side tracked by other minor criticisms, there is so much more in Inkscape 0.42 (and 0.41) it unavoidably make it a little harder to learn and use. I was overreacting a bit.
I hope others can learn to cast a critical eye on Inkscape because if it sucks to be the only one playing devils advocate
Well, you're far from the only one. We had a lot of discussion with Kevin Wixson for example, and this resulted in a lot of improvement in
I look forward to hearing more from Kevin and Jimmac if they can spare the time. Jimmac particularly as a working graphic designer familiar with Illustrator has very valuable insights.
the Node tool, and as far as I remember most if not all of his criticisms were resolved satisfactorily. So if nobody supports some of your criticisms, well... maybe it's because people like Inkscape the way it is? :)
:P
Have split various other points out into other mails in an attempt to keep this from being even longer. As you may have noticed I sometimes have difficulty concentrating on any one thing for very long and get easily distracted.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
This particularly hit a nerve because the GIMP harasses users with inane questions the first time you run it, including displaying the License. There are better places for evanglism than this.
Those "insane" questions include display resolution, right? :)
Rulers are ugly. Turn them off by default.
Can you share your definition of "ugly" please?
Not pretty. If Inkscape were all about Techincal graphics maybe but rulers add visual noise and complexity for new users, and other software I have encountered turn them off by default leaving a clearer cleaner more pleasant default look. Off course uses can turn them on as needed, just as they turn the grid on as needed. Frankly I just think it looks better, keeps things simpler and is worth the small discoverability penalty.
Well, again -- how else do you add guidelines to a sketch without dragging them from a ruler? The very first thing I do when I use someone's copy of Photoshop/Illy is Ctrl+R to enable rulers. No rulers - no guidelines. No guidelines - no work. This is simple :)
I've rearrange a few dialogs to use left aligned text and it is substantially more readable. English and other European languages left align text, the only time we do otherwise is for decorative effect not readability. There are a few cases where it may look odd at first but sometimes it requires a few other minor layout adjustment to get things to look right.
A mockup to look at has an URL, right? :)
Alexandre
On Fri, 29 Jul 2005, Alexandre Prokoudine wrote:
Date: Fri, 29 Jul 2005 16:48:12 +0400 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: Inkscape Harsh Criticisms
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
This particularly hit a nerve because the GIMP harasses users with inane questions the first time you run it, including displaying the License. There are better places for evanglism than this.
Those "insane" questions include display resolution, right? :)
The insanity is asking fist time users questions at a time when they are worst equipped to answer them. If any of these things need to be configurable they need to be configurable from the preferences. I can understand historically how the GIMP needed to do all this for itself but installers at startup is an idea that should have died off with Gnome 1.4. Ubuntu fixed (as in neutered) the first time installer so I try not to complain about it anymore.
Rulers are ugly. Turn them off by default.
Can you share your definition of "ugly" please?
Not pretty. If Inkscape were all about Techincal graphics maybe but rulers add visual noise and complexity for new users, and other software I have encountered turn them off by default leaving a clearer cleaner more pleasant default look. Off course uses can turn them on as needed, just as they turn the grid on as needed. Frankly I just think it looks better, keeps things simpler and is worth the small discoverability penalty.
Well, again -- how else do you add guidelines to a sketch without dragging them from a ruler? The very first thing I do when I use someone's copy of Photoshop/Illy is Ctrl+R to enable rulers. No rulers
- no guidelines. No guidelines - no work. This is simple :)
I'm sure we will get lots of opinions on which people prefer and whatever is decided will be pretty subjective either way. I do wish I had more to backup my reasoning on this but I really don't think most users need Rulers and Guides enough when they are first getting started to have them on by default. I suppose I should submit a patch and see how much people like you complain about having to turn it on, everyone else will probably barely notice.
I've rearrange a few dialogs to use left aligned text and it is substantially more readable. English and other European languages left align text, the only time we do otherwise is for decorative effect not readability. There are a few cases where it may look odd at first but sometimes it requires a few other minor layout adjustment to get things to look right.
A mockup to look at has an URL, right? :)
If you want an example I could point you to Gimp 2.2 versus Gimp 2.0 where various dialogs have been changed, particularly Script Fu. Could probably come up with more example if I had time, it really does work though.
- Alan
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
the tools: node tool doesn't include any labels in the Commands bar would
I suppose at least Add Remove(Delete/Merge/???) should be labelled.
Yes. A couple labels before buttons groups would be good.
(If the first space on the Commands bar showed the currently active/selected Tool like how Adobe Photoshop does this would make it easier to keep track of what was going on
May be a good idea. But we need to find a way to show the tool icon there in a way that makes it clear it's not a button, but rather a label.
I guess I'd prefer something like this (would all be on the Command bar as one line:
Recangle X [ ] Y [ ] Height [ ] Width [ ]
[/] Rounded Corners X Radius [ ] Y Radius [ ]
Yes, Rect toolbar certainly needs W/H controls, it's on my todo for ages. (Volunteers?) But no X/Y, that would be redundant with selector (whereas W/H in rect may act differently from selector if the rect is rotated/skewed).
Rulers are ugly. Turn them off by default.
Can you share your definition of "ugly" please?
Not pretty.
Well, that's subjective. I find them rather pretty. Not to mention useful. I see absolutely no reason to remove them.
The Metadata tab of the Document preference dialog, is disproportionately tall compared to the other Tabs,
Yes, which might be a reason to break it into a dialog of its own.
Both Freehand and Illustrator use Ctrl+Shift+G would be better if it were the one shown by defualt
OK with me, any other opinions on making Ctrl+Shift+G the shown default for ungroup?
I was particularly on a roll with that one, talk about minor details. The menu lable tells you it is going to be something about keys and mouse, but what?
Obviously it's going to be keys and mouse HELP, it being in the Help menu.
I guess on balance I'd be happier with "Help, Keyboard Shortcuts"
This document also describes mouse shortcuts.
Hmmm, the silent majority of us are too busy using and enjoying Inkscape to have so many complaints....
Re UI - keep on posting the screenshots on the mail-list, some of us view those and if we really object, we'll let you know, otherwise it's not that important to us. Things that I find take the most time: pdf import, pdf export, easier straight line drawing (I think someone has been/is addressing these), dxf import (coming in SOC) and maybe a drag/drop storage panel for often used custom shapes.
Congrats on a great program and role-model OSS project (hmmm, maybe that's why some people are so critical). Now I'm off to attempt installing .42 on my mixed gcc Debian unstable.
btw - little by little, I'm working on an article for how SVG is the way to go for civil engineers to incorporate GIS and Autocad in report graphics with Inkscape. How stable is Firefox 1.1 alpha to start using for svg support? John
bulia byak wrote:
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
the tools: node tool doesn't include any labels in the Commands bar would
I suppose at least Add Remove(Delete/Merge/???) should be labelled.
Yes. A couple labels before buttons groups would be good.
(If the first space on the Commands bar showed the currently active/selected Tool like how Adobe Photoshop does this would make it easier to keep track of what was going on
May be a good idea. But we need to find a way to show the tool icon there in a way that makes it clear it's not a button, but rather a label.
I guess I'd prefer something like this (would all be on the Command bar as one line:
Recangle X [ ] Y [ ] Height [ ] Width [ ]
[/] Rounded Corners X Radius [ ] Y Radius [ ]
Yes, Rect toolbar certainly needs W/H controls, it's on my todo for ages. (Volunteers?) But no X/Y, that would be redundant with selector (whereas W/H in rect may act differently from selector if the rect is rotated/skewed).
Rulers are ugly. Turn them off by default.
Can you share your definition of "ugly" please?
Not pretty.
Well, that's subjective. I find them rather pretty. Not to mention useful. I see absolutely no reason to remove them.
The Metadata tab of the Document preference dialog, is disproportionately tall compared to the other Tabs,
Yes, which might be a reason to break it into a dialog of its own.
Both Freehand and Illustrator use Ctrl+Shift+G would be better if it were the one shown by defualt
OK with me, any other opinions on making Ctrl+Shift+G the shown default for ungroup?
I was particularly on a roll with that one, talk about minor details. The menu lable tells you it is going to be something about keys and mouse, but what?
Obviously it's going to be keys and mouse HELP, it being in the Help menu.
I guess on balance I'd be happier with "Help, Keyboard Shortcuts"
This document also describes mouse shortcuts.
On 7/29/05, John Taber <jtaber@...480...> wrote:
easier straight line drawing
What's wrong with that? Bezier tool and click, click, click. Optionally with Ctrl.
Changed title - to get away from "harsh criticism"
When I click, I often get the bezier curve instead of a straight line - or I get the rubber banding polyline - it usually takes me a couple of tries to get it right. It's kind of frustrating. Easiest would be two different tool buttons, but.. I've brought this up before and I think something in the click procedure was changed (I haven't tried 0.42 yet - hopefully in next few hours - will let you know if it seems to work better).
bulia byak wrote:
On 7/29/05, John Taber <jtaber@...480...> wrote:
easier straight line drawing
What's wrong with that? Bezier tool and click, click, click. Optionally with Ctrl.
On 7/29/05, John Taber <jtaber@...480...> wrote:
When I click, I often get the bezier curve instead of a straight line -
Increase the Click/drag threshold in Inkscape Prefs (Mouse tab).
On 7/29/05, John Taber <jtaber@...480...> wrote:
Changed title - to get away from "harsh criticism"
When I click, I often get the bezier curve instead of a straight line - or I get the rubber banding polyline - it usually takes me a couple of tries to get it right.
May I ask you why? :)
1. Ctrl+F6to switch to bezier/straihg line pencil 2. Click to start a new line 3. Move cursor to the point where you wnat the line to end. 4. Doubleclick.
That's it
Alexandre
Changed title - to get away from "harsh criticism"
When I click, I often get the bezier curve instead of a straight line
-
or I get the rubber banding polyline - it usually takes me a couple of tries to get it right. It's kind of frustrating. Easiest would be
two
different tool buttons, but.. I've brought this up before and I think something in the click procedure was changed (I haven't tried 0.42 yet
-
hopefully in next few hours - will let you know if it seems to work better).
It is a separate tool. Don't use the "Draw Freehand Lines" tool. Use the "Draw Bezier Curve" tool... and don't drag with the mouse... click where you want it to start, and then click again where you want that straight line to end. (which is basically what Bulia said)
bulia byak wrote:
On 7/29/05, John Taber <jtaber@...480...> wrote:
easier straight line drawing
What's wrong with that? Bezier tool and click, click, click. Optionally with Ctrl.
Right there... ;)
-Josh
Joshua A. Andler wrote:
tool... and don't drag with the mouse... click where you want it to start, and then click again where you want that straight line to end. (which is basically what Bulia said)
Thanks for all the feedback. Well, I guess the dragging is what is causing problems - but isn't it more normal/intuitive to "click, drag, release" to draw a straight line?
I'll also adjust preferences, though wonder if that shouldn't be the default? Anyway, I'll get .42 installed and make any comments from that.
On 7/29/05, John Taber <jtaber@...480...> wrote:
Thanks for all the feedback. Well, I guess the dragging is what is causing problems - but isn't it more normal/intuitive to "click, drag, release" to draw a straight line?
No, that is the default to draw a bezier _handle_.
I'll also adjust preferences, though wonder if that shouldn't be the default?
The default of 4 works for most people. You'll need to increase it only if you often want to make a click but get a small drag instead (which is how I interpreted your description).
On Fri, 29 Jul 2005, bulia byak wrote:
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
the tools: node tool doesn't include any labels in the Commands bar would
I suppose at least Add Remove(Delete/Merge/???) should be labelled.
Yes. A couple labels before buttons groups would be good.
Terse labels of course, preferably one word. We have Tooltips, status bar and documentation for varing degress of further detail.
(The commands bar is different from a normal toolbar and a lot more like the Options bar in Adobe Photoshop which is about the best reference I can give to help describe what I'm getting at.)
(If the first space on the Commands bar showed the currently active/selected Tool like how Adobe Photoshop does this would make it easier to keep track of what was going on
May be a good idea. But we need to find a way to show the tool icon there in a way that makes it clear it's not a button, but rather a label.
It was a pretty random idea, I'll bring it up again some other time.
I guess I'd prefer something like this (would all be on the Command bar as one line:
Recangle X [ ] Y [ ] Height [ ] Width [ ]
[/] Rounded Corners X Radius [ ] Y Radius [ ]
Yes, Rect toolbar certainly needs W/H controls, it's on my todo for ages. (Volunteers?) But no X/Y, that would be redundant with selector (whereas W/H in rect may act differently from selector if the rect is rotated/skewed).
I took a look at Jasc Webdraw and although not directly comparable it has a tickbox in front of the X Radius which allows you to turn off the property (they were working with the file format in mind it seems).
Looks roughly like this (for Inkscape they would be on the one line):
[/] X Radius [ 20] [/] Y Radius [ 20]
Rulers are ugly. Turn them off by default.
Can you share your definition of "ugly" please?
Not pretty.
Well, that's subjective.
You betcha ;)
On Fri, 29 Jul 2005, David Christian Berg wrote: ...
annoying because they waste so much screen estate
So you are in favour of hiding the Rulers by default?! (Taking quotes out of context is fun!)
I find them rather pretty. Not to mention useful. I see absolutely no reason to remove them.
The grid is useful too but it is not shown by default.
I think it is going to be very hard to convince you on this, I dont have much more to go on than the example of Adobe, the cleaner aesthetic, and my other little reasons. Until Inkscape is ported to a small cramped handheld device I suppose I try not to bring this up again.
The Metadata tab of the Document preference dialog, is disproportionately tall compared to the other Tabs,
Yes, which might be a reason to break it into a dialog of its own.
I believe Gnumeric has or is in the process of moving their properties/metadata out into a standard goffice library. (Probably wont suit Inkscape I expect but I figured I'd mention just in case.)
Both Freehand and Illustrator use Ctrl+Shift+G would be better if it were the one shown by defualt
OK with me, any other opinions on making Ctrl+Shift+G the shown default for ungroup?
filed a request for Ctrl+Shift+G http://sourceforge.net/tracker/index.php?func=detail&aid=1247709&gro...
I was particularly on a roll with that one, talk about minor details. The menu lable tells you it is going to be something about keys and mouse, but what?
Obviously it's going to be keys and mouse HELP, it being in the Help menu.
I guess on balance I'd be happier with "Help, Keyboard Shortcuts"
This document also describes mouse shortcuts.
What is bothering my is probably that from the user point of view what is important is to get Helpful Shortcuts, the input device is almost incidental but the current labelling puts emphasise on the implemenation rather than the action. I am I explaining this any better?
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
Hi,
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience. of course I'd love to have both but it doesn't make for a great default approach.
I'll have to write seperate mail suggesting keybindings we should other keybindings we should rationalise to reduce the learning curve for former Illustrator/Freehand users, they have quite a few keybindings in common we could probably also use.
...
using the commands bar/options bar for both the tool defaults and
changing
the properties of the current object is weird (therefore harder to learn) and I still dont particularly like it.
Already discussed, I'm VERY MUCH not convinced (I think it's one of the best things in our UI), not a regression in 0.42.
... but a certain category of user which I fall into is never going to be satisfied with behaviour substantially different from what they are familiar with. I just feel these are things that Inkscape would be slated for if reviewed by a mainstream Graphics magazine. Myself I'll probably get used to it eventually.
Just my 2 cents there : If, after Gtkmm work, keybindings and shortcuts become customizable, why not to provide different 'layouts' of shortcuts. Default one would match current implementation, and some others (to be choosed in Prefs) would reflect Illustrator/XaraX/...
Regards,
Matiphas
Just my 2 cents there : If, after Gtkmm work, keybindings and shortcuts become customizable,
why
not to provide different 'layouts' of shortcuts. Default one would match current implementation, and some others (to be choosed in Prefs) would reflect Illustrator/XaraX/...
Now, THAT is the best idea I've seen so far in this discussion.
-Josh
Just my 2 cents there : If, after Gtkmm work, keybindings and shortcuts become customizable,
why
not to provide different 'layouts' of shortcuts. Default one would match current implementation, and some others (to
be
choosed in Prefs) would reflect Illustrator/XaraX/...
Now, THAT is the best idea I've seen so far in this discussion.
Now that I think of it... isn't it theoretically possible for us to be even smarter with the gtkmm and make it support customizable menus too? Kinda in the vein of "GimpShop" if we could take the above mentality and further extend it throughout Inkscape, we could one up everyone else that I know of. Honestly though, I love the inkscape way of doing things, so it's definitely not a priority in my book... just a thought. And the other thought is the people that want it to match their program of choice can do the work to come up with those mouse/key/menu sets. ;)
-Josh
On Fri, 29 Jul 2005, Joshua A. Andler wrote:
Date: Fri, 29 Jul 2005 11:14:11 -0700 From: Joshua A. Andler <joshua@...533...> To: matiphas@...8..., 'Alan Horkan' <horkana@...44...>, 'bulia byak' <buliabyak@...400...> Cc: 'Inkscape is a vector graphics editor' inkscape-devel@lists.sourceforge.net Subject: RE: [Inkscape-devel] Re: Inkscape Harsh Criticisms
Just my 2 cents there : If, after Gtkmm work, keybindings and shortcuts become customizable,
why
not to provide different 'layouts' of shortcuts. Default one would match current implementation, and some others (to
be
choosed in Prefs) would reflect Illustrator/XaraX/...
Now, THAT is the best idea I've seen so far in this discussion.
Now that I think of it... isn't it theoretically possible for us to be even smarter with the gtkmm and make it support customizable menus too?
It is possible so it will probably happen but to do it is a clean and easily maintainable way could be a huge hassle. I would hope we would have good enough defaults, enough flexibility in the user interface and a good variety of extensions that people would not be rushing to do this. Ways to make transition easier are all well and good and while I'm all for making this very similar there will invetibly be places where we really want people to get used to a new way becuase we are sure it is better not just different.
Kinda in the vein of "GimpShop" if we could take the above mentality and
The pain of maintaining different user interfaces for the same program is quite big (translation, documentation, and various other issues).
that I know of. Honestly though, I love the inkscape way of doing things, so it's definitely not a priority in my book... just a thought. And the other thought is the people that want it to match their program of choice can do the work to come up with those mouse/key/menu sets. ;)
In the long run I do expect it to happen but ideally it would be for testing out new ideas and then going making changes if we come up with something that is genuinely better. Might even be a good way to tempt former Macromedia users away from whatever Adobe does with the Macromedia product lines.
- Alan
On 7/29/05, Joshua A. Andler <joshua@...533...> wrote:
Now, THAT is the best idea I've seen so far in this discussion.
And this idea is more than a year old:
http://www.inkscape.org/cgi-bin/wiki.pl?KeyboardProfiles
On Jul 29, 2005, at 11:18 AM, bulia byak wrote:
On 7/29/05, Joshua A. Andler <joshua@...533...> wrote:
Now, THAT is the best idea I've seen so far in this discussion.
And this idea is more than a year old:
There's a lot that happens to fall into place together.
A lot of the same internal cleanup needed for keyboard 'profiles' or 'personalities' happens to also be stuff in line with exposing things cleanly in an abstract manner to plugins. And more internal cleanup to get to a stronger M-VC separation can benefit both of those...
We get closer and closer all the time. Just fill out info like that wiki page and we'll try to pick up features as we can.
Please try to trim long messages
Just my 2 cents there : If, after Gtkmm work, keybindings and shortcuts become customizable, why not to provide different 'layouts' of shortcuts. Default one would match current implementation, and some others (to be choosed in Prefs) would reflect Illustrator/XaraX/...
That has always been the long term plan. The downsides of using non standard widgets.
Doesn't solve the question of what should be the "default Inkscape shortcuts" question though, but if things were configurable it would become less of a problem.
- Alan
On Jul 29, 2005, at 1:47 PM, Alan Horkan wrote:
That has always been the long term plan. The downsides of using non standard widgets.
Yup.
And that's one thing I've started on cleaning up. In the short term there are various levels of annoyance caused by cleaning up (like many I've bugged Bulia by doing, and some still not quite corrected), but long term things will get happy.
One big thing is getting proper information and feedback so we know how much to customize and where.
On Fri, Jul 29, 2005 at 06:53:53PM +0200, matiphas@...8... wrote:
Hi,
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience. of course I'd love to have both but it doesn't make for a great default approach.
I'll have to write seperate mail suggesting keybindings we should other keybindings we should rationalise to reduce the learning curve for former Illustrator/Freehand users, they have quite a few keybindings in common we could probably also use.
...
using the commands bar/options bar for both the tool defaults and
changing
the properties of the current object is weird (therefore harder to learn) and I still dont particularly like it.
Already discussed, I'm VERY MUCH not convinced (I think it's one of the best things in our UI), not a regression in 0.42.
... but a certain category of user which I fall into is never going to be satisfied with behaviour substantially different from what they are familiar with. I just feel these are things that Inkscape would be slated for if reviewed by a mainstream Graphics magazine. Myself I'll probably get used to it eventually.
Just my 2 cents there : If, after Gtkmm work, keybindings and shortcuts become customizable, why not to provide different 'layouts' of shortcuts. Default one would match current implementation, and some others (to be choosed in Prefs) would reflect Illustrator/XaraX/...
Yes, these will be customizable after the Gtkmm work, but there's a number of prerequisites that must be coded before we can implement that feature.
Actually, all the Gtkmm menu/keyboard code has been written (although it's out of date with current menus) and can be invoked by inkscape --new-gui. Unfortunately, that's just skin; the guts still aren't there.
Still, if anyone is interested in working on implementing code for editing keybindings and menu layouts, I'd be happy to point out what's been done so far.
Bryce
On Fri, 2005-07-29 at 13:37 +0100, Alan Horkan wrote:
... but a certain category of user which I fall into is never going to be satisfied with behaviour substantially different from what they are familiar with.
Unfortunately, such users are not all accustomed to the same thing. Some might be familiar with Freehand, some with Xara, some with Illustrator. We simply can't make everyone happy.
(customizable keybindings/etc might help, especially if we had predefined "Freehand", "Illustrator", "Xara" -- but of course there is MUCH more to an interface than simply keyboard shortcuts)
(If the first space on the Commands bar showed the currently active/selected Tool like how Adobe Photoshop does this would make it easier to keep track of what was going on and for anyone who wanted to turn off the toolbox to make more space but it seem unlikely that users would actually want to do that in practice except on extremely cramped displays.)
That might be a good idea. It looks like you're suggesting a text label below, but do you think it would be a better idea to use the icon?
I guess I'd prefer something like this (would all be on the Command bar as one line:
Recangle X [ ] Y [ ] Height [ ] Width [ ]
[/] Rounded Corners X Radius [ ] Y Radius [ ]
Hmm, yes. I think I would also prefer "Rounded Corners" as a checkbox rather than a button.
Again it is the whole management of expectations, and it is important to try and head off criticism by warning users things are incomplete and planned to be worked on.
We've gotten complaints about a lot of things, but blank command toolbars has never been one of them as far as I know.
Complaints have been more along the lines of "it's not obvious how to get this" or "the dialog to do this is too bulky", both of which would be addressed by populating the corresponding toolbar.
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
Not my area - Peter, can you comment?
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface.
It was added because a strict reading of the license requires it (yes, debatable, I know).
I think ultimately license information would be better as a link/button in the about dialog rather than a separate entry on the help menu, an approach which is not unheard-of in commercial applications.
But to do that, we've got to rewrite the about dialog first.
Not pretty. If Inkscape were all about Techincal graphics maybe but rulers add visual noise and complexity for new users, and other software I have encountered turn them off by default leaving a clearer cleaner more pleasant default look.
Which applications have rulers turned off by default? Maybe I'm just accustomed to turning them on immediately and forgetting, but in my entire graphic design career I don't remember ever seeing rulers turned off when I started an application that had them.
Also, I know if we turned them off I strongly suspect we'd start getting a flood of questions about how to create guides from users who were accustomed to Illustrator, Flash, etc...
Thankfully the rulers on the same level as the page and thankfully Inkscape has avoided the bevelling other software has on their rulers which may look pretty but makes it slightly more awkward to line things up with the rulers as quickly and as precisely.
Indeed!
I've complained before about the Document preferences dialog, I think we need to do a split between the "Page Setup" and the File Properties (aka metadata).
OK with me, if anyone makes a patch I won't object.
Likewise.
read the HIG, text should generally be left aligned (sometimes top left) it isn't in this dialog.
I like the current alignment better. Any other opinions?
I've rearrange a few dialogs to use left aligned text and it is substantially more readable. English and other European languages left align text, the only time we do otherwise is for decorative effect not readability. There are a few cases where it may look odd at first but sometimes it requires a few other minor layout adjustment to get things to look right.
Personally I prefer the current right-aligned appearance, whatever the HIG says.
However, the way it's currently implemented means that you cannot click on the label to activate a checkbox. That's very bad.
Both Freehand and Illustrator use Ctrl+Shift+G would be better if it were the one shown by defualt, we may want to use Ctrl+U for something else later. (I dug up a bunch of keybinding reference cards on Adobe/Macromedia more on that later.)
I'm not overly attached to Ctrl+U as the "default" for ungrouping. I wouldn't object to making it Ctrl+Shift+G, and I can see the argument for doing so.
I'm basically wondering if the time has come for a full menu for Select like Adobe Illustrator which would incidentally help slim down the Edit menu but Macromedia Freehand makes me wonder if there might be a better way.
Freehand is the one app I suspect many of us have not had much experience with... it might be particularly helpful for you or someone more familiar with it to document its interface for our reference. (Wiki?)
It would be helpful if you could start capturing some of the less controversial items in the RFE tracker, to make sure we don't forget them again.
-mental
Not going to address all your points, covered some of them elsewhere but bring them up again if you feel I've neglected anything.
Again it is the whole management of expectations, and it is important to try and head off criticism by warning users things are incomplete and planned to be worked on.
We've gotten complaints about a lot of things, but blank command toolbars has never been one of them as far as I know.
It takes a someone like me to complain about nothing doesn't it!
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface.
It was added because a strict reading of the license requires it (yes, debatable, I know).
The General Public License was never intended to have an obnoxious advertising clause.
I think ultimately license information would be better as a link/button in the about dialog rather than a separate entry on the help menu, an approach which is not unheard-of in commercial applications.
But to do that, we've got to rewrite the about dialog first.
Using the standard Gtk about dialog should take care of most of the functional requirements of any new About dialog. Adding the artwork back in without making things too big might require a few adjustments but following the standard API will probably save hassle in the long run.
I've complained before about the Document preferences dialog, I think we need to do a split between the "Page Setup" and the File Properties (aka metadata).
OK with me, if anyone makes a patch I won't object.
Likewise.
I wish I had the time and the skill but I'll see what I can do.
I'm basically wondering if the time has come for a full menu for Select like Adobe Illustrator which would incidentally help slim down the Edit menu but Macromedia Freehand makes me wonder if there might be a better way.
Freehand is the one app I suspect many of us have not had much experience with... it might be particularly helpful for you or someone more familiar with it to document its interface for our reference. (Wiki?)
I have only used it briefly myself as the trial version has timed out but i can still read through the documentation (the inset tool is quite interesting). I've used Flash a bit more than I have used Fireworks and there are similarities in the various products. Also do not be fooled, Fireworks is worth looking at too because even though it is used to generate raster graphics in many ways it works more like a Vector graphics application, it has on canvas live gradients similar to Inkscape.
It would be helpful if you could start capturing some of the less controversial items in the RFE tracker, to make sure we don't forget them again.
Added some reports, will have to add more as I remember them.
Others such as the menu restructuring, to accomodate future expension in a managable way and my wish to make reorganise some of the keybindings require a bit more planning and detailed description on my part.
- Alan
On Fri, 2005-07-29 at 23:22 +0100, Alan Horkan wrote:
Using the standard Gtk about dialog should take care of most of the functional requirements of any new About dialog. Adding the artwork back in without making things too big might require a few adjustments but following the standard API will probably save hassle in the long run.
I wouldn't mind doing that, except do you have any suggestions for how we would embed an SPSVGViewWidget in the standard about dialog?
GtkAboutDialog's API doesn't seem to permit embedding anything except a non-rescalable bitmap image in the from of a pixbuf:
http://developer.gnome.org/doc/API/2.0/gtk/GtkAboutDialog.html#gtk-about-dia...
-mental
On 7/30/05, MenTaLguY <mental@...3...> wrote:
On Fri, 2005-07-29 at 23:22 +0100, Alan Horkan wrote:
Using the standard Gtk about dialog should take care of most of the functional requirements of any new About dialog. Adding the artwork back in without making things too big might require a few adjustments but following the standard API will probably save hassle in the long run.
I wouldn't mind doing that, except do you have any suggestions for how we would embed an SPSVGViewWidget in the standard about dialog?
GtkAboutDialog's API doesn't seem to permit embedding anything except a non-rescalable bitmap image in the from of a pixbuf:
http://developer.gnome.org/doc/API/2.0/gtk/GtkAboutDialog.html#gtk-about-dia...
You know, while I like the idea of using SVG in bowth Help documents and About dialog, I do hate when I have to wait till it's rendered and shown.
On my 1,6 Centrino + 512 Mbyte RAM laptop the current About dialog renders ~6 secs. This is insane. I would vote for a GIMP-like About box with a smaller SVG inside, if anyone cares to listen :)
Alexandre
On Sat, 30 Jul 2005, Alexandre Prokoudine wrote:
On 7/30/05, MenTaLguY <mental@...3...> wrote:
On Fri, 2005-07-29 at 23:22 +0100, Alan Horkan wrote:
You know, while I like the idea of using SVG in bowth Help documents and About dialog, I do hate when I have to wait till it's rendered and shown.
On my 1,6 Centrino + 512 Mbyte RAM laptop the current About dialog renders ~6 secs. This is insane. I would vote for a GIMP-like About box with a smaller SVG inside, if anyone cares to listen :)
There is a strong possibility the gimp will move to the standard dialog too and then see about adding back the eye candy.
The current About screen is quite slow to load which somewhat detracts from its good looks.
- Alan
You know, while I like the idea of using SVG in bowth Help documents and About dialog, I do hate when I have to wait till it's rendered and shown.
On my 1,6 Centrino + 512 Mbyte RAM laptop the current About dialog renders ~6 secs. This is insane. I would vote for a GIMP-like About box with a smaller SVG inside, if anyone cares to listen :)
There is a strong possibility the gimp will move to the standard dialog too and then see about adding back the eye candy.
The current About screen is quite slow to load which somewhat detracts from its good looks.
interesting. i always found it quite amusing to use a aboring about screen as a demo space of an application... yes it's slow, but with a reason. i like it because it is different from any other app i've used, and thus has a spirit of it's own. there is really no need for so rarely used and in fact useless function as an about screen, to be seuperfast or a subject to any user interface laws. a dialogue with only one button (or even without), that you only use for curiosity, has no need for efficiency.
not that it's a big issue, but i will be sad if it goes away.
regards, bostjan
On Sat, 30 Jul 2005, [utf-8] Boštjan Špeti�^M wrote:
Date: Sat, 30 Jul 2005 22:12:43 +0200 From: "[utf-8] Boštjan Špeti�^M" <igzebedze@...402...> Cc: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: Inkscape Harsh Criticisms
You know, while I like the idea of using SVG in bowth Help documents and About dialog, I do hate when I have to wait till it's rendered and shown.
On my 1,6 Centrino + 512 Mbyte RAM laptop the current About dialog renders ~6 secs. This is insane. I would vote for a GIMP-like About box with a smaller SVG inside, if anyone cares to listen :)
There is a strong possibility the gimp will move to the standard dialog too and then see about adding back the eye candy.
The current About screen is quite slow to load which somewhat detracts from its good looks.
interesting. i always found it quite amusing to use a aboring about screen as a demo space of an application... yes it's slow, but with a reason. i like it because it is different from any other app i've used, and thus has a spirit of it's own. there is really no need for so rarely used and in fact useless function as an about screen, to be seuperfast or a subject to any user interface laws. a dialogue with only one button (or even without), that you only use for curiosity, has no need for efficiency.
not that it's a big issue, but i will be sad if it goes away.
Thing is although you might think About Dialogs are pointless or almost useless they do serve a purpose.
The tell you what the program is about, "Inkscape is for Drawing Scalable Vector Graphics (SVG)"*, they often provide a link to the website and contact information, they tell you the version (and sometimes specific build information that may be useful for bug reporting), and although not essential they show the developers names which is a source of pride.
Some programs add all kinds of animations and distractions to the About dialog which make it harder to get at the useful information (copy and paste it out) or make it impossible to point to the names of the developers because the actual information you are intereste in it is buried under a slow and tedious animation.
The standard about dialog makes sure to take care of all the functional requirements first, it may not be as pretty but it gets the job done.
I'm sure the inkscape artist can come up with a beatiful splash graphic even if they were given a slighly smaller canvas to work with. Using the standard dialog would however mean the information would be already taken care of so the graphic would have a lot less requirements. (If anyone were ever to try and port Inkscape to the Nokia 770/Maemo platform having used the standard widgets or at least the standard API will make their porting work a lot easier. Same probably goes for porting to any future versions of Gtk.)
Initially it might be easier and faster to use gdkpixpub/librsvg to render the SVG in the About. Perhaps another solution will be found, unless the standard GtkAbout dialog can be made scalable it might be nearly easier to use a prerendered PNG. Unfortunately all that defeats the one big strength of the current about dialog, it is a case of eating our own dogfood.
Sincerely
Alan Horkan http://advogato.org/person/AlanHorkan/
* You might think a person running your program already knows what it is about but you'd be wrong. It also makes a whole lot of sense to actually use the About dialog to tell users what the program is actually about. If we are very lucky Inkscape will be the first and only SVG Editor many people ever want to use.
On Sun, 2005-07-31 at 15:30 +0100, Alan Horkan wrote:
Initially it might be easier and faster to use gdkpixpub/librsvg to render the SVG in the About.
Unfortunately librsvg has very buggy rendering. We had considered using that for rendering our SVG button icons (so we could take full advantage of the standard Gtk icon factories, etc...), but it didn't work out.
Since people usually author about screens and icons for us in Inkscape, it would be very bad for things to look fine when edited in Inkscape, but then get all funky when used for Inkscape's own icons -- or worse the about window.
We get enough bug reports about people's Gnome SVG icons not rendering properly in Nautilus as it is. :/
Perhaps another solution will be found, unless the standard GtkAbout dialog can be made scalable it might be nearly easier to use a prerendered PNG. Unfortunately all that defeats the one big strength of the current about dialog, it is a case of eating our own dogfood.
We _could_ prerender to a pixbuf using our own renderer.
But then we'd still be abandoning the resizable dialog illustrating the scalability of SVG, and also some of the interactive rendering performance dogfood. :/
Right now, you can run inkscape with gprof, show the about dialog, and get a pretty good profile indicating interactive rendering bottlenecks.
-mental
On Sun, Jul 31, 2005 at 12:48:07PM -0400, MenTaLguY wrote:
On Sun, 2005-07-31 at 15:30 +0100, Alan Horkan wrote:
Initially it might be easier and faster to use gdkpixpub/librsvg to render the SVG in the About.
Unfortunately librsvg has very buggy rendering.
Note that this appears to be improving, and should largely resolve itself with cairo becoming the librsvg backend.
Since people usually author about screens and icons for us in Inkscape, it would be very bad for things to look fine when edited in Inkscape, but then get all funky when used for Inkscape's own icons -- or worse the about window.
Using Inkscape's renderer to render the About screen makes sense since we often encourage people to create screens that show off the latest and greatest features.
Also, to echo Alan's point about the about screen being useful for determining the version, I think it would be extremely useful if it included more than just the version number. I.e., the About screen may say 0.41, but the user could have a nightly build installed, or a pre-release of 0.42, or who knows what...
Bryce
the tools: node tool doesn't include any labels in the Commands bar would help if some of the items were labelled. same goes for the Zoom tool, too many similar icons are hard to disambiguate and text would help.
May be a good idea. Can you make a specific proposal?
Think Priority text, like on a standard toolbar.
I suppose at least Add Remove(Delete/Merge/???) should be labelled.
A single label to help group the three corner/node types might be enough rather than needing to label everything, at least for now.
Well, this is one point, where I disagree. I do think that grouping the items in the toolbar with separators would help to easily find the right tool, but labels are annoying because they waste so much screen estate when assigned to each button and are basically useless when you just use them as separators. Furthermore I personally think that the tool tip is what is supposed to tell you what a tool does. A graphic program like Inkscape is to some degree for professionals... you have to know the difference between a cusp and a smooth node. As soon as you do, you easily understand the images. Taking a look at them to distinguish them from one another doesn't take longer than reading a label but takes less time. Users who are still learning to use vector graphics are not familiar with many of the concepts, but labels -- i believe -- will not help explaining. Tool tips do a better job because they have more room. Anyways, if you do decide on labels, I ask you to make it dependent on the gnome setting for menus and toolbars -- actually I think that'd be the best solution.
Take care!
David
On Jul 29, 2005, at 1:40 PM, David Christian Berg wrote:
Well, this is one point, where I disagree. I do think that grouping the items in the toolbar with separators would help to easily find the right tool, but labels are annoying because they waste so much screen estate when assigned to each button and are basically useless when you just use them as separators.
I think that could be why one thing under GTK+ theme control is labels on buttons.
In doing some of the UI cleanup I started on we might hit that fairly soon. (Testing behavior with different extremes of themes is one thing I'm just getting started with).
Between themes and options we should get quite a range of people happy. Of course, that needs to be balanced with limiting the problems of too many choices.
On Fri, Jul 29, 2005 at 01:37:44PM +0100, Alan Horkan wrote:
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
Not my area - Peter, can you comment?
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface. It will probably need to be mentioned in the documentation anyway but the license is important to Free Software Evangelists not to users who want to draw stuff. Distributors should read the Licensing information, users shouldn't need to worry about it and windows users have already been required to agree to the License in the installer. (And users do not need to agree to the GPL just to use the software, only if they wish to redistribute modified versions.)
This particularly hit a nerve because the GIMP harasses users with inane questions the first time you run it, including displaying the License. There are better places for evanglism than this.
And to have a menu label steal the promiment position at the end of the list and then to have a five word label is not at all aesthetically pleasing to put it politely. (Sorry the more I do this the more hypersensative I get to these anomolies.)
I was also a bit curious when I saw this added to the help menu. It might be better to simply call it "License"?
I know that at least one user has asked for licensing terms for usage, so it's not ONLY good for evangelism purposes. Also, given that nearly every application out there bugs the user with the licensing terms on installation or at start up, I think having it just be a link somewhere in one of the menus is not too obtrusive.
On the other hand, I do see a point that from a user perspective it's probably not a very important link. Perhaps if the end of the list is a prominent position, it could move to mid-list.
Bryce
P.S., Alan, if you ever do get interested in hacking code, I'd encourage you to check out the menu code first; it's pretty simple code as far as code goes, and it sounds like you put as much thought into menu positioning, etc. as Bulia does into keyboard shortcuts. :-)
Bryce Harrington wrote:
I was also a bit curious when I saw this added to the help menu. It might be better to simply call it "License"?
I know that at least one user has asked for licensing terms for usage, so it's not ONLY good for evangelism purposes. Also, given that nearly every application out there bugs the user with the licensing terms on installation or at start up, I think having it just be a link somewhere in one of the menus is not too obtrusive.
On the other hand, I do see a point that from a user perspective it's probably not a very important link. Perhaps if the end of the list is a prominent position, it could move to mid-list.
Bryce
I have mentioned this before a couple of times recently. But I think that displaying the GPL and having someone "click thru" it, is a very cool thing. It lets the users feel like they are experiencing something that is a bit subversive. And with the "click," it allows them to be partisans in the Open Source movement.
I'm not talking about politics or cynicism. I'm just thinking about the "cool" factor that the end users might enjoy.
Bob (ishnal)
On Sun, Jul 31, 2005 at 11:37:03PM -0500, Bob Jamison wrote:
I have mentioned this before a couple of times recently. But I think that displaying the GPL and having someone "click thru" it, is a very cool thing. It lets the users feel like they are experiencing something that is a bit subversive. And with the "click," it allows them to be partisans in the Open Source movement.
Hmm, I don't know, I think this might be one of those things that's cool the first time you see it, and then just annoying every time after. ;-)
Don't get me wrong, I am most clearly a strong open source fanatic and quite driven to help encourage others to learn more about free software. I just don't think that popping up a copy of the GPL is going to have that effect; I would imagine people would just close that without reading it. ;-)
Bryce
Bryce Harrington wrote:
On Sun, Jul 31, 2005 at 11:37:03PM -0500, Bob Jamison wrote:
I have mentioned this before a couple of times recently. But I think that displaying the GPL and having someone "click thru" it, is a very cool thing. It lets the users feel like they are experiencing something that is a bit subversive. And with the "click," it allows them to be partisans in the Open Source movement.
Hmm, I don't know, I think this might be one of those things that's cool the first time you see it, and then just annoying every time after. ;-)
Don't get me wrong, I am most clearly a strong open source fanatic and quite driven to help encourage others to learn more about free software. I just don't think that popping up a copy of the GPL is going to have that effect; I would imagine people would just close that without reading it. ;-)
I agree, nobody will read it just as nobody read the EULA which is shown by various Microsoft applications in this way.
Selon Nicu Buculei <nicu@...398...>:
Bryce Harrington wrote:
On Sun, Jul 31, 2005 at 11:37:03PM -0500, Bob Jamison wrote:
I have mentioned this before a couple of times recently. But I think that displaying the GPL and having someone "click thru" it, is a very cool thing. It lets the users feel like they are experiencing something that is a bit subversive. And with the "click," it allows them to be partisans in the Open Source movement.
Hmm, I don't know, I think this might be one of those things that's cool the first time you see it, and then just annoying every time after. ;-)
Don't get me wrong, I am most clearly a strong open source fanatic and quite driven to help encourage others to learn more about free software. I just don't think that popping up a copy of the GPL is going to have that effect; I would imagine people would just close that without reading it. ;-)
I agree, nobody will read it just as nobody read the EULA which is shown by various Microsoft applications in this way.
Would it be a good idea to transfer this at install level : - nsi file for windows users - (existing) COPYING file for linux users (that are more aware of this) and remove it from the help menu ?
Regards,
Matiphas
Bryce Harrington wrote:
Hmm, I don't know, I think this might be one of those things that's cool the first time you see it, and then just annoying every time after. ;-)
Don't get me wrong, I am most clearly a strong open source fanatic and quite driven to help encourage others to learn more about free software. I just don't think that popping up a copy of the GPL is going to have that effect; I would imagine people would just close that without reading it. ;-)
So what exactly do the users give back, if 30 seconds of their time is too much? ;-)
Bob
On Sun, Jul 31, 2005 at 09:21:14PM -0700, Bryce Harrington wrote:
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface. It will probably need to be mentioned in the documentation anyway but the license is important to Free Software Evangelists not to users who want to draw stuff.
Roughly speaking, any user of any piece of software has some interest in copying that software -- whether copying to another machine, giving a copy to a friend, installing at work, etc.
I've no problem with changing the menu structure; indeed, I think we want a number of similar help items, some or all of which might be grouped together in a submenu:
- how to obtain the software (e.g. the most recent version, or getting for another platform);
- who to contact for support
- how to get the source code
- how to improve translations
users shouldn't need to worry about it and windows users have already been required to agree to the License in the installer. (And users do not need to agree to the GPL just to use the software, only if they wish to redistribute modified versions.)
I agree. Offhand, I don't think the GPL should be displayed by the installer at all.
This particularly hit a nerve because the GIMP harasses users with inane questions the first time you run it, including displaying the License.
I too think it shouldn't be displayed when first running the software.
I was also a bit curious when I saw this added to the help menu. It might be better to simply call it "License"?
I don't think so. The word has unfortunately become understood in the context of software not as a `license' (granting of permission) but as a contract that takes away freedom.
"Copying this software" would be OK though.
pjrm.
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface. It will probably need to be mentioned in the documentation anyway but the license is important to Free Software Evangelists not to users who want to draw stuff.
I was also a bit curious when I saw this added to the help menu. It might be better to simply call it "License"?
I don't think so. The word has unfortunately become understood in the context of software not as a `license' (granting of permission) but as a contract that takes away freedom.
"Copying this software" would be OK though.
Menu items need to be terse and succint, peferably one word so "Copying this software" would not be OK. "License" may not be perfect but it is by far the most suitable suggestion so far.
- Alan
On 8/1/05, Peter Moulder <Peter.Moulder@...38...> wrote:
users shouldn't need to worry about it and windows users have already been required to agree to the License in the installer. (And users do not need to agree to the GPL just to use the software, only if they wish to redistribute modified versions.)
I agree. Offhand, I don't think the GPL should be displayed by the installer at all.
The fact that most users don't read it doesn't mean that _all_ of the users should have no idea about their rights and responsibilities a propos software _before_ they install this particular software.
Alexandre
On Sun, 31 Jul 2005, Bryce Harrington wrote:
Date: Sun, 31 Jul 2005 21:21:14 -0700 From: Bryce Harrington <bryce@...260...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: Help -> License
On Fri, Jul 29, 2005 at 01:37:44PM +0100, Alan Horkan wrote:
Help, Modifying and Redistributing Inkscape. :( must resist urge to kill
Not my area - Peter, can you comment?
It is cruft, an unnecessary distraction. I would really like to see this bit of marketing propoganda removed entirely from the user interface. It will probably need to be mentioned in the documentation anyway but the license is important to Free Software Evangelists not to users who want to draw stuff. Distributors should read the Licensing information, users shouldn't need to worry about it and windows users have already been required to agree to the License in the installer. (And users do not need to agree to the GPL just to use the software, only if they wish to redistribute modified versions.)
And to have a menu label steal the promiment position at the end of the list and then to have a five word label is not at all aesthetically pleasing to put it politely. (Sorry the more I do this the more hypersensative I get to these anomolies.)
I was also a bit curious when I saw this added to the help menu. It might be better to simply call it "License"?
That would be a good start, I expect some of the translators have effectively done so already (although translators could provide valuable insight into usability issues if they pointed out problems rather than glossing over them).
I'd hope there could be room to move it to the about dialog at some point, a more standardised About dialog could accomodate a row of buttons underneath the main graphic. (I want to see the stanadard GtkAbout dialog used so I am reluctant to even suggest this but it might be more intereting to use a normal fully decorated Inkscape window to show the about information like Mozilla does it.)
I know that at least one user has asked for licensing terms for usage,
I saw that mail too. Magazine editors often ask too despite the GNU General Public License being clear on their entitlements.
It would be good to have the license with some explanation on the website if it is not there already, and prominantly linked from the download page which I think is the best place for it.
so it's not ONLY good for evangelism purposes. Also, given that nearly every application out there bugs the user with the licensing terms on
Commercial applications certainly do feature licensing information prominently but Open Source applications are a lot more sublte about it.
installation or at start up, I think having it just be a link somewhere in one of the menus is not too obtrusive.
Yeah. When I get started poking at little issues it is hard to accurately convey the relative (un)importance of my various suggestions.
On the other hand, I do see a point that from a user perspective it's probably not a very important link. Perhaps if the end of the list is a prominent position, it could move to mid-list.
Top and bottom positions of a menu are hotspots, and you will almost always find the Help Contents as the first item and the About Program as the last.
P.S., Alan, if you ever do get interested in hacking code,
The old Sodipodi code scared me off, it was quite unlike the other Gtk applications I had seen before and could usually manage to provide patches for the details that concerned me. It is still a horribly time consuming job to get it all up and running and get a properly tested patch but I will really have to make more of an effort to provide patches in future. Thankfully the new XML for menus should make it easier to propose a new layout soon.
My brother is getting married this month so I will have to propose things by the end of the week because after that I probably will not have any more time for Inkscape until well after the next release.
I'd encourage you to check out the menu code first; it's pretty simple code as far as code goes, and it sounds like you put as much thought into menu positioning, etc. as Bulia does into keyboard shortcuts. :-)
You tend to learn the rationale for shortcuts, mnemonics and menu positioning all at the same time and they tend to fit together.
On the one hand you dont want to have a menu structure too deep (helps to ahve at least 3 items before bothering with a submenu) but you dont want menus too long. There is the oft quoted research which says most people can remember 7 things plus or minus 2 but the complexity of an application like Inkscape will necessitate longer menus and it is probably better to keep it practical and look to the average graphics application for reference. I hope to get a trial version of Freehand and possibly Illustrator running and have suggestions soon. I'm increasingly confident a seperate Select menu might be a good idea (Adobe Illustrator has it, Macromedia Fireworks MX has it but strangely Freehand does not). I have a couple of other ideas I have to try out and make sure they do not look too lopsided with Inkscape current feature set but I really hope to have a useful plan soon.
- Alan
On Thu, 28 Jul 2005, bulia byak wrote:
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
I hope others can learn to cast a critical eye on Inkscape because if it sucks to be the only one playing devils advocate
Well, you're far from the only one. We had a lot of discussion with Kevn Wixson for example, and this resulted in a lot of improvement in the Node tool, and as far as I remember most if not all of his criticisms were resolved satisfactorily. So if nobody supports some of your criticisms, well... maybe it's because people like Inkscape the way it is? :)
:P
If you want me to keep doing this you really have to keep asking. Inviting the Gnome usability team and the Open Usability group to take
a
go at reviewing Inkscape might be a good way to hear a different point
of
view from mine for a change.
Sure, what do we do to make this happen?
something like this mailto:usability@...45...
Dear Gnome Usability Team
We would love if somone could help evaluate Inkscape with a fresh pair of eyes. Experience of graphic design and familiarity with other vector graphics software is a plus but please be honest about any bias you may have. There are various things we are generally aware need work but have not decided best how to tackle the problems. Anyone interested in helping review Inkscape should probably keep in touch with the developers on irc.freenode.net #inkscape so as not to get up to speed and get a chance to look at things that have not been considered yet.
Sincerely
"A. Inkscape Developer"
Requesting a review from OpenUsability should be similarly easy and from what I have seen of them they will likely take quite a formal approach and could produce very different insights.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
may have. There are various things we are generally aware need work but have not decided best how to tackle the problems.
Please consuder adding a list of most visible issue we are aware of (like Preferences dialog)
Anyone interested in helping review Inkscape should probably keep in touch with the developers on irc.freenode.net #inkscape so as not to get up to speed and get a chance to look at things that have not been considered yet.
Inkscape's Jabber channel seems to be a more usual place for discussions.
Alexandre
On Fri, 29 Jul 2005, Alexandre Prokoudine wrote:
Date: Fri, 29 Jul 2005 16:50:41 +0400 From: Alexandre Prokoudine <alexandre.prokoudine@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Requesting Usability Reviews [was Re: Inkscape Harsh Criticisms]
On 7/29/05, Alan Horkan <horkana@...44...> wrote:
may have. There are various things we are generally aware need work but have not decided best how to tackle the problems.
Please consuder adding a list of most visible issue we are aware of (like Preferences dialog)
Not sure where best to highlight these things, but will try and make some time add suitable comments in the Wiki.
Anyone interested in helping review Inkscape should probably keep in touch with the developers on irc.freenode.net #inkscape so as not to get up to speed and get a chance to look at things that have not been considered yet.
Inkscape's Jabber channel seems to be a more usual place for discussions.
They are interlinked.
- Alan
On Thu, 28 Jul 2005, bulia byak wrote:
<snip>
Oh and if you could get Inkscape into Garnome[1] I'd be a lot more likely to build it occasionally and perhaps others would too.
Anyone knows what needs to be done for this?
A "garball" would need to be create for Inkscape. The ideal person to look at this would be familiar with packaging and buidling from source.
From my understanding this should be somewhat familiar to anyone who has
created a Gentoo package.
At least part of it is a makefile which specifies the download location and dependencies for Garnome to draw down as needed.
The Garnome developers are very helpful. The slightly more unusual dependancies of Inkscape might worry them but I think they already include a few other GtkMM programs. (I've created a garball before but I was I was able to copy the one from an existing program with similar dependancies and only really needed to change the names.)
I'll file a request and if someone famaliar with all the difficulties and gotchas of building Inkscape could add themselves to the CC list and provide help that would probably be a good start http://bugzilla.gnome.org/enter_bug.cgi?product=GARNOME
I'll post a follow up message with a bug number when I have file the request.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
Yeah, yeah... top posting is the devil.
With things such as toolbar buttons ('not rounded/reset' type stuff) and menu entries, I would be more than happy to make modifications along those lines if it is what the other developers want.
Your metadata "jargon" issue is kinda strange though, I was recently at a state bar seminar and I was amazed at how many people actually know what metadata is. I'm talking secretaries, legal assistants, office managers, and attorneys (none of which I would think would know what it was). It's a much more commonplace term these days than it was in 1998.
-Josh
-----Original Message----- From: inkscape-devel-admin@lists.sourceforge.net
[mailto:inkscape-devel-
admin@lists.sourceforge.net] On Behalf Of Alan Horkan Sent: Thursday, July 28, 2005 12:36 PM To: bulia byak Cc: Inkscape is a vector graphics editor Subject: [Inkscape-devel] Re: Inkscape Harsh Criticisms
On Thu, 28 Jul 2005, bulia byak wrote:
Date: Thu, 28 Jul 2005 14:41:52 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: Inkscape Harsh Criticisms [was Re: [Inkscape-devel]
Possible
bug in 0.42]On 7/28/05, Alan Horkan <horkana@...44...> wrote:
The edit menu has a massive twenty one, count 'em 21 items.
I have a feeling everyone is looking at me. Hey guys, I think I already explained it: menus (top menus and right-click menu) are NOT my domain. I'm just not interested in them because I don't use them. EVERYONE is welcome to come and rearrange them in any way
imaginable.
Hey, rearranging top menu items is as easy as rearranging single
lines
in interface.cpp. Where are your patches?
Fair point but that only goes so far, I really dont have the time to
work
on every project I see a problem with even if I would like to help.
The menus were but one example.
Inkscape Preferences dialog is a candidate for the User Interface
Hall
of
shame.
What is BY FAR most important to _me_ is that all options have meaningful descriptions and tooltips, and on copyediting them I
spend
a lot of my time. The rest (what? pretty icons? anyway, whatever you like) can be handled by anyone who's motivated to do it.
That is condescending and dismissive. There are serious structural problems in the layout. In one situation you can get three levels of Tabbed dialogs which is frankly insane but Alexandre has worked on this and hopefully his work
can
be put into practice.
Please do try to read through the Gnome Human Interface Guidelines
even
reading a little of it might help give a sense of some of the
underlying
concepts. A good book on user interface design would probably be more pleasant to read though and just as informative.
I am sorry to say I am dissapointed by Inkscape 0.42 which in some
ways
has taken steps backward in terms of usability
Such as? Please be specific.
How long have you got?
Keep in mind you did ask and I did warn you ...
I dont have time to list everything. I'm not an expert either so sometimes all I can do is vaguely point at a problem without
necessarily
being able to offer a solution.
If the Inkscape developers cannot step back and see most of the problems themselves things will only get worse again. Reread my
previous
mail and see if you can guess which misfeatures I was trying to point
out,
try and find a prominant feature that is more about debugging than about artwork and never should have been left visible in a release build.
My previous comments about getting rid of parenthesis from menu
item(s)
was ignored.
Vacuum Defs is still weird. I don't have all the answers but a way to "define styles" and treat defs similarly to predefined styles.
I know a lot of my suggestions will amount to looking at the
competition
and seeing what they do which is why I encourage others to do the
same.
I suppose I should look at XaraX too and try and get some insight into where Bulia is coming from but I think Adobe Illustrator and
Macromedia
Freehand are by far the most important to take a look at.
Other miscellanious quibbles, fairly raw and unfiltered:
need a submenu "View, Zoom" (short version, long versions will require a little more thought and reorganisation)
keybindings are not configurable, forces developers to try and
hardcode
defaults for everything cannot please everyone.
the old F1 ... keybindings are a bit weird, and I will bet the target audience of former Sodipodi and Corel Draw users is smaller than the Illustrator/Freehand audience. of course I'd love to have both but it doesn't make for a great default approach.
using the commands bar/options bar for both the tool defaults and
changing
the properties of the current object is weird (therefore harder to
learn)
and I still dont particularly like it.
the tools: node tool doesn't include any labels in the Commands bar
would
help if some of the items were labelled. same goes for the Zoom tool,
too
many similar icons are hard to disambiguate and text would help. text to the right of some of
retangle tool "Not rounded" inconsistent should be Reset, other tools labelled default should be renamed to Reset (use a verb not a noun).
freehand/draw bezier/text tools have nothing on the command bar.
colour
picker has only one item. seriously rough edges, sanding smoothing painting and polishing required.
Help, Modifying and Redistributing Inkscape. :( must resist urge to
kill
"Help, About memory" is not a useful user (artist not developer user) feature should at the very least be hidden from release builds (this
is
what I was referring to earlier).
Help About Inkscape. I'd prefer if this were simply Help, About like
most
Gnome programs. Stock items make less translation work. I strongly recommend implementing the standard GtkAbout dialog. The standard
dialog
provides version and contact information that can be easily cut and
paste
out of the dialog. The inkscape about dialog does not. use the
standard
dialog, make work then make it pretty later.
Rulers are ugly. Turn them off by default. Sure there is a small discoverability penalty but Inkscape is not for techincal drawing and
we
dont leave the grid on by default either.
The word metadata is jargon and we should not need to use it in the
user
interface. I've complained before about the Document preferences dialog, I think
we
need to do a split between the "Page Setup" and the File Properties
(aka
metadata). read the HIG, text should generally be left aligned (sometimes top
left)
it isn't in this dialog.
Group Ctrl+G, Ungroup Ctrl+U. Isn't Ctrl+U being used elsewhere for Unicode input? using Ctrl+Shift+G would be more consistent with the
HIG
anyway.
think as a new user: "How is a Path not an Object?" is suspect they aren't and a reorganisation will effectively merge most of this back
into
the Object menu. dont have a copy of Illustrator available to check against unfortunately.
Fill and Stroke, Swatches, Object Properties are all palettes/docks
and
should probably be under view rather than Object.
The Layer menu includes a lot of "Layer, something Layer" which is redundant.
having a top level select menu might help sort out some of the
imbalance
in the Edit menu but it may only serve to move the problems around.
The
tool "Edit, Find" in many ways similar to Select by ...
"Help, Keys and Mouse" doesn't make sense, needs a better label.
...
...
you did ask ...
dont say I didn't warn you ...
More later. It is difficult to turn my brain off and be hypercritical about everything. It can be quite tiring and a little depressing especially when I start feeling I'm being ignored. Being able to look back and say "I told you so" doesn't motivate me to continue making suggestions (which combined with exams is why I've been fairly quiet recently).
I hope others can learn to cast a critical eye on Inkscape because if
it
sucks to be the only one playing devils advocate, and it is not my
goal to
be the designated jerk but keep in mind I'm trying to give useful
feedback
but sometimes I have to tap into my "inner troll" to do it and it
makes me
really crankey. Arguing on the internet just makes everyone involved
a
loser and it is not my idea of fun. I dont have time (or expertise
but it
is effectively the same as time) to implement most/any of this even providing as much nitpickign as I do requires a fair amount of effort without so much as a footnote in the Thanks file for it.
If you want me to keep doing this you really have to keep asking. Inviting the Gnome usability team and the Open Usability group to take
a
go at reviewing Inkscape might be a good way to hear a different point
of
view from mine for a change.
Oh and if you could get Inkscape into Garnome[1] I'd be a lot more
likely
to build it occasionally and perhaps others would too.
Sincerely
Alan Horkan
[1] http://cipherfunk.org/garnome/
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Quoting Alan Horkan <horkana@...44...>:
That is condescending and dismissive.
...
Please do try to read through the Gnome Human Interface Guidelines even reading a little of it might help give a sense of some of the underlying concepts.
You may want to carefully examine your own tone.
If the Inkscape developers cannot step back and see most of the problems themselves things will only get worse again.
I'll give you a pass, as it's easy to lose track of the discussions now that the mailing list is so high-volume, but most of the concerns you've mentioned have been raised by other Inkscape developers on this exact list, often multiple times.
A few things we do strongly disagree with, sometimes because the requests are impractical or contradictory due to technical issues and annoying properties of the SVG specification (c.f. our discussion re: your request for ellipse-as-<ellipse> a month or two back, versus your current demand for the removal of distinctions between shapes and paths).
In many cases, though, things are as they are due to lack of time and/or difficulty in finding workable alternatives. The current developers are pretty much maxed out, and a most of our time goes into bugfixing and resolving architectural issues.
Stuff like the preferences dialog has annoyed me for a long time (and I'm on record many places, e.g. here on the list and on Slashdot as saying so), but I simply cannot do anything about it without abandoning other work.
It often is an either/or choice between bug fixing and UI work for us. e.g. I too am unhappy with the current prominence of the About Memory dialog (which we do want to give to end-users in some form, as it helps them gather information for certain classes of bug reports), but I simply. did. not. have. time. to. do. the. requisite. surgery. on. the. bloody. interface. code. to. fix. it. before. the. release. thank. you.
Oh and if you could get Inkscape into Garnome[1] I'd be a lot more likely to build it occasionally and perhaps others would too.
Yes, how about it? Any volunteers out there?
It's good to raise these things periodically, and in fact I suspect some of them will get addressed soon because they've been raised now.
But, if stuff doesn't get done for a long period of time, _acting hurt when the existing developers don't adopt your priorities_ (regardless of how good they may be in their own right) doesn't help anything.
It leaves people feeling like they are expected to be your personal monkeys.
If you feel something particularly important is simply not getting addressed, make a patch, or if the particular work is beyond your means, try soliciting volunteers who aren't already overworked to do it.
Then we can discuss the actual merits of the patch, instead of "why should I work on this rather than something else?" It also puts an end to theoretical arguments about what is feasible.
I could be mistaken regarding that paths versus shapes distinction, for example, but at this point I'm not going to devote fifteen hours to proving myself right or wrong on that point in preference to other work.
-mental
Sorry, that was a bit over-the-top.
I think many of the things you presented were good and need to be addressed (and a "polish" release cycle like 0.43 is an appropriate time); I was reacting emotionally to the presentation because a lot of them have been locii of frustration for me.
-mental
On Thu, 28 Jul 2005 mental@...3... wrote:
Date: Thu, 28 Jul 2005 16:50:55 -0400 From: mental@...3... To: Alan Horkan <horkana@...44...> Cc: bulia byak <buliabyak@...400...>, Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: Inkscape Harsh Criticisms
Quoting Alan Horkan <horkana@...44...>:
That is condescending and dismissive.
English is a rotten language sometimes, terribly lacking in precision.
Please do try to read through the Gnome Human Interface Guidelines even reading a little of it might help give a sense of some of the underlying concepts.
You may want to carefully examine your own tone.
Yeah, sorry I got a little carried away.
Best if I wait until tomorrow before writing a calmer and better thought out series of responses to the various points. I admit I did throw out a laundry list of minor gripes which do however all add up and give an idea as to why someone like the user on that forum might dismiss Inkscape so casually but in the larger scheme I shouldn't have gotten so bothered about.
I'll respond to the other points later.
Sincerely
Alan Horkan
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
Best if I wait until tomorrow before writing a calmer and better thought out series of responses to the various points. I admit I did throw out a laundry list of minor gripes which do however all add up and give an idea as to why someone like the user on that forum might dismiss Inkscape so casually but in the larger scheme I shouldn't have gotten so bothered about.
Frankly, I very much doubt that anyone can call a program "utterly unusable" based solely on things like oversized menus, strange command names, or hard to navigate preferences dialog. Much more likely, he just had an early crash or two.
On Thu, 28 Jul 2005 mental@...3... wrote:
Date: Thu, 28 Jul 2005 16:50:55 -0400 From: mental@...3... To: Alan Horkan <horkana@...44...> Cc: bulia byak <buliabyak@...400...>, Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: Inkscape Harsh Criticisms
Quoting Alan Horkan <horkana@...44...>:
That is condescending and dismissive.
...
Please do try to read through the Gnome Human Interface Guidelines even reading a little of it might help give a sense of some of the underlying concepts.
You may want to carefully examine your own tone.
If the Inkscape developers cannot step back and see most of the problems themselves things will only get worse again.
I'll give you a pass, as it's easy to lose track of the discussions now that the mailing list is so high-volume, but most of the concerns you've mentioned have been raised by other Inkscape developers on this exact list, often multiple times.
A few things we do strongly disagree with, sometimes because the requests are impractical or contradictory due to technical issues and annoying properties of the SVG specification (c.f. our discussion re: your request for ellipse-as-<ellipse>
I realise editing the markup directly is a weird obsession of mine few others share. I blame Jasc WebDraw for making it so easy. Realising the techincal difficulties of making this happen I'm willing to ignore this until the distant future until it become less impractical and it is not (or at least should not be) as big a deal to me as I may have suggested.
a month or two back, versus your current demand for the removal of distinctions between shapes and paths).
Huh? Don't think I asked for that.
In many cases, though, things are as they are due to lack of time and/or difficulty in finding workable alternatives.
I got caught up in the frenzy of the release and the brain drain of slashdot and lost sight of the pratical realities of Open Source developments. (My inner troll took control temporarily and tricked me ;)
The current developers are pretty much maxed out, and a most of our time goes into bugfixing and resolving architectural issues.
Fair point, all to easy to forget. I guess I have to be constantly reminded.
Stuff like the preferences dialog has annoyed me for a long time (and I'm on record many places, e.g. here on the list and on Slashdot as saying so), but I simply cannot do anything about it without abandoning other work.
It is the contrast of knowing things are wrong with wanting to defend Inskcape from wild accusations and trolling that makes this situation so awkward.
It often is an either/or choice between bug fixing and UI work for us. e.g. I too am unhappy with the current prominence of the About Memory dialog (which we do want to give to end-users in some form, as it helps them gather information for certain classes of bug reports), but I simply. did. not. have. time. to. do. the. requisite. surgery. on. the. bloody. interface. code. to. fix. it. before. the. release. thank. you.
I guess some of these kinds of things could be metioned in the wiki, perhaps on the roadmap or some where else as known issues to try and avoid frustration about it.
I guess it is trying do usability work on Inkscape is like trying to paint a speeding locomotive!
It's good to raise these things periodically, and in fact I suspect some of them will get addressed soon because they've been raised now.
But, if stuff doesn't get done for a long period of time, _acting hurt when the existing developers don't adopt your priorities_ (regardless of how good they may be in their own right) doesn't help anything.
Lets just say I didn't put things across exactly as well or as clearly as I might have liked to have done.
It leaves people feeling like they are expected to be your personal monkeys.
I'm sorry if I was too overbearing. What I was really hoping for was for more of the really minor trivial changes could be quickly fit in with other changes by developers who could get things done a million times quicker than I possibly could. I've also assumed there was more agreement with my suggestions than perhaps there really was.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Fri, 29 Jul 2005, MenTaLguY wrote:
Date: Fri, 29 Jul 2005 14:31:20 -0400 From: MenTaLguY <mental@...3...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Re: Inkscape Harsh Criticisms
On Fri, 2005-07-29 at 14:17 +0100, Alan Horkan wrote:
I guess it is trying do usability work on Inkscape is like trying to paint a speeding locomotive!
That is seriously the most apt description of it that I have ever heard!
I was going for something quotable (fat chance of anyone quoting me but I live in hope) and a non Inkscape specific way of putting it would be:
"Trying to do usability work on any large project is like trying to paint a speeding locomotive"
- Alan
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
On Thu, 28 Jul 2005, bulia byak wrote:
On 7/28/05, Alan Horkan <horkana@...44...> wrote:
The edit menu has a massive twenty one, count 'em 21 items.
[ snip ]
[ snip ]
Vacuum Defs is still weird. I don't have all the answers but a way to "define styles" and treat defs similarly to predefined styles.
(Aside) I wouldn't know what Vacuum meant in this context. The term was once used in the Postgresql project. Something like 'Delete/Clear/Clean up unused/unneeded colours/styles/definitions/...' would be better. Perhaps not as a menu item, but an option in a 'Save As' or 'Export' dialog.
[ snip ]
"Help, About memory" is not a useful user (artist not developer user) feature should at the very least be hidden from release builds (this is what I was referring to earlier).
(Aside) I think end users quite like looking at memory usage and footprint. Most are well aware of the significance of adequate physical memory to the performance of their system as a whole and perhaps welcome the chance to monitor it for themselves; and it is evidence that the developers care about memory issues.
Rulers are ugly. Turn them off by default. Sure there is a small discoverability penalty but Inkscape is not for techincal drawing and we don't leave the grid on by default either.
(Aside) it is possible that some people want rulers (I do) and some people don't. If you really don't rulers on by default (not many of us can draw well without help) then there is a case for a preference.
The word metadata is jargon and we should not need to use it in the user interface.
Yes, but meta-data has a precise meaning, and one that is useful to people who are using SVG.
[ snip ]
having a top level select menu might help sort out some of the imbalance in the Edit menu but it may only serve to move the problems around. The tool "Edit, Find" in many ways similar to Select by ...
I agree with the two substantive points there.
1. There is a case for a Select menu. Photoshop has one, and when we use a art program we are constantly making, modifying and clearing selections. It is extremely useful to be able to go to a top level menu and see what the developers have provided for us.
2. Find is similar to Select By.
If you wanted to quickly improve/work on the Edit menu we could reasonably:
1) Move all Find/Replace operations to a separate menu; and 2) move all Select operations to a separate menu; and 3) move the XML editor to either a View, Window or Tools menu. (The XML editor button sits nicely on the toolbar, and I would even question whether it needs to be on a menu at all. I would hope that the XML editor might one day become a 'view codes'/Split screen operation. IIRC Dreamweaver either does or used to do this) .
H O W E V E R, do we really want to do anything quickly? Do we want programmers/developers pushing the user interface, or users/artists pulling it?
Personally I feel that developing the user interface is the single most important activity. Can it be done stepwise in an evolutionary way? Should we be requesting detailed mock ups? Should we release several competing designs. Few, if any, bazaar developed projects have passable user interfaces, let alone good ones, and I don't see why this should be ...
FWIW, a program that suited me perfectly would probably not be at all appealing to anyone else, and I am certainly not going to push my ideas, but I do argue against working in a vacuum. Without a clear idea of the constituency that we need to please, making changes is just going to be a waste of time.
Are we likely to identify 'user stories' - cases where users have had difficulty performing tasks owing to some feature of the design? In the present case, are people pulling down the Edit menu expecting to find 5 or 6 items, actually seeing over 20 and running away - saying that Inkscape isn't ready yet ...
I don't know ...
Ben
On Fri, 2005-07-29 at 01:10 +0100, Ben Fowler wrote:
(Aside) I wouldn't know what Vacuum meant in this context. The term was once used in the Postgresql project. Something like 'Delete/Clear/Clean up unused/unneeded colours/styles/definitions/...' would be better. Perhaps not as a menu item, but an option in a 'Save As' or 'Export' dialog.
To summarize the prior discussions about this:
The main reason we've not done that is that there's no precise way to determine "unused/unneeded" in SVG, especially because of the potential for (intentional) external references.
We use a very conservative heuristic, but heuristics are by definition imperfect. Right at save time would be the worst possible time for such a deletion heuristic to fail.
If we only prune library objects in response to explicit requests by the user, they at least have an opportunity to check and undo if something got nuked that they wanted to keep.
Library/defs management needs a less opaque UI anyway (i.e. more than just the XML editor -- something at least as good as Flash's library palette). Once we have that we'll have somewhere else we can move "Vaccuum Defs", where its effect can be apparent and sensible. Visible context may inspire a better name too.
Are we likely to identify 'user stories' - cases where users have had difficulty performing tasks owing to some feature of the design? In the present case, are people pulling down the Edit menu expecting to find 5 or 6 items, actually seeing over 20 and running away - saying that Inkscape isn't ready yet ...
I don't know ...
Researching and collecting user stories is an important part of usability work. We should certainly do more of it than we have been doing.
-mental
On Thu, Jul 28, 2005 at 09:37:01PM -0400, MenTaLguY wrote:
Are we likely to identify 'user stories' - cases where users have had difficulty performing tasks owing to some feature of the design? In the present case, are people pulling down the Edit menu expecting to find 5 or 6 items, actually seeing over 20 and running away - saying that Inkscape isn't ready yet ...
I don't know ...
Researching and collecting user stories is an important part of usability work. We should certainly do more of it than we have been doing.
I think this is a great idea, would anyone be interested in interviewing users and collecting this information into well organized wiki pages?
Bryce
participants (19)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
Andreas Nilsson -
Ben Fowler -
Bob Jamison -
Boštjan Špetič -
Bryce Harrington -
bulia byak -
David Christian Berg -
Erik -
John Taber -
Jon A. Cruz -
Joshua A. Andler -
Lee Braiden -
Lucas Vieites -
MenTaLguY -
Nicu Buculei -
Peter Moulder