top of page



When Shirley Bryant approached me with a request to do an interview for the IOBA’s The Standard newsletter, it forced me to reflect on what it is my colleagues and I do at Allusive Information Systems and how we got here to be doing it….


From personal experience, I can tell you that book dealers and computer people are very much alike – generally independent, a bit eccentric and definitely passionate about the ingredients of their respective vocations. Just as book dealers do much more than simply buy and sell books, computer folks do a whole lot more than simply sit and code, or create computer systems for clients. The world of books and the world of computers exist – both cultures of communication.


I began as a citizen of the world of books….

After a stint in New York working for a Japanese trading company where I could use my Japanese language skills acquired in college to a practical end, I moved to northern California in 1975. I was working as a finish carpenter in 1977 when an acquaintance asked me to become his partner in a small used bookshop in a small apple town where the freight trains still ran down the main street (called Main Street, by the way) on their way to the cannery. The day I came by to talk to him, he gave me a set of keys and put my name on the checking account. Suddenly I was a book person – a full partner in a business that had grossed almost $14,000 the year before!


Most instances of autobiography now turn to the enormous success that followed – fortune and the respect of colleagues accumulating through the years – the subject turning back in self-satisfaction to consider a life well led…


In my case, I would have to say that, while I hope I have gained at least some regard from my colleagues and learned a little bit about the craft of dealing in the books of East Asia, what I really found that day over 25 years ago was a passion, a love for books and for the world of books. I did become a member of the Antiquarian Booksellers’ Association in 1980 (at a time when the ABAA was full of young booksellers in their late 20’s to their early 40’s). A few years later, I moved to Boston and became involved in the life of Helen Kelly and her business, the Boston Book Co., founded in the 1970’s. It was Helen who gave me the chance to see what a large urban book business could be and who opened my eyes to the joys of domestic life – we married and had a son in the late 1980’s.


Helen had one of the first computers in the old book trade: In 1982, she bought an original IBM PC with specifications laughable by today’s standards – but it was top of the line (with a hard drive, no less) and cost her about $10,000! Not so laughable a sum then. Soon after I merged my book business into hers, I became involved in the care and feeding of that by then venerable PC and its successors – then creating a network…..I was hooked.


Helen had introduced me to my second passion – the world of computers.


Helen had equipped that original PC back in 1982 with Bookease – Marc Younger’s professional bookseller’s package, built on DOS, which he had created for his own bookseller wife Helen in the same year. By the early to mid-90’s I had become Boston Book Company’s information technology department – our computer network had grown – we had gone far beyond the first PC to the blistering speed of the 486! Marc had succeeded in creating a version of Bookease that networked well and stably, we had bought a commercial space specifically for our rare books. Our book business was prospering… we cranked out catalogues, published lists and I personally had also become our Asian book department of one and was doing a land-office business with Japan.


But off on the horizon, no bigger than a man’s hand, a dark cloud was churning. The Japanese market was in decline; that was clear. Techno-friends were starting to talk about the growth of a “network of networks” called the internet and I decided to take a look. By 1992 I had an email address and a shell account so I could start exploring the ‘net (not via the Web, though, it was too early for that –I didn’t even use Windows….). But even in my halting fashion, I found my way in cyberspace and what I found astonished me: the internet was full of librarians!

Viewed from the near side of the dot-com divide, the internet of those days seems quite quaint. Even folks with “com” domains were careful to give as little offense as possible to the dominant anti-commercial culture. The ‘net was for the exchange of information – if you wanted to share bibliographical information as a bookseller with your colleagues and with the library and academic worlds, that was fine, but booksellers should not flog their wares.

But soon there was an accelerating move to make more than pure information available over the ‘net – fueled largely by the splashy, graphics-heavy and user-friendly World Wide Web. By 1993, Boston Book Company was on the Web and by early 1994 we had established a searchable database of our wares there. Interloc was still a Bulletin Board Service not open to the public, ABE and Bibliofind were just stirring, Amazon had only burned through their first few millions – spring was in the air.


As the dot.com boom evolved in the mid to late 1990’s it became clear to me and many of our colleagues that the easy answers for marketing that the Web seemed to provide for small businesses like ours were not an unmixed blessing. Bibliofind, ABE, AntiQbook in Europe, Interloc (later Alibris) and soon many other sites were jostling each other for a piece of the pie – trying to lure dealers to post their listings and to draw eyes to view them as well. And just like that we all seemed to get bulldozed by big money – folks you would never expect it of were suddenly interested in books. Capital was being poured into the process – relatively big fish were being swallowed by bigger fish in the internet world – Bibliofind was grabbed by Amazon which had discovered a sudden interest in old books and ways to market them and Interloc became Alibris absorbing Bibliocity, hoping to create a whole new market for old books by raising their visibility through the pages of the New Yorker…. It was a strange time.

