I have about a dozen articles in MarsEdit (my blog software) waiting to be finished. There always seems to be so much to say, it seems awfully difficult to resist capturing every relevant thought or idea in one article. So they sit there, languishing in their unfinished state. It's hard to write something you feel is meaningful and reflects what you think, without it ending up as a great opus of constantly expanding scope... So one of my New Year's resolutions will be to be concise, focused and succint (okay, stop sniggering - it's hard).
August 2006 Archives
Can you measure productivity in pixels? Some people (apart from LCD manufacturers) seem to think that more screen space == more productivity. But I've seen some evidence that convinces me that this is not always the case - in fact sometimes it can be counter-productive.
I have worked in (and visited) several offices where people have two screens (nearly always LCD screens) side by side. Apart from making me jealous, they made me wonder what it would be really useful for.
I personally can think of numerous benefits - one of the most common window configurations I use while coding is:
- Emacs: editing source code, usually with a dozen or so buffers
- xterm: one running the software under development and viewing debugging output, one for general shell operations, sometimes another for a database session
- Firefox: browsing API reference material, typically with many tabs open, and one window per related contextual group
I usually split this across two or three virtual screens, and hotkey between them. It is a fast method, but it could be faster. Imagine having two large LCD displays, with Emacs and xterms spread across the first, and Firefox on the second. You could simply glance back and forth between the code and the reference material, which would be quite a bit faster than flicking back and forth in virtual desktops.
Another useful scenario would be to have the Final Cut editing windows (timeline, media bins, settings, etc) on one screen, and a full-screen preview window on the second. Or a Blender screen, with multiple orthogonal views on the left and a full preview (maybe even live with enough grunt!) on the right. The list goes on...
So that's how I would use two screens. But what of this claim that it can be counter-productive? Because in many of the offices I have seen people with two screens, they have one screen as their primary workspace (often Word or Internet Explorer) and the second screen is a maximized window running Outlook.
It has been thoroughly documented how constantly checking your email can damage your prodictivity. In this age of instant communications, mobile phones, text messaging, instant messaging, Skype, pagers, Blackberry, email - people are instantly reachable in a wide variety of ways. But it's certainly not always good to be constantly and universally interruptible, or even welcome.
Imagine you are working intently, you are in the zone, you are productive and concentrating on your work. A single distraction can take you out of this productive zone, and it can take a good 10 minutes to return to your productive state. If you get distracted as little as 3 times in 1 hour, this can effectively halve your productivity! You will spend more time trying to return to your working context than doing anything useful!
So why do people actively invite distractions by having a 30" window full of messages demanding their attention, sitting there begging to be read? Making a "bing" sound with each incoming missive? Or worse - a cheery "You've got mail!" They are sacrificing 50% of their workspace to something that will inevitably gnaw away at their attention, and thus drastically reduce their productivity.
These are often the same people who have their inbox set to refresh every 10 minutes. Now unless you are a member of a crack emergency response team and wear a uniform with lots of pockets and reflective stripes, do you really need such a frequent and intrusive messaging system? The world probably won't fall apart if you don't respond to the latest "hey have you seen this?" or "who took my lunch from the 2nd floor fridge?". The number of emails that actually require response times in the order of minutes are, if we are honest with ourselves, negligible.
So - the advice from your humble author is: close your email client, and only check a couple of times a day. If you schedule breaks to deal with emails, your working sessions will be longer and more productive. Provided of course, you can keep away from certain other distractions. (Yes, I'm looking at you, Michael...)
I direct all kind readers (especially those of you who have your inbox refreshing in anything less than 1 hour intervals) to Merlin Mann on productivity and distractions. There is a veritable gold mine of useful articles and tips on his site.
There are two significant aspects to Microsoft's recent announcement regarding Office:Mac (see MacWorld coverage).
First, the good news: Office Mac is going Universal, so MacIntel users will have a native build for their new MacBooks and Mac Pros. Good news, which should be reassuring for the long-term viability of the product.
But almost as an aside, the announcement mentions that MS will be dropping VisualBasic support from Office:Mac, making it not quite as Universal. Now, I'm not exactly the biggest VB fan in the world, as anyone can attest. But I do know that an awful lot of businesses rely (for better or worse) on large, complex macros and VB scripts to stitch together their business processes with Office documents. This undermines the ability for a Mac user to fully and equally participate in an Office environment that relies on such VB macros, thus relegating Office:Mac users to second-class citizens.
For example, a friend of mine works in an organisation that uses macro-laden spreadsheets to implement their timesheet and billing system. Until now, an Office:Mac user enjoyed complete compatibility with their Windows peers, and one could freely use a Mac if they so preferred, and still participate in the Office document economy. No longer... will they be forced to switch to a PC now, just to fill out a form? Or maybe switch to OpenOffice.org?
Update 14-Aug: A very insightful and honest post from one of the lead developers on the Office:Mac sheds light on the matter and the reasoning behind the decision, including lots of technical detail. Apparently the developers faced some very tough decisions on how to support VB going forward into Universal support. They are painfully aware of the impact of the decision on users, but are limited by time and resources.
It turns out that the VisualBasic front-end parser builds a series of opcodes from the macros. These opcodes are then processed by the engine backend that generates assembly code on the fly, doing all sorts of complex register allocation, variable mapping and so on. All this is obviously highly architecture-specific, thus making portability a nightmare.
Also, the Forms module (the GUI component of VBA) does all sorts of funky tricks, like swapping vtable pointers of C++ objects and features lots of custom assembly code.
Apparently the Office:Mac codebase has sufficiently diverged from the original Windows codebase that porting the newer implementation would be just as problematic, as even the object model is different, and the features between the Mac and Windows versions are not in sync.
To make matters even worse, this part of the codebase was written before most of the current developers joined the project, so there's hardly anyone left who actually fully understands how this code is designed and how it actually works. They have been trying to hire more developers for some time, without much success.
As a developer (who puts a huge amount of effort into writing portable code), one inevitably ends up questioning many of the design decisions that led to this path, as it seems standard practice for Microsoft to bake in features that are inherently non-portable (and potentially just difficult to maintain). But it's easier with 20-20 hindsight, and the MacBU at Microsoft are obviously doing the best they can under the circumstances. So if you're a Mac developer in the northwest, why not check out positions at Microsoft? Millions of Mac users would be grateful...
Properties and settings dialog boxes in Windows used to be application-modal, and you couldn't see the effects of the change until you hit Ok. Nearly all the dialogs had the familiar triad of Ok/Cancel/Help. The meaning was straightforward and clear: Ok accepted the changes and closed the dialog, while Cancel reverted the changes and closed the dialog.
But in recent years, Windows has changed: the Help button has been hoisted up into a more discrete question-mark in the top corner (if it is available at all), and another button has joined the familiar Ok/Cancel: the Apply button. What's so bad about that?
The intention was that Apply would effect the changes, while keeping the dialog box open. That way, the user could see the changes applied in the document window behind and continue to make more changes (or revert changes just made). If you were happy with the changes, you could still just press Ok: the Apply button was simply a convenience to enable the user to effectively make a series of changes in discrete steps. (This was before the more modern trend of modeless dialogs that instantly apply the changes, but that's a whole other usability discussion.)
Conceptually it seems clear enough - Apply is simply the complement to the action of Cancel, as this table shows:
Action Close? Change? --------------------------- Ok Y Y Cancel Y N Apply N Y
Yet this has only served to confuse users, as there are now two slightly different ways to effect your changes: via Ok and via Apply. And so I have seen this confusion demonstrated, as I have watched users on literally dozens of occasions playing out the following set of actions: they go into a dialog, make their changes, then press Apply, and then immediately press Ok! This completely redundant pressing of the Apply button reveals the erroneous underlying mental model: "if I don't press Apply, my changes will be lost!". And when I see people doing this, the action is performed in quick succession, as a rote step, a learned behaviour or strategy. The reasoning goes like this: if there is a button to apply the changes, and I don't press it, my changes will be lost. Add to this the confusion that clicking Apply will (usually!) disable the Cancel button, because now you can't back out of the changes. The scope of the changes is no longer the scope of the dialog.
So by adding the ability to Apply changes without closing the dialog, confused users have developed this cargo-cult approach to working with settings dialogs.
Users would be better off with a more straightforward model: one way to save changes, one way to abort changes. If a developer wants to provide instant feedback, it would be better to have a modeless dialog, or use other approaches to settings.
As part of the developer festivities at this year's WWDC, Apple made several significant announcements on the Open Source side of things. Projects such as WebKit, Launchd and Bounjour are up on MacOSForge, and published under the liberal Apache license.
But what really caught my eye was the new Darwin Calendar Server, aka Collaboration. And what's more, it is written in Python using the Twisted framework. Excellent!
It implements the CalDAV protocol for collaborative scheduling, and supports multiple client packages such as iCal, Sunbird and Outlook. The documentation also refers to an intriguing new product called "Teams", which seems to be part of the new Leopard Server.
Another significant announcement was that the source to the Intel-based Darwin kernel has now been published. Apple copped a great deal of flack in recent months, as it had not published the sources since the release of the Intel-based Macs. This fuelled speculation that it was to counter efforts to make Mac OS X run on non-Apple hardware, and that it had effectively become a closed project. Well, no longer - xnu is now published, and people can build their own kernels once more (great for people running clusters, for example).
