My two cents: For platform owners such as Apple, Amazon, Google or Microsoft, the ‘art’ is to close the door only so much that the input-providing participants don’t feel uncomfortable squeezing through it, and keep providing stuff (apps and content), because the consuming participants will only start switching once they realize the restrictions applied lead to a perceived lack thereof. Angry nerds won’t fix it. Unless they invent a different thing that restarts the cycle.

Apparently, the Bootcamp EFI record only exists on one volume at a time, which in my case was one of the two that were merged to the RAID. On the next bootup, the Win 7 volume was not available. So what to do now?

Here’s a solution that worked for me:

1. Get rEFIt and burn the image to a CD.
2. Re-boot an launch the CD by holding down [option] or [c].
3. Choose the Partition Tool (second to the left in the lower row).
4. If it detects inconsistencies between the EFI and the MBR, have them be repaired.
5. On the next boot, your Windows (Bootcamp) volume should show up. Try booting from it.
6. If you’re getting the [BOOTMGR missing] error, continue reading. No errors: Congrats. Other errors: Good luck.
7. Re-boot from your Win 7 installation DVD and navigate to the repair section.
8. Choose “Start command prompt” (last item of the five).
9. Enter bootrec /fixboot , hit Enter and wait for success.
10. Enter bootrec /fixmbr , hit Enter and wait for success again.
11. Reboot, start from the Win 7 partition and hope the error is gone. Yes? Congrats. No? Don’t worry, there’s one bullet left (as far as my experience goes).
12. Re-boot again from the Win 7 installer DVD, go to Repair options and choose ”Auto-repair” (first menu item).
13. That’s when I had it fixed. If you haven’t, I’m sorry I can currently do no more to help you. In some forums people have said that running the auto-repair routine multiple times eventually solved the issue, yet I can neither confirm nor deny it.

In various forums, people have reported problems with camera stabilization inside Final Cut Pro 7 using the plugin SmoothCam (which orginally comes from Shake, no pun intended), but not in Final Cut Pro 6. For comparison I ran some tests on both systems and came to the conclusion that FCP7′s SmoothCam does not work properly with interlaced footage no matter which codec you use. FCP6′s SmoothCam does the job with whatever kind of video.

Two more tips for Apple Color:

Always de-interlace when using Color, especially when working with Color FX. There are two ways to do this, one via the Clip Settings Tab and the other in the Color FX Tab. I haven’t compared whether they give different results but my guess is it’s not going to be that dramatic (we’re talking video ‘ere).

Last one: When migrating a Color project from Version 1.x (Final Cut Studio 2) to 1.5.x (Final Cut Studio 3) and you want to keep a copy of the old version, be careful to keep them in different folders. Thing is, when you rename the .colorproj bundle (it’s not a file, but a file package), Color will crash when opening the project (because he filenames inside the package don’t match). So you can either re-name the backup, open the current version, update & save-as the project and then re-rename the backup file, or just use different folders.

There are a number of music collaboration platforms on the web already, but most of them don’t seem to be very productive, because all projects are open-end, there’s no deadline, no need to ship. Hence engagement soon drops after the initial euphoria. I think making music is more fun when it happens quickly and spontaneously, as well as under a time constraint, something you can see in the many remix contests that only allow participants to work on their remix for a few days or even a few hours.

So here’s the beef:
A collaborative music platform where there’s just a limited amount of time to finish a song. Not measured in real-word time, but in project-time. Huh? Very simple. A song has to be finished in, say, 12 hours. For instance, a guitarist starts a new project by uploading a riff. Someone downloads the music file and adds a bass part. The timespan until the new file is uploaded again will be added to this project, so when the bass player needs 90 minutes to contribute her part, there’s 10 hours 30 minutes left to finish the song. To spice it up even further, the whole thing does not happen in linear fashion, there can be multiple forks or branches per project. Again, huh? Well, say there are two bass players and each has a different idea (likely to happen), there will be two branches on each of which the project can be continued, each with its own timeline. Combine that with 3 different lyrics, 5 vocalists, one drummer, you might end up with 30 results based on the original part.

I’d be extremely happy to see someone turn this into reality. Got questions? Just drop me a line.

Here’s what I responded:
“We’re all customers, aren’t we? And what do we appreciate more, trying to find an existing solution that’s already out there (a.k.a. “Check the FAQs” and “search for a tutorial”) or having someone take the time to (find out and) tell us what to do? Of course every customer prefers to have problems solved immediately, but that’s a different aspect of the same issue. Engineers and technicians used to be not very good at interaction with real people (yep, that’s a cliché), that’s why they preferred to keep track of every issue and include it in the manual or FAQ — or, ideally, they would solve the issue in a self-explaining way (not likely, but hey..). And -surprise!- people have not embraced studying manuals cover to cover, because it’s boring, techy stuff! Same problem as before.

Another point: An angry customer is just as good as a happy one, because he gives you two opportunities: You can solve his problem AND make him happy. That’s a reward for everyone involved, isn’t it? :)”

The reply to which was: ” ‘Of course every customer prefers to have problems solved immediately’ – You said it. And so everything else becomes void :-P Welcome to my world!”

This reminded me of one of my favourite drawings. And it’s quite interesting to consider it in the context of software.

