Be Newsletter

Volume II, Issue 47; November 25, 1998

Table of Contents

• BE ENGINEERING INSIGHTS: Comdex Report, by Bob Herold
• BE ENGINEERING INSIGHTS: The Art of Prototyping, by Tim Martin
• DEVELOPERS' WORKSHOP: Sweet Mystery of Life, by Doug Fulton
• Giving Thanks, By Jean-Louis Gassée

After spending two and a half days at Comdex manning the BeOS booth, returning to Be's offices has provided a chance to reflect on the experience.

I am not a Comdex connoisseur -- for this I relied on the cab drivers, who all offered hard evidence (wait times at the airport for fares, traffic congestion, etc.) that it was less crowded this year than in years past. Several big players -- Netscape, IBM, Intel -- chose to reduce or eliminate their presence this year. Perhaps Comdex has evolved into something less useful to both vendors and attendees.

Comdex, even if it has passed its apex as the Woodstock of the US computer industry, is nonetheless huge. We were on the least desirable floor of the least desirable event hall, and still the scale was mind-boggling. The variety of vendors addressing all possible angles of the PC ecosystem reinforced the wisdom of Be's decision to enter the Intel architecture fray. Nothing is single-sourced here. From processors, chip sets and motherboards, to mousepads, keyboard locks, and screen visors, there is competition in pricing, quality, features, service, and availability. It is a fertile field for planting our new OS seeds.

The booth traffic was good Monday, but Tuesday and Wednesday it was packed. Perhaps everyone cruised the main hall Monday, and Tuesday they migrated to the hinterlands. On Wednesday we started to get referral visitors, where a friend or associate had seen our booth and told someone to check it out. Word of mouth is still high quality advertising.

We had several stations dedicated to showing apps. It was great to direct visitors to see applications that demonstrate the substance behind our marketing message (video and audio editing on commodity hardware for under $2000). When visitors asked if we had productivity tools, we had more stations addressing those needs. Apps will be the engine that pulls this train.

We announced that Hitachi will be bundling the BeOS on PCs in Japan. They are producing an elegant, compact box with a 400 Mhz Pentium II, and a crisp, flat panel LCD display. It will dual-boot to either preinstalled OS. An exciting announcement, which might explain booth visits from other Japanese PC vendors eager to see what was going on.

Response to the BeOS was mostly positive, and not just because we are an alternative to today's dominant OS. Most visitors had never seen the BeOS or heard of Be. A few thought we had gone out of business when Apple decided to buy a different OS. Almost all visitors were excited to see the OS running on familiar hardware doing unfamiliar things. They were open to running more than one OS on their systems. I think we can thank the recent surge of Linux interest for raising multi-OS awareness in the industry.

There were the usual entertaining discussions from knowledgeable geeks criticizing this or that implementation decision. These verbal aerobics are always welcome, as we often learn something useful for the next release, and we also see what matters and what doesn't. My favorite was "why did we pick 256k stack size?" 512k seemed too big, and 128k seemed too small...

Most encouraging were the number of reseller inquiries -- people who run chains of computer stores seeing potential for making some money by adding the BeOS to their product line. We need to cultivate these relationships -- these folks will be on the front lines selling customers on the benefits of the BeOS environment.

All the announcements from application developers and hardware OEMs, as well as introducing R4 itself, left me the most excited I have been about Be. The enormity of the show made me realize we have a lot of work ahead to build the case for BeOS being at the center of a profitable business. We have an OS that lays the technical foundation. Now we can ship apps that solve real problems or provide useful benefits that have customers reaching for their credit cards. We need ways to make customers aware of what the BeOS can do for them, and we need to make it easy for them to buy the BeOS and applications. Many of these pieces are falling into place, which is immensely exciting. Lets get back to work!

A brief introduction: My name is Tim Martin, the only Be employee with a bachelor's degree in Industrial Design. What, you might ask, does industrial design have to do with computer software? As a designer, my focus is on understanding the interaction between people and products and making it better. From a design viewpoint, creating good software isn't all that different from creating a good power drill or a cool dish rack.

Interaction design isn't about what your product looks like; rather, it's about the experience you build for users. Interface (the visual appearance of the product) is part of what creates this experience. More important, though, is the way the product works and the concepts on which it is built. While a user develops an understanding of interaction, work flow, and concept model only after days, weeks, and months of using the product, these aspects shouldn't be neglected in favor of making a product look superficially "cooler."

Today, I'll be talking about the methods and value of prototyping in software design. Later I'll follow this up with an article about breaking boundaries in software design. Feel free to e-mail me to request subjects for future articles, but for now let's take on awareness and understanding of prototyping, and how it can help all BeOS developers make great software.

What is prototyping?

Prototyping is making a pencil sketch, a mock screenshot, or a simple program. It's a combination of these steps that creates something that allows you analyze and evaluate design decisions. It's a way to make sure you're doing the right thing and headed in the right direction. It can help you figure out what application to make and what the application does, how it does it, and what it looks like.

Why prototype?

