Archive for category Uncategorized

Sneaky sliders

Gary Larson showing the danger of extrinsic affordance

Warning: if you are using a MacBook today, this article is likely to blow your mind by showing you something you had no idea your computer can do.

I always get excited whenever I discover a new user interface experience.

I know a lot of people claim that not much has been invented since WIMP (“Windows, Icons, Menus, Pointer”), the UX experience that was invented at Xerox PARC in the early 70s. That’s obviously an egregious simplification. Yes, we are still using the very same metaphors that the visionaries at PARC came up with fifty years ago, but a tremendous amount of UX inventions have occurred since then.

This is not the point of my post here, but since I will most likely be asked what UX innovations have occurred since then, I feel obligated to mention a few. Maybe these won’t be convincing, but at least, they might introduce a little bit of wavering into these questioning minds:

  • Flat icons. These feel pretty mainstream today, but back in the late 90s, the fierce debate around affordances (I will get back to this word shortly) made it so that if you want to have a button in your interface, that button needs to be in 3D: if it can be pushed, it needs to show a 3D border. Makes sense, right? And then one day, Microsoft changed our world by publishing a toolbar made entirely of flat icons. Which could be pushed. Madness! Yet… the user population adjusted overnight, proving that maybe, the concept of affordance is overrated.
  • Verbose scrollbar thumbs. You know how you are sometimes scrolling through a document made of hundreds of pages, using the scroll bar, and while you are scrolling that thumb in the scroll bar, you have no idea where you are? Well, one day, Microsoft (them again!) decided to add a tooltip to that thumb which indicates where you are. Today, this seems like a pretty mainstream idea but it was pretty innovative back then. Such an obvious idea today and yet totally unobvious back then. The kind of concept that nobody thinks of until someone comes up with it, and then it’s the most natural thing in the world. You can find this UX pattern everywhere today: Android, iOS, Windows, macOS, etc…

I got pretty excited lately because I came across not one but two user interface interactions that I had never seen before. And it turns out these two interactions are actually quite similar. And they violate a few basic UI laws too.

The first encounter came during my Unity project.