There seemed to be a two-fold attack on our way of life. On the one hand, it was clear that money was trying to take over the old book world – whether that was sensible or not, whether there could be any reasonable return for the outlay of cash required to get noticed on Wall Street. One could foresee a future in which old book dealers would become glorified scouts for the various huge marketing venues. Not the sort of future most of the book people I knew relished.


The second attack (or just plain change, to be more neutral about it) was a revolution in our day-to-day activities. Traditionally there had been a “food chain” in the old book biz – at least since the demise of the truly great generalist booksellers – dealers sold to other dealers up that chain, retailing to their own customers along the way and wholesaling to specialists or those with more savvy about marketing at the high end. The romance of the vagabond bookseller hunting for gold on the less-traveled roads of America was being written every day, even just a few years ago. Yet the growing access to information (and misinformation, alas) over the internet meant lots of people knew lots more about books and markets than ever before, and the out-of-the way bookshops got much less remote. In the meantime, the multiplication of electronic venues, and the growing need for sophistication in all things digital, meant that there was less time for actually handling the books we all love…. Our customers, who had relied on us for expertise, were going to the search sites or to Amazon, to find information certainly, but more often to find stuff cheaper.


Ironically, the computer, which was supposed to make everything easier, ended up on the verge of separating us from our wares, making us work harder and maybe even making it harder to make a living.


The old book world responded with a whole raft of marketing solutions – ideas like the IOBA, high-end venues like WorldBookDealers, the ABAA/ILAB website and search engine, the joint ownership represented by TomFolio, etc. Each was an effort to reclaim the old book world from the new giants. We had all seen too clearly the utter demise of the independent new book dealers. No one wanted to follow them.


I supported all those efforts as best I could, but there had to be an answer from the computer side of things, as well. In that atmosphere, I decided to try and create some tools that would make it easier to interact with the brave new world of bibliospace, to alleviate some of the new drudge work that our friend, the computer, had created for us. As a member of Boston Book Co., I felt I was a good position to understand the joys and pains of 1990’s bookselling – we operated a used bookshop near the BU campus, and had a rare book operation in Jamaica Plain, a Boston neighborhood. At the rare shop we handled general antiquarian items, but we also pursued a fairly serious specialization in the world of Japanese books. In short, because of our internal diversity, whatever we could create to help us at the Boston Book Co. would probably help many of our colleagues, as well.


If I turned to my book business for inspiration and experience, I turned to my next-door neighbor for digital muscle. My neighbor, Mark, is a very skilled database developer with over 20 years experience in creating database tools for hospitals and educational institutions. He and I started to discuss the idea of using the internet not merely as a marketing medium but also as a foundation for helping booksellers more easily control their businesses as well. Our talks, at first theoretical and purely speculative, soon became very practical and, by early 1999, we had formed an LLC: Allusive Information Systems. Mark quit his job and came on board as a full-time in-house developer.


Over the course of those conversations, we developed a set of principles that would be the underlying theory of Allusive. Allusive was set up to fill a niche in the old book world, to develop a set of answers to some problems that I had learned about too clearly as a bookseller.


First of all, as computer people, we had to learn to listen to the customer, to the bookseller. Technical people tend to see the world in terms of their own latest technical “fad” – they are excited by the new, want to explore the “bleeding edge” of technology. We were determined not to prejudge a solution by its technical “sexiness” alone. What works, works.


On the other hand, it is true that clients and especially booksellers who aren’t computer literate have a certain Luddite strain (which I don’t entirely disagree with) that has to be dealt with. Sometimes the old way of doing things has simply gotten too complicated. I often find that booksellers use a Rube Goldbergian mess of structures, techniques and equipment that has evolved in response to practical needs as they have changed over time, which “works”, kinda, but which is so inefficient that it isn’t making economic sense for the business.

The result of those two problems is that booksellers are sometimes stuck with systems that are either alien and unusable or antiquated and overly complicated. In both cases, the systems are further compromised by being unreliable. And where do you find somebody to help you fix a problem at a moments notice? If your technical “faddist” moves to Peru, who will understand what latest gizmo he or she has equipped you with? On the other hand, if your system is a crazy quilt of operating systems and older equipment, who can pull it all back together when it falls apart?


Mark and I came up with the notion of creating a “toolbox” of software, both for the dealer’s office and for use over the internet. We figured that the basic task of the bookseller was the creation, storage, conversion and transfer of information. The average bookseller has data that they need to store and have access to – book records, sales records, wants, etc., etc.


Most everybody has some sort of database that they use for helping them with that – a software replacement for the raw memory skills and the many, many index cards we all once used (and once had, in the case of memory skills). Those databases are sometimes brewed at home out of Access or a spreadsheet or Filemaker Pro. Alternatively, there have been dedicated bookseller programs around for many years: Bookease, Homebase, BookTrakker, BookHound, etc., etc. Some were built from scratch, some on a base of Access or Filemaker – all useful as far as they went. It was the integration of those existing tools with the internet, and the growing marketing opportunity the internet represented, that we wanted to aim at.


