Schmap is one of those elegant Web 2.0 applications that if you have anything to do with web development, you kick yourself for not thinking about it. Schmap provides travel guides through an integration of maps, travel data, photos, book recommendations and of course, the ubiquitous Google AdSense. In Web 2.0 parlance, Schmap is a mashup but it is so well done and with such a high level of sophistication that all the independent pieces that make-up this great WebApp integrate into a smooth and pleasant experience. For example, the Yahoo Maps are nicely implemented as a long vertical left-hand panel. I happen to think that of the big three Web Mapping API's (Google and MS Virtual Earth are the other two) Yahoo Maps is the most aesthetically pleasing. Yahoo Maps is also the latest to enter the fray which explains why is not as popular as the other two. Where Schmap shines is in the integration of its Yahoo Maps with a center-panel full of summarized content which is easy to navigate via links, tags and an intuitive “big” menu which further explodes into a right-hand panel with detailed information and additional references.
Most of the content for Schmap seems to be provided by wcities, a company specializing in "...compiling, and aggregating location-based information..." Now I am really kicking myself; My company, PROCON, has been providing this type of Location Based Services for our B2B Partners but it has always been tailored to emergency, roadside assistance and concierge services. How wonderful to see LBS implemented in an application available to the general public for the travel guide niche that Schmap has chosen.
What is striking about Schmap is how many photos are included on their website and how well those photos are integrated into the content. They are all beautiful pictures of every conceivable point of interest arranged in neat travel guides. When one starts analyzing the sheer number of quality photos available on Schmap, the obvious question is: Who is providing these photos? Well, I'll tell you who is providing that content: You and me and every other flickr and creative commons shutterbugs. Using one of the main tenets of Web 2.0, Schmap has recruited every Joe Schmoe with a digital camera to provide free quality content for their website. And why would anyone happily do that? Because, once all the social-networking is done, it is flattering to have a serious outfit ask for one of your photos, which they apparently thought was good and want to include in their travel guide website. Your photo may even help some other Joe Schmoe decide to visit one of Schmap's Top Attractions and snap a better shot than yours.
Schmap also provides a downloadable Player which is a desktop application that presents essentially the same content provided on the website. The Schmap Player provides a slightly better interactive experience than the website. However, the website is so exquisitely designed that the only reason I think anyone would use the desktop application is to have the travel guide content available off-line on a laptop. I did not get to test Schmap for the iPhone™ and iPod® touch but it looks apfel cool. I still have to test how well Schmap runs on a Windows Mobile device (On the skyfire™ browser, of course!) I hope, Schmap is making money from their superb effort; They obviously generate some income from the Google AdSense and Amazon Books recommendations but is difficult to tell if that would be enough to make this compelling Web 2.0 application a viable enterprise in the long run.
Schmap is so Web 2.0 cool that it also provide easy-to-build widgets that can be customized into fun and interesting content for other websites. The three Schmap widgets included in this blog are for the Toledo, Spain city guide which is where my selected flickr picture is included. The picture is grouped under the Churches and Temples points of interest. It is of the door to the Synagogue of Santa María la Blanca and part of a puertas series I shot on a wonderful holiday trip during Christmas of 2006. I think it is the worst picture I shot during that trip but probably the only publicly available one of that particular door. And it is included in the very cool Schmap website!
I received a most interesting email from a salesman of one of the cellular carriers my company uses to provide Location Based Services to our customers. We had been experiencing some technical difficulties that resulted in several of our customers not being able to communicate to our LBS devices. All LBS devices operate using the cellular networks, usually GSM although CDMA has a strong presence in the US because it is used by Verizon and Sprint. Our carrier has always been helpful and technically capable, good traits when dealing with problems that result from complex cellular issues such as SIM activation, roaming or HLR/VLR problems. Only after forming a task force with one of our most important distributors, the device manufacturer, the carrier and technical expertise within our organization, were we able to isolate the problem as an easy-to-resolve hardware issue and nothing to do with the carrier.
What caught my attention about the salesman's email was that he had attached a research paper from the Journal of Information Science and Engineering titled The Evaluation of Distributed and Replicated HLR for Location Management in PCS Network by Guan-Chi Chen and Suh-Yin Lee. I am certain that I was the only cc on that email who gave any consideration to this document. Although this salesman is technically savvy and always willing to get involved in the technical aspects of his job, sending that document was a clear indication that he had literally thrown in the towel. He was now reaching for any possible explanation, the more technically convoluted the better.
It reminded me of years past when I used to sell Alpha Micro mini-computers as part of "turn-key solutions" bundled with software I developed for the Field Service Management industry. I remember a specific incident when I made the same mistake that all technical salespersons make sooner or later: Over-reaching for far-fetched technical explanations that just do not make any sense, leaving the customer disconcerted and jeopardizing the trust the customer has placed on you: I had sold a new system with about fifty terminals that were attached to the computer system via RS-232 connections. My customer had a large building and we had pushed the limits of the RS-232 specification causing their brand new, and very expensive system, to crash almost on an hourly basis. I contracted wiring and electrical specialists to check for any electrical interferences which have always been a source of problems for RS-232 connections. I rewired my customers systems with special insulated cabling. I convinced them to upgrade their electrical systems; Nothing worked! Their new system still kept crashing with hourly regularity. In frustration, I explained to my customer that their system's problems could be caused by "cosmic rays" I had not pulled that explanation out of a hat. This was something that Alpha Micro had actually suggested as a possible problem. But the minute, I presented this possibility to the customer, it was obvious that I had run out of ideas and possible solutions, risking the hard-earned relationship of trust I had with my customer Luckily, Alpha Micro engineers got involved because this happened to be one of the first machines of their new product line. A little tweaking with the I/O interface provided the ability of using more robust RS-422 connections and that along with serial repeaters finally resolved the problem.
Owning a small software development company for many years taught me to wear many hats. Wearing the hat of a technical salesman was easy because I developed the software I sold, I picked the hardware and O/S that it ran on and I even picked the accounting system that my software integrated with. When you believe in what you sell and you understand the technical aspects of the product you are selling, you easily gain a level of trust from prospects. If one can hit the prospect's "hot buttons" and provide solutions to the prospect's problems, those prospects soon become trusting, long-term customers.
As an Alpha Micro Value Added Reseller, I had to take part in several sales training courses. Some of the most interesting courses had to do with selling leasing services. In my opinion, most sales courses make use of gimmicky techniques that eventually backfire. And most salespeople think that their success can be attributed to a special personal trait or a specific technique they have developed to "close the deal." This may be true for some types of sales but the most interesting and straight-forward facts I learned about salesmanship came from a small gem of a book titled The Lacy Techniques of Salesmanship by Paul J. Micali. Among the many salesmanship nuggets this little book contains, there are the following:
THREE THINGS [THAT] DETERMINE YOUR VALUE AS A SALESPERSON
- Technical knowledge.
- How much work you are willing to do (this along with technical knowledge controls the quality of your salesmanship).
- Personality (this element controls quality).
When technical problems arise, Micali's three things also apply, except in the reverse order: (1) A salesperson must have a strong personality to resist offering esoteric explanations to technical problems. (2) He must work hard to trouble-shoot the problems or to assemble and assist a technical team that can troubleshoot the technical problems and (3) He must have enough technical knowledge to be able to understand the possible causes of the problems and how to go about resolving them.
National Telecommunications and Information Administration
My company has Value Added Reseller relationships with several cellular carriers. That is because most digital devices used for Locations Base Services work over the cellular network just as regular cell phones do and thus they need a SIM that is provided and activated by a carrier. A delay in a VAR application to a big carrier caught my attention; The application had been properly filled and submitted weeks ago. However, we received a notice to get in contact with a special Department. The information requested was basic and already included in the application which me made question why this carrier was presenting this additional hurdle.
The answer was provided by the many articles popping in the business and IT publications; 1,122 licenses for a couple of slivers of the US radio spectrum are being auctioned off by the Federal Communications Commission. I suspect that our carrier is involved in these auctions and probably has to disclose or update information about its VAR's.
FCC Auction 66 is also known as Advanced Wireless Services (AWS-1) which "...is the collective term used for new and innovative fixed and mobile terrestrial wireless applications using bandwidth that is sufficient for the provision of a variety of applications including those using voice and data (such as internet browsing, message services, and full-motion video) content..." That has to sound exciting for not just for the gearheads and the geeks but for anyone that has a cell phone.
FCC auctions have always intrigued me. All kinds of new technologies are enabled by the availability of new frequencies, often resulting in revolutionary product and services. Remember when pagers were an essential business gadget? Cell phones evolved from a brick-size device we were willing to lug around just for the sake of instant communication. Today, nobody considers a cell phone unless it fits into a shirt pocket and has a combination of sophisticated built-in gadgets such as a music player, a camera, a video-cam, even a thumb-size keyboard so that we can respond to emails and surf the the net anytime, anywhere.
I think that AWS will result mainly in evolutionary rather than revolutionary products and services. Wireless broadband has been available from the major cellular carriers for a while. They are well on their way, implementing 3G technologies across the US. (And playing catch-up to Asia and Europe where the ubiquitousness of GSM makes the roll-out of new cell phone technologies easier) All the promises of 4G will be undoubtedly be enabled by the availability of the newly auctioned FCC frequencies. Over the last few months, we have seen the introduction of Verizon's VCAST Service that allows the download of music and videos to Verizon phones from LG, Samsung and Motorola. Sprint has similar services but what I find most interesting is that one can now listen to SIRIUS Satellite Radio on a multimedia Sprint phone. This marriage of satellite and wireless is not going to be limited to cellular carriers offering satellite-only services over their networks as the bidding for Auction 66 clearly illustrates. The most aggressive bidders so far has been a group that includes DirectTV and and Echo Star Communications. The analysts believe that the satellite-TV operators do not want to be left out of the multiple service offerings that cellular carriers and cable companies are providing now and will keep on improving with AWS.
So will AWS just mean video bilogging on every cell phone? That's already happening and the blogosphere is using it in some creative ways that will keep on challenging traditional media. What could be really wonderful is if Google and Yahoo finally deliver on their half-hearted efforts (Google WiFi and at&t Yahoo) and actually start delivering their contents on their own backbone in a new innovative way; A good chunk of those AWS spectrum slivers would make that possible!
The other intriguing factor of FCC auctions is all the rags-to-riches stories that are now part of the history of the telecommunications industry. Even today, there seems to be some opportunities in FCC Auction 66, according to Information Week:
"...The FCC has divvied the spectrum into hundreds of rural licenses--rather than a handful of licenses that span large geographic areas--making it easier for smaller providers in remote cities and towns to bid. They also get a financial advantage in the process; smaller providers that bid on spectrum are required to pay just 75% to 85% of their winning bidding price, according to FCC rules, while large providers pay 100% of their winning bids..."
I wonder if anyone has yet bid for the Northern Marianas?
Developers are familiar with the reams of documentation that usually accompany an API or SDK. Help files integrated into development tools are of great help such as the MSDN integration into Visual Studio and Intellisense. However, when dealing with programmers that seem bent on keeping everyone else in the dark, no amount of Intellisense is going to be of any help. This is specially maddening as it applies to what is supposed to be the .NET holy grail of "...information anytime, anywhere, on any device."
The following should look familiar; It is a Web Service's .asmx page that .NET automatically generates along with the WSDL to be used by the Web Service consumer. The .asmx page is the deployment interface of a .NET Web Service. It provides a testing mechanism and lots of information if one is into parsing XML in one's head. A major deficiency of the .asmx page is that the only sections available for the developer to document the Web Service seem to be one-liners extracted from the code, specifically the WebService and WebMethod descriptions attributes as in:
<System.Web.Services.WebService(Description:="PROCON Web Services for activation of retail Customers.", _ Namespace:="http://webservices.poweredbysat.com/PartnerIntegration")> _ Public Class PartnerIntegration Inherits System.Web.Services.WebService ... <WebMethod(Description:="Credit check for retail Customers.")> _ Public Function CreditCheck(ByVal PartnerID As String, _ ... <WebMethod(Description:="Activation for retail Customers.")< _ Public Function CustomerActivation(ByVal PartnerID As String, _The term "self-documenting code" is computerese for either "I am too lazy to document my program!" or "I am such a great programmer that if you don't understand my code you should not be allowed to peruse it, let alone maintain it!" But a self-documenting Web Service makes perfect sense because there is no better way to document it than right there where the Web Service is being deployed!
So how can a .NET Web Service be documented given the meager resource provided by description attributes? Wouldn't it be neat if we could just include HTML in the description of our Web Service as some .NET Web Services resources seem to suggest? Unfortunately, HTML tags included into Web Services' description attributes will not be interpreted as HTML in the .asmx page but will instead be rendered as text! However, once we understand that the .asmx page is generated from a default template then there are many possibilities for documenting a Web Service. Before hacking the DefaultWsdlHelpGenerator.aspx template, here is the criteria that I wanted to follow for documenting Web Services:
- Keep the consistent style of the .NET .asmx page and its testing and WSDL functionality.
- Avoid any changes that would alter the definition of the WebService and its WebMethods such as extraneous variables or additional coding.
- Separation of the HTML documentation from the WebService code and no need for recompilation or redeployment of the Web Service if changes are made to the HTML documentation.
- Allow for the default operation of the .asmx page when needed so that it can always be tested and not be suspect because of the changes made to enhance self-documentation.
- Since the information been documented will probably be best presented in some sort of tabular form, it would be nice to this painlessly (Unless one is an HTML table masochist!)
Once I customized the WSDL Help Generator template there were only very minor changes necessary to implement a self-documented Web Service. Following are the changes necessary to the WebService and WebMethod description attributes. It should be intuitive that the documentation is included in external HTML files named for the WebService and WebMethods.
<System.Web.Services.WebService(Description:="PartnerIntegration.htm", _ Namespace:="http://webservices.poweredbysat.com/PartnerIntegration")> _ Public Class PartnerIntegration Inherits System.Web.Services.WebService ... <WebMethod(Description:="CreditCheck.htm")> _ Public Function CreditCheck(ByVal PartnerID As String, _ ... <WebMethod(Description:="CustomerActivation.htm")< _ Public Function CustomerActivation(ByVal PartnerID As String, _
Following is an example of what is possible when documenting a Web Service through external HTML files included in the rendered .asmx page.
Clicking for a full description of the CreditCheck WebMethod will show the following:
Here is a link to the working self-documented Web Service. As previously discussed, this is possible because I have customized my WSDL Help Generator template which can be downloaded here (Save Target As... & remove ".txt" from the filename, since it is an .aspx page!) The customized WSDL Help Generator template should be placed in IIS Server's <Windows System Folder>\Microsoft.NET\Framework\<.NET Framework Version>\CONFIG directory. It will not overwrite the original DefaultWsdlHelpGenerator.aspx template. It that is not possible or desired, the customized template can simply be deployed in the same directory as the .NET Web Service. To override the default WSDL Help Generator template, the following will have to be included in the .NET Web Service's web.config <system.web> section:
<webServices> <wsdlHelpGenerator href="WsdlHelpGenerator.aspx"/> </webServices>
Notice that the description of the WebMethods is extended in their individual documentation/test pages but only a short paragraph is included on the top page. This allows for the top page to provide an overall description of the WebService and list all the WebMethods without including the extensive documentation that should be part of each individual WebMethod. This is accomplished by enclosing all the HTML that should be listed in the top page in <description> tags. For example, the following HTML is for the CreditCheck WebMethod which provides a short description for the top page and the full documentation for the individual page:
Additional Notes & Resources:
<description> Credit Check for retail Customers. </description> <br><br> <pre> <u>Required Parameters</u> <u>Max</u> <u>Description</u> <i>PartnerID:</i> 20 Integration Partner ID for WebMethod Authentication. <i>PartnerPass:</i> 20 Integration Partner password for WebMethod Authentication. <i>Title:</i> 10 Customer's title ('Mr.' or 'Mrs.') <i>FirstName:</i> 30 Customer's first name. <i>MiddleName:</i> 30 Customer's middle name (May be blank) <i>LastName:</i> 30 Customer's last name. <i>Address:</i> 50 Customer's address. <i>Address2:</i> 50 Customer's address line2 (May be blank) <i>City:</i> 30 Customer's city. <i>State:</i> 30 Customer's state. (Two letter postal code) <i>Zip:</i> 9 Customer's zip. (5-digit postal code. 9-digit postal code if known) <i>PhoneHome:</i> 20 Customer's home phone number. (10-digit phone number including area code) <i>SSN:</i> 9 Customer's Social Security Number (9-digit SSN) </pre> ...
- Notice the <pre> tag in the HTML above. It encloses "pre-formatted" text that will be rendered with its normal spaces and carriage returns without the need to build HTML tables for rendering tabular data with the added benefit that it automatically fits the style of the original .asmx page for detailed information. Following is the HTML documentation for the WebService: PartnerIntegration.htm and its WebMethods: CreditCheck.htm & CustomerActivation.htm (Save Target As...)
- If an HTML file is not defined in the description attribute, then the text is treated and rendered normally which is the default behavior of the WSDL Help Generator template.
- The customized WSDL Help Generator lists WebMethods in alphabetical order which is an improvement over the random order that is the default behavior. This is helpful when a WebService consists of several WebMethods.
- I have decided to allow the HTTP GET/POST methods for testing my Web Service. There are several security vulnerabilities in allowing this functionality and it should probably be disabled in a Production environment. However, I feel that the testing capability should be provided, at least in a Staging server environment, so that the Web Service can be readily tested and debugged by a consumer. For instructions on how to enable/disable the HTTP GET/POST and testing capabilities and even how to disable the documentation functionality altogether, see this MSDN article.
- If the HTPP GET/POST testing will not work, it is usually a result of a bug in the Web Service. This seems to be always true if the result of the test page is an "HTTP 500 Internal Server Error". Several resources mention Windows permissions as an issue but I have been able to test Web Services successfully in a IIS6 server without giving additional permissions to the Web Service's directory (ASP.NET for IIS5 & IIS_WPG for IIS6) Apparently, in .NET 1.0, permissions to the <Windows System Folder>\temp directory had to be set, since this directory is used by .NET for XML serialization/deserialization.
- Debugging a .NET Web Service is a little more complicated than debugging an ASP.NET mainly because there is no visible user interface; See this MSDN resource for more information in debugging Web Services.
- There are many ways to secure a Web Service. For production purposes, I always implement my Web Services over SSL. For .NET 2.0, it seems that the newly available WS-Security Protocol is the preferred methodology.
- A known and reproducible bug in using a customized WSDL Help Generator is related to how the Web Service will be deployed. This problem will occur if the Web Service is not deployed under a website's root directory. I deploy my Web Services as a subdomain that is its own IIS website. The Web Service application is deployed as a subdirectory under a "\WebServices" directory and an IIS "Virtual Directory" under the subdomain. The Web Service URL is a little long but this scheme keeps things organized. Also, a simple HTML page can be created to catalog all the different Web Services that could be implemented as separate applications for whatever reasons.
- Interested in seeing the changes to the customized WSDL Help Generator that make self-documentation for .NET Web Services possible, as described in this article? Take a look at the .aspx C# source code and search for "HACK"!
Speaking of Google for searching addresses and phone numbers, if you include a City and State in your query you will get Google Local results with not just the address and phone information but also an embedded map which is, of course, a Google Map and that I have just discovered has now become Google Local; Google Maps is no longer in Beta! If you are interested in other Google Hacks, O'Reilly is a great place to start.
I recently heard about 1-800-555-TELL (1-800-555-8355) which is a phone service that provides all types of information via recorded messages and text-to-speech. I played with the service for about an hour and got mixed results. To start with, the speech recognition is somewhat frustrating, it doesn't always work plus the way the menu prompts are presented do not seem to allow for quick interruption and successful recognition of subsequent commands. The speech recognition seems to improve if you do not use a speaker phone. The service quickly becomes annoying because of the smarminess of the menu messages.The information available through the service is presented as follows:
- Stock Quotes.
- News Center: Weather, Traffic, Business, Technology, Entertainment News, Sports Update, Lottery & Time.
- Sports: All major professional and college sports including a couple of unexpected choices like Boxing and Soccer.
- Entertainment: Movies, Horoscopes, Soap Operas & Blackjack.
- Travel: Driving Directions & Taxi.
- Popular Shortcuts: A short list of the above.
Unless you are a teenager, using SMS to communicate is an exercise in futility. You can pretend to be up to speed and learn the lingo but wouldn't it be better if you could send a well formed text message that you could type? Like an email but not an email because although most business people can access their emails from their phones not everyone has this capability. It turns out that you can send a text message to a special email address and it will be received as SMS by any cell phone. The special email address depends on the recipient's carrier but it always starts with the full cell phone number as in "1" + Area Code + Phone Number (i.e. 19495551212 for (949) 555-1212). Following are most of the SMS email addresses for the US:
Paul English came up with the IVR Cheat Sheet™ which has been widely publicized by blogs and the news media because of the originality and usefulness of his idea. He created a list of major US companies, their 800 number and more importantly he documented the "steps to find a human" so that you won't have to suffer IVR (interactive voice response) hell or be subsequently aggravated by the long wait for a Customer Service representative. The conventional wisdom is that companies automate their systems to discourage an actual connection to a human operator. It will be interesting to see if companies adjust their system to adapt to Paul's hack. He seems to understand how telephony systems are put together and will probably figure out any changes to IVR configurations. He is also counting on getting feedback from the public at large to keep his useful database up to date. Paul also a page with other great phone tips.
Mobiledia provides a great Cell Phone Reception and Tower Search utility which is even integrated with Google Maps. It is an excellent way to determine the best carrier for your locale or to check for tower proximity which might prove invaluable when looking for good reception in a new area. Mobiledia allows this utility to be incorporated into any webpage, free of charge. All carriers have their coverage maps but if you have a GSM phone, GSM World has the most complete GSM Coverage Maps and Roaming Information to my knowledge.
Google Mobile provides an interesting array of tools if one has web access through the cell phone. It includes Gmail, a personalized Google homepage and Google Local for mobile which unfortunately does not currently work with Nextel or BREW enabled phones (Verizon, Alltel, US Cellular) or Palm devices. Most carriers include their own personalized mobile homepage and there are quite a number of interesting alternatives such as Yahoo Mobile. What is unique about Google Mobile services is that it provides Google SMS which is like the 1-800-555-TELL service except it is all via SMS. You submit queries to Google from your cell phone via SMS and Google responds back with useful information. I will probably not use this service much because I think I need to have a cheat sheet to properly form the queries. And if I have to access a cheat sheet, I would probably need access to my laptop, in which case I would use the real thing! I don't use the web browser on my cell phone and I often wonder if a Blackberry or a Treo would better serve my telecomunication needs. Sounds like a topic for a future blog entry!