Unity has a lot of user interface components and many of them display discrete or continuous values (e.g. integers, floats) in text fields. Obviously, these text fields have a label, so you can identify what they represent (and these values often map to public fields in your C# code). The novelty here is even though the labels look like very standard labels, they are actually concealing a slider if you click on them and then drag your mouse:

There is no static affordance showing you what you can do with these labels (probably because even if such hints were very discreet, the whole Unity UI would immediatly look overcrowded since these text fields are everywhere. This is most likely the same reason that led Microsoft to flatten the toolbar: because all these 3D buttons make the UI look very cluttered). The cursor does change as soon as you hover over the label, though, with an icon clearly indicating that you can perform an action there.

Even though this widget breaks the affordance rule, using it turns out to be pretty straightforward and actually incredibly convenient since playing with values in this way is an extremely frequent action in Unity.

My second encounter with a new UI came from the most unexpected place: my MacBook Pro laptop. And more specifically, its Touch Bar.

The Mac Book Touch Bar remains pretty controversial and polarizing, even today. I am still not a fan and I have just grown to tolerate it, and personally, I would absolutely not mind going back to a row of good old keys. The widget I am talking about right now is the volume control.

If you are like me until not long ago, changing the volume on your Mac Book is pretty straightforward: tap on the volume icon, the UI gets replaced with a slider, move that slider, exit the volume mode.

As it turns out, the volume icon happens to be one of these “sneaky sliders”, exactly like the one I showed above in Unity:

As the video shows: if you don’t tap but actually keep the icon pressed for just a bit longer, the slider appears and you can control it directly from the icon, without having to move your finger from the icon.

This is another example of a control breaking the affordance rule, thereby making its discoverability very unlikely, but which, once identified, turns out to be a very useful UI interaction. I use it all the time these days (and obviously, it doesn’t apply just to the volume, try it on the brightness control).

I wonder how many other hidden user interface controls I am not aware of today…

Interesting reads – 07/12/2020

Zoom background #14

Zoom background #13

Text by the mile


This article resonated a lot with me, especially this part:

Writing is not the hardest job in the world, but it’s taxing enough that, like working out or scrubbing the baseboards, I’ll subconsciously drift over to any other task that requires even a little less effort.

Anyone who’s ever had to write more than a few pages know how interruptible an activity writing is.

I was extremely worried about this when I had to write my PhD thesis many years ago. The Internet wasn’t quite there yet but computers were already replete with enough distractions that I was concerned I’d be constantly sidetracked and I would never see the end of it. So I made a radical decision. Well, two.

First, I decided I would not tell anyone on the team that I started writing my thesis. This was a reaction to seeing so many PhD students over the years getting engulfed in the process of writing to the point that it was all they could talk about. Morning coffee, lunch, random moments during the day: everything was about how many pages they had written today, their struggle with their word processor, how deflated they were, thinking they’d never make it. I decided I would do none of that.

Not only did I stay silent about it, I also made the decision to not work on my thesis during the working hours. At the office. I knew it would be a lost cause anyway, so I just focused on either work related tasks or some personal projects. Needless to say my teammates never missed an opportunity to make fun of me for not working on my thesis, but I was smirking inside.

But the crucial decision that I made was that every night, I would spend a few hours at home writing my thesis, and more importantly, I would write my entire thesis on a simple text editor. I can’t recall if I used Notepad or something like that, but I can assure you it was a very barebones text editor that could not even format in bold or italics.

My goal was to “write miles of text” and not be distracted by anything else. Especially not formatting (which can take such a long time), let alone arranging chapters or sections, or rereading what I wrote. I allowed this cursor to go forward only, and nowhere else.

I am not the right person to ask if my final thesis was of good quality or not, I leave that to my then advisors, but I can assure you that I was able to put together 200 pages in probably the least amount of time I could. And ever since, I have made a point of following this simple guideline whenever I sit down at the keyboard to write a sizable amount of text and I strongly recommend it to anyone who’s ever faced the dread of an empty page.

Separating the content from the form. It’s worked pretty well for the web, and it turns out, it works splendidly for writing too!

Zoom background #12

Months ago, I decided to change my virtual Zoom background every week to keep my colleagues entertained. I have failed to post them so far, so trying to start now. Here is this week’s:

This is a scene from Hayao Miyazaki’s wonderful “Spirited Away”.

But there is more to this picture than meets the eye.

This is not the real scene. Here is the real scene from the movie:

The problem with that scene is that on Zoom, my face would cover the two protagonists, which defeats the purpose. So I took advantage of this problem to accomplish my goal #3 for the Shelter In Place period: learn how to use Photoshop.

I am happy to report that after a few hours, I was able to master enough basics of Photoshop to cleanly separate Chihiro from her ghost friend, moving them apart, and even preserving backgrounds and transparency (see how Chihiro’s legs appear behind the ghost in the foreground in that first picture? Pretty proud of that one).

Stay tuned for more Zoom backgrounds (I’ll try to post every new one each week and maybe post some of the other ones I’ve used these past months).

Supraland is a real gem

I recently finished Supraland, what a gem of a game.

Don’t mind the intro video, which turned me off at first: it compares the playing area of Skyrim and GTA V to that of Supraland and you end up thinking Supraland is minuscule. This game has a lot of content.

This is a puzzle game which I would describe as a gentle and logical mix of Myst and Portal. I have to insist on the “logical” aspect: the puzzles are fantastic and all make perfect sense. I only looked up a couple of hints and I facepalmed both times for not thinking of these solutions myself.

Supraland keeps pushing you forward by progressively giving you new odd devices that unlock new kinds of puzzles and force you to look at previous areas in a totally different way. On top of being a lot of fun, this game is a completionist’s dream. It took me about thirty hours to finish, and by then, the game teased me that I was only at 55% completion with more than 80 chests left to find.
Supraland is a one man show: it was basically done by David Münnich, which I find incredibly impressive and humbling.

A DLC is on the way and Supraland 2 is already funded on Kickstarter.

Writing my first game in Unity

… and how I eagerly embraced my repressed hunger for writing ugly code

I have been wanting to write a game for a very long time, probably forty years or so. I even dabbled into it when I was a teenager and took my first steps in BASIC and 6502 on my Apple ][, but I never went really far. This prolonged shelter in place that we are currently going through was the perfect opportunity for me to make the resolution to write a game in Unity and see how far I can go.

The result can be found here and it looks like this:

It’s been a very interesting experience and I learned tons of things.


I could have written this game in a few hundreds of lines in any language really (I would probably have picked Typescript), but where is the fun in that? The point is to learn about game development, and these days, there are really only two players in that Arena: Unity and Unreal Engine.

I ultimately ended up going with Unity because Unreal Engine’s support for C# appears to be more recent and also because Unity seems to be the standard in the industry. Having said that, a large amount of the games I’ve played these past few years have been created with Unreal Engine, so there is no doubt that both of them are extremely powerful game engines.

I have been keeping track of C# loosely since its inception, almost twenty years ago. It’s always been an appealing language to me and the only reason I only ever wrote toy programs in it is that both my work and personal interests have never been completely focused on the Windows ecosystem. Overall, it was very easy to dive into the language and .net is replete with expressive standard libraries that make everything easy.

Having said that, C# feels a little bit antiquated after almost ten years of Kotlin. Nothing wrong with that, Kotlin benefited a lot from the hindsight of C# and other languages, but once in a while, the constructor syntax or the limitations of C#’ enum construct got mildly annoying. Nowhere near a deal breaker, though, but I thought it was interesting how two languages that are ten years apart are a testimony of where the state of the art in programming language theory has been moving.

Also, C# evolves very quickly and the latest announced version, 9, will be including some of the niceties that I’ve become spoiled with in Kotlin.

Visual Studio is a very competent IDE and I suspect that the few occasional friction points I have encountered have more to do with the long time habits I have developed with IDEA than shortcomings of Visual Studio itself.

The integration between Unity and Visual Studio has been working seamlessly for me: I have both tools open all the time and I can easily break into my code whenever I feel like it and inspect everything. There are still a few areas that I haven’t quite managed to make work (such as being able to enter manual expressions of C# in the context of my break point), but this is more due to my lack of familiarity with Visual Studio than anything else.

Game writing

Writing a game has always been intimidating to me because I’ve always felt that my brain is not wired for it. I have a default habit of not thinking too much about performance, or at least not until it really starts to matter, and to follow well documented and established design patterns in software engineering. These two focuses are a bit at odds with game development since performance is always a huge factor in game writing, and this strong focus often impacts the code and forces the developer to break good practices in order to reach the necessary speed.

Obviously, performance is not really a factor for the toy game I set out to write for this exercise, and I have to say that I felt it quite liberating to not have to overthink the architecture of my code either. I have felt little shame in exposing fields publicly and tightly coupling classes and objects in ways they really don’t need to be. But I felt okay with this because I decided that finishing the game was priority #1, and everything else is secondary.

Another lesson that became quite clear to me is that a game is never finished.

As someone who’s been playing games for about forty years, this is not exactly a revelation, but looking at this from the author of the game’s perspective instead of the player, I was quite surprised to realize that as soon as I reached what I had arbitrarily decided what version 1.0 was going to be, I already had a dozen items in my mind of how I could improve and expand this very simple game.

State machine

Games are operating on a different life cycle than regular applications.

Well, not *too* different, since they run inside a container with life cycle functions, just like a web server, a mobile app, or an application server, but the emphasis is different.

There is what is called the “game loop”, which, depending on the engine you are using, might take various forms, but fundamentally, they all share the same characteristics: one function in your code is going to be called extremely often. This function is where you get a chance to update the state of your world: move animation one frame forward, calculate collisions, update the world, etc…

If you want the player to have a smooth experience, you want this function to be called at least sixty times a second, which means the code inside it needs to complete within 17ms. Entire books have been written on the topic of how to optimize your game loop, so I’m not going to get into this, but this is yet another fascinating new perspective for someone like myself who’s just used to write mobile apps or back end apps.

The simple pattern I ended up converging toward was that any event happening in my game (e.g. a collision) makes a change in the world as fast as possible (e.g. transitioning to a state), but that change is actually processed in the update function. For this to work efficiently, you quickly reach the conclusion that your code is slowly going to turn into a giant state machine.

My mind immediately started racing once that realization dawned on me, and I started imagining all kinds of ways in which I could rearchitect my code to accommodate both a state machine and being easy to maintain and refactor.


It’s always seemed counter intuitive to me to write a game while being so tightly entangled with an entire studio. The source of your game is literally the combination of C# source code and also entire panels and screens specified in Unity. This looked deeply unsettling to me until I realized that I already depend heavily on an IDE to write my open source and work projects (IDEA), it’s just that Unity is pushing this concept one step further.

I used to write Windows COM code in the early days of that technology and for those of you who remember, the IDE was generating thousands of lines of boiler plate code in an attempt to hide the inherent complexity of developing a COM application in C or C++. I was concerned Unity was going to steer me down this path again, but that fear turned out to be unfounded. I have gotten accustomed to the idea of tying up my game tightly to Unity and trying to embrace it. And once you get over the business logic aspect of it, there is no denying that being able to manipulate scenes and objects with a real graphical editor is invaluable.

Dependency injection

Objects are organized in graphs in Unity, pretty much like any regular application, except that this graph is prominently and constantly displayed for you, which is very convenient. You are free to organize in any way you want, and that hierarchy can make sense from either a graphical or business logic standpoint. What was new to me is how objects can refer to each other.

Unity’s solution to this is interesting. You can either look up objects dynamically (e.g. GetComponentOfType()), or statically. When that connection is statically, you simply declare a public property in your script:

public GameObject TopWall;

When you return to the Unity window, your new code is automatically compiled and a new field has appeared in your UI, under that script:

That new field is empty, so all you need to do now is select that object from the graph and drag and drop it into that slot. Pretty effective way to bind your objects together.

You can also select that object from a list of the objects you have created.

The old way and the new way

The standard way to build games in Unity is making heavy use of inheritance and polymorphism. All your objects inherit a standard base class MonoBehaviour and you will typically override methods such as Start() or Update(). This allows you to get up to speed very quickly.

These past years, a different pattern has emerged in game programming called the Entity Component System. In this model, you replace inheritance with composition and decouple the data from its behavior. I’m not going to go too deep into this since there is a voluminous amount of documentation available, but in a nutshell, in this model, decoupling the data from the behavior of your objects produces entities that have the ability to visit a subset of your game objects by defining a filter and then apply behavior to them.

This approach allows the system to heavily parallelize your game updates, including on your GPU, which allows you to create and animate tens of thousands of objects with little effort. Unity supports ECS but there is some legacy baggage that makes this approach a bit awkward from what I’ve seen.

Friction points

Needless to say I encountered quite a few hurdles on my beginner journey. I am pretty sure these are all my fault and not Unity’s, but here are a few:

  • The web is filled with Unity tutorials and most of them are outdated. They show older UI’s or make recommendations that are no longer the correct way to develop games.
  • The 2D kit that I tried to use, and which allows you to add bone and skin animations to sprites, was pretty buggy to me, with weird behaviors and undocumented steps that I had to puzzle out by myself. Considering how central 2D physics are to Unity, I was quite a bit surprised by how fragile that whole system appears to be.


I was very curious to find out how big my game would end up being once built for the web. The amount of packages and assets that are included by default in my project was quite daunting, so I was wondering if I wasn’t going to end up with some copy of the entire .net runtime on my website.

~/dodger$ ls -l Build
total 8016
-rw-r--r-- 1 ubuntu ubuntu  159307 Jun  3 15:04 UnityLoader.js
-rw-r--r-- 1 ubuntu ubuntu 2168234 Jun  3 15:04
-rw-r--r-- 1 ubuntu ubuntu     500 Jun  3 15:04 html.json
-rw-r--r-- 1 ubuntu ubuntu 5779835 Jun  3 15:04 html.wasm.code.unityweb
-rw-r--r-- 1 ubuntu ubuntu   87452 Jun  3 15:04 html.wasm.framework.unityweb
~/dodger$ du -sh .
8.0M    .

The entire WebGL application adds up to 8 MB. Not great. Not terrible.

Probably a little on the heavy side from a purist standpoint, but considering all the support that I got from free, including the freedom of not having written a single line of Javascript, I feel pretty content with the trade off.

Take aways

This little project has opened my mind to a lot of possibilities, starting with the fact that I feel very comfortable writing games now. Not AAA 3D games, mind you, but whenever I see or play a game now, my mind immediately starts breaking it down in ways I’d design it in Unity, and suddenly, it all seems a lot less daunting.

This experiment was also a good opportunity for me to learn some basic Photoshop skills, something I’ve always wanted to do but never got around to doing.

If, like me, you’ve always been curious about game programming but you’ve never gathered the time or the courage to jump in, I can strongly recommend taking that step, especially since Unity turned out to be a lot less intimidating than I initially thought.

How to "Go Home" on your Verizon Droid (and Android in general)

As you probably know by now, Verizon’s Droid has been officially announced and it will be available in the US on November 6th.

It’s running Android 2.0 (“Eclair”), which is by far the most advanced release we have worked on. And in case you didn’t follow, this is the third official release in about a year (there has actually been one more that was never made official).

One of the features that has received the most coverage so far is our turn-by-turn navigation application, which turns your Droid into a speaking GPS device. While most articles I have read do a good job of covering its basic features, some articles deplore the absence of a “Go Home” function.

Well, actually, this function already exists.

It’s very simple really, all you need to do is create a home shortcut. Here is how you do it:


Long press on the Home screen, select Shortcuts and then Directions.

Make sure that “Turn by turn navigation” is checked.
Enter your home address (or any other),
pick a name for your shortcut and press “Save”.


Your shortcut is ready, tap it to start navigating.

Happy navigation on your Droid!

Duct tape and the brittleness of agility

Duct tape, reloaded

In a recent article, Joel Spolsky discusses the concept of the “duct tape programmer”. According to Joel, a duct tape programmer is a developer that “gets things done”. They don’t spend too much time over designing, discussing or writing tests: they just sit down at their desk and code until the feature is ready to be used by customers.

Joel uses Jamie Zawinski (jwz) as the perfect example of a duct tape programmer. For people who don’t know jwz, he was made famous during the Lucid/XEmacs/Netscape era. He was known for never sleeping and tirelessly being busy coding. His contributions include vast portions of XEmacs (in C and Lisp) and countless features in Netscape. He retired from coding a few years back, bought a club in San Francisco which he uses to organize events. His web site still shows his undying geekdom and if you’ve never had a chance to read about them, check out some of the pranks he came up with during his tenure at Netscape.

jwz is the perfect example of a duct tape programmer and the kind of developer that Joel would want on his team, as opposed to “software astronauts” that spend more time discussing problems than implementing solutions.

Clean Code is code that hasn’t been run enough times

Not surprisingly, Rob Martin didn’t like Joel’s article. Although he tries to be civil and compromising, Rob is pretty much at the other end of the spectrum when it comes to software development. In particular, Joel’s emphasis that testing should come second since it doesn’t directly impact customer satisfaction rings a sour note with the entire Agile community.

The funniest part in Rob’s rebuttal article was:

Programmers who say they don’t have time to write tests are living in
the stone age. They might as well be saying that man wasn’t meant to

Well, man is indeed incapable of flying, which is why we need to use devices to achieve that goal.

Joking aside, Rob’s assertion that a software product that is not tested is necessarily buggy is pure fantasy. There are thousands of software products that we use regularly that are probably very poorly tested (or poorly automatically tested), and yet, they work and they are fairly usable.

The crux of the disagreement can probably be found in Rob’s following statement:

I want you to ship, but I don’t want you to ship shit.

Nobody can disagree with this, but I bet you that Joel and Rob have very different ways of defining “shit” in the software world. For Joel Spolsky and Jamie Zawinski, “shit” is a product that is buggy or unusable. For Rob Martin, “shit” is software that wasn’t designed with TDD and that doesn’t have 100% test coverage.

In order to understand their standpoint, it’s important to keep in mind who these two people are and what they do. Joel is the founder of a fairly successful software company and their flagship product, Fogbugz, a bug tracker, seems to be quite liked by its users. Rob Martin is employed by Object Mentor, a methodology consultant company.

They both have something to sell, although it seems to me that Joel probably doesn’t expect that this kind of article will help boost the sales of Fogbugz. On the other hand, it’s important for Object Mentor to make sure that Agile, XP and the other methodologies that their business is based on, keep being discussed and cited as positive technologies that help deliver products faster.

Is Agile on the way out?

Joel’s article is just the most recent example of a growing backlash that is slowly building against Agile and XP. Here is another testimony from Mike Brunt, someone who has had a terrible experience with the practice.

Even though it’s unlikely that Joel and Mike know each other or read each other’s article before writing their own, some of Mike’s points are very close to what Joel is saying. For example:

Agile programming emphasizes coding.

This may sound like a good thing but it really is not, especially when you emphasize coding over feature #1 (shipping). Unit tests fall into that category. Unit tests are tools for the programmers. They are a convenience, one of the many ingredients that you use in the kitchen but that your customers really don’t care much about.

The extreme emphasis on developer comfort (unit tests, code coverage, TDD, etc…) over the satisfaction of your customers is something that has always deeply disturbed me in the Agile/XP movement. I have expanded in more details on this topic in my book, so I won’t repeat everything here, but there is another point that I feel strongly about: if I have time to write either a unit test or a functional test, I will always pick the latter, because such a test will exercise a feature of the product that my users will be seeing, as opposed to a unit test, which is only destined to make my life easier (i.e. find bugs faster).

Agile is fragile

The comments on Mike’s articles were not very friendly. It doesn’t take much to get Agilists riled up, and this post was no exception. However, most of these comments are all using the same old tired argument: “if you use Agile and it didn’t work for you, you were not doing Agile properly”.

This argument is very similar to the one you read whenever somebody dares to post that Linux is not working out for them: “Oh you’re using Fedora (1)? No wonder you’re having these problems, you should be using Ubuntu (2)”. Replace (1) and (2) with any of the Linux distributions and you basically have the template of the response you will see on any post that dares to criticize Linux.

This sort of answer is very similar to “Oh Agile didn’t work for you because you were doing Agile wrong”, and both these statements come from delusional people who just don’t understand that if their technology is so hard to use “right”, then it’s useless.

Brittleness in software

Linux and Agile/XP are both technologies that I call “brittle”. Brittle because you need to manipulate them very carefully or they will just explode in your hands. Brittle because you need to follow extremely precise guidelines to use them, and failure to do so dooms you to failure.

Finally, they are brittle because the amount of expertise necessary to use these technologies is simply too high.

However, Agile/XP is in much worse shape than Linux, which has quite a few success stories. Put in the right hands and used in the right conditions, Linux can do wonders, and hundreds of companies (including my employer) can attest to that. But Agile/XP doesn’t really have any track record of success to show despite many, many years of trying to become mainstream.

Ironically, the few times where I have seen a few Agile practices being successful was when the teams using them were cherry-picking from the Agile manifesto. They read all the points in the Agile manifesto, chose the practices that made sense to them and disregarded the rest. And it worked.

Agilists are not very agile

There are two paradoxes here:

  • Teams that “don’t do Agile” (i.e. they don’t follow the manifesto to the letter) can be successful.
  • The very same people who advocate Agile are actually far from being agile and open-minded. “Agile means this and no variation is allowed” never sounded very agile to me.

I know Rob Martin really believes in all these principles he advocates, but it’s really hard for me to forget the fact that he’s making a living out of them. If software methodologies become easy to apply and they no longer require a five day course to learn, his employer will go out of business.

On the other hand, while Joel Spolsky never misses an opportunity to mention Fogbugz (and I can’t really blame him, it’s what his company does), I don’t think he has much to gain from a commercial standpoint with this kind of article. I do think that he’s exaggerating his points a little bit in order to be provocative and generate indirect publicity and I’m pretty sure that Fogbugz is a lot more tested than he wants us to think.

But overall, I’m happy to see the pendulum beginning to swing the other way. Instead of advocating religious methodologies, I want to see thought leaders suggest common sense and judgment and show flexibility when it comes to recommending technologies. I think we will have reached this point when an Agile advocate comes to see me, takes a look at my team, chats with them a little bit and then tells me “I think stand-up meetings will be useful to your team but you should probably not use pair programming”.

Now, this is true agility.