Occasionally I am asked to explain the difference between groups and folders in Together. I might be able to boil this down for the FAQ, but here is a full explanation.

Together has two ways of collecting files together, groups and folders. In a nutshell, folders work the same as in the Finder, while groups work like iTunes playlists.

Groups were introduced in version 1.0 to support the point of Together, in that you do not need to file items into folders because they always appear in your library. Folders were added to version 2.0 because sometimes the folder structure is important to the files being stored and because some people were accustomed to that way of working.

Folders

Folders in Together work exactly like folders in the Finder, and that’s exactly what they are. A file can only exist in one folder at a time, adding a file to that folder moves it there and removing a file from a folder moves it to Together’s Trash and removes it from Together’s library and any groups or smart groups. Removing the folder moves the folder and its entire contents to the Trash.

Groups

Groups work like iTunes playlists and are very different to folders. Groups cannot be arranged hierarchically. A file can appear in more than one group at a time. Adding a file to a group adds a reference to that file, and removing a file from a group or removing the group itself doesn’t change anything else. Groups will always keep track of files, no matter where they are stored.

Using Groups and Folders

How you want to use these is up to you. Folders, as mentioned, are good when you want or need to organize files hierarchically, while groups allow you to create loose collections and removes the limitation of only being able to see a file in a single place. You can’t mix groups and folders in a hierarchy because they’re pretty incompatible in terms of what is stored where.

Groups are ideal for research, where you can collect a number of documents from different locations into once place, without moving the files from their original locations. Once you’re finished with the group, you can just remove it without removing any of the files it contains.

Any developer will tell you that no application can remain simple for very long. This is good as further development of the application through ideas and requests means that the application can grow with a receptive audience. The difficult part is determining how.

Some applications suffer this problem more than others. The most dangerous aspect of this for a developer is to introduce something that becomes a problem, and in the worst case, a millstone around their neck. It’s not easy to remove features, even if they are problematic. Likewise, insufficiently implemented features will generate more work in support requests than they took to add in the first place. The key to keeping this manageable is to work within the scope of the application.

My two applications are oceans apart in this respect. Both have grown in ways I could never have imagined, but none more than Feeder. It started as a fairly straightforward RSS reader, but then became involved in the anything-but-simple world of podcasting. Now it’s an RSS editor, an audio / video file tagger and FTP client all wrapped up in one package.

And yet, on the surface, Feeder hasn’t changed much at all. Someone who bought the 1.0 version for creating a standard RSS feed won’t feel like the app has become something different or unsuitable. The features have integrated seamlessly because they are right for the application. There are many requested features that didn’t make the cut, and I’m satisfied that those decisions proved correct over time.

Together’s potential scope is much broader than Feeder’s to the point that I am still implementing features I thought of four years ago. On seeing the app, people have many ideas about what it should do or be. In the two months since Together’s 2.0 release I have done little more than answer emails and during that time have collected over 100 valid feature requests, filtered through what I see as the scope of the application.

Together’s scope is no different to version 1.0 and that is to store, organize, preview and search files as elegantly and efficiently as possible. In time, the scope might expand without detracting from the fundamental nature of the application, but for now, with strong demand for features that will likely take years to fully realise, there is far too much to be done. Of course, these features cannot be added all at once. People expect regular updates, so each release will prioritise the most needed requests.

Interest in Together has been so great as to be overwhelming. Even with all the work put into the 2.0 version, the potential for the application is huge and some people will be happier with its progress than others. Thankfully, there are lots of options out there, so there should be something for everyone. Obviously, I can’t keep sprinting on the support treadmill, so I’ve set up the forums and placed much more emphasis on the FAQs to try and bring the situation back under control.

As I mentioned when I announced the application, version 2.0 sets the platform from which the app will grow over the next few years. Some things are going to take time, but the future for Together looks very promising, not least thanks to everyone who has supported and contributed to Together and KIT so far. The 2.x series is shaping up to be very exciting indeed.

This is a slightly more obscure tip, but since I’ve been asked it a couple of times I thought it was worth posting.

If you work with source code, you may have seen the Quick Look plugin, QLColorCode. Together provides rudimentary editing of source code files, but with no syntax coloring. This means you will see Together’s built-in editor rather than a Quick Look preview when viewing source code files.

There is a way around this though, and that’s to disable Together’s source code editor. Right now you can’t do this in the app, you have to set a hidden preference in Terminal. First, quit Together, then enter the following line in Terminal:

defaults write com.reinvented.Together TRExcludedPlugIns -array-add com.reinvented.TRSourceCodePlugIn

The next time you launch Together, you should see source code files as Quick Look previews from the QLColorCode plugin.

To enable the Source Code plugin again, quit Together and use this command in Terminal:

defaults delete com.reinvented.Together TRExcludedPlugIns

Happy New Year! 2007 was a great year for Reinvented Software, but in trying to sum it up, I’ve decided that it was a bit like a sandwich. You can see the top and bottom, while the meat is mostly hidden in the middle. The highlights:

