339 lines
27 KiB
HTML
339 lines
27 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 3: 1998</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume3.html" title="Volume 3: 1998" /><link rel="prev" href="Issue3-46.html" title="Issue 3-46, November 18, 1998" /><link rel="next" href="Issue3-48.html" title="Issue 3-48, December 2, 1998" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue3-46.html" title="Issue 3-46, November 18, 1998"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume3.html" title="Volume 3: 1998"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue3-48.html" title="Issue 3-48, December 2, 1998"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 3: 1998</div></div><div id="headerB">Prev: <a href="Issue3-46.html">Issue 3-46, November 18, 1998</a> Up: <a href="volume3.html">Volume 3: 1998</a> Next: <a href="Issue3-48.html">Issue 3-48, December 2, 1998</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue3-47"></a>Issue 3-47, November 25, 1998</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering3-47"></a>Be Engineering Insights: Comdex Report</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Bob</span> <span class="surname">Herold</span></span></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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
|
||
<acronym class="acronym" title="Liquid Crystal Display">LCD</acronym>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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...
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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!
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering3-47-2"></a>Be Engineering Insights: The Art of Prototyping</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Tim</span> <span class="surname">Martin</span></span></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
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."
|
||
</p><p>
|
||
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.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id761193"></a>What is prototyping?</h3></div></div></div><p>
|
||
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.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id761211"></a>Why prototype?</h3></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id761239"></a>Can I do this alone?</h3></div></div></div><p>
|
||
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!
|
||
</p><p>
|
||
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.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id761269"></a>How do I start?</h3></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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?
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id761312"></a>When does it all stop?</h3></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id761334"></a>Today's bit of universal design wisdom?</h3></div></div></div><p>
|
||
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.
|
||
</p></div></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="DevWorkshop3-47"></a>Developers' Workshop: Sweet Mystery of Life</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Doug</span> <span class="surname">Fulton</span></span></div></div></div><div class="qandaset"><table border="0" summary="Q and A Set"><col align="left" width="1%" /><tbody><tr class="question"><td><a id="id761381"></a><a id="id761384"></a>Q:</td><td><p>
|
||
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?
|
||
</p><p>
|
||
- Naughty Marietta<br />
|
||
Ovaltine, Missouri
|
||
</p></td></tr><tr class="answer"><td align="left" valign="top">A:</td><td align="left" valign="top"><p>
|
||
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.
|
||
</p></td></tr></tbody></table></div><p>
|
||
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.
|
||
</p><p>
|
||
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".
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee3-47"></a>Giving Thanks</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
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.
|
||
</p><p>
|
||
Happy Thanksgiving!
|
||
</p></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue3-46.html">Issue 3-46, November 18, 1998</a> Up: <a href="volume3.html">Volume 3: 1998</a> Next: <a href="Issue3-48.html">Issue 3-48, December 2, 1998</a> </div><div id="footerB"><div id="footerBL"><a href="Issue3-46.html" title="Issue 3-46, November 18, 1998"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume3.html" title="Volume 3: 1998"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue3-48.html" title="Issue 3-48, December 2, 1998"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|