rasmusfabbe

[waving] author here

Perhaps the author lives in a place with bad tap water, like where you don’t drink it if you can avoid it. I’ve visited a few places like that. If the tap water is good to drink it will be good to make coffee with. Period.

Hello! Wow, cool to hear you followed along with Kod. It did ship and was used by a bunch of people. Its code is open source and still up on the github: https://github.com/rsms/kod

More importantly Kod was a side project I did for fun during an extended vacation. I remember publishing the first version on a December evening while visting my Mom on the countryside of Sweden. The next morning the program had been downloaded 25000 times and I was like "wat?!" A really fun little side project.

Playbit is something quite different to me. It is an _idea_ more so than a _solution_, it is a concept and path to a new alternative for software creating and sharing which I deeply believe in. Playbit is the beginning of a materialization of years of discussions, thoughts, experiences and research. I hope that I will have something more concrete to share soon. We have gotten so used to quick quick quick low-end web apps turning things around in a few months that I fear expectations on all software has been affected; Playbit is a long-term project and not something that will be "done" in a few months.

Then again, I might screw this up and it might die as a concept and some half-written code. I guess we will see :–)

Hello, person behind Playbit here. Happy to hear you like some of the concepts :-)

My hopes with Playbit is to create a "setting", a "scenery", really an environment which encourages software creators to be more experimental and do less heads-up planning. All this with a playful tone and approach. Think about someone wanting to spend a Sunday today, making some simple todo app or whatever. The wall of software the average person in this situation need to sift through is ridiculous. You install Homebrew, then nodejs, then some horrid 1900 file big set of npm packages, spend an hour researching how to get this week's js bundler working with the latest typescript with last week's most popular UI framework. And so on. Once you actually start tinkering on your little fun app, most of your Sunday has likely gone by. This is no criticism of and specific tools or software libraries but—I believe—a mindset issue.

If the barrier was lower to experiment we might see more ideas and more interesting software.

Is there nothing like this? Of course there is :-) History and event the contemporary software world offers many examples. For example, the web in ~2000 was really interesting. You could look at a big-name website, view source, save it as mything.html, make some edits—which result you'd see immediately—and share it by drag and drop in an FTP client. Was it the most immersive and rich software ever made? No. Was is the most reliable and testable way to develop software? Definitely not. Was is secure? Hell no. But was it fun and did it spur an ocean of ideas and creative change to software? Yes! Another example: In ~2005–2010 creating Mac OS X apps was a similar experience. Yes it was only possible on a Mac, but the barrier to make an app and share that with people was inspiringly low. Table views, buttons, windows and most other kinds of things you might want were all there and really easy to use. You spent your time exploring the essence of your app, not choosing which table-view implementation to use.

Now I don't know exactly what the path to something like that will look like, but my bet is that starting out with a safe playground that makes a few people able to experience this is a good place to start. Playbit might end up being more of an app you run on your whatever OS rather than an OS by itself, no matter the technical manifestation I believe that it needs to "take over the screen" for the "setting", the playful environment to succeed.

Addressing the DOM structure: This is a tactical & practical small piece of the Playbit effort. In order to provide a landscape in which to play there needs to be some lego pieces around to support the basics. Any interesting software indeed speaks with the outside world which can be thought of as "data" in "code & data" (i.e. software is both code and data.) An earlier version of the "data" solution was an acyclic graph, another was a Facebook Ent-like key-value database. I landed on a DOM structure as a (not "the", BTW) data layer. It can be used as a list to make a text editor, as a tree for an email app, or a dictionary for ...uhm, a dictionary.

Namespaces: The file system (it's "directories") is closer to the kind of namespaces I'm talking about (than for example namespaces in Clojure or C++.) The Linux kernel does have a (really neat) namespace feature which Playbit may make use of, but in a transient hierarchical way rather than a persistent concurrent way. In my experience namespaces gets messy when treated as a named link of indirection. We all know the classic saying that in computer science, all problems can be solved with an extra level of indirection. It's both a joke and a practical truth. Some limited indirection can be really useful (like for example file name -> inode -> disk sector) but when the abstraction (of the indirection) leaks it means a cognitive toll is payed by the person having to navigate it and that is not good. I think this is often when computers feel "complicated". I'm sure many of us have followed a call stack trace in code at some point, trying to trace the cause of an effect. If the program made use of things like asynchronous message passing (or things like JavaScript promises) the dimensionality of indirections can explode and we can almost feel the computer "working against us." Anyhow, end of ramble :-)

Twitter thread: https://twitter.com/pervognsen/status/1355028789055475712

Source gist: https://gist.github.com/pervognsen/91474ed5f6a81fa01566e63d9...

That website is 90% shady ads and 10% article. Even if this is an actual legit article, the way it’s presented here takes away any chance of me taking this seriously.