It was at that point in 1999 that an interesting practical circumstance arose that put a point on our need to come up with tools for integration. I had been friends with Marc Younger, the developer or Bookease, for many years. He had handed over the maintenance of Bookease to other people soon after developing some simple tools for exporting internet-ready files out of it in the mid-1990s. The handover was not a success and became a classic case of the two failings we were seeing: too much tech on one hand, too little service on the other. The first group that took over Bookease for DOS meant well but never seemed to be around when there were problems or questions from the Bookease booksellers. In despair, Marc made an arrangement with another developer on the west coast – this fellow decided to rebuild Bookease from scratch as a Windows program on an Access foundation. Bookease had been brilliantly conceived by Marc and was a very stable and expandable piece of software built on a Foxpro foundation. Access, on the other hand, is not a foundation for a mission-critical business environment – at least not as it was used in the new “Bookease Pro” for Windows.


The results were instability, loss of data, bookseller recriminations and the new developer’s disappearance from the scene. Bookease Pro was in shambles and Bookease Plus for DOS, while humming merrily along, was running into a limit we all saw in the late 1990’s – the Y2K dilemma. Bookease for DOS needed an update desperately and time was running out.

It was at that point that Marc Younger came to us, and asked if we at Allusive might take over the maintenance of Bookease for DOS. Though it seemed a bit far afield from our primary mission of building all new tools, I saw it as an opportunity to establish a relationship with a whole group of longtime computer users who still used the old Bookease program, and an acid test for our ability to integrate the old and the new with software “bridges.”


In late 1999 we set up a Y2K upgrade system, contacted those many Bookease DOS users who had been languishing a bit since the mid-90’s, created a service contract system and Y2K converted every dealer who wanted to sign up before the January 1 witching hour. It was a great experience, an early success, and it taught us a lot about where we should be going. It was also the genesis of the online data conversion system that would become BookRouter.


As I mentioned, Bookease had a rudimentary capability to export book records in UIEE format, which had originally been developed by Tom Sawyer of the then Interloc as a lingua franca for the transfer of book data. That was great as far as it went; one could log on to the various indexing sites and upload the export files, or one could use email to send an attachment to a few of the sites, or send by FTP, or…. There were many ways to keep up – too many it seemed and I–and many of my Bookease customers–was spending one heck of a lot of time creating formats and logging on and sending by email, and it didn’t seem to make much sense.


It was in that environment that my database-savvy neighbor and I put aside the development of yet another online search site, and decided to create a universal online data converter which could take pretty much whatever text-based data that was thrown at it, convert it to an appropriate format for the various indexing sites and send it on. We also thought it would be good if we could do things to the book records on the fly…. Perhaps the dealer would only want to send books over $100 to one of their sites – or perhaps they wanted to have an instant “sale” by lowering prices, or they wanted to add an html link to their homesite to each and every record. We (or should I say Mark) created a “swiss army knife” data converter online at http://www.bookrouter.com and our first “bridge tool,” the prototype for the whole concept, was born. BookRouter went public in mid-2000. It has gone through many changes and improvements since, but the original simple idea remains the same: Upload once to us and we will take care of the rest – including all the toing and froing and talking to the sites when a mistake occurs. We wanted BookRouter to become the ultimate time-saver. At first customers were skeptical – it was really quite easy to upload files after all, and it didn’t seem to take much time – skeptical until they realized just how much time they really had been spending now that they weren’t spending it anymore.


The Bookease experience also showed that there really was a need for a multi-tiered approach to the in-house bookseller software dilemma. Bookease DOS had been built on a state-of -the art foundation that was very robust, but the platform was creaky now and it was clear that a lot of functions (direct export of data to emails, for one, “assisted cataloguing” like Homebase’s ISBN lookup, for another) that were so necessary for modern commerce could not be added via DOS. But the Bookease Pro disaster showed that simple conversion of Bookease functionality into a Windows-based environment was not the answer by itself. A “one-size-fits-all” mentality wouldn’t work where some folks were dealing with thousands and others potentially millions of book records. New thinking was needed. We had to look around for new systems, new approaches.


We had been using a Linux data server at Boston Company for many years. Linux was free, or close to it, and it was incredibly stable and bulletproof, as well. It networked well with Windows and made it possible to set up data server boxes separate from the rest of the Windows network and thus protect against the data corruption that came from inevitable Windows crashes. In addition, hardware had gotten so cheap that there wasn’t too much economic pain involved in setting up those Linux servers, as well. Any “entry-level” machine off the shelf was more than capable of doing the job. Over the course of time, I have set up a number of Bookease users with whole new systems – integrating their old hardware with a new box that hummed along – delivering data. It was almost comical – I would stop by a client’s shop to deal with some problem or another or just to check in – and the server would be running perfectly. I would reboot it just since I was there anyway. There are data servers at some of my clients’ places that are only rebooted once or twice a year.


