Not a complete failure

Interesting research paper about the small Mac developers who form a community with its own role models and non-written rules. (via Gruber)

I feel identified with this description of independent Mac developers. Hopefully I can join this ‘creative class’ soon.

Indie Mac developers appear to be prototypes of what Richard Florida (2002) calls the ‘creative class’. On average they do not make a sharp distinction between their personal and professional lives (Florida, 2002, p.14), they appreciate systems of meritocracy and subscribe less to the status of wealth, they seem more motivated by the respect of their peers than by money (idem, p.78) and rally around their professional identity as a software entrepreneur (idem p.80). Indies fall into the category of ‘free agents’ (idem, p.107): people whom willingly sacrifice the securities of a job to be able to pursue their own creative interests.

But you can only pursue creative interests full-time once you’ve solved the money problem. Thus making remarkable products that sell is the most difficult part of the equation.

A few days ago, as I was brainstorming ideas for my new icon design, several concepts emerged.

The “Chest”, my preferred one, was featured in the previous post. But a second idea also looked interesting and I decided to develop it as well:

A common problem I find when I write or design stuff, either an user interface, an illustration or an icon, is how difficult it is to judge your own work.

Usually, I let pass a few days before I look at it again. While you’re designing, you’re trying hard to make a certain message emerge out of the drawing, so your perception is biased until you’ve evacuated it completely. You can discover that the design doesn’t work or conveys a different message, but only after a while.

That’s why I’m leaving those two icons in this “almost-done” stage, until my mind cools down and I decide that I like them enough to finish the job.

As it’s just for a secondary application, that plays a small role in a bigger thing, I haven’t engaged the services of a professional designer.

I’ve still some rough edges and details to polish, but I’m pretty happy with that. It took me about 10 hours of work:
Brainstorming, selecting ideas, developing a few ideas, handmade sketches, mock-ups to see what works and what doesn’t, pick an idea, and finally do detailled drawing.

A few lessons learnt:

• You will end with something different than what you plan.
• Design at once Application Name + Icon + “Catchphrase”. Otherwise it’s too heavy for only one element to convey all the force of your idea. Make each element reinforce and complete the other two.
• No more than 2 or 3 visual elements in your icon. Beyond that, it will not be understood and will not work at small sizes.

(Second instalment of “Movie Repair Guide”)

When confronted with a corrupt movie file, there’s a quick way to check that it still contains the media data, which is a necessary condition to repair it: the “Zip test”

We create a compressed version of the file, which tells us the compression rate. For example, 50% means that the zip file is only half the size of the original one.

Audio and video data will give a low compression rate whereas other type of data will be around 50% or higher.

In Mac OS X, you can use the zip utility, either from the Finder, or from the Terminal:

zip --filename--

In Windows, you can use WinZip utility.

Here are aproximate compression rates you get:

• For data completly erased (file full of zeroes), 90 to 100%
• For alien data, 25 to 100% (Office documents: 50%, Applications: 40%)
• For audio integer 16, 21%
• For AIFF, 17%
• For DVCHD Pro, 11%
• For DV, 5 to 12%
• For other video codecs, DivX with mp3, Intermediate, MPEG2, H264, JPEG: 0 to 8%

There is a big gap between audio/video data and any other type of data. If you have a corrupt file, and the “Zip test” gives you a result over 25%, probably a complete repair is impossible because the data is partially or completely gone.

You can also refine the test by measuring on segments inside the file:

With a 500mb file, we split in 5 segments of 100mb and run the zip test on each segment with this two Mac OS X Terminal commands:

split -b 100m corrupt.mov
zip deleteme xaa xab xac xad xae

(The first one, split, cuts the file in chunks of 100mb each, called xaa, xab, xac, xad and so on.)
(The second creates a compressed archive called deleteme from xaa, xab, xac, xad and xae.)

This gives for example:

xaa (deflated 5%)
xab (deflated 5%)
xac (deflated 12%)
xad (deflated 100%)
xae (deflated 100%)

Which tells us that the media data in last two segments is probably lost. If a repair is possible, maybe 50 to 60% of the original file will be restored.