A common mistake that is seen over and over again on the web is the presumption that business on the web operates just like business on Main Street. Big mistake and a recipe for disaster. Build it and they will come applies even less to the web than it does to Main Street. If you open a corner store on Main Street, at least some potential customers will stumble in out of curiosity. The store is there, it is right in front of their eyes. The web is entirely different. Building a web site and waiting for customers is like building a corner store in the middle of the woods and hoping that customers will come by before all the milk spoils. It's not going to happen. The site might offer the greatest widget in it's niche. It's still not going to happen. Not in a million years. Or more aptly, not in a million web sites. As of the writing of this screed, there are over 50 million active web sites. There are estimated to be 200 million active web users. The simple arithmetic suggests 4 users for every site. 4 users is hardly enough traction for a site to achieve any type of success. Friends and family could probably exceed this number handily. Even 4 users is overly optimistic given that the top 100 sites get the majority of the available eyeballs. The only way to get more than your fair share of eyeballs is to get out there and drag them in. In other words, plain old hard work. Every single day.
There are some things that thoughtful people need to take a stand on. Taking a stand means doing any little thing possible to help in a situation. Films and documentaries by social commmentator Michael Moore are often relegated to non-prime time slots on public television. This is a shame because the ideas presented ought to be made widely available and considered by the greatest number of people possible. To that end, you can read about his films at Michael Moore's site.
Related in theme, but just recently introduced, is the new satellite site for the Canadian Centre for Policy Alternatives, growinggap.ca - the growing gap between the rich and the rest of us
Of course, "think and link" has a certain ring to it, but really, it should be "think, comment, and link".
A rock solid application instills confidence in users. Unexpected results are disconcerting and frustrating for users. No matter how easily explained by the programmer, the user will not be a satisfied user.
For example, the title of this entry has an apostrophe in it. It's a punctuation mark that appears in many every day uses. But, certain uses of the apostrophe in combination with javascript will cause unexpected failures. This fact has probably hit every coder who has ever tried to use javascript in a non-trivial way.
The easy way out for the coder is to have the application refuse input of data fields containing the apostrophe. The harder way and the one that is riskier is for the coder to find all the places where the apostrophe will interfere with the application and code defensively around it to allow for the display of the apostrophe as intended by the user without blowing up the application. Guess which approach is going to make the user happier?
Harder work for the few, but many more happy users. Seems fair to us!
Come to think of it, the coder ought to feel some pride in taking the correct path rather than the quick way out.
Well, the regular expression was not quite right. While cruising the testing stats, we found a test spec that had been improperly truncated. Having a new bug crop up as a result of a previous fix is not to be encouraged, but it did give us a chance to demonstrate our approach to customer service. Yes, customer service. Even though our monitoring services are free to all subscribers, the subscriber is still, in our eyes, a customer.
An email was sent to the subscriber administrator querying what the host name should be with a promise of a manual fix and immediate attention to the code. In the meantime, the subscriber had sent an email reporting the problem and specifying the fully qualified domain name required. We manually corrected the data record, reactivated the test and informed the customer of the manual fix. In his words: "wow ...I did not expect to get it corrected that fast !!!".
Why wow? Well, the problem was reported at 4:07am, a remedy plan sent at 4:19am and a final resolution reported at 4:23am. Fixing the code took another couple of hours. We can't do this all the time, but we can try.
Just like you, we are tired of making telephone calls and sending emails to customer service departments which have no effect. This happens because in reality customer service departments never seem to have the tools or authority to fix problems. Good customer service reps can be as sincere and sympathetic as they like, but they are often by the reality the customer service departments have the purpose of screening complaints at the lowest cost.
We intend to bring back old fashioned customer service by directly responding to the specifics of every customer query. No canned responses allowed. We have the tools and authority, and we plan to use them to the fullest effect.
This is actually quite selfish. We fully realise the effect of dealing with customers well. A satisfied customer can bring new customers to the table much better than any sales or promotional effort we could possibly undertake.
It is often repeated by marketing types that keeping a customer is far cheaper than getting a new one. But very few organisations have studied the numbers. We did a spreadsheet forecasting subscriber acquisition rates based on varying rates of subscriber signups resulting from the recommendations of existing subscribers.
Being able to deliver good service feels good, but the numbers tell us that having great customer service is the only way to go. We hope other will follow.
Random occurences of missing daily reports have finally been fixed. This took a rather long time to find because of the difficulty of tracing executables running as system services. This was compounded by the fact that the process is scheduled to run only once a day.
A few users were able to insert testing url specifications for pages other than the home page. There was also an instance of an ip address being used in the host specification. These anomalies have been remedied in the regular expression that validates the requested url.
Users who subscribed in the last few days were having duplicate account records inserted into the database. While one of the accounts was dormant, it cascaded into the alert destination insertion routines. This caused every requested alert destination to be inserted in duplicate. The database has been cleaned up and the code error fixed.
Netscape and Firefox users can now do everything from the comfort of their home browser. A minor bug affecting one javascript action link was fixed. An obscure incompatibility, but easy to fix once found.
There must be a homework assigment due in the next few days on 5 9's uptime. The hits from the search engines are all showing these keywords as the query in the referrers. Well, we hope the information helps. Especially, the uptime calculation table.
Well, the main site and the services behind it have launched publicly.
That means that there is a need for a place to interact publicly. A place to write down all the stuff that comes to mind that does not fit into an faq or news release section.
The site launch also means that there is finally time to write without feeling that there is something else that should be done.
This is because the greater part of running a site is not the coding, but taking care of the users.
The software behind the uptime journal is about as simple as it gets. There is none. The page is handwritten in plain text and included in a template. Simple and effective. No software of any kind to install.
It may not be the way to go for anyone else, but for us this seems to be the easiest way to get going.