So we had grown busier – besides the toolbox business, as exemplified by BookRouter, we were also doing systems consulting, taking care of all the Bookease DOS users, setting up hardware/software networks, consulting on equipment acquisitions (we have found that most folks overspend on hardware because they are insecure about what they really need), etc. Help was necessary. Especially since early in 2001, Mark, having built BookRouter and the online search engine, got an offer from MIT he could not refuse.


We brought in a part-time developer, Steve Clay, to take care of further work with BookRouter and the search engine on a consult basis. In addition, we hired an office manager, first Cathy, then BJ – who sends out bills to our customers and makes sure at least some of us get paid. We added Scott Pezza to take care of customer service. He is the one who fields questions, sets up new clients, writes conversion scripts for the occasional exotic data format beyond the reach of even BookRouter’s built-in tools – in short, he is the glue that holds the day-to-day operation of BookRouter together. And he is a gifted developer as well. Over the last many months, he has been hard at work creating a new tool for the toolbox: He has written an order management system which integrates and organizes all the email orders from the various online listing services – puts them into a coherent form, generates reports, creates packing lists and invoices, keeps track of clients, etc., etc. All this can be done either locally over an intranet or over the internet when the user is away from home. We haven’t come up with a name for this analogue to BookRouter, a Swiss army knife for orders, the results of our labors, but we are thinking about one – for now it is just “OMW” – Order Management Web.


We are refining the online search mechanism, which now exists in-house as a database of our BookRouter users. Soon we will be offering that database “backend” as a feature to our BookRouter clients: they will be able to search their own inventories from their own websites without potential customers being diverted into the ordering systems of the indexing services. The search results, logo, colors and all, will appear to come straight from the dealer’s own search engine.


We have outsourced development work on the successor to Bookease DOS to a group of programmers in Europe and further east and are working closely with them to dot the “i”‘s and cross the “t”‘s. The program is called Biblioware and it is a total departure from the standard in-house bookseller’s database program. It has a front-end with all the bells and whistles derived from the best of the bookseller programs, a user interface that can potentially plug into any modern database you please – whether it be our home grown Java data backend that will allow the Java version of Biblioware to be totally self-contained and totally compatible with any operating system, or a heavy-duty Linux/Unix/NT database for heavy lifting client/server operation, for people with thoughts of putting a million book records online.

Carrying the “toolbox” idea even further, we are also working with a fellow who has created a wonderful assisted cataloguing system that is at least as accurate as Homebase’s ISBN lookup feature, but which will also allow the lookup of older, pre-ISBN material, as well. Its functionality will be integrated into Biblioware, the successor to Bookease DOS, but it will also be “modular” so that it can integrate with any bookseller’s program out there. One needn’t have to convert to a whole new system like our Biblioware or stick to an essentially “light-duty” database like Homebase in order to derive the benefits of assisted cataloguing technology.


Obviously, even with outsourcing some development, we are going to need more hands to make all this work. Scott needs an assistant, I need an assistant, we need an extra full-time developer on staff – the wish list is long. We “come in” in the morning (sometimes we log in from far away, actually), clear up any problems re Bookease or BookRouter first thing, then start to work on toolbox projects or in setting up connections with new customers or new indexing sites. We have, in the past, had to create entire new programs to allow bulk uploads to Amazon or Half – there is never a dull moment at Allusive Information.


Finally, we are always looking for new ideas from our book-selling colleagues. We are committed to making this “computer thing” work for all of us, not just for the ones with the money or technical savvy to bulldoze their way to a solution. So far we have created BookRouter, which we are very proud of as a tool for reducing the day-to-day drudgery of the online bookseller. We have set up a stable maintenance contract environment for all the Bookease DOS users still out there. And we are hard at work on a whole group of new capabilities or tools – centered around the new bookseller’s program called Biblioware, but consisting of a group of universally adaptable modules: the order management system, the assisted cataloguing system, the online search engine. All of these will follow the BookRouter model of being universal and adaptable to as many legacy systems as possible. It all sounds very complicated, but, hopefully, the complication is under the surface where the user never sees it. Take one, or take them all, the tools are created to make things just a little bit easier and more simple for the bookseller client.


With that, I think I have to say goodbye to you all. This essay ended up being a lot longer and a bit more technical than I thought it would be when I started. I am always ready to field any questions that anyone might have about what we are about, but for now, from Scott, BJ, Steve, our European friends and myself, I would like to wish all of you in the world of books heartfelt best wishes from the world of computers.




 

