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 :–)
Thanks for the response, definitely excited to see where you take this and the videos you tweeted looked interesting. I'm certainly all for long term projects :)
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 :-)
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.
Recently, I started using Firefox plugin NoSript which stops javascript execution on random websites. It makes browsing little better.
I started using it when I found out one tab was eating 2GB of RAM. I think in todays world its very important that you allow only selected trusted websites to run Javascript!
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 :–)
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`
What is the rationale for defaulting to proportional numbers? I always assumed that "tabular numbers" are just "numbers", and deviating from that standard sounds like a recipe for needless confusion. Sure, you can flip a CSS switch, but how many webdesigners know that these switches even exist? And what about native UI frameworks where these switches don't even exist?
