TidBITS#571/12-Mar-01 ===================== Adam writes more about document collaboration this week, with case studies and specific recommendations for your next collaboration task. Joe Clark also joins us again to discuss problems with Web accessibility for the disabled. In the news, we pass on a "upgrade" program for PowerBook 190s and 5300s, note the releases of the Handspring Visor Edge, Photoshop 6.0.1 and AirPort 1.3 (with PPPoE support!), look at Napster's reaction to the new injunction, and announce a new sponsor. Topics: MailBITS/12-Mar-01 Web Accessibility: Surfing the Web Blind Come Together: Document Collaboration, Part 2 Copyright 2001 TidBITS Electronic Publishing. All rights reserved. Information: Comments: --------------------------------------------------------------- This issue of TidBITS sponsored in part by: * READERS LIKE YOU! You can help support TidBITS via our voluntary <- NEW! contribution program. Special thanks this week to Nick Gough, Rick Cricow, and Carl Scott Zimmerman for their support! * APS Technologies -- 800/443-4199 -- How do you back up your APS hard disks? Try APS tape, removable, and CD-R drives! * WinStar Northwest Nexus. Visit us at . Internet business solutions throughout the Pacific Northwest. * Small Dog Electronics: PowerLogix 400 MHz G3 Upgrade: $165 <------- NEW! Epson Stylus Photo 1200 Printer USB and Serial refurb.: $269 Mac OS X with Mac OS 9.1 & free Ben & Jerry's ice cream: $119 Palm Vx: $365 -- 802/496-7171 * Aladdin Systems: New StuffIt Deluxe 6.0 Now Shipping!!! The Complete Compression Solution, now with ArchiveSearch, ReturnReceipt and more! Works with OS X Public Beta! Upgrades are just $29.95! * SkyLINE 11Mb WIRELESS PCI Card from Proxim (formerly Farallon). Affordable wireless solution for desktop Macintosh computers with PCI slots. Works with popular SkyLINE PC Card for Macs and PCs! * Blue World: Discover how Lasso products beat ASP and ColdFusion <-- NEW! in ease-of-use, performance, security and more when building & serving powerful data-driven sites. View comparison reports at: * Bare Bones Software BBEdit 6 -- It doesn't suck. New in 6: Support for multi-byte text, new Web standards like XHTML, WML, and CHTML, even better scripting support, and more. Buy or upgrade at our Web site: * NEW TRAINING RELEASE! PHOTOSHOP 6.0. A 10-volume series on video <- NEW! and CD-ROM. Learn how to use the world-standard image editing solution. Master the power of Photoshop quickly. Find out more: or call 800/527-1914 * ConceptDraw: If you need to draw a diagram or scheme, <------------ NEW! this is the program for you! 80 industry-specific libraries, 1,700 pre-drawn objects, powerful HTML export, OS X support. Get a FREE demo at: * Web Crossing: Does your site need more community interaction?! <--- NEW! Web Crossing is the the world's leading community development software that works across platforms and via email and the Web! TAKE OUR FREE NEEDS ASSESSMENT! --------------------------------------------------------------- MailBITS/12-Mar-01 ------------------ **Web Crossing Sponsoring TidBITS** -- We've seen focus on the Internet shift from search engines to portals that aggregate content, but many sites discovered not only that developing high- quality content is difficult, but also that the best way to attract and retain users is to encourage the growth of online communities. As those of us who have rolled our own solutions know, creating good technology to support an online community takes significant effort and resources. That's where our latest sponsor, Web Crossing, steps in, with their eponymous software for running Internet communities. I first met Tim Lundeen, Web Crossing's creator and a long-time TidBITS reader, back in 1995, and we've discussed aspects of Web Crossing and online communities over the years. During that time, Web Crossing has evolved into a powerful communications server that provides Web-based discussion forums with fully integrated mailing list support (along with POP or IMAP user accounts) and support for access via Usenet newsreaders, chat functionality, personal calendaring, SSL-based security, and more, all backed by a serious relational database. It's great to see such software running on the Mac OS (along with many other platforms), and we're especially pleased to have Web Crossing supporting the Macintosh community by sponsoring TidBITS. If you're cringing at the technical effort necessary to start or enhance an online community, check out Web Crossing's demo. [ACE] **Handspring Skirts the Edge with New Handheld** -- Handspring has announced what is sure to become the "must-have" accessory to Apple's PowerBook G4 Titanium: the Visor Edge, an anodized aluminum handheld that's just .44 inches thick. The Visor Edge runs Palm OS 3.5, comes with 8 MB of memory, sports the high- contrast grayscale screen found in current models, and includes a rechargeable lithium ion battery. Unlike other Visors, the Edge does not have a built-in Springboard expansion slot; to compensate, each Edge includes a snap-on Detachable Springboard Slot that can utilize any Springboard module. The Visor Edge costs $400 and should be shipping by the end of the month in metallic silver, red, and blue colors. [JLC] **Trade in Your PowerBook 190 or 5300** -- If you have a PowerBook 190 (the last 68040 model) or its PowerPC cousin, the PowerBook 5300, Apple has a little-publicized, limited-time offer to "upgrade" your laptop to a 400 MHz PowerBook G3 (FireWire) for just $1,600. The offer is available only until 23-Mar-01 and is for only one configuration of the PowerBook G3 (FireWire) while supplies last (the full specs are available on Apple's Web page). [MHA] **Photoshop 6.0.1 Update Released** -- Adobe has updated its flagship image editor, rolling bug fixes and tweaks into Photoshop 6. The new version features a handful of usability improvements to the painting tool brush picker and makes clipping paths in EPS and TIFF files readable to programs like QuarkXPress. It also corrects problems with low memory situations and includes other performance enhancements. The 09-Mar-01 release is the "official" updater; an earlier 6.0.1 update was apparently made available too soon and quickly pulled. Users who installed the "unofficial" update need to uninstall and reinstall Photoshop 6.0, then apply the new updater. The update is a 12.4 MB download. [JLC] **Napster Injunction Handed Down** -- Following up on last month's Ninth Circuit Court of Appeals decision, U.S. District Court Judge Marilyn Patel issued an injunction 06-Mar-01 ordering the Napster song-swapping service to remove all copyrighted materials within 72 hours of notification by the copyright owners. Napster has said it will comply with the order while continuing to negotiate for some sort of settlement with the record companies and prepare a membership-based service that would enable it to pay royalties to copyright holders. In the meantime, late on 10-Mar-01 the RIAA delivered a list of 135,000 items for Napster to prevent from being swapped on its service; Napster has until 15-Mar-01 to comply, and more lists are on the way from music publishers. It remains to be seen if Napster can successfully limit access to copyrighted material, since multiple song title formats could foil automated searches, and users could also intentionally modify file names (think Pig Latin or Leetspeak). [ACE] **AirPort 1.3 Adds PPPoE Support** -- Apple has released AirPort 1.3, a new version of the software for the AirPort Base Station and AirPort Card. (See "Going to the AirPort" in TidBITS-567_.) Foremost among the changes is support for PPPoE (PPP over Ethernet), an ugly yet common technology that enables ISPs to make always-on DSL connections act like session-based connections. A number of DSL providers, including Apple partner EarthLink, require PPPoE for DSL. PPPoE software for the Mac has generally received poor reviews, so adding it to the $300 AirPort Base Station so you don't have to run PPPoE software on a Mac makes the AirPort Base Station all the more attractive. Other changes in AirPort 1.3 include DHCP client ID support, enhancements to computer-to-computer mode, support for AppleScript, and access point density adjustments for sites with multiple base stations. Also, the AirPort Base Station and AirPort Card have received Wi-Fi certification, which ensures interoperability between 802.11 wireless Ethernet products from different manufacturers. The free update is a 7.4 MB download. [ACE] Web Accessibility: Surfing the Web Blind ---------------------------------------- by Joe Clark In two previous articles, I explained concepts related to accommodating Macintosh users with disabilities, some of the hardware and software (adaptive technology) available for that purpose, and how Apple has fallen asleep at the switch in recent years when it comes to accessibility. (See "Accessibility on the Mac" beginning in TidBITS-568_.) These days, of course, nearly every new Mac sold is connected to the Internet, as are scads of the old ones - even my coelacanth of a machine, a Power Macintosh 7100/66. But the Internet raises entirely new issues when it comes to accessibility, with a crucial new wrinkle: making the Web accessible requires not only important adaptive technology on the Mac owner's part, but also careful design and coding choices by Web authors. If you thought accessibility on the Mac was in bad shape, Web accessibility is worse. On the positive side, things are improving quickly. **Traditional Media** -- Let's think of old media for a second. Start with one of the oldest media, the printed book. If you can't read the type on the page due to a visual impairment, you have a few choices: * Wait for a large-print, Braille, or audio tape version to come out (months later, if it happens at all). * Use a magnifier to enlarge the print until it's big enough to read (usually on a big monitor not connected to a computer). * Use a reading machine that scans print and reads it aloud (a near-miraculous technology when Raymond Kurzweil invented it in 1976, now quite commonplace). Reading machines, formerly separate, free-standing equipment, are largely Windows-based now, though the L&H Kurzweil 3000 electronic text reader is available for Macs. In other words, to make a printed book accessible, you must use something other than the book itself. **On the Web** - By contrast, to make a Web site accessible, the site itself must be set up properly and, in most cases, you also must use adaptive technology. An important distinction comes up here between accessibility on the Web and on the Mac in general. Even in the age of Napster and QuickTime, the Web remains essentially a visual medium composed of text and images. Accordingly, the accessibility or inaccessibility of the Web mostly affects blind and visually-impaired people. Deaf or hard-of-hearing Web-surfers might find an occasional accessibility problem with multimedia, while people with learning disabilities like dyslexia may find reading all that colourful online text difficult, but the extent of these barriers pales in comparison to the simple issue of seeing and understanding the screen. The World Wide Web Consortium has a very readable site that gives some imaginary examples of people with various disabilities and the ways in which they use the Web. **It's All about Options** -- As you undoubtedly know, Web pages are written in a markup language called HTML (though an increasing number of Web pages consist of non-HTML technologies like Flash). The markup gives structure to a document. For example, text in a paragraph goes between

