ZAT - notes on Z to A Travel

Yesterday MySpace, which was purchased by Rupert Murdoch’s News Corp. for $580 million, was valued to be worth around $15 billion dollars. And YouTube, a company that has always lost money and has no business model, was purchased by Google for over a $billion. While some people might look at numbers like that with their eyes aglow, there is an interesting quote from Craig Newmark (of craigslist) in this article:

http://today.reuters.com/news/articlenews.aspx?type=internetNews&storyid=2006-09-28T131335Z_01_L28672677_RTRUKOC_0_US-CRAIGSLIST.xml&src=rss&rpc=22

Craig says “Who needs the money? We don’t really care. If you’re living comfortably, what’s the point of having more?” He said that he and craigslist CEO Jim Buckmaster agree on not cashing in. “We both know some people who own more than a billion (dollars) and they’re not any the happier. They also need bodyguards.”

I couldn’t agree more.

My goals for ZAT are:

1) have fun!
2) work on something interesting and technically challenging, with other interesting and smart people
3) make enough money so the site is self-sustaining
4) provide a useful service to people
5) encourage world understanding through travel

If those goals are met, I will be very happy.

I’ve sold companies I founded for millions of dollars, and I’ve also been dirt broke in my life. Money has never made that much of a difference to my happiness. Having enough money to be free to work on whatever you want is cool, and being able to help out your family in times of need is good, but beyond that, to paraphrase Craig, who the hell needs the money? I had to spend far more time worrying about money when I had it then when I didn’t.

People who spend all their time trying to get more money, don’t have a life.

–wm

The new way that ZAT is dealing with tags has some interesting implications for the Web2.0 world. Maybe I should write an article about it.

As mentioned in an earlier post, tags are very popular in Web2.0 websites, but they have a number of serious problems. Some sites, like digg, don’t even use them. Instead, they stick with categories. I originally was going to support both categories and tags, but I figured out a way to have most of the advantages of both tags and categories in a single system.

On top of that, ZAT tags have values, so they are actually ratags.

–wm

I’m noticing something interesting while I’m building ZAT. I seem to be building the interface backwards!

I have implemented pages for adding Tags, adding Regions, and adding Spots. After I get all those working properly, I’ll implement a page to add Links. I need to do it in this order because I can’t add any Regions until I have Tags working, and I can’t add any Spots until I have Regions working (a Spot must belong to a Region, and both Spots and Regions must have tags).

But in reality, a user of ZAT shouldn’t ever use any of these webpages, except for the Add Link page. If they try to add a link, and the Spot or Region doesn’t already exist, it should be created then, not in some separate precursor step.

So I’m in effect building a bunch of web pages that are there only to bootstrap the application, and once I get it going, they should hardly ever be seen again.

–wm

So, I’ve been trying to figure out how to do categorization in ZAT. The new hot thing is tagging, as exemplified by sites like del.icio.us, flickr, and others, but there are definitely problems with existing tagging sites. For example, read Metacrap: Putting the torch to seven straw-men of the meta-utopia.

Even so, I think I have decided to not use any categories in ZAT, and use tags instead, but make some pretty major changes to existing tagging systems. First of all, I am going to use ratags (ratings tags) exclusively, instead of plain simple tags. So for each tag, there will be a rating associated with it.

For example, let’s say there is a place we want to enter into ZAT that is both a hotel and a restaurant. You would give it two tags, “restaurant” and “lodging”. That place might be a great restaurant, but a mediocre hotel, and the ratings would (hopefully) reflect that.

You can add other tags to any place, to support special interests. For example, there could be a tag for vegetarian restaurants.

Second, I am not going to just let people type in any old tag they want. Tags have to be explicitly created. By default, I would have tags like “restaurant” “lodging” “camping” and “top-sight”. Users can create their own tags, too. When a tag is created, you also can give it a number of related names. For example, “food” might be a related term for “restaurant”. I’m going to use some AJAX auto-completion with tags, so if you are submitting a restaurant to ZAT and you start to type in a tag of “food” it will provide an auto-completion value of “restaurant”. I hope this will help people use consistent tags.

We’ll see how this works out.

–wm

[added 28 sept] so far working out very well!

Good user interfaces are built upon metaphors. Lately, I’ve been thinking about metaphors for ZAT.

