• filed under
• Flash
• Web Design

I’ve seen the meme that “Flash is dead” made increasingly often lately (e.g. here), and as someone who works with Flash on a regular basis, I wanted to address it a bit.

Flash is (should be) enjoying a much reduced presence on the web in future: technologies are coming into general use that dramatically reduce the places where you’d need to use it.

The Flash Site

Fully Flash sites, featuring piles of animations and visual effects were one of the first cases of Flash on the web (I’ve done a few). They’re especially popular with ad agencies and design companies that don’t know the web very well (or haven’t updated their site in a while). For this sort of stuff, we can really stop using Flash.

The effects that are possible with Flash that’d you’d want to use (moving/scrolling elements, sliders, fading in and out, etc.) are easy to do with jQuery/jQuery UI or prototype/scriptaculous or a half a dozen other JavaScript libraries. The sorts of things that aren’t feasible with this arrangement are generally things that shouldn’t be done or are just showing off (the latter of which is fine if you’re a Flash design agency, as 2advanced is). For almost anything that resembles a website, a standard HTML/CSS/JS stack should really be able to suffice.

Why not make a Flash site anyway? They’re slow to load, slow to run, hard to make properly accessible, bad for search engines, and just generally a pain. Also, they’re typically bastions of non-standard interfaces. After all, if you wanted a standard website interface, why would you be using Flash in the first place?

The Web Application

There are a number of (usually graphics-intensive) web applications that run based on Flash, like the Aviary suite, or Photoshop.com. Adobe’s Flex framework is really aimed at building web applications, though it has broader uses as well.

This is an area where Flash is losing ground. JavaScript-based web applications are becoming more and more capable, but for graphics manipulation, support in JavaScript really doesn’t exist yet. (The outlines do, via <canvas> and SVG support, but until IE picks up one or both of these, it’s still not there yet. More on this later.)