You prototype for the same reason that you compile and run your application more then once while writing it. You can never be sure that you've make the correct programming decisions until you compile your code and see the results. How often have you forgotten a close brace or a semicolon? Worse yet, have you forgotten to declare variables or free memory when you were done with it, or had an off-by-one error? These are simple (but common) engineering mistakes, which require constant testing to make sure that an application is working properly from a technical standpoint.

When we make software though, there are many mistakes that have nothing to do with programming errors, but rather with the usability and usefulness of the application itself. What good is a bug-free application that doesn't present the right information to the user in a useful way? I can't even begin to count the perfectly smooth-running applications that were useless because they made no sense, displayed the wrong information, or just plain didn't fulfill a real need.

Prototyping is one way we have to make sure we're on track with not only the visuals of the product, but also the interaction and underlying concept model.

Can I do this alone?

It's an excellent idea to have a trained professional designer with a passion for human-computer interaction. Unfortunately, they aren't always just hanging out at the 7-Eleven. The next best thing, if you're doing this work yourself, is to learn something about how people use computers. Don't assume that because you use a computer, you automatically understand how people use computers!

Even if you're doing this alone, you'll still benefit greatly from the input of others. Find some people who fit your user profile, people you think would either want or need to use your software. Find some additional people who aren't programmers to bounce ideas off of. If you surround yourself only with programmers, chances are you'll end up with software that is usable only by programmers. Unless that's what you want, you need to orient yourself toward users.

How do I start?

First, get a pencil and some paper. This may seem retro, but nothing can replace the time-tested design skill of paper prototyping. It's impossible to test a design solution only in your mind, without so much as a mark on paper. So rather than write code you might eventually have to abandon, start simply.

Let's assume you have an idea for some software, and a good one at that. You think that person "X" will not only want to do thing "Y," but that they'll pay you to help them. It's good to keep in mind that the purpose of software is usually to help someone do something useful. Games don't seem to fit this rule, but many games simulate some sort of useful task a player must successfully accomplish in order to save the world. With this in mind, you should start listing the functions that are necessary to your application, when they are necessary, and what accompanying information must be displayed and when. Don't forget who your main users are; it's easy to go overboard in this phase and jam-pack your software full of features and displays and dialogs brimming with information. This generally results in hard-to-use bloatware.

Start laying out maps to show how a user will accomplish the types of tasks your application is intended for, to make sure the most often used features aren't too hard to get to. It pays to keep in mind what's important to users, because often they're not the same things that are important to you! Don't forget to ask your friends what they think; stopping people in the street isn't a bad idea either.

Most problems have more than one solution and for the most part there's no one right choice. There are certainly some wrong ones though. One advantage to prototyping is that you can explore different design directions and variations on them without excessive time penalties. Many features and functions in software can accomplish a task in more than one way; others deliberately have only one way of doing it. These decisions always depend on the situation and circumstances surrounding each case, yet the answer may not always be clear. By mapping out and making mock-ups of a few different methods you can evaluate which works better for you and your users both. Try not to be too inhibited by what you think you can or can't do. In the world of programming there are so many ways to do things that you shouldn't let constraints box you into a decision too early in in your process.

Eventually the direction that seems right will emerge from the pack for many reasons. Beware: people may not pick the proper choice consciously. Perhaps the variations you present are visually unpleasing, but if it's clear that the "ugly" direction is the one that's the most useful or presents the clearest communication, you can focus your efforts on making variations on that direction which address the visual concerns. Continuously reviewing your improvements and showing them to other people helps refine the product to the highest degree possible. You can't design products in isolation.

By now you can see that narrowing the path helps you find the direction and proper variations that lead to a pleasing and successful product. But all things must reach an end right?

When does it all stop?

This is a tricky question... there's always room for improvement, right? Think twice about your improvements, though. Adding features is the most commonly thought of method for improving software, yet is often the least effective. For many years, the feature list of a program was its selling point. However, it turns out that what people want is smooth-running, fast, efficient software that does exactly what they need. Most users would prefer a few programs that work well together rather than one huge program that does everything.

Design is an iterative process of concept development, refinement, prototyping, testing, and polishing. You should never be afraid to go back to your initial stages and take a different direction, which is why prototyping (and rapid prototyping especially) can be important. It's better to make several prototypes and abandon the bad choices, rather than build layer upon layer of corrections and additions.

Today's bit of universal design wisdom?

Prototyping lets you finish a project with a clean, well thought out product. You waste much less time making multiple versions and cause less frustration to your users by not treating them like Guinea pigs. A lot of thought and work always needs to be put into making the software work to the users advantage (and the earlier the better). Simplicity is a relative term so please remember that "simple" doesn't always mean "fast" or "easy." Software that is truly simple to use was undoubtedly difficult and time consuming to design. The reward of prototyping is having a product that is useful to its users -- for its intended purpose -- and that creates an experience that users prefer over other methods.

"Developers' Workshop" is a weekly feature that provides answers to our developers' questions, or topic requests. To submit a question, visit

http://www.be.com/developers/suggestion_box.html.

