Sun Mar 30 00:07:09 CET 2008
(workspaces) and better resource management, one of the ultimate
development goals of Krita is to take content and interface management
increasingly out of the hands of the developers and increasingly into
that of the users, with good defaults in-between.
Of course, developers are also users, but this allows the interfaces
to be designed from the perspective of someone unfamiliar with the
underlying coding and history.
No-one's to blame, but it is simply that when you're used to something,
you completely lose track of the fact that somebody else does Not get
it. Photoshop users may rant and rave about how great the Photoshop
interface is, but -I- remember the confusion I felt when I started it
up all those years back.
The way I see it, if Krita is successful, its "development" community
will one day be divided into the following:
1. The core developers. Nothing changed here, except some may be
divided into teams focusing on specific workspaces (so some programers
can go crazy on the photo workspace for example, while leaving alone
the painting coders).
2. Extra plug-ins developers.
3. The interface default designers. This team of designers basically
have to do the following:
- communicate with the core developers, to keep up to date with new
features and discuss the most intuitive interfaces.
- establish the workspace default settings, the ones that ship with
each new version. The interface default designers should preferably
be power users of the workspaces they manage: painting, photo, etc.,
so it is certain that the workspace is usable. Basically, an artist
must manage the art workspaces, etc.
- keep in touch with the wider user community, including the resource
contribution community, to eventually select the best resources for
inclusion into the default distributions: brush shapes, textures, etc.
- keep track of input by "complete newbies", people who aren't familiar
with either coding or computer graphics programs, thus can point out
the most puzzling aspects of the interface.
4. The documentation contributors. The core team is in charge of the
"core" tutorials for each workspace and updates for each release, and
providing links to the most useful tutorials submitted by users (a
list of all tutorials can also be available, but basically, they
should somehow be ordered for the sake of the users. The Gimp User
Group doesn't order anything, and as a result I can't find Anything,
which rather defeats the point)
5. The translations contributors. For localization, naturally.
6. The greater user community. Basically, they use and promote Krita,
but they may also submit new resources such as brush shapes, paper
textures, tutorials and more, even their own versions of workspaces
and resource settings. When submitting to Krita, it should be under
a CC license, and preferably by collection and with a preview (hey,
it's how they do it on Deviantart. Downloading a collection of brushes
is easier to manage than finding one at a time).
7. With all this in light, the Krita website developers would have
a lot of work as well. The website would be the get-together point
for developers, interface designers and users, and the resources
submitted would have to be classed and ordered in a way for users
to easily find them. For the interface team to find them too, so
that they can include the best submissions into the default. They
also have to manage all the venues for communication (mailing lists,
IRC, forums, etc). Huge work, yeah.
Many open source projects still have the problem that they only think
in terms of coding development.
But check out the following, closed-sourced program, for example:
Opencanvas is quite popular in Japan and also managed to gain a
following in the west. I have no doubt that its community system is
a big component of its visibility, though what I'm hoping for
Krita is not quite the same and not quite as extensive (not yet, at
Like movies? Here's a limited-time offer: Blockbuster Total Access for one month at no cost.
More information about the kimageshop