Last week I was telling the story of how the NY Times played a big role in getting my first company, Living Videotext, off the ground. It was 1983, and I had just shipped the Apple II version of ThinkTank, a product that's actually a lot like Fargo. I was having trouble getting anyone to look at it. I was pestering Erik Sandberg-Diment at the Times because I was reading his software column, then a very new thing for such a mainstream publication. I felt he'd get the idea, because he approached software from a non-traditional point of view. He was the kind of person I had made ThinkTank for. I could just feel it.

His review came out at almost the exact moment I was giving up, and getting ready to look for a real job. I looked up the review today, it's in the Times archive, and read it again, 31 years later. The computer industry still doesn't understand outlining software, and Erik's review still cuts through all that, especially the last paragraph:

It was after running the tutorial that I came upon what may be one of the best uses of all for Think Tank, and it's not any of the myriad organizational tasks stressed by the program's producers. Rather, it's simply putting people at ease using a personal computer for something besides games. Think Tank is so easy to use, and so relatively errorproof, that even a first-timer feels as if he's in charge of the computer, instead of the other way around. And being in charge of the computer is what enables you to do with it things you may never have thought of doing before.

Bing!

I've been dealing with a really bad cold for almost a week. I got really sick last Thursday, and spent a few days sleeping and watching Netflix series. I started feeling better yesterday, and today I felt much better, but still called-in sick. I've learned over the years that my downfall when managing colds is that I declare victory too soon, and then relapse and lose more days. So I spent an extra day reading and sleeping and doing a little light writing and thinking work.

One of the little projects I did was a review of the to-do list for Fargo 2 today and decided that nothing on it is important enough to wait for, so the next mini-project will be to archive Fargo 1 and make 2 the default. It'll still be marked a BETA to alert users to be extra cautious and make backups periodically.

After this release, I'll be free to start new projects, or pick up some others that were on the back-burner, something I'm really looking forward to. I love Fargo, I use it all the time, but I'm itching to create something brand new.

There's a brief thread on Twitter with interesting participants from different parts of the web design world. Not sure exactly where I fit in, but I found I had a perspective to offer, and decided to write a post instead of a sequence of 140-character chunks.

The idea of Bootstrap, as I see it, is to add a layer of standardization between the app developer and the "hardware," in this case, the user interface offered by the modern HTML 5 web browser. When you view it this way, there's nothing controversial about it. It's what engineers always do. When we see complicated chaos, we try to figure out what's really going on, and produce a simplified and rational view of it. Then all the code that rides on top of the new layer can also be rational and relatively simple.

I want to tie-off the details of how menus work, for example, in one place, and once done, I never have to do it again. But there's another view of it. If there's only one place I do menus, and we have a rational abstraction of what a menu is, then we can slip in a whole other implementation behind it, and the upper-level code, unaware of the change, will still work.

Even better if a large base of software agrees on how menus are done. Then people can create tools for authoring menus. So we get to a higher level. Something everyone had to do for themselves at one point, now is part of the toolkit that everyone can build on.

This is how all software is built. Bootstrap is just another instance of this process, and a much-needed one.

Another example, when I write Mac software, I don't get to say how menus or dialogs work. That's up to the operating system. That makes the developer's life easier, but it makes the user's life easier too. If you only have to learn how to use one type of menu, you can learn to use more types of software. Why waste time learning two ways to do something so common and simple?

Same with dialogs, typefaces, layout, the details of style-creating. Almost everything you see on this website, scripting.com, flows through Bootstrap in some way.

Over time the innovations of the past become commodities, and then are baked into the OS, creating room for innovation at a higher level. When software is flowing properly, this should be a process that's repeated frequently. Never too soon, never before the pattern of use has emerged, but hopefully not too late. We are ready for what Bootstrap does. It's good that it exists, and I think it's something everyone should build on.