There are three main things in ZAT: Regions are things that take up a substantial area on a map, such as cities, states, countries, national parks, etc. Places are smaller things on the map, like hotels, restaurants, sights, and other places to go to. Links connect Regions and Places to web pages with information about them.

There isn’t really a good metaphor here. These are more implementation terms than conceptual terms.

One metaphor I’ve been thinking about is the (printed) guide book. In the guide book metaphor, Regions become Sections (and sub-sections), Places become Entries, and Links, um, become something (Posts? Bookmarks? Tips? or stay Links?). The metaphor is that a guide book is divided into Sections. There can be a section on Oregon, and a (sub) section on Portland, and (sub-sub) sections on specific neighborhoods. Within sections there are Entries. There are entries for hotels, restaurants, sights, etc. And each Entry has a number of Posts (Links).

I’m not sure if I love this metaphor, but at least it is a metaphor, so unless I come up with something else, I’ll probably change over to it. Or not.

–wm

[added 29 sept] I didn’t end up using this metaphor, but I did change the name “Places” to “Spots”. So a spot is a specific place on the map (like a hotel, restaurant, etc.). I’m now using the name “Place” to refer to both Regions and Spots. I’m still thinking about changing “Region” to “Area” but for now I’m sticking with Region.

[later] I did change Region to Area. To recap, Places is the generic term, which in turn consists of Areas and Spots.

I thought long and hard about how to do registration for ZAT. There are several reasons for needing people to register. One is just a practical matter. In order to implement groups or allow you to have friends, I need to uniquely identify the user so I can know what groups they are in and who their friends are. And it isn’t good enough to just remember what computer they are on with a cookie, since ZAT’s users are travelers, and travelers, well, travel — we want them to be able to access ZAT from many different computers around the world.

A secondary reason is for spam prevention. This website will be rating and promoting commercial establishments like restaurants, hotels, and other paying attractions, so we at least want to make it inconvenient for people to promote their own business excessively. For example, if you didn’t need to register to vote, someone could just sit there voting for their own B&B, in order to make it the most popular B&B in a city. This would destroy the value of voting in ZAT. Even ignoring fraudulent voting, a user might mistakenly vote for the same place more than once.

The bottom line is, ZAT needs to know who people are. But I also wanted to make it as easy as possible for people to sign up. So I had to think carefully about how to verify who people were. In the end, I decided to require people to enter an email address, and then I send them an email with a generated password. They can then use this new password to sign on and can change their password if desired.

I would prefer to skip the email verification process. Verification emails can get lost in the mail, or stuck in people’s spam filters, etc. As time goes by, I might try to get rid of the email verification, if it doesn’t result in any problems.

There were other decisions to make — should the site allow them to pick a password or generate one for them. For now, I’m generating a password, and I allow the user to change their password at any time. This does add a step for people who want a specific password, but it was convenient (for me) because it meant I didn’t need any other mechanism to verify their email address (a link for them to click on, etc.). And the same mechanism is used to let people reset their password, should they forget it.

I should mention that people can access and use slims without being registered or signed on. All information on the site will be freely available. But people must be signed on in order to vote, add comments, or submit new sites. And of course, they must be signed on in order to join groups.

–wm

One thing that is surprisingly (and annoyingly) difficult to do in HTML and CSS are resizable layouts. By resizable layouts, I mean web pages that fill a browser window, even if you resize the browser window. And it is difficult to do this either horizontally or vertically (or both at the same time), which is what I wanted to do with ZAT.

Resizable layouts are very common in normal (non-web) applications, so it is strange that they are so difficult to do for web apps. And it is especially strange, because HTML was originally all about resizable layouts. If you create a static web page, you have to actually work hard to not have it fill the entire window and reflow as you resize the page.

But once you start putting in navigation side bars and things like that, it gets dicey. I always figured that this was some sort of revenge that designers wreaked on the web, since they have been trained on media like print and TV, which do not resize. What else could explain the large number of websites today that are of fixed width, forcing you to either resize your browser window wider in order to see all of the content (or — horrors — using a horizontal scroll bar constantly to move back and forth), or alternatively if your browser window is wider than the content, live with vertical stripes of whitespace on the left and right side of the window, wasting screen real estate (which then forces you to use the vertical scroll bar to move down the page more often).

For ZAT, I wanted the following layout:

