App/Interface Kit: Darkwyrm and his merry band have been laboring away furiously. As you have all read on his website, he believes that the hardest parts of the app_server are now complete. A lot of things are coming together. There is still a good amount of work, and a lot of it is higher level than in other kits, so this is a good place for experienced C++ people to help out.

Game Kit: Very little progress here. This is mostly intentional. There are really two parts to the Game Kit - the Video and the Audio. Marcus has already claimed the Audio side, once the Media Kit is done. The Video side really needs the app_server stuff to be more complete before we can go too far. Don't worry about the lack of progress here. This is not a big deal at all.

Media Kit: We have had a few alpha releases. Marcus is busy right now, but is nearly done with the new Codec API. Once that is done, we could use a few hands to go out and find codec source from other OSS projects and get the Media OS up to speed.

Preferences/Command Line Apps: Many are done, still a fair number to do. These are really pretty easy. If you have ever wanted to learn how to do GUI coding for BeOS, the Preferences apps are a good place to do so. If you are an old time Unix guy (like me), the command line apps are almost all ports from other OS's. Things like fold need to be brought over and built. I seriously thing that someone with a BSD source tree and an afternoon or two could put a big dent in the remaining command line apps.

Storage Kit: The Userland stuff is pretty well done. The kernel integration is preceding, but is (of course) slower and harder than the Userland side. As a side benefit, we now have UDF filesystem thanks to Tyler.

BFS: Development is pretty much done. There needs to be a lot of testing here. There are few (any?) known, reproducible bugs. Little activity here, since we don't need BFS for OpenBeOS quite yet.

Input Kit: Lots of real life issues here. This kit is at the fabled 95% status. It works with the app_server and R5 integration is nearly done. When reality subsides, look to see an alpha.

MIDI: Complete except for the synthesizer which Jerome is looking at now.

Printing: Another kit at the 95% status. Michael says that there are a few things left to do, but, again, real life intercedes. Things on the todo list include: Finish BPrintJob, improve the Preferences panel (maybe) and Epson Stylus driver (maybe). We have added a number of good printer drivers that BeOS didn't have before, so we are in good shape, here.

Translation Kit: Very little left here. Mike has been working on an image view that takes advantage of some of the features of certain graphics formats (like multiple page tiffs). We also are working on including a GIF translator. But this kit could ship today.

Kernel: Axel has been working like a maniac to get the kernel booting on PowerPC before this weekend. This has caused a lot of changes everywhere, which is good. The PPC work will also firm up some things on the x86 boot side. I hear that Thomas' IDE drivers are getting nearer to completion. While we can, technically, boot now, this work will make our boot process not depend on the "fake" bootfs. We will boot using files and BFS (the BeOS/normal way). There is lots of kernel work to do, but this is the tough stuff. If you work in embedded apps, have prior kernel experience or just the desire to beat your head against a firm object for hours, we could use you.

Networking: There is some bittersweet news in networking. Philippe has had a phenomenal real life opportunity that he has accepted. This leaves him little to no time for OpenBeOS. We thank him for his work and wish him nothing but the best with his new pursuits. Waldemar has been working hard on the PPP stack. But we still need 3 or 4 good networking folks. This, too, is kernel work - our networking stack does live in the kernel. If you are interested, please get with me - as I did with Midi when Paul left, I will take over networking until a team comes together.

ScreenSaver: Ah. My evil arch nemesis. Our first kit to show progress. Scott and Andrew are back on the job attacking the few features and bugs that still need work.

New Website: Kurtis estimates this at 92%. It is fully functional (and gorgeous). There are some minor graphical things to fix, plus we need to add some more content. But the database back end and PHP work is pretty much complete.

Birds of a Feather....

By not leaving the application's design simply up to the programmer's concept of the application is crucial to designing a good interface because one could say that developers are a breed unto themselves. Developers as a group utilize a vast body of knowledge that they understand or have the capacity to learn quickly. They speak a lingo of their own, as well. Simply by education are they automatically set apart from the majority of the user community as "experts," whether or not this is true for each individual developer. Understanding the terminology in an application is rarely a problem for a programmer nor is learning seemingly arbitrary actions to perform a task - learning an API or a command-line interface such as UNIX. However, most people have difficulty with these very same things and are more concerned with thoughts like "The big guy wants that projected sales report on his desk in the morning" as opposed to "Now what was that switch that piped cvs checkouts to stdout? Hmmm.... where's that man page?"Programmers have a distinct tendency to design applications which other programmers - but not necessarily others - use well. In some cases, the only person who can easily use such an application is the person who wrote it.

