Does Apple really hate netbooks?

This week's big news is that Apple publicly dissed netbooks. (You know, those smaller-than-laptop-but-larger-than-iPod computers that customers insist on buying.)

Apple made some harsh but perhaps not undeserved observations about netbook PCs: small screens and cramped keyboards were the big criticisms.

Some folks think that Apple hates netbooks. I disagree. I think Apple dislikes the current set of netbook PCs. Computerworl has an article/blog about it.

I'm pretty sure that Apple is studying the netbook sales figures. Heck, Microsoft changed Windows 7 to let it run on netbooks. If a trend gets the attention of the Boys from Bellevue, the folks in Cupertino will watch.

I think Apple wants to bring out a netbook, but isn't quite sure how. One problem is the product line: a netbook would fit above the iPod and iPhone, but below the MacBook. Another problem is the design: should it have a keyboard? An Apple netbook with a keyboard would be a small MacBook (and possibly cannabalize sales). An Apple netbook without a keyboard would be a... Newton! And possibly a big success, with the right applications.

I'm guessing that Apple wants to introduce a tablet PC, something physically larger than an iPod but smaller than the smallest MacBook. It won't have a keyboard. It will have Wi-Fi, run OSX, and build on the 'app store' model from the iPod. It will probably have geo-location services.

Apple will need some time for design and manufacturing, some time for negotiating selected apps to the "Neo-Newton", and some time for marketing. Only some apps will go over, Not everything for an iPod makes sense on a larger tablet.

If you have an iPod app, start thinking big!

Scale of software

A friend and I had dinner in a neighborhood restaurant eariler this week. After dinner, I gave her a short walking tour of the neighborhood. I live in the old part of the city, with houses and churches from the turn of the century. (That is, the previous century.)

My friend commented that the city looked very different when viewed on foot. She was familiar with that part of the city but only while driving in a car, and walking was a new experience for her. The city is different on foot. Or, more accurately, our perceptions of the city are different.

In a car, we move along at twenty-five to thirty miles an hour, and we must pay attention to traffic, street signs, and pedestrians. We have no spare attention for architecture. On foot we can focus on other things. Yes, one must be aware of cars and other pedestrians, but the amount of attention required for them is small. You can spend attention on other things. If you want, you can stop and look at buildings while everyon else goes about their business.

The city (at least the downtown portion in which I live) is designed for pedestrians. It is scaled for foot traffic. Buildings are close; many abut their neighbors. There are sidewalks. Some streets are one-way. The result is that it is easier for me to walk to the grocery store than to drive.

Suburbia is scaled for automobiles. The buildings are placed further apart, and surrounded by parking lots. Some suburban developments have no sidewalks. Suburban malls are often built in areas that are unapproachable on foot.

The scales of city and suburb are different.

Are there similar scaling in software? I think that there are. Software is not scaled along the axis of pedestrians and drivers, but for individuals and organizations. Some software works well for the individual and poorly for a large organization. The traditional PC packages (word processor, spreadsheet) are scaled for individuals and do not allow for collaboration. In contrast, databases are designed for multiple users and database applications are better for teams than individuals.

Instant messaging is scaled for individuals, but small sets of individuals. Instant messaging is useless for a single person; you have to have a partner for messages. But it is limited to two (or maybe three or four) people at a time. 

E-mail is interesting in that it can scale from two users to a large number of users. Two people can use e-mail easily. A team of people can use e-mail with distribution lists.

Microsoft has taken some interesting steps with Sharepoint and their Office suite. They are moving the word processor and spreadsheet out of the single-user realm and into the multi-user realm. This is why they hawk their Sharepoint product as a "collaboration tool".

Most web applications are designed for multiple, collaborating users. PCs are efficient at private information, the web is efficient at shared information.

When building an application, be aware of its scale. Think about the users and their needs. Software built at the right scale will be well-received. Software built at the wrong scale will be ignored.

The Twitter Revolution

The world is a-twitter about Twitter, the new social networking messaging service. It is the current "rave", and I think rightly so. Twitter can bring about significant changes.

First, a brief description of Twitter: a one-way, multi-target, subscription-model instant messaging service.

Instant messaging and its close cousin text messaging are two-way, two-party (occasionally more) messaging services. I can establish an IM session with you and then we can exchange private messages. (Private to the extent that the carriers and eavesdroppers can read them, but others cannot.) Or I can establish an IM session with you and someone else and then the three of us can exchange messages, each seeing what each person sends.

