I’ve been remiss in not writing this up sooner, but I remember it only when I’m in the car, listening to podcasts or music on our iPod nano. Since the most recent iPod update – iPod Updater 2006-06-28 – our iPod nano has suffered from frequent (at least one per car trip) 1- to 2-second bits of garbled playback. Another person reported this on TidBITS Talk as well, although it’s not clear if the problem is widespread. Since the iPod Updater 2006-06-28 contains iPod nano Software 1.2, with Nike+iPod support (and unspecified bug fixes), if you’re not using the Nike+iPod Sport Kit (see “Grab Your iPod and Run” for details), I’d encourage you to hold off on this particular iPod update. Apple knows about the problem and is undoubtedly working on a fix.

If the problem bothers you sufficiently, you can restore to the previous iPod nano Software 1.1.1. Look in your /Applications/Utilities folder for an iPod Software Updater folder, which contains older iPod updaters. I launched iPod Updater 2006-03-23, the second-most-recent one, clicked the Restore button (remember that this will erase everything on the iPod, so do a restore only if you’re loading everything from the Mac anyway), and let it restore. Before copying music and podcasts back to the iPod nano, iTunes tried to get me to install the bad update again; I demurred, and all was fine. I later let the bad update install again for testing purposes, and the problem returned, so I repeated the entire process to revert back to iPod nano Software 1.1.1. I’ll revisit this issue once I’m ready to test the just-arrived Nike+iPod Sport Kit.

Different people learn software best in different ways. Some like playing with a program on their own, others prefer reading something like one of our Take Control ebooks, and many people like attending classes. But there’s yet another form of training that’s becoming increasingly popular – video training via the Internet. Perhaps the best-known company in this field – at least of those that provide topics of interest to Mac users – is lynda.com, founded by Lynda Weinman in 1995. lynda.com has approximately 250 training programs, many of which cover Macintosh software and were created by the same authors who have written best-selling books and ebooks. So if you’re interested in online video training, check out the list of topics in lynda.com’s Online Training Library; all the titles have free samples, and you can see if any of them would prove useful in your work.

In this week’s DealBITS drawing, you can enter to win a one-year premium subscription to lynda.com’s Online Training Library, worth $375. Entrants who aren’t among our lucky winners will receive a serious discount on an Online Training Library subscription, so be sure to enter at the DealBITS page linked below. All information gathered is covered by our comprehensive privacy policy. Be careful with your spam filters, since you must be able to receive email from my address to learn if you’ve won. Remember too, that if someone you refer to this drawing wins, you’ll receive the same prize as a reward for spreading the word.

The announcement last week from Microsoft’s Macintosh Business Unit (MacBU) that Virtual PC for Mac will be discontinued, and that future versions of Microsoft Office for Mac will lack support for Visual Basic macros, has sparked one of those rumor wildfires over which, as usual, cooler heads must prevail.

Virtual PC was always a desperate half-measure at best, sufficient (say) to test a cross-platform application built with REALbasic slowly, but not for serious Windows-based work. Personally, I won’t miss it, and I look forward to acquiring an Intel-based Mac and running Parallels Desktop so I can try Dragon Naturally Speaking at last.

As for Visual Basic, the news seems to me almost entirely good. Visual Basic support in the Mac version of Office was always a crusty hack (just how crusty is made clear by Erik Schwiebert in his blog and by Rick Schaut in his), and was never on a par with the Windows version anyway; its removal will be, if anything, liberating.

The real take-home message here is that Mac Office has at last been completely migrated into Xcode. This means that a universal binary build of the Office applications is now more than a theoretical possibility. In effect, the MacBU has managed to squeeze a camel through the eye of a needle; the fact that in the process one of its humps fell off (Visual Basic support) doesn’t detract from the achievement. Plus, remember, a Microsoft Office that can’t run Visual Basic will close one of the largest security holes on most people’s Macs today, namely the danger of receiving a Word document infected with a macro virus. Finally, you’ll still be able to automate Office through AppleScript, support for which became downright excellent in Office 2004, and which will surely be even better with the underlying Visual Basic scaffolding removed and no longer dictating how an AppleScript command is formed.