The lifestyle of a developer often dictates that he spend copious amounts of time talking to other developers and wondering why management just doesn't understand. Management exists to ensure that whatever products and/or services provided by the company will make the most money possible. Developers exist to create those products and services. Results are important, not the implementation. Which word processor a status report is written with Productive, Word, or OpenOffice's Writer makes little, if any, difference as long as it is written. From the manager's perspective, accounting for the probable case is more important than every possible case. Most developers are the exact opposite. Conflict often exists because each group tends to understand its own and not attempt to understand the other.

Target in Sight

Although it might seem somewhat strange to think of it in this manner, the computer industry is really a service industry. The products and services are bought by and ultimately for people. It is, thus, necessary to remain focused on who an application is meant for, such as developers, web page authors, graphic designers, etc. By recognizing and anticipating a person's strengths and weaknesses, it is possible to compensate for his weaknesses and make his strengths even stronger. In designing for only one or two people, the application is designed for a large number of users just like them. People is people.

When a company makes these decisions, it writes a couple fictional biographical profiles, often called 'personas.' These personas guide design to include the necessary functionality and display it in the proper way. The level of detail in each persona varies on the project and the design team. Often times a persona will include a name, age, personal interests, job title, relative level of computer literacy, and needs.

While the tendency of developers to write for developers is not a Bad Thing (TM), most often, we are targeting someone on the level of Joe User or Joe's Grandma. Joe User (sometimes condescendingly referred to as Joe Loser), is a stereotype for end-users which are not technically-oriented.

Since we're talking about Joe User, let's talk about him in a little more detail. Joe User works in a white-collar job and is not very technical. He probably is a teacher, parent, or a small business owner. Make no mistake, Joe is not a beginner, but he is no expert, either. He knows where the power button is, and knows that there is no 'Any' key. Normally, he can find the files he has created, but occasionally loses them in the file hierarchy and needs to ask one of his coworkers to help him find it. There are a lot of things about computers he just doesn't know much about, so he wants it to just work and let him get his work done and go home without unpaid overtime.

The above example is a rather general description of someone. While it could very well be used to guide design, it can only do so much because it is for a general context - no specific application. However, if we are to get some help from creating a persona, we need an application to which it is associated.

Example: Dox

Let us start with a fictional documentation system for OpenBeOS called Dox. Its goal is to provide the user with a powerful, yet relatively simple means to find content in text files of various sorts. One of its users is named Aaron. Aaron is a 43-year-old janitor who hasn't previously shown much interest in computers, but has had his curiosity piqued after his son gave him one of his older machines. The computer is a bit old, so it had BeOS installed on it to make best use of the hardware. Anyway, he finds it difficult to learn anything about it because he can't find any books on BeOS and doesn't really know where to start. His son told him that there are text files on the computer to help him, but Aaron can't find them himself. Most of the time, his son just makes a few icons on the desktop for him to click on for the programs he uses most.

Unfortunately, we can't let ourselves forget Dirk, a senior Business major in college. Dirk loves computers and uses them to organize his life. He dreams of opening a PC support business when he has the sufficient startup funds. Currently, he uses his computer mostly for term papers and such, playing around with something he downloaded recently called BeOS Max Edition. Because he has Internet access via the college's LAN, he downloads applications left and right. The only problem is that he is tired of having to remember where he put apps to look up help files and is intrigued by the Terminal application and how to use it. He finds it frustrating having to navigate through BeOS' HTML files in order to look up switches for grep, tar, and bzip.

The company wants to market Dox to people like Aaron and Dirk. By knowing who the application is for, it is clearer what will be needed for each gentleman in order to work than if someone said "Dox needs to be easy for the newbie and powerful for the power user." For those of us who code by themselves on a project, a little work like this may not seem very useful or interesting, but our projects are better for it nonetheless. It doesn't take much time, though. In fact, it took the author more time to type the two above personas than it did to brainstorm the details. Sometimes what is thought of as the Fast Way is not necessarily the Right Way - in this case, the right way is about remembering that programming is really all about the people the software serves.

