More Data vs Design

Continuing the data vs. design meme, I'd like to point to two recent articles. The first cites studies that qualitatively demonstrate that "more attractive" design is more usable. I generally tend to agree with this sentiment, so I don't find the findings terribly surprising. It is heartening to have some hard evidence though. And the idea that emotion is important is a simple yet powerful one.

I also pretty strongly agree with the idea that attractiveness is not universal — that it's subjective. So what may be more usable for one person may be less so for another. This is not really addressed in the article, which is too bad. I think it's an important point, and one Modernism is known to actively avoid or completely disavow.

The second article speculates on the true nature of the typical Google employee and what makes him incapable of even perceiving the differences between good and bad design. It's a pretty snarky take, and I can't say I take it too terribly seriously. But it's a fun read, and probably holds some grain of truth as to why Google's design looks the way it does.

So, if anyone's still interested in this topic, go check out the articles. Very interesting stuff.

Coda Follow-Up

So I wanted to mention quickly that I went ahead and finally bought Coda. I have not been disappointed. It's pretty fabulous.

A couple minor things that bother me:

• When I'm working on a page that contains session values, and then I save that page, Coda auto-refreshes the page in the Preview window. But it loses the session data, forcing me to go back to the previous page and resubmit a form. This often makes previewing in another app — specifically, a browser — more convenient than staying in Coda.
• The Books section is nice, but sometimes the web is better. The web gives me examples that the books often lack, and Coda's book search is pretty lacking compared to Google; it does not appear to allow complex searches of the books.

Both these points lead to one inevitable conclusion: Guys, build a browser into Coda! Am I right?

On the plus side, I have made one joyous discovery: In Text Wrangler, my previous web-text editor, when you double-click a PHP variable only the letters get selected, not the variable symbol. Let me give an example. Let's say I have a variable called $cheesewiz. That variable is preceded by a dollar sign, which is a common way to denote variables. If I double-click that variable in TextWrangler, it does not select the dollar sign. This is fine, and has been the preferred behavior nearly every time I copy-paste. The Text Wrangler way (which seems to be the way most text editors handle such a thing) makes it just as easy to replace by hand everything in my document that says "cheesewiz" as it would be to replace all instances of "$cheesewiz", whereas if the behavior were reversed this would not be true.

In Coda, the default is to select the dollar sign when editing PHP code ("Double-clicking a PHP variable now includes the $ prefix once again"), which is fine too, and I understand the logic, it's just almost never what I want to happen. But I've recently discovered that in Coda — and this is really cool — if you double-click $cheesewiz and then, in one gesture-like fell swoop, move the mouse slightly to the right before letting go of the button, Coda will deselect the dollar-sign. So Coda actually gives you two ways to select variables: double-click to select the whole deal; double-click-jiggle to select only the variable text.

And that, my friends, is remarkably slick.

Design vs. Data Redux or: Apple and Tandy

I got a number of great comments on the recent post on Design vs. Data. But my favorite by far was on the subjectivity of design and aesthetics:

"The way things look is important, but the way things look is also *subjective*. Terribly so. I have a Macbook Pro and I think it looks like something Tandy would have come up with in 1979. Really, that whole slightly rounded silver design is TRS-80 style."

It's true that a comparison can easily be drawn between, say, my beloved titanium PowerBook:

And the TRS-80:

It's also true that which design you prefer is a very personal thing.

But I think my point was less that Google's apps look crappy, and more that the crappy (in my view) look of their apps (among other things) makes me think that they don't regard design highly, and that if they did hold design in higher regard they could innovate even more than they already have, and make even better products. I assume Google is a company always on the lookout for ways to improve. I'm arguing that a stronger focus on design is one direction that might lead to better products.

Today I was struck by an article over at Ars Technica about Yahoo's new image search preview page. Typically in search engines, clicking on an image in a list of image search results brings up a page that has a frame at the top that contains the image, a link to it and some info about it, and the page that actually contains the image in another frame beneath it. Yahoo has decided to make that upper frame actually useful by granting it some new capabilities, namely, a preview of the next search results and a group of related searches. What's instantly notable is how beautiful the search result frame looks:

Clearly, Yahoo is paying attention to design, and I would argue that it's this attention that has yielded not just better looks (again, to my eye), but greater functionality. The upper frame is visually distinct from the referring page through the use of color. The use of imagery, layout and color and font choices clearly delineate both what the upper frame is and what it does. Contrast this with Google's search result page:

