Documentation is also a really difficult thing... Not just because it's difficult to create good documentation, but also because it's difficult to _read_ documentation. The amount of queries I get on foundation@krita.org about things that are plain and well documented is astonishing. People don't read: they skim, their eyes glaze over and they assume that what they are looking for isn't there. And that isn't the fault of the documentation author, of the format, of the layout, the spelling or the illustrations.

It's perhaps a bit similar to what Bruce discusses here: http://www.datamation.com/applications/ ... -apps.html.

It's a matter of assumptions. On the one hand, the assumption that what you're looking for isn't there and therefore not seeing it, and on the other hand, the assumption that this is what you get, and that's it. So, I'd like to join Wolthera (who is also a Krita developer, in addition to all the other things mentioned above) in saying this:

Documentation is a community effort. You don't need anything special for it, you can just help out. That is, you do need something special: a certain amount of humility. The humility to help complete what's out there, instead of starting something new, the humility to make your contribution mesh with what already exists. The humility to check for what is missing and add that -- instead of redoing something that already exists but isn't to your taste. That's not different from coding in krita, actually... Fixing a bug helps, starting to port Krita to GTK-- doesn't. Same with the documentation!

Askinner, you already helped with updating the screenshots -- and that's awesome. But the nature of open source development is that it's either fast-paced, or dead. So it's always going to be an ongoing effort. One thing that _I_ pride myself on is that we really try to listen. So if there's a suggestion out there that will make Krita better, we'll try to implement it, even if it's radical. And that means that keeping the documentation up to date will always be a struggle. Books are going to be out-dated quickly, too, and still there's a book in Japanese, and books in French and English are coming. The author of the book in English has actually already said he found the community documenation essential when preparing his work...

In the end, the manual, the documenation we provide, that's, just like Krita, a community effort. Or it should be: Wolthera has shouldered a really large part of the effort and should be applauded for all the effort put into that! I think that the results of that effort are helping a lot of users find their way around Krita, and I invite everyone who finds gaps to help fill them.

Woltherea....you said

"But... considering you too have experience with technical writing? What would you think needs to be done to facilitate the manual writing? Because, sure, there's things like the colour management which only a few people really understand, but for each colour management page, there's a rectangle tool where people added constraint thingies at one point, and I would imagine someone could play with the constraint thingies and see what they could add to the manual for that?

Do you need a 'how to contribute to the manual page?' "

It's true that in my previous life as a development manager I was responsible for the creation, editing and maintenance of all internal and customer documentation. That being said, I'm afraid my experience is worlds apart from the fast-paced world that boudewijn describes. I managed through highly defined wiki-based style guides, distributed content creators but centralized editorial and publishing enforced consistency, etc... All the things that would be anathema to an open-source project like Krita. So I guess since I come from this disciplined world I've been reluctant to just "dive in" and start editing. But hey, I'm willing to try. Maybe some others will join in along the way....

I took a quick look at the wiki logs and you certainly have been hard at work Wolthera. Thanks for everything that you have done.

Hello Wolthera,
please don't let this get you down!
Of the ten thousand people using Krita so far very few are unhappy with the documentation and a hand full are unhappy enough to say something about it.
Most are very happy with Krita AND the documentation as it is.
With a growing userbase and growing visibility, you see more bugreports and more complaints.
But that is just because those who are happy are usually silent, or this forum would consist of 99% praise posts!
BTW, i think it is inspiring how you manage to be an artist, a student, a software developer and a documentation writer all at once!
Greetings
Arne

torpak wrote:Hello Wolthera,
please don't let this get you down!
Of the ten thousand people using Krita....

where did you get the 10,000 number from?

nharmony wrote:

torpak wrote:Hello Wolthera,
please don't let this get you down!
Of the ten thousand people using Krita....

where did you get the 10,000 number from?

It was a rough guess that for every one patricipating at ther kickstarter campaign there would be at least ten krita users that didn't which seems rather on the low side to me.
Also that was not the important part of my post.

Can I have a developer response about Krita and somewhat "random" issues, i've seen a few threads where the response is a long the lines of "well there's something wrong with your system"

The more general user response to this is " Why does every other software work fine, except krita? How could my hardware be the issue, when all the commercial apps on my system handle it fine. Why is Krita a special case?."

To a developer, that might sound like a stupid question.

Is there really an issue with the users system? sure that could be the case. However wouldn't the common reason be that, krita developers don't have access to enough systems to test krita on, therefore it doesn't work as good as it could on the majority of systems/platforms? because that would be more understandable. I've used blender sculpt mode, and zbrush for example, zbrush fast as hell, blender sculpt, ugh. Maya viewport yay, blender viewport nay. So It seems the actual issue, is how advanced the code is, rather than the hardware. I mean, that seems like common sense, I could be wrong about that, which is the reason for this post.