Tom Sawyer is an éminence grise of the Internet bookselling world. He is the creator of the UIEE format that has become the de facto industry standard, the developer of BookMaster, Record Manager and BookMate software — and now, the soon-to-be-released BookWriter. A man with bookselling in his blood (his mother is an antiquarian book dealer), Tom is one of the most knowledgeable, most capable — and most interesting! — people in the business. As one of the co-founders of Interloc, Tom designed and coded the software that made Interloc the first on-line bookselling success story. Later, Tom co-founded Alibris, successfully adapting Interloc’s software to a new business model. Over the years Tom has met and worked with hundreds of booksellers, and yet he has never been formally interviewed. Not even a photo of Tom has ever been published.


So fasten your seatbelts, Standard readers! We’re about to give you a breathtaking industry scoop, guaranteed to thrill, inform and entertain.

* * * * *


It was a complete accident. My mother has been an antiquarian bookseller for 40 years. One day in 1987 I visited my folks and found my mother tearing her hair out trying to keep track of twenty thousand 3×5 cards. She knew I had some experience with computers, so she asked if I could write a program that would help her manage her book records. I said OK, so I created the original BookMaster program, which worked well for her. Then, her friends started asking for copies, which I provided. I later started handing out a LOT of copies and I said “Hmmm, I wonder if I can make a living at this?” I’ve been at it ever since.


How did you get involved in on-line bookselling?


Again, serendipity. Dick Weatherford had reviewed BookMaster in AB Bookman’s Weekly in 1991 and he liked it. He called me up in June of 1993 and asked if I could create the software for an entire on-line system for book dealers, both front and back ends. I was really flattered he called me. This had been tried before unsuccessfully so I was a little nervous about it, but Dick was great about supporting my ideas. We went back and forth for a while and we came up with a workable design. I recommended Brad Councilman to handle the back-end hardware and network, and he did a super job on a shoestring budget. And amazingly, it all worked! In the five years Interloc existed before reincorporating as Alibris, the three of us only actually met face to face on three occasions. Our relationship was based entirely on trust. It was the greatest experience of my professional life. We’re still very close friends.


Did you develop Record Manager for Interloc? Didn’t it also provide UIEE support?


Yes, Record Manager was the first program to provide direct UIEE upload capabilities, in support of Interloc. BookMaster created UIEE files, but didn’t directly upload them. I authored all versions of BookMaster, Record Manager, and BookMate. Alibris provided guidance for the BookMate feature set.


Were you involved in the creation of ABE or Bibliofind?


No, not in the sense I think you mean. Michael Selzer and Rick Pura were some of Interloc’s first customers. They developed their systems independently when the Internet started to take off. I don’t recall having had any personal contact with them, but it was a long time ago and I also did Interloc tech support the first couple of years, so it’s possible we spoke at some point.


Are you still involved with Alibris?


No, my relationship with Alibris ended in April of last year. I’m still in touch with some of the people involved, and I do own some stock in the company.


Many people were disappointed when Alibris elected not to release a BookMate II version. Can you give us any idea of why this happened?


I had no direct involvement in that. My understanding is that a BookMate II version was not released because of a business decision to no longer develop client software.


What can you tell us about BookWriter, your new bookselling software?


Well, BookWriter is actually just one of several programs under development. We’ll also be offering an auction composition and upload program for HomeBase users, as well as some UIEE conversion utilities and other things I’d prefer not to mention just yet. But to answer your question, BookWriter contains the features that booksellers would expect to be there: Hit List, catalog composition tools, rapid data entry, global editing, ISBN lookup, export to several different file formats, multi-destination upload capabilities and lots more. It also provides the ability to relate images to book records and manage them directly, something I feel very strongly about. I think the program will be well received.


What’s different about BookWriter as compared to other bookseller software?


Okay, there are two things that really set BookWriter apart. The first is that BookWriter will compose auctions and upload them to venues like eBay, Amazon, Yahoo, and Popula. The image management software is part of this. The composed HTML can be used in pretty much any auction venue or web page. I feel that giving booksellers the ability to use their existing book record databases to quickly and easily compose auctions will really give them a huge competitive edge and restore their ability to increase sales through broader, mainstream exposure.


But the second thing that sets BookWriter apart, and I believe more importantly, is that BookWriter will be the first user program to be fully 100% UIEE 2.44-compliant. This means the UIEE files can contain not only record text, but images and other objects as well. Images are maintained from within the program and uploaded as part of the UIEE file, not as separate entities. This capability is going to make life a lot easier for everyone as companies adopt the new specification. The upgrade process is already quietly underway.


Very interesting, indeed! Will companies like ABE and Alibris adopt the new UIEE format?


I can’t speak for them, but we hope so, and frankly I don’t see how they can avoid it, for three reasons:


First, UIEE 2.44’s objectives are right in line with venues that serve as intermediaries between sellers and buyers. It will make their activities both simpler and more cost-effective, so I don’t see any practical reason they would choose not to adopt it.


