On Mon, Oct 09, 2006 at 05:16:16PM -0700, Jon Phillips wrote: 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

On 10/9/06, Aaron and Sarah Spike <spike@...749...> wrote: 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. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

Cool, you may also have a look at the user_manual branch and see if it can be added as help. pygmee

On 10/11/06, Alan Horkan <horkana@...44...> wrote: Sure, linking to inkscape.org should be preferred, but ten years? I can't imagine anyone will use Inkscape 0.45 in 2016. You can do that by running inkscape --help. But that information is brief and not detailed. They are needed by some, that's enough. We get questions on how to use Inkscape in scripts regularly. 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. 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. Yep, by making that a redirect. 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. Sure, so it links to inkscape.org/report_bugs.php which explains all that. Who says that? 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. 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. 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? -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

On Wed, Oct 11, 2006 at 11:22:42AM -0700, Jon Phillips wrote: 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: Ok, I added this. Should I add anymore rewrite magic for shorter URLS? http://inkscape.org/faq http://inkscape.org/FAQ Jon <snip /> -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jon@...235... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: rejon@...896... IRC: rejon@...897...

On Wed, 11 Oct 2006, bulia byak wrote: Exagerrating to make a point, I know it was excessive but I hoped it wouldn't require further explanation. 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 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. 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). 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. 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'. 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. 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. 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? Okay, make sense. Attempting to raise the quality of user feedback is another seperate question. 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. [XML editor, useful to understand the SVG source ... link to file format specs] 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'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/

Alan Horkan wrote: 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, Oct 11, 2006 at 11:02:21PM +0100, Alan Horkan 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. 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 Oct 11, 2006, at 9:29 PM, Alan Horkan wrote: 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, 11 Oct 2006, Bryce Harrington wrote: 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. 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 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. (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) (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 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. I thank $deity inkscape is better than that but ... ... 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. 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 ... ... 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. Sorry if that sounded like I was taking a jab at you Bryce, you always follow through those ideas and carefully balance them. 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. You missed the iterative usability part the other bit was somewhat spurious ;P 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. -- Alan

On Wed, 11 Oct 2006, Bryce Harrington wrote: 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. 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. That defines "what" or perhaps "how" but the question of "who" isn't entirely clear. 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.

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

On Thu, 12 Oct 2006, Tavmjong Bah wrote: 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. Again thanks for your work. -- Alan