The implications of a flat response like "its unique to your system" are that the user might have to update/replace the hardware (which will obviously put people off). So perhaps a more sophisticated response is needed from developers in these cases? I'm sure its a scenario that annoys devs a lot, and users too.

(oh and ofcourse if someone doesn't have the minimum specs to run krita, that's definitely on them, but hopefully its clear that i'm not talking about those situations)

nharmony wrote:Can I have a developer response about Krita and somewhat "random" issues, i've seen a few threads where the response is a long the lines of "well there's something wrong with your system"

The more general user response to this is " Why does every other software work fine, except krita? How could my hardware be the issue, when all the commercial apps on my system handle it fine. Why is Krita a special case?."

To a developer, that might sound like a stupid question.

Is there really an issue with the users system? sure that could be the case. However wouldn't the common reason be that, krita developers don't have access to enough systems to test krita on, therefore it doesn't work as good as it could on the majority of systems/platforms? because that would be more understandable. I've used blender sculpt mode, and zbrush for example, zbrush fast as hell, blender sculpt, ugh. Maya viewport yay, blender viewport nay. So It seems the actual issue, is how advanced the code is, rather than the hardware. I mean, that seems like common sense, I could be wrong about that, which is the reason for this post.

The implications of a flat response like "its unique to your system" are that the user might have to update/replace the hardware (which will obviously put people off). So perhaps a more sophisticated response is needed from developers in these cases? I'm sure its a scenario that annoys devs a lot, and users too.

(oh and ofcourse if someone doesn't have the minimum specs to run krita, that's definitely on them, but hopefully its clear that i'm not talking about those situations)

The problems appear to be random because they highly depend on a number of different parts. The are diffent manufactures of tablets, several tablets from each manufacturer, sever driver version, operating system, versions of Krita and other software on the system. There could be a bug in any of these systems that cause the tablet to not work properly.

The fact that one application works and the other don't doesn't mean that much by itself. It's more likely that they use the stack differently. It's just like different browser where each web designer tweaks with a number of different versions of different products until is somewhat looks like he wants. To some extend it depends on how much testing the tablet manufacturer and the developers can do. For example Wacom would certainly test their tablet with Photoshop before they ship anything and Adobe will have a sizeable collection of tablets.

The "its unique to your system" stuff is usually because it works on the systems of all the developers and nobody has the same bug. Diagnois is really limited, so most of the time the proposed solution is the change parts until it works. The more sophisticated reponse would be that the user would have to send in his system or something like that.

We'd love to give better feedback, but so often we do not have the ability to tell what is causing the issue on the users system, not just because there's a million different configurations, but also because the users themselves are far less tech-savy than your typical blender user.

For example, we tend to have to explain what 32bit and 64 bit is, what an operating system is, how to find the version number, ask whether or not they use multiple monitors, how to figure out their type of graphics card, whether or not they even use a tablet, etc. Where a typical blender user is able to say 'I have this graphics card and this driver, oh and btw, I use two graphics cards, maybe that has something to do with it', we have to spend so much time on educating the users to even tell us whether they use windows 8 and which version of Krita they are using, that it is kind of difficult to understand what makes the user's computer unique, and whether or not that may cause the bug.

Similarly, where Blender users make Benchmark tests, Krita users just tell us that Krita is slow. They don't even tell us where they perceive this slowness, just that it's slow. Even though slowness while loading Krita is completely different from slowness with the filters, the average Krita user is too innocent of computers to understand that makes a difference.

The sophisticated response is indeed 'sent in your computer', 'build krita yourself and run it in debug mode in msvc', and 'I dunno why it's not working on your system, you're the only one with the problem, so I can't figure out why it happens'. And we ourselves really don't like giving those answers too.

Mind you, I myself don't really recall saying a lot of 'must be your system' recently, I have however been spamming 'delete your kritarc in %appdata% to see if that fixes the problem' and 'turn off high-quality filtering in the display settings and see if that helps'.

EDIT: I mean, if you have a better solution to this, please do tell. I don't like telling people that some mystery factor on their computer is breaking Krita.

Thanks for both of your responses. This a lot more about the user/dev relationship than anything. Sorry if this post gets too long, maybe save it for night time reading.

I would think a lot of people trying Krita, don't really understand the difference in resources that Commercial apps have vs relatively small opensource app. and because Krita is actually quite excellent for something that is free-to-use, people kinda see it as a commercial app, and get freaked when it has a seemingly small issues. Krita might actually be too good for a free app in that sense, heh. and its why it might feel like its in "forever-beta" Boud made a statement telling devs to avoid telling users that "krita was designed for linux " etc.when it came to windows issues. I'm just thinking somewhere along those lines. Anyway, easier said than done,

Another thing i'm trying to point out, because these large companies have, well, money, they probably have unlimited hardware to test their software, and it probably why a lot of these "random" issues don't really happen with commercial 2d paint apps (perhaps its just in my experience.) With commercial software, its likely very rare the user has to physically send in their hardware, because it probably has already been tested by these companies who's pockets are filled with money You said it yourself, krita users are too innocent, but I would say 2d artists in general are fairly innocent, because 2d painting apps generally don't require as much "research" as 3d apps. Probably all commercial 2d paint apps, work on a standard modern store bought machine. So the idea of having to send in hardware is probably "wtf?" to the average guy. "it should just work, right?"

Examples: I still have cursor jumping issues. Sometimes krita is unresponsive, leading me to have to minimize and maximize the window to have it work again. I still get weird artifacts when dragging one document window on top of another. I reported that, but I guess back then I was still in the mindset of, "wtf all my other apps are fine, booo! i'm not buying new hardware just for krita or blender or any other app, this sux" and I think thats how a lot of us idiot artists think even if its not said

Perhaps something can go up in the FAQ in regards to "why some bugs don't get fixed! "why your hardware may have issues with krita" or just something to do with Krita foundations hardware limitations, something you can refer a user too, Thats all i meant by "sophisticated" response. The innocent average user isn't going to just get it. Perhaps it hurts the "brand" of krita to point out flaws, or perhaps having a copy-paste standard response to users makes less of a community, but i'm guessing these things will come up over and over and over again regardless.

At least if someone gets rowdy or is unclear, you can link em to that faq page rather than fume on an internet forum.

edit: oh, I did have delete my config recently because krita kept crashing when using scratchpad

boudewijn wrote:So it comes down to this: what would users prefer: less bug fixes, less new features but more documentation? Who is going to write the documentation? Developers shouldn't write manuals, that way madness lies...

One of the reasons why I have been asked by my local paint group to make instructional videos is because the guy who suggested Krita as a platform (rather than any of the other free paint programs like Gimp or Mypaint) couldn't find much current documentation.

Documentation is often the Achille's heel of open source development. When asked (which is, granted, not very often) my advice is to focus as much on a documentation team, which isn't directly associated with the dev team). Technical writers are best to communicate technical information. That's not a job developers are suited for - or they would be technical writers.

canon wrote:

boudewijn wrote:So it comes down to this: what would users prefer: less bug fixes, less new features but more documentation? Who is going to write the documentation? Developers shouldn't write manuals, that way madness lies...

One of the reasons why I have been asked by my local paint group to make instructional videos is because the guy who suggested Krita as a platform (rather than any of the other free paint programs like Gimp or Mypaint) couldn't find much current documentation.

Documentation is often the Achille's heel of open source development. When asked (which is, granted, not very often) my advice is to focus as much on a documentation team, which isn't directly associated with the dev team). Technical writers are best to communicate technical information. That's not a job developers are suited for - or they would be technical writers.

