At the dawn of the industry, we needed big companies to deliver quality software. You’d buy version 1.0 because the way it worked was revolutionary, and it let you do amazing new things. You’d buy version 2.0 because it added helpful new features. Apple, Adobe, Microsoft, etc. became household names because software was hard to make, and even harder to box up and get on store shelves.

But by the time version 10~ or so releases, the product includes basically every feature possible. It’s all things to all people.

So how do you make version 11 compelling? The answer turned out to be Lol who cares now. Once you have monopoly market share, the product (and the people that made it) are largely irrelevant. What now keeps the almighty profit line going up and to the right 📈 is sales and marketing – and predictably the relationship between user and tool metamorphoses from symbiotic to parasitic.

The old monopolies aren’t going anywhere. But a new era of tools designed for a different fate are sprouting up out of old, analogue ideas like creativity, purposefulness, human-made craftsmanship.

Domino’s – the Microsoft of pizza – also isn’t going anywhere. But for those who know, and those who care, there’s always a way better neighborhood spot.

Chasing Good Friction

I spend a lot of time thinking about tools for thinking and creativity, and how they’ve changed. If you’re not used to drawing or writing – and even if you are – the scariest thing in the world is a blank page.

The first sentence, or the first brush stroke, is a high anxiety situation. Full of potential, full of unknown pain.

So to help with the blank slate problem, software tools added Templates. File → New turned into File → New → Do You Want to Make a Portfolio? Or a Résumé?. This more recently turned into File → New → Ask AI to Do It. These features help some people, but also create new problems.

These tools can generate almost effortless outputs. They unburden us from the abrasion of creativity and their generic-by-design results keep us cocooned from the risks of standing out. No one wants to make ‘ugly’ art, or a ‘bad’ website. But struggling and making mistakes is an important part of developing skills and – increasingly important – finding your own voice.

We don’t talk enough about the many-years-long rite of passage that every creator goes through.

Everyone can draw or write, but only the smallest sliver will decide that they want to earnestly make things to share with other people.

At whatever age it grips you though, the urge to create pulls you into a world of frustration, where your skills don’t yet match your taste and everything you try feels not good enough. Unfortunately, the first step to being good at something is to suck at it.

But the expedition is especially dispiriting when your tools constantly wink at you to generate ‘perfect’ results instantly.

Why did I spend two+ painful weeks writing a blog post?

For the Journey

I don’t write very often, so I’m not sure if my pace is glacial or merely tortoise-like. Then again Tolkien took 12+ years to write The Lord of the Rings.

Speaking for myself, even after I plan things out, the shape of an essay (sometimes even my whole argument) changes as I write.

I type with two IA Writer text editor windows open. One for the post, and one where I throw rejected or tangential paragraphs and ideas that don’t quite fit. So far, each file contains ~2000 words… implying that I throw away ~half of what I type.

From a short-term-results point of view, this process may seem inefficient, painful, and somewhat savage. I wouldn’t really disagree – but, like working out, or eating well, the sweat and tears are worth it in the long-term because I solidify my ideas with every new post I write.

Even after all that work, it’s never as good as I want to be – especially considering the effort. I’m still always a little bit embarrassed to share my work, because it’s never ‘perfect’.

But it’s better than perfect, it’s imperfect.

Struggling is an important part of developing skills and finding your own voice, and having an audience that’s watched your work evolve over years is a slept on privilege.

The Human-Tools Era

When you’re excited about a new hammer, everything looks like a nail. In the case of LLMs, just a year or two ago investors couldn’t catapult money fast enough at anyone incanting the magic letters A and I. Now that the dust is settling, I suspect we’ll look back at AI as something that was good(ish) at summarizing text and image recognition – but was used to make everything in the world harder to understand, less fun, and worse.

More so now than ever before, making something yourself that you fully understand is deeply empowering. As the world gets noisier, glossier, and more fake, the more valuable the human-touch becomes in both the real world and on the real web.

LLMs are the new normal. “Easy to use” became “let me tell you what to write and how to draw”, “here’s what you’ll watch next”, and “here’s what you believe”.

But there is always be a market for understandable, engaging, and fun-to-use tools.

In your heart, you probably can’t be an enthusiast for everything. I like cool cameras, I don’t care about wine (TBH I’ll happily drink Coors Light™), and obviously I care about good software. Let me add a row:

When it comes to thinking through problems, working through projects, or expressing yourself, special tools aren’t a necessity – but they can make the journey a lot more fun.

Doing things a little differently makes the results more imperfect and personal. Being authentically you is what makes the journey worthwhile.

Special thanks to Aneesha and Ben for helping edit this.

