Learning from Terminals to Design the Future of User Interfaces

Don't get me wrong, Electron has a lot of issues. I think Slack should switch toolkits. But I don't see how we argue that a famously poorly implemented app is somehow indicative of the entire space of GUI apps and that a space equally fraught with UX issues is somehow obviously better.

Especally when we have excellent examples like VS Code, which is cheerfully giving neovim and emacs a run for their money and displacing longtime contenders like sublime, because it's genuinely quite good and plenty fast enough for most folks.

Unfortunately, not every animation. In particular, the Spaces transition animations that the OP is complaining about is not one of the ones you can disable with `defaults.write`.

I re-check if it's been added with every new macOS release; no luck so far :(

I don't think the 'terminal' model of UI gets enough attention. I don't know why that is, perhaps it is a feeling that it is the "old" way to do things and so not a source of good ideas.

Xerox's XDE had a very nice terminal. It could use proportional fonts and you still had precisely formatted text for code. It was not as fast as a VT100 or an xterm which relied on monospaced fonts. But that was the root of the issue.

Terminals conflate "formatting" and "content" in the worst way possible, there is content that "is" formatting (whitespace). This closely mimicked how typewriters did it but they did it that way not because it was "best" but because it was "possible" given the mechanics of building lines of type without a bunch of lead letters.

It is insidious how that in band content/formatting mixing of ASCII and then later ISO-Latin-x drove compromises in editor and text manipulation tool design. But here we are.

I wrote a pretty printer for come code once that pulled apart the format from the content and it would print out source code with a nice proportional font (I think a2ps(1) could do this too at some point) and I admit that the code "looks wrong" in that form but I also have to admit that it only looks wrong because I'm not used to seeing it in that form. It is harder to read when things like parenthesis fade into the text because they are so much thinner, but this is again the design vs eyeball sorts of trade-off.

When I read this bit what I heard was "Gee, it would be really awesome if some designer could capture the flow of terminals with a modern set of capabilities." But that XDE terminal? Dave Curbow, who was with Xerox Business Systems, once tracked down how many function calls had to be made before the glyph ever hit the screen and it was a lot. It made it hard to run efficiently on the hardware of the time (great when you can code new microcode, less useful on CPUs without that capability).

I wrote a comment under a different post just a few days ago. My comment got _way_ out of hand and wasn't as articulate as I had hoped. But the salient point I made with it is simple and applies equally well to this article.

UI is hard.

User interfaces seems really simple. Every programmer I know has looked at a UI and thought to themselves "I can code that in an hour!" and then ended up spending weeks, sometimes _months_ building the UI.

I believe UI is a big, unsolved problem in modern computer science. Just as hard as any other unsolved problem in our field. Right up there with general artificial intelligence and P=?NP. I'm not even joking.

We will eventually solve the problem of UI. But there are a thousand and one articles posted every day either A) complaining about existing UI or B) telling everyone the solution (without providing real, concrete new libraries, frameworks, code, etc). No one wants to admit that this stuff is just plain hard and we shouldn't beat ourselves up over the fact that we haven't solved it yet.

In other words, it's easy to complain. It's easy to display hubris. It's hard to put forth real, practical solutions. Or at least be humble and admit that we _don't_ have the solution.

Slack's problems have zero to do with Electron.