Q&A: My interview with Microsoft Encarta developer lead
Amy Raby, developer and then the development manager of the Microsoft Encarta team
Q: Who came up with the dialogue in MindMaze?
Raby: “MindMaze was always contracted out. The original version was written, I believe, in Visual Basic or some other interpreted language. It had performance problems. All the rest of Encarta was written in C++, with some small portions written in assembly to make them a little extra zippy. We on the development team were dissatisfied with MindMaze’s performance, which did not meet the standard of the rest of the product. But at the time, our development team (programmers) was just a handful of people, and we didn’t have the resources to write MindMaze in-house. So, it was written by a vendor. I’m not sure who wrote the questions. Probably our editorial team.”
“After the original Encarta came out (1993 version), Bill Gates spent some time trying it out and sent us an in-house email with his critiques. Most of the contents of this email I have forgotten, but I remember one part clearly. He complained about MindMaze’s performance, saying something like, “This is the slowest thing I have ever seen!!” You’d think we on the development team would be mortified. But instead, we were dancing in the aisles. Bill Gates’s singling out that problem meant that in the next version, we would have to fix it, and that was something we on the dev team had desperately wanted to do.”
“So MindMaze got a rewrite! However, it still was not done in-house. We still didn’t have the programming resources. It was contracted out, but I think this time it was written in C++ or at least something with better performance than before.”
Q: Encarta’s designed with illustrations, animations, & maps in mind. What did that process look like?
Raby: “The multimedia part of the encyclopedia — maps, images, illustrations, videos — presented unique challenges. One was that we had to fit on a CD-ROM. Our editorial team always wanted more media than we had room for. A big piece of Encarta was the two internal engines, Shadowfax and Media View, which together took all the media files, as well as the text, and compressed them as tightly as possible into a single file that had to fit on the CD. Creating that file was a long, slow process, so if anything was wrong — say, a media file was missing — we couldn’t just quickly re-run it to fix the problem. That missing image would have to wait for the next build.”
“Editorial requested media for their articles, and then we had a team of media producers who created and/or acquired what the editors wanted. An internal tool linked media to articles. We also had an in-house cartographer, Whit Alexander (he would go on to co-create the board game Cranium), who created our maps.”
Q: Can you talk about the color palette that Encarta used? I read that it provided optimal image quality with minimal palette flashing.
Raby: “Palettes! The word will be forever linked in my brain to Bert Kleewein. Palettes were a struggle in early versions of Encarta, and when Bert joined the team, he tackled it head-on and rewrote all our palette code, largely fixing the issues — although whenever a new palette bug showed up, he’d grumble. Palettes were challenging in Encarta because of fundamental limitations of the technology.”
“We could only display 255 colors at a time, but you could choose which 255 colors you wanted. For an image of the ocean, maybe you want 255 shades of blue. So, you set your palette to all blues. Now you can only display variations of blue — and then you need to display a forest image. You can’t render a forest with only blues. The system will do its best, choosing the closest match to each actual color in the forest scene. But you’ll still end up with blue trees. Now say you switch the palette to one with some greens and browns to fit your forest image. That will cause a palette flash. The forest image will switch to appropriate colors and the ocean scene will be re-rendered in greens and browns.”
“Palette flashes are undesirable. We especially don’t want the basic Encarta UI and text to be flashing, so we would always reserve 32 colors or so as Encarta’s basic palette. Those colors would never change. I think we might have actually produced our images to include that basic palette at the beginning. If not, Bert’s code would have modified each image’s palette to put those 32 colors at the beginning, so they never changed and thus never flashed. Each image has its own palette attached to it — greens and browns for forests, blues for oceans, etc. As you scroll through the article, different images appear onscreen, and Bert’s code was responsible for shifting the palette as necessary to render each one with as true a color scheme as possible.”
Q: What was the best part of working on Encarta?
Raby: “The best part of working on Encarta was having the security and resources of a big company behind us, but feeling like we were working in a start-up, as we had almost total independence and control of the product. Because the team was relatively small, especially in the beginning, every single person made a big impact on the product. Ideas we came up with could become part of Encarta if we could persuade the rest of the team.
Q: What’s your favorite feature?
Raby: “My favorite feature was our search capability, called the Pinpointer from (I believe) Encarta 1995 on. Search in Encarta was sophisticated for its day. The entire text of the product was indexed during our build process by a piece of internal software called Media View. In that index, we stored every word found in the text along with a bit-array of flags that said which articles it appeared in. That is, in a 32-bit integer, we used each bit as a flag. If true, that word appeared in the article; if false, it didn’t appear. So when you searched on a word, Media View would look up the index entry for that word, grab the bit-array, and then it was a simple bit operation to reduce the list of articles to just those that contained that word. Bitwise operations are fast, and with 32 flags stored in each integer, we could whittle down that list almost instantaneously. Whether you searched on “Istanbul,” which might be found in only a dozen or so articles, or the word “people,” which might appear in thousands, we could near-instantly give you every article in which that word appeared.”
Q: What’s something we might not know about Encarta?
Raby: “I can tell you a story about a technology conflict with one of our competitors. I don’t remember which competitor this was. Might have been World Book, might have been Compton’s. Our testers would routinely install both Encarta and one or more of our competitors on the same machine to make sure they played together nicely. And they discovered that when they installed this competitor first, on a clean machine, and then installed Encarta, some of Encarta’s multimedia did not work. However, if you took the same clean machine and installed Encarta first, then the competitor, everything worked fine.”
“Lots of diagnosis followed. Both Encarta and the competitor were using a piece of 3rd-party software to render some types of multimedia. I think it was Adobe Flash Player or a similar piece of software. Both Encarta and the competitor would install Flash if it wasn’t already on the user’s computer during their setup process.”
“It turned out that the competitor was installing it incorrectly. As it happened, their incorrect installation only broke it in certain ways, and they didn’t use it in those ways, so the incorrect installation did not break anything in their product, just in ours. This was around the time of the Internet Explorer being preinstalled with Windows controversy. We didn’t want to be the source of any bad press for Microsoft that could result from our messing around with software installed by another company, especially a competitor. And yet their installation was simply broken and needed to be fixed for our product to work. We contacted the company that owned Flash (I can’t remember if it was Adobe or somebody else) and had them independently verify that our competitor’s installation was faulty. They verified it and gave us explicit permission to fix it if we found it that way on a user’s computer. So we added code to our setup to look for a faulty Flash installation, and if we found it, quietly repair it. I don’t think anyone ever found out, not that we’d done anything untoward.”
Q: What’s something you learned from working on Encarta that you still think about today?
Raby: “One experience working on Encarta that made a particular impression on me was listening in on tech-support calls. I know many tech companies farm out their tech support these days, but when we were making Encarta, Microsoft’s tech support was located in another building just a few miles away from the development team. It was important to us to minimize the need for tech support. Our product was relatively inexpensive, and if a user had a problem and called tech support, the cost of that call — and it was charged back to us, even though it was an internal expense — would wipe out all the profit on that unit. So as developers, and program managers, and testers, it was important that we understand the kinds of problems people had and take them into account as we developed future versions.”
“I remember listening in on some calls and thinking, about the support professionals, “These are the most patient people in the world.” I listened to them stay completely calm and even-keeled even when customers got frustrated or angry or didn’t seem to understand the instructions. We would also sit in, sometimes, in usability studies, where people came into a lab and used our product for the first time, and things that seemed obvious to us about the way the product worked turned out not to be obvious at all. It has stuck with me that you cannot know how your product is being used in the real world and what problems people might have without getting outside your bubble to observe and listen to real-world users.”