It seems clear to me that Google has not given a great deal of thought to the design of their frame, especially when seen next to Yahoo's version. Google's result frame is both less appealing and less distinctive. It is not readily apparent why the frame exists or what function it provides. Nor does it provide much function at all. I maintain that even if Google were to implement the sort of functionality that Yahoo has incorporated into their search result frame, were they to continue to ignore design to the extent that they have their result frame would be significantly less usable than Yahoo's. I also can't help wondering if Google's lack of design sense may even prevent them from coming up with ideas like the ones present in Yahoo's version of the search result frame, though on this I can only speculate.

So, not to beat a dead horse here, but I did want to reiterate what I was trying to say in Design vs. Data, and point to a rather striking example of it. I think Yahoo's search result frame is just swell, and I would guess that it's at least partially the result of a design sensibility.

Alarms: The Downside to Calendar Syncing

I'm thrilled to have all my calendars centrally located and synced after all these years, I really am. But there is one minor downside: email alarms.

To explain: let's say I have a calendar called "Birthdays" (which, in fact, I do). That calendar lives on a server (Google's, to be precise), and all my computers read and pull birthday information from it. Great. Just as it should be.

Now let's say my mom's birthday is coming, and I don't want to forget about it. So I add an alarm (or, what Google calls a "reminder") for the date — an email that will get sent 24 hours before Mom's big day. Now, a day before Mom's big day, Google's server will see the calendar alarm and send me an email reminding me of the upcoming big day. Awesome. Very handy!

Unfortunately, Google's server is not the only computer that's aware of the alarms.

As I said, all my other personal computers (or, "PCs," as their sometimes called) are aware of my Google calendars. I use iCal on my laptop, for instance, to subscribe to my Google-hosted Birthdays calendar. I do this on my work computer as well. And on my home tower. Each time one of these systems loads the Birthdays calendar it also loads the alarms. And, as one might (or might not!) expect, it acts on them. So each system that loads my Google calendars also sends out any alarms that have been set up. That means that I get no fewer than four emails reminding me of Mom's big day. And in my case, I send out two emails per birthday — a heads-up one day before, and then one on the day of the event. Do the math. That's a lot of emails.

Well, at least there's no danger of forgetting, I guess.

The good news is, there does seem to be a cure, though it might not work for everyone. iCal has two preferences that apply to this problem under its Advanced preference pane. They are: "Turn off all alarms" and "Turn off alarms only when iCal not open." The former will cause iCal to ignore all alarms. This is great if all your calendars are online (which mine are, luckily). But if you still have some local calendars with alarms, those alarms will not get sent. In that case, the latter may be a better choice as it will only stop alarms being sent when iCal is closed; open iCal and you should get your local alarms.

This could still be a problem for folks with a bigger mix of local and server-based calendars who really rely on local alarms, and in some ways it forces you to choose between one approach or the other. Ideally, iCal would offer a third option, something like "Disregard server-based alarms." But I'd say for the vast majority of users there's a solution here.

On a side note, this problem has been bugging me for a while. I discovered the fix during the writing of this article, and I'm pretty glad about it. It's just one more advantage to having your own blog. Shweet!

UPDATE:

Reader augmentedfourth posts in the comments an option I'd totally forgotten about, namely that alarms for individual subscribed calendars can be disabled locally as well. Simply locate the calendar in the sidebar, select it and choose "Get Info" from the file menu (or hit command-i). In the dropdown you'll see an option to disable alarms for that calendar.  Click it, and there you go.

Coda and Espresso

I've been tasked with building my first ever, real live web application. And I'm loving it. It's a classic but fairly simple HTML/CSS/PHP/MySQL deal. Perfect for learning the sort of basic web programming that I've been wanting to learn for quite a while, and just the kind of puzzle that gets me excited. In the course of its development I have, understandably, become interested in refining my workflow. And so, one-window site editing applications like Panic's Coda have been on my radar.

Actually, even without a web project, Coda's been on my radar as an interesting application design for some time, so this project was a good opportunity to give it a real spin. But when I initially tried Coda I dismissed it. I'm not entirely sure why. It could be that I hadn't gotten far enough along in my process to really understand how it works. Or maybe it was all just too much; maybe I was overwhelmed by the sheer scope of the app. It does a lot.

I'd eventually settled on editing my site over the network using Transmit (also by Panic) as my FTP client (I had to forego Yummy FTP for this as it's much slower editing over the network for some reason), TextWrangler as my HTML/CSS/PHP editor and Firefox and Safari as my preview browsers. (I'm using Sequel Pro to manage my databases, FWIW, and it's been terrific.) I've actually been pretty happy with this combo. It's lean and mean, mostly free, and fast and easy to use. But it's clumsy and requires that I keep all these different apps open. Apps that can eat up a lot of RAM and processor cycles and slow things down in general. It also requires switching contexts as you switch from one app to the other, which can also bog down the process somewhat.