Flex does have another advantage, which is Adobe’s AIR environment, which lets Flex apps (like TweetDeck) serve equally well on the desktop or in the browser. There are alternatives to this (most notably, the Cappuccino framework and its Atlas IDE, and some mobile platforms (Palm’s WebOS and the iPhone) allow web apps to run as or emulate native functionality. But for the moment, AIR is the only such environment that’s cross-platform across desktops and on the web (though, notably, not on the iPhone).

Games

It’s possible to do some limited games using only HTML/CSS/JS, but in general, graphics-rich gaming is going to be the province of Flash for the foreseeable future. It’s technically possible to do some serious stuff with Canvas—but the amazingly lousy support IE has for it hampers performance far too much for serious games. And, frankly, the Flash games community is so large that I’d expect it to be one of the last communities to adopt an alternative approach.

Interactive Graphics

Much like with games, lack of Canvas or SVG support in IE limits what’s possible with interactive graphics (maps, charts, tables, etc.). A rich graph like this one would be nearly impossible to make work, and work cross-browser, without Flash. Like graphical web applications and games, this is waiting for Canvas and SVG support to become richer and more widespread.

Font replacement

sIFR is probably the most common font-replacement technique on the web now. There are JavaScript alternatives like Cufon, which relies on SVG (sensing a trend?) or FLIR, but Cufon isn’t cross-browser and FLIR generates non-selectable text (images).

There’s also the @font-face CSS system, which is facilitated by services like Typekit, and unlike sIFR (or Cufon or FLIR), its feasible (even encouraged) to use this on body text. However, there are licensing issues, font format issues, browser adoption issues, FOUC issues, and more. Take a look at Nice Web Type for some more information.

Video

Flash runs most of the video on the web, including every major video sharing site (YouTube, Vimeo, Viddler, etc.), not to mention Hulu. HTML5 included this nifty <video> element that was supposed to make Flash video on the web a thing of the past. Unfortunately, the whole thing got mired in the codec wars, and Microsoft has yet to give any hints of whether they’ll support H.264, as Apple and Google advocate, or Ogg Theora, as Mozilla and Opera want—or if they’ll stalk off in a huff and tell everyone to use Silverlight.

In the meantime, supported video codecs will be officially unresolved in the final definition of HTML5, and so long as Firefox can’t adopt H.264 (its patents don’t expire for another 15 years) and open-source alternatives remain prohibitively poor*, we’re stuck. Which is to say: Flash video is here to stay for the foreseeable future.

So what have we got?

For web design, Flash is toast. We shouldn’t be seeing fully Flash sites in almost any cases. For graphics-rich content—some applications, most games, many interactive graphics—Flash is still clearly the way to go. sIFR, though a royal pain to use, is also still often the best option for font replacement (more fonts can be licensed for it, more browsers support it). And for video, there’s not even a probable replacement in the works. Even in cases where a replacement exists, cross-browser issues are going to plague it for years to come, whereas Flash comparatively just works right everywhere (assuming you can get it to work).

Regrettable as it is, Flash isn’t going away.

---

*from the Ars Technica article: “If [YouTube] were to switch to Theora and maintain even a semblance of the current YouTube quality it would take up most available bandwidth across the internet,” according to a manager at Google. If true, that’s prohibitive.

• filed under
• Print Design
• Web Design

Aisle One has a great article about the utility of grid systems today. You should read it. It pokes holes in a lot of silly misconceptions about grids.

I want to explore one of his points a bit more, though. He talks about the idea that “grids can impede creativity.” That’s false, for sure, but I think it’s particularly important why it’s false. Ellen Lupton (who he quotes) puts it this way: “To say a grid is limiting is to say that language is limiting, or typography is limiting.”

All of these things are, indeed, limiting. But they are limiting in helpful ways. We observe rules of language because, having agreed upon them ahead of time, they help us ensure we are not misunderstood. The rules of typography have been developed over centuries of printing (and calligraphy) to aid the human eye in clearly reading and interpreting letters on a page.

That’s not to say no one breaks the rules (of either English or typography). But to do it effectively requires extreme skill, because you’re working without a net. A master writer may violate a point of grammar or use a word incorrectly because it lets her tease more meaning out of it, rather than less; a great typographer may set text with intentionally irregular spacing or on top of itself or other lines to achieve an effect. But for most people, and in most cases, it is better to follow the rules.

So it is with grids. A grid system is extremely flexible, but it provides constraints that promote good design. It encourages hierarchies and prioritization of content, standard sizing of elements, and a good, clear flow to the work. To the extent that a grid limits you, it mostly prevents you from doing bad things. The grid frees you to be creative without having to worry as much about those things. That’s an unalloyed good.

• filed under
• Web Design

Well, all right: lots of people are still going to put up meaningless lists of trends for 2010 or 2020 or whatever it is they’re doing. And Jason Santa Maria’s criticism is (of course) spot on.

The tendency towards meaningless lists is probably as much lamented as it is irreversible, but I’d like to counter it at least a bit. So, as a public service because I have nothing better to do since it’s a fun way to procrastinate, here’s my stab at addressing the situation: I’ll take a look at a couple design trends that are coming on the web now and try to parse out a bit why they’re effective (or not effective) and what sorts of sites might want to use them. Today…

The Footer

A number of sites (including this one) have been reinventing the footer. Footers have often been afterthoughts in web design, a place for some fine print, utility links, or a basic sitemap. CNN’s recent redesign uses something like this.

But there’s been a big change in the way people interact with content on the web. In the early days of web design, people were obsessed with “the fold”—that area of the page that appeared on the screen when people first load the page, before they had to scroll down. These days, “the fold is dead.” We need no longer obsess about fitting stuff into the top of our sites.

The fold is dead?

Well, all right: the fold isn’t really dead. There’s a number of reasons why people say that, most of which are explained in the links above, but the part that’s important for this discussion is that, contrary to the belief (and perhaps the reality) of the early web, visitors will scroll down the page. Indeed, people scroll all the way to the bottom. (I attribute this to two things, by the way. First, scroll wheels have become ubiquitous on mice in the last decade; second, the rise of blogs and the run-on designs that software like Blogger and WordPress have made commonplace means the web is teeming with very, very long pages.)

If people will scroll, it means the bottom of your website is not a tomb. Visitors will read what goes down there.

Moreover, visitors that do get there are probably people who’re interested in what you have to say. They read your page.

Enter the massive footer.

Behold the Mammoth

So now we’ve learned that visitors to our sites will actually look at stuff at the bottom of the page—putting things in the footer isn’t a waste.

Still the most common use for a footer seems to be site-mapping, but instead of the giant jumble of links many pages use, it can be done elegantly, taking a little more vertical space to let readers make sense of the list. The Los Angeles Times takes this approach, setting out a basic directory of the site at the bottom of every page.

The wonderful FortySeven Media take this a step further, diving into their sites content structure and providing individual bits of content.

Alternatively, CSS Tricks puts a list of site feeds and Chris Coyier’s related other sites in his footer.

Jason Santa Maria’s blog uses its footer as a digest of many different kinds of content he features on his site: portfolio, photos, book reviews, assorted links—and, of course, a search bar.

There’s a central theme in these approaches, and it’s a good one. The visitor who makes it down to the footer read your page—or, at least, was interested enough by what you put above to want to keep going.

More importantly, they’re done with what you’ve just served up to them. They’re looking for where to go next. These footers are in the business of giving them ideas. Sticking RSS feeds or links around your site in the footer is inviting the reader in. They’re saying, “Oh, you liked what you saw? Well, here’s where you can get more.”

An ideal footer might even tailor links in the footer to content on the page (instead of putting it in the sidebar, where people have to scroll back up once they’ve done reading)—though standard blogging software isn’t generally set up for this, preferring to have uniform headers and footers and put post-dependent content in between.

Making Contact

The other common use for a footer is for contact information. Arrival Design puts their address, phone number, email, and a helpful map in their footer, so that anyone can get in touch.

Some sites, like the Greg Brady Project, put their whole contact form into the footer, to make it easy to get in touch.

Alternatively, Edgepoint Church features their social media outlets—Facebook, MySpace, Flickr, and YouTube—prominently in their footer.

These sites are out to make contact with the reader, whether it’s in a business transaction, fan feedback, or to establish a connection, rather than just directing them to other parts of the site. By putting this in the footer, they’re inviting feedback, giving their readers a gentle nudge in the direction of getting in touch, taking the next step—ultimately, making a conversion.

Do I Want One?

Start by thinking how your users are going to interact with your page. Footers work best with linear content, like blogs or articles, where readers will scan from top to bottom and the footer is the natural endpoint for their progression through your content. If you’re designing something that’s more application-like than page-like, a large footer is probably not for you.

Similarly, if your page isn’t organized in a linear fashion, a big footer isn’t going to be as effective. On a site like Typeneu, a large footer wouldn’t make sense (even if the page didn’t scroll endlessly), because the eye isn’t drawn down the page, it’s pulled across and up and every which way. The footer is most effective when the content is driving your reader towards it.

Conversely, a big footer is great for text-heavy sites that draw have blocks of text that direct the reader down, down, down. Blogs and newspapers/magazines are the obvious examples.

Before we move on, though, a special consideration for blogs: comment threads get in the way of the footer. If your blog accepts and displays comments by default, your comment thread and comment form at the bottom will separate your content from your footer. Many visitors who are interested in your content, won’t read through your readers’ content—and won’t see the footer on post pages. Plan accordingly.

Amazon addresses this problem by putting a “footer” in the middle of the page, rather than at the end. There’s a short block of vital information about the book: title, author, price, if it’s in stock, add to cart, etc.— and then: a footer!

Below this is minutiae about the book and then user reviews (e.g. the comment thread). But Amazon wants to be sure people see their footer (links to other stuff you might buy) before you get bored by content they don’t control, and wander off to some other website.

Setting Out on the Right Foot(er)

The first rule is contrast. If you’re going to have a footer, make sure it’s obvious where your content ends and your footer begins.

There’s plenty of ways of achieving that, but by far the most common (and most effective) is with color contrast (e.g. as Jason Santa Maria does). Others use lines (like the LA Times) or large white space (the Greg Brady Project). Whatever you do, it should be clear to your users that they’re looking at a separate piece of the page.

The same things that make for good web design in general, make a good footer. It’s an opportunity to draw your reader in, and suggest to him or her what a likely next course of action might be. Do you want customer contact? Give them a way to reach you. Want them to read your article? Link it in the footer. Do you want people to buy your book? Point them at its Amazon page. Are you soliciting money? Drop in a donate button.

The footer should be part of your overall content strategy—think of it as a generic conclusion to every page of your site. Its job is to tie things up neatly and restate your point (so to speak).

Don’t try to cram the footer with too much content. Keep it straightforward and directed. Your footer can give the reader an idea of where you think they might want to go next. Lay out some alternatives, in a clear fashion. Think about which “next actions” you want to include are more or less important, and use contrast, size, and placement to prioritize them to the reader.

---

Well, that’s all for me for now. I’ll do another of these… probably next time I’ve something to put off. I hope you found this useful. And by all means, let me know what you thought or what I’ve got wrong in the comments.

• filed under
• Browsers
• Javascript
• Web Design

There’s been some contentious debate about the advent of HTML 5, and we’re now (with Safari 4 and Firefox 3.5) getting our first go at actually working with it.

I’m sorry to say it’s not going well.

Others have covered some of the ridiculous issues the new “standard” has brought, like the video standard-that-isn’t and the mess of unnecessary, non-backwards-compatible, semantic tags. I’m going to get into Javascript, here.

One of the key purposes of HTML 5 is to move the browser towards creating richer interfaces. A number of features have been added to the standard. Two I’ve been working with recently are the drag-and-drop functionality and the contentEditable property. Drag and drop is new; contentEditable is much older (it’s a Microsoft invention in IE 5.5 that’s slowly spread to the other browsers).

contentEditable

contentEditable turns an element into a rich-text editable element, but the spec on this offers no particular guidance on how to implement the things it’s supposed to do. execCommand is inconsistent among browsers, and so is the styling: Safari, for example, tosses in <b> and <i> tags where Firefox dumps in <span style="font-weight: bold;"> and <span style="font-style: italic;">.

Drag and Drop

Drag and Drop is even more bizarre. The spec here is much more prescriptive about how the Javascript behind it should work, but there’s still plenty of room for silliness. Ideally, you’re meant to just stick draggable="true" ondragstart="/* drag function here */" on a element and it becomes draggable. It works in Firefox, but not in Safari, which requires an extra CSS element(!?) be applied to the draggable items. Moreover, in Firefox, text is draggable, but in Safari, it’s not. For example:

This is draggable!

You’ll notice in Firefox 3.5, the above rounded box is completely draggable (though you can’t drop it anywhere). In Safari 4, however, it’s only draggable if you click on the healthy padding—click on the text itself and you’re just selecting text instead.

Drag and drop also leaves a lot of mess on the HTML itself: there are a lot of events firing. Shapeshed has a great little overview here.

You’ll notice to create a drop zone requires this lovely markup:

<div id="trash" ondrop="drop(this, event)" ondragenter="return false" ondragover="return false></div>

Cancelling ondragenter and ondragover are currently required. That’s a bit of a mess. (And all the event attributes! Ugh.)

Firefox 3.5’s drag events also bubble in the wrong order: events fire on the lowest elements first, and only then up to the elements they contain. If you stick a dropzone on the <body>, it’s the only dropzone on the page that will fire. Ever.

Worse Together

There’s a note at the beginning of the “User Interfaces” section of the HTML 5 spec (here):

“Would be nice to explain how these features work together.”

Alas, in the case of contentEditable and drag and drop, fact is they don’t, at all. I’ve spent some time hacking the two of them together, and I’ve come up with something that’s almost workable in Firefox 3.5, though not in Safari 4, which (of course) has different behaviors. I worry it’d take me another week at least to figure out the further idiosyncrasies of Safari 4’s implementation; frankly it’s not worth it as I sincerely hope both implementations will be replaced with something better in a future version—which will render my version broken and useless.

Right now, to drop an element into a contentEditable region in Firefox, you have to parse it to HTML (not actually a trivial task). contentEditable has its own idea of what dragging and dropping is and does and it’s got no awareness of HTML 5’s new thoughts on the matter, so it doesn’t interact in any especially controllable (or sensible) way with the dataTransfer features of HTML 5’s drag and drop. In a number of ways, it seems the whole implementation is set to just do what it decides it wants to do and that’s that.

In Firefox 3.5, dropping an element on an editable area dumps text/html or text/plain out of the dataTransfer, which is immutable. (It prefers text/html.) You can drop an HTML element this way by rendering it into HTML, and at least this allows you to drop it at the cursor.

Safari 4, by default, does nothing at all when you drop an element into an editable area, which makes it very hard to select a spot in the text for insertion based on the cursor location.

In neither implementations does there appear to be a model for figuring out where in the contentEditable text you might be dragging something in to; Firefox just happens to handle this by default so long as you’re doing something reasonably compatible with its basic functionality.

 

In all, it’s a frustrating experience. These new features have a lot of bugs to iron out, and it doesn’t help that browser manufactures are happily pushing out products based on unfinished specs that will leave behind inconsistencies web designers will have to plan around for years to come.

• filed under
• Web Design

One of the questions I face a lot when presented with a problem in web design is this: should I build it myself? Or should I take something off the shelf?

The Web today is full of “time-saving” alternatives to us coding things ourselves. These sorts of tools range in complexity from really simple things, like a little piece of Javascript to make .png files appear properly transparent in IE6, to extremely powerful tools that perform a huge host of functions, like content management systems. Some of them are more popular than others.

What can go wrong?

Well, a number of things. The biggest is that you’re taking a risk by using someone else’s code. You don’t know how it works. You won’t be able to modify it without breaching what may prove a steep learning curve. Such things often break in unpredictable ways. People don’t set things up the way you expect. You can cause bugs in places you never expected them.

There’s a risk associated with using these shortcuts, which you’re balancing against the risk that you might not finish the project in time without them.

So how do I choose?

There are a few questions I usually ask myself before I choose solutions like these:

Does it work?

This ought to be a no-brainer, but it’s often skipped: before you commit to using something, make sure it does what it’s supposed to. (If it’s not easy to test yourself, wide adoption is often—but not always—a good indicator of this.)

How long would it take me?

If you’re going to use a shortcut, it should at least be saving you time. This is why I don’t use CSS frameworks (like the increasingly ubiquitous 960.gs). Sure, it’s nice. But I can throw together a custom CSS layout for a site that works as well or better in about the same time it’d take me to put the framework in place and tweak it the way I like it. I’m picky, and it’s just not that complicated.

What does it prevent you from doing?

Shortcuts are often limiting. For example, there’s a really elegant script called s3 slider, built in jQuery, to make a rotating image/link gallery. It’s gorgeous—one of the most elegant examples of its kind, honestly. But it’s restrictive. To set up buttons to skip to particular items in the s3 slider, say, you’d have to alter its core functions (which means first going through someone else’s code to figure out how that might work).

By contrast, jCarousel Lite isn’t as pretty out of the box, but it’s massively configurable. It doesn’t limit you. It’s not that s3 slider is bad: if s3 slider fits your needs exactly, by all means you should use it—but if it doesn’t, or if you think your needs might grow in future, you’re better off using jCarousel Lite.

Is it extensible?

This isn’t always important. In the case of a small element, like the slider managers I discussed above, it’d probably take you longer to learn a plugin architecture for them than it would to just reprogram them from scratch. But when you hit the really big projects, extensibility is key.

Realistically, you’ll never hit a content management system or a JavaScript framework (or anything of comparable complexity) that does everything you want it to, out of the box. But it’s easy to build a plugin for jQuery or WordPress or ExpressionEngine—and there are tons of plugins already built for them. If you’ve picked a good system, it’ll be saving you so much time that learning the plugin system will still be worth the effort.

In summary…

There are some really great systems out there that have saved me huge amounts of time, like jQuery, jQuery UI, and ExpressionEngine; there are plenty of others, like Google Maps, Google Checkout, or sIFR, which let me do things completely beyond my abilities and/or resources. Plenty of others have proved exercises in frustration.

In general, I’m skeptical of timesavers and tend to want to build my own solutions where and when I can. But carefully selecting smart pre-built solutions can save a whole lot of time.

There’s no point reinventing the wheel. Just mind the square ones.

• filed under
• Web Design
• Life

I have often been told, usually with a certain air of self-satisfaction, that Twitter will not replace the newspaper. (Well, okay, maybe The Guardian.)

This is sort of like saying that rollerblades won’t replace the family car. It totally misses the point. Twitter is not destined to be the next iteration of reporting. Or blogging. Or searching the web. Or Facebook. That’s a complete misunderstanding of what it does.

Join the chat room!

Twitter’s most reasonable analogue, if you must have one, is something like IRC. It’s a place where people can come and have a chat in short bursts. The other similar invention of the early web is Usenet. (Of course, both these things still exist; on the web, nothing ever quite dies.)

There are, however, a couple key differences that separate Twitter from its antecedents. First: Twitter is fundamentally open. There aren’t rooms or groups on Twitter. The only closed parts of the system are users who make their posts private (in which case, only people they allow can see their feed), and direct messages, which are fairly incidental. If someone tweets about, say, Expression Engine, someone else can search for that and find it. (Even better if they use the hashtag #expressionengine or #ee, which people use to unify all the tweets on a given topic.) Many twitter clients let you run and observe searches like this in near-real time.

The second big difference is that you only see what you want to. Twitter can’t be derailed the way IRC or Usenet could. There’s no need for moderators. Your main feed is pulled from the people you choose to listen to. If you don’t like someone’s tweets, you can always unfollow them. People needn’t “play nice,” because there’s complete separation.

So what?

That makes Twitter exceptionally useful — if you’re in one of those groups (like web technology or politics) that’s adopted it broadly. You end up very quickly coming into contact with people who have the same interests as you, because they’re searching for the same things on Twitter, or monitoring particular topics on Twitter that are important to them. It’s all a very cool way of making conversation across great distances, and it accomplishes it in a way that its closest relations don’t, because of its open, casual nature. All in all, a brilliant invention.

• filed under
• Web Design
• Review

About a month ago, MacRabbit launched their new web editing tool, Espresso, a full-featured text editor, configurable and customizable to all sorts of languages, plus the wonderful Live Preview feature of their fantastic CSSEdit. Espresso also purports a fully functional FTP client and some pretty robust tools for keeping local and remote copies in sync.

Lucky for me, Espresso was included in the MacHeist bundle, so I have a full copy! Here’s my run-down of how it stacks up against the other two giants of the Mac text-editing world, Coda and TextMate (both of which I use a lot).

Editing Text

As a pure text editor, Espresso excels. It’s at least the equal of TextMate for many languages (especially HTML). It’s easily extensible to additional languages with plugins called “sugars,” and there’s a wide array of them available already, if not better. It’s clear that navigating through complex HTML structures was a key challenge MacRabbit aimed to solve, and their Navigator gives you a foldable view of the whole file tree really elegantly. The CSS Navigator is identical to the one in CSSEdit (no surprise there); sadly, the navigator rapidly becomes useless in other languages, failing even to identify Javascript functions. It does identify comments, so as long as you comment your documents intelligently you’ll still get something out of it.

Espresso’s also very good about intelligent code completion; unlike TextMate (and like Coda), Espresso is very forward about prompting you for your code. I’m particularly appreciative of it’s tag closing—Coda handles this by automatically adding the close tag when you finish the open tag, which is annoying. TextMate relegates it to a contorted shortcut. In Espresso, when you type ‘</’, it closes the last open tag. Clean and elegant.

Espresso’s support for regex, though, really blew me away. Espresso gives you live search results as you type, highlighting everything in your document that matches the search, so you can see, live, as you change your regex how that effects your results, making it super easy to see if you’re picking up the things you want to. Brilliant execution here.

There are two things that annoy me about Espresso as a text editor. First, that it doesn’t automate tab stops, even a little. If you start typing a function, it won’t bother to indent the next line. Annoyingly, I think this is a limitation of the application itself, as it doesn’t even automate tabbing in the (third-party) Python sugar. (It will, at least, preserve tabs from the previous line.)

Second, somewhat surprisingly, its CSS has a major bug. It auto-fills properties (e.g. “display”), but not values (e.g. “inline”), because when you autofill the property it adds a semicolon to end the line automatically, which frustrates the second part of the autofill. (Delete the semicolon and the autofill menu pops right up.)

In all, Espresso may have become my favorite text editor, though there are still a number of things TextMate has on it (for example, in-program validation, code-tidying, and much better support for Ruby).

Live Preview

Unfortunately, past the text editor, Espresso falls apart very quickly. The vaunted Live Preview (brilliant in CSSEdit) is virtually worthless here. You’ve got no tools to search deep into your CSS files based on elements you’re looking at — you’ve got no way to explore your DOM at all, actually, as it lacks anything like CSSEdit’s X-Ray feature or Firebug’s “inspect.”

Moreover, it also lacks a Javascript debugger, and since Espresso, unlike Coda, doesn’t know where to find your files in a browser, it can’t refresh its preview whenever you write the file. If you are working with a database-driven app or anything that involves server-side coding, you’ll have to reload every time you save, for anything but overridden CSS.

Remote Issues

Espresso also includes an FTP client and features for keeping local and remote copies of your file in sync. However, lacking any form of version control, it often fails to catch when files have changed. You can edit files directly on the server, but this functionality is hidden a bit. You have to enter “browse” mode in the connection palette and open the file from there, and then it’ll pop into your workspace with a little cloud next to it.

You can also use the “quick publish” feature, which writes local files to the server whenever you save them. This is fantastic — but you can’t make it the default behavior. You have to set it individually for each file you’re working on. Even more annoying, it doesn’t remember your quick publish setting if you close the file and open it again. I end up setting and re-setting this a lot.

Espresso’s FTP also lacks Coda’s ability to open files in other programs. You can’t, for example, open a remote file in CSSEdit or TextMate or Photoshop and have it write it to the server whenever it’s saved. You could, of course, use Transmit, but that sort of defeats the point of one-app editing.

Final Thoughts

In general, I think Espresso is a great start. The places where they’ve put their design muscle into it shine, beautifully. The text editor is excellent and nearly as fully featured as TextMate, and even better for core languages of the web (HTML, Javascript, CSS). But as soon as you try to go beyond that, you run into the limits of what the folks at MacRabbit have created.

I have high hopes for version 2, but in the meantime, Espresso’s just not quite ready to replace the more mature products out there already.

• filed under
• CMS
• Graphic Design
• Web Design

Remember how I said I was doing a redesign a couple months ago? Well, of course not, no one reads this blog.

However: here it is! 100% Expression Engine goodness.

There’s now two sorts of posts: blog posts (these) and what I’m calling “whimsies” (because I’m silly like that), which are links off to other bits of the web I think are cool.

There’s probably going to be a good deal more design stuff on the blog now, since I do a lot more design work than I did when I started this blog a year ago.

I’ll have some more notes on this later, but for now I’m just thrilled that everything is working right and online. Let me know what you think!