I want to like Netscape 6.2, really I do. And there are a lot of aspects of it that I do like. But it has all these annoying habits that slow me down:

• When I open a new window, the cursor is not blinking in the URL field. Normally it should be. This drives me nuts.
• Tabbing should toggle between the URL field and the body of the window. It doesn’t, at least not reliably. If there’s a page with links displayed, tabbing moves the focus from one link to the next. This is a Windows-y behavior that I’m not used to. I need to grab the mouse to get the cursor in the URL field.
• Forms on web pages do not use standard Apple interface widgets, they use very Windows-y widgets. Not what I’m used to. I know Netscape is trying to use a common code base as much as possible, but it’s still annoying.
• There’s a noticeable pause when opening a new window.
• It helpfully can remember all your website passwords, but rather than hooking in to Apple’s keychain, it makes you enter a master password separately.
• For reasons I’ll never understand, it renders some elements differently than previous versions of Netscape, or IE, or whatever. Dumb stuff. Like some pop-up menus, horizontal rules, that sort of thing. Why?
• Oh, and this really bugs me: hitting escape or command-period used to stop animated GIFs, but no longer. Some animated GIFs I do want to watch; most I do not. Why this useful feature was dropped I can’t imagine.

I do like the fact that it’s really fast, it gives me basic keyboard controls for navigating text in editable fields (shame, IE, shame), I like its sidebar approach better than IE’s

Test of iBlog beta

I don’t like the way phones work.

First off, let’s take phone numbers. Phone numbers are not easy to remember. I can remember 10 or so. Admittedly, speed-dialers have made me lazy–I could probably remember more if I put my mind to it. I like e-mail addresses much better. I can tell someone my e-mail address, and they can probably remember it, at least until they get home. If I tell anyone my phone number, they’ll almost certainly need to write it down immediately, unless they have an excellent memory or I come up with a cute mnemonic.

Next, think of all the phone numbers people need these days. A well-connected person might have a home phone, office phone, cellphone, pager, and fax number. That’s five numbers, and two of them aren’t even for voice communications. Imagine this worst-case scenario for trying to reach this person: The guy you are calling is in the field, with his cellphone, but the batteries are run down. You try him first at home, then at work, then on his cellphone (which can’t answer). You try paging him, and he gets the page, but can’t call you back. As a last resort, you write out what you wanted to say and fax it to him. Perhaps by the time he gets to a phone to return your page, you are away from the phone from which you sent the page, so he starts chasing you at all your various contact numbers.

Admittedly, some people have multiple e-mail addresses (I am one of them), but it is usually not hard to set things up so that they are all funneled to one address, or so that you can pick them all up easily.

Phone numbers generally change when you move, certainly if you move a long distance. E-mail addresses do change for a lot of people when they change service providers, but there are easy ways to get permanent e-mail addresses so that you can move around and change ISPs with impunity, and still be easily reached.

So what do we do about this?

The future of phones is in the Internet. Phone calls will be carried over Internet lines like e-mail or pictures. We won’t have phone lines running into our homes per se, we’ll have permanently-connected data lines that carry voice signals among other things. The devices on which we make phone calls may or may not look like phones. Internally, they will be more like computers (unless they are computers, plain and simple). Cellphones will be essentially the same. Once phone calls run over the Internet, they’ll work more like existing Internet services, like e-mail.

Here are some descriptions of specifically what I have in mind.

One aspect I predict is that phones (or phone lines) will not have specific phone numbers permanently assigned to them, any more than computers have specific e-mail addresses assigned to them today. When you get to a phone, you will log into it to let the network know where you can be reached. So how would a call get to you? A few possibilities come to mind.

The folks responsible for Java have invented something they call a Java ring, which is pretty much what it sounds like. A ring that you wear on your finger, which contains a small processor, and which could be used in place of numerous keys, ID cards, etc. I love this idea, and envision that future phone-like devices will let you log into them by waving your ring over them, or touching a pad, or something like that. When the phone interfaces with the ring, the phone gets information about you from the ring, and configures itself to answer calls intended for you.