Twitter is different. The first difference is that Twitter is one-way: messages go from sender to recipient with no return messages. Second, Twitter is multi-target and messages can go from one sender to multiple recipients. (Sounds like e-mail without the "reply" button, doesn't it?)

The third difference is what makes Twitter revolutionary: it uses a subscription model. Senders do not pick recipients; recipients pick the senders that they want to "follow". The receiver is in control, not the sender. This is quite a reversal of power.

Corporations could use Twitter to keep people informed of events. (Corporations already use instant messaging, e-mail, telephones, and paper memos, why not Twitter?) I suspect that a corporation would want a private Twitter network, available to employees but not outsiders. But the subscription model used by Twitter is quite at odds from the usual corporate distribution list. The normal corporate distribution list is centrally controlled, and depending on the situation one must ask for permission to be added to a list or perhaps one is put on a list despite one's desires. Twitter changes that thinking, by giving the "opt-in" and "opt-out" choice to the recipient.

With a Twitter service, the sender (or "Twitterer" in the parlance) has no control over the distribution of the sent messages ("Tweets", in the parlance). With e-mail a manager can include all direct reports and exclude members of other teams, with Twitter that is not possible. It is akin to posting the location and time of a group meeting and not mandating specific individuals but allowing anyone to attend.

Changing the corporation's internal Twitter service to allow such forced reciept of Tweets and to limit Tweets to specific individuals would change the Twitter service back into instant messaging with a distribution list. And that is a very different animal. It is a different social contract, one in which control remains with the sender.

Twitter is revolutionary because it places control in the hands of the recipients. It is a democratizing approach, allowing people to select the information that they receive. Telephone calls, e-mail, and paper memos that use sender-maintained distribution lists are dictatorial.

I think corporations will benefit from Twitter. It is not a complete replacement for paper memos and e-mails, or instant messaging. It complements these services. Twitter can replace a lot of status reports and e-mails, and notifications about events (such as test results or group meetings), and it's subscriber model can make the distribution of messages more efficient.

Viva la revolucion!

The EDVAC leap

New technologies often allow us new ways of doing work. Many times, we see the new way only after the technology is developed.

Two early computing devices were ENIAC and EDVAC. Both were created in the nineteen-forties and used to compute ballistics tables for the US Army. ENIAC was created first, as an electronic calculating machine. Previous calculating machines were either mechanical (all gears, rods, and levers such as Babbage's Difference Engine) or electromechanical (electrical relays but not vacuum tubes).

EDVAC followed ENIAC and was quite different.

ENIAC was an electronic version of a mechanical calculating machine. Mechnical calculators used rings to hold digit values. Think of them as fance versions of old-style car odometers. ENIAC used electronic circuits to duplicate the physical rings of machines. It used decimal arithmetic, with each digit having one of ten possible values. It was a "direct port" of the electromechanical design into electronics.

EDVAC used a different design, one made possible by electronics. EDVAC did not duplicate the ten-digit rings, it used binary values and two-state memory digits (today known as 'bits'). It had other innovations too. One can draw a sharp line between ENIAC and EDVAC and label the early part "calculators" and the later part "computers".

But perhaps this experience tells us about our inventive skills. We use a new technology to build a new version of something, duplicating the design. Then we invent new ways to use the technology, creating new designs that were not possible with the old technology. With electronic calculators, we had to build ENIAC first. We could not go straight to EDVAC.

Another example is automobiles. When first created, they were close replications of carriages. The term "horseless carriage" really meant a horseless carriage! The initial design was a carriage that could move about without the aid of a horse. We gained knowledge about motors and their application to carriages, and made design changes. The automobile grew out of the horseless carriage, providing benefits that we could not see prior to the invention of the horseless carriage.

When confronted with a new technology, we do not see the range of possible applications and the potential uses. (OK, that's a pretty trite observation.) But here's the thing: We need the new technology in place, and then we can have the vision of new devices, devices that break from traditional design. The new designs are very different from the old.

This is the EDVAC leap. (The name is somewhat arbitrary. I wanted to give EDVAC some recognition.) We can understand a new technology and then leap to a new set of designs, devices, and uses.

Electronic calculators have been done. Automobiles have been done. Which is not to say that they are finished, but that we've had the EDVAC leap for them and learned how to use those technologies. Other new technologies may lead to other EDVAC leaps:

Electric/battery-powered cars
Segways
Social networks
Twitter
Wearable computers
WiMax and ubiquitous connectivity

Cell phones were originally cordless phones with a much larger range. Now they let us send and receive text messages and pictures, store information, and play TV shows. Who knows what new these technologies will let us do? All we need is the EDVAC leap.

Little Earthquakes (part II)

When introducing a set of changes to a web site, one can add them all at once, or slowly over a period of time. The former I consider the "big earthquake" method: nothing changes for a long time, and then suddenly everything moves!

The other approach is when I call "little earthquakes": small changes over a period of time. The end result is the same set of changes, but each change is smaller and more easily absorbed.

Your selection between these two methods has an affect on advertising.

Foregoing a large set of changes means foregoing the fanfare of the "new look". You cannot stick a label on your site with the words "new and improved" when you make minor changes to navigation. Or the next week when you fix some defects in your web application. If you do not have a large set of changes, the "new look" tag makes no sense.

A fair amount of advertising is based on "new and improved". It works for some things. I'm not sure that it works for web sites, or that it is even helpful to web sites.

With physical products like cars and detergent, the phrase "new and improved" may be effective in gaining new customers. Cars are durable goods and are purchased infrequently. The phrase "new" may spur people to purchase a car earlier than necessary. Detergent is a commodity. One soap is pretty much the same as another, and we tend to use the same amount of soap over time -- we don't increase our soap consumption because the soap improves. The label "improved" may encourage a customer to switch brands but it won't increase overall consumption.

Web sites are neither durable goods nor commodities. They are services, not products, and tend to be complex and non-substitutable. (LiveJournal is not the same as FaceBook, and neither are the same as LinkedIn.) The phrase "new and improved" works poorly for web sites: it doesn't make an existing customer purchase more of the service, nor does it convert a customer from another web site to yours. It *may* encourage people who are not using web sites to sign up with yours, but I suspect new sign-ups come from any advertising, not specifically "new and improved" advertising.

Exception: If you add a feature to your web site, something new, you may want to provide some "new services" fanfare. But only in the case of truly new services. Don't cry "new and improved" because you changed the colors or the shape of buttons.

Don't get me wrong: I am not advocating stasis. I am not saying that you should make no changes. I am recommending small changes over time.

If big earthquakes do nothing to gain new customers or increase sales, is there any harm to them? I think there is, in that they make things difficult for your existing customers. I find it easier to work with smaller changes; I learn them one at a time and I retain confidence in my abilities to use the web site. I find large, sweeping changes harder to work with.

So if big earthquakes gain you no business and possibly irritate your customers, and little earthquakes gain you no business (you aren't advertising them) but cost you no customers, which do you use -- and more importantly, what actions will gain you customers?

More on the "gaining customers" later. For now, I'm looking for little earthquakes.

Little Earthquakes (part I)

Those of us who use Google (which may be everyone) and those of us who pay close attention to Google's web site (which may be a smaller number) know that from time to time Google adjusts their logo. The "Google" that appears on the web page is often decorated in the style of the day: green on St. Patrick's Day, fireworks on July 4th, and so on.

While these changes appear whimsical and without purpose, that may not be the case. Changing the design of the Google logo can serve a purpose beyond the amusement of their users.

Changing the logo (really, changing the image file that holds the logo) requires a process to update their web site. At the very least, they must replace one image file with a second image file. (There are other ways of updating the web site, such as changing the HTML on the home page to refer to a different image file. The result, a process to update files on their web server, is the same.)

Most organizations isolate their production web servers (the ones that customers actually see, not their internal test servers) and carefully guard against changes. They limit access to one or a few teams. They put procedures in place to review all changes and test them prior to "moving them to production". They create an environment which discourages changes to web servers, probably out of fear that a change may cause a failure.

The result is that their web sites change infrequently, and when they do, the changes are usually a bunch of changes that have been tested in advance and patiently waiting for "update day".

This kind of thinking was (and is) used with other computer systems: PCs, minicomputers, and big mainframes. It is not tied to a technology but derived from managers' confidence (or lack thereof) in their people.

Indeed, this kind of thinking extends beyond the IT industry. Magazines will revise their layout, changing the "look" of the publication. They spiff up (or slim down) the table of contents, add (or remove) graphic elements, and change the typeface used for articles. They make these changes all at once, usually with some fanfare about their new look. Even the magazine Fast Company which espouses 'fast' principles and decries the 'old' way of doing business uses this "all redesign at once" philosophy.

Google takes a different approach. Rather than hold all changes for one big update, Google makes small changes over a period of time. It updates a single application one week, and then updates another a following week. Google changes their web site slowly, in small increments. A magazine could do the same thing, by changing the typeface in one issue, adding graphic elements in a subsequent issue, and revising the table of contents in a third issue.

Google's approach is the "little earthquakes" method. Rather than one big earthquake of short duration but large magnitude, Google accepts smaller shifts over a period of time. I think that this works well for them, and for users. (I am a user of their applications.) Google benefits by getting feedback on changes earlier and with fewer risks per update. I benefit by having to learn fewer changes at any one time.

To make this happen, Google needs a reliable process for updates. It must have a process that it can count on. And the best way to create a process that one can count on is to run the process frequently.

So Google's "whimsical" changes to its logo (which requires an update process) on a frequent basis is a way for Google to test its process and see that updates are easy to deploy. And maybe that is not such a whimsical idea.