20 years ago, handling computers was not very straightforward. You had to learn a set of commands to tell the machine what to do, which in itself was awkward enough to keep the majority of people away from it. Unless, of course, your computer’s brand contained a fruit. There was little convenience in using these gray boxes, and the once who used them were in majority expert enough to find workarounds in case something caused an error, like “Oh, this field requires only digits to be entered, and I entered letters, so it didn’t store them.”.

The first major shift happened when software became more accessible by graphical user interfaces (GUI). The upside for the software companies was they could sell more because there were more customers because of the improved convenience. The downside was that the more people used software, the less experienced they were. Thus manuals grew ever larger, and programmers had to implement more error handling and feedback mechanisms to tell the users what to do when the software didn’t deliver what the user thought it should.

The second major shift happened when computers became ubiquitous. Now software designers had to deal with the whole range of users from absolute newbies to experts who had been using their software since version 1.0. The analogy here is the VCR. Every household had at least one, but even in the 90s, when VCRs were sophisticated as they could be, only a small fraction of people would know how to set the time. It just wasn’t straightforward. It’s like comparing Microsoft to Apple to Linux. Every company or project has it’s own approach of how things should be, and some people favor one over another because it matches their expectation.

Nevertheless, it’s still software which has been made by people who do not always consider or who can’t anticipate every way a user will use their product. This is a given which also applies to custom designed software. People do not know everything they want their software to do, because they don’t care about what happens under the hood. What they do care about is the look of the GUI, and ideally, error handling and feedback functions that do not make them feel stupid.

Another thing that users in general have little concept of is “beta”, meaning “it should work, but there will be some glitches that we have to figure out yet”. Which is why most beta versions are free, because no one can expect you to pay for a product that doesn’t work. Or can they?

Zynga’s very popular game Farmville is labeled as beta ever since its release one year ago, spreading like wildfire with more than 70,000,000 players worldwide. Like other games, this one has a virtual currency allowing you to buy stuff in the game. One way to increase your amount of virtual currency is to buy it with real money. And what happens (quite predictably) is that people are confusing things: The game is free and still in beta, so you can’t expect it to work perfectly. But what you buy should be yours no matter what. This explosive combination detonates every once in a while. It’s technically okay when the game crashes, but not when items they bought disappear. But people do not distinguish between the two. Their posture is: “I pay for this, so I can expect it to work.” Which is not quite the case. What’s worse though is that they a) keep on playing no matter what, and b) they complain to the public, but not to Zynga. This is not changing anything, it’s just whining.

One more thing before I’m trying to wrap this up: Software design is also about fashion. It doesn’t matter if the latest trend or technique adds any value to your project, but you better brace yourself that your customer will ask for it — just because they can! They pick up something somewhere, and they will ask you just to look smart themselves, impress their peers, whatever.

So what do we make of all of this? You have to embrace a number of things:

• Whatever approach you take, one size will not fit all. There will always be someone screwing up, and that’s when your phone rings.
• Be careful about customer’s expectations. There’s a large shift as soon as money is involved.
• People hardly call when everything is alright. That’s when you should call to ask for improvements and the like.
• Expect your customers to be human, not tech experts. This also implies that they will react as humans do, meaning they will be angry when they call you in case something fails. That’s ok. You have the opportunity to solve their problem AND lighten their mood. Give them a hug.

Combine that with the result of another study concluding that Facebook users (in general) are very prone to spam and abusive clicking manipulation — never mind the fact that they accuse Facebook of ignoring privacy and personal rights, but on the other hand they just click shortlinks on somebody’s wall or blindly forward them, same goes for Twitter — and you get three conclusions:

• There won’t be less spam in the near future.
• Antivirus and Firewall software never compensate all user responsibility deficiencies.
• Not getting an error message doesn’t mean you’re an expert.

But Apple’s policy makes perfect sense. Cross-compilers can induce errors in the executable app that can not be seen in the source code, because it’s an entirely different language. It’s like having a simaltaneous interpreter when you’re talking to someone whose language you’re not speaking. You don’t know if the interpreter is exactly saying what you were saying to him. No chance of verifying the output.

Also, programming software for Apple computers has meant starting from scratch ever since. You have to use an entirely different framework than on a PC. Never heard any complaints about that. Quite the opposite is true, many developers prefer Apple’s tools.

But the most important point is this: Apple knows perfectly well that if too many faulty apps are being released, this will not affect the programmers. Not at all. It will only affect Apple as a platform and as a brand. They have worked almost 30 years to build their reputation of “switch it on and it works straight away”, they will never ever put that to risk. Would you? Of course not.

Can you make it? Pretty please?

The core question is: How do we organize data? What’s most annoying about the classic folder concept is that it only allows for one context in which data can be represented, but technically, it doesn’t matter. The file system itself is nothing but a giant database where a string variable points to a physical area of your hard drive. Some more information that is stored there: file size, file type (extension), creation date, modification date.

I’d like someone to come up with a piece of software that hooks in at this very basic level and gives me whatever contextualization of the data I like, say, by last modification date, document type and a number of tags I have entered. Or the other way round, with a single click, not going through the whole procedure again. It’s all built in, but not being used. To be clear: I don’t want a search tool, what I’m asking for is a flexible explorer (hint: if you’ree finished making it, flexplorer.com is already taken — by a Cayman Island Domain Troll of course. Flexplorer-xp or winflexplorer are still up for grabs).