To understand how this might work in more detail, it helps to understand a little of how existing Internet services work. Take domain name servers, for starters. Every machine that is permanently hooked into the Internet has a long dotted-decimal number called an IP number (like “192.102.1.226”, for example) and a name (like “sluggo.cartoons.org”). Domain name servers maintain long tables of the associations between the two. When you type in a website’s address, your web browser first asks a name server “what is the IP number for this name” gets a response, and then uses the IP number to connect to the web server. These tables are updated once a day.

The nice thing about this is that it is dynamic: the domain name can move around to different machines on the network. It isn’t hard to imagine something like this with phones–you would have a permanent “virtual” number (or better yet, name, perhaps the same as your e-mail address), and the network would keep track of what physical phone-like device was currently hosting that phone number. But only updating once a day is much too slow for a phone system, since people are constantly moving around–tables would need to be updated every few seconds, and that would be impractical too, since the tables would be really big.

A more productive example might be the way e-mail works. When you send out a piece of e-mail, your e-mail software connects to a server called an SMTP server. It is the SMTP server’s mission in life to take your outgoing e-mail, find where it is going, and send it there. It does not go directly to the recipient’s e-mail software, though, it goes to another server called a POP server, which acts as a holding-pen for e-mail until the recipient gets around to checking for his e-mail. You can send e-mail via any SMTP server in the world, as long as it is willing to talk to you, and you can pick up your e-mail from any POP server in the world, as long as you have an e-mail account on it and know your password (SMTP is not password-protected for some reason, which has benefitted spammers greatly. Many ISPs restrict the machines that their SMTP servers will talk to, as a way of blocking outgoing spam). Another way of putting it is that you can access your regular POP server from anywhere in the world. This is great, because you can travel without changing your e-mail address. You just need to be able to get a connection to the Internet.

How exactly would that work? That’s where the different possibilities present themselves.

One scenario would be sort of like the name-server arrangement–master tables of people and the phones they are at, which are used whenever someone tries to call you. The drawbacks to this scheme have already been covered.

Another option would be to mimic the mailserver scheme. You would have a (semi) permanent “call server” that would be analogous to a POP server; when you logged into a phone, that phone would simply learn where your call server was, and notify the call server where you were. Calls would always pass first to your call server, and then on to you. This doesn’t require master tables of phone numbers to be updated all the time, but it is inefficient to force the voice signals to be routed through a call server that may be far away.

This suggests a hybrid approach. When you log into a phone, it notifies a call server of your current location. From that point on, the call server will receive incoming calls, but notify the calling phone “here’s where he is really at, you can make a direct connection to him now.” This only requires a one-time detour to the call server, so it is probably most efficient. (In fact, this is a lot like the name server system–once your web server learns a certain machine’s IP number, it doesn’t continue to pester the name server for it.)

While not strictly necessary, it might also be handy for your call server to receive a log of your outgoing calls (technically, your call server would not need to be involved in any of your outgoing calls). This would be handy for reconciling your call log with your phone bill, although there might not be any such thing as a phone bill under this system–everythings just Internet data, right?

Billing under this scheme becomes problematic. Like I said, calls are just packets of Internet data, so you can’t really bill by call duration or distance. However, you can bill by the amount of data the call consumed, and you can also multiply that by the priority with which it was delivered. Right now the Internet cannot prioritize the types of information it carries, but it will be able to before long. Live voice conversations will require a very high priority, since we cannot tolerate long equipment-induced delays in conversations (if you’ve ever had an international call that was routed by satellite, you have an idea of how irritating this can get). It is possible to squeeze down the amount of information that a phone conversation requires quite a bit, so people should be able to trade off voice quality for bandwidth (and money) savings.

Figuring out the data volume and packet priority for the call is just the first step in computing the price. Perhaps if your call server and the phone you are calling from are operated by the same network, the price will be lower than otherwise. If the other party is on the same network as your current phone and/or your call server, there might be a price reduction for that too. It gives a new perspective on the concept of a “local call”, doesn’t it. Network proximity becomes more important than geographic proximity.