Secondly, even though uiee.com has only been live for a couple of weeks, we’ve already been contacted by several listing services and auction companies wanting to become directly UIEE 2.44-compliant. We’ve also received inquiries from software vendors wanting to upgrade their clients. BookWriter may be the first software client program to support UIEE 2.44, but it certainly won’t be the only one.


And third, UIEE 2.44 is a solution to problems that aren’t going to go away by themselves. This new standard supports all types of collectibles, not just books, in both retail and auction venues.


Won’t upgrading be a major undertaking for companies?


Definitely not. The special nature of UIEE is that programs can be created in any environment to assemble and disassemble upload files. Although we’re offering software that will run on most servers, anyone is free to create their own. That’s the point of developing and publishing the new specification. Of course standard UIEE files are supported in every respect. Nothing is lost.


In fact, the companies receiving the files have it easy — all they have to do is disassemble the UIEE files, and that’s really simple to do. The burden is really on client software developers to effectively create an environment in which images and text can be managed harmoniously. That takes a bit more doing, but there are many auction programs already doing this well, so there are plenty of examples to draw on. Programmers writing bookselling software are going to have to add a new dimension to their work.


What about storefronts, like eBay Stores, Yahoo Stores, zShops, and Popshops?


BookWriter can export data in multiple formats, including Excel .CSV format, which is the “standard” used by most SQL-based storefront and retail environments. BookWriter users can send their data wherever they like and be assured it can be read correctly by the systems that receive it. But, most storefront companies have set themselves up such that users must still handle images manually, often on an on-line only basis. This is a very cumbersome way to get things done.


For example, in the case of my parents’ online storefront shop at http://www.bdunique.com, I was able to load 600+ records plus images in a single day. However, I still had to add the images manually which was a tedious and time-consuming process requiring some 18 hours of hands-on work. If this system had been UIEE 2.44-compliant, the job would have been done all at once, completely automatically. The same is true for any company offering storefronts.


In the broader sense, adopting the UIEE 2.44 specification solves this problem completely for all venues requiring simultaneous image and text management. Images can be bundled with text and HTML and shipped directly in a single UIEE file for import into such venues.


How likely is it that storefronts will accept UIEE files?


Some of them already do. The widespread adoption of UIEE makes it possible for companies already receiving old-format UIEE files to view a transition to UIEE 2.44 as a relatively easy “upgrade” rather than a fundamental “change” (something companies are loath to do). It is my intention to do my very best to urge companies to adopt it as a standard means of receiving structured records. So far, the response has been positive.


Remember, the capability to upload records to a storefront is presently more a function of being able to export records in a compatible format and then use whatever built-in upload capabilities the storefront system provides, rather than being able to upload records directly and programmatically from within an application like BookWriter. There will be a transitional period, no avoiding it. Again, this is why I’m hoping that the adoption of UIEE 2.44 will happen as quickly as possible — it will solve dozens of such problems.


The UIEE update is very exciting! I immediately think of standardization of data exchange on all online sales venues. This could have very significant implications for all booksellers, collectibles dealers, auction companies and businesses across the board. Do you think it’s likely to be adopted as you hope?


Yes, I do. Again, the only real objection will be the usual resistance to change. There are no practical reasons not to adopt it. And, keep in mind that the UIEE specification may have been something I created, but it is simply intellectual property and TAS Software has given it away. We’ve done this by placing the entire specification on-line at http://www.uiee.com for anyone and everyone to make use of, without fees or obligation. If someone wants something changed or updated, then all they have to do is contact us, we’ll go over it, and if it has merit, we’ll add it to the spec. The only strong request is that anyone making use of the UIEE 2.44 format adhere to it. Proprietary flavors of UIEE are not allowed. That said, we’re just the custodians and we have no direct way to enforce compliance.


Are you working alone?


No, we’ve got some excellent people helping out and users will be quite satisfied with the level of support we’re providing. Old-time booksellers would recognize some of the people involved. We’re not novices.


What are your goals? What are you trying to accomplish?


Well, I’d have to say the goal is to be successful making and supporting the tools it takes for booksellers to be successful. It’s not so much a noble goal as a practical one. If you read the UIEE spec, you’ll see language that speaks to the idea that part of the underlying philosophy for creating UIEE in the first place is that people should not have to be software engineers to exchange data with one another or with other computer systems. I feel very strongly about this. There is a LOT of enthusiasm out there for a simpler, more efficient way for users to manage their data. Anyone who’s ever worked through a standard retail or auction venue knows that uploading separate images and then trying to relate them online with separate records is a very cumbersome process, and it doesn’t always work. Yet this has become the norm. UIEE 2.44 completely does away with all that.


Will companies see this as a threat rather than a boon?