With the recent release of Espresso, a new one-window, do-it-all website editor from MacRabbit, the makers of the beautiful CSSEdit, I decided to revisit the realm of one-window website editors, hoping that a comparison between Espresso and Coda might help me better understand the utility of these types of apps. So I sat down with my site and began a side-by-side comparison, taking note of the things I loved and hated in each. What follows are my random notes and observations.

Espresso:

• Love the sidebar/tab bar, particularly the Workspace

  The sidebar contains the site — the hierarchy of files you're working on — as well as a "Workspace" of frequently accessed documents. Very handy!

• Like the Project concept

  This is sort of the main conceit of these apps: each site is a "Project" and can be fully accessed from a single Project window.

• Hate that servers are per-project and can't be reused

  Every time I set up a Project I have to enter the server information, even if another project is using the same server. There are no server bookmarks of any kind.

• Hate that there's no way to see the file path of a given file

  While Espresso's contextual menu does contain "Reveal in Finder," and there is a beautiful icon that tells you if a file is on a server, there's no obvious way to quickly determine the path of any given file. I don't know about you, but I have lots of files called "index.html" on my server, and I need to know which is which. The only way I can see to do this is to command-click on the document icon in the title bar. Inconvenient!

  

• Love the Live Preview

  Espresso's "Live Preview" is pretty much a browser window that will update as you make changes to any given page. It can be open in its own window alongside your site editor or in a workspace inside the main window. Crucial, in my opinion, for any kind of one-window site editor, and a pretty nice implementation.

• Hate that you can't see HTML DOM structure in Live Preview

  I'm really getting into DOM inspectors, those things that let you rollover the sections of a page and see what part of the code they live in. I can get one of these for Firefox. I miss having one in Espresso.

• Love style sheet overrides

  Style sheet overrides are really cool. Setting a style sheet override allows you to see what a page will look like using a different style sheet. I'm not sure how much I'd use it, but I can see where it would be immensely handy.

• Love snippets

  The Snippets window is a place where you can drop frequently used code for later use. Love this, and Espresso's implementation is beautiful.

• Love the Navigator

  Unique to Espresso is its "Navigator" on the right side of its main window. The Navigator lets you highlight whole blocks of code. Say you want to highlight the meta code on an HTML page. Just select the whole thing with one click using the Navigator. Nice!

• Love code folding

  Code folding allows you to hide away code that you're not actively working on in a page. Got a long PHP script in your page, but you only want to look at the HTML? No problem. Just activate code folding for the relevant chunk and the PHP will roll up into a bubble on the page. This is great for coding big, complicated pages.

• Love that there are key-commands for indenting, outdenting and commenting

  This is common, I know, but after having it in TextWrangler I don't think I could live without it.

• Not sure why Settings is called "Settings" when it only contains server settings

  Perhaps more will go here some day, but right now it's only server settings. Why not call it "Server Settings?" Or "Servers?"

• Hate, hate, HATE the fact that there is no color palette

  I guess I'll just have to memorize all those hex codes. Um... Seriously... I can't find one anywhere. This is a problem.

• Dislike that the only way to drill down in folders is to use disclosure triangles

  Not sure why this is. Double-clicking a folder in the sidebar doesn't drop you into that folder. In fact, it doesn't do anything but sound an error alert. Weird. This should behave as much like the Finder as possible. Anything else is just confusing.

• Dislike that Live Preview is not auto-updated when working remotely

  If I'm working on local files, the Live Preview window gets updated on every save. But if the file I'm working on lives on my server, Live Preview's not so live anymore. I'll have to refresh the window to see the change. At that point I may as well have a browser window open.

Espresso Overall:

For the most part I like Espresso. It's beautiful to look at and incorporates some novel and extremely cool features. But it lacks certain basic functionality that some might consider crucial. The lack of a color palette, in particular, seems like a major oversight to me.

Coda:

• LOVE the CSS editor; brilliant!

  Coda's visual CSS editor reminds me, ironically, of CSSEdit, which is made by MacRabbit, the company that makes Espresso. I can only think that MacRabbit omitted the visual CSS editor from Espresso to keep from cannibalizing sales of CSSEdit. Too bad. 'Cause the one in Coda is really nice, and doesn't require having an extra app open.

• Love the Local/Remote views

  Coda keeps both local and remote views of your site in separate tabs in the sidebar. I prefer this to Espresso, which keeps local files in the sidebar and remote files in the main work area of the window.

  

• Love the contextual menus and the ability to edit in other editors

  Coda's contextual menus contain all sorts of useful stuff.

