bulia byak wrote:
I still think this is wrong. Imagine you're learning some foreign language, say French. Would you want your French teacher to teach you phrases that sound funny to native French speakers? Of course not. On the contrary, you want to learn phrases and constructions that are idiomatic and natural for the target language.
You don't expect first year French students to learn perfect French by the end of the first class, either. Baby steps, man. Again, learning more about Inkscape's particular advantages is in's and out's is something they can do once they get their feet under them. What's important about Inkscape will stand out as important without so much pointing, I promise you. You're pushing too much on to them, expecting too much of them, and you are anticipating a stronger desire to learn Inkscape than the target audience is likely to have at first. You are talking like someone is very enthusiastic about something you're proud of and that you want to emphatically express how cool you think it is. I'm advocating giving the audience what they want, not what you (or we) may want. You can lead a horse to water...
I'm not arguing for a "sales speech", just for a concise and practical introduction which mentions the most important capabilities, _especially_ if they are different from those of AI.
No, a concise and practical document is what I'm pushing, and why I'm resisting having more added to it. You later say that it has to be longer (which goes against being concise) and the most practical approach is putting AI tasks in an Inkscape context at first and letting Inkscape reveal itself to the users at a pace the users can handle and want. You keep wanting to add Inkscape tasks in an Inkscape context. As of tonight (local graphic design meetup group) I've road tested this document with some actual AI users who haven't yet used Inkscape. Have you? Any feedback?
Currently it's just an embryo of a document. It needs to be much longer to be of any use. But we need to agree on the approaches before growing it further.
I emphatically object. The longer it is, the less it serves as a practical introduction to AI users. It's not an embryo, it's a stepping stone from where they will move on to other documents. You have to start looking at this like one page in a book, not the whole book.
Maybe you didn't author it, but you restored it when I deleted it.
We've covered this. I restored 'cause you hacked too much. Let's not keep rehashing. We're really a lot closer than all of this.
I would not mind the tone transgressions if they would not be accompanied by some factual inaccuracies and approaches which I consider wrong.
You consider them wrong approaches because you have a bias that comes from working closely on the project, and a lack of experience with AI. Please consider that this might be adversely influencing your decisions here, and that other people's approaches, like mine, might have some credibility in spite of the fact that they're different than yours. Developers rarely make good documenters.
As I said in the note, in this particular case it's not entirely subjective to say that the way that Inkscape presently handles node transformation is less responsive *in they eyes of AI users.*
"Less responsive" says nothing useful. It may mean anything. Please be specific: what exactly it can and cannot do. If you want an overall statement, you can add it, but please make it more to the point (e.g. "misses some important features", or "uses a one-tool approach", or "is less convenint in working with such-and-such use cases").
Well, as has been the consensus from the AI users who have registered their thoughts, to a man they have all said that Inkscape is less responsive when it comes to node editing and that the Pen tool is still young in Inkscape. So obviously it does have a meaning that's fairly well understood. But if you want to say "is less convenient" instead, then that would probably make sense too. I'll consider some revision in that phrasing if that paragraph says at all, which it might not, depending on developments.
if you want me to swap out "more responsive" with "more context sensitive" I'm willing to do that.
"More context sensitive" makes more sense, but please explain exactly what type of context is missing in Inkscape.
http://www.angelfire.com/mi/kevincharles/inkscape/aiwf.htm
I mean, here I am talking to you developers, and I don't know the first bit of C or C++. I own AI, the latest version, and I like it just fine. By your reckoning I shouldn't be here. But I've never been able to talk to an Adobe developer. So you see, there are reasons beyond simply features and capabilities for users to switch.
Fine, then why won't you mention "the ability to talk to a developer" among Inkscape's advantages in the document :)
Because that's a function of OSS, not a feature of this program. The section is very tightly constrained as a feature list, and in a "either it has it or it doesn't" sort of way at that.
I have only AI 9 and it has nothing in the way of clones at all, which is why I added a mention of it. By the way AI 9 isn't all that old. As for the features you mention, they will all be addressed eventually, some of them hopefully very soon.
AI 9 is two versions old. That's old regardless of how many years it's been. As features are added to Inkscape, then obviously this section can be revised. In the mean time it provides useful information to AI users.
A. Kwixson has removed my mention of keyboard accessibility, in particular keys for screen-pixel-sized transformations, claiming this is not important. I've seen this attitude before from other AI users; they tend to dismiss this because they don't have it. Those who are really using Inkscape (or Xara, where I got the idea from, though by now Inkscape's keyboard is superior even to Xara) will disagree.
Looks like the majority of replies here, including those from AI users, supports this point. So I think we need to restore this. It is important.
From what I saw of the responses, all of the reactions were based on your phrasing in the email and they hadn't read the Wiki page in question.
OK, I agree to put the "convert to path _if you need path_" advice first in that section. But my paragraph on shapes must remain, even if it comes second. Again, the consensus on the list seems to be in favor of explaining shapes.
I have a thought on this that might be a workable compromise. More later.
Yes, certainly.
So, can you please prepare a next version of this document, taking into account all the discussion in this thread (and removing our arguments from the wiki page)? Then we'll hopefully have input from more people. I promise not to delete lots of stuff without discussing it first :)
Okay, but I've already made it half way through a "one issue at a time" draft of resolving the remaining issues... I'm convinced that there are only three or four specific points of contention left, and the biggest one I was going to tackle first I really thing is contentious because you don't know AI that well. That's why I made the aiwf.htm page, and I'm planning on yet another explainer to demonstrate your technique and my technique side by side to let people see if what I'm saying makes sense or not. Let me finish that process and I'll put together a new version and I think we'll be pretty much done.
Okay.
Thanks, -Kevin