Some may. But I also think that any company offering their dealers the convenience and efficiency of receiving both text and images simultaneously is going to have a huge competitive advantage over companies that don’t. I attribute much of the success of companies like AuctionWatch and Andale to their ability to make life simpler for their users in this respect. We want the same thing for booksellers without the proprietary locks, and this seemed the best way to go about it.


Bottom line is, this is a perfectly natural evolution. As time goes on, images are going to become more, not less, important to the sale. I suspect most people who’ve ever auctioned or bid on eBay already know that. I’ve been very gratified by the support we’ve received so far and, as I mentioned, the upgrade process is already underway.


If we can return to BookWriter for a moment, you said it provided “multi-destination upload capabilities,” but I’m not sure if that’s a one-touch procedure. Does BookWriter have a one-touch upload feature, i.e., can users put in the parameters and/or requirements of which databases/sites/auctions they want to upload to and either do them all at once or pick and choose which to do when? Or if you can choose to upload only to all book databases you list with at once, or only to auctions, or both at the same time, or???.


The intent is to have a one-touch upload capability in place at release time, but this is a feature that is partly dependent upon the listing services to be implemented. Time constraints may prevent all of the desired venues from appearing initially on the distribution list, so I can’t say for certain how comprehensive a list of destinations will be offered in the first release. And of course, I’m behind schedule as usual.


Have you already arranged this with any databases or auction services, or storefront services?


I don’t want to appear evasive, but I’d prefer to wait until the upload circuits are 100% established to disclose this. As I mentioned, arrangements are being made now. Several services have already requested upload capabilities and I’ve received positive responses from those whom we have contacted directly.

Does each auction and storefront service, like Yahoo, Amazon and eBay, have totally different programming and requirements in-house? Or are they pretty similar?


They are all completely different. I would venture to say that you would find few, if any, programmatic similarities, even among those who use the same off-the-shelf packages like MySQL and Oracle. Every company codes their programs to meet their specific business needs within the framework of the hardware set up to run the programs. No two systems are precisely the same and every program is different. It’s the standards for exchanging data that ultimately matter most, and a good standard is what’s been missing.


You haven’t mentioned accounting and report capabilities in BookWriter — will those features be part of the package? Which and what, if so?


The program provides some good reporting capabilities and there is a Reports menu. Users can also export selected data directly in Excel format for loading into spreadsheets. We’re looking at adding Quicken and QuickBooks exports as well.


Can you tell us what the purchase price of BookWriter will be?


There will be a $124.95 introductory price, which will be available only until December 31, 2002. As I mentioned, we’re still assembling the complete feature set. Some of the add-on capabilities are very powerful and require our purchasing runtime licenses from other companies, so I can’t really quote prices beyond the introductory period at this point.


Is there one version only of BookWriter?


There will actually be several versions of BookWriter, but they will not be incremental. For example, there will be a version of BookWriter that works directly with HomeBase database files. However, its functionality is not much different than the version we’re preparing to release that works in its own native database format.


What about multiple users? Can a user buy BookWriter and use it on more than one computer, or do they need to buy (or be licensed) for the software for each computer it is used on? Can a user copy it onto their laptop, as another example, as well as using it on their desktop?


BookWriter will be licensed for use by a single user on a single computer. The license provides for the same user to install the program on several different computers, providing only one at a time is in use. We haven’t yet established a network license policy.


Are you going to issue CDs, or will it only be downloaded from your site?


The plan right now is to offer the software as a downloadable program and on CD-ROM. BookWriter contains a built-in context-sensitive help system, so no on-line connection is required for help. I’m very pleased with the Help system — I think users will like it.


Will there will a printed manual, or online help only? Any reference cards, like days-of-old (I used to love those things!)?


A bound, printed manual will be available at nominal cost. A reference card is a good idea, but frankly, I doubt it would be of much use. This is a very easy program to operate and the context-sensitive Help system is really all you need. Like most production software, once you learn the half-dozen things you really need to know to quickly get your work done, you can safely ignore the rest.


Re customer service: Phone, email, live chat help, all of these, none of these, or??


E-mail support is provided free of charge. Telephone and on-site technical support will be available, but we’re still working through the details of precisely what support levels we’ll be offering. We have some very good people working with us on this, and we need to plan this carefully to satisfy everyone’s needs.


What existing formats can be used to transfer data into BookWriter? Will this be an automatic thing, or are you going to develop it as you go, by working with each format as it comes to you and preserving that developed capability for future uploads of that format? Is this all done on your end, or does the user have to work with you on changing any data fields around, etc.? I assume formats other than UIEE can be imported? And what about exports? Will anything other than UIEE be needed, actually?


