Stupid Calendar UX

Here’s something I don’t get about calendaring software, that I cannot believe Microsoft has not figured out —

Let’s say you have a meeting that starts early in the morning on Mondays, Wednesdays, and Fridays. Someone creates the recurring event in Outlook, and sends it around. Why the fuck doesn’t Outlook, or whatever, create two reminders for you automatically?

Based on the average starting and stopping times in a work day, and the definition of an average working week (Monday to Friday), why do these stupid calendaring programs not —

  1. create a reminder that goes off 15 or 30 minutes before the event starts
  2. create a reminder that goes off 18 hours before the event starts, i.e. shortly before the end of the previous working day (or on Friday, if the next working day is Monday?)

I really don’t get it, is this tricky? The User Experience on the world’s calendars is stupid, when this isn’t happening. As a personal example, this very problem bit me in the ass this week at work. We’d defined a new meeting, along these early morning lines, and I missed the first meeting in the series. Had I been usefully reminded before leaving work the previous day, this probably wouldn’t have happened. I know it sounds a bit like kicking the dog, but seriously, is this that hard to implement?

I noticed the same issue when I was leaving work this evening. Because I’d set the whole event-series reminders to trigger 18 hours ahead of time, it’ll go off on Sunday evening, when I’m not at work. (No, I don’t sync my work calendar with my phone, I’m not that important, nor do I want to mix business and personal syncs.)

Xamarin’s Installer Needs Help

Variations on a theme, I’ve been trying to get Xamarin Studio up and running on Windows 7, and it is a royal pain. I don’t think they test it using Standard User accounts on Windows, because there is a huge a number of problems here.

  • First and foremost, the Xamarin Studio shortcut is installed only in the installing account’s profile, which is by default an Administrator’s account. It’s not installed for All Users, so you can’t see it as a Standard User. You’ve got to create a shortcut to the executable in the C:\Program Files (x86)\Xamarin Studio\bin folder.
  • If you start Xamarin Studio as a Standard User, it cannot find the connected Android devices. Android Debug Bridge (adb) doesn’t seem to be started in a way that lets it see them. However, if you’re using Google’s Android Studio as a Standard User, it works just fine, so it can’t be a permissions problem.
  • The Xamarin installer downloads a separate 32-bit Java 6 JDK, even though the 64-bit Java 8 JDK works just fine now with Android. Worse yet, you can try as much as you want to point Xamarin to your system-installed Java 8 JDK, and it will absolutely refuse to use it. This seems to be related to a 64-bit vs. 32-bit issue, however, as I stepped my JDK down to 32-bit Java 7, and Xamarin seems to be ok with detecting it.

After futzing around with all of this stuff as a Standard User, I seem to now have a working system. The specific configuration that works for me on a 64-bit Windows 7 desktop, is to do all of the following as an Administrator user:

  • Install Android SDK for All Users to C:\Program Files (x86)\Android\android-sdk.
  • Unpack 64-bit Android NDK to C:\Program Files (x86)\Android\android-ndk-rxxx.
  • Install 32-bit Java 7 JDK.
  • Set ANDROID_NDK_PATH=C:\Program Files (x86)\Android\android-ndk-rxxx, where xxx is whatever revision they’re up to now.
  • Set JAVA_HOME=C:\Program Files (x86)\Java\jdk1.7.0_xx, where xx is whatever point release they’re up to now.

Then, run Xamarin Studio as your Standard User account, and set the SDK Locations to:


With any luck, Xamarin Studio should have picked up the locations automatically, via the environment variables. With all of these items set, the build should now work properly and adb should pick up the connected device. And you don’t have to run your system as an Administrator, or do any other hokey things to get Xamarin to work.

But the fact is, Xamarin asks you to install it as an Administrative user, but it shouldn’t actually need any special administrative rights to do its job. Or, if it does (to install a JDK, for instance), then it doesn’t need those rights any longer once it is installed. For instance, it installs its own copy of the Android SDK in the Administrative user’s %APPDATA% folder, which it could just as easily do in a Standard User account.

Overall, they are assuming that everyone out there uses a single Administrator account on their computers, and I suppose that’s a pretty safe guess, except for when it’s not the case. I get the impression there are probably other devs out there who don’t run around as Administrator, because we know just how bad of an idea that is (even with User Account Control).

(Parting thought: I’d be willing to bet even money that the Xamarin installer works without a hitch on OS X, because that seems like the place most devs spend their time these days, if the Berlin coffee shop scene is any indication.)

Windows 7’s Updater Sucks

I reinstalled Windows 7 from a recovery disc recently and have had to suffer through the seemingly drawn-out process of applying all the patches via Windows Update. After failing to install Service Pack 1 for Windows 7 a number of times, the Service Pack installation finally succeeded, and I was then greeted with the option to install 164 other patches.

Seriously? I wish Microsoft could figure out a way to slipstream the install, or just do like Apple does and download the latest operating system image before doing a clean install*. There has to be a way for them to know what the state of the system should be, given patches X, Y, and Z (to infinity) have been applied. Maybe they could treat the Windows system directory as a super-secret / protected storage area that they can just update bitwise with binary diffs (you know, like real firmware). Maybe they should stop differentiating their operating system features so much and just unify them into 2 versions with no subversions (Home and Business). It’d certainly make it easier to unify what the operating system actually needs to install.

And if they still can’t do this, if they still can’t override the inertia of useless business units and middle management (seriously, who came up with Windows Home Premium versus Ultimate, and why? What benefit was it to all users to sell a crappier version of your OS, en masse? The incremental price for one additional unit of software is what, exactly?), they should get one of their people at Microsoft Research to figure this out. It’s only a few million man hours per year of wasted time at stake.

What an utter waste of bandwidth and time, not to mention the wear and tear on the hard disks of the world.


As it chugged through the 164 patches, I also noticed that the memory usage on my system seemed to be rising inexorably.

And wouldn’t you know it, Process Explorer told me this:


That’s right. The Trusted Installer component felt the need to consume over 4 gigabytes of memory during the update process. Why? I have no idea, but screw you for asking! Seriously, does nobody test this stuff in Redmond?

Thank goodness my system has 8GB of RAM, or who knows how badly the system would be swapping right now.


And of course, right after I finish that big batch of updates, after the next reboot, Windows Update tells me I have 21 more:


I feel like I’m living Zeno’s Paradox. It’s a mathematical certainty that I will reach my goal, but from the halfway point it certainly doesn’t feel like it.

*I know, I know, I’m not a huge fan of Apple’s Software Update system either, why they can’t do binary diffs like Google or JetBrains can, doesn’t make sense to me.