And what if you need Visual Basic compatibility in order to cooperate with Windows users? I guess you’ll just keep on using Office 2004 (under Rosetta, if you’ve migrated to Intel); that will be a pity if it means missing out on subsequent Office improvements, but to call it a hardship would be a bit strong.

The real unanswered question, it seems to me, is how Excel users will write custom functions (as opposed to macros). AppleScript’s math would not be up to this, even if Excel could somehow call back into it, so the MacBU must either ignore the problem and cripple Excel or come up with a completely innovative solution. Time will tell.

Apple’s Worldwide Developer Conference (WWDC) wrapped up this year with the annual Apple Design Award winners, who received not only fame and Mac developer cred, but a special cube award that lights up when touched. (How is this illuminated miracle accomplished? The winners of the 2004 award for best student project didn’t merely take theirs apart like any normal person; they peeked inside using a CT scanner and built 3D reconstructed models, of course!)

Congratulations to this year’s winners, and we encourage you to visit their Web sites to get a sense of why they were chosen.

<

ul>

• Best Mac OS X Developer Tool: Winner: TextMate 1.5. Runner-up: F-Script 1.3.
• Best Use of Mac OS X Graphics: Winner: modo 201. Runner-up: Unity 1.5.
• Best Mac OS X Dashboard Widget: iClip lite 2.0. Runner-up: WeatherBug Local Weather Widget.
• Best Mac OS X Automator Workflow: Winner: Build Real Estate Catalog/Ultimate Productivity Action Pack. Runner-up: Lecture Recording Workflow 1.2.
• Best Mac OS X User Experience: Winner: iSale 3.1. Runner-up: Boinx FotoMagico 1.7.
• Best Mac OS X Game: Winner: The Sims 2. Runner-up: Wingnuts 2: Raina’s Revenge.
• Best Mac OS X Scientific Computing Solution: Winner: EnzymeX 3.1. Runner-up: FuzzMeasure Pro 2.0.
• Best Mac OS X Student Product: Winner: Lineform 1.1. Runner-up: PhotoPresenter 2.5.

Thanks for all your mail and comments about my “Calling Mac Developers: Request for a Collaborative Editor” article in the 24-Jul-06 issue of TidBITS. What with the comments on my article and Jason Snell’s post on Macworld.com, we’ve been having discussions both with users who desperately want the collaborative editor we’re proposing and with some developers who are potentially interested in writing it. That doesn’t mean we don’t want to hear from more developers; the more the merrier, and if someone were to start an open source project, I’m sure the extra coders would be welcome. However, we want to clear up a couple of common misconceptions that have arisen.

SubEthaEdit and Real-Time Tools — First, lots of people have asked if we’ve considered SubEthaEdit, from The Coding Monkeys. Yes and no – we know all about SubEthaEdit and use it occasionally, but it’s not at all suited for the kind of group collaboration we have in mind here for two main reasons:

• It’s only real-time, which demos incredibly well and is very useful in specific situations like group note taking and the occasional group writing situation. However, most writing and editing is done asynchronously and sequentially, where each person works on his or her own schedule and passes the file along when done.
• It loses track of who made what changes as soon as the document is closed – there’s no persistence, and no versioning capabilities. Saving is also somewhat confusing; since the person who shares the document should be saving, but if anything interrupts the connection, all the people connected to that document end up with a local-only version that they don’t know if they should save.

As I said, we do use SubEthaEdit whenever we’re working on an article as a group. For instance, for our coverage last week of the announcements from WWDC, we fired up SubEthaEdit and all wrote (or at least edited – several people find the presence of other activity in the same document highly distracting) into a shared document, divvying up specific bits of coverage. And this week, we wrote our Leopard Wish List article in SubEthaEdit as well, since it too had small contributions from a number of people.

We’re testing a workaround for the saving issue by having the person who creates the document use an auto-save utility; currently we’re trying GoldfishSoft’s $20 shareware SaveMe, and it would seem to fit the bill (although it’s hard to say how it would work over time, given that the demo times out after 30 saves). It’s also worth noting that the current version of SubEthaEdit itself is no longer free, but the notable changes between the free versions and the current SubEthaEdit 2.5 revolve around its capabilities as a text editor, not as a collaboration tool. Luckily, it turns out that you can still download older versions of SubEthaEdit for free.

