I got a new tool in my tool box: KeePass HotKey is a wrapper utility to open a KeePass DB or trigger the Auto-Type Feature.

This utility is very specific to my use case:

  • I want to trigger one action from a dedicated hardware key on my keyboard
  • This action should either open a specific KeePass data base file, configured by the user, or
  • Trigger the “auto-type selected” feature of KeePass, if a KeePass instance is open, running, and has a selected entry.

You can find sourc code and released binaries at Github.

Hello everyone!

I am a bit late, but: Happy New Year!

And boy oh boy, this will be a year. I am so looking forward to what’s coming. Likely, the most important reason for me being happy at this moment is: I got a new job. Exactly with the new year, starting with January 1st:

I am now a Senior Software Developer at Microsoft’s Mixed Reality Team.

I am still in the middle of my on-boarding. This opportunity is great. I am grinning every morning when I switch on my workstation. And, until now, no day disappointed.

This will be a great year!

Today I present you the Checkouts Overview tool.

https://github.com/sgrottel/checkouts-overview
https://go.grottel.net/checkouts-overview

What? Why? Because this little tool helps me.

In my private setup, I have a lot of smaller repos checked out, and work on them only occasionally. In addition, I got several repos to collect the history of some text documents. Some of those repos are synced against servers which are only occasionally online, partially for power saving or partially due to VPN and network connectivity stuff. As a result, I often keep losing track of the sync states of all the different repos.

Is everything checked in? — most times, yes. If the change was complete.

Is everything pushed? — maybe.

Am I on branches? — no idea.

You might not need this app, if you have a better structured work process with your stuff than I do. I don’t, so I need help by a tool, by this tool.

If you are interested, you find more info in the app’s github repository.

Note: and as for the app’s icon, it’s about (repository) clones, right.

This is my second article in my series around application icons and logos. This time I want to write about colors and icon backgrounds.

Icon Color Design

Icon shape and color is most of the time defined by a corporate identity. There is then little room for creative freedom in the concrete implementation of an application icon. And, that is a good thing. Visual consistency and memorable colors and shapes are important for a brand identity to be burned into everyone’s memories. Think of the Golden Arches. I bet you can now almost taste the greasy fries.

So, designers working on an icon representation of a product or a company will, on the one hand, need to adhere to a lot of inflexible conditions dictated by the corporate identity, and, on the other hand, will try their best to create an icon usable in many situations.

I will use an older application Icon of FARO® SCENE as an example:

This icon nicely follows the design guidelines and provides a nice compact representation of the product. Some exemplary details:

  • The “S” is based on the full product title brand guideline,
  • The circular border is based on the FOCUS laser scanner brand guideline, and
  • The colors follow FAROs brand guideline of that time.

To account for some flexibility in usage the icon was designed for white (bright) background and dark (colored) background. Not an unusual approach. You can often find this approach if something is designed for digital media and print media.

And all is well, right…

Background and Shape

… More like “no”.

While the idea of having variants of an icon for different backgrounds is valid in general, it is not valid for application icons. An application is one executable binary file. With one representative icon embedded. In most scenarios, there is no way to select variants.

And, to make things worse, the icons will be used on all kinds of backgrounds. Think of a personal computer with a desktop background image chosen by the user. It can be anything in color! And as a result, the icon will need to be compatible with anything. The original FARO icon was not.

The only viable option out of this is to explicitly include a background color as part of the icon. The first versions of that icon did just set the background color.

This does work, to make the icon appear as designed. But it also completely disconnects the icon from the surrounding. The icon is not really part of the desktop or the start menu. It feels like a foreign object. Not nice.

The solution is not that hard to imagine: include the background in the icon. … Did you see what I did here? Do not just “include the background color”, do “include the background.” That is color and shape! Make a part of the background yours. An easy way to do this, is to use a background shield following the shape of the icon itself, often a circle, but sometimes a more complex shape.

The shape of the background, following the shape of the rest, becomes part of the icon. It’s no longer a disconnected image. And, if the desktop background color and the icon background color merge, then the backgrounds merge, and the icons exists as designed. No problem at all. Very good.

And, if you want to further strength the connection of the icon with the colorful background, think of using a little amount of transparency. Don’t go overboard with that. It is easy to create something which looks strange, imprecise, and ugly, with too much transparency. A little bit is all you need. This not-current version of the Steam icon is an example which does a great job on this.

Summary

For an application icon you cannot control the background color it will be placed on. You must be ready for every color.

To still be precise in your icon design, make a little bit of the background part of your icon. Not just the color, but the color and shape. Closely align the shape with your icon to create a consistent look.

Series