January 2012

This is the best thing I’ve read about Path, and it perfectly articulates something I’ve thought not only about Path, but also a lot of other exemplars of the fussy, post-Apple wave of “high design” in tech products.

Because Hibari is a secondary app, I want it to fit in with the feel of the operating system as much as possible. I call Hibari “minimalist,” but it’s certainly not an instance of bare, angular, monochromatic minimalism. I’m aiming instead for a quiet, soothing, Japanese-style minimalism; one that feels natural. For my taste, an angular black & white app juxtaposed against the grays of OS X wouldn’t produce the most minimalist result.

Because in the past the user only had to decide whether to share something they just read, but now they have to think about every single article before they even read it. If I read this article, then everyone will know I read it, and do I really want people to know I read it?

Every few years I check out Linux-on-the-desktop, and every few years I’m disappointed because it seems like they’re just designing Windows clones.

The argument for this is that it made it easier for people to switch. Which I think is a terrible argument: why copy something sucky? Why not attract users by doing something new and better?

In recent years it started to get a little better, when Ubuntu started to design Mac clones instead. I say “better” because I think Mac user interface is better than Windows — but the same criticism still applies. Why not try something new? Why not shoot for better?

Maybe, finally, the Linux world is trying something new. Or, at least, Ubuntu is. See Mark Shuttleworth’s blog post about the HUD and the future of the menu.

I don’t know if it’s a good idea, or if it will prove usable. But I’m in full favor of the spirit.

Since Fantastical is all about natural language processing, localization is an especially interesting issue.

With most apps, localization means translating menus and labels into other languages and displaying the right translations based on a user’s language settings. But Fantastical has to go farther: it has to understand what you type.

The first step in understanding what you type is to know what language you typed. The developers could have gone the straightforward route — look at your language settings — but instead they went a step further: Fantastical detects the language based on what you actually typed.

This means your system could be set to French but you could type Spanish text and it will work.

I like this. The best Mac developers have been famous for taking the extra steps. Most people won’t need this — but those who do it will delight.

During my rare spare cycles, I’ve been working on updating a Toolbox app which was Carbonized just enough to run on OS X back in 2001.

It still runs now, yes, but years have passed, and many of the APIs it uses have been deprecated. I can’t even use Xcode 4 to build it — I have to boot back into Snow Leopard and use Xcode 3.

The biggest challenge with this app, by far, is dealing with QuickDraw. I’ve already switched from Open Transport to sockets and switched from old date APIs to NSDate and related APIs. But QuickDraw is the black beast, since it’s so unlike Quartz.

Among other things, it’s given me the opportunity to learn Core Text, which I hadn’t had a need for until now — but which I will need soon in my job.

The code is a great reminder of how far we’ve come and how much easier many things are now. For example: this code has switch statements for which part of a scrollbar was hit. It calls WaitNextEvent. It uses cooperative threading (which meant using non-blocking sockets). It’s got lots of globals. It’s written in C (but using a very object-oriented style, with structs, function pointers, and callbacks).

Eventually I’d like to make it a Cocoa app — but the first step is replacing deprecated APIs and being able to build on Lion using Xcode 4.x. (It still runs on Lion, at least.)

Toulouse as a dining, lounge and experiential possibility was inspired and built around notions larger and more expansive than any particular theme or region: unique and lusty cuisine that requires discipline and skill to prepare; texturally rich and intricate décor that can only have been designed and created by individuals who approach their craft with focus and commitment; and the general desire to deliver the various possibilities of dining, drinking and adult escapism to others in a way that is positive safe, friendly, values-driven… and which leaves everyone better off for having had the experience.

Not a word about how good is the gumbo — and plenty of words that make me want to never go there, ever.

Flash is finally losing ground, and developers are replacing it with standards-based technology.

There’s a renewed interest in design of all kinds — very much including web design. See Dribbble and Ui Parade. Native mobile app design ideas are coming to web design, and designers are experimenting.

While the giant companies are busy rediscovering the America OnLine model of walled gardens, while Congress is debating the Stop Online Piracy Act, developers are remembering the web as the open garden of free speech. And they don’t want to lose it.

I haven’t done serious web work — HTML web work, that is — since I last worked on Manila 10 years ago.

I’ve done some small things — the system that generates this blog, for instance — but I haven’t had the chance to use almost any of the newer web technology. I’ve never written a Rails app, used JQuery, or deployed to a virtual server.

So when I had the chance to re-do the websites for our company and main product, I was excited — because it meant I could try some of the new technologies and learn some things.

The plan: re-do four sites

I wanted to re-do SepiaLabs.com and Glassboard.com — their home pages and blogs. That’s two sites, but in practice it was four sites.

I don’t claim these as exemplars of design, and there are bugs and nits to fix — there’s plenty of room for improvement. Tons of room.

I’ll talk about #2 — responsive web design — and what I learned.

Breakpoints

Responsive design works because of the combination of CSS layout and CSS media-queries. You can change the layout for different sizes.

When I first started, I created two breakpoints (where the layout changes): one for iPad-sized screens and one for phone-sized screens. It seemed logical.

Later on I figured out a better way: create breakpoints when the layout breaks.

I just shrank the width of my browser window until the design broke in some way, then I dealt with it, either by changing things or by creating a breakpoint and changing the layout at that point.

This made more sense because I was working with the design rather than thinking about specific devices.

Layout

It was kind of like working with toothpaste.

When the layout broke and I created a breakpoint, I worked from the top down to fix the layout. The more narrow the screen, the more the layout became vertical, and the more often I relied on centering to make things work. I also hid things (via display: none) that were nice at bigger sizes but that weren’t needed at smaller sizes.