• A small navigation bar at the top. The left side of this bar is the top-level navigation, to allow you to select between the major tasks in ZAT (browsing, changing your preferences, adding new information, and viewing other information about ZAT). The right side of the navigation bar identifies who you are, and has links to let you sign in (or sign up, if you are not already registered).This navigation bar is fixed height, so that is reasonably easy to do with CSS. The bar is also the full width of the window, also reasonably easy. Laying out some things on the left and some things on the right is a little more complicated, but doable. In the end, I actually used a table (which the designers seem to abhor) so that the navigation buttons would spread out as the page gets wider. I also do the standard tricks, like using :hover so that navigation buttons highlight when the cursor is over them (to encourage you to press them, I suppose).

  I experimented with having three sections in the navigation bar (one left aligned, one right aligned, and one centered between them) but that was much more difficult to do gracefully, and get it to work reliably on all browsers, so I dropped it.

  For now, I am not using any drop-down menus, but that may change as the site gets more complicated, and people want to jump directly to specific pages.

• Second, there is an area that depends on the specific page. Typically it is a form, with information you fill in or widgets to control what is displayed. The height of this section is highly variable, and in fact it can change in height as you type in information. This form/control area is laid out using normal HTML flow constructs. It often has multiple columns.
• Jumping to the bottom of the page, there is an info bar. Currently, the info bar just says “Z to A Travel” and is of fixed height, but eventually it will contain other information. For example, as ZAT joins various professional travel associations, their logos might go here. And various logos indicating that ZAT is secure, trustworthy, safe, etc. Many sites put the “built using X” logos here, but I think I’ll leave those off.
• Finally, there is a map. Here’s the hard part. I want the map to take up all the remaining space, from the bottom of the second part (the form) to the top of the info bar. Furthermore, I want the map to be a minimum height. If the window is not tall enough to allow this, then I want the window to have a vertical scroll bar. Currently, the map has a minimum height of 500 pixels. If the combined height of the navigation bar, form/control, map, and info bar is too tall, the whole window gets a scroll bar (so the info bar and possibly the bottom of the map is scrolled off the bottom of the window). If you scroll down, the navigation bar scrolls off the top, and possibly the top of the form.

This is an interesting layout, very different from the multi-column layouts that seem so popular today. The purpose was to give as much space to the map as possible, since ZAT is primarily a map-based webapp. Even so, there are plenty of map-based web apps that use multi-column layouts. For example, Google Maps, which has a navigation area across the top. The rest of the page is divided into two columns: a control area on the left (fixed width) and the map on the right. The map resizes itself as you resize the page. I find this awkward, and it cannot deal with minimum sizes (the window never scrolls).

In the end, there was no way to implement what I wanted using HTML and CSS. I used JavaScript to respond to resize events, to layout the page after each window resize. The only complicated part was calculating the size of the form/control area. You have to walk up the DOM hierarchy, adding up heights, to determine the total height of this area. After that, since the navigation bar and the info bar are fixed height, you can easily calculate the area remaining for the map. If this is less than 500 pixels, I simply set it to 500 and let the page scroll.

Width is easier, since everything is full width, and just resizes using normal HTML flow constructs as you resize the width of the window. This is a little more complicated in the form/control area, since it will often contain multiple columns, but it can be done in CSS without too much pain.

Why I have to use JavaScript to do a layout like this is beyond me, and is one more reason I think CSS sucks.

–wm

I’ve actually been getting quite a bit of coding done the last few weeks, so I haven’t posted much here. The user code for creating a new user id, signing in, changing your password, and so forth is done. You can now sign in, and even have it remember you on your computer (with a cookie). I don’t have any of the other user profile things done.

I decided to use the user’s email address for the user id. Each user has a (unique) nickname, so they can sign on using either their email address or their public nickname. When a user creates a new account, their password is emailed to them. They use this password to log in, but can change their password if desired. If they forget their password, they can have a new one emailed to them. This isn’t completely secure, but this website really doesn’t need a bulletproof level of security. Besides, it won’t be particularly secure until I get a certificate and start using https.

I read an interesting article that pointed out that as long as you have an easy way for people to reset their password, you don’t really need to do the common thing of having them type in their password twice. If they make a mistake, they can just reset it and try again.

