Last week was kind of hellish. You know when multiple things go wrong at once? I'm not a fan of astrology, and I don't believe in it, but there is a period every year that is called the "Astral Hell" (not sure if this is the correct English term) that starts a month before your birthday. Last Monday (October 16) was exactly a month before my birthday.
Over the last many years I started tracking this period very carefully. About 4 years ago I went to my doctor and I was having a very strong Flu. When he looked at my file he said the last time I was sick was exactly the same week on the year before... The week of October 16.
Besides having to worry about new directions for Sampa (what kind of site/blog are we helping users to build)?), my hand decided to bail on me this weekend. I'm having another tendinitis crisis. I have that once or twice a year and usually is a reflection of a week where I worked (typed) a lot, like last week.
To top it off, we had a rough weekend at home, with Victor not sleeping much and not giving us a rest, and a social event on Saturday (Momix at UW), in which we got home at around 2AM and wake up at 7:30.
This week my wife is at an offsite training, so it will be just me and Victor. Let's see how we manage that.
If you look at (almost) all viral websites they are viral because the user feel some type of association with its content and wants to distribute it to his/her friends. If you look at YouTube, Blogger, Flickr and many more, you will see a common thread. All of them allow users to set up their "address", you know, a link that uniquely identifies that person.
Now, I'm always surprised on how some websites setup that unique address. There is a undeniable grading system on how bad it can be, which I list below, starting at the worst and moving to the best:
7) http://company.com/useless/morestupid.htm?user-id=123735 This is the classic Dynamic URL where the user id is a parameter on the query string of the URL. This is bad for two reasons. First, you are now officially called "123735". Second, this is not friendly to search engines.
6) http://company.com/useless/123735/ At least this one fixes the dynamic query string and converts it to a single URL path.
5) http://company.com/123735 Smaller is always better because you can help users remember without having to copy and paste the link every time.
4) http://company.com/useless/username/ Ok, now we are getting into a more Web2.0-ish style. You setup your user name (and if the site is not very popular, you probably don't need to use john734).
3) http://company.com/username/ Why the useless virtual directory? Figure out a way to the username be the first virtual path, or, better yet...
2) http://username.company.com/ Just use the username as part of the domain. That certainly gives users a sense of ownership.
1) http://userdomain.com/ Now, that is the real deal. Although, this is going to cost the user some money to setup.
If you are starting a company today, make sure it uses either #1 and #2, but not #3 or worse. And #1 and #2 would be better if they are provided together, this way users that want their own .COM domain name can have it, but it is not a mandatory thing like with virtually all web hosting companies.
SQL Server 2000 Standard version has a limitation of 4GB for the database size. This was a strategy from Microsoft so big companies would always buy the Enterprise version with unlimited database size.
Turns out that even small companies can have way more than 4GB of structured data nowadays. Imagine that you import 100% of your websites logs into SQL. An average small business getting about 10K page views per day, would reach the 4GB boundary in about a year.
On my case, I'm building a Geo database with geographical names and locations. That is about 5-6 million rows. With indexes and name variations the entire database is about 3GB. During the weekend I hit the bottleneck a couple of times while trying to optimize the database, so I had to be extra creative to prevent that from happening.
That made me look into the alternatives. The two obvious options were to upgrade to SQL 2005 or to go with MySQL. I couldn't find info on MySQL about its limit, so I assume it is unlimited. Now for SQL 2005, suprise surprise, it is also unlimited in the Standard version.
Microsoft should release a patch for SQL 2000 that removes the 4 GB limit. This is better than having companies evaluation the competition because they need to migrate to something else.
I should start getting paid by BlogLines since I write so much about them. The problem is that with all the Web 2.0 services that I use the one that I use the most is BlogLines and I can't live without it. I tried the new Google Reader, but again it didn't do what I wanted.
This time my issue with BlogLines is its utterly incompatibility with MSN Spaces (or Microsoft Windows Live Spaces Blog and Social Networking Service, for those that like the official name).
Of the 160 feeds that I subscribe to, only two are from MSN Spaces for two friends of mine (Oliver and Flavia). Oliver's last post is about 2 or 3 months old, but everyday, Bloglines tells me that Oliver has 35 new posts. Everyday for the last 2 weeks!!! For Flavia, Bloglines sometimes tells me there are 6 new posts, sometimes 12 new posts, sometimes other number. And the last post on Flavia's blog is about 2 weeks old.
When MSN Spaces launched, Oliver (he was a PM a MSN at the time) wrote a blog post on how BlogLines was using the wrong method to detect if something had changed on a blog post (that was on May 2005!). They are computing the hash of the body of the post. The problem with that is MSN Spaces changes the address of pictures every so often. So, Bloglines thinks there was an update.
Now, I looked at MSN Spaces and they are correctly using the dc:Modified element to indicate when the item was last updated. Why can't Bloglines just use that information instead of trying to be "clever"?
Go to Live Local (or MSN Virtual Earth, whatever you prefer to call it) http://local.live.com and enter the following string on the second box ("Enter city, address or landmark"):
47.68096 -122.13501
What do you get? Some bizarre match on New York because MSN thought the closest match was the zipcode 13501.
Google does the right think and assume this is a Latitude/Longitude value.
My point is that Google is being done by Computer Science engineers. And engineers love to get this kind of feature done. They always justify it by saying "I'll use that".
Microsoft software is also done by engineers, and they do have ideas like that, but it never gets into the product, you know why? Because there wasn't a program manager to "sponsor" it, or because customers didn't ask for it, or the few that asked were considered too outside of the mainstream customer base, or because the feature that would take just a couple of hours to get done was cancelled after 6 meetings of 1h each because they couldn't find the right way to explain in the user documentation, or because the tester thought it would be too hard to test it, or the PM thought that nobody would use it, or the International PM thought the use of "dot" versus "comma" would be too problematic in Europe, or ....
Disclaimer: I have a few friends that work on Virtual Earth.
Recently, there has been a few of discussions on some blogs about the memory leaks and performance of IE vs. Firefox (Scobleizer, LifeHacker). This is a complex subject matter because performance depends on the task being executed, and I don't think you can easily define what is the most common tasks for a web browser. Sure, you can say things like how fast it renders a page, or how efficient is its javascript engine, but that is not the reality of the average usage of a browser. To be honest, I don't even think you can define average usage since there are so many people using the browser in their own personal way. Some people open multiple windows, some open multiple tabs, some open multiple instances of the browser. Then there are extensions installed, sites visited, frequency between reboots, etc.
Yesterday, I performed a non-scientific test on IE 6 vs. FF 1.5.
At 4 PM yesterday I closed all browsers' windows on my PC, then opened IE and FF, and navigated both of them to Bloglines for My Feeds. Bloglines now uses AJAX and updates the feed list automatically every few minutes.
When I started the task, the memory footprint for each browser was this:
Firefox: 29.2 MB
IE: 33.5 MB
When I've got to the office this morning at about 9AM, the browser windows were open for 17 hours straight, with nobody interacting with it but the Bloglines AJAX. The result:
Firefox: 37 MB (increase of 27%)
IE: 195 MB (increase of 4,821%!!!)
Yikes! IE sucks... Not quite, IE was pretty bad, but that could be because the Bloglines team used FF to develop their AJAX framework, and never did a good job of testing it on IE and getting rid of the most obvious memory leaks.
So the quest for the answer of who's faster continues...
We are working on a new Geo-Tagging function for Sampa. Like most Web 2.0 sites that store pictures, you'll be able to Geo-Tag a picture in Sampa.
My surprise is how low the bar for Geo-Tagging has been set. The sites that I visited that did Geo-Tagging, all that they did is associate a Lat/Long with picture. Basically, a dot on the globe.
That is a pretty low bar because you don't have the option to convert points to locations, like in "Show me all pictures in France". It also doesn't give you the opportunity to do Geo-coding, basically where you say "this picture was taken on the 'Eiffel Tower'", and the system converts that to the point on the map. And you can't even have more advanced features like "Show me all pictures in Beaches".
I see a trend in Web 2.0 companies at assuming that all users think alike and they'll have a single way of doing things. And then, most Startups stop thinking by themselves and just follow the competition.
Since I started Sampa I decided to create multiple ways for users to achieve any task. If there is a way to do something with drag-and-drop, certainly there is a way to do the same task without having to press-and-hold the mouse button.
Our Geo-Tagging will be no different. Yes, you'll be able to point-and-click on a map, you'll also be able to enter "Paris, Fance", or "47.68096 -122.13501" (for the GPS aficionado). On top of that, we understand that your world is more important than the pre-defined world, so you'll be able to create your own locations, like "My Home", "Beach House", "Josh's School", etc.
To top it all off, Sampa will make Geo-Tagging ubiquitous on your site. As weird as it might sound, you'll be able to associate any item on your site to a location. From the obvious ones, like your pictures, albums and blog entries, to the not so obvious ones like pages, profiles, book reviews, folders, etc.
Do you have a great idea about Geo-Tagging? Send me your suggestion. This is the perfect moment for it.
John Cook writes the best blog in Seattle about Startups.
He's asking if the Pacific Northwest is inferior in terms of entrepreneurs and business ideas? The short answer: YES!
I can't speak for the Pacific Northwest, because I have no idea what is happening in Oregon (or Idaho), but I can talk about Seattle and vicinity.
One of the pre-requisites for a lively entrepreneurial community is people. Smart people, risk-taker people, entrepreneur people. And we barely have that. Sure there are exceptions, but not enough to make a dent.
IMHO, the reason we are even on the map in terms of technology, is the same reason that we don't have more Startups and business ideas: Microsoft.
Microsoft is like a giant vacuum cleaner sucking all engineers that come near its headquarters. There are exceptions like those that are on the Microsoft-is-evil camp, the very few that prefer Amazon, RealNetworks or InfoSpace, and those that been there and left (like me).
Once engineers are inside the vacuum cleaner, the g-force needed to escape is tremendous. You've got your exceptional benefits package, you make a very decent salary/living, and you have a bunch of Stock Options (or Stock Awards) that will be worth something someday. Why risk all that?
The ones that think about leaving, they don't really think about leaving, they just want a different position on a different team, or more salary, or more stocks. It takes a while for them to realize that life outside the vacuum cleaner is, well, full of opportunities. Microsoft is like Plato's Cave experiment. People lose their touch with reality.
So, if you are a Microsoft employee and you have just a tiny bit of entrepreneurial spirit... Fly, fly away and build a company or join a Startup and build a true legacy.
Now, answer the following question: Do Dell employees will feel proud of this video and say things like "I'm glad I work at Dell", or are they going to say "This is so @#$% lame, why did we do that?"
You know when you are being duped when Oracle is being considered "open" or "standard-compliant" software.
The winner is Web Hosting and Data Center companies. Check out www.1and1.com and click on the "Servers" tab. Stare at that page for a minute and see the yellow sticker saying "Sold Out". What? They sold out their entire inventory of server lease? That is beyond impressive assuming that 1&1 is the biggest Web Hosting company in the world.
This is different from the Web 1.0 boom, where people would buy their servers and routers (mostly from Sun, IBM and Cisco) at a huge upfront cost, then have it not be used to its fullest capacity (because the CTO over-estimated the traffic). Then, once the company would bust, the servers, routers and licenses for databases would be sold on the used market at a fraction of what they paid for it. This situation had a major downturn effect on the big tech suppliers.
Web 2.0 is different. First, to get a very good server costs you just a couple of thousands dollars. Colocation is also much cheaper. On top of that, you have very affordable managed servers and virtual servers. Even if the Web 2.0 companies go bust (and most will), 1&1, Internap and other data centers will do much better this time around because they better understand how to grow their business without doing too much upfront expenses.
Here I was building a geo-database for Sampa, when I found something in the middle of the official USGS data that could be either a prank, or somebody that really commited a crime and wanted to be found. You tell me.
The Clues
Everything starts with the official US database of National Geographic Names. I download this file and started importing it into my database, but the import would stop midway. I tried a couple of configuration changes and nothing, but it always failed at the same line, record number 882213.
An ordinary line on this database contains many data about a place, like its name, state, latitude, longitude and some other info. For example, the line for Seattle looks like this:
1512650 Seattle Populated Place WA 53 King 033 473622N 1221955W 47.6062095 -122.3320708 56 Seattle South
The file is so big that you can't use "traditional" ways of opening and going to line 882213, but I manage to get there and the line that was failing to import was this:
2070999 "Tell Him I Blame Him for the Children We Have Lost..." Aish-Ke-Vo-Go-Zhe Historical Marker Park MN 27 Aitkin 001 464410N 0931842W 46.73611 -93.31167 Minnewawa
Searching Google I couldn't find any reference to that phrase in the context of a geographical place or not, nor I could find any reference to what "Aish-Ke-Vo-Go-Zhe" means. I ask a friend that speaks both Chinese and Japanese, but she said it doesn't mean anything on those languages.
But, there is still one clue left. The coordinates on that row refer to a place in Minnesota near a place called Big Sandy Lake Reservoir, in Aitkin County. Here is the Google Maps link for it.
The Outcome
I can't go there, but if you live near that place or know someone that does, wouldn't be cool to figure this one out? Or, if you know somebody that has access to the USGS database, can you ask them how this data got into the system?
If you have any idea post a comment on this blog or send me an email (marcelo {-at-} sampa.com).
The phrase "Tell him I blame him for the children we have lost..." was said by Asih-Ke-Vo-Go-Zhe (or Native American 'Flat Mouth') in 1850 during negotiations between the US Federal Government and Native Americans on the Minnesota region.
Go to www.glifwc.org to know more, and thanks all for the comments, feedback and investigation.
Still would be interesting to get a picture of that location to see if there is something there.
I manage have either my blog or Sampa appear at same pretty impressive sites.
Last year, a post that I've made about improving the speed of web pages end up at #1 in Digg's Homepage. That drove about 10,000 unique visitors to my website.
In August, Sampa was feature on CNET News.com on the #1 spot on their Homepage (you know, where the 3 images appear, we were the first one). That drove about 7,000 unique visitors to Sampa.com.
Three days after the News.com article, LifeHacker wrote about us as well, generating about 3,500 unique visitors to Sampa.com.
And yesterday, my "mystery" blog entry was featured on Boing Boing and that generated about 1,400 unique visitors. Boing Boing is the #2 most popular blog according to Technorati.
Boing Boing probably has more than 100,000 readers, however, since they publish so much on a daily basis, no post survives more than a few minutes on their Homepage.
The Digg post was very controversial (amazing how a technical post can be controversial), and that is why it generated so much traffic. A lot of bloggers wrote about it, helping to drive even more traffic.
CNET News.com on the other hand was the most effective for our Startup. It generated an immediate huge traffic to Sampa.com, and had many ripple effects on other sites and blogs like LifeHacker, ZDNet, ZDNet Japan, etc.
There is a ton of research on user behavior based on task response time and I'm sure if you search Jakob Nielsen's site you'll find something.
I remember an IBM study made more than 15 years ago that said if it took 1 second for the computer to respond, it would take 1 second for the user to start the next step, but, if it takes 10 seconds for the computer to respond, it takes 20 seconds for the user to start the next step on his task. It is an exponential problem because users get more and more distract the longer it takes for a command to respond.
Web sites are no different. Google proved with its super fast pages (part real, part perception) that users will perform many more searches if they know they don't have to wait long. If each query on Google would take 20 seconds to respond, you are more likely spending more time thinking about what search terms you'll use. But since it takes just 3 seconds, you just keep adding and removing search terms.
So, since I started working on Sampa, I've gathered a list of tips on how to improve the download and rendering speed of web pages. These tips can affect latency, bandwidth, rendering and the perception of when a page is ready and they are in no particular order.
But first, a warning: This tips are for those that are building highly scalable high-demand websites (like Yahoo, Google, MSN, AOL, Digg, Technorati, etc.). If you are building a website for your uncle Joe's Bakery the list below won't be of much help.
Tip #1: Strip spaces, tabs, CR/LF from the HTML
I'm always surprised when I look at some large website HTML to find out that it has a ton of unnecessary spaces, tabs, new-lines, HTML comments, etc. Just removing those elements can reduce the page size by 5-10%, which in turn can decrease the download latency. I'll go one step further and say to you to not use quotes on attributes unless necessary (read the HTML standard on when attribute quotes are not needed).
If you are using PHP or ASP.NET to generate your pages, you might have to install a Response Filter to do that, because removing on the Source Code would just make it super hard to maintain. If you are using C++, C# or Java to generate the HTML, you probably don't have those spaces anyway.
Tip #2: Don't use XHMTL
This is very controversial, so if you love XHTML and think it is better than sex, skip to tip #3.
A lot of people will call me crazy, but I don't see the big benefit in XHTML. It has some pros, but the drawbacks outweights those in a high-perf environment. XHTML generates larger download sizes and it takes longer to render on a browser (search the web and you'll see that is true). Fanatics will always build their page on XHTML without questioning its value.
And about the argument that XHTML is a standard and that is why it is better, well, I have breaking news: HTML *is* a standard. It is even better if you use HTML Strict.
Now, contrary to what I just said, I use XHTML on www.sampa.com, why? Because that website is not expected to generate a lot of traffic. The blogs/sites built with Sampa are the one's that I'm worried about.
Reasons to use XHTML:
If the site is not going to get a ton of traffic, and;
Your XHTML editor is better than your HTML editor (make it more maintainable), and/or;
You need to parse the result using an XML parser.
Tip #3: Keep Cookies Small
Your cookie is sent back to your server every single time the user makes a request for anything. Even with Images, JS, CSS requests or AJAX the cookie is sent. A typical HTTP request will have between 500-1000 bytes. Now, if you have 4 cookies each with names like "user_name" followed by a value with 30 characters, you are adding 15-30% more bytes to the request.
Tip #4: Keep JavaScript Small
Who cares if I'm calling my JavaScript function "start_processing_page()" or "slp()"? The download speed cares and the interpreter cares as well, so, use tiny function and variable names, remove comments and unnecessary code.
Use a Cruncher to reduce the size of your JavaScript (I've built my own version for Sampa.com that removes comments and all unnecessary elements).
Tip #5: Use Public Caching
IMHO, This is one of the most under-used features of HTTP. Big websites use it (usually through a CDN, like Akamai), but the vast majority (I dare to say 99%) don't. All those icons, CSSs, JS can, and should, be cached by the browser (Private Cache), but public caching also allows Proxies in-between to cache them. This reduces the load on your server, allowing more CPU and bandwith to do the important stuff. Now, a lot of people don't use Public caching (or even Private) because their CSS is changing, the JS has bugs that need to be fixed, etc. Well, you can do 3 things to deal with that. 1) Let content to be cached for a short period of time (for example, 24h only). 2) Rename the files every time you make a change to them, this way you can let it be cached permanently, or 3) Implement an HTTP Filter that automatically renames the file if they have changed.
Sampa uses #3.
Tip #6: Enable HTTP Compression
Your HTML couldn't be a better candidate for compression. It has a very limited character set and lots of repetitions (count the number of "DIV" on your page). That is why HTTP Compression makes so much sense. It can reduces the download by 70% or more. So, instead of having to send 40KB of data, you are sending just 15KB. The user will thank you.
Tip #7: Keep all as much as possible in lower case
This actually works in conjunction with HTTP compression. Remember that this type of compression is lossless, this is, decompressing a content will yield the exactly original, which means that the compression algorithm will treat "DIV", "Div" and "div" as different streams. So, always use lower case for tag names and attributes on the HTML and CSS. Also try to be consistent on your JavaScript.
Tip #8: Avoid Tables (or use fixed-layout tables)
Rendering a table is probably the worse nightmare for a browser. If the browser starts showing the table before all the content inside it is loaded, the browser's rendering engine will have to re-render it many times as each piece is loaded. On the other hand, if the browser needs to wait for everything to be loaded, the user we see a blank page (or partially blank) for a few seconds. Browser's usually use a combination of both to reduce the number of re-renderings without leaving the user hanging in there. The point is, don't make your whole page start with a table. It is preferrable to have 3 tables (header, body, footer). Whenever possible, just avoid using tables altogether.
And, better yet, set the default CSS properties of all tables to fixed-layout:
table { table-layout: fixed }
If you do that, you must sure that you always set the table width and the columns width.
Tip #9: Set image size
This is very similar to the table rendering problem. If you add an IMG tag to the middle of your page and don't set "width" and "height", the browser has to wait for the image to be loaded to decide the final size, but, meanwhile it will cost the browser at least 1 re-rendering because it will not wait for all the images to be loaded to show you the page.
Tip #10: Compact your GIF/JPG
So, your page has several GIFs and/or JPG? It is very likely that those could be compressed even more without any loss! GIF/PNG mainly have a very compact data structure, but most applications like Corel Photo-Paint and Adobe PhotoShop don't optimize it well. Go to http://download.com and find yourself a good set of tools to compact your image files. You will be surprised that one of your GIFs had 900 bytes and after compacting it, end up being just 80 bytes.
Tip #11: Reduce the number of external elements
If you see a request graphic from Keynote (a site perf monitoring service) you would be shocked at how long it takes to download just a few extra files to render a page, like a few images, a CSS and a JS file. If you did a good job with Tip #5 (using caching), the impact will be lesser. A browser can only request an image file, after it detected it on the parsing of the HTML. A lot of those file requests are serial. Some browsers limite the number of TCP connections to a single server (usually to 2), thus, allowing your page to only download 2 files at a time. If you have 1 page, 1 css, 1 js, and 7 images on your page (10 files), you can imagine that a lot has to happen before everything is loaded. The point here is, try to reduce the number of files (mostly images), and, if the CSS/JS are small enough, embed it into the page.
Tip #12: Use a single DNS Lookup
This is so overlooked. How many Web Developers think about DNS Lookup when they are building a site? I guarantee you, not many. But even before the browser opens a connection to your server, it needs to do a DNS Lookup to resolve the domain name to an IP address. Now, DNS lookups is one of the fatest things on the Internet, because the protocol is tiny and it is cached everywhere, including the user's computer. But, sometimes you see sites making "creative" domain names for the same server. Like all images come from "images.mysite.com", the page is coming from "w3.mysite.com" (after a redirect from "www.mysite.com"), and the streaming video comes from "mms.mysite.com". That is 3 DNS lookups more than necessary.
If you are Google Maps or Virtual Earth it does make sense to have each image be retrieved from a different domain name, since the latency would make those sites quite annoying to use, but hey, they don't work on mobile devices and are horrible at slow speed connections.
If you cannot use a single DNS lookup, at least keep it in mind that this could be affecting your users.
Tip #13: Delay Script Starts
If you have a process that renders 100 images per second using 100% CPU, and you add another process doing the same thing, the performance will be less than 100 images per second (less than 50 per process). That is because now the OS has to manage context switches. The same thing applies to scripts on your page. If the browser stills loading and processing a few images, or CSS and you just fire a script, it will take longer for that script to execute than if you had waited the page to be completely loaded. Actually, it gets a little bit more complicated. The browser fires the "onload" event for the page once it has all the elements necessary to render the page, not after the page has really been rendered (there is no "onrendercomplete" event). This means that even after the onload event, the CPU still being used by the browser to render the page. What I usually do in situations like this is to add two indirections. First, attach a script to the onload event to invoke a function that will create a time-event in a few seconds that will do the real initialization. In other words:
<body onload="setTimeout('init();',1000);">
Tip #14: Watch for Memory Leak
The biggest problem with browser's memory leak is that it doesn't affect only the page that created the leak, it affects every single page from any site after that. Internet Explorer is notorious for its massive memory leaks (becase of poor JavaScript). There are a few tools on the Internet to find out if your script is causing memory leak and where. The easiest test is to load your page 100 times and watch PerfMon to see if the Working Set is growing or not. The most simple thing that you should do is to unbind every event that you bound to (dynamically), and to release every reference possible (this also helps the JavaScript garbage collector to be faster).
Conclusion
If you have no clue what I talked about in one of the topics above, either you really don't need to know about it, or, you should immediately go buy some books, and I recommend all books by O'Reilly, like:
Dynamic HTML: The Definitive Reference - by Danny Goodman JavaScript & DHTML Cookbook - by Danny Goodman HTTP: The Definitive Guide - by David Gourley & Brian Totty Web Caching - by Duane Wessels
Footnote: This is a re-edition of an old post on my old blog.
I just figure out my Rank at Technorati is 574,980. Since they are tracking more than 50 million blogs, that puts my site on the top 1% of all blogs. That is good or bad, depends how you look at it.
My goal on the next 6 months is to move my blog from the top 1% to top 0.3%. Since the blogosphere is doubling every 6 months, that means 100M blogs and my blog rank must be in the 300,000 or so.
So, I'll write a lot of interesting stuff, not like the crap that I've writing so far. :)
UPDATE: Decio pointed out a flaw on my math. I thought I was at the top 10%, while I'm already on the top 1%. So, my new goal is to make to the top 0.3%.
I just got an email from UPS that I was 99.9% sure it was spam. Turns out it was a legitimate email, but it was poorly done.
First the message comes from "QuantumView [QuantumViewNotify@ups.com]". Seriously? Is that the name that you guys choose? I'm sure it is some kind of internal tool or service on UPS, but as a customer it couldn't be less effective. Couldn't it be called "UPS Shipping Notification" or something less bizarre.
Then it comes the title of the message:
"UPS Ship Notification, Tracking Number 1Z341YAY21587224761"
Ok, not bad, at least it says it is a UPS package info with the famous UPS tracking number, but it doesn't really tell me anything. It looks like spam. If it has a link on the body it sure must be spam (wait, there is a link in the body of the message!)
There is two mistakes on the title, first, it doesn't tell me who is it from, nor tells me that you guys know who I am. Next time, try this.
"UPS Shipping from Digital Room to Marcelo Calbucci"
Just by having my full name on the title is a big plus. Most spammers only figure out "marcelo" because that is the email alias. Telling who is shipping the content also helps because you'll immediately identify what it is. UPS knew about Digital Room because it appeared on the body of the message.
Now, the worst part of the email is the body. It has a lot of legal disclaimers right at the top, it has the shipper ("Digital Room") buried in the middle of the legalese, and it has a poorly formatted content, all in black, that makes it extra harder for me to see my name, the content being shipped, the tracking number.
My suggestion for emails like these, are to stack rank what are the 3 most important things that you want to get across. Put them right at the top, easy to identify and read, and then add all the crap from the Marketing team, from the Legal team, from the great guys from IT at the bottom. On the case of this message, the 3 most important things are:
Who shipped the content;
What is the tracking number;
When is it expected to arrive.
There was one super cool thing about these email: It didn't have any embedded or linked images.
Subscribe to this Site
(what kind of site/blog are we helping users to build)?), my hand decided to bail on me this weekend. I'm having another tendinitis crisis. I have that once or twice a year and usually is a reflection of a week where I worked (typed) a lot, like last week.
November, 2007