A new product came out today, and it’s one that I’ve been excited about for quite some time.
The developer in question is known for making beautiful and functional software, and a phrase that is often associated with them is “Mac-like.” This implies that their products are well-made and unique, but still feel native to the larger macOS ecosystem.
This concept of “Mac-like” software is a nice idea. It implies that a product shares sensibilities with those produced by a billion dollar design-focused corporation. These same words, however, can also be seen as a critique, both of the philosophy of the company and the product itself.
Apple’s focus has always been on user experience, and often what that means is a focused feature set. In hardware that shows up as a reduced set of configurations, or a minimal amount of buttons. In software that means providing only the features deemed most necessary to accomplish a task. This has the benefit of removing distractions for a user, but can also be limiting when a user has grown beyond the provided options.
The process of removing or omitting features from a user’s experience also means that the developer will have some kind of core workflow in mind. That workflow is being traversed by the user, utilizing the provided features, to hopefully extract maximum benefit from the product. This user may or may not have some existing conventions to draw upon, but the plan is that they will step into this product’s workflow, and be guided by the developer’s features to utilize it in the best way possible.
A question for any user of a new product is: can I adapt my workflow to this preferred way of doing things?
If yes, then the process is complete, the user has a new tool. If no, then the user has more decisions to make. Can they adapt to the new way of doing things, or can they modify the product to their preferred way? If they adapt or modify, then we are also done. If they cannot adapt, then the only remaining option is to try requesting features from the product to provide the desired workflow.
This process can create a very odd relationship between the user and the software. The user wants something from it, but many times in the case of “Mac-like” software, the developer wants to remain focused on their original goals.
While there may be many aspects of this new product that can be appreciated in its current iteration, the user must also be aware that the existing drawbacks could be there indefinitely. My past experiences with “Mac-like” developers is that the iteration process is often very slow, so one is stuck deciding if the few things they enjoy outweigh all the things they are missing.
In this world of “Mac-like” products and companies, features are given as like a gift, rather than being supplied as a product of work. In that world we accept and adapt, or move on and look elsewhere.
As a developer myself, I fully appreciate the need to restrict a product’s focus. As a user, however, I must be honest with myself when it comes to these types of situations. If I see something lacking, I must prepare myself for that feature either coming much later in the product’s lifecycle, or not at all.
Contrast this feeling with many open source products that I use daily. The initial features get me interested, but there’s also part of me that knows that anything missing has a high likelihood of being requested by others. Combine that with open contribution or a robust plugin system, and the decision to jump into that product becomes a far easier decision.
Changing anything about one’s workflow is disruptive, and I’m doing my best not to equate my own muscle memory with the pain of learning a new routine. Having said that, there’s no escaping my uncertainty about the future of this “Mac-like” product. I’ve watched Apple for a long time, so I know that often times the road ahead is murky, and sometimes very long, so for now I’m going to stay where I am.