Comments…

This aesthetic screenshot of an old windows app has been in my inspiration space for ~5 years. Until recently, I assumed that it was just a nostalgia bait concept.

The calm, serene life associated with gardening pairs suspiciously well with rose-tinted wistfulness for a simpler time in computing. I’m happy to be wrong though, because software doesn’t get more real than PlantStudio.

Written by Kurtz-Fernhout Software, PlantStudio is a surprisingly deep botany simulator for creating and arranging 3D models of herbaceous plants based on how real plants grow, change, fruit, and flower, over their life cycles.

How to Install

Because the last release of the app was in 2002, and it was for Windows 95/98/2000/NT4, we’ve got a little bit of work to do to get it running on macOS:

1. Download PlantStudio210.zip and unzip it
2. Download Whisky to run windows code in a container called a bottle
3. In Whisky, click + button to create a new bottle (I set it to Windows 10)
4. Click Open C: Drive and copy the PlantStudio210 folder into Program Files
5. Click Run and open Program Files/PlantStudio210/PlantStudio.exe

PlantStudio lives again 🌱🌺

Let’s Grow Some 3D Plants

After you read or skip the tutorial docs, you’re be greeted with an empty window, which is kind of like the ‘garden’ that your plants will live in. One way to jump in is to File → Open some sample files.

The interface is full of unlabelled and unfamiliar icons, but the hover tooltips in PlantStudio are the most verbose I’ve ever seen – which helps a lot.

To fill the garden with our own herbs, shrubs, and flowers, use Plant → Create New… which opens the thorough 10-step Plant Wizard, and teaches us some biology terms along the way.

Each option button has a detailed little illustration that makes the impacts of technical concepts, like ‘inflorescence’, easy to understand.

I also love the wizard progress icons in the footer. Because the colors match the button illustrations, it’s easy to jump from editing stems and leaves (green icons), to editing flower related options (purple icons). The start and stop traffic lights for the intro and confirmation steps serve as cute bookends.

Designers can use color to conceptually link related interfaces together. I did this when I redesigned Futureland a couple years ago.

One thing I kept wishing for while creating plants was the ability to see a live preview while I was selecting options. Maybe they didn’t think of that, or maybe the performance impacts would’ve been too much for the minimum required 100MHz CPU of the day.

Cultivating a Garden

As you create plants, they’ll appear in the garden area, where you can arrange them by scaling, rotating, editing, posing, and even changing their age.

It took awhile, but by repeatedly creating plants in the wizard and arranging each one, even I could make something pleasant enough:

I could’ve probably saved some time by selecting one or multiple plants to Plant → Breed to create offspring. The Breeder lets you define how similar the children are from their parents, and adjust the amount of mutation (random chance changes).

Export Options

You can be creative with your plants models by exporting jpg, 3ds, or obj files into other art apps. The official Gallery has a couple y2k-era masterpieces that were composed with whimsical 3D tools like Bryce, and then polished in 2D art tools like Paintshop Pro and Photoshop.

The process for making these images is strikingly similar to what landscape architects do today. Much like how software designers use mockups, architects use 3D renderings to convince clients, to market their work, and as a starting point for working with contractors.

Also, plants look really cool inside Kinopio spaces. Maybe I’ll figure out some kind of ‘integration’ in the future…

So Why Am I Only Finding Out About Plantstudio Now?

The husband and wife duo Paul Fernhout and Cynthia Kurtz were the authors behind Kurtz-Fernhout Software. Unsurprisingly, both have degrees in Biology and Ecology.

Their original goal was to build a gardening simulator to “help people understand how to garden in a more sustainable way in their own backyards”. The simulation was based the EPIC (Erosion/Productivity Impact Calculator) agricultural model by the USDA Agricultural Research Service.

We worked as a team on most design phases of the project. Paul did most of the low-level coding, the general architecture, the undo/redo system, the file system, the graphical display, and the 3D turtle engine. Cynthia did most of the translation of the EPIC model, the flowering/fruiting submodel, the plant drawing algorithm, the various window designs, and the artwork, music, and documentation.

PlantStudio was originally built to draw plants for the gardening simulator, but they “found that everyone tended to like the plant designer so much they wanted to play with it instead of with the garden simulator”, so released it separately.

Not entirely dissimilar to the story behind SimCity,

While developing his first commercial game […], Will Wright noticed that designing city maps for the player to fly over in a helicopter was more fun than actually [playing the game]. He began expanding his world-building tools as an experiment. He applied various urban planning and computer modelling theories, implementing whatever ideas he’d been reading.