Q: Release 4 is all but out the door, on the truck, in the mail, over the rainbow, and through the woods to grandmother's house in the valley beyond the shadow of a doubt. When Grandma unpacks the CD, tosses a chicken, and installs R4, what will she find in the on-line BeBook?

- Naughty Marietta
Ovaltine, Missouri

A: Near the release finish line there's a stack of composition books upon which sit the tech doc writers. As each engineer sprints past, a writer grabs a book, shouts out a few unheard questions, puts finger to mouth and starts scribbling. The game, among the writers, is to pull out the books without upsetting the stack, although it's never been clear just what is forfeited personally by the loser, since the lot of them end up in a whining pile of ink and white out. It's a sad little ritual and probably should be left on the shelf with other superstitious ceremonies such as the chicken toss, taxes, mumblety-peg, and baptism, but it's how the ancients did it and, as part of that history, I'm not going to jigger tradition. Unfortunately, the rite has its dark side: Sorting the pages and blotting the spilled ink takes time. And although we've used a cunningly sequential numbering system to grease the collation, by the time we look up, the door has shut and we're left outside with the leaves clutched in our little mitts while the rest of the engineering team is bathing in milk, gorging on figs, and trying on each others' clothes. The perks of a job well done.

Now I'll answer your question: Not enough. Call it too many cooks and not enough napkins, call it sloth and ennui, call it the kernel team kidnapping a third of our technical writers, or call it the way of the world, all flesh, and the devil -- documentation always lags behind that other stuff, just as marketing jumps on your lap before you've sat down.

Not enough, but not nothing: Open your BeBook to chapter Media Kit and you'll find a few thousand nouns and verbs rubbing up against each other like kittens tied to your ankles. And there are any number of little tweaks and twiddles that improve the book technically and stylistically. Of the latter, the documentation now avoids anacoluthon -- do we need examples of this? Also, we're in the process of unstuffing the priggish and prissy vocabulary that accumulates over time: Brussels sprouts words such as "tantamount to" and "veritable" are replaced by the brown rice bland but digestible "almost".

But that's all just CD between you and me. The real action takes place on the web site. If you're a developer, the first thing you should do when you receive your Release 4 CD is throw away the BeBook that you just installed on your hard disk and replace it with the one on the Be web site. Put your thumb in www.be.com/documentation and fish around a bit. Long lost links, such as the appendix that lists the Be message formats, the keyboard layout information, and (god help me I toss the chicken far enough) the chapter-by-chapter index lie simpering in submission.

A few weeks back, I made some waving motion that could have been mistaken for something that might look like a promise that the UI guidelines would make it on the Release 4 CD. (Actually, what I said was "We're going to try to get the UI Guidelines ... on the R4 CD. But if they don't quite make it, they'll be posted to the web site soon thereafter.") Now that the fellow with the shaved back and the nasty look on his face is no longer holding my head under water, I can glub that we didn't quite make it to the CD but we'll hold to our word that the UI guidelines will start to appear in the next few weeks on the web site. I promise, so help me Nelson Eddy.

First, congratulations and thanks to the sharp-eyed and gentle-penned readers who spotted a lapsus abaci, a slip of the exponent, in my last column. Many wrote to congratulate us on achieving a billion dollar valuation. Some even asked how we managed to find investors willing to buy into the company at such a valuation.

The humbling secret is a typo. I dropped a zero in stating Be's worth compared to Microsoft's market cap. I should have written that our investors value our company at between 1/2000th and 1/3000th of what Wall Street says Bill's company is worth -- not 1/200th.

We're back from Comdex and, by the time you reach my column you'll already have seen Bob Herold's report. It was a productive week in Vegas, following a great one in Tokyo. My thanks go to all who made it possible, from Sylvie Pelaprat, our PR & Marcom Manager, who masterminded and delivered the event; to the engineering team who delivered R4; to BeOS developers who showed what they could do with our platform; to our friends at Intel who came out and supported us; and to all who took booth duty seriously and graciously.

I usually come back from trade shows feeling good after meeting users, developers, and business partners in rapid succession -- it's a concentrated reality check. Returning from Comdex, I feel better than ever about the nature and size of the opportunity ahead of us. No slam dunk, but readier acceptance of "other than Microsoft" ideas. Combined with the significant progress made with Release 4, and the emergence of BeOS applications, it all adds up to a sense of critical mass in the making.

The last three words signify. This is not a time to make premature or extravagant claims, but rather to say that we're grateful for the increasing support from our key constituencies.

And speaking of thanks, a special word for Valerie Peyre, who left us to return to the Old Country. She came to Be in 1995, right after the Agenda Conference, recommended by Dan Dahle, a Be alumnus now at Intel. One of her first tasks was to start this newsletter, which she did, cajoling and goading contributors into delivering copy week after week. She quickly demonstrated the ability to shoulder more responsibilities and, before she left, was in charge of Developer Programs. She'll be missed and, as she returns to France we hope she carries with her a little bit of the gratitude her skills and dedication have created. And we secretly hope she'll miss the crazy Silicon Valley soon enough.

Happy Thanksgiving!