Beckism.com

I have never found a Mac OS X RSS feed reader that, after extended use, I was completely happy with, and this makes me sad because my feed reader is right up there with my email client for regular usage. Every time a new feed reader comes out, I eagerly try it, am often very happy with it initially, and then inevitably become dissatisfied with its shortcomings after a week or two of use.

I’ve tried and discarded NewsFire, Vienna, NetNewsWire, NewsLife, Times, and many others which were on my computer such a short time they don’t deserve a mention. None of them fully satisfied my needs.

Most recently, I decided to give Fever a try. Though I highly dislike web apps (I’ve never found a web app that was remotely as good as its desktop counterparts, mainly thanks to speed and usability issues), I love Mint and figured that maybe, just maybe, Shaun Inman would be the one who could write a web app that was actually useable day to day.

Sadly, my hopes were dashed. Fever is too slow to handle the speed that I can skim through feeds, and has some of the same problems that drove me from NewsFire (like refreshing automatically and losing your place in whatever you’re viewing after an update). I find that I never use the “Hot” functionality because it is so useless at actually predicting what I’ll find interesting (partially thanks to my lack of Spark link blogs, but others have had similar issues), and as a result Fever for me has turned out to just be a rather unresponsive generic feed reader.

(Side note: I haven’t been happy with Fever, but I’d still hesitantly recommend it for some people. Simply the fact that its capable of standing up with options like NewsFire and NetNewsWire is a big point in its favor if you don’t mind the Ajaxy slowness.)

Despite my rampant discontent, I still do not want to code a feed reader myself, so on the off chance that someone is trying to make the perfect feed reader, here’s what it needs.

Make sure keyboard navigation is easy to use. This is the part of Fever that I enjoy most. Hit space bar to jump to the next item. Right arrow opens the item in the browser. Enter swaps between excerpt and full text. Left arrow jumps back to the source list to select a different group. Brilliant.

Allow grouping items by source feed. NewsFire does this beautifully, but for some reason none of the other feed readers have even attempted it. I typically want to read or skim items based on which feed they’re in, and grouping items visually by feed makes it very easy for me to do so. Sticking the source website in a column, or under the title, or over the title, or next to the title does not work as well.

Don’t use a three-pane interface. Mail is a brilliant application for reading email. Feeds are not email. Go use Fever, NewsFire, or Times and find out why designing a great, feed reader-specific workflow is a better plan than rehashing the tired old three-pane news reader.

Settings should be possible to apply per feed, per group, or as application defaults. I love that NetNewsWire and Fever both allow me to granularly set behavior preferences for feeds. Setting refresh rates on a per-feed basis is rarely necessary, but when you need it you’ve got to have it. When I was hunting up freelance work, I subscribed to a few Craig’s List feeds. I eventually had enough work that the feeds were just noise, so (thanks to NetNewsWire), I stuck them in a group and turned off refreshing for that group. They were ready for when I needed them in the future, but out of my way for now.

Don’t sacrifice performance for aesthetics. Times, I’m looking at you. Times is a beautiful feed reader, with an innovative approach to feed reading, and a great set of features. I’d be using it right now if it weren’t buggier than an anthill. The somewhat recent 1.1 update fixed a lot of the really annoying bugs, but the program still isn’t usable. Maybe in another few point updates.

Don’t sacrifice aesthetics for performance. Hi, NetNewsWire! To be fair NetNewsWire mitigates this problem somewhat by offering some really top-notch themes, but although the application is certainly solid and obviously has been given a lot of attention to detail, it could still use a bit of the flair of NewsFire, Times, or Fever. I think there’s a middle road here, and on that middle road a talented designer and talented developer are collaborating. Sadly, feed readers appear to be primarily one-man-in-his-basement affairs.

Remember that users will subscribe both to feeds they want to read every word and those they merely want to skim. Times and Fever are both best for feeds that you want to focus on every headline. NewsFire is great for skimming through lots of headlines thanks to its group-by-feed feature. NetNewsWire is actually pretty good at both, as long as you’re careful about how you sort feeds into groups. The problem here is that the needs (and thus best interface) for feeds with lots of signal versus feeds with lots of noise are quite different, yet feed readers invariably only offer a single interface for browsing and accessing feeds (or offer multiple possible interfaces, but you have to switch between them globally for the whole program). I don’t know what the perfect solution is here, but I do know that it can only exist if the program recognizes that I have two very different approaches to feed reading and provides options accordingly.