Unfortunately, PlantStudio was discontinued in 2002,

What happened to our old software and the plans for it? We spent years working for other people to pay off money (with interest) we borrowed to finish it and free it.

I empathize with their story because the world is rarely kind to organic niche creative consumer software. I’m sure the market at the time was a lot more developer friendly overall, but businesses need to always be reaching new people to sell more licenses.

In an alternate universe, maybe PlantStudio could have survived by evolving into a game in the vein of SimCity and SimEarth, e.g. ‘SimGarden’.

Incidental Beauty

There’s something appealing about objects and interfaces built for purpose, like race cars and professional-use espresso machines. In cases like these, beauty feels like a byproduct of an object built to do it’s job well – and there’s something appealingly genuine about that.

I’d describe PlantStudio the same way. It doesn’t look or work like a modern app, but anyone can figure it out because it’s interface elements are delightfully chunky, unfussy, and well documented by illustrations, inline text, and tooltips.

It’s definetely not for everyone, but the best things rarely are. Creating those gardens gave me a new perspective – and some new ideas – for my own design work.

It took a while, but I’m glad I found PlantStudio.

Special thanks to Ethan from Plantkind for giving me a bit of insight into his landscape architecture practice for this post.

Comments…

A couple months ago, I wrote a short piece for the Sublime zine about my vision for collaboration,

What if We Could See Each Other’s Thoughts?

When you asked me to do something, I would know why you think it matters. If I told you my plan, you would know the thinking behind it.

Instead of debating what to do, we could discuss why we need to do it. Instead of hiding behind a powerpoint proclamation, we could share our truer selves, and our rougher thoughts, and figure it out together.

The curse of humanity is that we can’t read minds, but we do need to work together. Every company I’ve ever worked with has struggled to connect what we need to do, to why we need to do it.

This is where whiteboarding comes in. The combination of writing and drawing anywhere you want can help us build ideas and solve problems together. No two whiteboards are the same because no two problems are ever the same.

Collaborating like this, in the spirit of openness and vulnerability, we can share our goals, assumptions and ideas, we can ask questions, make plans, have fun, and learn to trust each other.

Unless you’re unlucky enough to be using an enterprise software whiteboard.

Designing for the Journey

Here’s the prettiest screenshot for Miro I could find, taken from its marketing site, illustrating its many features in use,

Let’s say I have a cool idea you want to share with the group. Hold on, I’ve got some decisions to make first:

• I want to type my idea so I’ll use the Text tool
• Oh wait, should I add a Sticky Note instead? What’s the difference? Which pastel color should I choose in the sub-options that appear?
• Oh nooo, I clicked on the + button and 30+ additional tools popped up (seriously click that link, the list is nuts). Umm, what’s a Card? How is it different from a Text or Sticky Note?
• I see multiple Diagram, Flow Chart, and Mindmapping tools. So if I want to add an idea that’s connected to another idea, do I need to use one of those?
• What was my idea again?

This “what if design app, but business?” kitchen-sink UI makes it possible to produce high-fidelity diagrams and flowcharts – but it also ruins the whole point of a whiteboard. (Also, at this point, why am I not just using a real design tool?)

Drawing and writing on a physical whiteboard is a mode-less experience that anyone can do. Being at least as easy, expressive, and fun as a $10 sheet of plastic and some markers is the bare minimum that a software whiteboard should be.

Unlike text documents and spreadsheets whose general shapes were settled pretty early on, collaborative digital whiteboards have only been around for ~15 years or so.

Despite this, every app in this space follows the same dreary UI playbook. Maybe that’s the nature of enterprise apps for the fortune 500, but why should the rest of us suffer? I think we can do better.

Wide Interfaces vs Deep Ones

As products gain features their interfaces can grow either wider or deeper to accommodate them. It’s kind of like a lake,

Wide interfaces show you every tool and control upfront to make them easy to discover and quick to access. But as the number of options increases, they become visually overwhelming, requiring designers to stuff some things into submenus.

In the right context, this is great. Wide interfaces are ideal for specialized professional tools designed to produce high-fidelity outputs like pixel-perfect mockups, millimetre-accurate architectural plans, and complex 3D models.

Pro tools take a lot of time to learn, but they’re usually critical to your profession, so that’s time well spent.

But the same qualities that make them powerful for professionals, also makes them prickly for cross-discipline collaboration. Complex tools elevate experts and intimidate novice users from making unique contributions, nurturing groupthink.

Deep interfaces, on the other hand, present fewer controls upfront. More advanced features reveal themselves contextually as you add content.