A few people pointed us toward NoteShare from AquaMinds, but it too is a real-time tool, though with the added fillip that only one person can edit a particular shared notebook at a time. That eliminates the need for tracking multiple sets of changes simultaneously, but it also means that a collaborative editing team would have to store only a single document per notebook to avoid having one person lock everyone else out from all other documents in that notebook. NoteShare is definitely a 1.0 product, though it may evolve in useful ways given comments made by AquaMinds about future versions possibly allowing multiple simultaneous editors of a single notebook and providing versioning capabilities.

Text Creation, Not Publishing — Second, a number of people aren’t quite realizing where in the publishing process our proposed GroupEdit exists. In a professional publishing environment, text is written by an author, is edited and commented upon by one or more editors, goes back to the author, returns to a primary editor, goes to a copy editor/proofreader, and only at the very end of the process is sent to print publishing software and/or a Web content management system.

In most Internet publishing scenarios – particularly weblog and wiki approaches – collaboration happens at the very end of this process. Weblog entries only generate comments and links once they’re posted, and wiki entries are available for modification only after they’ve been published for the first time. That’s because weblogs evolved from the personal publishing paradigm, and although wikis have long been group-oriented, an entry in a public wiki like Wikipedia is available for public collaboration from the very moment it is created, not once it has been “published” officially.

So what we’re looking for in GroupEdit is a tool that supports the pre-publishing process, long before the public ever sees the end result. We don’t want a sausage, we want a sausage stuffer. And yes, the back-and-forth that results in a well-written, well-edited, thoroughly proofed publication is a case of sausage making – it isn’t always pretty, and it’s not something that most publications want exposed to readers. Although I haven’t been deeply involved in Wikipedia, my impression is that the manufacturing of a controversial Wikipedia entry reveals quite a bit of the sausage making, and while that may be fine for Wikipedia, it’s not something most publications want to do.

I say all this as a way of explaining the more basic reason why tools that enable Web publishing, like weblog utilities, wikis, and even programs like Macromedia Contribute, never quite provide what we’re looking for. All of them are tweaked to support that final aspect of the publishing process, rather than the early steps when a document is moving back and forth rapidly (and the more rapidly the better, though current tools hamper quick transitions tremendously) between an author and one or more editors.

The program that comes the closest to meeting our needs is probably Adobe InCopy, which integrates with InDesign to enable writers to work more fluidly with text that’s destined for InDesign layouts. Although InCopy would seem to have many of the basic features we want, it falls down in being focused primarily on integration with InDesign and on collaboration between writers and designers, not writers and editors. Plus, at $250 per copy, it’s not something we or Macworld could afford to provide to freelance writers.

Return to the RFP — Therefore I would once again encourage everyone to take a look at our RFP in QuickTopic Document Review, both with an eye toward making comments that could help refine or enhance the proposal and toward alerting Macintosh developers who might be interested in working on such a project or who might even have code that would benefit from features along the lines of those we outline in the RFP. The comments and discussions that the RFP has spawned so far have been helpful and are exactly what we hoped it would bring out. We’re looking forward to keeping the dialogue going and hopefully getting something along the lines of GroupEdit into development.

When he introduced Mac OS X 10.5 Leopard on stage during last week’s Worldwide Developer Conference keynote, Steve Jobs was clear about how there were more “top secret” features coming in Leopard. That got us thinking – given what Apple has done in previous versions of Mac OS X, and what they’ve announced for Leopard, what’s left? What improvements to Mac OS X remain for the picking? After some discussions among the staff, we came up with this list. (And if you’re interested in hearing more about what Jobs did talk about in Leopard, check out the last two MacNotables podcasts, one a panel discussion with Dan Frakes, Ted Landau, Bob LeVitus, and Andy Ihnatko, and the other a solo show with Adam.)

Faster Faster, Pussycat! Put bluntly, the overall Mac OS X user experience is still too slow. Throwing hardware at the problem helps to a certain extent, but working in the Finder and switching among multiple different applications involves far too many pauses. The spinning pizza of death is a sufficiently common occurrence that we find ourselves distractedly switching applications merely to keep working, although it’s nice that the colored wheel is less commonly an indicator that a restart will be required in the near future. We’d like to see significant attention paid in Leopard to performance in areas that will provide perceptual speed differences to every Mac user with sufficiently modern hardware. New features are great, and we understand the need to justify the selling price of a new version, but fine-tuning what’s already implemented not only provides a boost in everyday activities, it makes sense when looking ahead to future revisions.

