I'll make some comments on this, but I think that you actually want someone closer to the SoC to pick this one up
On 05/05/06, Timothée Anglade <timothee.anglade@...1261...> wrote:
Ok, let's try to put this back into context. I understand that as developers, your main concern is the application. I have to be honest and say that as a potential SoC applicant my concerns also match my passion for the project, but I do have an additional time constraint.
That is 'our'.
Whether that sense of urgency (on my side) jeopardizes the well being of Inkscape is for you to judge, but here is a pre-proposal (nothing formal yet) I'd like to make.
As Inkscape is GPL'd little short of a long nuclear winter would jeopardise it. The worst that might happen is that some svn commits might need to be rolled back - the work of a moment.
[ snip ]
- Part 3 would optionally be the implementation of theses changes, if
any are deemed interesting by the community.
That is right. You are free to implement (and distribute) any changes you fancy, but only those that create some interest will be survive.
The goal being of course to make out of Inkscape, as Ben said, a "best-of-breed" app that the vector drawing or Open Source communities would be proud of.
I wouldn't necessarily push for "best of breed" if some other prize winning category were more achievable or in some sense better. "His sins were scarlet but his books were read". I would like Inkscape to: Be capable of accepting feedback, Be useful, Be chosen by the discriminating, Be capable of doing things that its authors had not thought of.
I think there is room for several editors, and in fact Inkscape as a pure SVG editor could take second place to Sodipodi if that became a general purpose editor with similar abilities.
I am fairly sure that there is room for editors specifically for icons, and something like XaraLX which also does bitmap editing.
One last point regarding the team-vs-one guy approach. I'm a firm proponent of the later, because all my experiences in design with a (large-)group have been failures, as it's never possible to have everybody agree on a design or another. What people do agree on are results (in this case, more people coming to use the app and help develop it, less complaints about usability or learnability). And I think putting trust in someone to do that job and present results almost scientifically (I'm using 'almost' because we're talking about design after all !) is the best approach to get results.
It is possible for a 'large group' to agree on one person's being the architect, but I wouldn't bet an OSS project on that. I think that Qmail works like that, and Cyrus and Arch.
* To encourage developers, one needs to have a build system that doesn't break, sound instructions, mailing lists, bug trackers and so on. The code needs to look as though no one is going to jump on you for hacking on it. Big "up front" design http://xp.c2.com/BigDesignUpFront.html needs to approached with caution, see http://www.agilemodeling.com/essays/bmuf.htm http://butunclebob.com/ArticleS.UncleBob.JoelOnXp and should be avoided if it creates a barrier preventing a hcker from jumping in and hacking. The code needs to sufficiently well written that it can be modified with little chance of breaking something else.
* Yes, I would like that subset of people who use vector drawing programs every day and do coding to come and hack on Inkscape, although there are quite a lot of people in that category, the supply is limited, and I don't claim to know how to recruit for Inkscape!
* We are going to get complaints (bug reports) for as long as new features are being added, new people are picking up Inkscape and it is being put to new uses. By and large, OSS is not shelfware.
Arguably, we need some form of organisation so that such reports are analysed and the necessary changes and fixes are put into the code and documentation, and tutorials and screenshots provided. Maybe the total number of open reports looks large, but my understanding is that Inkscape, whilst still a youthful project, is becoming more mature, and serious code defects do not remain long.
* Personally, I would like to see a way of comparing our interface with the Gimp. I would vote for proposals that entailled interface elements that exist in both applications (Layers, Colours, Export) being either very similar and actually identical if possible, or quite distinct.
Also a group can agree on a Highest Common Subset approach - include all those features with no negative votes - but this often leads to a mediocre result and has to be used with discretion.
Hope this helps, but I have wandered off your topic again ...
Ben.
On 5/5/06, Ben Fowler <ben.the.mole@...400...> wrote:
On 05/05/06, Alan Horkan <horkana@...44...> wrote:
On Fri, 5 May 2006, Ben Fowler wrote:
Date: Fri, 5 May 2006 11:39:14 +0100 From: Ben Fowler <ben.the.mole@...400...>
[ snip ]
It has yet to be shown that an OSS project can produce a best of breed UI (I think that it is possible, and that to date, no project has put together all the ingredients needed for success), which is why one suggestion of mine was to achieve a purity of design, and perhaps work alone for a period of time.
Purity of design or inconsistent and more difficult to learn?
If you think of the best designs in any area that you are familiar with, my guess is that you could name the designer and assert that it came from the brain of one person. That is what I meant by 'working alone' and 'purity of design'. (I was also assuming that everyone on the dev list actually likes making vector drawings - I know that I do; and perhaps had a generous modicum of what Paul Graham calls good taste http://wingware.com/pipermail/py-design-forum/2003-September/000184.html and http://david.shackelford.org/?p=304).
Inconsistent is a loaded word. "Lets be consistent and force all the square pegs into the round holes."
'Difficult to learn' can mean 'easy to use'. One persons 'good' UI (easy to learn) could be the next man's poor design (hard to do good work with).
As with the more techincal discussions - such as the shared understanding that native GTK for Mac OS X is the only practial way to go - things go more smoothly when a consensus builds and we all pull together. At the moment there is a rough sense of how we all want to Inkscape to have a better/best user interface possible but a clearer vision of how we can all achieve that together would help. Anything which could help us all form a clearer plan and then break that up into smaller shared tasks will really help. Management is an important part of development, something which I think has been a key part of the success of Inkscape so far.
Without disagreeing with you too much, you are describing how to reach a local maximum. This is not going to help becoming best of breed. In fact a better way would be for as many people as are willing to produce a design (or merely a mockup in the GIMP) and have the group provide criticism. Perhaps we need to decide whether we should be seeking to be best of breed, or whether a local maximum (nothing need be added, nothing taken away) is good enough. There is a lot to be said for 'good enough'. Perhaps we need to decide how long we can defer such decisions. Perhaps the longer the better. What will people watching the progress of Inkscape (and for that matter the Gimp) think about its UI being and looking unfinished for the next 55 milestones. My answer would be "Hey, our users are happy and they care enough to send feedback".