Appendix
Under the Hood
The program is 99 % based on Cocoa/Obj-C. The remaining 1 % contains some generic C code and Carbon bits for QuickTime archiving.
We use Distributed Object technique for the management of shared data updating.
Rendezvous is implemented in the serving/joining part of the code.
The programs are tested under OS X 10.3.2 using iBook G3, G4 Powerbook and a G4 iMac, all connected via Apple Airport. All machines have at least 512 Mb of memory or more.
Snapz Pro X from Ambrosia and MS Word were used in preparing pdf version of User Manual. Most graphics were prepared using Adobe Photoshop and iChalk.
Google and real books were used with equal frequency for research.
Serious consideration has gone into optimizing the way iStorm exchanges various types of data across network while maintaining the collaboration logistics intuitive and pleasant. (harsher critics may say bearable..) One of the early challenges were to minimize the amount of images sent over network. A cache-like technique was employed (v.1.1 and later) to remove any redundancies. Another challenge posed as iChalk went full color was to optimize the data communication for changes made on the chalkboard (v.2.0 and later). In a nutshell, iChalk monitors the size of minimal number of changes required to restore the screen on the other ends (differential update). This tends to grow in size as a user takes time to make changes here and there, keeping collaborators in suspense. Then the rate reaches a plateau as the same pixels get drawn over. At some point, it becomes viable to use a compressed Tiff image of the whole board instead, thereby throwing away the redundant historical load up to that point. Behind the screen, iChalk/iStorm is very busy monitoring and judging all these, occasionally doing its own dishwashing.
FAQ
What is the best strategy to resolve a network-congestion related crisis during a collaboration?
Please check at the end of the chapter on Hosting for an answer.
Could the chalkboard communication become faster? I have seen some shared drawing program exchange data faster.
Generally, vector graphics are much smaller in size and allow rapid data transmission. iChalk strokes are based on manipulation of four components bitmap and thereby give far richer shared graphic experience. While it is possible that we will add vector and text layers in near future, we have almost fully exhausted various ways to optimize data transport of such complexity. Hopefully, we will all be surfing over fiber optic cables in near future ;-)
Why not allow "simultaneous" editing?
With robust network, simple text may be edited simultaneously by several people. However, we could not come up with a compelling argument for it over the current blue-green-red button method. Maybe for a musical jam, it would make a strong case. But not for text based collaboration, in our opinion. Rich text with graphics make it even less sensible as the group will experience characters as well as images popping in and out unpredictably. Boy, we are not into '60s style experimentations here.
Is there a plan for Windows version of iStorm?
No. It is beyond our capability resourcewise. We also feel slightly religious about this issue.
There are some user interface elements which deviate from Apple Guideline. Are they intended?
Most of them are not intended and we are constantly busy improving them.
So far, most of the vocal comments were made on the toolbar and the big one-button interface. Our toolbar was designed to minimize their presence. Many programs use toolbars populated with eye-candy buttons, which by themselves are pleasure to behold. They fit well in a program which consumes digital content rather than creates one. An example would be iTunes. iStorm is designed for more sustained concentration over a document. We thought it better to have them disappear from user's perception once the collaboration gets full steam.
The same principle guided our development of the scheme with the central button. The button serves at least five or six functions without cluttering users' mind and visual field. For the first-time-users of iStorm, the austere one-button-does-it-all interface may look too Spartan and cryptic, but as soon as one grasps what is going on, the majority of the people find the interface intuitive and catch on almost instantly. Its size and prominence in a relatively empty region of the document has been much commented on. Our reservation against using more informative but cluttered text messages or smaller sizes is that it adds another load of mental activity which bears down on users subconsciousness. Any second-time user will have no trouble remembering what the colors on the button mean. If still in doubt, try your arguments against traffic lights.
In iChalk, some buttons have rather unusual functionality and behavior. If you do not find it funny at all, please consider switching to Windows: We would rather serve users who appreciate and respect the playful spirit than a huge, gray people who expect nothing but the expected. We hope many OS X users will understand and bear with quirky character of iStorm.
The buttons in the iChalk packs several different modes accessible by repeatedly clicking on them or on the board. Why not use more specific buttons? Our decision on this issue was made following the observation on how we use our remote-control for selecting channels on TV or CD tracks. Despite the ten numeric buttons and what not, we seem to enjoy wearing down the + and - buttons. Pressing a button twelve times may tire our thumb, but it requires much less mental activity than having to first decide on the number 12 and to find the right keys in right sequence, and finally landing safely on the tiny Enter button. Of course, the story is different if you have 100+ channels to surf. (We have only 13 to worry about.) That is probably why the venerable folks at Microsoft and Adobe are comfortable with the ever-proliferating buttons. Sometimes, we even find buttons to suppress other buttons from appearing. It leads us to speculate that Bill Joy's recent polemic on the gray-goo problem was nothing but sublimated anxiety over the exploding number of buttons in commercial software.
Do you plan to extend Baby TeX to allow a shared full-blown TeX environment?
Doug Rowland's Equation Service is a promising program for more versatile use of TeX. TeXShop with teTeX will satisfy most serious TeX needs on OS X, although we sometimes miss the pricey Textures from Blue Sky Research which used to have a nifty live-mode, but not available on OS X natively as of Feb, 2004. With iStorm 3.3, if you choose the Full TeX Document option in the Baby TeX options drawer, you can process a full LaTeX document, if you select the complete source text in the main document window. Combined with syncPDF, it will provide an effective way to collaborate on a paper with your colleagues.
