Since none of our standard libs could offer a cross-platform, easily available way to launch an URL in the user's default browser, I looked around and found exactly what we need in Python (which we carry anyway) - the standard "webbrowser" module. So I created some Python extensions to launch various URLs using webbrowser.open calls, and put them into Help menu:
- Inkscape Manual links to http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
- Command line options: http://inkscape.org/doc/inkscape-man.html
- FAQ on wiki
- Release notes for the current version
- "Report a bug" page
- SVG 1.1 specification at w3.org
I tested this and it seems to work well in Linux and Windows. Let me know if you have any problems. Also feel free to suggest other "launch an URL" commands for Inkscape (openclipart? wiki? inkscape.org? Aaron's extension page?)
The only change I made in the core of Inkscape was to allow an inx file to specify <effects-menu hidden="yes"/> so that these new extensions don't automatically show up in the Effects menu.
On Mon, 2006-10-09 at 21:00 -0300, bulia byak wrote:
Since none of our standard libs could offer a cross-platform, easily available way to launch an URL in the user's default browser, I looked around and found exactly what we need in Python (which we carry anyway) - the standard "webbrowser" module. So I created some Python extensions to launch various URLs using webbrowser.open calls, and put them into Help menu:
This is so great! Thanks bulia...
- Inkscape Manual links to
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
I think we should offer tavmjong to have a subdomain for his manual at:
http://manual.inkscape.org/ and then link to this. What do y'all think?
- Command line options: http://inkscape.org/doc/inkscape-man.html
Very cool!
- FAQ on wiki
y
- Release notes for the current version
y
"Report a bug" page
SVG 1.1 specification at w3.org
Maybe we could have a hierarchical menu that links to all major versions of SVG. This would be great for development. I'm thinking:
SVG Specifications
SVG 1.2 Draft http://www.w3.org/TR/SVG12/ SVG 1.1 Spec http://www.w3.org/TR/SVG11/ SVG Mobile 1.2 Draft http://www.w3.org/TR/SVGMobile12/ SVG Mobile Spec http://www.w3.org/TR/SVGMobile/ SVG Print Spec http://www.w3.org/TR/SVGPrint/
And a link to the w3 svg page: http://www.w3.org/Graphics/SVG/
(I basically copied the main specs they highlight) This is important for development IMO.
I tested this and it seems to work well in Linux and Windows. Let me know if you have any problems. Also feel free to suggest other "launch an URL" commands for Inkscape (openclipart? wiki? inkscape.org? Aaron's extension page?)
Yeah, all those would be absolutely awesome...Is there a generic bag/main-menu we should have for those?
The only change I made in the core of Inkscape was to allow an inx file to specify <effects-menu hidden="yes"/> so that these new extensions don't automatically show up in the Effects menu.
Very cool!
Jon
On Mon, Oct 09, 2006 at 05:16:16PM -0700, Jon Phillips wrote:
On Mon, 2006-10-09 at 21:00 -0300, bulia byak wrote:
Since none of our standard libs could offer a cross-platform, easily available way to launch an URL in the user's default browser, I looked around and found exactly what we need in Python (which we carry anyway) - the standard "webbrowser" module. So I created some Python extensions to launch various URLs using webbrowser.open calls, and put them into Help menu:
This is so great! Thanks bulia...
- Inkscape Manual links to
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
I think we should offer tavmjong to have a subdomain for his manual at:
http://manual.inkscape.org/ and then link to this. What do y'all think?
Great idea... Mental and I had discussed this at OLS this past summer.
Mental, would you mind setting up the DNS for this? Will a VHOST entry be needed for it?
Bryce
bulia byak wrote:
The only change I made in the core of Inkscape was to allow an inx file to specify <effects-menu hidden="yes"/> so that these new extensions don't automatically show up in the Effects menu.
Was there already any work toward placing extension commands in arbitrary menus via the inx files?
Aaron
On 10/9/06, Aaron and Sarah Spike <spike@...749...> wrote:
Was there already any work toward placing extension commands in arbitrary menus via the inx files?
Not that I know of, and thinking about it, it does not seem like a good idea for inx files to be aware of the entire menu structure of Inkscape. They only need to know the organization of their only menu effects subtree, and the application then grafts that entire subtree into the Effects menu by a single command in menus-skeleton.h.
On Mon, 9 Oct 2006, bulia byak wrote:
On 10/9/06, Aaron and Sarah Spike <spike@...749...> wrote:
Was there already any work toward placing extension commands in arbitrary menus via the inx files?
Not that I know of, and thinking about it, it does not seem like a good idea for inx files to be aware of the entire menu structure of Inkscape. They only need to know the organization of their only menu effects subtree, and the application then grafts that entire subtree into the Effects menu by a single command in menus-skeleton.h.
I just want to say that I agree with Bulia on this. I don't think having everything in the INX files will scale well. As more functionality moves to extensions, it will also become very difficult to support other menu organizations from other programs (the point of having the XML support). So, I think it's be better to use the extensions from the menu definition if that makes sense for the extension.
--Ted
Cool,
you may also have a look at the user_manual branch and see if it can be added as help.
pygmee
Since none of our standard libs could offer a cross-platform, easily available way to launch an URL in the user's default browser, I looked around and found exactly what we need in Python (which we carry anyway) - the standard "webbrowser" module. So I created some Python extensions to launch various URLs using webbrowser.open calls, and put them into Help menu:
- Inkscape Manual links to
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
Command line options: http://inkscape.org/doc/inkscape-man.html
FAQ on wiki
Release notes for the current version
"Report a bug" page
SVG 1.1 specification at w3.org
I tested this and it seems to work well in Linux and Windows. Let me know if you have any problems. Also feel free to suggest other "launch an URL" commands for Inkscape (openclipart? wiki? inkscape.org? Aaron's extension page?)
The only change I made in the core of Inkscape was to allow an inx file to specify <effects-menu hidden="yes"/> so that these new extensions don't automatically show up in the Effects menu.
Sorry for the late reply.
On Mon, 9 Oct 2006, bulia byak wrote:
Date: Mon, 9 Oct 2006 21:00:14 -0300 From: bulia byak <buliabyak@...400...> To: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] NEW: more stuff in Help menu
Since none of our standard libs could offer a cross-platform, easily available way to launch an URL in the user's default browser, I looked around and found exactly what we need in Python (which we carry anyway) - the standard "webbrowser" module. So I created some Python extensions to launch various URLs using webbrowser.open calls, and put them into Help menu:
The help menu already includes many great tutorials and I think that is where the focus should really be and only a few links should be included (particularly given the brittle nature of web links).
- Inkscape Manual links to
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
Yes definately. In ten years time that link might break, especially since it links to index.php instead of the relevant directory. Odds are it will break far sooner than that - and who knows what it could get changed to - but once there are Inkscape binaries out there in the wild there will be nothing we can do about it.
Inkscape should only include links under the cotrol of Inkscape which can safely be changed later in case of emergency. Who knows in several years Inkscape could be run be a completely different team of bright new developers (hopefully that wont be necessary but again you never know).
So linking indirectly through inkscape.org is best practice and is definately what should be done.
- Command line options: http://inkscape.org/doc/inkscape-man.html
Linking to specific .html pages should be avoided, preferably links should go to diretories, that way it doesn't matter if the actual page is index.php or index.cgi or index.html or whatever.
For something like command line arguements it might be better to programatically show exactly what arguements are available in the version the user actually has. Pointing to a page on the web risks giving users information that doesn't match their version, and although there is always that risk it will be particularly obvious and avoidable in this case.
I would be concerend that Command line arguments should not be needed by most users - if many people are using them then batch features of the GUI would need to be improved. The man page or running inkscape --help are the standard places to find command line help, a menu item would be relatively unusual. Simply making sure a copy of the man page was included in the ordinary users manual should nearly be enough.
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
We've seen the FAQ move several times already and even an update in the Wiki software might cause it to move again.
- Release notes for the current version
Personally I wouldn't consider this as something users would read frequently (more than once even?) and therefore not worth having a menu item.
- "Report a bug" page
Good idea in principle, problematic in practice = bug or feature request? (Mostly a menu item will give you feature requests.)
Real bugs need detailed feedback like stack traces and integration with bug-buddy or similar tools is more likely to result in the kind of high quality feedback you really want.
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape. Is this really useful to artists?
Also which specification do you link to, there are plenty of variations to choose from and I do think this would be much better served by writing up a page in the documentation.
Referencing the specifications in the manual is certainly a good idea but again I do not think it is something users would check frequently enough for it to deserve a menu item. The manual and the FAQ are two things which I am confident users would check frequently and would even want to have links for both the local (fast access) and online (most up to date) copies.
I tested this and it seems to work well in Linux and Windows. Let me know if you have any problems. Also feel free to suggest other "launch an URL" commands for Inkscape (openclipart? wiki? inkscape.org? Aaron's extension page?)
I would urge restraint since I've seen so many crappy programs with links that no longer point to anywhere useful but it is certainly tempting to include a link to OpenClipart.org at least until OpenClipart.org is integrated with inkscape in some other way.
On 10/11/06, Alan Horkan <horkana@...44...> wrote:
Yes definately. In ten years time that link might break, especially since it links to index.php instead of the relevant directory. Odds are it will break far sooner than that - and who knows what it could get changed to - but once there are Inkscape binaries out there in the wild there will be nothing we can do about it.
Sure, linking to inkscape.org should be preferred, but ten years? I can't imagine anyone will use Inkscape 0.45 in 2016.
For something like command line arguements it might be better to programatically show exactly what arguements are available in the version the user actually has.
You can do that by running inkscape --help. But that information is brief and not detailed.
I would be concerend that Command line arguments should not be needed by most users
They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly.
- if many people are using them then batch features of the GUI
would need to be improved.
No, the GUI use and the command line use are quite orthogonal. Both are being improved but they will never converge or replace one another.
The man page or running inkscape --help are the standard places to find command line help, a menu item would be relatively unusual.
It is relatively unusual for a GUI drawing app to have command line operations at all. None of the commercial ones have them AFAIK. Therefore it is justified to mention them in the GUI because otherwise many people (that might benefit from them) will never even think to look for them.
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
Yep, by making that a redirect.
- Release notes for the current version
Personally I wouldn't consider this as something users would read frequently (more than once even?) and therefore not worth having a menu item.
On the contrary, for many users who are already familiar with the program, it's the most important information in the entire menu. And given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
Good idea in principle, problematic in practice = bug or feature request? (Mostly a menu item will give you feature requests.)
Real bugs need detailed feedback like stack traces and integration with bug-buddy or similar tools is more likely to result in the kind of high quality feedback you really want.
Sure, so it links to inkscape.org/report_bugs.php which explains all that.
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape.
Who says that?
Is this really useful to artists?
We have an XML editor in the interface, and this documentation is necessary if only to make sense of what it displays. Surely it's uncommon for a commercial app to link a complete documentation of its file format right in Help, but I don't think we should neglect this opportunity to be better than them. We take pride in using a completely open and standardized format, and we encourage editing SVG both by hand or by other tools in addition to Inkscape - so this menu item is quite relevant.
Also which specification do you link to, there are plenty of variations to choose from and I do think this would be much better served by writing up a page in the documentation.
We use a subset of 1.1, which is why 1.1 is linked. But when we have other profiles such as Tiny, we will make a submenu as Jon Phillips suggested and provide specs for each SVG variety we can handle.
I would urge restraint since I've seen so many crappy programs with links that no longer point to anywhere useful but it is certainly tempting to include a link to OpenClipart.org at least until OpenClipart.org is integrated with inkscape in some other way.
By the way, can anyone update me on the current status and plans of openclipart? Will it have a voting system, user-editable keywords, multiple categories - and if so when?
On Wed, 2006-10-11 at 14:56 -0300, bulia byak wrote:
On 10/11/06, Alan Horkan <horkana@...44...> wrote:
Yes definately. In ten years time that link might break, especially since it links to index.php instead of the relevant directory. Odds are it will break far sooner than that - and who knows what it could get changed to - but once there are Inkscape binaries out there in the wild there will be nothing we can do about it.
Sure, linking to inkscape.org should be preferred, but ten years? I can't imagine anyone will use Inkscape 0.45 in 2016.
And, we will have flying cars ;) By 2016 we will be using 0.54, right? hahahaha
For something like command line arguements it might be better to programatically show exactly what arguements are available in the version the user actually has.
You can do that by running inkscape --help. But that information is brief and not detailed.
I would be concerend that Command line arguments should not be needed by most users
They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly.
I agree. We could even have an advanced submenu if that is better...really, is it not more helpful to have more help rathr than less! It is about organization IMO and Bulia's awesome addition really cracks this one open IMO.
- if many people are using them then batch features of the GUI
would need to be improved.
No, the GUI use and the command line use are quite orthogonal. Both are being improved but they will never converge or replace one another.
The man page or running inkscape --help are the standard places to find command line help, a menu item would be relatively unusual.
It is relatively unusual for a GUI drawing app to have command line operations at all. None of the commercial ones have them AFAIK. Therefore it is justified to mention them in the GUI because otherwise many people (that might benefit from them) will never even think to look for them.
Yeah, I totally agree. This is one area where Inkscape (GIMP) and others really really shine. At siggraph many production companies were into Inkscape and other open source apps because they could do mass amounts of work via batch scripts. Its really in our best interest to pimp these features.
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
Yep, by making that a redirect.
Yep, who is doing this? I think mod-rewrite is in order:
RewriteRule ^faq /wiki/FAQ [L,QSA]
Can someone add that please? I'm outta the loop on the new website...
- Release notes for the current version
Personally I wouldn't consider this as something users would read frequently (more than once even?) and therefore not worth having a menu item.
On the contrary, for many users who are already familiar with the program, it's the most important information in the entire menu. And given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
Agree.
Good idea in principle, problematic in practice = bug or feature request? (Mostly a menu item will give you feature requests.)
Real bugs need detailed feedback like stack traces and integration with bug-buddy or similar tools is more likely to result in the kind of high quality feedback you really want.
Sure, so it links to inkscape.org/report_bugs.php which explains all that.
Agree...
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape.
Who says that?
Is this really useful to artists?
Yep, I agree. I like how Bryce makes it a point that we really focus on developers. This is really key to getting more features in Inkscape...we have to make it easy for new developers to get involved. and this is really key to our philosophy. More features and developers means way more artists...
We have an XML editor in the interface, and this documentation is necessary if only to make sense of what it displays. Surely it's uncommon for a commercial app to link a complete documentation of its file format right in Help, but I don't think we should neglect this opportunity to be better than them. We take pride in using a completely open and standardized format, and we encourage editing SVG both by hand or by other tools in addition to Inkscape - so this menu item is quite relevant.
I totally think so as well. This is very very key! Plus, it will help us and others find compliance problems quicker (esp. if there are questions).
Also which specification do you link to, there are plenty of variations to choose from and I do think this would be much better served by writing up a page in the documentation.
We use a subset of 1.1, which is why 1.1 is linked. But when we have other profiles such as Tiny, we will make a submenu as Jon Phillips suggested and provide specs for each SVG variety we can handle.
I totally agree...this will set a new standard for apps IMO...and is another reason I think our pimped out help/about menu is going to be so great!
I would urge restraint since I've seen so many crappy programs with links that no longer point to anywhere useful but it is certainly tempting to include a link to OpenClipart.org at least until OpenClipart.org is integrated with inkscape in some other way.
By the way, can anyone update me on the current status and plans of openclipart? Will it have a voting system, user-editable keywords, multiple categories - and if so when?
Yes, http://openclipart.org/cchost is what we are moving too...it has all of these things. We need more developers to help us in the two remaning areas: thumbnails and moving over our old collection.
Otherwise, I have updated the old site so any uploads we get go into our new system now...so please link to http://openclipart.org
Awesome! I love how the simplest feature additions sometimes are the most r/evolutionary...bulia, awesome job on this feature, really!
Jon
On Wed, Oct 11, 2006 at 11:22:42AM -0700, Jon Phillips wrote:
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
Yep, by making that a redirect.
Yep, who is doing this? I think mod-rewrite is in order:
RewriteRule ^faq /wiki/FAQ [L,QSA]
Can someone add that please? I'm outta the loop on the new website...
Please put in a bug on this one; if no one else gets to it, I'll make sure it's done well before the release.
(Or if you'd like access on the machine to be able to do that, we can arrange this.)
Bryce
On Wed, 2006-10-11 at 18:53 -0700, Bryce Harrington wrote:
On Wed, Oct 11, 2006 at 11:22:42AM -0700, Jon Phillips wrote:
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
Yep, by making that a redirect.
Yep, who is doing this? I think mod-rewrite is in order:
RewriteRule ^faq /wiki/FAQ [L,QSA]
Can someone add that please? I'm outta the loop on the new website...
Please put in a bug on this one; if no one else gets to it, I'll make sure it's done well before the release.
(Or if you'd like access on the machine to be able to do that, we can arrange this.)
Bryce
Cool, I emailed you my pub. keys...I will add the rule...thanks for the loving Bryce nudge :) I'm on it...
Jon
On Wed, 2006-10-11 at 18:53 -0700, Bryce Harrington wrote:
On Wed, Oct 11, 2006 at 11:22:42AM -0700, Jon Phillips wrote:
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
Yep, by making that a redirect.
Yep, who is doing this? I think mod-rewrite is in order:
RewriteRule ^faq /wiki/FAQ [L,QSA]
Ok, I added this. Should I add anymore rewrite magic for shorter URLS?
Jon
<snip />
I see as something strange that the in fact really tavmjong appears in the help menu.
1. i still can see no licence on the pages 2. we have a wip in the repository.
i don't see any advantages in keeping up2date two different documentation that have *nearly* the same approach. I have several time introduce contributor to the user_manual branch so i have to know what the real status of it before continuing to tell people working on it, especially for translations.
cheers pygmee
On Wed, 11 Oct 2006, bulia byak wrote:
Date: Wed, 11 Oct 2006 14:56:18 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: more stuff in Help menu
On 10/11/06, Alan Horkan <horkana@...44...> wrote:
Yes definately. In ten years time that link might break, especially since it links to index.php instead of the relevant directory. Odds are it will break far sooner than that - and who knows what it could get changed to - but once there are Inkscape binaries out there in the wild there will be nothing we can do about it.
Sure, linking to inkscape.org should be preferred, but ten years?
Exagerrating to make a point, I know it was excessive but I hoped it wouldn't require further explanation.
I can't imagine anyone will use Inkscape 0.45 in 2016.
People are still using Windows NT 4 and Windows 98. It may not be a good idea but isn't too hard to imagine.
Keep in mind the time it takes things to get adopted by distributions (months for Red Hat, even longer for Debian stable) and then institutions such as schools which might only upgrade their software once a year or less.
That isn't really important though, we all see the merit in centralising links at inkscape.org
For something like command line arguements it might be better to programatically show exactly what arguements are available in the version the user actually has.
You can do that by running inkscape --help. But that information is brief and not detailed.
I'm not saying there shouldn't be a page in the user manual explaining it but that it might not be important enough to have a menu item, rather than having one menu item pointing to the manual or website.
I would be concerend that Command line arguments should not be needed by most users
They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly.
Might just mean the command line arguments are not very user friendly. Usability applies to command line applications as much as GUI applications (applies to quality APIs too, a case where the targer users are developers too, but again I digress).
- if many people are using them then batch features of the GUI
would need to be improved.
No, the GUI use and the command line use are quite orthogonal. Both are being improved but they will never converge or replace one another.
Perhaps I should have phrased that differently, there will always be a place for command line features because it allows inkscape to be pipelined together with many other command line utilities. However I dont think anyone would disagree that it might be useful if the user interface provided a way to achieve a batch task like exporting each layer of a document as a seperate image.
The man page or running inkscape --help are the standard places to find command line help, a menu item would be relatively unusual.
It is relatively unusual for a GUI drawing app to have command line operations at all. None of the commercial ones have them AFAIK.
I'm thinking more of other Open Source software which very often does include command line arguments, particulary for things like file format conversion but even then we might just have different ideas of 'unusual'.
Therefore it is justified to mention them in the GUI because otherwise many people (that might benefit from them) will never even think to look for them.
You cannot mention every useful feature directly in the user inteface certainly not in the level of detail I think this functionality would deserve which is why I think a page in the manual would be best. A page in the manual would provide room for the kind of detail people seem to want like including a short example and enough shell scripting to iterate through and process a large set of images.
- FAQ on wiki
Again I'd very strongly prefer to see a nice clean link pointing at inkscape.org/faq/
Yep, by making that a redirect.
- Release notes for the current version
Personally I wouldn't consider this as something users would read frequently (more than once even?) and therefore not worth having a menu item.
On the contrary, for many users who are already familiar with the program, it's the most important information in the entire menu.
I would think people (adminstrators?) would read the release notes before or while downloading the new version. The Changelog and News files provide even more information.
given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
It is great that the release notes are of such high quality and provide good descriptions but shouldn't this information really be in the manual and tutorials?
Good idea in principle, problematic in practice = bug or feature request? (Mostly a menu item will give you feature requests.)
Real bugs need detailed feedback like stack traces and integration with bug-buddy or similar tools is more likely to result in the kind of high quality feedback you really want.
Sure, so it links to inkscape.org/report_bugs.php which explains all that.
Okay, make sense. Attempting to raise the quality of user feedback is another seperate question.
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape.
Who says that?
Who are the target users of Inkscape? Nailing that down would avoid confusion and help people focus on serving those users and make decision making easier when tradeoffs must be made.
Artists are one target group right?
Bryce has said before "contributors" are possibly the most important group. The tendency then is to think of contributors in the narrow sense of developers contributing code and Inkscape becomes increasing about techincal drawing. It is much harder to make things easier than to just make them possible.
Other projects tend to talks of their archetypal users or strive for software so easy Aunt Tillie could use it. I tend to think an appropriate archetype for Inkscape non-technical artist, intelligent people with the obvious skill and talent to create beautiful imagery but not necessarily adept at computers or particularly interested in techincal details.
Maybe the artist is not the primary user but with a better impression of who the targer users are then I will be able to make more appropraite suggestions, and perhaps not place so much importance on that type of user.
I know all this frequent criticism is not ideal but it is about as close as I can get to providing iterative usability analysis. Much as I might love to have experts and testing on large samplings of live users I'm doing to the best I can to keep Inkscape on track but the problem is the track isn't particularly clear.
Is this really useful to artists?
[XML editor, useful to understand the SVG source ... link to file format specs]
Surely it's uncommon for a commercial app to link a complete documentation of its file format right in Help, but I don't think we should neglect this opportunity to be better than them.
so this menu item is quite relevant.
Okay, I've stated my opinion but you do still think it is worth showing it prominantly in the menus. A link to the specification is still probably too technical and less use for the purpose you stated than a short entry in the manual explaining the basics of XML and SVG tags, and has the added advantage of not requiring net access - for those travelling and playing with inkscape on the train or on a plane for example.
Make it a link to inkscape.org that points to the specification and can be easily updated to something better should it exist then I guess I would have no excuse but to create something better. Then again linking to a page in the documentation avoid relying on an internet connection.
It makes a huge difference is you stated the underlying purpose behind the link which makes it possible to come up with better solutions.
I would urge restraint since I've seen so many crappy programs with links that no longer point to anywhere useful but it is certainly tempting to include a link to OpenClipart.org at least until OpenClipart.org is integrated with inkscape in some other way.
I'll attempt to summarize (okay more like rephrase) my points, menu items are prominant highly visible indicators to users of useful functionality but the more things you give menu items the more you reduce the clarity and usability of the other menu items. (Inkscape has what, ten types of Paste?) Links are great if you have an internet connection, but if you dont the time wasted by firing up a web browser to nowhere can be very slow and annoying.
Anyway it will be excellent to have links in the menus, and a clever use of python. Great idea bulia.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On 10/11/06, Alan Horkan <horkana@...44...> wrote:
I'm not saying there shouldn't be a page in the user manual explaining it but that it might not be important enough to have a menu item, rather than having one menu item pointing to the manual or website.
Perhaps in 1.0, it will be incorporated into the manual. But for now I think it's worthwhile to push it a bit more aggressively.
Might just mean the command line arguments are not very user friendly.
Yeah, and that is exactly the way to make them more friendly... or at least discoverable :)
together with many other command line utilities. However I dont think anyone would disagree that it might be useful if the user interface provided a way to achieve a batch task like exporting each layer of a document as a seperate image.
Yes, I agree. An extension might handle that.
On the contrary, for many users who are already familiar with the program, it's the most important information in the entire menu.
I would think people (adminstrators?) would read the release notes before or while downloading the new version. The Changelog and News files provide even more information.
The Changelog has been abandoned, and the NEWS file is actually a copy of the Release Notes.
It is great that the release notes are of such high quality and provide good descriptions but shouldn't this information really be in the manual and tutorials?
Developers are not interested - and should not be forced - to update the manual once they add a new feature. Manual is a very different kind of writing, differently structured and with a different requirements. A developer has the obligation to describe exactly what features he has added to the program, completely and detailedly, nothing more nothing less. A manual is a wrong place for this information; the Release Notes are the correct intended place. Later, the manual author(s) would update the manual based on the Release Notes, by placing it in a proper place, rewriting for easier understanding, adding examples etc.
Links are great if you have an internet connection, but if you dont the time wasted by firing up a web browser to nowhere can be very slow and annoying.
Yes, some of the things can be shipped with the program - such as the man page and rel notes in HTML. But for the manual, I don't think we have the permission from the author to do that. And the SVG spec is too big to be included.
Alan Horkan wrote:
Who are the target users of Inkscape? Nailing that down would avoid confusion and help people focus on serving those users and make decision making easier when tradeoffs must be made.
I think that the target can be summed up quite easily... anyone and everyone.
The userbase has done so many things with Inkscape that I think we can't really say we have a "target"... people use inkscape to create all kinds of things from logos, marketing materials, websites, artwork, comics, maps, crime scene plotting (remember that guy?), clothing, banners, posters, technical diagrams, charts, basic blueprints, cards, invitations, etc.
Effectively, we want to create something that is for everyone. A tool that is simple yet powerful. In my experience, Inkscape really has the feel of what I believe to be the true spirit behind open source... "the sky is the limit" style collaboration and open-mindedness.
-Josh
On Wed, 11 Oct 2006, Joshua A. Andler wrote:
Date: Wed, 11 Oct 2006 14:06:24 -0700 From: Joshua A. Andler <joshua@...533...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: more stuff in Help menu
Alan Horkan wrote:
Who are the target users of Inkscape? Nailing that down would avoid confusion and help people focus on serving those users and make decision making easier when tradeoffs must be made.
I think that the target can be summed up quite easily... anyone and everyone.
Yes sure, but that is quite different from what I'm talking about. There are subgroups within "everyone".
As you yourself listed there are people who can be grouped by the tasks they are trying to achieve. For example it might eventually make sense to gather a set of extension and a custom version of inkscape for technical drawing and crimes scenes (kind of like visio) which would highlight some functionality and demphasise others. It might make sense to have a version tailored to comic books, or other versions tailored to different tasks etc. It is a fairly standard idea in usability and design to try and pin down who your users are as it helps you prioritise what to work on first even if you would like to work on everything straight away.
Knowing the audience and knowing the tasks people are trying to achieve helps give developers targets and also makes it easier for users to choose the right tools for them and the task they are trying to achieve.
On Wed, Oct 11, 2006 at 11:02:21PM +0100, Alan Horkan wrote:
On Wed, 11 Oct 2006, Joshua A. Andler wrote:
Who are the target users of Inkscape? Nailing that down would avoid confusion and help people focus on serving those users and make decision making easier when tradeoffs must be made.
I think that the target can be summed up quite easily... anyone and everyone.
Yes sure, but that is quite different from what I'm talking about. There are subgroups within "everyone".
As you yourself listed there are people who can be grouped by the tasks they are trying to achieve. For example it might eventually make sense to gather a set of extension and a custom version of inkscape for technical drawing and crimes scenes (kind of like visio) which would highlight some functionality and demphasise others. It might make sense to have a version tailored to comic books, or other versions tailored to different tasks etc. It is a fairly standard idea in usability and design to try and pin down who your users are as it helps you prioritise what to work on first even if you would like to work on everything straight away.
I don't know; I can certainly see how this is a valuable approach for a commercial product, where you have developers that don't really understand what the product needs to do, and need to set up strawmen and use cases in order to understand what to code.
However, particularly in Inkscape, defining a "target user" may not even be necessary; Open Source developers tend to be heavy users of the software and thus have an inherent knowledge of what priorities and usability issues need worked on.
In fact, despite having a roadmap, each developer actually has his own set of priorities and motivations. In fact, the roadmap really ought to be thought of more as a 'forecast'. Developers should be free to work on what they each feel are the most important priorities; for tasks that involve multiple people, the roadmap is useful as a way of documenting their present concensus on what should be worked on when, but shouldn't be taken as written in stone or anything.
Regarding target users, Josh is right - Inkscape does not have a single target user, but more of a range, and a highly organic range at that. As users make contributions that open the tool to new classes of users, our target userbase makeup will shift. (And since the shift will be driven by the desires of the contributors, we again see a strong correlation with the desires of contributors, and thus again reach the observation that Inkscape's target audience can be defined by its contributors.)
Indeed, you could even argue that Inkscape's target audience are people that find Inkscape of only borderline usefulness to them; these people are the ones most likely to get irritated enough to contribute, and thereby open Inkscape up to that whole market. If you follow this particular line of reasoning, you actually arrive at a conclusion that many of the links Bulia added (spec, faq, release notes, etc.) are extremely important, since those are the exact thing these users will need in order to make the contributions necessary to open Inkscape to those audiences.
I think another reason I dislike the idea of defining "target users" is that it facilitates the mentality that users and developers are two separate groups, and that users exist to define requirements for the developers to implement. That is the WRONG MODEL for us; it's the commercial software product model. In the open source model, users are empowered - indeed, customers/users/consumers have *HUGE* power in this model, moreso than they've ever had for thousands of years; yet taking advantage of this requires that they *GET INVOLVED* - users realize their power through contributing, and those who do not participate won't be empowered. Thus for the user's own sake we need to take every advantage of getting them to stop thinking in terms of user vs. developer, and more thinking in terms of contributor vs. non-contributor, and make them realize that in this model it is the contributors who are going to be the big winners.
Today I just sat through a whole series of talks at OSDL's member company conference. A bunch of end user companies/governments spoke about their FOSS adoption and the question came up if they ever contributed back. EVERY ONE of them not only said they contributed back, but that they viewed the ability to contribute back as one of the big advantages to using FOSS.
Bryce
On Wed, 11 Oct 2006, Bryce Harrington wrote:
I don't know; I can certainly see how this is a valuable approach for a commercial product, where you have developers that don't really understand what the product needs to do, and need to set up strawmen and use cases in order to understand what to code.
I admire your optimism. Inkscape does have some useful contraints already, the SVG specification in particular helps set that up, and somewhat implies a Web audience (macromedia were always more web than adobe with their history in the print industry).
The idea of target users is complimentary to ideas like a Roadmap, which you dont strictly need but it helps people row in the same direction. The idea is more a way of clarifying the unspoken understandings developers already have, and that kind of information can make it easier for new developers to get on board. There are so many ideas that current developers know implictly but cannot pin down exactly that would take a while for someone new to the project to get the hang of
One of the things the idea of targer user helps with is knowing when something is easy enough. I'd use tile clones as an example of something that works but is too difficult for beginners but I think previous discussions already discovered lots of people found it difficult to use (and tutorials will certianly help but again a different question). It can also help with decisions with terminolgy and what level to pitch things at, or even accepting that Inkscape is not going to be suitable for someone who doesn't already know a bit about SVG or the difference between vector and raster graphics. (I'm reaching for examples, please forgive that they aren't great examples.)
I think another reason I dislike the idea of defining "target users" is that it facilitates the mentality that users and developers are two separate groups, and that users exist to define requirements for the developers to implement.
"requirements" is the wrong model, but being able to say Inkscape isn't aimed at kids does set a useful limit and gives groups such as OLPC a blessing to take the codebase in another direction rather than trying to turn Inkscape into something the developers know it is not well suited to.
(In reality the target users of OLPC have already resulted in strict technical requirements which means they have been encouraged to branch from the pre C++ versions of Inkscape but again I'm trying to find examples in terms of users and tasks.)
advantage of this requires that they *GET INVOLVED* - users realize their power through contributing, and those who do not participate won't be empowered.
As a user I like applications to look a certain way, the GNOME HIG gives me a much clearer way to express that. A better understanding of who the target inkscape users are also helps me contribute by letting me know the right path and not spend excessive time trying to make inappropiate suggestions or at least prioritise certain things to focus on.
company conference. A bunch of end user companies/governments spoke about their FOSS adoption and the question came up if they ever contributed back. EVERY ONE of them not only said they contributed back, but that they viewed the ability to contribute back as one of the big advantages to using FOSS.
They might have assumed that contributed back meant more than filing bugs and feature requests but your point is well taken, and I guess every release should hammer home that Inkscape is looking for new contributors.
having a few parallel projects - like the summer of code proposals - and a few developers dubbed as mentors might help in that regard, quite a few projects seem to be capitalising on the methodology used during the Google summer of code to draw in more contributors beyond those who got paid sponsorship.
(Getting very very sleepy, goodnight...)
On Oct 11, 2006, at 9:29 PM, Alan Horkan wrote:
As a user I like applications to look a certain way, the GNOME HIG gives me a much clearer way to express that. A better understanding of who the target inkscape users are also helps me contribute by letting me know the right path and not spend excessive time trying to make inappropiate suggestions or at least prioritise certain things to focus on.
Remember, while the GNOME HIG says how users should expect GNOME desktop apps to work. Inkscape, on the other hand, works on GNOME, KDE, Windows, Mac OS X...
Their HIG is decent, but not perfect. Also it changes over time (remember that Inkscape's toolbars predate GNOME's). Inkscape's stated goal is to be the best SVG editor, not "the best GNOME SVG editor".
Remember, some of the points from the GNOME HIG are in direct conflict with the Windows UI guidelines, and have even been pointed out as bad things about GNOME apps on Windows.
On Wed, Oct 11, 2006 at 08:50:26PM +0100, Alan Horkan wrote:
I would be concerend that Command line arguments should not be needed by most users
They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly.
Might just mean the command line arguments are not very user friendly.
Oh please. Are you arguing just for argument's sake? ;-)
- if many people are using them then batch features of the GUI
would need to be improved.
No, the GUI use and the command line use are quite orthogonal. Both are being improved but they will never converge or replace one another.
Perhaps I should have phrased that differently, there will always be a place for command line features because it allows inkscape to be pipelined together with many other command line utilities. However I dont think anyone would disagree that it might be useful if the user interface provided a way to achieve a batch task like exporting each layer of a document as a seperate image.
Given this comment, I can tell you don't have strong insight into what people running inkscape from the commandline are using it for. Many of the people whom I've spoken to that are using it in this fashion are doing so in a web environment. There is no X server, and thus a GUI batch function would be inadequate.
I think you may be conflating these issues with scripting, which is yet another (quite separate) use case, and takes the discussion too far afield to address further.
- Release notes for the current version
I would think people (adminstrators?) would read the release notes before or while downloading the new version. The Changelog and News files provide even more information.
You probably missed that the developers decided to cease maintaining a Changelog, and evidently have missed that the NEWS file and the Release Notes are one and the same.
given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
It is great that the release notes are of such high quality and provide good descriptions but shouldn't this information really be in the manual and tutorials?
It is. I don't think you understand the way documentation works with Inkscape.
Inkscape actually has one of the best documentation writing flows that I've seen in open source projects. Traditionally, developers are very resistive of writing documentation, and documenters are very resistive of "just read the source code", so as a consequence many FOSS projects suffer along with little or no docs at all.
The workflow in the Inkscape project has discovered a comfortable compromise. We impose the (modest) requirement to developers that when they add a feature, they add a bullet point or two about it to the release notes. They aren't obligated to write a tutorial or update a manual or anything major, just a few sentences. Sometimes someone else even does it for them.
In return, documenters can use those comments as a springboard from which to create more extensive, proper documentation and tutorials. In a way, because the developers *don't* take responsibility for writing the docs themselves, this has opened a great niche for writers to fill, and we've all benefitted greatly as a result.
The Release Notes are a crucial piece of this workflow, and its importance cannot be underemphasized. They are the authoritative source of knowledge about the program, and well worth being included in the help menu.
They also provide a very useful brief "what's changed" list. It is possible some may read this when they download and install inkscape, many people get Inkscape via CD's or distro upgrades or myriad other mechanisms where they won't be exposed to any release documentation. And even if they did, they may wish to easily refer back to it later. Having it in the help menu is a smart solution to a wide range of usage models.
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape.
Who says that?
Who are the target users of Inkscape? Nailing that down would avoid confusion and help people focus on serving those users and make decision making easier when tradeoffs must be made.
Artists are one target group right?
Bryce has said before "contributors" are possibly the most important group. The tendency then is to think of contributors in the narrow sense of developers contributing code and Inkscape becomes increasing about techincal drawing. It is much harder to make things easier than to just make them possible.
Hold on there. If you re-read any of my screeds where I speak of the value of contributors, I ALWAYS follow with a long dissertation about how contributions come in many forms, and that even non-coders can bring extensive benefit to Inkscape through translation, documentation, PR, and so on.
You're also making a jump that programmers only care about technical drawing features. Boy I wish that were true. ;-) The evidence in Inkscape shows that random external code contributors care about a huge range of features, especially including artistic features.
Much as I might love to have experts and testing on large samplings of live users...
Alan, this can be done quite readily through listening to the users who are posting questions on mail and irc. ;-)
(Seriously, I recall you had done this approach a few times in the past, and your well researched information was fairly convincing.)
Bryce
On Wed, 11 Oct 2006, Bryce Harrington wrote:
Date: Wed, 11 Oct 2006 19:26:30 -0700 From: Bryce Harrington <bryce@...961...> To: Alan Horkan <horkana@...44...> Cc: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: more stuff in Help menu
On Wed, Oct 11, 2006 at 08:50:26PM +0100, Alan Horkan wrote:
I would be concerend that Command line arguments should not be needed by most users
They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly.
Might just mean the command line arguments are not very user friendly.
Oh please. Are you arguing just for argument's sake? ;-)
I was almost done with the discussion but I cannot let that go. Usability applies to command line argument as much as anything else, some are better than others, as I said compare how easy it is to convert using imagemagick versus the gimp.
- if many people are using them then batch features of the GUI
would need to be improved.
No, the GUI use and the command line use are quite orthogonal. Both are being improved but they will never converge or replace one another.
Perhaps I should have phrased that differently, there will always be a place for command line features because it allows inkscape to be pipelined together with many other command line utilities. However I dont think anyone would disagree that it might be useful if the user interface provided a way to achieve a batch task like exporting each layer of a document as a seperate image.
Given this comment, I can tell you don't have strong insight into what people running inkscape from the commandline are using it for. Many of the people whom I've spoken to that are using it in this fashion are doing so in a web environment. There is no X server, and thus a GUI batch function would be inadequate.
Again I didn't deny there was a place for command line arguments but that there were cases were some might say use the command line instead of makign the user interface easier for batch tasks. There is certainly room for both, but some users will never want to use the command line if they can avoid it (not much of a GUI app if they haven't any choice).
In fact if running inkscape headless is a frequent use case you might want to look at the "server mode" command line options for abiword. Essentially it keeps abiword open for repeated commands rather than requiring a new copy of the application be run each time you want to do a conversion or some other back office task.
I understand this use case better than you think ;P
I think you may be conflating these issues with scripting, which is yet another (quite separate) use case, and takes the discussion too far afield to address further.
The areas overlap and scripting is another way of exposing the same underlying functionality but I hope you have a better idea of what I was getting at.
- Release notes for the current version
I would think people (adminstrators?) would read the release notes before or while downloading the new version. The Changelog and News files provide even more information.
You probably missed that the developers decided to cease maintaining a Changelog, and evidently have missed that the NEWS file and the Release Notes are one and the same.
(bulia already replied saying the same thing. this is all getting quite confusing, apologies if I'm repeating myself but I've entirely lost the order of this discussion)
given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
It is great that the release notes are of such high quality and provide good descriptions but shouldn't this information really be in the manual and tutorials?
It is. I don't think you understand the way documentation works with Inkscape.
(again in the other message I accept the differnce between the ideal and the practical, the information is provided and expecting it to be further processed into detailed documentation is impractical and expecting too much)
Inkscape actually has one of the best documentation writing flows that I've seen in open source projects.
Inkscape has its own way of doing things and has produced an excellent collection of useful information, especially the tutorials and it is certainly better than what many other project provide.
Traditionally, developers are very resistive of writing documentation, and documenters are very resistive of "just read the source code", so as a consequence many FOSS projects suffer along with little or no docs at all.
I thank $deity inkscape is better than that but ...
In return, documenters can use those comments as a springboard from which to create more extensive, proper documentation and tutorials.
... as with the other suggestions i was just suggesting there was an underlying problem to be solved and ideal we were aiming at such as nice tutorials but that release notes are the reasonable practical solution.
In a way, because the developers *don't* take responsibility for writing the docs themselves, this has opened a great niche for writers to fill, and we've all benefitted greatly as a result.
Intersting way to look at it, I think it is bit much to claim there is particularly a niche create for writers to fill but ...
The Release Notes are a crucial piece of this workflow, and its importance cannot be underemphasized. They are the authoritative source of knowledge about the program, and well worth being included in the help menu.
... that inkscape has set things up in such a way that developers do provide good "documentation" in the form of release notes which makes the task of writing documentation much easier for the many enthusiastic contributors.
Bryce has said before "contributors" are possibly the most important group. The tendency then is to think of contributors in the narrow sense of developers contributing code and Inkscape becomes increasing about techincal drawing. It is much harder to make things easier than to just make them possible.
Hold on there. If you re-read any of my screeds where I speak of the value of contributors, I ALWAYS follow with a long dissertation about how contributions come in many forms, and that even non-coders can bring extensive benefit to Inkscape through translation, documentation, PR, and so on.
Sorry if that sounded like I was taking a jab at you Bryce, you always follow through those ideas and carefully balance them.
You're also making a jump that programmers only care about technical drawing features. Boy I wish that were true. ;-) The evidence in Inkscape shows that random external code contributors care about a huge range of features, especially including artistic features.
I still do think there is a bais, maybe I consider things techincal drawing that others do not but there are plenty of requests for AutoCAD like tools, measurment, plotting and mathematical tools other features that an artist could certainly make use of but I think are more technical drawing features.
Much as I might love to have experts and testing on large samplings of live users...
Alan, this can be done quite readily through listening to the users who are posting questions on mail and irc. ;-)
You missed the iterative usability part the other bit was somewhat spurious ;P
(Seriously, I recall you had done this approach a few times in the past, and your well researched information was fairly convincing.)
Trawling through the request tracker does tend to show things recurring but in terms of usability I should probably sit down again and review HIG complaince, especially since I missed a few really obvious things like the lack of any close button at the bottom of the Preference dialog.
There is an issue of with the "clones" terminlogy I really should bring up but I'm postponing that indefinately because I know it is going to be a pain to change it, or at least until I gather lots more evidence about why it really is a problem.
On Wed, Oct 11, 2006 at 02:56:18PM -0300, bulia byak wrote:
The man page or running inkscape --help are the standard places to find command line help, a menu item would be relatively unusual.
It is relatively unusual for a GUI drawing app to have command line operations at all. None of the commercial ones have them AFAIK. Therefore it is justified to mention them in the GUI because otherwise many people (that might benefit from them) will never even think to look for them.
...or will pop on IRC asking where to find docs. We've found that there is a non-trivial category of windows users who want to use inkscape in commandline mode, yet who cannot run man inkscape or inkscape --help (and who do not find the online manpage on our website.) Having the cmdline args defined in the help menu will be much more likely to clue them in.
As well, there are many who - like bulia says - won't realize inkscape can be used from the commandline, and so may entirely miss that category of features.
- Release notes for the current version
Personally I wouldn't consider this as something users would read frequently (more than once even?) and therefore not worth having a menu item.
On the contrary, for many users who are already familiar with the program, it's the most important information in the entire menu. And given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
Also keep in mind that this is the definitive location for telling users about "known bugs & workarounds". Having this linked to from the application itself is a very good move.
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape.
Who says that?
Inkscape's defined mission is to be the best SVG editor. I don't know if it's going to be a terribly useful link for the average user, but it certainly is within scope of our target audience. I suppose there's a risk that its presence will make people think that Inkscape should support 100% of the features listed there, but I expect most people will simply ignore it. ;-)
Also which specification do you link to, there are plenty of variations to choose from and I do think this would be much better served by writing up a page in the documentation.
We use a subset of 1.1, which is why 1.1 is linked. But when we have other profiles such as Tiny, we will make a submenu as Jon Phillips suggested and provide specs for each SVG variety we can handle.
This is definitely a good idea.
Bryce
On Wed, 11 Oct 2006, Bryce Harrington wrote:
Date: Wed, 11 Oct 2006 18:51:18 -0700 From: Bryce Harrington <bryce@...961...> To: bulia byak <buliabyak@...400...> Cc: Alan Horkan <horkana@...44...>, Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: more stuff in Help menu
On Wed, Oct 11, 2006 at 02:56:18PM -0300, bulia byak wrote:
The man page or running inkscape --help are the standard places to find command line help, a menu item would be relatively unusual.
It is relatively unusual for a GUI drawing app to have command line operations at all. None of the commercial ones have them AFAIK. Therefore it is justified to mention them in the GUI because otherwise many people (that might benefit from them) will never even think to look for them.
...or will pop on IRC asking where to find docs.
We've found that there is a non-trivial category of windows users who want to use inkscape in commandline mode, yet who cannot run man inkscape or inkscape --help
Cannot? I accept the discoverability point and I fully endorse having a section in the manual/documentation[1], I was only making the point that a menu item would be excessive (cant have a menu item for everything).
I understand that users might not think to find out about command line arguments but I'm puzzled if there is some technical difficulty preventing windows users from running: inkscape --help
I tried it myself and thought it was some anomoly and perhaps I was doing something wrong. Presumbly there is a bug that needs fixing or some underlying technical problem, which would be an entirely seperate and more fundamental problem.
- Release notes for the current version
Personally I wouldn't consider this as something users would read frequently (more than once even?) and therefore not worth having a menu item.
On the contrary, for many users who are already familiar with the program, it's the most important information in the entire menu. And given the amount of new features in our versions, and their detailed descriptions in the release notes, this menu item will certainly be consulted more than once.
Also keep in mind that this is the definitive location for telling users about "known bugs & workarounds". Having this linked to from the application itself is a very good move.
Okay, in an ideal world we would have a team of documentation writers who would make sure this was all written up nicely in a user friendly way. For practical reasons we are saving a lot of work and directing users straight to the Release notes such as they are.
http://inkscape.org/report_bugs.php
Note the Report Bugs page neither warns people to read the release notes to find out more about known busg and workarounds nor does it warn users that what they might consider a bug is what Inkscape categorises as a request. If there is going to be a menu item directing to the page it is even more important to manage expectations and avoid users getting annoyed when their "bugs" get demoted to the level of feature requests (users really don't like this but they live with it, so being nice and polite helps).
Again there are implicit problems to be solved and adding these links will address part of the problem but by clarifying the problems you are aiming to solve other complementary solutions may present themselves so I hope everyone sees the value in discussing the underlying issues here.
- SVG 1.1 specification at w3.org
Artists are the target users of Inkscape.
Who says that?
Inkscape's defined mission is to be the best SVG editor.
That defines "what" or perhaps "how" but the question of "who" isn't entirely clear.
I don't know if it's going to be a terribly useful link for the average user, but it certainly is within scope of our target audience. I suppose there's a risk that its presence will make people think that Inkscape should support 100% of the features listed there, but I expect most people will simply ignore it. ;-)
A feature you expect most users to ignore ... :(
Okay so this is mostly harmless but I'd hate to see inkscape have features most users were expected to ignore. Before you know it we'll have an installer asking lots of unanswerable questions the first time you run it and you'll think it is perfectly acceptable because most users will just ignore it. Deja vu all over again. ;)
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
[1] I tend to think of Tavmjongs "A Guide to Inkscape" http://tavmjong.free.fr/INKSCAPE/ as the Inkscape book rather than a manual per se. Since the inkscape book cannot be shipped with inkscape people might be inspired to craft a manual, but currently the tutorials are so good and the book is available online there is no real pressure to produce a more conventional boring manual.
On Thu, Oct 12, 2006 at 03:25:56AM +0100, Alan Horkan wrote:
http://inkscape.org/report_bugs.php
Note the Report Bugs page neither warns people to read the release notes to find out more about known busg and workarounds nor does it warn users that what they might consider a bug is what Inkscape categorises as a request. If there is going to be a menu item directing to the page it is even more important to manage expectations and avoid users getting annoyed when their "bugs" get demoted to the level of feature requests (users really don't like this but they live with it, so being nice and polite helps).
You're likely right that it needs updating. Could you please take what's there and wordsmith it into something better. If you don't want to bother fussing with the HTML, just put the text into a bug report and assign to me, and I'll try to get it updated prior to the release. Or if you're okay with doing HTML, please feel free to work directly in the crucible_web module, which will allow the page to be updated sooner.
Bryce
Looking at the new web links/online content in the Help menu but there is no way to tell which are web links and which are not. Firing up python then starting the browser and then loading the page can be awfully slow, especially compared to how fast an inkscape dialog or even the large tutorials load.
Icons in the menus to help disambiguate the web links would really help or perhaps you would consider grouping the web links between two seperators or since there are more than a few links they could be grouped in a submenu like the tutorials?
Also acronyms dont translate well (at all) so FAQ needs to be expanded to Frequently Asked Questions or labelled in some other way.
Sincerely
Alan Horkan http://alanhorkan.livejournal.com
- Inkscape Manual links to
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
The direct link is nice... but I think that a redirect is preferable. While I am committed to keeping the manual available at its current site, the domain name depends on my keeping Free as my Internet provider. I don't foresee a change but one never knows.
There are a couple of other issues to think about: One is matching manual version to Inkscape version. Another is handling translations of the manual. There are two translations in progress (French & Dutch).
Tav
On Thu, 12 Oct 2006, Tavmjong Bah wrote:
Date: Thu, 12 Oct 2006 22:15:41 +0200 From: Tavmjong Bah <tavmjong@...8...> To: bulia byak <buliabyak@...400...> Cc: Inkscape Development Mailing List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] NEW: more stuff in Help menu
- Inkscape Manual links to
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/index.php, do you think we should host a redirect at inkscape.org instead?
The direct link is nice... but I think that a redirect is preferable.
I hope it isn't necessary to say so but out of respect I say it anway, requiring a redirect is in no way intended as an insult or any kind of question of your integrity. You have done great work documenting inkscape and I think we are all very grateful for that.
It just makes sense to have a redirect, much as we respect you there is the possibility of events beyond your control that may occur and it is easy enough to plan ahead and avoid any potential problems.
site, the domain name depends on my keeping Free as my Internet provider. I don't foresee a change but one never knows.
Again thanks for your work.
participants (10)
-
Aaron and Sarah Spike -
Alan Horkan -
Bryce Harrington -
bulia byak -
cedric GEMY -
Jon A. Cruz -
Jon Phillips -
Joshua A. Andler -
Tavmjong Bah -
Ted Gould