The short answer to these questions is that BookWriter initially will be able to import and export to and from any UIEE or delimited file. Users will be able to map fields as they so choose. Excel formats will also be supported for uploading to venues currently requiring this type of file. As the adoption of UIEE 2.44 develops, more direct upload circuits will be added. Obviously, we hope all of them will upgrade their file receiving and processing systems for UIEE-2.44 compliance, but I’m not blind to the realities and I’m sure some companies will be slow to adopt. However, I must again stress that BookWriter is merely the first program, not the only program that will be UIEE-2.44 compliant, so I won’t be the only one driving the transition.


You talked about images; could you explain a bit more on this? Will BookWriter provide image editing capabilities?


The initial release will rely on the user to prepare their images as they prefer before attaching them to records and sequencing for upload. We’re considering offering an Image Editor as an add-on, but no firm decision has been made at this time.


For non-programmers like me, will there be any built-in HTML code phrases or help for users (sort of a fill-in-the-blanks in a code sequence type of thing)?


BookWriter works on the basis of templates, into which your data is intelligently inserted. The templates can be edited as desired using any standard HTML editor (such as Microsoft FrontPage). We’re considering offering an HTML Editor as an add-on, but as is the case with the other add-ons I’ve mentioned, we’ve made no firm decision yet.


Which operating systems can BookWriter be used with?


BookWriter runs on all flavors of Microsoft 32-bit Windows operating systems (95, 98, 2000, NT, XP, and ME). There is presently no plan to produce a Mac version. Mac users can use any of several inexpensive Windows O/S emulators to run the software.


What about collectors needing software? Any thoughts of providing software specifically geared to that market, just for maintaining info on collections not to be sold? I see and get lots of inquiries on this.


There is no “collector-only” version planned at this time, though we may consider creating one. Given the low purchase cost and the scope of capabilities the program provides, I don’t think it would be wise for me to try to second-guess how someone might or might not want to make use of them. A Swiss Army Knife without a screwdriver blade doesn’t cost much less than a knife without one, but it’s a lot less useful.


There are probably thousands of people still using BookMaster, Record Manager, and BookMate. Will they have to import their records into BookWriter and will they be able to continue to use their old software?


Users of BookMate, Record Manager and BookMaster won’t have to import their records because BookWriter will work directly with existing databases from my older programs. But, BookWriter adds a lot of new information to the old database formats and, naturally, the old software won’t be aware of it. There are cases where this can potentially cause problems. So the short answer is: Yes, users can continue to use their old software, but we recommend migrating to the new format.


What about HomeBase users?


There is a plan to produce a version of BookWriter that works directly with HomeBase files, if possible. If this is produced, HomeBase users won’t have to import their records either — BookWriter will work directly with their existing HomeBase database file. There are many advantages to this, not the least of which are simplicity and complete freedom of usage. However, ABE has deviated from the field standards that existed previously and there are some incompatibilities to be addressed. This is not a trivial issue.


What about other database formats?


For users of other book inventory software, BookWriter can import records using any of several file formats including UIEE, comma- or tab-delimited, flat ASCII and others. BookWriter provides field-mapping capabilities to suit individual needs.


What do you do when you’re not programming?


My wife Niki and I both love animals and enjoy the outdoors. She’s one of the real people who can “talk to the animals.” We have a 50-acre farm in upstate New York, well away from the cities. It is a truly beautiful area. We hope to build a new house, if and when we can afford it.



I heard you have a flock of sheep. What’s that all about?


Niki is a master handspinner and we have a flock of Black Welsh Mountain Sheep, a very rare breed. They retain many of the wild characteristics of their ancestors. They’re multi-purpose and disease-resistant and they produce good fleece and meat. They’re affectionate and just love to have their ears scratched. We have 47 now, including a few off-breed animals we received as orphans, whom we refer to as “The Office Sheep” because that’s where they spent most of their childhoods — under my desk and in Niki’s lap while we worked at our computers.


I’m a guitarist, and I produce my own recordings. For recreation, more than anything in the world I love to fish! Niki and I go way up north into Quebec where there’s no electricity, no phones, no e-mail, and few people. We’ve done it nearly every year since we were married, and I did it nearly every year with my family before that. I have a very good memory, but my mother likes to pull my leg by asking me why I don’t remember my first fishing trip — the reason being that she was pregnant and I hadn’t been born yet.


I’m also a NAPWDA certified bloodhound handler and Niki and I have both worked cooperatively with local law enforcement and search and rescue groups trailing missing persons. Not every trail had a happy ending, but our hounds never failed to find their quarry. Although some of them have passed on, they’ll always occupy a special place in my heart. I’m also a certified Smoke Diver for our local volunteer fire department. Although I’m now on the inactive roles, I do sometimes miss the action. During Interloc days, Dick Weatherford used to call daily to chat — and to make sure I was still alive!



Thank you so much for this opportunity to interview you, Tom!


On the contrary, thank you for giving me the opportunity to talk. I really enjoyed it!


If you’re interested in learning more about BookWriter, please contact Tom directly at tsawyer@rochester.rr.com

 
bottom of page