Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
iMovie '09: Speed Clips up to 2,000%

iMovie '09 brings back the capability to speed up or slow down clips, which went missing in iMovie '08. Select a clip and bring up the Clip Inspector by double-clicking the clip, clicking the Inspector button on the toolbar, or pressing the I key. Just as with its last appearance in iMovie HD 6, you can move a slider to make the video play back slower or faster (indicated by a turtle or hare icon).

You can also enter a value into the text field to the right of the slider, and this is where things get interesting. You're not limited to the tick mark values on the slider, so you can set the speed to be 118% of normal if you want. The field below that tells you the clip's changed duration.

But you can also exceed the boundaries of the speed slider. Enter any number between 5% and 2000%, then click Done.

Visit iMovie '09 Visual QuickStart Guide

 

 

Related Articles

 

 

Coda Plays Web Developers a New Tune

Send Article to a Friend

I spend a fair amount of time doing Web development, and although I have access to graphical tools such as Dreamweaver, I've long preferred to do all my coding by hand - yes, even for complex CSS layouts, tables, and forms; it's just the way I'm wired. But even my two 20-inch widescreen monitors don't always provide enough pixels to display all the windows I want to see at once: my text editor (BBEdit), my FTP client (Transmit), a Web browser for previews (Safari, at least for a first pass), Terminal for tasks like running MySQL commands and fiddling with permissions on the server, and frequently, yet another browser tab or window showing the online documentation for PHP.

Clearly, the good folks at Panic have been spying on me, because they used almost exactly that list of windows to illustrate the problem that their new Web-development tool, Coda, is designed to solve. For people like me who code Web sites manually, Coda combines a highly capable text editor, a visual CSS editor, an FTP client, WebKit-based previews, a terminal that supports SSH connections to remote servers, and even online documentation for HTML, CSS, JavaScript, and PHP - not just in a single application but in a single window.

It just so happened that I had a new Web site to create last week, so I've spent a number of hours getting to know Coda with a live project. Although I haven't delved deeply enough into the program yet to write a comprehensive review, I want to share some of my initial impressions. I can summarize them as follows: it's like buying your dream car, only to find out that the seats are kind of uncomfortable and there's no heater. Coda comes so close to being great that its shortcomings are especially annoying. Having tried this way of working, I'm loath to return to having four applications open all the time - and yet I keep running into issues that irritate me almost enough to give it up.


A Quick Tour -- The Coda window has multiple panes and tabs that let you interact with any given site in numerous ways; although a typical arrangement would be to have all of a site's elements in a single window, you can open multiple windows - one for each site, or even multiple windows per site.

