About Archives RSS Kinopio

Subscribe to New Posts by Email

 
Subscribing…
Subscribed
Error
  • Oct ’23 Kinopio's Design Principles
    kinopio
    design

    This post is adapted from a talk I did at the Design Matters conference in Copenhagen.

    I’ve been working on Kinopio for over 4 years now. It’s felt more like building a house, piling up little bricks and wood planks, just a little bit each day. Except that, this house is never finished.

    Something I learned from my time at Glitch, was that before you get too deep into the process of building, you should write out a short list of product design principles.

    The more unique and definitive your values are, the more useful they’ll be as a decision making tool later on.

    These are some of the principles that I use to design (and redesign) Kinopio:

    1. Embrace smallness
    2. Build for fidget-ability
    3. Embrace plain text
    4. A single interface for mobile and desktop
    5. Refine by pruning
    

    Principle #1

    Embrace Smallness by Embracing Code as a Living Design System

    Being bootstrapped means that resources are tight. But that’s it’s own kind of blessing. When you feel constrained, you’re naturally drawn to simple and basic tools and processes.

    When planning out a new feature, instead of using design software to draw and arrange buttons, inputs, and dialog windows into detailed mockups, I skip all that and jump right into real code with <button>, <input>, and <dialog> elements.

    Here’s the HTML part of a dialog window component (using pug):

    <template lang="pug">
    dialog.narrow.dialog-name(v-if="visible" :open="visible")
      section
        p blank dialog, please duplicate
      section
        button(@click="incrementBy")
          span Count is: 
        p Current theme is: 
    </template>
    
    (View full file)

    Which produces:

    In the spirit of keeping things simple, the UI is described mostly using regular HTML tags and the layout basically designs itself.

    The way that works architecturally, is there’s a global parent file (App.vue in my case because I use vue.js) which contains global styles that all the other child components inherit from.


    Relatedly, it’s pretty satisfying to make things that are efficient, small, and fast. Maybe it’s the craft-like part of engineering.

    Embracing smallness also means being diligent about only adding small third-party dependencies and utility libs that do one simple thing like date manipulation or generating random colors.

    Partly because of this, Kinopio only weighs ~220kb with libs and assets. So in an alternate dimension where we didn’t have the Internet, but still had HTML, I’d ship kinopio to you on a single 3.5mm floppy disk (and it wouldn’t even need to be a high-density one)

    Principle #2

    Building for Fidget-Ability, hmmm

    The first time I really thought about fidgeting was in the early 2000s when I learned that the faceted curves on this Japanese cell phone were explicitly designed for you to run your fingers over when you weren’t using it.

    (W11K - Naoto Fukasawa Design)

    Software Design is usually focused on capturing user inputs and showing outputs. But most of the time we spend using software tools, we’re actually in between those two actively engaged states.

    This is what I call the “hmmm” state.

    As in, “hmmm, what should I write next?” Or, “hmmm, I’m highlighting this text while reading it to help me focus”, Or “hmmm, I’m swiping back and forth on my phone homescreens while I figure out what I want to do”,

    This in-between time is a great time for fidgeting.

    One way that Kinopio designs for fidget-ability is having cards ‘stick’ to your cursor when you hover over them. Once you get too far away, they bounce back.

    There’s a handful of little details that make this fun without getting in your way.

    • sticking only starts after your mouse has rested on a card for ~200ms to prevent things feeling too sticky.
    • Cards stop sticking when you’re near a clickable button on a card, like a tag, a link, or a todo checkbox, so you can still be precise when it matters.

    This also happens to be an example of a feature that couldn’t be conceived through mockups, and required a lot of fine-tuning with real code to make work well and feel good.

    Principle #3

    Embrace Plain Text

    Text – even markdown – is not just for nerds and programmers. Text and full URLs are atomic units of computing: it’s copy-able, paste-able, and the most flexible way to share.

    Embracing plain text also helps you turn regular people into power users because they can build on top of the skills (like ctrl-c, ctrl-v) they already have.

    In Kinopio, almost everything in a card is just text that supports basic **markdown**, and a couple other custom syntaxes like [[ for tags, or a file or website URL.

    When the card name changes, a hyper-fast custom parser (i.e. a crap ton of regexes) splits the text into html segments based on whether that text is plain text or a special content type like bolded text, tags, an image URL, or any other kind of URL. and uses those segments to render the front of the card.

    This parser and segment system is some of the most complex code in the app – but I like that the effect feels effortless to everyone else.

    Principle #4

    A Single Interface for Mobile and Desktop

    One of my pet peeves is the premise that if you’re viewing something on your phone that must mean you need a ‘clean’ minimal experience.

    Platform Supported
    Desktop Everything
    Mobile ☹ Read only, or a quick entry UI only

    Screw minimal – I want to do real work wherever I want. This is how it should be:

    Platform Supported
    Desktop Everything
    Mobile Everything

    Building an interface that works everywhere requires considerations that you need to bake in from day one this principle means that you can’t rely on hover to reveal controls. You need tappable alternatives to keyboard driven commands. And, of course, there’s way less room to fit things into – especially when the onscreen keyboard is up.

    Related: The Hybrid Architecture of Kinopio for iOS

    Principle #5

    Refine by Pruning

    Another habit I picked up at Glitch was to upload old mockups and screenshots somewhere that I can reference later.

    When I go back in time to something like this original version of the card editing view, I’m reminded of the basicness of it.

    Back then cards had fewer options: you could only remove the card, or add a decorative frame. Although I much prefer the flexibility of cards today, it’s undeniable that there was much less to figure out back then.

    Inspired by this, I habitually re-evaluate whether features are still needed and used often enough to justify their existence.

    Here are just two big features I’ve removed over the years:

    Removed: Minimap [2 Weeks of Work]

    Hold shift down or click the button in the bottom right to toggle on the minimap. Drag the window around to adjust your view, or tap anywhere to jump.

    Unfortunately, no one really used the minimap because it was out of sight and mostly out of mind. I considered placing a persistent minimap in the corner but doing so compromised the feeling of a sense of place within a space (and it wouldn’t fit on a mobile screen anyways). After adding space zoom out I removed minimaps because they were now redundant.

    Removed: Save Twitter/X Threads [3 Weeks of Work]

    Import Twitter threads into your spaces from a tweet card. Or create new thread spaces by replying to on Twitter with @kinopioClub save

    There are whole entire products built around saving Twitter/X threads, and people had requested it, so I was confident this would be a win.

    But after all that work, tweets were being saved only once or twice a day. So after Twitter/X became increasingly hostile to developers, it was an easy choice to delete all Twitter/X-specific features from Kinopio.


    Both of these features demo-ed really well and got a lot of likes on social media. But in the real world, all they did was take up valuable UI space, and their code would inevitably become a maintenance burden.

    🔪 The most satisfying and direct way to handle complexity is to excise it like a tumor. But removing things has it’s own problems and needs it’s own special considerations and process…

    Removing a Feature Is a Community Effort

    The problem with removing things of course is that every feature has at least one person that relies on it. So it’s impossible to just remove something without someone feeling bad.

    Compounding the problem, the longer things stay the same, the more people get attached to them working the same way. So the older and more advanced a tool gets, the harder change naturally becomes.

    This makes pruning hard work – but it’s also an opportunity to build and strengthen the community around a tool.

    1. Share what you’re thinking of removing and why. The people most passionate about your product want to be as close to decisions as possible. I’d post this in Discord and on the Forum.

    2. Listen to what everyone has to say. See where the feature fits in their workflows and whether there’s an alternative way they could accomplish what they want to do.

    3. Be prepared to be wrong and change your mind if you overlooked something.

    The hard part of being a designer or a coder isn’t design or code – it’s convincing people, and understanding and responding to their concerns and criticism.

    Good principles exist to make you feel pain before your users do. They should guide and constrain you into thinking creatively about how to handle complexity.

    Special thanks to Aneesha and Xhfloz for helping edit this.

    Comments…

  • Sep ’23 The Hybrid Architecture of Kinopio for iOS
    kinopio
    engineering

    Using Kinopio iOS running on my scratched up iPhone 12 mini

    A couple months ago I was in Bali, Indonesia for a wedding and had lunch with Lucas, the developer of Futureland where I did some contract work last year. He asked me when the Kinopio iOS app was coming so I shared my apprehension about having to spend months on app development only for it to be rejected by app store review at the last minute.

    Having gone through a similar rejection situation with his own app, Pagi, and having built the Futureland iOS app, he felt pretty confident that he could do Kinopio iOS. So when I got back home, we started planning things out in a space,

    We decided what the app should do and how it should work, with the goal of keeping scope low and maintainability high for this first version. After we’d settled all the hard questions of what we were building in the space, I summarized the conclusions into a Notion doc and we got to work.

    Fortunately, because Kinopio was designed to be touch friendly from the beginning it already worked well on mobile Safari. So the plan was to adopt a hybrid architecture where the native app would be a container for a WKWebView where the Kinopio website would live.

    To enable the native app to send messages to the webview (and vice-versa) we built a bridge between the two worlds using plain old postMessages. So the Kinopio webview can say something like postMessage.send({ name: 'updateBackgroundColor', body }) and the native app can take action and send messages back to the webview in a similar way.

    This postMessage bridge allows for native-only features like haptic feedback when touching content, as well as syncing the pixels above the webview with the dynamic background color behind the webpage:

    The background color of the app slowly cycles between different shades. This video is sped up by over 70x

    We also added share sheets and widgets to quickly capture new thoughts and URLs. In the spirit of simplicity, the share sheet also uses the same kinopio.club/add page that the browser extensions use.

    Regardless of platform, part of this whole programming-as-craft thing for me is getting the most out of doing the least. Which usually means using basic technologies that are easy to understand, debug, and maintain.

    Anyways, 7 annoying app store rejections later (which I’ll skip talking about here for the sake of my mental health), I’m happy to be able to tell you that Kinopio iOS is now live 🎊.

    I hope using it feels like an extension of your hand and mind, like it already does for me. Swipe-to-scroll and pinch-to-zoom, press and hold to paint-select and drag cards around.

    Download Kinopio iOS on the App Store

    Comments…

  • May ’23 A Tool for Those Who Dream of Being Understood
    life
    kinopio

    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.

    (Source)

    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,

    1. Write tasks,
    2. Do tasks

    Instead of putting lipstick on a pig, what if we looked a little closer at the little oinker?

    Starting with step one,

    1. 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.

    Ama pearl diver

    Or, as Rain put it,

    “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

    Comments…

  • Feb ’23 Securing Sign Ups, Without Being Annoying
    engineering

    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?

    (source)

    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.

    Comments…


Subscribe to New Posts by Email

 
Subscribing…
Subscribed
Error

I make Kinopio, the thinking canvas for whiteboarding, research, moodboards, and note-taking that works how our brains work.
No sign up required.

Connect your Thinking →