That’s not the most sophisticated approach, but, given the time constraints and my goals, it worked.

Why not design for mobile first?

As I was finishing the sites I read some advice on the web: design for mobile first, then build up to the desktop size.

I like this advice because it forces you to think about what’s utterly necessary from the start, and it makes sure the mobile size is not an afterthought or something done in a hurry when the project is due.

That’s not what I did, but I think I’ll try it next time (whenever that may be).

CSS Transforms

Sometimes I needed to move something from where it would naturally be to somewhere nearby. Sometimes the traditional way of doing it would make for bad code: divs-within-divs-within-divs, or worse.

One way to move something a little bit is to use translate, translateX, or translateY. Simple.

I kind of think of this as a bit of a cheat — certainly something to be used sparingly. But it worked.

Tools

I started by doing CSS by hand, just me and a text editor. I got about halfway through before I switched to Sass and Compass.

Sass is wonderful. (I’m sure I’d like LESS no less.) Just having variables alone would be enough for me to love Sass, but it has a bunch more (functions!) besides.

The way it works is that you launch a command-line script that watches for changes in your .scss file (the file that you edit). When it changes, it compiles a .css file. It happened so quickly that I never noticed the compile time.

JavaScript

Though the sites have some JavaScript, none of it is used to make the sites work at different screen sizes. I didn’t think it would be necessary, and it turned out I was right. (Using JavaScript for this would make the sites harder to maintain, I reasoned.)

Testing

Testing on my desktop was easy: I used Safari, Chrome, and Firefox. I also then uploaded the sites to a staging server and tested with IE 9 on Vista and Chromium on Ubuntu (via VMWare) and tested with an iPad and an iPhone. Other folks in the company tested with other browsers and with Android devices.

But testing was absolutely necessary. Though adoption of CSS3 has progressed, this is not quite standards-based Eden.

Version control

I created a local Mercurial repository whenever I started a project. I have not yet taken this all the way. I should have a repository that other folks at the company can access, and I should have a deploy script for staging and live servers.

This is made somewhat complicated by the blogs: they’re WordPress blogs, and I don’t know if changing a theme is scriptable. (Maybe it is. I haven’t looked yet.)

What have I not learned?

I’ve dipped my toes in: I’m a novice. At this point in learning new technology I try to get a rough idea of the size and shape of everything I haven’t learned yet. I also assume that I’ll look back to now and smack my forehead.

But there’s an important thing I did learn: I learned that this work is fun.

I was reminded of how the Cocoa world felt in 2002 — those days felt like early days again. There was so much excitement for what we could make and what would come next.

Running a search at Google was starting to feel like walking through a minefield. I’ve trained myself to be careful where I click, because I might step on a +1 explosive or get blown to bits by surprise double-chevrons.

But I still used Google search, because I trusted the search. Now I don’t.

Losing trust of its users may be the worst thing a search engine can do.

I’m trying Bing, which I never thought I’d do. It’s easy to switch: the search bar in Safari has a little menu where you can choose your search engine. You can switch back if you don’t like it.

I don’t trust Bing yet, but I don’t have a reason to distrust it, either.

That’s the thing. If it weren’t for the web and software — if I had had to rely on somebody telling me “yes” to have a vocation — I’d still be a busboy.

(I was a great busboy, by the way. Detail-oriented, fast, and good at keeping the coffee cups full. Seattle-ites will recognize some of the places I worked: Trattoria Mitchelli, McCormick and Schmick’s, A-Jay’s, and Chinook’s. Mostly Chinook’s. I loved coming home with actual cash every day.)

It reminds me of the classic geek religious war between the text editors Emacs and Vi.

Emacs is its own world — it’s been described as an operating system that happens to include a text editor. You can read your email, open a shell, and debug your app all inside Emacs. (And plenty more. Way more.)

Vi, on the other hand, is more purely a text editor. If you want to read your email, you use your email app. If you want to debug your app, you use a debugger instead of Vi.

Emacs is a container for a whole set of tools, while Vi is one tool in a chain.

I like Vi’s approach. It’s realistic, because, no matter what, people do use more than one tool. And it means that Vi can focus on being a great text editor rather than on doing a bunch of things.

I see my blog that way: it’s one place on the web, the place where I write. It’s one leaf on a tree. It doesn’t have to contain everything. These days there are so many ways and places to comment — so many other tools — that including comments here would be Emacs-like.

Scripting isn’t the new literacy, it’s the new tinkering with the engine, the new re-wiring the house. The new DIY for the digital age. These sorts of skills are incredibly valuable, but they’re not now, and certainly won’t be in the future, anything close to being an art form that stirs our souls.

Code isn’t an art form — but neither is musical notation. Music is an art form. Eventually, the things that code builds (websites, apps) will become art forms too. Eventually.

I got on the Homebrew bandwagon about 24 hours ago — and I like it so far. I haven’t investigated it in any deep way. I’ve just installed a few small things. But it’s simple and it works.

The most recent thing I installed was contacts (which is useful to connect mutt to the OS X Address Book). I could have cloned the repository and built it — but it was so easy to do brew install contacts that I did it that way. And I feel fine about it.

How does that set Homebrew apart from Fink and MacPorts? It may not be that much different — but it feels more modern and less fiddly. Installing was simple. Use is simple. It’s git-based. Formulas are Ruby scripts. There’s no weird /opt folder.

Bonus: it has a delightful typo on the home page, where it says that “Homebrew compliments OS X.” (Italics mine.) I know that complements was meant, but the typo made me think that Homebrew is a nice, polite young person who compliments their elders. Why not?