Perhaps I’ll never see my perfect feed reader, and instead be destined to keep bouncing between substandard options as they release new upgrades and rekindle my hope that maybe this time they’ll have gotten it right. Perhaps Mac OS X feed readers simply aren’t profitable enough to attract the time and care necessary to craft something that does everything I want without being bloated and terrible, and I’ll eventually just have to suck it up and go with a web app.

But I hope that isn’t the case.

My other favorite time estimator is Stuffit, which back when I still used it would tell me that files would be completely unstuffed anywhere from -16,000 to 1,000,000,000 minutes. I never was sure how a file could have been unstuffed in negative minutes. Possibly Stuffit was trying to tell me that it had been unstuffed once before in the past, so why the hell was I opening it again?

Espresso 1.0 has officially been released for general consumption, and I’m extremely proud to announce that TEA for Espresso (coded by yours truly) is bundled with the application! Espresso is a text editor aimed firmly (for the moment) at the web editing crowd, and offers code folding, a powerful code navigator, FTP synching, Textmate-style text snippets (with tab stops and all that jazz), and an extensible underbelly for extending the program. It’s pretty sweet.

That said, I have to admit that my feelings about this release are mixed, and I don’t think that most people who live in their text editor (including myself) will be able to switch to Espresso full time just yet. I’m beginning to think that this may just be how text editors work. I was completely underwhelmed by Coda when it first came out, too, but after Coda 1.5 I tried it again and started migrating projects to it, and as of 1.6 I’m using Coda full time. While some people will find Espresso 1.0′s friendly and simple editing just what the doctor ordered, I suspect that its wider appeal will not be truly realized for another few point releases.

None of which, of course, answers the question, “Is Espresso for me?” Obviously, you won’t know until you try it out for yourself, but for those of you who like to have other people do the initial dirty work, here’s what Espresso is, what it is not, and where it’s probably headed in the near future. (Please note that I don’t have any insider info; I have been participating in the betas since slightly before they went public, however, and would like to think that my guesses are fairly educated.)

In many ways, to understand Espresso you first need to understand what it is not.

Espresso is not CSSEdit

Before you so much as think about downloading Espresso, you need to be clear on one thing: Espresso is not CSSEdit. Yes, you can edit CSS files with Espresso, but it does not offer visual CSS editing, and X-ray and the inspector are nowhere to be seen. You can override stylesheets, CSSEdit groups are supported in the code navigator, and the CSS text editing is very similar, but if you are expecting CSSEdit plus the ability to edit HTML you will be sorely disappointed.

I’m going to make a prediction here (and yes, it’s just a prediction; I have no insider knowledge): I think that Espresso will get X-Ray in a point release. I think it will probably get the inspector and the ability to jump straight from the Inspector to a style in the CSS. But I don’t think it will ever get CSSEdit’s visual editors. Why?

Because competing with yourself is stupid.

CSSEdit is the best way to edit CSS (right now, anyway). Espresso is shooting to be the best way to edit code, no matter what the language.

Perhaps someday MacRabbit might want to merge CSSEdit into Espresso and retire their original flagship product, but don’t hold your breath.

All that said, I’m as baffled as the next guy why you can’t right click a CSS file in Espresso and choose “Edit in CSSEdit”.

Espresso is not Coda

Particularly when MacRabbit announced Espresso and showed off screenshots of an integrated FTP editor I think a lot of people assumed that Espresso was setting out to be an all-in-one editor to challenge Coda (albeit much more slimmed-down). “Hooray!” cried the masses. “Perhaps at last we’ll have an all-in-one solution with a decent text editor at its core!”

The masses were a ways off the mark. Coda attempts to give you every tool you’re likely to need to edit code. Espresso tries to give you a fantastic environment for editing web pages with an extensible Sugar architecture to allow you to expand the editor to other languages. Notice how different those two sentences are.

If you love Coda because of the diverse tools that it gives you, you’ll probably be underwhelmed by Espresso. However, if the shortcomings of Coda’s text editor rub you the wrong way and you don’t very often find yourself using SVN, books, the terminal, etc., then Espresso might be a wonderful solution to your needs.

Espresso 1.0 is a foundation

