About 20 people met at the Frog Design building downtown a few months ago for the first Austin Ruby on Rails user group meeting, and by the third meeting that number had doubled. Founders Damon, Robert Rasmussen, and Rob Jones have done a great job getting the group off the ground and lining up interesting topics.
Last night was our fourth meeting. Bruce Tate gave a talk on his experience ramping up a Rails team and comparisons to the Java world. As a new experiment on the agenda, afterwards some of us stuck around to hack together a member directory for the web site. I didn’t actively participate in the coding efforts, but I had a good time meeting new people. As usual, it was all followed by drinks at Hickory Street Bar & Grill, where topics of discussion ranged from refactoring to Perl to C++ windowing toolkits to AppleGuide. You know there’s some real substance to Rails when it brings together such a diverse group.
Also just announced: the Rails Happy Hour at SXSW. Should be fun.
Bruce Tate answers questions after his presentation
Everyone complains about software bloat. And it’s easy to see why — applications are bigger and slower than they’ve ever been, and users think the dozen features they will never use are to blame.
On the Mac we are lucky to have a large number of great, small, focused tools that solve a few problems well. The best of these become successful, but what then? You have to keep adding features. How do you control the software so that it becomes even more useful without feeling too packed?
One way is to differenciate between visible and hidden bloat. For example, Microsoft products used to have a tendency to take every major bullet point on the side of the box and make a toolbar icon for it. Even if the user only uses 5% of those features, they have easy access to far too many of them, and they needlessly have access to them all at once.
Instead, adding features in context allows the application to grow without feeling too busy, and without distracting the user from the core set of features they are familiar with. The new user interface is discovered by using a new feature, and otherwise remains out of sight.
This point was really emphasized for me while using Keynote 3 the other day. I love the contextual floating slider when editing a shape (see image). They could have put this slider in the inspector window, but it is so infrequently used it would have remained disabled most of the time, and cluttered those panes with little benefit.
I’ve been living in Campfire quite a bit over the last few days. It’s a great app, well designed and very fast. But it suffers from a problem that iChat and other AIM clients do not have: it’s easy to forget about a chat room while working on something else because there’s no audio or visual notification that you missed a message.
I whipped up a tiny AppleScript that monitors the chat and beeps if there have been any changes. It’s simple but it works fine for me, and should make do until someone writes a full WebKit-based Campfire client app with more options, or until 37signals releases a supported public web services API.
Requirements and how it works:
- Requires Safari. Does not work with Firefox or Camino.
- Campfire must be in its own web browser window, or the front tab in any window.
- Every 2 seconds, it grabs the HTML from the <div> that Campfire uses for the chat messages. If it has changed since the last time, it beeps.
- Only beeps if Safari is not the frontmost application.
- If you are in multiple chat rooms, only works if they are in their own window and visible on screen.
Download: Campfire_Beep.dmg (90K)
Just open the application in Script Editor to edit it. Or view the full source.
Comments? Email email@example.com. Enjoy!
Update: I updated the script so that it doesn’t display errors, more correctly identifies URLs, and supports multiple open Campfire chat windows.
This just in: 37signals added sound notification to Campfire today! So this little AppleScript is officially obsolete. I’d like to take credit for convincing them that such a feature was needed, but we all know how they love to build features that won’t roll-out until the 2nd week after launch. :-)