Archive for March, 2005
Managed to resist a STRONG temptation to walk out of a console shop with a
japanese import . Only the price tag made me come to my senses. The US
Launch tag is $250 while a bare console here cost almost $400. I was also
from HK which still makes sense even with the VAT added. But man, you always get ripped off being an early adopter. Resist!
Isn’t that a slick toy from the
evil empire, is it?
Jiri has been improving Daniel’s key status app for showing keyboard and mouse activity while recording demos with xvidcap as I’ve blogged about earlier. While I went the lazyman’s path of using a simple regex to render the extra keys needed, Daniel has some more sophisticate SVG tweaking utilities on his page, definitely worth checking out. We are so not using SVG’s potential on the
To show it off, here’s a little glimpse of Bulia’s great efforts on improving the node editing interface in Inkscape.
Women can be extremely motivating. “Finish the tax paperwork at last, so you
can go to shovel the snow outside.” Somehow feels like digging your own grave
while the assasin is smokin’ one.
Historically the best chance of having a functionality go into a free software project has been by sending a patch. That means doing all the work yourself. Many still think that you can only be part of a free software community if you become a hacker. Let me assure you that is not the case.
With free software you can get your stuff implemented by either sponsoring the project developer or someone outside the project to figure it out and write it for you. But you can also invest your time to make it a lot more simple for the hacker to implement it.
Many users take the same attitude toward a free software hacker as they have for the proprietary developers who they indirectly support by buying licenses to use the software. Thinking the hackers are there for you to please every wish will hardly get you anywhere.
If you take the time to write a functional specification, you are very likely going to motivate someone to get it implemented. You take the burden of designing the behaviour and let the developer worry about implementation details, data structures, etc. You invest your time and effort just like the hacker would have. Here’s a few suggestions.
- Define the functionality by creating a few test cases on what problems you are trying to solve.
- Be very specific and go through the process step by step. It will make you find problems with your design. If you were to just suggest functionality and don’t work out the details, you will, in the best scenario, waste developer’s time discussing the flaws you would have found yourself.
- It is better to find a bad design while writing the spec than after it has been implemented. Convincing a developer to redo something is close to impossible when he already invested a lot of time in it.
- Be visual. Create mockups of the interface as you go step by step through the process of solving the task. Many times I have thought my descriptions are clear, when they weren’t. Images tend to be less vague (Well this may simply be because my writting sucks, too).
I sincerely hope I don’t repeat myself since I have a very dejavu feeling. And yes, I have partly written this for myself . I better do as I speak too.
You may have noticed I enjoy using the great screen capture utility, xvidcap. It is really nice to create small demos that illustrate a certain functionality of a gui app better than writing it with plain text.
The app has a lot more potential though. It could be really helpful for usability testing if some additional functionality was added. A developer could have a neat tool to identify problems users have with solving a particular task with his/her application. The functionality required for this:
- Keyboard Status – some indicator of pressed keys should be recorded.
- Virtual usability lab infrastructure – an easy way for a developer to set up a virtual usability testing lab. A web interface possibly being the best approach. A developer would write down a number of tasks the subjects are supposed to achieve, the xvidcap-like client should be launched by clicking a specific URI (custom schema) that would set up the recording session in the recorder. The user would simply press a “record” button and start with the task. After completion or unsuccesful try, a stop button (perhaps the very same button) would need to be pressed, displaying a simple dialog. In there, the subject would attach a simple text comment providing some additional feedback, especially since sound support (see next point) should be optional. Cancel, Save to File, Submit buttons are the likely ways to dismiss the dialog. The default Submit button would upload the file to the provided location set up by clicking on the initial link.
- Sound support (this already exists) – the struggling user usually mumbles useful information when getting stuck with the task. Unfortunately a microphone isn’t a very common peripheral so this should remain optional.
Technical note – Xvidcap is quite a bitch to compile and pretty much requires to have ffmpeg linked statically in.
Luis, I truly regret missing the opportunity to take an active role in the judging. Have I not missed the discussion that apparently took place on the marketing list, which I am not subscribed to (as opposed to gnome themes for example), I would have not submitted the artwork for the contest myself. It doesn’t have anything to do with being busy.
At the time of writing the blog entry, “gosh it sucks” felt like it summed up my thoughts best. But here’s my take on the “constructive criticism” now that I calmed down:
- Bad lighting. The foot shading doesn’t correspond to the shadow cast on the wall.
- Color. Saturated purple gradient with a large contrast gap between the gradient stops is probably what makes it hard for me to accept.
- Layout. There is no harmony between the individual elements of the splash. Especially the “GNOME” vs “2.10″ text.
- Font. I am guilty of breaking this rule myself, but the GNOME logo is supposed to use the Trebuchet MS font.
The problem is, a splash may comply with all the rules (which weren’t really mentioned in the initial call for participation) and still not be executed well. And there may (and were) many entries that break the rules, use the Gnome 1.0 foot for example, and still be appealing and well executed. As you know, artwork is subjective. As much as I hate writing guidelines, I guess we need some for the “look” as much as we needed it for the interface “feel”. This splash looks very alien on the GNOME desktop.
Not “bitching about it” after it happened is perhaps a valid point, but as a person who devoted a lot of time trying to give GNOME a consistent and pleasing look I simply couldn’t help myself.
Kris, since you have comments off in your blog, let me misuse Planet Gnome as USENET
The number of dutch folks in Liberec is very close to all the germans (close to the border), so I’d really like to know what makes you guys come here all the way. The mountains surely can’t match the Alps. Is there some mass promotion going on in NZ?
Even during summer I see a lot of dutch people in the summer camps so I’m really interested in knowing what makes the country attractive to you? Cheap beer and sexy chicks, eh?
* app/tools/gimptextoptions.h: allow to adjust letter-spacing.