As far back as I can remember, I’ve struggled to be able to express what was in my head. Whether it was drawing, writing, design, I was never happy with the result.
It took me over a decade to be able to give life to my ideas and ideals in the form of words, software, and art, in a way that satisfies me. 10+ years probably sounds like a long time, because it is. But it took creating Kinopio for me to realize just how powerful expressing yourself to turn ideas into understanding really can be.
Self-Expression Is a Productivity Superpower
Throw a rock and you’ll hit a new productivity tool you can use to Get Things Done and change your life, or your team at work.
But this one’s different, I swear. You can add comments, color-coded labels, stuff things in folders, assign them to other people, generate charts, and ask chatGPT to summarize the nightmare we’ve created.
But it’s all basically just,
Write tasks,
Do tasks
Instead of putting lipstick on a pig, what if we looked a little closer at the little oinker?
Starting with step one,
Write tasks
We’ve all read vague, flowery, way-too-long documents and plans that use a lot of words to say very little – or nothing at all. The tasks this kind of writing creates in any tool is a classic case of garbage in, garbage out.
“Being misunderstood is one of the most frustrating feelings in the world” - Kali Uchis
Being able to clearly express your thoughts is the unsung productivity superpower: your thoughts become actions that you feel confident doing, and your plans become tasks that your team feels inspired to execute on.
But getting the thoughts out of your head is its own special kind of work.
The Thinking Work Before the Work
We have an endless number of thoughts and ideas swimming around our heads every second of every day. Because the mind is an inherently messy, creative space, organizing your thoughts is less like cleaning your room, and more like fishing for pearls:
Dive in, swim deep and collect what shines. Then refine and polish what you find for others to cherish.
“When an idea first arises, there’s still so much shaping, transforming, deleting, expressing, before you can arrive at a semblance of a place. Kinopio is perfect for making sense of this in-between state.
It’s also […] a constant reminder of the magic in software”
Who Kinopio Is For
I didn’t create Kinopio to be a better whiteboard, or a Miro/Mural/etc-killer. The origin story is way more basic than that.
While designing mockups and writing technical specs in previous jobs, I got into the habit of writing and moving ideas around using the text tool in design software. Being able to write this way was creatively liberating and inspired me to build a spatial thinking tool that anyone could use, by themselves or collaboratively.
Communicating your ideas, the thinking behind them, and expressing more of yourself is scary – right up until it becomes second nature.
Kinopio helps you get over that hump. It’s a tool, and a community, for those who dream of being understood.
P.S. Here’s the thinking space I used to make this blog post
Normally I don’t write much about server and security issues. I’m certainly no expert. But if I can prevent the birth of even a single captcha, then I’ll sleep well tonight.
Every website you can sign up for eventually will need to ask themselves the question,
how do you prevent a malicious person from running a script 100s of times a second that acts like a sign up form submission to spam or DDOS your service?
At the very minimum your server should be rate limiting requests from the same IP address. But because IPs can be faked, additional protection is needed.
The different solutions to this puzzle each strike a different balance between security and convenience:
Captchas: use these if you hate your users
Sign-in with Facebook/Google/etc.: causes support issues, ties critical infrastructure to untrustworthy megacorps
User must verify their email before account is created: not too bad, but having to open email is noticeable friction – especially if you have other unread messages yearning for your attention
I was looking more user-friendly alternatives to these systems when I came across the idea of temporary tokens on the W3C wiki,
Assign a temporary token to the users at the start of their sessions. The token will be associated with the submitted form. When the session is terminated, the token expires.
Color me intrigued.
Putting Yourself In a Hacker’s Shoes
As intimidating as the term is, cybersecurity can be a fun mental exercise. While I build server routes, controllers, etc. a little voice in the back of mind asks “If I knew these api endpoints, how could I exploit them?”
So let’s take a step back to the original scenario to create some assumptions:
To make 100s of accounts a second, you’ll most likely be running a script from the command line.
There’s a relationship between benefit and effort. The less moral or financial incentive there is to break a service, the less effort you want to spend customizing your script.
Validating Sign Up with Session Tokens
Based on our assumption, a weak point of scripted sign ups is that the script isn’t running on the page itself. So instead of proving humanity (i.e. solve this puzzle), we really only need to prove presence (i.e. were you here? did you sign up on this website?).
Here’s how we can do that using temporary tokens:
When you load Kinopio and open the sign up form, a randomly generated session token is created by the client and saved to the server database.
When you submit the sign up form, the session token is included and the server first checks to see if that session token exists. If it does, then the token is removed from the database, and the sign up process continues. If it doesn’t, than the server responds with an error instead.
Periodically, old unused tokens are purged from the database
This is definitely more towards the convenience end of the security spectrum, but no single solution here is perfect and the advantage of session tokens is that they can stack nicely on top of other measures down the line if needed.
So over the last couple weeks, I’ve been talking to VCs and founders who have and haven’t taken VC to learn whether it makes sense for Kinopio. I don’t think it does.
I’m open to the idea of selling ~5-10% equity in Kinopio for 💰 to live a smoother life right now. But the relatively-easy money of VCs has a cost – once you get on the VC ferris wheel 🎡, the primary goal of a business changes:
Before “lets make a great product and sell it to people who love it”
After 🎡 “we need fast growth to raise ever-higher rounds of investment until the company gets acquired, so I never have to work again”
This really clicked for me during a chat with someone who recently took VC:
I like what I’m building, and if it dies it’ll be a shame. But it won’t kill me like it’s killing my baby that I would’ve loved to work on for the next 10+ yrs.
Maybe that’s the healthy approach, almost certainly the smart one – but it’s not mine. I want to work on Kinopio for at least a lifetime.
Built to Die, and Secretive About It
Funding models explain why it’s so hard to rely on software services long-term. Not because of technical problems like crashes, but because they’re often built to die.
Interesting, cool, and nice-to-use tools and platforms come out all the time. But it’s annoying to invest the time in learning and relying on something new only for it to get acquired and sunset, or become crappy in the 🎡 pursuit of growth-at-all-costs.
I’ve found that the best way to predict whether software is made to die is to look at how it’s funded. What’s the company’s business model? How will they make money?
It seems like more and more people are explicitly or intuitively becoming more aware of this. But it’s still rare for businesses to share how they’re funded. Advice I got from multiple founders is that if you raise VC, wait 2-3 years to announce it.
On the other-hand, it’s also not that common for self-sufficient businesses to share their business model either. Maybe they’re afraid of looking small, or maybe they think that people don’t care.
Two different kinds of farms can grow vegetables. One is a factory farm built for scale, and the other takes the time to grow more expensive but healthier plants without pesticides.
Will everyone appreciate the difference? Of course not, but the latter plants are labelled ‘organic’ to give us the information and the choice, so that those of us who do care can make better decisions.
Organic Software
So maybe we should have ‘organic’ software as well, made by companies that:
Are not funded in such a way where the primary obligation of the company is to 🎡 chase funding rounds or get acquired (so bootstrapping, crowdfunding, grants, and angel investment are okay)
Have a clear pricing page
Disclose their sources of funding and sources of revenue
And, if you are making organic software, please proudly tell the world because we want to know you’re making something we can rely on.
p.s. I know that software terms like bootstrapped and indie also exist. But these are vaguely defined (is angel investment okay? is having staff okay?), and predominantly speak to founders, instead of to why regular people should care.
p.p.s Thanks to everyone who graciously took the time to talk to me about funding. And special thanks to Aneesha for editing this.
Futureland is a journaling platform that helps you build habits or learn new skills through daily posting and activity streaks.
This is the tale of my redesign of the Futureland (FL) web app over the last year – how I started, what I did, and what I learned.
How I got Involved
I chanced upon FL when looking for a place to write rough thoughts and development diaries that I wanted to share. Creating journals and posting was straight-forward, and I liked it’s light-weight feel, simple aesthetic and tight-knit community,
The original UI
But while trying it out, I kept giving myself paper cuts on confusing parts of the interface,
The sidebar grouped journals under ‘All’,’Daily’, and ‘Shadows’, but it was never explained what these meant
When opening a journal, the sidebar that listed your journals would slide away, with no obvious way to get it back
Opening a journal and completely losing navigation
The cumulative result of these paper cuts was an interface that appeared minimalist but required regular pauses in workflow to remember how to use.
I posted about these issues, in case it was helpful, with no expectation of anything more coming of it. But the founder and lead developer, Vin and Lucas replied, and later on asked if I’d like to help make FL more usable.
My goal has always been to work on Kinopio full-time. But especially back then, the extra money would be very much welcome, to stay alive and occasionally buy nice things.
Making mockups is easy, communicating is hard. So the first thing to do was establish a shared foundation and vision. I started by asking questions to understand the thinking behind the existing design, and by collecting feedback from the community.
FL already had vocal power-users who’d climbed it pretty high up the pyramid by being manually 1:1 onboarded by Vin, but basic usability issues still slowed them down and were a barrier for newcomers.
🕊 The first way to make an interface feel intuitive is by grouping together related controls.
It made sense to do this by making the sidebar the ‘home’ of the interface with new responsibilities,
Primary: Organizing and navigating journals, teaching tips
Secondary: Creating journals, user profile, search, discovery
I started by proposing little adjustments and drawing new icons and controls for basic journal creation and navigation. By necessity, I was already updating the visual appearance of controls to fit inside the sidebar
An early update to the sidebar
Now that the fundamentals were set, this was a good time to step back and shape an aesthetic unique to FL.
I started with Vin’s original inspirations which I described as sleek, graphic, minimalist
We then added new images and commented on what we liked about them,
One of the themes that resonated were bright spot colors,
The phrase ‘colourful abilities’ was also interesting to me
This gave me the idea for tying color to function. Users wouldn’t need this to explicitly explained – they would naturally form associations between like colored controls which would help them parse and learn the interface.
Function Color
Related To
Example
Green
Activity Streaks
Blue
Journal Info
Pink
Sharing
Purple
Writing a New Post
Orange
Post Info
Yellow
Scheduling
I used this system to design self-documenting components that were easy to develop against, and allowed the rest of the team to build new and consistent UI without needing me. Broadly speaking, these include,
Component
Purpose
Example
Segmented-Button
Filter results by the selected option
Dialog
Presents item info or editing controls, inherits function color
Dialog Inputs
Short text entry in dialogs
Some Stuff I Did
I was only contracting 1-2 days a week. To make the most of that time, Vin would summarize the community, product, and business problems or aspirations of the week, and I’d tackle these in public in the Futureland.design journal.
We managed to touch almost every part of FL – here are some highlights,
Organizing Journals, Onboarding, and Grouping
On FL, journals are separated by posting frequency. Journals you post to regularly are Today journals, and everything else is Not Today. Today journals are listed first and show activity streak counts to encourage frequent updates.
The Today, Not Today concept is a little hard to explain though, so dismiss-able inline tips are meant to gently guide new users towards that use, without being dogmatic about it.
Jumping between your ‘Today’ and ‘Not Today’ journals
Additionally, a welcome journal was added for new users with more in-depth explanations,
Once people started creating dozens of journals, they wanted more ways to organize them so we added custom groups
Streak History and Scheduling
Posting everyday to a journal increments an activity streak count that is publicly shared.
As people grew ever-higher streak counts, they got more anxious about losing them. Requests started coming in for ways to conditionally forgive missing a streak. In response, others raised concerns about diluting the meaning of a streak.
Public streaks – which therefore have social value – are potentially toxic. But we softened the preciousness and anxiety associated with streaks through:
Streak History, so if you lose a streak you’ll still have a record of it that is publicly visible
Scheduled Journals, that let you customize streak frequency. This flexibility makes growing streaks easier, reducing their rarity and public value
Posting
Posting to your journals is the most important interaction on FL. Most posts on FL are short breezy updates, but occasionally someone will publish a couple paragraphs. You’re also able to publish private posts in a public journal.
Building features out as responsive components allows this same interface and code to be reused in other contexts, like quick-posting from in the sidebar,
Interactions ‘Assume Success’ and Complete Immediately
Sometimes feeling fast, is more important than actually being fast. This is especially the case when publishing a new post or comment.
When publishing content on FL, you had to wait until the server successfully responded before you were allowed to do something else. Whether consciously or not, these sorts of penalties for interaction naturally discourage future interactions.
The work here was describing how to eliminate these delays using a principle I like to call assume success,
In the rare case that the server responds with an error, FL asynchronously notifies you of the issue and lets you handle it in your own time
I’m particularly happy with how this turned out IRL, Lucas did a great job implementing this.
The Web App is the Best App
The sum of all these changes and others means that every feature of Futureland is now completely usable on Android and iOS. Having less platform specific code to maintain helps a small team do more with less – hopefully for years to come.
Ending on Some Thoughts on Contracting
I stopped working on FL a couple months ago to refocus on Kinopio full-time.
Looking back, this was my first time working as a contractor. I used a simple time tracking space to track my billable hours, which I’d compile into an invoice at the end of each month or so.
The main thing I wish I did differently was charge by the day instead of hourly to give myself a bit more breathing room to think long-term without the feeling that I had to make every second count.
So would I do it again? I’m not sure.
On one hand, it was pretty stressful working on two products at the same time. On the other, the perspective from being placed inside the beating heart of another community helped inspire Kinopio features like notifications, and weekly review emails.
It’s not so often in life that you get to help grow a new and promising community. I’ve been lucky (or unlucky) enough to have been here a couple times. The only constant is that it’s different every time.
Working with Futureland was a unique and interesting experience that I’m happy to have been a part of.
Kinopio
I like what I’m building, and if it dies it’ll be a shame. But it won’t kill me like it’s killing my baby that I would’ve loved to work on for the next 10+ yrs.