• Love that there are key-commands for indenting, outdenting and commenting

  Again, standard, I know, but this is a deal-breaker.

• LOVE the DOM hierarchy inspector

  In Coda's preview window you can turn on a DOM inspector that shows exactly which page elements are which.

• Love the tab rollovers that show the file path (though sometimes they disappear too slowly or not at all)

  Rolling over the tab for any given page will show you a heads-up of its location. This is great. Occasionally the heads-up stays on, for some reason, even after I've rolled away. But I like this implementation a lot. It tells me just what I need to know. No more, no less.

  

• HATE that you can't view a preview side-by-side with the code; that blows

  Actually, not only can you have the preview in another window, you can also have it in another pane in the same window, and that pane will auto-update when changes are made (even remotely). Which brings us to...

• LOVE split pane

  Coda has a feature called Split-Pane that allows you to split a window into multiple sections and put whatever you want in each section. Typically I keep the editor open in the top pane and a preview open in the bottom pane. Very cool! I just wish you could set a preference to always open windows this way.

• Love clips (like snippets)

  Clips are Coda's version of Snippets, a storage area for blocks of frequently used code.

• OMG! LOVE the CSS editor!

  Did I mention the CSS editor? Yeah, this thing is awesome. And guess what? It even contains a color palette. You know, for getting colors.

  

• Love the "Highlight matching brackets" feature in scripts

  Arrow-key over a bracket in your code and Coda will highlight the corresponding open/close bracket with a super cool circular sonar effect.

• Love that Coda saves the application state

  Coda remembers what you were working on and where you were in the site's file hierarchy even after closing the app. This is great as I easily forget what I was working on from day to day.

• HATE that there is no global list of servers

  Coda, too, lacks server bookmarks. How is it that the maker of one of the most popular FTP clients — which certainly does have server bookmarks — doesn't include this obvious convenience in their web editing application?

• Like that you can access a terminal when needed

  Having a terminal window available is nice. Not exactly a necessity, but quite useful. My favorite touch here is that Coda cds into the site directory you define when you set up your project.

• Books are a great idea as well, making Coda true one-window site design

  I have to admit I'm finding the PHP manual here immensely helpful. I only wonder why they excluded a MySQL manual. Were there licensing problems, perhaps? Kinda sucks to have to go to the web to look up MySQL calls. But, Coda, see how you've spoiled me!

• Multiple tab styles take some getting used to

  Coda's beautiful, and packs so much into such a small space, and I'm not sure how you'd avoid this. But there are tabs for freaking everything: Sites in the sidebar get one kind of tab, pages get another, and there there are tabs for mode (Sites, Edit, Preview, CSS, Terminal and Books). I'm used to it now (it didn't take long) but I did find it confusing at first. (I remember reading something by the Panic folks about this, so I think it's something they're aware of and working on. Ah, yes. Here we go. And here's the initial criticism, which is far more informed than my own, though I think the basic problem we're talking about is the same.)

Coda Overall:

Coda is an amazing app, loaded with great advanced features as well as all the basic stuff you'd expect from an app like this. In fact I have very few complaints about this app. It both looks and works beautifully and is as revolutionary as everyone's been saying.

Conclusion:

I have to admit, I was not convinced — and was even a bit confused — by Coda initially. But once I had a real, meaty site to work on, the usefulness of Coda began to become evident. I was also convinced of its usefulness, oddly enough, by trying its competitor, Espresso. Don't get me wrong, Espresso is a wonderful application, and I have no doubt that it will soon give its older sibling a run for her money. But right now nearly every complaint I have about Espresso is answered by Coda with competence and style. Espresso is beautiful and simple and has useful features that really shine, but Coda is the clear winner when it comes to sheer number of features (which I think is what I originally found daunting). And while I really like the Workspace concept and the Navigator, Coda's fantastic CSS editor and better preview integration trump them by a long shot. Coda wins on basics as well, providing essentials like a color palette and allowing you to look at the filesystem more naturally as well as giving better information about the location of the file you're looking at.

There's a bit of a learning curve with this type of app, and Coda's is probably a bit steeper than Espresso's. I'm already grappling with learning HTML, CSS, PHP and MySQL, so I may  not be quite ready to jump into — or pay for — this type of environment. I have yet to decide if I'll actually buy one of these apps, but it's looking like, right now, if I do, it'll have to be Coda.

UPDATE:

Reader EchoD writes to mention that additional books can be added to Coda using the little plus sign doohicky at the bottom of the Books mode window, thus addressing one of my minor Coda complaints.

EchoD also notes a link with instructions on how to customize your books. Pretty cool!