url posts

I've now spent a good deal of time hunting and searching through the updated SpringBoard executable. Much of what I found is dull; some is useful. While hunting around during the adding-Apps-to-SpringBoard effort, I discovered a number of items that appeared to be new Safari-style protocol handlers.

These items were each listed near a host application, for example itms near com.apple.MobileStore. Not surprisingly, opening an itms:// URL launches the iTunes mobile store. Here are the working protocols, both old and new

itms:// Launches Mobile iTMS store.

maps:// Launches Google Maps. (iPhone only)

feed://, feeds:// Launches dotMac reader

tel:// Dials a number, specified in the URL. (iPhone only)

mailto:// Launches the iPhone mail app. (iPhone only)

youtube:// Launches YouTube.

Other items that were listed but do not seem to work are: calshow://, callto://, vmshow://, prefs://, nowplaying://

It's been over a year since we first mentioned Pyro, the powerful Mac OS X client for 37signals' Campfire web-based chat service for groups and businesses. While I personally didn't pick up a copy back then since I wasn't a Campfire user, I'm not entirely familiar with every change that has come since April '06. Still, even the most recent list of changes warrants Pyro another mention, especially since I'm looking at using Campfire for a few uses and projects.

In addition to already offering a dashboard and central location for all your Campfire chats and displaying message status alerts in the Dock icon, check out what's new in Pyro 1.6:

• Any file type can be dragged onto Pyro to share in a Campfire chat
• Pyro will automatically zip a folder or .APP
• Dragging an image from a web browser will insert a URL for that image instead of uploading it
• Campfire's new sidebar search field now works in Pyro
• Support for the new WebKit installed by Safari 3 beta (mentioned on the Pyro development blog)
• and of course, bug fixes

As Campfire's example uses page details, there are a lot of great scenarios for such a slick web app, and Pyro looks like the perfect tool to bring together the coolness of Campfire with the power of Mac OS X. Surprisingly, Pyro is still offered free, and even though Campfire primarily focuses on business users by offering a few paid accounts, it too has a free account with which you can register and tinker around to see if Campfire is right for your use.

I know Adium can insert links from some browsers by itself, but I just found a script at the Adium Xtras site which offers much more fine-grained control over inserting a link from any browser, with the page name's descriptive title linked nice and clean, instead of the long ugly URL you get from copy/pasting. As you can see, specific commands are included for all the major browsers (and even some not-so-major ones), as well as a catch-all Default Browser command. The ones I can test seem to work pretty well, though I'll admit I don't have any copies of iCab or Netscape lying around. Enjoy.

Yojimbo, the information collection app from Bare Bones Software that helps you 'master the onslaught', has been updated to version 1.2. Among the additions and improves are a Quick Start movie for new users that launches on first startup, search term highlighting, browser bookmarklets for one-click bookmarking or web archiving in Yojimbo, AppleScript importing and much more.

A 30-day fully functioning demo is available, while Bare Bones offers full single user, family and educational licenses for $39, $69 and $29, respectively.

The iLife Updates Apple released yesterday fixed a gripe some users (including myself) had with the new URL scheme that iWeb employed. With its original release, an iWeb site's URL was http://web.mac.com/username/iWeb/. Leaving that last /iWeb/ off the URL would result in a 404 error. While this isn't a big deal to some, it's just one extra quirky name to add to a URL. To those unfamiliar with the internets however, .Mac and iWeb could mess up, resulting in that exponentially increasing frustration that usually leads to users simply giving up on the endeavor.

After installing the 1.0.1 update last night and making changes to some of my iWeb pages, I was pleased to see the URL in the "announce your site" confirmation window chopped down to simply http://web.mac.com/username. This not only makes the URL a little easier to remember and pass around, it also adds a bit more credibility to the URL, especially over the previous http://homepage.mac.com/username scheme.

Adding to the small pile of gripes with the new technology Apple is using with iLife 06, such as complaints about iWeb's bloated CSS or RSS standards and photocasting, I just developed a beef that I haven't really seen mentioned yet: the crummy new URL scheme for iWeb sites, both on and offline.

First of all, in the olden day the .Mac "homepage" did't seem to be case sensitive, as in: homepage.mac.com/user will get you to the same place as /User. iWeb is a bit pickier, as a wedding site I'm working on lives at web.mac.com/myuser/iWeb/Wedding/, but /wedding/ will result in a 404 error. Yes, a friend already reminded me that "Unix = case sensitive," but I don't care. While this could be labeled a minor complaint, my fiance and I have plenty of family members who aren't too hip on these computer thingies. They're going to get confused by something silly and minor like this, and I'm sure our relatives aren't the only ones.

Next on my list is the URL scheme itself. web.mac.com/user/iWeb/sitename? Could that get any less friendly? Granted "homepage.mac.com" might seems a little unprofessional to some, but this new scheme feels pretty cumbersome and just plain ugly. Why couldn't we simply have web.mac.com/user and web.mac.com/user/othersites, Apple?

Last but not least is how the new sites are organized in a user's iDisk. Old homepage sites still live in iDisk/Sites/, while shiny new iWeb sites live in iDisk/Web/Sites/iWeb/sitename. Nevermind a discussion about how needlessly buried that file structure is - I'm sure this dichotomy of old/new sites and content is going to confuse plenty of .Mac customers if they ever want to get at any of those files, or make a backup of their sites or entire iDisk.

But enough about my gripes, what do you guys think: do iWeb and its underpinning .Mac support have more issues besides CSS and standards? Let's hear your thoughts.

MacOSXHints has a slick tip on creating clickable iCal events that are either URLs or links to files. Sure, you can add a URL to an event's description, but with this simple method you can create an event itself that is click-able from iCal's main day/week/month calendar view.

All you need to do for a URL is either drag it (or its icon) from a browser's address bar onto a time slot in iCal, or add a URL to an event's title and surround it with carrots like this, sans-quotes: "." To create a click-able link to a file, you'll need to use a web browser (such as Firefox) to surf your file system, then simply drag a file or folder from the browser into iCal in the same way as a URL. Don't try it with Safari, as it apparently doesn't do local file/folder surfing.

This has already has become a darn handy tip for me, as I constantly add URLs to iCal events for upcoming local shows, and this takes one step out of the "so what is the site again?" process. The one thing I haven't tested yet is whether these would be click-able in iCal's pop-up reminder window. Anyone?