Smarter Finder — Speaking of the Finder, rumor has it that Apple is working on it for Leopard, and we have some pet peeves we’d love to see addressed beyond performance. There are still times the Finder doesn’t notice new files appearing, which is confusing at best, and its warning when you’re copying multiple files over files with the same names really needs the chronological information available when copying a single file over an identically named item. Other complaints include the default button when changing the extension of a file’s name (if you’re changing the extension, in most cases you probably intend to change it, so that should be the default); the way the Finder selects the original file after you duplicate it, rather than the copy that you probably want to work on; the tendency of a folder to be scrolled out of sight when you rename it; and the way the Show Original contextual menu command doesn’t always (if ever) select an alias’s original file. Apple could do worse than to study Cocoatech’s Path Finder for hints on how to address these and other small usability problems with the Finder.

Smarter Authentication — How often are you prompted for your administrator password? Perhaps it’s not as often as we are, given the amount of software we install and test, but we’re willing to bet that you blithely type your password whenever prompted without the slightest thought about what will happen next. (That’s true of us most of the time too!) In Leopard, therefore, we’d like to see serious consideration given to how often authentication requests are made – with an eye to reducing the number to the point where users are more likely to pay attention to them, and to how the authentication requests are made – with thought given to making them more explicable. One possibility might be to create security levels, with a different type of authentication request for each level and with the necessary user action becoming more involved for higher security levels. So an installer that wants to install an application in the Applications folder would require relatively simple authentication, but if that installer also wanted to install a kernel extension, the action required to authenticate would be more complex (and would be required to inform the user more thoroughly about what it intends to do).

Service Management — We appreciate the utility of services, but frankly, the entire situation is a mess. Any application can register a service, cluttering the Services menu with an insane number of services, many of which hijack keyboard shortcuts or are impossible to figure out. We’d like to see Leopard provide a way for users to manage which services are available, control their keyboard shortcuts, and learn more about the functions that the services actually provide. This might entail developers adding metadata to their applications with service descriptions, but users should be able to add their own descriptions as well. Also, services should be made available through some other mechanism than the hierarchical Services menu within the Application menu, which is clumsy to access and which few users ever even notice; for example, imagine if you could specify a few services as favorites and access them from a full-fledged Services menu (which could be just an icon) in the menubar. (Peter Maurer’s shareware Service Scrubber is a good interim step, but this is the sort of operating system-level control that should be provided by Apple.)

Hotkey Manager — There are numerous ways in which a keyboard shortcut can be defined in Mac OS X: hard coded within applications; customized within applications; services; automation utilities like iKey, Keyboard Maestro, and QuicKeys; launchers like LaunchBar and DragThing; and Mac OS X’s own Keyboard & Mouse preference pane. With so many possibilities, it can be nearly impossible to figure out what a given keyboard shortcut will do, and sometimes keyboard shortcuts stop working for inexplicable reasons. Leopard should rationalize this situation as much as possible by having the Keyboard & Mouse preference pane become a central clearinghouse for all registered keyboard shortcuts.

Active Security Agent — Every so often, there’s a huge fuss in the Mac world about some piece of software sending data back to the mother ship, secretly installing an input manager, or generally doing things that it shouldn’t. As much as we approve of software like Objective Development’s Little Snitch, and firewalls like DoorStop from Open Door Networks, and IPNetSentryX from Sustainable Softworks, we’d like Leopard to include an active security agent that would build up a profile of standard patterns of use and warn the user when something seemed to be deviating from those patterns or behaving in ways that are known to be dubious. The Mac has long had a reputation for being highly secure, but it’s safe to say that the concentrated attention of less savory elements would undoubtedly reveal vulnerabilities, and a gram of prevention is worth a kilo of cure.

Seamless Network Usage — It’s a little hard to pin this wish down, but it seems that using network-based resources like file servers or printers is still too fussy. The spinning pizza of death is a commonplace sight when working with network resources that may be slow or unavailable, and while some of that is undoubtedly unavoidable, it would be great to see Leopard make network usage more seamless. Perhaps that means checking network connections in the background when they’re not being used to make sure they’re available when requested, or providing error messages without waiting 2 minutes when a server connection disappears. Or perhaps it means providing some sort of status display that the user could use to determine whether or not a network resource was really available without having to try a connection that won’t work. Improving Leopard’s behavior in this area will be left as an exercise to readers at Apple.

