Path is tappy and its content reads like the content of taps. “I am in a place,” you tap. “:)”, come the replies.
Buzz Andersen on sexpigeon on Path:
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.
Read both, and then the Khoi Vinh article article Buzz links to.
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.
I love reading about design philoshopy. Good post.
And it motivates me to check out Hibari, which I hadn’t done yet.
360MacDev starts on Friday. It looks like tickets are still available and just $300.
I’m doing the keynote. Other speakers include Mike Lee, Dave Wiskus, Kyle Richter, Colin Donnell, Luc Vandal, and more really smart people. Here’s the schedule.
This may be the only Mac-specific conference in the world! And I totally can’t wait. Mac apps rule. You should go.
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?
My co-worker Nick Bradbury asks:
So “legacy apps” are ones built for the most prevalent versions of Android?
Jenny, on the Glassboard blog:
When I think of oversharing, I think of self-pitying status updates that can at least garner schadenfreude. But this information is useless, much like non-alcoholic beer or another Chipmunk movie.
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.
I enjoyed Gwynne Raskind’s two posts about the Mac Toolbox on Mike Ash’s blog.
Friday Q&A 2012-01-13: The Mac Toolbox
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 Petit is a popular Seattle restaurant on lower Queen Anne that specializes in Cajun food. I recommend it.
But check out their website. The first paragraph:
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.
Luckily, I have eaten there, and I know it’s good. So I’ll go again.
Stephen Hargrove wrote his own static blog generator: it uses Perl, Dropbox, AppleScript, Acorn, and Hazel — and it does a lot more than mine does.
I dig how it works. Stephen writes:
So basically, my workflow is now this: 1. Write a post. 2. Rename the post with the “.markdown” extension. 3. Check my iPhone when the notification comes in to see the post was successfully made.
I bought Slender today. Not because everybody else did — they did — but because I’ve wanted something like this for a long time.
My friend Faisal Jawdat is co-author of Ninja UI — reusable widgets for web pages. Reusable widgets that are lethal.
It looks like the web is being born again, again.
Here are some things I’ve noticed about the web:
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.
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 did them in this order:
I had two main goals:
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.
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.
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.
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).
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.
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.
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 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.
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.)
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.
And now it feels like that for the web. Again.
One day, if you’re working at a business with a “content” based model, you’ll wake up and find out you’re not hitting your revenue numbers.
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.
Matt Mullenweg: “The Internet needs a strong, independent platform for those of us who don’t want to be at the mercy of someone else’s domain.”
Collin Donnell: “No one could tell me ‘no’…”
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.)
Rottin’ in Denmark on Seattle: “Those clouds are made from the vapor of 3 million cappuccinos.”
(Via @johnroderick.)
On GigaOM, Matthew Ingram argues that comments are still worth the effort, and says, “A blog without comments is a soap-box, plain and simple.”
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.
ReadWriteWeb, Jon Mitchell on Google+:
It swarms with disciples of the + waiting for the messianic downfall of the Evil Internet, so that the One True Google+ is all that’s left.
Lesson learned: don’t tease Collin about his man-purse, because he gets “crazy-touchy about it.” Got that? Don’t tease Collin about his man-purse. Do. Not. Do. It.
Good list. It includes Marked, which I’ve recently started using too. I haven’t tried Alfred yet — since LaunchBar does exactly what I want. But I should give it a try.
Nick Bradbury: “Many of my favorite mobile apps are immobile. I can’t take them with me.”
Nick writes about how at work we had a no-WiFi week. It was hell. But it improved our software.
Guy English, Learn to X:
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.
Daniel Jalkut says you should learn to code.
I’m reminded of Matt Mullenweg saying “Scripting is the new literacy.” Matt’s right.
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?
(I hope they never fix the typo.)
Learn how to code this year: Code Year.
I think this is a fabulous idea. I almost wish I didn’t already know how to code so I could learn it for the first time.
Douglas Rushkoff is quoted on the site:
If we don’t learn to program, we risk being programmed ourselves… program or be programmed.