Coda lets you specify, for each Web site, a local folder, a remote folder, or both. (Remote folders are accessed using FTP, SFTP, or WebDAV, with the usual array of security options, as in Transmit.) You can edit your files locally and then upload them with a single click or, if you prefer, edit files directly on the server. (At least, that's how it appears: in reality, Coda caches a copy of each remote file you edit and uploads it each time you save.) You can add, remove, and rename files in a familiar list-view pane on the left side of the window, and switch back and forth between local and remote copies using tabs at the top of that pane. Click any file to open it in a new tab in the window's main pane.

That larger pane, in turn, can contain multiple tabs, much like Safari's. By default, new tabs display a full-featured text editor, complete with syntax coloring for numerous languages, code completion, optional line numbering and line wrap, HTML validation, text clippings for frequently used blocks of code, and a grep-capable find-and-replace feature. This editor is based on SubEthaEdit, a collaborative text editor from TheCodingMonkeys that the TidBITS staff uses frequently for projects that require real-time group editing. In fact, you can share Coda documents with SubEthaEdit users and vice-versa. I'd personally find it awkward to edit a single HTML, CSS, or PHP file at exactly the same time as someone else, but I can imagine situations where this would be a useful feature for workgroups. Whether working individually or with others, Coda can track each document's changes, but (like SubEthaEdit) it displays only additions and changes, not deletions.

Because Coda's preview is based on WebKit, Web pages should appear exactly as they would in Safari. You can also preview your work in other browsers with a menu command or keyboard shortcut. Although previews refresh instantly as you work, they're not editable; if you're accustomed to working in a WYSIWYG Web-design program, you'll have to fight the temptation to edit in Preview mode. While in Preview mode, you can inspect a page's underlying hierarchy using a DOM Inspector feature - hover over an element and it appears in outline, with its logical structure shown in a status bar at the bottom of the window. Also available in Preview mode is a JavaScript console, complete with debugger support.

The visual CSS editor lets you change any element's attributes by filling in a form (with helpful pop-up menus showing which options are available where). It's helpful if you're uncomfortable editing cascading style sheets manually or if you've forgotten some parameters, and is similar in concept to (though perhaps not quite as elegant as) MacRabbit's just-updated CSSEdit (see "CSSEdit 2.5 Makes CSS Even Easier," 2007-04-25).

The Terminal mode connects you to the server of your choice (typically, the one on which your site is hosted) using SSH; it can also run a shell on your local computer, just as Apple's Terminal utility does. It's just about what you'd expect from any terminal emulator: nicely functional and straightforward.

The last mode is called Books; in it, Coda can display the contents of No Starch Press's "Web Programmer's Desk Reference," which covers HTML, CSS, and JavaScript, plus the complete PHP documentation. Unfortunately, this information is available only when online; if you try to access it while on a plane (as I did last week), you'll get an error message.


Mixed Modes -- Coda's interface has a way of subtly mixing metaphors that nearly always manages to surprise me - and not in a good way. For starters, the toolbar has buttons for Coda's six main modes of work: Sites (for manipulating the files that make up a Web site), Edit, Preview, CSS, Terminal, and Books. Given a document (such as an HTML file) visible in a tab, clicking one of these buttons, or pressing one of their associated keyboard shortcuts, switches that tab's view accordingly. So, if you're looking at raw code (in Edit view) and you click Preview, you see the final, rendered page. That makes perfect sense. Similarly, if you're looking at a style sheet in the visual CSS editor, you can click Edit to view that same file as raw text. Again: perfect. But if you're editing, say, an HTML file and you click Terminal, instead of opening a new tab with a terminal session - or perhaps giving you a view, within a terminal window, of that HTML document - you replace your current document view with a new terminal session. (One could easily assume - as I did at first - that in so doing Coda had closed the HTML document, since it's no longer visible. But it hasn't; Coda thinks of that tab as still containing the same document.) Similarly, if you click the Preview button while editing a CSS file, you see a useless, word-wrapped text version of the CSS file.

In other words: Coda's modes are a confusion between nouns and verbs. Sites, Books, and Terminal are nouns; Edit and Preview are verbs; and CSS means "Edit as CSS" - another verb. When you're viewing an HTML document (a noun), it makes sense to switch back and forth between an Edit mode and a Preview mode (performing either of two actions with that noun). But an SSH shell session with your Web server is not another view on that document - not another action you take with that noun - and so that shouldn't be the kind of thing you switch into, in the same tab, using exactly the same interface metaphor.

Of course, you can open as many tabs as you want, and each tab can have a different kind of thing in it. One can be an HTML file, one a terminal session, and a third a PHP reference. And, in that HTML file's tab, you can either toggle between Edit and Preview modes or split the window (vertically or horizontally - even multiple times) and have a different mode displayed in each one. Plus, you can not only have multiple documents open at once, you can have a single document open in multiple tabs at once. So, it's not that you can't get Coda to display your information any which way you want. You can. But it really needs a rethinking of those toolbar buttons and the way it distinguishes between viewing modes (verbs) and data types (nouns). All too often I ended up switching my view when what I really wanted to do was open a new tab with a new type of data, or vice-versa.

On yet another level of mixing, Coda's Sites view shows you all the sites for which you've configured settings, but once you open a site, that particular window can contain only files from that site. So even though you can mix and match tabs, splits, and views in all sorts of ways, you can't mix documents from two sites in a single window. In my opinion, this is another respect in which Coda tries too hard to force everything into a single window.

Can this confusion be fixed? Sure, but it may require some rejiggering of the interface. As a quick, partial fix, Panic could force Coda to open a new tab each time someone clicks the Terminal or Books buttons. But better yet would be to stop treating nouns and verbs as being equivalent "modes" - keep the noun-like interface elements completely separate from the verb-like elements. When you're looking at an HTML document (or JavaScript or PHP or whatever), you should be able to choose between two verbs: Edit and Preview. For CSS documents, the relevant verbs are Edit as CSS and Edit as Text. My preference would be for each tab to be tied to one kind of noun (file, terminal session, documentation). Those tabs to which multiple verbs apply could switch modes - but the choices would be constrained by what makes sense for a given type of data.


Preliminary Conclusions -- Apart from the interface weirdness and a few cosmetic bugs, Coda performed for me as advertised. It enabled me to create my site, quickly and easily, without switching applications. But I can't shake the feeling that some important things are still missing.

Panic has made no secret of the fact that they're deliberately keeping each of Coda's modules fairly lightweight. They're fighting feature bloat, and I respect that. The text editor isn't as full-featured as BBEdit, and the FTP client doesn't have all the bells and whistles of Transmit. Coda's main selling point is the integration of all these features. That's fantastic, but here's the problem: Panic's target market is Web-development geeks (like me!). The kind of person who has a bunch of different applications open at once to accomplish the sole task of hand-coding a Web site is also precisely the type of person who relies heavily on all those obscure features in a text editor or FTP client that Coda is missing.

To cite just a couple of examples, I kept finding myself wanting to use BBEdit's Balance command, which highlights everything in the current block of code - useful if you have deeply nested brackets, parentheses, or braces and lose track of where something starts and ends. And I missed BBEdit's Find Differences command, which compares two versions of a document and highlights where they differ. I like to use this when two copies of a file are out of sync - say, one on a staging server and one on a live server - but doing so in Coda, even if it had a diff feature, would break the one-window-per-site model. (Coda does, by the way, let you open any of your files in an external editor, but that defeats the purpose of the integrated window.)

And then there was the realization that switching from one application to another isn't any harder than switching from one tab to another. Yes, that means more window clutter, but not so much that Expose can't handle it. That's not to say Coda's benefits are illusory. But it's also not quite the melding of BBEdit, Transmit, Terminal, and Safari I'd envisioned when I started using it.

The question for me - and, I suspect, for other Web developers of my ilk - is whether the integration benefits of Coda, minus its missing features, are worth $80 (or $70 if you already own Transmit). If I didn't already have BBEdit and Transmit, it would be a no-brainer: absolutely yes. But since I already have powerful tools that work well, the decision is less clear. You can decide for yourself with Coda's 15-day free trial. Coda 1.0 is a 15 MB download, and requires Mac OS X 10.4 or higher.

 

Updated! PDFpen for iPad 1.7: Designed for iOS 7, faster, and
better-looking. Edit your PDFs anywhere. Sign contracts, make
changes, fill forms, and more. All while you’re on the move.
Syncs via iCloud and Dropbox. <http://smle.us/tbpdfpen-ipad>