Shorten URLs in TextExpander
If your Twitter client doesn't automatically shorten URLs for you, you can use TextExpander to shrink those long links to tweetable lengths. First, add the Internet Productivity group by choosing File > Add Predefined Group > Internet Productivity Snippets. Then, to shorten a URL using a service like TinyURL, copy the destination URL to the clipboard, and type the abbreviation
/tinyurl to insert the shortened URL at the insertion point.
Ever tried to work on a document with someone else via the Internet? It's often more difficult than it seemingly should be, so this week Adam starts a series of articles looking at how TidBITS does it and how you too can build successful document collaboration systems for different situations. Also this week, Louise Bremner returns to TidBITS with another report from Macworld Expo Tokyo, and we note the passing of a long-time Macintosh favorite, MacWEEK.
MacWEEK to Roll into MacCentral -- After eleven years in print and three more years online after the print transformation into eMediaweekly (which itself lasted only five months), MacWEEK is finally no moreShow full article
MacWEEK to Roll into MacCentral -- After eleven years in print and three more years online after the print transformation into eMediaweekly (which itself lasted only five months), MacWEEK is finally no more. As of today, Mac Publishing, Ltd. will integrate MacWEEK's content into the MacCentral site. When Mac Publishing acquired MacCentral, MacWEEK's focus on industry news analysis had trouble finding the right fit between MacCentral's emphasis on frequently updated news and Macworld's editorials, features, and reviews. Though the online MacWEEK has long lacked the strong community presence of the old print version, we're still sorry to see it go, and we wish the best to the seven employees laid off in the reorganization of Mac Publishing's online operations. MacWEEK will always have a place in our memories - the white lies seemingly everyone used on the free subscription forms, the Mac the Knife columns from when rumors felt important, and the impact MacWEEK editor Robert Hess's death had on the entire industry. [ACE]
Much is made of the Macworld Expos in San Francisco and New York, but Macworld Tokyo 2001 drew roughly twice as many attendees than this year's record-breaking Macworld San Francisco (181,000 vsShow full article
Much is made of the Macworld Expos in San Francisco and New York, but Macworld Tokyo 2001 drew roughly twice as many attendees than this year's record-breaking Macworld San Francisco (181,000 vs. 93,000). This was my first time with a digital camera, so I didn't take the Psion Series 3mx with which I usually take notes. I figured I'd rely on brochures and my own pictures to remind me of all I'd seen. This approach didn't work quite as well as I thought, but it wasn't a total disaster, as you can see from the images in the page linked below (Ringo MUG, Tokyo's English-language Macintosh user group, also posted some pictures, along with other information about the show). I've included URLs to products and companies which particularly caught my eye, but note that some of these pages are in Japanese and lack English-language equivalents.
Irritating Delay -- I arrived just after the published opening time, expecting to go straight into the show. It was only later that I re-read the announcements and realized my error. At previous Expos, the general public has been let into the main hall at the same time the keynote speech starts. This gives everyone a chance to either see the speech on the huge screen set up in the center of the hall or get a start on looking at the booths before the crowds arrive - or, of course, do a bit of both. But this time the doors didn't open until after the keynote at 11:30 AM. I could have tried to sneak into the back of the hall where the speech was being held, but that would have meant I'd still need to register afterwards anyway.
Instead I experienced several joys, starting with lining up in front of the ticket counters until 10:30 AM, while being constantly harangued by various young megaphoned gentlemen - YMG - who insisted loudly we have exactly 2,500 yen ready, although the woman who took my money wasn't the least bit irritated at my 10,000-yen note. Next, we lined up in an enclosure in front of the reservation desk until 11:00 AM (and were constantly nagged by more YMG to stand closer together in five lines); then we lined up in more enclosures in front of the doors until 11:30 AM (and were nagged by yet more YMG to scrunch into four lines). Luckily, I'd thought to add a book to my bag, even though I usually try to arrive light in preparation for all the paper I expect to pick up during the show.
It might have been a mistake to bring a list of products to check out, because I treated it like a shopping list. I have a theory that a full wallet sends out a signal which befuddles the owner and screams, "Here comes a sucker!" to every loose item of merchandise within range. That may be why I zigzagged towards the T-Zone booth and bought a far more powerful Sonnet G3 upgrade package than I'd intended, because it was one of only five special packages bundled with the video adapter that I correctly thought might be necessary for our Power Macintosh 7100. And that meant, of course, that I was lugging around a bulky package for the rest of the day. Not smart.
Fortunately the U.S. keyboard that my husband wants for his PowerBook G3 is still too expensive for our budget and I couldn't find any of the other things he wanted, so my wallet's signal faded away, and I was free to enjoy the rest of the show.
Confession Time -- I feel a little guilty admitting this, but I find smaller companies exhibiting at Macworld Expo to be far more interesting than the large ones, especially when the smaller companies have created niche markets exploiting areas that Apple has left open. I know big companies contribute the most towards Macworld Tokyo - they pay for the biggest booths and provide reasonably comfortable seating for the Expo-weary. But their flashy, noisy presentations tend to leave me cold.
One of these smaller companies is Id East End, who turned up last year with various keyboards and accessories for PowerBooks, and this year were showing off their Arch 43: it's a keyboard shelf which lets you tuck your keyboard under your monitor (and out of your way) when you're not using it. The Arch 43 isn't like the clunky metal keyboard shelves I've seen before - it's an elegant arch of shaped wood, either blond or dyed a lacquer red, which spans an area large enough to hold a keyboard when it's not in use, and which also sports two indentations on top for the front legs of Apple's Cinema Display monitor and two holders for speakers. It's a sleek piece of furniture that wouldn't be out of place in a living room. [Information on the Arch 43 hadn't been posted to the company's site as of TidBITS's publication time, but there's a picture in Louise's photo collection, above. -Geoff]
I was also intrigued by the Matrox Millennium G400 for Mac, a two-connector video card that enables G4 Cubes to support multiple monitors - a boon since smooth support for multiple displays is one of the biggest productivity advantages of the Macintosh. The second connector can also be used for TV output.
And then there are all the third-party keyboards (including one with dingbats on the keycaps - fun, but probably not very useful). I don't fully understand why Apple Japan provides only JIS keyboards. JIS stands for Japanese Industrial Standards and thus JIS keyboards ought to be ideally suited to this market, but few people seem to enjoy using that horrible layout, judging from the number of companies making alternatives. I have seen some third-party JIS keyboards, but not many. Most alternative keyboards are either U.S. standard, or U.S. standard with combination kana/ASCII keycaps. Eleking was there as usual, selling various kits to convert JIS keyboards into closer approximations of the U.S. keyboard, including a bag of loose keycaps to replace kana-marked ASCII keys with plain ASCII ones.
Unknown Territory -- I'm also fascinated by applications that I would probably never have seen if I hadn't gone to Macworld Tokyo - such as a CCD camera that mounts on top of a microscope to relay the image to a Mac, or CD-R disks small enough to be printed up as information-packed business cards, baseball cards, or wedding commemorations.
For instance, this was the first time I'd seen SoftMac 2000, a Mac emulator for Windows machines, with the demonstrator proudly showing off the smallest "Mac" in the world - a Sony Vaio C1 PictureBook. It's being sold in Japan through Amulet, who had their usual booth with the usual skillful-looking lad doing on-the-spot PowerBook upgrades.
Palm Stuff -- My PDA of choice is a Psion, but the most recent Psions don't interface well with the Mac at the moment, so I'm still using the older 3mx and regretting the lack of Japanese on it. I have bought a Japanized Palm clone, but I haven't got the hang of using it, which means that although I do look at Palm products, my interest is mostly academic.
The cute little MicroPower "super mini portable AC/DC adapter" attracted my attention, together with a backup module for Palm devices called MemorySafe. Those products may have pulled me more towards the Palm, a feeling reinforced by gMovie Maker - but why on Earth would I want to run movies on that tiny screen?
There were also attachments to turn the Palm into a gaming machine, such as the Visor GameFace, a joystick/button combination that fits over the existing buttons. I need to forget about those quickly, which is why I didn't pick up brochures.
Smooth Operators -- Demonstrating a product is a strange job - not one I could manage myself, so I feel sympathy for people who find themselves stuck in it. Some just chat with friends and ignore potential customers, while others pounce on passersby - which scares me off. In between the two extremes are the smooth operators who manage to both attract my attention and draw me in.
My first good demonstrator experience was at the SoftPress Freeway booth. I was looking at the displays and the man asked whether I'm interested in putting up a Web site. My answer was intended as a brush-off: yes, but I'm not going to make things more difficult for myself by learning how to do it all in Japanese. Whereupon he said that Freeway 3.0-J can switch to the original English menus, and sat me down to demonstrate that feature. He then went on to show how easy it is for someone with QuarkXPress experience to set up a master page, and then individual pages. I could feel myself being led on, but it was an enjoyable experience. I'd had vague ideas of maybe cobbling together some sort of Web site for my photos, but I assumed I'd just have to learn how to hand-code the HTML. He's got me thinking it'd be a good idea to invest in a dedicated software package. There are lots of packages out there, of course, but the Freeway rep caught me first.
My next experience was a guy demonstrating a basic CD-label printing package, one of five that have recently been introduced by Hisago - a pack of special paper together with a CD-ROM containing templates that the user can customize with different colours, patterns, and images. He was so enthusiastic he nearly tempted me into buying a couple of the packages there and then, even though my elderly HP printer probably couldn't cope with the glossy paper.
Then there are always the weird encounters. As the Expo progressed, I realised I had taken plenty of pictures of booths, products at booths, demonstrators at booths, and backs of customers at booths, so I went looking for something different - preferably cute. Unfortunately, a little girl punching a foil balloon was moving too fast for my non-flash shutter speeds. Then I saw a torpid dog, lounging on a high-chair at a booth - ideal shutter fodder. So there I was, taking several photos of the dog while the booth personnel made noises to persuade him to look alive. I thanked them and moved on, then looked back and saw the big screen behind them, showing what looked like an array of thumbnail images. They had seen I had a camera and that I was clicking the shutter several times - which surely should've suggested I had a large Compact Flash card in the camera and hence a need to catalog those shots. So why didn't they talk about the product, instead of showing off the dog?
Time to Go -- Before leaving, I played with the Titanium PowerBook G4 (which induces minor lust: I like it a great deal, but I don't need it) and had a look at the new Flower Power and Blue Dalmatian iMacs. They boggled me slightly, since I thought part of the iMac's appeal was the seductive way in which you can't quite see the innards through the semi-transparent casing. So what's the idea of making the casing opaque, and with those patterns?
This year's Macworld Tokyo wasn't a major event for the Macintosh industry, but it wasn't a bad Expo either. It was simply proof that there are many serious Mac users in Japan. There seemed to be a wider range of people attending this year - more older people, suits, and young families. In fact, on my way into the show, I wondered whether I'd come on the wrong day because the crowd looked to be made up of so many everyday people. But in many ways, that range of users is precisely what Apple needs, both here and throughout the world.
[Louise Bremner is a freelance technical translator (Japanese-to-English), based in Tokyo.]
One of the great features of the Internet, according to the pundits, is how wonderfully it enables communication and collaboration between widely separated individualsShow full article
One of the great features of the Internet, according to the pundits, is how wonderfully it enables communication and collaboration between widely separated individuals. Much of this communication occurs via email or, in some cases, via instant messaging, and works well. But I'll bet that if you've ever tried to collaborate with a group of people on the Internet to write and edit a document, you've found that moving the document back and forth across the Internet is merely a minor aspect of the entire process, and that effectively collaborating with people is quite difficult.
Here at TidBITS, we spend a lot of time together editing documents - even though none of us share a physical office - and we've worked out a system that has proven quite efficient for us. But since we all write for a variety of other publications and organizations, we've also come across numerous other collaboration approaches. It's continually astonishing to us just how hard it is to put together a good document collaboration strategy and how different groups have chosen to handle the problem.
This week I'll look at some of the major variables involved in any document collaboration system and give you a detailed look at exactly how we share documents within TidBITS. In the next installment, I'll explore a number of other systems I've used with other groups and talk about how well each worked. By the end, I hope you'll have a starting point from which to make your next document collaboration task fast and efficient.
Collaboration Design Variables -- There are several variables to consider whenever you're trying to set up a document collaboration process, especially one which doesn't rely on fancy tools that can be expensive, hard to deploy, and tricky to use. My assumption here is that you have a document you wish to have reviewed and edited by others; although documents may have multiple "owners" throughout a publication process, at any one time there should be only one person ultimately responsible for it.
Version control. Perhaps the most important consideration is how you'll handle version control, or making sure that everyone's comments and changes are integrated properly into the final document. There are two approaches here, scattershot and round-robin. In a scattershot approach, you send the document out to all the reviewers, then collect and combine those reviewer's comments. It's easy, requires little technology, and doesn't make demands on the reviewers. Unfortunately, it also often results in duplicate comments from reviewers (who also don't benefit from seeing each other's comments) and gives you a lot of extra work in evaluating and integrating all the different responses. That extra work can make for a better document in the end, though, since you maintain a coherent view of the whole. In the round-robin approach, each reviewer edits the document in turn, which lets them comment on one another's changes and eliminates some extra integration work. Unfortunately, you generally still have to do major cleanup on the final document. Worse, the round-robin approach takes time, and the amount of time goes up with the number of reviewers, since only one person can have the document at a time.
Number and type of reviewers. If you're passing a document to one other person and receiving it back, it shouldn't be hard to agree on an approach. However, as the number of reviewers increases, it's often best to choose one of three approaches: simple, rigid, or assisted. A very simple approach that requires little of the reviewers works best with ad-hoc reviewers, though it increases the work of the person in charge of the final document. A detailed approach with rigid rules about markup styles for comments and changes works better when you have a close-knit group that can agree on a process. Finally, if you simply can't get your reviewers to follow a process, assistance from document management tools may become necessary. I can't comment on these for the most part, since they tend to be large, complex, and expensive - three adjectives we at TidBITS avoid like the plague.
Document location. The resources available for document location and access - both for you and for your reviewers - play into how you set up your collaboration process. Centralized servers can work well, especially for a round-robin approach with a number of trained reviewers, but they're often hard to use and overkill for a couple of ad-hoc reviewers. In that case, a decentralized solution (usually using email, floppies, or CD-Rs to distribute files) usually proves more effective.
Document format. The document format you choose to work in can affect your collaboration process significantly, but it's important to remember that you can use different formats at different points in a publication process. For instance, even if an article is destined for QuarkXPress, that doesn't mean you can't design the review process to use Microsoft Word documents or even straight text files. Plus, programs like Word offer (occasionally inscrutable) collaboration tools of their own, whereas other formats may require you to decide on some simple markup to indicate additions, changes, deletions, and comments.
Document markup. No matter what format you choose (and different projects may call for different formats), it's a good idea to negotiate markup conventions ahead of time. Otherwise you'll waste a lot of time trying to figure out different markup approaches, particularly in situations where you'll be passing many documents by a number of reviewers. Even in Word - which has revision tracking and a comment feature that identifies the author of each change or comment - it's a good idea to agree on usage conventions ahead of time.
Keep in mind that no one collaboration strategy will fit every situation, and you may need to come up with several strategies for different groups.
TidBITS Collaboration -- We've adopted a specific strategy for document collaboration that works extremely well for us. It's not perfect, and it undoubtedly wouldn't work in all situations, but let me explain it so you can get a sense of how you might go about using parts of it in your own collaboration process.
We rely on a round-robin editing approach among a small number of editors working on a centralized server, accessible via both FTP and AppleShare over IP. All of our documents are in Nisus Writer, which provides styles for markup, although no revision tracking or comment features like Word's. Here's how a document might go through the entire process to end up in a TidBITS issue.
One of us creates the draft document, applying the styles necessary for our issue creation and distribution macros. That person also does an initial edit pass. We don't worry about small changes, but we mark meaningful changes with colors so others can see what was done. Additions or modifications appear in green, and proposed deletions appear in red. If we need to make a comment or query about a paragraph, we make the comment in red on a line by itself below the paragraph to avoid confusing the meaning of the paragraph with intratextual comments. All comments are signed with the initials of the person making the comment. If the comment or query applies only to a small bit of text, we mark that text in blue. Comments and text for deletion are both red because all red text is automatically removed just before distribution.
After finishing the initial edit pass, the document goes into a folder called IN on our server. Appended to its name are a version number and a set of initials. So this article is currently called Collaboration.1.ace, which indicates it has undergone one edit pass by me.
Let's say Jeff Carlson wants to take the next edit pass. Anything in IN is fair game, so he checks the document out by moving it (a Finder drag via AppleShare over IP, but possible in Interarchy via FTP with the Rename/Move command) to another folder called OUT. He also adds his initials to the filename so anyone trying to figure out who owns the document can tell by the fact that it's now called Collaboration.1.ace.jlc. Checking out the document also involves downloading for Jeff and Geoff, while I, since I'm on the same network as the server, just open it directly, although I otherwise follow the same rules. While Jeff has the document out, he can make any changes he wants, using the same colored markup scheme and comment approach outlined in the first step.
As Managing Editor, Jeff often has the task of sending an article back to the original author, if it wasn't written by one of the TidBITS staff members. Here's where our system falls down a bit. When copying text from Nisus Writer to any other program (such as Eudora), color information is lost (we also prefix all comments with three asterisks so they stand out even without colors). Interestingly, a similar color pasting problem afflicts Microsoft Word as well, so we can't export from Nisus Writer into Word as a workaround. And since relatively few people use Nisus Writer, sending the original file isn't generally a useful option. Thus, our preferred approach is to send the article back in the body of an email message and ask the author to make comments and offer suggested changes just as though they were replying to a normal email message. Jeff then incorporates the changes manually. That works well as long as the changes are relatively minimal, but for more significant rewrites we find that we just have to give the original file back to the author, let him or her make the necessary changes, and then restart the entire process. When Jeff''s done, he uploads the file to IN again, and changes the name to Collaboration.2.ace.jlc so we know it's gone through the second edit pass and who did it.
At any time during this process, we may send the article draft out to expert friends for quick technical review. They too get the article in the body of an email message and make comments and corrections in their reply. Whoever sent it out for review then has to incorporate the corrections and address the comments in the file, checking it out and back in again as necessary. At times, the list of initials at the end of the filename gets too long, at which point we delete some from the beginning of the list.
When he's ready, Jeff moves the current version of the article into OUT, copies all the text, complete with colors and comments, and pastes it into what we call a "copy file," which is the working draft of the full issue. Once the copy file holds the latest versions of all the articles, it too goes into IN and follows the same process rules, although we only add initials to the filename when it has been moved into OUT, since that's happening on Monday when we need to know exactly who has the file open at all times. On Mondays we also tend to use email and the phone fairly heavily to let others know when the document moves to avoid wasting time in between manual checks of IN and OUT.
Throughout all of this, colors and comments stay intact. At the last step before actual distribution, Geoff Duncan gives the issue the final read-through (often out loud - hopefully his neighbors don't mind) and deletes all the comments and text marked for deletion.
For the most part, our system relies on simple technology - an AppleShare/FTP server and colored text in a word processor. We intentionally try to keep our markup rules simple so there's never any confusion internally about what's happened. And when we bring in reviewers via email who don't know our approach, either they don't need to know it, or we can explain it easily.
However, our system also relies on having a small number of technically savvy reviewers with excellent attention to detail. Our approach would fall apart if anyone was overly sloppy or failed to follow the rules, especially those relating to checking files in and out, since we could end up overwriting someone else's changes. But there are other approaches that work better in such situations, and in the next installment, I'll look at some that I've used with varying degrees of success.