... In which this blogs "hello world" post is done, our intrepid hero (me) retells his experiences from the Plasma Sprint and we do a quick glance at the issues with KDE and design which will be covered more extensively in the future.
|“Blueprint,” © 2009 Will Scullin, CC-SA|
This blog is a place for me to write down and keep my thoughts on design, mostly graphical, and KDE - all things written down are my opinions and do not in any way reflect the opinions of KDE, the company or community, or any other groups or companies affiliated with KDE in any way.
I will try my best to keep it updated, actual, easily understood and SFW. So no swearwords but even more important - no fluffy buzzwords and hypespeak.
You have been warned.
A few weeks ago I visited the Plasma Sprint in Barcelona held at Blue Systems offices. Thats how all this started. I was invited initially by Aaron Seigo and later by Sebastian Kügler as a "graphics dude". What exactly would be my contribution was unclear, to them and me, but the idea was that it might be good to throw a new guy in the mix and see what happened (I think).
Before going I was nervous. I know what happens at meetings with ad-agencies, with AD's and Creative Directors. I can walk blindfolded through the minefield of an magazines editorial meeting anywhere and come out with both legs and dignity intact - but this?
How would it work? Would they laugh? Would they assume I was a programmer? Would I have to pretend to write code while trolling twitter in a corner for three days?
I should at this point mention the invaluable help of Boudewijn Rempt who tried to calm me down, telling me that my fears of being lynched because I couldn't laugh with sincerity at jokes about C++ was unfounded. For future reference - always listen to Boudewijn.
This has been three inspiring days. I've watched programmers and devs work in perfect tandem, throwing questions and ideas back-and-forth without pride or aggression. Any question was given due thought, any answer was met with the most humble of assumptions and for me - everytime they saw me listening in on a topic one or all would simply turn and explain the issue for me as a non-techie without even the slightest sliver of condescending attitudes or behavior.
I wish I had stayed longer and been quiet more (I talk when I'm nervous and the more nervous I get the louder and faster I tend to talk).
Seen from a technical stand-point, a thousand and one good things where handled - although I shouldn't be the one to talk about it and I suggest looking at Sebas, Marco and Martins blogs for more information about that. For further reading of me gushing over the other attendants I suggest my Google Plus post.
From a designers POV - it was an eyeopener. KDE needs designers, graphical, interactive, sound and animators. KDE need marketers, communication experts and copywriters.
The issue is simple. KDE has a set chunk of "the market" and it has its own niche to fill and it does that with gusto. Technically KDE is constantly in the forefront but very few know what many of these innovations are. A good marketing plan for the next iteration of Plasma by KDE would go miles in spreading the word of what you can do and that it exists.
Because the issue is KDE is made by technically adept people, programmers thinking the way great programmers think: "there is a good way to do something and there is a way that doesn't work". Most times and issue with programming is totally objective - you can prove quickly what works and what doesn't. With design this simply doesn't exist. The quality of design (especially interaction design) cannot be easily proven since its not until its being used extensively by a large enough test group for a longer period of time that you can objectively prove its quality.
You simply have to rely on the past knowledge of the designers.
Equally the idea that "the best thing will always be chosen by users" is a complete fallacy. This is only true if all users have a grasp of the options, the technical issues and how they are solved. If they know all things needed to make an enlighted decision - and any good marketer or communication expert can quickly tell you that thats not how people work. We all don't have the time to make an enlightened decision - the availability for us to do so should be there - but we tend not to.
The issue within KDE is simply explained: the work method is made for programmers and devs working within Open Source. They drive innovation and they handle everything. Which is awesome except that that also includes looking and often hunting around for someone who can help do icons, layout or interactivity design for them. For designers this means that there are no easy "ins". The idea of reporting design issues through a bugtracker might make sense to people used to bugtrackers but to those who aren't even looking there for issues to solve simply doesn't make sense. An email list called KDE-Artists found by scanning through a massive list of email-lists is another way in.
If you would for some reason go looking for a nice email list (in 2014) where you could help out chances are no dev will see you volunteering since they don't use that list. But maybe you just want to see if its for you? You still have to sign up to see the history so you have no idea of knowing.
Since finding a designer is so tricky it means the dev has to cast a wide net and ask as publicly and loudly as possible - this means issues have popped up where designers have independently started working on the same thing and then at a late stage notice it and consider the time wasted or found themselves in a beauty competition with a total stranger judged by people who themselves profess having no eye for design. Further the amount of design love some app or plasmoid gets depend on the waxing and waning of designers who jump aboard or leap off the various mailing lists.
So I decided that besides the icon work and logos I promised working on at the Sprint that I should do something more lasting: shape up the situation so that designers following me could slip into it more easily. That they could know that they wouldn't just do days and days of work for nothing and that they would always be met with smiles and support. Just like I was met at the sprint but from a wider design community within KDE.
But most importantly that they should see a need existed, what needed to be done and could easily pick one up.
So in the future this blog will be about as much design as it is about restructuring the design work with KDE, if its possible, if it works, if it doesn't. It will be an awful gruelling recount of the horror that is internal work methods.