Because these interfaces are easier to start using, they’re better for collaboration with a wide range of people and a wide range of skill sets. Everyone feels more welcome to contribute when the barriers are low.

Like a physical whiteboard, the outputs produced this way tend to be lower-fidelity and conceptual – ideal for problem solving and consensus building.

The downside of deep design is that advanced features are inherently harder to discover. Good help docs and sharing examples of advanced use can go a long way though.

The other challenge is that you can’t just wedge new feature buttons into a toolbar. You have to think through how features could be invoked contextually – and be okay with some features taking longer for users to unearth.

In practice, almost every app has a mix of wide and deep interface design decisions. Now that you can recognize them, you’ll see these patterns everywhere. Sorry about that.

Eternally WIP

When Kinopio was born 5 years ago, whiteboarding wasn’t on my radar, so its design comes from a totally different place.

In 2019, I introduced Kinopio, why I made it, and how to use it in Hello Kinopio. I think I got a lot right from the start.

Early on, I noticed that those who use Kinopio the most, also use it at work. It’s really motivating to see people using the tool I created to help shape the kinds of teams and companies that I’d love to work for.

Kinopio isn’t for the Fortune 500 – there’s plenty of enterprise options for them. I’m personally drawn to the people and teams who care about using great tools because they take pride in their work.

Ultimately, my goal is to create something that’s so effortless and toy-like you’ll invent new reasons to sink into it with your friends and teammates.

Special thanks to Aneesha and Kevin for helping edit this.

Comments…

On the eve of it’s 5th anniversary, I’ve decided to make the code for the kinopio-client app public. That means you can run Kinopio on your own computer, make changes, and share improvements.

kinopio-client on github

kinopio-client is the app that’s downloaded and run in your browser when you go to https://kinopio.club. It can save data locally, and to the kinopio-server.

Because the app weighs only ~220kb, in an alternate dimension where we didn’t have the Internet but had html, I’d ship kinopio to you on a single floppy disk. It wouldn’t even need to be high-density.

To be honest, opening up 5 years of private code does feel a bit intimate, like inviting someone over. I’ve cleaned the dishes and swept up, but … don’t look in that closest.

That said, compared to other commercial codebases, you might find it refreshingly straightforward. It’s just a node.js app and here’s the entire install process:

git clone https://github.com/pketh/kinopio-client.git
cd kinopio-client
npm install
npm install -g @vue/cli
npm install -g hostile
hostile set localhost kinopio.local

Then create an .env.local file containing VITE_PROD_SERVER=true.

And to run it:

npm run serve
https://kinopio.local:8080

Why Make Commercial app code public?

I’ve long been thinking about how to share the amount of work that goes into Kinopio. The more you know how something is made, the more you appreciate it – even more so when it’s a quality product built to last a lifetime.

But at the same time, making software isn’t like carving fountain pens or acoustic guitars. As much as I would like to sometimes, I don’t toil in meditative isolation until I’m ready to deliver the perfect timeless objet d’art.

By contrast, delivering software is more like delivering a gooey crying baby. It’s alive. Squirming, growing, and changing because the technologies it relies on do too. Physical materials rarely change, but web browsers, operating systems, and servers sure do.

The big benefit of public code for me is that it’s another way to share the work that goes into Kinopio. One more piece of the puzzle, in between diagnosing bug reports, discussing feature requests, and sharing updates on social media.

Some kind souls might contribute changes. But because Kinopio is such a complex interface-based app, I have no idea yet how often that’ll happen.

Risks?

Sharing the code for paid software carries some potential risks worth considering,

1. A counterfeiter could theoretically use the code to make a clone product. Commercial derivatives are prohibited by the license, but even if they ignore that, the forger would still have to reverse engineer their own kinopio-server. It’d be way easier to use an off-the-shelf infinite canvas library or tldraw instead.

2. Code contributions are appreciated, but having too many PRs to review can be very stressful. On paper, Kinopio is a one person operation, but I’m not really alone because I’ve got a community of users I trust that moderate discussions and answer questions when I’m not able to. As always, I’ll be relying on their help and generosity.

What Happens Next?

If you are interested in contributing, please by sure to read the contributor docs first. And just like in the discord and forums, there’s only one rule:

We’re all friends here, so let’s be cool, constructive, and always treat each other with respect.

Compared to a library or CLI tool, where new features and more options don’t really complicate basic usage, what the ‘correct’ thing to do for a GUI application is far fuzzier and subjective.

I’m looking forward to seeing what kind of activity takes place in the repo. Will I spend more time reviewing and less time coding? Maybe I’ll stream some live coding sessions?

With loving scrutiny,

– Pirijan, Kinopio Creator

Comments…