In many ways, Espresso is building off the legacy of Textmate, if you can say that a piece of software that’s still nominally developed and actively used has a legacy. Text snippets with tab stops and mirrored segments directly mimic Textmate’s snippets and the Sugar syntax system is fairly Textmate-y, as well. Where Textmate provides extreme flexibility with a correspondingly steep learning curve, Espresso attempts to provide some of the core aspects of that flexibility but focus on providing users with a more polished, CSSEdit-ish application.

Espresso 1.0 is a foundation, a solid feature-set that shows the core capabilities of the program and through its scope and design may give you a good idea of what directions the application is likely to grow. When I first read MacRabbit’s descriptions of Espresso I immediately began imagining the possibilities, and every time I launch it I find myself imagining possibilities again. It has the potential to grow into an application almost as flexible as Textmate, but easier to extend and with a friendlier interface that also happens to offer the core features needed for web development.

Aside from its potential, Espresso 1.0 is a powerful text editor that’s overly focused on web design with a few rough edges tucked away beneath the overall gleam of its interface. It’s better than most of the web-centric offerings, but may not be quite good enough to lure you away from heavy hitters like Textmate, Coda, or the venerable BBEdit.

If you’re looking for a simple yet powerful web-oriented text editor with a lot of flexibility and promise for growth, I highly recommend giving Espresso a download. As long as you don’t go in expecting CSSEdit, Coda, or something that will turn into a magical unicorn and solve all your problems you should be pretty pleased with what you find, even if, like myself, you’re unlikely to be able to switch to using it full time for your day job until the application is a bit more mature.

That’s nice; what about TEA?

I haven’t been talking about TEA for Espresso much because although I’m ecstatic that it was one of the few Sugars chosen to be included in the application, it frankly wasn’t ready. I still consider it in beta even if Espresso is out, and because I didn’t know that it was going to be bundled in the application until the morning the app was released, some of its better features are broken. Once I’ve got it in a more mature place, I’ll definitely brag about it a bit more and offer some examples of how to use it; for now, please give me a shout in the Espresso forums if you have any feedback, requests, or bug reports.

I have always disliked Terminal. I got a basic grounding in Unix command-line usage in a C++ class in college, but Terminal still bugs me. Yes, I can adjust colors and fonts in the preferences, but it isn’t the background color that bothers me; it’s the fact that I can never tell my prompt apart from my output.

This became particularly aggravating when I recently started using Git. Git, unfortunately, does not have a great GUI client on the Mac that I’ve found, so I was doing all my work on the command line and determining where the prompt ended and output began was getting to be a persistent problem. I also was not happy with the fact that almost any command besides a simple cd or ls was wrapping onto multiple lines; the default Terminal prompt just takes up so much horizontal space.

Fortunately, it is possible to modify your bash prompt, and having trolled the internet and tested various solutions, here’s what I’m currently using to distinguish prompt from output:

Yes, my computer is named Tastefully Delicious. I myself am not entirely certain how this occurred.

My custom prompt isn’t perfect, and it’s certainly a lot more basic than some that you can create, but it does a great job of visually distinguishing between input and output which is exactly what I needed. Fortunately, it’s not terribly difficult to enable something like this; although bash prompt examples around the internet range from gibberish to hundreds of lines of cryptic functions that you have to load into your bash session, understanding the basics of a custom bash prompt in order to make your own peace with Terminal is quite simple.

First off, head over to IBM’s cheat sheet for bash prompt modification. This was by far the best reference I found on modifying the prompt, and offers a complete listing of available bash sequences and colors (as an added bonus, it uses a much simpler syntax for colors than some other sites advise). In my examples below I’ll be using the specific variables for my personal prompt, but you can of course substitute any bash sequence that you like to make the command line your own.

There are two main parts to customizing your prompt: deciding on the right prompt declaration for you, and then writing it to a file so that it’s loaded every time you load bash. The prompt is stored in the PS1 variable in bash, which you can examine like this:

echo $PS1

To temporarily change the variable (for instance, while testing out various prompts), you’ll run something like this:

export PS1="Your prompt here > "

By adding bash sequences to your prompt, you can make it display more interesting information. For instance, if you wanted to use just the second line of my prompt (what folder you’re in, what computer you’re logged into, and what user account you’re using), you could enter this:

export PS1="\W @ \h (\u) \$ "

Which would result in a prompt that reads something like this:

You can, of course, use any of the sequences listed on the IBM reference. For myself, I found that changing the content of the prompt itself wasn’t enough (even when I experimented with multi-line prompts); what was really needed was some color.

Colors in bash are rather offputting, but easy enough to use as long as you’re careful. The basic format is \e[0m — "\e[" starts the color code, 0 is the actual color declaration (0 specifically means "reset to default"), and "m" ends the color. However, in order to make sure bash wraps things right (should they need wrapping) you have to add some backslash-escaped brackets to mark the code as taking up no space on the line:

\[\e[0m\]

Fun, illegible times. In the color chart on IBM’s reference, you can see the various codes associated with different colors. To setup a specific color combination, separate different numeric color codes with semicolons (so far as I know, order doesn’t matter). So if you wanted red text on a black background you would use \[\e[31;40m\] and if you wanted bold green text on a blue background you’d use \[\e[1;32;44m\] (the number 1 makes the text bolder and/or brighter for use on a dark background). You can also leave off any of the color codes (to just set the background color without messing with the default text color, for instance).

For my prompt I wanted something more subtle than most of the bash colors provide for, so I set the background of the whole window to light gray in the Terminal preferences, and then used the code \[\e[1;30;47m\] which set the text to the bright variant of black on a white background. I wasn’t too happy with the bold text, but fortunately Terminal offers a pair of options to disable bold text and make it “bright” which worked perfectly for me:

With colors worked out, the last step was adding a horizontal rule (via underscores) to separate out the prompt even more. My default Terminal window is 80 characters wide, so I just tossed in 80 underscores. I’m certain there are ways to get tricky with functions and only output as many underscores as you need to fill the window, but that seemed like more effort (and processing overhead) than it was worth.

So without further ado, my complete custom bash prompt:

export PS1="\[\e[1m\]________________________________________________________________________________\n\[\e[1;30;47m\]| \W @ \h (\u) \n| => \[\e[0m\]"

There’s additionally a second level prompt that you may need if you’re entering a command over multiple lines. I just duplicated the final line of my original prompt for the secondary one:

export PS2="\[\e[1;30;47m\]| => \[\e[0m\]"

For both of them, note the “return to default” color code at the end; if you don’t enter that, you’ll end up with an entire window the color of your prompt, which will likely defeat the purpose.

Once you’ve found a prompt that you like, you’ll want to save it so that it automatically loads. To do this, just add the export commands to a hidden file in your home folder named either “.bash_profile” or “.bashrc” (I don’t have any idea what the difference is; I’m personally using .bash_profile because it already existed in my home folder).

Once you’ve saved your path to the file, you should forevermore experience a more visually appealing (and possibly informative) bash prompt, hopefully rendering Terminal a less painful program to use.

Here’s the thing: I absolutely adore LaunchBar. I use it constantly throughout the day, and if I’m using a computer without LaunchBar I practically can’t function because I keep habitually hitting the LaunchBar shortcut and opening Spotlight on accident. So when I write Applescripts that I want to accept text and do something with it, I use LaunchBar-specific code.

However, there’s a large number of people out there who prefer Quicksilver (link to Google Code project; also see Blacktree’s site). I don’t know if it’s for the sexier (if more complicated) interface or just because they’ve got Quicksilver embedded in their fingers as badly as I’ve got LaunchBar in mine, but they’re unlikely to switch anytime soon.

And then there’s the folks out there who haven’t discovered the joys of a launcher program and just run Applescripts manually or with something like FastScripts.

All of which adds up to a bit of a conundrum if you want to share your favorite Applescripts with the world. Fortunately, with a bit of Googling and some good old trial and error, I’ve written a simple Applescript template that allows all users, no matter how they like to launch scripts, to use yours. Without further ado, here’s the code:

-- You'll want to rename this function something appropriate
on action_function(someText)
    -- Check to see if we've got text, ask for it if not
    if someText is equal to "" then
        set question to display dialog ("Enter text:") default answer ""
        set someText to text returned of question
    end if
    -- Do whatever your script does here
end action_function

-- Quicksilver tie-in code
using terms from application "Quicksilver"
    on process text qsText
        my action_function(qsText)
    end process text
end using terms from

-- LaunchBar tie-in function
on handle_string(lbText)
    my action_function(lbText)
    open location "x-launchbar:hide"
end handle_string

-- Call the function in case the script was run directly
-- (Don't worry; this line won't execute if called from LB or QS)
my action_function("")

If you’re familiar with Applescript, the code should be pretty self-explanatory. You wrap all of the scripts actions into a function (called action_function in the example), and then call that function using the specific access routines for Quicksilver or LaunchBar (with a normal call to the function included just in case the user directly accesses the script). The code within action_function is merely a fall-back in case it receives a blank string (you’ll likely only need the fallback if they are calling the script directly). I leave any more specific error checking to you.

This template specifically accepts text; if your script needs to process a list of files, for example, you’ll need to change the code for the various programs appropriately (how specifically to do that I leave up to you, but the general template should still serve you well). One caveat is that if you’re compiling the code, you’ll need Quicksilver installed (even if you only use LaunchBar). However, as far as I can tell, if you’re just running the Applescript you don’t need to have either program installed (or you can have just one or the other). The main downside of needing both to compile is that if you rely on your users to adjust config variables in your script, then they will need to install Quicksilver (unless you include instructions to remove Quicksilver’s code if they aren’t using it).

Let me know if you run into any trouble using this code! I haven’t run into any errors with it in my testing, but that certainly doesn’t mean that they don’t exist.

In case you hadn’t heard, TextSoap was updated to version 6.0 a few weeks ago. I’ve waited on posting about it because I wanted to share some of my custom cleaners (you can jump straight to the download if you’re so inclined), and now I’ve finally found the time.

For those who know about TextSoap, version 6.0′s main benefit (at least from my point of view) is a vastly redesigned custom cleaner editor. Cleaners can now run text through sub-routines, there’s a quick regex reference right in the window, and you can attach notes to cleaner actions to remind yourself what the heck that complicated regex pattern is supposed to be doing. There are other improvements, as well, but the custom cleaners interface is where it’s at for me. If you’re curious, check out the release notes for the full scoop.

For those not in the know, TextSoap is a fantastic piece of software that allows you to make changes to plain and rich text both using built-in cleaners or custom cleaners that you define yourself by combining regular expressions and any of the built-in cleaners with familiar Automator-style rules.

Yeah, I know, it doesn’t sound too impressive, does it? But that’s only because you’re used to wasting a lot of your time on mindless repetitive tasks involving text. TextSoap not only provides an easy way to save sets of common text-based find and replace actions, but it allows you access to them from pretty much anywhere on your computer by integrating with popular programs via plugins, offering a system-wide contextual menu, or hanging out in the Services menu.

When I first bought TextSoap, I regretted it because I barely ever used it (this was back in version 4.0, I think). Then one day I was doing something incredibly repetitive with text (I don’t even remember what), and I got fed up, launched TextSoap, and took a look at the custom cleaners. I’ve never looked back. Although the most powerful custom cleaners require knowledge of regular expressions, there are still hundreds of things you can do without ever worrying about regex simply by combining TextSoap’s provided cleaners with the building blocks available in custom cleaners. TextSoap provides an approach to text manipulation that has saved me hundreds of hours of drudgery.

Over time, I’ve found that the custom cleaners I create tend to fall into two categories:

1. Cleaners that address specific problems that either recur or only happen once but require the same actions repeated a bunch in that sitting. For instance, for one client I have to convert a Word document into a newsletter every two weeks, observing their byzantine rules for HTML formatting. The first time I did it, it took a mind-numbing four hours. The second time, I created a custom cleaner while I worked and it took me two. The third time all I had to do was use the custom cleaner, and it took me one. With practice, I’m now down to about forty minutes.
2. Cleaners that address generic recurring actions. These are cleaners that I’ve slowly tweaked over time, and now use primarily as building blocks for my task-specific cleaners.

It’s this last type of cleaner that I would like to share with you.

My XHTML suite of custom cleaners

My main use for TextSoap is manipulating HTML, and because I know a lot of other people out there have to do this on a regular basis I’ve decided to share the basic cleaners that serve as the foundation for my workflow. TextSoap has revolutionized how I perform certain tasks (particularly converting styled text to HTML and converting really hideous HTML into tasty XHTML), and I strongly recommend it to any web junkie who has cursed out a previous developer for their table-filled monstrosity of a website. Before I get into the nitty-gritty details of what’s included, here’s the download:

Download TextSoap XHTML Suite

Included are eight custom cleaners (if you’re only interested in one or two, see the ReadMe for details on which cleaners require one of their brethren):

• Encode Ampersands. This encodes every ampersand that isn’t already part of an HTML entity.
• Escape Single Quotes. Primarily useful for Javascript, PHP, etc., this escapes all single quotes with a backslash.
• HTML Curly Quotes. For those clients who must have curly quotes, this is your solution. It converts every quote outside of HTML tags into a curly. (Please note: only works for English curly quotes.)
• HTML Paragraphs. This converts text blocks separated by double line breaks into paragraphs, and converts single line breaks to <br /> tags.
• Style to HTML. One of my workhorses, this cleaner takes richly formatted text and turns it into simple, paragraph-delineated HTML with appropriately placed strong and em tags.
• URLs to HTML Links. This cleaner finds all of the easily recognizable URLs in a document (starting with http, https, or www) and converts them into HTML anchor links.
• WebHappy. This happy little cleaner simply converts richly styled italics and bold into strong and em tags, straightens all quotes, and converts any problematic characters into HTML entities.
• XHTML Cleaner. This is a pretty hefty cleaner, and I run it by default on any HTML that needs serious love to turn into XHTML. The cleaner performs a laundry list of common tasks (properly escaping self-closing tags, b to strong, lowercased tag and attribute names, etc.) and also attempts to add and remove linebreaks so that you can easily indent the code in your favorite editor (like Textmate). I rarely use XHTML Cleaner directly, but it offers a great starting point for any custom cleaner that needs to deal with poorly written HTML.

Although some of these cleaners are great on their own (I have a special place in my workflow for WebHappy, for instance, even if I never did think of a good descriptive name for it), a lot of them work best as the starting place for your own task-specific custom cleaners. I’ve tried to add notes to all of the regex rules, as well, so they may help you figure out how best to perform your own tasks (keep in mind that some of these cleaners were developed while I was still figuring regex out, so some of those regular expressions are narsty). If you improve or otherwise modify any of the core suite of cleaners, drop me a line because I’d love to see what you’ve done.

Enjoy!

Coda 1.6 has been released, and boy howdy is it exciting! Coda now includes a plugin architecture, including Cocoa plugins for people who need to be able to manipulate the interface and an easy-to-use plugin creator that will allow you to run plugins using command-line languages (similar to Textmate). This is a fantastic update, and as we start to see plugins being produced I don’t doubt that Coda will become more and more appealing for Textmate users who have been holding out. It’s certainly not as powerful and flexible (no tab stops, for instance), but the addition of user-generated plugins will certainly allow people to do great things.

Along with the update to Coda, I’ve updated the TEA for Coda bundle (find the most recent version on the dedicated TEA for Coda page); all of the scripts will now perform their actions in the active document even if multiple windows are open. Additionally Indent New Line should be significantly improved performance-wise. The scripts do now require Coda 1.6, though; if you’re running an old version of Coda expect buggy behavior.

I am unlikely to improve the TEA for Coda scripts anymore; my new goal will be to get the Textmate bundle items that I know and love into Coda using the plugin interface. This will necessitate learning some Cocoa, though (since some of the key actions require user input), so it may be a little bit of time before I’m able to get a working plugin up and running. In the interim (or until someone else does it), TEA for Coda is still the best way that I know to get Coda to behave like a full-blooded HTML editor.

I’ve posted a minor update to my TEA for Coda bundle. This update includes two changes:

• The HTML Tidy script is now a universal binary! At long last, our PPC friends can run it just as easily as those with newer hardware.
• The Format with Em and Format with Strong scripts now keep your text highlighted rather than moving the cursor to the end. This is not only more congruent with Textmate’s behavior, but I think it makes better sense, particularly if you ever need to wrap the text in more than one tag (or wish to add a class name, or…).

You can get the update from the dedicated TEA for Coda page. Unless you use PathFinder or have some other way of viewing invisible files, you’ll need to replace the entire HTML directory (if you’ve made changes to the scripts, you should copy them into the new directory before replacing the old one). If you are comfortable with invisible files, then you’ll just need to replace the .lib directory and the Format directory.

I recently discovered that, utterly without fanfare, a new version of iShowU had been released: iShowU HD Pro (and iShowU HD, a less feature-rich version of the software). Looking at the screenshots it looked like it was a clone/competitor to ScreenFlow. However, aside from some obvious mimicry in the interface, iShowU HD Pro approaches screencasting from a completely different angle than ScreenFlow and will appeal to a different set of users.

ScreenFlow, for those who aren’t aware, is an all-in-one screencasting solution. The general idea is that ScreenFlow captures positively everything that happens on-screen (while simultaneously recording audio, of course) and after you’ve recorded everything you can go in and highlight certain mouse interactions, add iSight video clips, change what part of the screen has focus, etc. If you are using ScreenFlow, then you are almost certainly intending to do a fair amount of post-production work on your screencast from within ScreenFlow before you share it with the world.

iShowU HD Pro, on the other hand, has no post-production capabilities whatsoever but enables you to post a finished screencast in the shortest amount of time possible. Unlike ScreenFlow, once you finish capturing a screencast iShowU HD Pro compresses it down (very quickly, using your graphics card to accelerate the process), and then provides you one-click access to post the video on YouTube (presumably more upload options will be provided in the future). Depending on the length of your video and amount of compression you can have it online and shared with the world literally seconds after you finish recording.

Unlike the original iShowU, iShowU HD Pro also allows you to visually highlight mouse clicks and keyboard events, or record from your iSight simultaneously while recording your desktop. Aside from the iSight recording, however, these features are all or nothing. When you start the program (and before you start recording) you can toggle mouse and/or keyboard capture on or off, and then for the duration of your video you’ll either have highlighted mouse and keyboard events or you won’t. You can also position an image over some or all of your recording area if you want to, say, have your website address displayed along the bottom of the screen. Sadly, this too will last throughout the entire movie.

iShowU HD Pro and ScreenFlow are doing very similar things from a technological standpoint (allowing you to capture high definition video or your entire screen), but the programs are obviously catering to very different crowds. iShowU HD Pro will be perfect if you need to record screencasts as quickly and easily as possible. It is one of those wonderful programs where you can be completely comfortable with the program within three minutes of launching it just by playing with the interface. If you need to record screencasts to share with your friends, or are a software developer who just wants to show users how to use a small feature without spending hours producing a video, then iShowU HD Pro will be an excellent choice. (It’s worth noting that iShowU HD Pro also supports drag and drop export to Final Cut Pro, so it likely has an audience with those people who like ScreenFlow’s capture capabilities but who feel limited by its post-production features.)

ScreenFlow will be much more appealing to the crowd who want to disseminate their screencasts a bit more widely and don’t mind putting in the effort to first learn the program and then do post-production on their recordings.

I’m pretty surprised that iShowU HD Pro hasn’t made more of a splash on Mac news sites and so forth; the program has a few issues and feels very much like a 1.0 release, but is still obviously a good contender in the screencasting software arena. Sure, it isn’t as flexible as ScreenFlow, but for some people who just want to get a good-looking screencast up as fast as possible, iShowU HD Pro at its cheaper price point will likely be the perfect solution.

At last! Galvanized by bug fixes and minor improvements, I finally tackled my two biggest wishlist items for my Textmate Emulation Applescripts for Coda: Wrap Each Selected Line in Tag and Indent New Line. Download the updated scripts, or read on for the details.

Wrap Each Selected Line in Tag does about what it sounds like. Select a bunch of lines, run the script, and you’ll get a dialog where you can enter the tag and its attributes (identical to the current Wrap Selection in Tag). Once you’ve entered your tag, the script will wrap all of the lines with it (and ignore lines that are nothing but whitespace). This is incredibly handy for creating lists.

Indent New Line isn’t inspired by anything in the Textmate HTML bundle; rather it’s inspired by Textmate’s automatic indenting. When you run the script it will take your cursor (or any selected text) and stick it on a new line at one more level of indentation (based on what you’ve selected in the Coda preferences). This script is a great complement to Insert Open/Close Tag: type div, run Insert Open/Close Tag, and run Indent New Line to end up with:

<div>
	|
</div>

(pipe represents cursor)

Indent New Line is also super useful for keeping your indentation clean when working with Javascript functions; just type your curly brace and run the script to get a nicely indented place to start coding.

I have now completed all my “must-have” items for TEA for Coda, so let me know if you have any favorite actions from Textmate (or elsewhere) that you’d like to see added to the bundle. I’m always open to suggestions. As always, you can get the most up-to-date info about the script on the dedicated TEA for Coda page.