As a result, creating a new account is very simple. You just type in your email address and a nickname. ZAT checks to make sure they are both unique (and valid) and then emails out a new password. Signing in is also easy — you just type in either your email address or your nickname, and your password. You can also check a box to have ZAT set a cookie and remember you on the current computer. Most people will want to do this, unless they are accessing ZAT from a random computer (like at an Internet Cafe).

I also have the first Google Map up. This is the map that allows the user to define new Regions. A Region is an area on a map, used to define countries, states, cities, neighborhoods, national parks, etc. Imagine a typical guide book — a Region in ZAT corresponds to a chapter or section in a guide book. Defining a Region is simple. You give it a name (e.g., Portland) and say what it is a part of (e.g., Oregon). You can optionally define alternate names or abbreviations (for example, for the USA you might specify that it has alternate names of “America” and “US”) — this makes it easier for people who are searching. Finally, you click on two points on the map to define the boundary of that Region. That’s it!

Next up is to implement the definition of Places. A Place corresponds to an entry in a guide book; for example, a restaurant, hotel, sight, etc.

After that is the part of ZAT concerned with associating a Place or a Region with a URL (to a web page). So for the Region “Portland” there can be a number of associated web pages, talking about travel to and about Portland. And for the Place “Benson Hotel” (one of the old classic hotels in Portland) there can be a number of links to websites with information about the Benson — the official website, blog entries from people who have stayed in the Benson, photos of the Benson, special discount offers to stay at the Benson, etc.

Then I can start to tackle the really hard part — letting people search a map for Places and Regions, and giving them access to the associated links.

So far it is going well. The Google Maps API is pretty straightforward JavaScript, and is well documented. I did spend a day trying to track down a bug, which turned out to be a bug in their library. I’ve submitted it but it has not been fixed yet. Luckily, it fails only on Safari (not on Firefox or IE, the two other browsers I test), so hopefully Google will fix this bug before I launch ZAT.

I’ve been reading a number of books in order to bring myself up to speed on current web technologies. Here are some of the ones I’m most enjoying:

Web Design in a Nutshell (third edition) by Jennifer Robbins
Bulletproof Web Design by Dan Cederholm
Pro MySQL by Kruckenbert and Pipes
JavaScript: The Definitive Guide (fifth edition) by David Flanagan

I’ve also bought the following, but haven’t read them enough to evaluate them yet:

DOM Scripting by Jeremy Keith
PHP Hacks by Jack Herrington
Google Maps Hacks by Gibson and Erle
Web Mapping Illustrated by Tyler Mitchell
Mapping Hacks by Erle, Gibson & Walsh
Upgrading to PHP5 by Adam Trachtenberg
Programming PHP by Lerdorf, Tatroe & MacIntyre (so far not too impressed)
Beginning PHP and MySQL 5 by Jason Gilmore

I’ve used a lot of programming languages in my time (even invented a couple of them) but it is very interesting trying to learn two similar languages (PHP and JavaScript) at the same time. Oy! I wish someone would create a decent set of server-side libraries for JavaScript, so you could write both the server-side and client-side code in the same language.

The other day I wrote some Javascript and it wouldn’t work. I looked at it and looked at it, and couldn’t see anything wrong with it. I checked all the library functions to make sure I was calling them correctly. Suddenly, I realized that I was trying to use a PHP library function in a JavaScript program. I was calling it with the correct arguments, I was just in the wrong language. Doh!

–wm

I was talking to a friend of mine today, and she told me that she looked at this blog but there was only one article in it! Now, I know I haven’t posted much in a week or so, but there is certainly more than one blog entry in here. Turns out that the problem was IE.

I program on a Macintosh, and normally use Safari as my browser (I also use Firefox). IE isn’t even supported on the Mac anymore. But when I set up the blog, I tweaked the theme to make it more to my liking, and somehow I broke IE (more precisely, I broke the blog so it wouldn’t display properly in IE).

Luckily, I have Parallels so I can run Windows on my Macintosh, so I fired it up and tried to fix the blog so it would work on IE. After futzing around for a while, loading an entirely new and different theme started to look mighty attractive. It’s funny, considering all the computer education and experience I’ve had, you’d think getting something simple like WordPress to work on a couple of different lousy browsers would be a piece of cake. But no. Sigh.

So now the blog looks completely different.

CSS sucks.

–wm