Well observed. There are a myriad of influences in Inter, some from existing fonts, some from graphic design and shapes I’ve seen in my surroundings and some ideas that grew out of thoughts. For instance, the bend of the “t”, “f” et al just felt right and was not influenced by anything else but their own shapes. In contrast, the “a” was inspired by many existing typefaces like Akzidenz Grotesk, Helvetica, etc. The shapes of the glyphs, spacing and angles of Inter have gone through a long evolution during the past three years. For instance, “e”, “1”, “s”, “g”, “n”, “m”, “d” (and several others) changed a lot early on.

Hello, I’m Rasmus. I’d love to dig deeper into these subjects — the details into rasterization and realities of layout engines (or “shapers”) that are out there. Perhaps in another interview or article :–)

Tabular numbers added and will be included in the next release (1.2) https://github.com/rsms/interface/issues/10#issuecomment-324...

Normally this is done with "tabular numbers", an alternate set of glyphs in the font where all digit glyphs is equally wide. However, another feature a font can provide is "proportional numbers"—the inverse of tabular numbers. Most fonts usually provide one or the other. Roboto for instance provides "proportional numbers" as an option, and uses tabular numbers by default. Interface by contrast uses proportional numbers by default, and the plan is to add tabular numbers as a feature that you opt in to for the scenarios you point out (e.g. tables.) In CSS you'd opt-in to tabular numbers with: `font-variant-numeric: tabular-nums`

Actually, I think you want to compare apples & apples, meaning Font A and Font B at the same size and line height.

Thanks for the thoughtful comment. Indeed really small sizes like 11px, distinguishing factors are few and even San Francisco and Roboto start looking like the same font, at least as far as most people are concerned. The goal with Interface is not to create a unique-looking typeface, or even to try to make something different in terms of style, but to create the best possible small-size, computer-screen, user-interface oriented font, even if that means that some characteristics become very similar to other typefaces. For instance.

Roboto is already being loaded from google fonts (https://github.com/rsms/interface/blob/b91dd3af/docs/lab/ind...) However, I think Chrome might do something weird where it fails to actually load the font files when later the font family "Roboto" is requested (https://github.com/rsms/interface/blob/b91dd3af/docs/lab/ind...) — a common hack for this issue is to have an invisible element in the document that explicitly uses the font and forces the browser to load it at document-load time. Could try that hack here.

Anyhow, the version of Roboto served from google fonts is an older version and a subset of the "real" roboto, as can be fetched from roboto's source code repository. If you have Roboto installed locally, you probably have the more recent and more complete version installed and will likely want to compare with that (rather than what's on google fonts.)

Edit: https://twitter.com/stuartpb/status/900484392472109056 points out that @import must be at the beginning of a style declaration. Website has been updated.

This is valid commentary and subject to much discussion throughout the recent history of typography. There's always a blance condition between personality, legibility, character ambiguity, pace, and so on. Every typeface needs to go in some direction on these dimensions, which is why we have different font families for different uses! For instance, mono-spaced fonts with "slab" serifs are popular with computer code since column alignment (mono-spaced) and ambiguity (slab serifs and other visual traits like slashed zero) are used. However, for most people it's easier to read a variable-width font with regular serifs for longer text, like what you'd find in a book. Similarly, for user-interface labels, dialogs, buttons, etc it's often better to use a font without serifs and with a little more tracking/letter-spacing than what you'd use for large bodies of text (e.g. in a book.) Interface is designed for the latter use-case; user interfaces on computer screens.

Happy to hear this! Would love to see a screenshot of what it looks like (I'm @rsms on Twitter)

Glad you like it. Once Interface reaches a more stable state (i.e. more glyphs and kerning have been added), the intention is to submit it for inclusion on Google fonts. In the meantime, you can use https://rsms.me/interface/interface.css which always points to the latest release of the font, and is hosted on a CDN (by Cloudflare, backed by GitHub.)

This is by design. A wider "O" would indeed make separating zero from "O" easier (and an earlier iteration of Interface had a wider "O") but it adds some uneven pace to how longer words and sentences read.

The hope is to add a stylistic set for character disambiguation to the font, which when enabled would enable graphic features on glyphs like upper-case "i" and lower-case "l", zero and "O", and so on. Tracked here: https://github.com/rsms/interface/issues/1

Hello Jack. I'm the creator of Interface. Indeed many glyphs's outlines comes from Roboto (though fitted into different glyph boxes.)

The "playground" feature of the website even has a feature for comparing Interface with Roboto. When you do, and you look at the details, you'll find that Interface is actually quite different from Roboto, at least as far as "different" goes with utilitarian UI fonts. https://rsms.me/interface/lab/?size=22&compare=roboto

Thanks. We'll look into it.

Is this on the "landing page" (figma.com/) or somewhere in the tool itself? We're really dedicated to performance and take this seriously.

Try using an "incognito" browser window (without any state about your previous browsing history.) Google ranks results based on your search history etc.