Zoom background #15


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 html.data.unityweb
-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.

I am the reason for Hungarian notation in Android

I am the reason for Hungarian notation in Android

You know, this:

private String mName;

That’s because of me.

There, I said it. It’s my fault.

This topic comes up on a regular basis and more recently, this reddit discussion reminded me that I had never really explained how this notation came about and also, how much misunderstood Hungarian Notation is. So I’d like to take this opportunity to clarify a few things, and I’ll do this in two parts:
1. How the m notation came about.
2. Why you probably don’t understand what Hungarian Notation is.

The m convention

I was one of the early engineers working on Android and within a few months of the project, I was tasked to come up with a coding convention style guide for Android API’s (ourselves, the Android team) and user code. We still had very few Java developers on the team at the time, so addressing this problem while the amount of Java code in Android was still reasonably small was a top priority.

When it comes to identifying fields, I come with a bit of a bias myself. At the time, I had written a decent amount of Java, Windows and C++ code and I had found that using a specific syntax for fields was very useful. Microsoft uses m_ to that effect, while it’s common to use a leading underscore (e.g. _name) in C++. Ever since I started writing Java code, I had always been bothered by the fact that Java did away with this convention.

But my task was to write a Java style guide and one of our goals with Android since day one was to create a development platform where Java developers would feel extremely comfortable.

So I put my bias aside. I took some time reviewing both Sun’s and Google’s own internal Java coding style guides and I came up with our own Android style guide, which was pretty much 99% what these two style guides proposed but with a few very tiny changes.

One of the difference I remember clearly was regarding braces. While both style guides require to use braces for everything, I introduced an exception when the continuing statement can fit on the same line. The idea behind this exception was to accomodate for the prevalent logging idiom in Android:

   if (Log.DEBUG) Log.d(tag, "Logging");

Without this exception, log statements would take up a lot of vertical screen space, something we all agreed was not desirable.

So that was the first version of our style guide, and that guide did not contain any requirement to prefix fields with anything.

I sent the guide to the team and, to my surprise, everybody pushed back very hard on it, precisely because it didn’t mandate any syntax for fields. Everybody felt that fields needed to be differentiated and they wouldn’t accept a style guide that didn’t have such a prescription.

So I went back to the drawing board and researched various ways to make this happen.

I considered _name and also m_name, as mentioned above, but rejected them because the underscore was too much of a detraction from Java’s standard. I came across a few other, more exotic notations (such as using the “iv” prefix, for “instance variable”) but ultimately, I rejected them all. No matter what I came across, the “m” prefix stuck with me as the most sensible and the least verbose.

So what was the obvious solution? Keep the “m”, remove the underscore and use camel case. And thereby, mName was born.

This proposal was accepted by the team and we then made this notation official.

You probably don’t understand Hungarian Notation

Whenever a discussion comes up about Hungarian Notation (HN), I notice that most people seem to think that whenever you add some metadata to an identifier, then it’s automatically HN. But this is ignoring the core concept behind HN and the very deliberate design that Simonyi put into it when he came up with this notation.

First of all, there are a lot of different kinds of metadata that you can add to identifier names, and they all belong to a different category. Here are the categories I have identified so far (there might be more):

  • Type information.
  • Scope information.
  • Semantic information.

Let’s review these in turn.

Type information

This is probably the most widespread use of identifier metadata: naming the identifier so that its type can be inferred. This is used everywhere in Win32/64 code, where you see names such as lpsz_name used to mean “Long Pointer to String with a Zero terminator”. While this notation seems to be extremely verbose and reader hostile, it actually quickly becomes second nature for Windows programmers to parse it, and the added information is actually very useful to debug the many obscure bugs that can happen in the bowels of the Windows system, mostly due to the very heavily dynamic nature of a lot of its API and the heavy reliance on C and C++.

Scope information

This is what’s used in Android: using the metadata to indicate what kind of variable you are dealing with: field, local or function parameter. It was quickly apparent to me that fields were really the most important aspect of a variable, so I decided that we wouldn’t need further conventions to discriminate local variables from function parameters. Again: note that this metadata has nothing to do with the type of the variable.

Semantic information

This is actually the least used metadata information and yet, arguably the most useful. This kind of discrimination can apply to variables of identical or similar types, or identical or similar scopes, but of different semantics.

This convention can be used when you need to differentiate variables of similar types but of different purposes. Most of the time, a sensible name will get you there, but sometimes, metadata is the only way out of this. For example, if you are designing a GUI that lets the user enter a name, you might have several variations of widgets called "name": an edit text called ("textName"), a text view ("tvName"), buttons to validate or cancel ("okName", "cancelName"), etc…

In such examples, it’s important to make it clear that these identifiers all relate to the same operation (editing a name) while differentiating their function (the metadata).

Hopefully, you should have a more nuanced view of Hungarian Notation now, and I strongly recommend to read Joel Spolsky’s “Making wrong code look wrong” article on this topic, which should help drive all these points home.

So, what do you really think about Hungarian Notation?

First of all, I think we need to stop using the umbrella name “Hungarian notation” because it’s too vague. When asked this question, I usually ask the person to clarify which of the three options listed above they are talking about (and most of the time, they’re not even sure and they need to think about it).

I’ll just use the term “identifier metadata” to describe the general idea behind adding information to a simple identifier name. And overall, I think this approach can have merits on a case per case basis. I don’t think it should be the default, but it’s definitely useful, especially in the GUI example that I described above. I find this kind of occurrence on a regular basis and not using identifier metadata for this kind of code leads to code that’s harder to read (both for the author and future readers) and to maintain.

I also don’t accept the argument that “Today, our IDE’s can distinguish all these identifiers with colors so we don’t need any of this any more”. This argument is flawed for two reasons:

  • Code is often read outside of IDE’s (starting, ironically, with the screen shot of the reddit discussion, whic has no highlighting). I read code in browsers, window terminals, diff tools, git tools, etc… Most of them don’t have the capacity for the kind of highlighting that would make parsing the code easier, so a light touch of identifier metadata can help a lot there.
  • IDE highlighting will still not help you make sense of ambiguous cases such as the GUI example described above. There are still cases where you, the developer, know more about your code than the IDE can ever know, and adding identifier metadata is then the only sensible choice you can make.

Don’t listen to people who tell you identifier metadata should never be used, or that it should always be used. This kind of naming is just a tool in your developer toolbox and common sense should make it relatively easy for you to determine when it’s the right time to add some metadata to your identifiers.

Finally, I often see very extreme reactions on this issue, and code conventions in general. Over the 30+ years that I’ve been writing code, I have noticed that it only takes a few days of working on code following a certain convention to completely accept it and stop noticing it altogether. There were times where I couldn’t tolerate code that is not indented with two spaces, then a few months later of working on a project with four space indentations, I felt the opposite. Same goes with naming conventions. You will get used to anything as long as the conventions are being followed consistently across the code base you are working on.