Clipstart file actions
Clipstart 1.1 is out, with support for the iPhone 3GS, YouTube, and more. I'm really happy with the response I've received so far. The 3GS is such a convenient device for video that even people who weren't taking lots of clips before now find themselves with a bunch of videos. That deserves a dedicated management app.
Ryan Irelan asked me the other day if Clipstart would support a simple email option, for quickly sharing a video with family without uploading to a web site. This is a pretty good candidate for using Clipstart's file actions, which allow you to process the selected video files with a script.
I liked how Acorn handled this kind of thing, so I essentially lifted its file actions feature directly and put it into Clipstart, even down to the ACShortcutKey shortcut comments. Even though Acorn is for still images and Clipstart for videos, it seemed similar enough that you could conceivably take lightly-modified scripts from one app and use it the other, if they did not deal with the file's contents.
Here's the email script that will be included in Clipstart 1.1.1:
#!/usr/bin/osascript
on run argv
set filepath to item 1 of argv
set old_delims to AppleScript's text item delimiters
set AppleScript's text item delimiters to {"/"}
set path_items to text items of (filepath as text)
set AppleScript's text item delimiters to old_delims
set filename to last item of path_items
tell application "Mail"
set new_msg to make new outgoing message with properties {subject:filename, content:"" & return & return}
tell new_msg
set visible to true
tell content
make new attachment with properties {file name:filepath} at after the last paragraph
end tell
end tell
activate
end tell
end
Running scripts has been in Clipstart since 1.0. The implementation is pretty simple. I parse the available file action files to extract the executable path and any shortcut keys and modifiers, then dynamically create the menu items. When it's time to run an action I use NSTask and friends to execute the program and pass the script file and selected movie path to it.
Instead of this:
/path/to/myscript.sh /path/to/movie.avi
Clipstart does it like one of these:
/usr/bin/bash /path/to/myscript.sh /path/to/movie.avi
/usr/bin/osascript /path/to/myscript.sh /path/to/movie.avi
I did this to not require setting +x on the file, but it also seems to be a more convenient way of processing command line arguments when run from osascript.
July 3, 2009 12:31 AM [link]Clipstart for iPhone?
You know it has been a good conference when you come back inspired, with ideas and tools to build new things. No surprise that WWDC was like that for me, as it is pretty much every year.
Even before the keynote was over I was getting questions — which continued all week — about whether I had iPhone plans. At the very least, Clipstart 1.1 needs to be able to import videos off of the 3GS. That's in beta now. But what about a native phone app?
I've convinced myself over the last couple weeks, after listening to what people are doing with their phones and evaluating the existing applications in the App Store, that Clipstart for iPhone would be a very useful app. Video on the 3GS is a big deal. Eventually I can see a new top-level Video category in the App Store, and whoever is in that list is going to do very well.
Neven Mrgan sums up the urgency:
"I'm sure Phil Schiller's prediction of iPhone 3GS quickly becoming the most popular video-capable phone — if not the most popular consumer video device period — is right on the money. A message for those working on apps that help us shoot, edit, organize, and share quick, casual video clips: get ready to get busy."
I'll admit that after WWDC I panicked, thinking for a moment that I had to deliver Clipstart for iPhone immediately, and drop everything I'm doing to make that happen. I no longer believe that. The Mac version of Clipstart has a lot of potential and I can't get too distracted from following up on that. But at the same time I will be expanding what I do on the phone, so we'll see where that goes.
June 29, 2009 01:01 PM [link]FastScripts 2.4
What I like most about the FastScripts 2.4 release is that Daniel was willing to completely change the product evaluation terms to give new life to the product and get it out to more users.
"I have been thinking for some time of eliminating FastScripts Lite. Customers found it confusing to differentiate between the versions, and I found it tedious to artificially maintain two versions. With the new, liberal evaluation terms in FastScripts 2.4, all of the old Lite functionality and much more is now included for free in the full version.
It's always a risk to make a pricing or demo limit change. Whether accurate or not, I imagine the financial side of product development as a delicate tower of blocks, where the slightest change could cause your whole sales structure to come crashing down. For that reason I tend to not touch anything if it is working, but I recognize that I am probably holding my business back at the same time by not being more flexible.
June 28, 2009 09:10 AM [link]Rogue Amoeba at Macworld
Paul Kafasis of Rogue Amoeba on exhibiting at Macworld 2010:
"I'm delighted to be able to plant a flag and say that in 2010, Rogue Amoeba will again be exhibiting at Macworld. We still believe in Macworld and all that it provides. We believe it's relevant, useful, and worth having. We believe that meeting new customers, talking to existing ones, and sharing a great time with all manner of Mac friends, is still worth doing."
I like companies that make decisions based not just on spreadsheet numbers, but on belief and instinct too. It's a shame Apple didn't show more of that when weighing whether to continue exhibiting at Macworld. Because Rogue Amoeba doesn't sell on the show floor, the conference has to be less about directly recouping costs and more about connecting with customers and building goodwill and name recognition. See also Should I Exhibit At Macworld, from Paul Kafasis in 2007.
I haven't attended or exhibited at a Macworld since the late 90s, and every year I miss it.
June 5, 2009 12:43 PM [link]Introducing Clipstart
Last week I looked at the SVN log for my application in development and realized that I had started it exactly 1 year ago. While I wasn't actively working on it every day or week during that time, that's still a very long time for me to work on an application before shipping it. I knew I had to call the 1.0 done and push it out.
I was falling into that infinite 1.0 cycle where I could continue to improve the application forever without releasing it. The sooner I noticed that trap, the sooner I was able to correct course and get the app into the hands of real users.
The app is called Clipstart. It's for importing, tagging, and uploading home movies. I have high hopes for the app and a lot of fun stuff planned for the future.
As usual, a lot of people talked about the product even before I did. My thanks to Dan Moren of Macworld for covering the launch before I even had a chance to spam him with a press release; to John Gruber for posting about how he uses it; and to Duncan Davidson and Mike Zornek for their write-ups. I also very much appreciate all the retweets and goodwill from my friends on Twitter. Those meant a lot.
May 4, 2009 09:58 PM [link]Apple competition in iPhone 3.0
There's always the risk when developing for Mac OS X that Apple will compete directly with your product. iTunes, Mail, and Safari are high-profile examples, as well as the "lightning strikes twice" hit of Watson/Sherlock and Sandvox/iWeb. That history is well documented so I won't repeat it here.
But when listening to the Macworld podcast a week ago (the episode with Dan Moren and Jason Snell back from the iPhone 3.0 announcement) it struck me that iPhone software is a little unique. They made the point, which I think is true for most software, that Apple's offering is usually simple, full of holes that could be filled with new features from third-party developers. There is usually room for a developer with a unique twist on an idea to market and sell his solution to like-minded users, even if Apple ships a default good-enough app for most people.
Except there's one pretty significant problem, especially on the iPhone. Apple cheats.
Third-party apps cannot run in the background. So it doesn't matter how many features a recording app has that Apple won't bother to implement, background recording is the killer feature that will always remain out of reach for developers.
Put another way, if the Apple app didn't record in the background and a third-party app could, that third-party app would likely be worth $5-10 to many people for that one feature alone. But give Apple background recording and it doesn't matter how many features another app adds — syncing music, FTPing to a server, multiple tracks, sound effects, more file formats — it's going to be a challenge to convince users they need two recording apps. I expect some audio developers to overcompensate by adding every feature listed above and more to make up for the one feature they can't have.
April 17, 2009 10:19 AM [link]MacHeist, roofing, and making it up on volume
I wasn't going to write about MacHeist this year, but after a hail storm damaged nearly every roof in our neighborhood, I noticed something kind of obvious: there are a lot of business that make it up on volume.
This is the new MacHeist promise, right? Not just exposure, although that's part of it, but selling so many tens of thousands of copies that the developers do very well regardless of their tiny underpriced cut of the profits per sale.
We don't get hail in Austin very often. I took the Flip out and filmed a little bit of it, as golf-ball sized balls of ice blanketed the yard. Afterwards every roofing company in Texas descended on Austin offering steep discounts, in some cases even covering an insurance deductable of $2000 or more. Depending on who you ask, such practices may or may not be considered insurance fraud, but like MacHeist it does come with ethical considerations. The roofing companies knew that they could do so much business in the next 2 weeks that they will easily make up for reduced profits by the sheer volume of work.
There's another kind of discount shared between roofing companies and MacHeist. Users promote the package they just purchased in exchange for further discounts. For MacHeist it's spamming your Twitter followers (I get a free Delicious Library!). For roofers it's spamming your neighbors with a yard sign (I get $250 off!).
I've learned a few things from all of this that I think will help me make my own indie business stronger, or at least more consistent. I gladly give free licenses to reviewers, bloggers, and small Mac user groups. I also routinely do 10-20% off discounts that anyone who knows how to search Twitter or RetailMeNot.com can use.
But I'm just going to have a default "no thanks" answer for big promotions and mass giveaways. It's consistent with what I believe about keeping prices fair to sustain a Mac business, and it takes the guess work out of which promotions harm the Mac ecosystem and which are a great deal for everyone.
April 14, 2009 08:44 PM [link]Twitter @wii
Last week my @wii account on Twitter passed 3000 followers and seems to finally be growing strong after a year of neglect. I now try to post once every couple days with Nintendo news, and I'll eventually throw in a tweet on new Wii Transfer updates. That was my evil plan from the beginning: have some fun with the account but also use it to build an audience and promote my own projects.
I view @wii as a gift. I don't know how long it will be under my control. As Twitter continues to go mainstream, eventually I expect Nintendo will want my little 3-character Twitter name for themselves, and I might just be glad to hand it off. Twitter works best with a personal voice, and I've already all but closed some of my secondary accounts.
I'm more conflicted about what to do with the Wii Friend Codes site. At one time I imagined it as a full Riverfold product, with integrated Mac and iPhone apps, but now I find that I lack the passion to really take it to new places. And to be honest, it works as is.
March 30, 2009 09:46 PM [link]Open source regression
On a previous episode of Core Intuition, number 14, Daniel and I talked about open source. One LGPL tool I use in Wii Transfer is called FFmpeg, a very popular video conversion project that forms the base of many video web sites, as well as the Mac QuickTime component, Perian.
In the latest Wii Transfer I updated to a new version of FFmpeg, which it turns out had a major bug: broken audio for 8-bit input sources. Of course I am including the fix in a bug fix update to Wii Transfer (still beta in the forums), but not before many customers were hit by the problem.
Not to look a gift horse in the mouth, but it reminds me of one annoyance with FFmpeg: no releases. You basically just follow trunk, and if there's a bug, sorry. This is understandable. It's open source, after all, and the developers don't owe you anything. But at the same time, it's one of the reasons I've moved to Perian-only in my new app, and left the FFmpeg trunk and other similar open source command line tool projects behind. With Perian I can track specific major releases and know that someone has tested them. QTKit is good enough now on Leopard that I feel comfortable basing on app on it.
Daniel also mentioned in passing that violators of open source licenses are likely to get away with it. I think that's largely true, but I found that the FFmpeg developer base has a pretty keen eye to this issue. If they notice that commercial software is using FFmpeg or MEncoder or other portions inappropriately, they will list the software in their hall of shame.
March 23, 2009 03:11 PM [link]Tab click-through areas
It's often true that the further away you get from an event, like the release day for the Safari 4 beta, the closer you get to a fair analysis. Initial Twitter reaction was gut level and some not even based on anything but screen shots. My own post was admittedly slightly half baked, but I think it stands up fine.
Now we are seeing some more thoughtful analysis, including from Dan Frakes of Macworld, and Lukas Mathis, and of course the thorough John Gruber of Daring Fireball.
I wanted to revisit one thing with click-through. If you eliminate the mouse rollovers and click-through for inactive tabs, you end up with surprisingly few places to accidentally click. Here are two screenshots illustrating the difference between Safari 4 and BBEdit.
It's true that the file icon needs a hold-and-drag, so it's harder to click, and the hide toolbar button is off to the side and less dangerous than closing a tab. Nevertheless, viewed by pixels alone there isn't a significant difference between the safely clickable area of these two window title bars if Apple makes this small change.
Update: If I left too much to the imagination, here are examples of the real Safari 4 clickable areas, not the way I wish it would be above.
And the extreme example with even more tabs:
The important point is that if you disable click-through for inactive tabs, the safe area does not change even with dozens of tabs, and in my opinion it is only marginally worse than other standard Mac applications, as shown in the first two screenshots. The current Safari 4 behavior, on the other hand, continues to degrade until the window title bar is nearly useless.
March 10, 2009 09:28 AM [link]Brent Simmons on Git, plus blog anniversary
Brent Simmons is still looking for the perfect version control system:
"People talk about how wonderful are features like re-writing history — and I read that stuff and think, 'Wow, Git's really cool and powerful.' But then I know it could suck me in and take away time from real work. It's already more work — for me — than when using Subversion."
I haven't used Git much since Daniel and I discussed it on an early Core Intuition episode. Like Brent I just don't see a big win for single-person projects, although it's fascinating to watch how open source projects are using Github.
I like what Brent did a few months ago with his blog redesign, how both inessential.com and ranchero.com complement each other. He also wrote more about his publishing system, including a bit in passing about the tool I used to start my blog, Radio Userland.
I mention it because this blog is 7 years old today. Happy birthday to manton.org.
March 9, 2009 08:33 AM [link]Ugly reminders
In my last post about family pricing, I mentioned that I modified my PayPal scripts for backend order processing to support family packs, but I left out that the whole system is a hack. A hack that processes a nice chunk of money, but a hack nonetheless. Hard-coded PayPal buttons and coupons, PHP that would make even newbie web developers cringe, too few lines of code to really be taken seriously.
I refactored it a few months ago, but kept some ugliness in there to remind myself that I should move to a mature store solution. Sometimes we build systems that are flawed from the start, and it's wasted effort to invest time into something that will be replaced. Instead, let the thing stand out like a sore thumb.
It's a complement to doing things simply and taking shortcuts even when it's tempting to overengineer and build the perfect system.
This ugliness trick works for other things too. For example, the Wii Transfer product page is /software/wiitransfer/ instead of just /wiitransfer. I gave this URL more thought and second-guessing than it deserved, and every time I type /software/ or see the link I cringe a little. But I did it for a purpose: one day I hope to sell or promote things other than software. For example, when I registered riverfold.com I was working on an independent animated film which I planned to sell on DVD direct to customers. (I've had that shelved for years now, though, as I've recently discovered there are only 24 hours in a day.)
Others will say that you shouldn't mix such different projects under the same brand, and that makes a lot of sense. But I also know it to be true that if you want to build a strong blog following, you should stick to one subject and become a respected voice in that field, and I didn't do that either. I made a conscious decision with my personal blog to keep it loose and cover several different things that I am passionate about, and because of that I'll likely never have tens of thousands of readers as other popular Mac development blogs have.
So maybe one day Riverfold will sell something other than Mac software. When that time comes, it won't matter what the URLs are, but until then, the /software/ URL won't let me ever forget that I have other things in mind.
February 27, 2009 10:02 AM [link]Defending Safari 4 tabs
The first reaction most people had to Safari 4 — especially the new tabs interface — was negative. I'm here to defend it.
But first, let's get the mistakes out of the way, because they are substantial. Safari 4 tabs have several new usability problems:
Clicks to close or drag in inactive tabs should not be allowed. As Daniel Jalkut pointed out on Twitter, these "landmines" decrease the available space to click when dragging a window. And the problem only gets worse as you add more tabs. It requires too much thinking before being able to drag a window. (You can bet Apple has research that shows most people only have 1 or 2 tabs open at a time, but nevertheless you are going to sometimes have a bunch.)
Click-through should not be enabled. Same point as above, but don't allow closing tabs or clicking the drag handle when Safari is not the frontmost app. John Gruber has written extensively on this issue, and this post from 2003 is a good place to start.
Title bar font is different than every other app. I understand this decision, but it's unnecessary for small numbers of tabs. If you have 1 or 2 or even 3 tabs open, there's no reason not to use the full font size so that Safari's title bar is consistent with other apps. It's distracting.
Too subtle. Because nothing in the content area of the window changes, it's easy to miss the tabs. They are in a more prominent place but somehow fade into the background. I'm not sure whether this is a good or bad thing yet, but I'm leaning toward bad.
There are other largely esthetic complaints about the new tabs, such as how the default wider tabs look odd compared to previous versions of Safari, but a lot of that is just unfamiliarity and doesn't point to a specific usability problem.
So why do I like what Apple is doing here? Because I'm hopeful that this is the first experiment to bringing system-provided tabs to applications.
Here's what I wrote about this issue in 2005:
"Instead, Apple should have built upon Exposé to offer system-wide window grouping state, so that in any document-based application the user is in control of how windows are tabbed. Actions like dragging to rearrange tabs could be implemented once and work consistently across all applications."
In the last 4 years the problem has only gotten worse. Developers are rolling their own tab solutions and there is no consistent behavior or keyboard shortcuts that I have seen. Worse, coding fully-featured tabs with the ability to drag windows in and out of a tab group is very difficult, and most apps don't go that far.
The Safari 4 tabs are conceptually the right way to go. It's not "tabs" at all. Instead, think of it as an efficient way to dock multiple windows together.
Getting the tabs out of the content area of the window is also the first real step to making this available to other developers. While I don't think you should stamp this on to all applications, certain classes of document-based applications could "opt-in" to this new system and get it mostly for free, with consistent UI and behavior provided by the system. Developers who had special requirements or wanted a custom tab look-and-feel could continue to build their own tabs without worry that their UI would be interfered with.
I have no idea if this is the direction Apple is going in, but the Safari 4 design makes me think that at least someone at Apple has this in the back of their head.
February 25, 2009 10:27 AM [link]Coraline
While not a major blockbuster, Coraline seems to be quietly doing pretty well. It has recouped about half of its production costs, and according to Box Office Mojo actually added a few theaters in its second week of release.
One of the artist blogs I follow is by Matt Williames. I didn't realize until he posted about it that he worked on facial expressions for the film:
"A couple years ago I got a call from this new studio called 'Laika'. They were doing a new Henry Selick film called Coraline and needed someone to design and animate the facial expressions (including design mouth shapes for dialogue) for all the characters in the film. And they wanted it ALL to be 2D upfront (it would later be modeling in the computer then molds would be made from that). It was a sweet gig-- I lived in Portland for 6 weeks, all expenses paid and was scared to death every day of failing miserably."
Cartoon Brew also links to a collection of YouTube clips from an artists panel about Coraline. It's a shame the "art of" book seems so incomplete.
I thoroughly enjoyed the movie. A packed theater and applause when the credits rolled only added to my impression that this movie is something special that is being carried by word of mouth.
February 16, 2009 09:44 AM [link]Better software, less support
A few months ago Ars carried a story about Apple canceling a call center in Colorado. This part stuck out to me:
"Somewhat surprisingly, the iPhone 2.1 update was also named as one of the reasons for the cancellation. The software update has apparently been so successful at resolving iPhone 3G problems that its release has caused a noticeable drop in support calls."
In this case it was just bug fixes, but it reminded me of Getting Real. Make software easy to use and simple and then there are fewer things that can break and users are less confused. I have been obsessed with following this advice lately. Some of the limitations I've put in a couple recent projects:
- No preferences (for Mac, no prefs window; for web, no options or settings screen).
- Single toolbar (no status bar or need to look in multiple places, e.g. both the top and bottom of the window).
- Minimal toolbar buttons (only the absolute basics are exposed outside of menus).
- Opinionated defaults (no customization, similar to others above).
On a few occasions this has hurt my ability to add features, but on others it forces me to see a user interface problem from a new angle, something I wouldn't have done if I hadn't had these limits to work in.
Limiting features in an app does not come naturally to me, but the more I embrace it, the more value I see in it. I tweeted a bonus side effect to this approach last week: "Maybe another reason why simple software succeeds: customers see in it all the possible features to come, implemented just right for them."
February 7, 2009 07:26 AM [link]