• January: Released Feeder 1.4.
• February: Released KIT 1.3.
• March: Started Together 2.0 in earnest, while Feeder and KIT were getting great reviews.
• April: Announced the Übercaster+Feeder Bundle with Pleasant Software.
• May: KIT on MacUpdate Promo.
• June: Attended WWDC 2007 (photos).
• July – October: Continued on Together, reworking things to use the new Leopard UI. Also worked on Leopard compatibility for Feeder and KIT.
• November: Released Together 2.0.
• December: Give Good Food to Your Mac and MacSanta Promotions.

The year ended insanely busy for me as Together’s launch was more successful than I’d anticipated, but that’s no bad thing. Thankfully though, things quietened down over the holidays, so I could take some time out, work on Together 2.0.4 (released earlier today) and, since I got so many requests for this, set up a support forum, which I’m launching today. There hadn’t been any call for this until Together 2.0, so I’m hoping it’ll be useful.

There are three sections: the “Frequently Asked Questions” section has links to the existing FAQs, “Support” is for support questions or reporting problems, and “Feedback” covers things like feature requests and other general discussion concerning the two applications.

Support is still available via email on the Support pages along with the form to automatically send out lost codes, and of course I will continue to write about the apps on this blog.

Thanks to everyone who helped make 2007 such a great year for me. The year ahead also looks to be a busy one too and who knows what’s around the corner with Macworld Expo in a couple of weeks’ time.

There are some very insightful comments on the last post, as expected from Daring Fireball readers. Thankfully, nobody took anything personally, because it was about whether super-cheap bundles are an efficient way of gaining customers, rather than any reflection on MacZOT (or any other bundle / discount) buyers or a particular site.

One theme running through the comments that did make me wonder ran along the lines of “the lack of updates caused me to look elsewhere”. There is the irony there that the extra support work not only delayed the 1.3 release, but put a squeeze on everything else I did.

The striking thing about this complaint though, is that it’s something I’ve also heard quite a lot in support emails regarding a number of Together’s competitors. I admit that I don’t keep tabs on them, because I don’t see the point, but as far as I can tell most of these apps get updated every 3 – 6 months, with bug fix / tweaks released every month or so, just like KIT.

For example, Soukyan writes:

What bothered me was that development seemed to slow to a halt for quite some time. I realize that you were preparing the 2.0 release, but this is the problem with small developers. My license entitles me to 1.x upgrades for free, but the paradigm in software has become, release, upgrades to release.5 at the most, and then do a new release and charge for the upgrade. Whatever the reasoning behind it, I don’t mind, but I do mind when the developer seems to drop off the face of the earth. The tells me that I cannot rely on the software to be maintained for the long term.

It’s when indie developers are quiet that they’re probably working the hardest. I spent almost the entire year working on KIT/Together. Version 1.3 was released within 6 months of the bundle and 2.0 another 9 months later, soon after Leopard was released. That was a longer gap than I’d normally like to have but in the meantime, KIT was updated every month or so all the way up until October, when it was made Leopard-compatible.

Obviously Leopard’s delay, and lack of development in the meantime, impacted everything quite significantly. I started Together when Leopard was supposed to be released in late June (and some rumour sites were adamant it would be April). I opened a lot of bugs about Leopard with Apple, a number of which still haven’t been closed and had to do a lot of work twice, to work around problems.

Indie Mac apps in general have frequent free updates that add features as well as fix bugs (often within days of them being reported), and this is what sets independent developers, whether individuals or small teams, apart from the likes of big companies such as Microsoft or Adobe, who release something huge every two years and nothing in between. Even Apple only manages, at best, annual updates to their applications, with the free, minor updates offering fixes but little in the way of new functionality (one exception being iTunes, but generally this is to support new iPods/iPhone or iTunes Store initiative).

Software development takes a long time and it’s most efficient to bundle changes together. One feature may appear as a bullet point, but take many weeks to design, develop and test. Most new features will impact something else, so the repercussions of even a handful of new features can be mind-boggling. Even a release that takes 2 or 3 months can easily devour another month in support, and for all sorts of reasons.

It’s a real balancing act for developers to come up with a release that has enough in it to satisfy people’s requests, works well, and provides enough features to get the attention of new buyers in a reasonable timeframe. I generally manage to release 2 to 3 such updates a year, alternating between both of my apps, and punctuated by the more regular bug fix releases.

Because indie Mac software is pretty low-priced anyway, and full version upgrades (e.g. 2.0, 3.0) often years apart, it’s important to keep that momentum going. There comes a point though where an upgrade like that won’t cut it and you need to make some pretty large changes, and that’s when it’s time for a major new version.

I guess that in Together’s market, where there is a range of diverse competitors people seem to bounce between, and where people may also use web apps that tend to trickle out smaller changes more frequently, people’s expectations can be very high.