I already explained the story behind the AppErgo logo in another article, but I think I skipped one step: explaining the choice of the name. With this article, I am correcting that oversight.
A name that had to evoke the project
Finding a name for a project, a brand, or a company is not easy: it has to be easy to remember and pronounce, but also evocative enough to suggest, in just a few letters, what you want to build.
Of course, it is possible to create a word with no particular meaning, then give it one through the power of marketing. However, when you do not have the means to do that, or when you want to save time, an evocative name can be a better starting point. That is why I followed this path when choosing the name.
An old interest in ergonomics
Ergonomics has always interested me, not only in the field of software. I have always been drawn to new electronic devices, very often long before they became mainstream: Citizen or Seiko pocket LCD mini TVs, Pocket PCs, Libretto-style mini-PCs from Toshiba, MP3 and MP4 players, tablets and e-readers. In short, any small portable device caught my interest.
I enjoyed discovering these objects, handling them, understanding their qualities, but also noticing their flaws. And there were often ergonomic flaws: poorly placed buttons, essential functions hidden deep inside a menu, settings requiring too many button presses, unintuitive interfaces, strange design choices.
Quite often, a device could be technically interesting, but very frustrating to use.
Simpler, more direct software
Having been interested in computing since the Thomson MO5, MO6, and TO7, I have also used many software applications over the years. Some were very powerful, sometimes even impressive on paper, but many gave me the impression of being bloated “gas factories”: too many features, too many menus, too many options stacked up over time, and sometimes too much slowness.
Sometimes, a function that should have been simple was difficult to find, or a useful tool was buried inside an overloaded interface. And that has hardly changed: many software applications remain complicated to use, even when you only want to accomplish a simple task.
It is often a matter of interface, but not always. A piece of software can look visually clean and still be impractical. Conversely, a very simple tool can become pleasant to use if it gets straight to the point, if the important actions are quickly accessible, and if you can understand almost immediately how to use it.
It is a bit like electronic devices: some are so well designed from an ergonomic point of view that you almost do not need to read their manual to use them fully.
That is precisely the direction I would like to give to AppErgo: to design simpler software, easy to get started with, and focused on the essentials.
App + Ergo, an obvious combination for me
For AppErgo, the name therefore came quite naturally. When looking for a name for my software development project, the word “ergonomics” quickly stood out. It matched something I had been interested in for a long time, but also what I intended to develop: useful, understandable, fast applications, and more broadly applications designed to be pleasant to use.
The two roots then appeared quite simply: App, for application, and Ergo, for ergonomics.
Of course, I tried other combinations. Names with “soft”, with “log”, and other variations around software and ergonomics. But AppErgo was the one that sounded best. Short, clear, and consistent with the idea behind the project.
I was actually a little surprised to find that the name was still available as a .com domain, as well as in other extensions. That felt like a good sign.
Conclusion
AppErgo is therefore not only a practical name, easy to remember and pronounce. It is also a small statement of intent: to create applications that do not try to do everything, but try to do well what they were designed for. Software that is easy to get started with thanks to an ergonomic interface, capable of perfectly accomplishing a few well-defined tasks thanks to clean and powerful algorithms. That is the direction I want to follow with AppErgo.