Where do we get these people?

3d print them

TheraHedwig wrote:

canon wrote:

boudewijn wrote:So it comes down to this: what would users prefer: less bug fixes, less new features but more documentation? Who is going to write the documentation? Developers shouldn't write manuals, that way madness lies...

One of the reasons why I have been asked by my local paint group to make instructional videos is because the guy who suggested Krita as a platform (rather than any of the other free paint programs like Gimp or Mypaint) couldn't find much current documentation.

Documentation is often the Achille's heel of open source development. When asked (which is, granted, not very often) my advice is to focus as much on a documentation team, which isn't directly associated with the dev team). Technical writers are best to communicate technical information. That's not a job developers are suited for - or they would be technical writers.

Where do we get these people?

Here, I suppose. ^^

While my instructional videos will all be in Swedish, and go into boring detail, I decided to reboot an old Youtube account I had, so over the next month I'll make some videos. Nothing much up yet, except a mission statement. I'm going to do some other videos before I get into the meat of Krita.

Next one answers the question: "Do you have to buy a graphics tablet". The one after that is about which 2d editor to get. Guess which one I'll recommend? After the second one, I'll be able to do some real tutorials about the program.

I'm not going to spam the board with the link to the channel. It annoys me when others do that, so.

nharmony wrote:3d print them

Hum, can you provide documentation for this?