Better Multiple Monitor Awareness — Most of us here at TidBITS use two monitors when we’re not on the road, meaning we maximize our workspace by attaching two monitors to a desktop computer or by adding a second monitor to a laptop. If we want to use Apple’s Dock, though, we sometimes get frustrated, since logical positions for the Dock on a single monitor don’t always map well to sensible positions for two displays. We can use Marcel Bresink’s free TinkerTool to position the Dock at the top of the screen, but it would be nice to see Leopard enable the Dock to live on any edge of any display, if multiple displays were present. Another option that would make multiple monitor fans happy would be the capability to show the same menubar on both screens. That way, the menubar would always be above the current window, no matter which screen contained that window.

Menubar Icon Management — Most users have a lot of icons at the right side of the menubar. Of these, some are controlled by preference panes, and others by options in application preferences, plus there are some, like the Script menu icon, that seem to have no visible interface for adding and removing the icon from your menu. Some can be removed by Command-dragging the icon off the menubar; others can’t. (Those of us who never use Spotlight from the menubar wish it were in the former category.) All this is by way of suggesting that Leopard should standardize and centralize how menubar icons are added and removed; it’s fine to provide multiple approaches, but having one place to turn off all the unnecessary ones would be a boon.

Extensible Location Manager — Mac OS 9 had a built-in Location Manager that enabled users to switch a number of settings all at once when they moved their laptop from one location to another. In Mac OS X 10.4 Tiger, changing your location setting using the Location submenu of the Apple menu adjusts only your network settings. That’s a good start, but unlike Mac OS 9’s Location Manager, it doesn’t affect other preferences you may want to change depending on where you’re located, such as your default printer, SMTP server, time zone, sound level, and Energy Saver settings. A third-party product called Location X offers most of these options, but it’s inexcusable that Mac OS X’s built-in Location support is still so far behind where it was in Mac OS 9.

And while we’re wishing, let’s go one step further: why put the effort into choosing a location when the Mac can do it for you? As soon as you connect to your AirPort wireless network at home, for example, all of your location preferences could be enabled. Or perhaps your Mac OS X firewall settings could be beefed up when you connect to a T-Mobile or other public Wi-Fi network? (Location X also has this feature, called AutoLocate.) Computers are designed to automate silly tasks, right?

Widgets Outside Dashboard — Dashboard makes a lot of tasks easier, but its main problem is modality: you must switch into Dashboard, perform a task, and then switch back to your regular working environment. If you take a simple tool like the Calculator, it requires more steps (and more time) to copy and paste a result from Dashboard’s calculator than from the stand-alone version in your Applications folder. How is that an advantage? So it should be possible to use any widget on its own, without having to switch into the Dashboard “layer” of Mac OS X. It’d be a great step forward in usability. You can already accomplish this with the Amnesty Widget Browser, but it shouldn’t require an extra purchase to make widgets usable.

Startup Item Manager — The days of Apple’s Mac OS 9 Extension Manager are long gone, but the need for an extension or startup item manager is not. We have system-wide startup items, account-specific login items, input managers, kernel extensions, and goodness knows what else. As such, it’s near-impossible for any mere mortal to figure out exactly what non-Apple code is loading at any given time. To help users improve performance, troubleshoot problems, and enhance security, we’d like Leopard to offer a unified interface for managing all types of third-party code that can execute without the user explicitly launching it.

Smarter Hard Disk Usage — With Time Machine storing multiple snapshots of your data over time, the hard disks in today’s Macs are going to fill up fast. Mac OS X needs plenty of free space to generate swap files and other invisible cache files, so we’d like to see three smart improvements to how storage is handled.

The first is dynamic repartitioning, a feature that already exists but is not accessible to average users. Apple’s Boot Camp Assistant creates a new partition on your hard disk for Windows to use, without requiring you to reformat your hard disk or jeopardizing any of your existing data. If you decide to stop using Boot Camp, the utility can remove the partition and return your drive to its original state. Disk Utility should include an interface to do the same thing with Mac partitions, and that capability should include resizing partitions if the need arises. There are already some ways to pull this off with command-line hacking, and several third-party utilities offer dynamic repartitioning (although they’re slow and awkward to use). We’d like to see Leopard make the process faster and easier. Also, since dynamic repartitioning involves having all your data concentrated in one area of the disk so as to leave a large contiguous empty space in the remainder, we’d get a defragmentation facility as a bonus.

