This weekend I added some ultra-cool features to Tinderbox 3, namely fast-update, only-build-if-there-is-something-new, and upload of builds to the server. Now the cycle time when there are no changes is less than a minute, so changes will be picked up as quickly as humanly possible.
tbox3 is now at the point where I consider it feature complete (enough to unleash it on the world at large). A few more features--very few--need to be added to make a drop-in replacement for the Mozilla Tinderbox, but that was not the main objective in writing this. I wanted a tbox various groups could use and apply patches to on multiple platforms. And I wanted a tinderbox client that was really easy to set up and hassle-free to administer (allow us to fix problems with as little intervention from the owner of the tinderbox client as security will permit).
Now I need to get server space and bandwidth, both for finished binary uploads and for the actual Tinderbox. I don't mind putting it on my server, but I am behind a cable modem and somebody might notice if people are downloading builds from my living room all day. I think getting people to donate machines for clients will be easy. The setup is brain-dead and you can always run the tinderbox off-and-on while you're not actually compiling. I find myself creating tinderbox clients as a way to keep my build up to date when I'm not there :)
Features of note in tbox3:
I would post the URL to the nice pretty tinderbox, but now that the clients are uploading builds to it, I need to keep it quiet to keep bandwidth problems from arising. You may And if you have bandwidth and a server for me (I have cron scripts that intelligently keep the binary builds under a quota), don't hesitate to drop me a line.
Posted by jkeiser at February 4, 2003 1:27 AMOther examples of these animations might be to show the status of an FTP transfer, the progress of media being digitized, or an updated time signature. And don't forget that users may want to have some control over this, so give them plenty of options, including the ability to turn these functions off.
Posted by: Maurice at January 25, 2004 6:06 PMBut limit your animations to whatever is required to communicate the necessary information. Avoid annoying animations that discourage ease of use. Ask yourself, "What do I need to show the user, and what is the cleanest way possible to achieve that?" A good example is the Mail application for Mac OS X. Whenever a new message arrives, the Dock icon changes appearance to indicate a changed state.
Posted by: Edmund at January 25, 2004 6:06 PMHelp! Did you include help tags in your applications? (I'd be lost without them.) Also, be sure to take extra time to develop your other help files. The Apple Help Viewer supports HTML, QuickTime, and also AppleScript. Take advantage of it! There isn't anything I hate more than going to the Help menu and finding there isn't any help.
Posted by: Judith at January 25, 2004 6:06 PMWhether native or not, this is obviously one of the first steps on your way to OS X. Keep in mind that often, the functionality of your code has a lot to do with how your interface is designed. How many developers have come up with great functional ideas from working with their interface or looking at their competitors'? Start working on your Aqua compliance from day one. Don't wait until the last minute.
Posted by: Emmett at January 25, 2004 6:07 PMFor example, if you see an AIM window peeking out from behind your browser and you click on it, that window will come to the front, but the main application window will not. The Mail.app/Activity Viewer is another example. The Aqua system of layers works well in many instances, but not in all. Thank goodness that the Dock is always there to come to the rescue. I know that clicking on an application icon in the Dock will always result in not only the application coming to the front, but also any non-minimized windows associated with it. And if the application is active but no windows are open, clicking on the Dock icon should create a new window in that application.
Posted by: Emmanuel at January 25, 2004 6:07 PMThe simple fact is that, when all other factors are equal, where will consumers spend their money? I believe that in the long run, the best looking, easiest-to-use applications will also be the most successful. I think that's why Apple encourages developers to write programs that are 100 percent Aqua-compliant.
Posted by: Edi at January 25, 2004 6:07 PMAdhere to Window Models. Document windows, Utility windows, Click-through, Layering, Drawers, Controls. How do users open windows, how do you properly title windows?
Posted by: Bartholomew at January 25, 2004 6:07 PMNot quite as entertaining as Shrek, but Dock animation can be an important and useful function in your application. For example, Dock animation is a helpful way to indicate the status of your application.
Posted by: Anchor at January 25, 2004 6:07 PMAdhere to File Locations. Make sure that when your users save documents, your application knows where to put them and also gives users flexibility.
Posted by: Phillip at January 25, 2004 6:07 PMTo help you become a good Aqua citizen, Apple has created a few guidelines. I've put together a brief overview of them, and we'll be tackling many of them in the months to come.
Posted by: Anne at January 25, 2004 6:07 PM