Everyone who has been around BeOS for a while knows that for a long time, Be, Inc. was trying to get developers to produce the "tractor app". This creative nomenclature could be defined as "the one application that will cause users to install BeOS and use it because there is nothing else that will let the user have the same capabilities." It is not a surprise that an ex-Apple executive would consider this to be wise. Visicalc drove Apple ][ sales for several years, catapulting it into the forerunning position in the business world, until IBM's marketing juggernaut came along. The Macintosh, with the laser printer and desktop publishing form a second example from the same company. A non-Apple example would be the Video Toaster and the Amiga 2000/3000.

Be, Inc. was of the opinion that some such app was possible with BeOS. When that application came along, it would mean untold riches for both Be and the developer. There are several flaws in this theory. I humbly submit, though, that I point them out with 20/20 hindsite. I didn't conceive of them at the time any more than anyone else did.

Each of the previous examples included hardware. That is the first fallacy that afflicts the Tractor App strategy. The Apple ][ was really the first computer (or maybe it was within months of the first) that could run Visicalc in a reasonable way. Many computers of that time period were either computer kits or required a lot of effort to use. The Apple ][ you could just turn on and use. Especially once the disk drive was released. The IBM PC of 1984-1985 could not really be used for desktop publishing - the graphics capability and the operating system were not capable enough. The Video Toaster was designed for the video slot of the Amiga - without the video signals generated by the custom chip set, the Toaster would not have been possible. The BeBox, on the other hand, offered only the GeekPort as unique hardware. As cool as the GeekPort was, it was hardly a revolutionary piece of hardware.

Each of the examples of Tractor Apps provided users the ability to do a vastly better job of something that they already did. Visicalc let accountants perform calculations and keep ledgers better. Desktop publishing allowed people to see the results of their everyday work on screen before they committed to paper. The Video Toaster allowed people to turn average video into outstanding video. But it required a video camera - anyone using it already had the ability to make a video. The Toaster added titling, special effects and 3d modeling.

Tractor applications sold computers to people who either didn't have them or didn't use them in that portion of their daily work. The tractor apps of the 80's came about at a time when most people didn't have PC's. By 1995 or so, "information workers" already had computers on their desks with a group of applications that they used on a daily basis; many people had custom applications on those PCs. Trying to displace the OS from those is very difficult.

There is a revolutionary feel behind tractor applications. The ability to change the world. They are fun and exciting - they draw people in. If enough people are interested, others will come to believe that there must be something worthwhile in it. At the same time, those people paid to be conservative, like IT staff, will be less inclined. That is why the Macintosh and the Amiga never made inroads into corporate culture.

It may be clear by this point that I don't believe that the tractor app has come or will come soon for BeOS (or any other OS). One reason is that the computer industry has changed a great deal. We all share the same hardware, for the most part. If some spectacular device came out, it would be weeks, not years, before every OS out there could use it. That prevents one OS from gaining an edge through hardware. Another reason is that most of the industries are as computerized as they can be. Those that remain are the tougher nuts to crack. Finally, people already have a PC on their desk. Adding one or rebooting the one that they have just to use some one application is onerous.

As I cruise the highways and byways of farm country, I have noticed that many farms don't have one single tractor. They have harvesters, threshers, tillers, and other odd looking machines. To extend the analogy, it seems to me that instead of a single tractor that drags people kicking and screaming onto our favorite OS, we need to have a bevy of tools, each properly appointed to a different type of user. A great DTP program for the professional writer. A simple word processor for the person who has simple needs. A basic photo app for the amateur photographer, but a deluxe bag of tools for the graphic artist. Command line tools for the Unix guru, but a slick IDE for the Visual Basic developer. The ability to read every file format under the sun, so that never once does anyone ever have to call and ask for a file to be sent in a different format. Unprecedented interoperability and compatibility, enhanced productivity and a complete user experience.

A long time ago, I was asked by my boss to prepare some graphics. The tools on my PC were totally incapable of the task. I brought my Amiga 1200 into work to take care of the task. They were totally awed by the fast boot time, the responsiveness of the GUI and the clean, slick look (Amiga OS 3.0 compared to Windows 3.1). They asked me to load an MS Word document. When I told them that I could not, the snickered. No matter how great the technical capabilities, if people can not do their everyday work well, they will reject the system. That is where BeOS is, today. While it is sufficient for some people's needs, others need the ability to read and write proprietary formats and to do work that there is not software to do well on BeOS. BeOS is acceptable from a technological point of view today. Sure, it doesn't have a driver for this or that. But that is easily fixable and would be fixed with greater popularity. The real issue is the applications.