The second improvement is a better early-warning system for when your free disk space is almost gone. By the time Mac OS X pops up a warning dialog, bad things have already started to happen: performance slows down, and you can’t burn optical discs (because there isn’t enough space to create a disk image, a problem that Roxio’s Toast works around quite nicely). In worst-case situations, you could be able to run an application or system update installer but not be able to reboot the machine successfully when the installer is finished. We’d like to see Disk Utility or some other background process monitor the space-related health of the hard disk. And Apple could do worse than to build in a utility similar to the excellent Disk Inventory X, which reveals what’s eating your free space.

And lastly, we’d like a bit more control over the Trash. We’d like to see the Empty Trash item in the Finder menu become hierarchical so we could choose which volume’s trashed files are erased. For example, if you have a USB flash drive mounted on the Desktop, and you choose Empty Trash in Tiger, the trash on the startup volume is erased as well, which may be undesirable. Another idea would be a feature that lets you set parameters for automatically deleting files over time when the disk space was needed. It could start with, for instance, QuickTime files that have been in the Trash for more than 3 months. Presumably, Time Machine’s tracking of deleted files would enable you to go back and rescue a file that you inadvertently trashed long ago and was automatically deleted.

Sanctioned Plug-in Architecture for Mail and Safari — Developers have created numerous plug-ins and extensions for Mail and Safari that add valuable features or resolve interface deficiencies. The problem is, Apple doesn’t officially provide a plug-in architecture for either program. There are no documented APIs for plug-ins and no developer support, so developers trying to add features have to use trial and error – and risk causing crashes or other application misbehavior (see “Are Input Managers the Work of the Devil?”). Apple does offer a framework for adding Internet Plug-Ins (for adding new content types to Safari and other applications that use WebKit), but what’s needed is a full-blown extension API along the lines of that found in Firefox and Thunderbird.

Nicknames in Mail — Mail’s Previous Recipients list keeps track of everyone you ever send email to, not just those you plan to correspond with again. As a result, when you use the auto-completion feature to address a message, chances are good that you’ll get the wrong one accidentally. You can prune the list manually, but it’s a pain. We’d like to have the capability to turn off Previous Recipients altogether and instead manually specify short nicknames for frequently used contacts (as in Eudora).

Easy File-, Folder-, and Volume-Level Encryption — FileVault stinks. Even assuming that Apple has worked out all the bugs in the initial versions, the mere concept of encrypting the user’s entire home folder is flawed, since very few users care about encrypting their photos, movies, and music, which likely account for the bulk of the data in most home folders. Plus, because FileVault relies on a sparse disk image file behind the scenes, backup strategies must explicitly ignore that file and instead look only at the contents while the disk image is mounted (otherwise, receiving a single email message would cause the entire multi-gigabyte disk image file to require backup). There’s no need for such a blunt instrument, and Leopard could easily apply the technology behind FileVault to individual files or folders, enabling us to encrypt only the data that we actually need encrypted. With some adaptation, it could also enable the encryption of an entire disk, which would be ideal for USB flash drives, iPods, and other removable storage devices that might carry sensitive data.

1984 — PodBrix created a limited-run Lego set of Apple’s famous 1984 commercial… which is now sold out. 3 messages

TidBITS on Avantgo — In the switchover to the new TidBITS publishing system, mobile PDA issues weren’t initially included, but they’re working now. 8 messages

VOIP echo problemo — If you’re experiencing echoes in Voice-over-IP conversations (such as with Skype), here’s an explanation of what’s happening. 3 messages

Thoughts about numbered URLs in TidBITS — We changed some of our formatting last week, where links now include a number that helps reference the corresponding URL. Readers respond to the change. 9 messages

Apple has redefined sleep — The sleep indicator light operates differently on newer Macs. 3 messages

Car dictation > Word processing — A reader learns how to dictate text – while driving – for later flowing into a word processor. 2 messages