and

tags. Or an image might reside in an tag that contains details like the filename and the image's size. For a Web page to be accessible, you must include layers of meaning and redundancy. The most common example is adding text to an image - usually in the form of an ALT (for "alternate") attribute which enables text to be included in the IMG tag. If your browser doesn't load graphics, or if you use an adaptive device like the reading machine mentioned earlier, you can rely on the text version rather than an image you can't see. As an easy example, the logo on the TidBITS home page carries the ALT text "TidBITS Electronic Publishing." If your browser loads graphics and if you're not using adaptive technology, you typically never see the ALT text, because you don't need to: you can look at the image instead. Accessibility, then, is all about options. Can't see a picture, for whatever reason? No problem. We'll give you words to read instead. Unfortunately, simple measures like this are seldom implemented. Web authors are interested in a lot of things: earning their livings, meeting deadlines, showing off, expressing themselves, pleasing their clients. What they are generally not interested in is accessibility. Why? * Unfamiliarity. Generally, Web design books and courses barely mention the issue. Web shops rarely have adaptive technology on hand to test their designs, nor do they do usability testing with disabled people (if they do usability testing at all). * Priorities (often misplaced). Web designers will spend untold hours coding JavaScript for a page and will labour over egregious Flash animations, but too often ALT attributes and a few other easy accessibility features get left out. * Squeamishness. As explained in previous articles, disability makes people nervous. To code for accessible Web design requires a leap of the imagination - to conceive how, for example, a blind person would navigate your site requires you to imagine being blind yourself. Despite these problems, designing for accessibility can help even non-disabled populations. Just as level entrances and wheelchair ramps make it easier for someone pushing a stroller to get into and out of a building, an accessible Web site works for old browsers, for people with graphics loading turned off, and for Web-enabled PDAs and cell phones. **Resources** -- Yet blame cannot be fully laid at the feet of Web designers or even the clients paying for the Web design work. Put bluntly, the resources available for accessible Web authoring are poor. The current HTML standard includes many features for accessibility - ALT attributes barely scratch the surface (though they are actually required in the current HTML version, 4.01). The source of these HTML specifications is the World Wide Web Consortium's Web Accessibility Initiative (WAI), which provides guidelines, checklists, and techniques for making Web pages accessible. However, in the grand tradition of World Wide Web Consortium standards documents, those pages are long, confusing, meandering, and either maddeningly generalized or overly detailed. There are surprisingly few other online resources for accessible Web authoring. You can find links at the HTML Writers Guild Aware Center and the Web AccessiBlog I maintain. There are only two books on accessible Web design: Universal Web Design, by Crystal Waters (out of print) and Web Accessibility for People with Disabilities, by Mike Paciello. (Last week I signed a contract with New Riders Publishing to write a competing book.) In short, it is hard to learn how to code HTML accessibly. And authoring tools like Adobe GoLive, Macromedia Dreamweaver, and even the trusty BBEdit make it difficult to include access features. You usually have to edit the code manually. **Through The Web, Darkly** -- The design of Web pages is half the problem; adaptive technology is the other. People with low vision use screen-magnification software like Apple's CloseView utility or InLarge by Alva Access Group. (Why not just select a very large font size in your Web browser? Don't forget that the browser runs on the Mac. The entire system needs to be accessible. Nice big type on a Web page doesn't help that much if your menu bar fonts and dialog boxes are still using teeny 12 point text. Moreover, due to poor Web-authoring practices, many sites look terrible and are almost unusable with extra-big fonts.) If you have such poor vision that you can't really see what's on your monitor at all even if magnified, you need a screen reader - a program that reads onscreen text and menus, and interprets icons and other items out loud. However, there is but one screen reader for Macs, OutSpoken by Alva Access Group, and it doesn't interpret HTML. Meanwhile, Windows screen readers are remarkably sophisticated, understanding tables, frames, and many of the HTML access features. And yet, even well-coded Web sites can remain inaccessible thanks to the fact that no browser _fully_ supports HTML, let alone all of the language's accessibility features. Netscape 4 is notorious for its incompatibilities, even with HTML tags that were current back in 1997. Microsoft Internet Explorer 5 for Macintosh supposedly supports the entirety of HTML 4, but it isn't true (features like LONGDESC, used for long textual descriptions of images, are absent). The Mozilla project maintains a hefty list of unsupported HTML tags in the new, allegedly standards-compliant Netscape 6. Meanwhile, the tiny, impressive Web browser iCab has much wider support of HTML 4, including nearly every access tag (LONGDESC is available), though iCab's accessibility support isn't documented. And of course, with only one screen reader for Macs which, by its maker's admission, does not interpret HTML, the tight browser/screen-reader integration we find on Windows is simply absent on Macs. To put it bluntly, you're lucky if you can get things to work. When it comes to Web accessibility for Mac users who are blind or have low vision, then, the news is pretty much all bad. In the short term, these people are still better off using Windows. In an upcoming article, I'll address the even trickier issues involved in accessible multimedia. Just what do you do with all those QuickTime movies and Flash animations? [Joe Clark is a former journalist in Toronto who's followed, written about, and worked in the disability field for two decades. Explore his many online accessibility resources at his Web site.] Come Together: Document Collaboration, Part 2 --------------------------------------------- by Adam C. Engst Last week I looked at some of the variables involved with creating document collaboration systems, and walked through the process that we use with TidBITS. This week I'm going to look at several systems I've used personally. Discussions in TidBITS Talk have also introduced some tools with which I have no experience, so make sure to check out that hot topic for a more complete picture. **Hit the Books** -- I've written books for a number of different publishers, and with one exception, they've used similar collaboration processes. In most cases, I'm a lone author working with one or two editors, which means sending chapters back and forth via email is all that's necessary. Sometimes publishers like to have draft chapters submitted via FTP, but that's proven more trouble than it's worth. In each case, the publishers dictated using Microsoft Word as the document format. Although I wrote my first two books in Nisus Writer and exported to Word when I had to send them in, I've stuck with Word since. I far prefer writing in Nisus Writer, but the pain of exporting, importing, and massaging the text - often multiple times per chapter - overwhelmed my preferences. Before Word 6, major changes to the text were marked with simple colors (never character styles, which could slip through to layout), but since then each project has relied on Word's revision tracking with mixed results. It's nice, particularly with multiple editors, to identify who made which changes when, but documents with revision tracking become messy quickly. You can hide some visual clutter by setting the style of deleted text to be Hidden rather than Strikethrough. Even still it's easy to cause confusion around paragraph breaks when adding and deleting text while using revision tracking, particularly when paragraph styles change at those points in the document. Plus, although Microsoft tries to make it easy to accept or reject changes, it's so much work to address a large number of changes in a book-length document that you tend to accept them all and move on. Conventions for comments have also been similar between projects, with comments appearing on lines by themselves after the paragraph in question, usually in a special Comment paragraph style to differentiate them from the text. With multiple editors or reviewers, convention called for everyone to sign comments with initials. That approach has worked so well that even after the appearance of Word's comment features, I've never been asked to use them while writing a book. I suspect they're too unwieldy for serious use: - the yellow comment pop-ups are annoying, the comment pane is awkward and uses too-small text by default (and in Word 2001 on the Mac, the comment pane's Close button improperly requires two clicks to activate). Also, since Word insists comments be attached to at least one word, people tend to select lots of text for the comment, thus making large sections of a heavily commented document a bright yellow. My Eudora Visual QuickStart Guide was an exception to the process above. It has relatively little text, many screenshots and captions, and a specific layout, all of which combined to make me do the writing and layout directly in QuarkXPress. Since QuarkXPress 3.3 lacks a good built-in way to make comments in files, I sent the files to my editor, who printed them out, marked them up with a red pencil, and sent them back via UPS. It sounds crude, but because so many comments related to layout (kerning, alignment, and so on), on-screen proofing probably would have been less accurate and more work. **Magazine & Web Writing** -- Magazine and Web writing is similar to books in terms of the number of editors (one or two at most) and the methods of exchanging files (always email). Magazines also rely primarily on Word for their document format, although Web publications often prefer either straight text in the body of an email message or HTML. With most periodicals, comments are relatively minimal because the articles and the deadlines are short. A longer piece for a monthly magazine is more likely to undergo significant editing and require multiple passes by different editors. One such publication had some conventions that had apparently evolved organically, since they had the right idea, but didn't go far enough. Changes either weren't marked at all, were marked in blue, or were handled via Word's revision tracking. Either of the last two would have worked fine, but the editors often weren't consistent, which writers found confusing. Similarly, although some editors put their comments at the end of paragraphs, others inserted them right in the middle of the text. A few long comments inside a paragraph made it easy to lose track of the actual text. As with the book editors, no magazine editors I've worked with have ever used Word's comment feature. Some other situations I've experienced have been quite different, however. **Legal Documents** -- When I helped start the XNS Public Trust Organization, the other directors and I worked on a number of long, complex documents - things like our charter, the XNS Global Terms, and various legal agreements. Although there were only four board members and our lawyer, we didn't have an author/editor situation, a centralized server, or reviewers who were publishing professionals. The approach we used was to email Word documents around. Because of busy schedules, we were able to use a round-robin approach, so each of us was able to see the previous comments with the exception of our lawyer, who worked in parallel with the rest of us. (I tried to use Word's Compare Documents and Merge Documents features to merge his comments and changes with a complete lack of success.) We used revision tracking somewhat, but since we were mostly reviewing and discussing these documents, relatively few changes were necessary. However, we ended up using Word's comment feature heavily (about 100 comments over 2 documents), and although it worked acceptably, I found it clumsy for heavy use. An unusual situation occurred when we had to finalize the XNS Global Terms just before launch. Delays meant we were working under a tight, one-day deadline, and we had about ten people involved, half of whom were lawyers. Initially we tried assigning the documents to a single person and hashing through remaining issues in a conference call, but that proved impractical. One of the lawyers recommended taking it back to email but keeping one person in charge of each document. Since the original documents were in Word, we kept them there, even though our eventual goal was to hand them off for conversion to HTML that evening. Plus, even though we were using a variety of Macs and PCs, everyone had a recent version of Word. Word's revision tracking worked extremely well in this case, since it marked clearly what had been changed. We had no copy editors waiting at the end, so it was important to make sure that even small changes were marked. We used Word's comment features occasionally when remarking on something in the text that only the document owner needed to see, but we kept most of the commentary in the email messages used to carry the attached documents around. That let the discussion run fast and free (I set Eudora to check mail every minute) without forcing everyone to open and scan through each document. Putting comments between paragraphs, as I've done in most other projects, didn't happen, in part because people were afraid to add text to the document that might prove confusing to strip out later, and in part because we didn't have time to agree on comment conventions. One lesson I've learned from these experiences is that the utility of Word documents is significantly hampered by having lots of user-defined styles in the document. Without a fair amount of care, not to mention knowledge of how Word styles work, a Word document rife with styles is a copy editing minefield just waiting for reviewers to walk through. The documents from these collaborations were fine in terms of content, but an utter mess otherwise. Some paragraphs were in the wrong styles, others appeared correct but had in fact been "fixed" manually, and almost anything Word did automatically (like numbered lists - a major portion of legal documents) was almost certain to be screwed up. Cleaning up the documents was easier than reformatting from scratch, but not much. **Simple Document Collaboration System** -- To distill my experiences with the processes above and from the TidBITS system I described last week, here are six pieces of advice for creating a successful document collaboration system that revolves around files intended for some form of publication, be it a group term paper, team report, magazine article, or technical book. * Settle on a format before starting. In all likelihood, it will be Microsoft Word, but if you choose something else, make sure everyone has software that can open and edit the files. Pay special attention to cross-platform issues. Relying on other programs to import and export is often a significant obstacle. * Test your distribution mechanism before relying on it at deadline. Email attachments generally work well these days, but a test can save major headaches. See our series of articles explaining email attachments for assistance. * Agree on basic conventions for marking changes. Use either colors or Word's revision tracking to mark changes, or if your editing environment has no color capabilities, some sort of intratextual markup (but be sure to remove it at the end). Mark changes when they're at all major. With Word's revision tracking, it's often best to have Word hide deletions to make the document easier to read. * Agree on how comments will be made, either by putting them between paragraphs (in a different user-defined style or with some prefixed characters) or by using Word's comment feature. If you're using Word, make sure everyone enters their initials in the User Information tab of the Preferences so comments are identified, and if not, make sure everyone signs their comments. * Encourage consistency and adherence to agreed-upon rules. This is primarily important when multiple people are making roughly equal contributions to documents with lots of formatting. In situations where you just want comments or are working with minimally formatted documents, it's easier to let reviewers work however they want and integrate comments manually. * Make sure you know who will be responsible for assembling the final document, which will involve integration of comments, approving changes, removing all markup and comments, and general copy editing and document cleanup. **Going Online** -- All of these systems discussed above used the Internet purely as a transport mechanism. In the next installment, I'll look at several services that offer collaboration environments via the Web with no need for special software or plug-ins of any sort. $$ Non-profit, non-commercial publications may reprint articles if full credit is given. Others please contact us. We don't guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. This file is formatted as setext. For more information send email to . A file will be returned shortly. For information: how to subscribe, where to find back issues, and more, email . TidBITS ISSN 1090-7017. Send comments and editorial submissions to: Back issues available at: And: Full text searching available at: -------------------------------------------------------------------