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!

Labels: flickr, lbs, schmap, web20

Image courtesy of
Visipix.com

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

1. Technical knowledge.
2. How much work you are willing to do (this along with technical knowledge controls the quality of your salesmanship).
3. 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.

Labels: cell, lbs, sales

United States Frequency Allocation Chart
available from
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?

Labels: cell, fcc, wireless

Image courtesy of
Visipix.com

<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, _
                                

• 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!)

<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, _
                                

Required Parameters   Max  Description

    PartnerID:        20   Integration Partner ID for WebMethod Authentication.
    PartnerPass:      20   Integration Partner password for WebMethod Authentication.
    Title:            10   Customer's title ('Mr.' or 'Mrs.')
    FirstName:        30   Customer's first name.
    MiddleName:       30   Customer's middle name (May be blank)
    LastName:         30   Customer's last name.
    Address:          50   Customer's address.
    Address2:         50   Customer's address line2 (May be blank)
    City:             30   Customer's city.
    State:            30   Customer's state. (Two letter postal code)
    Zip:               9   Customer's zip. (5-digit postal code. 9-digit postal code if known)
    PhoneHome:        20   Customer's home phone number. (10-digit phone number including area code)
    SSN:               9   Customer's Social Security Number (9-digit SSN)

Returned values            Description [CCReturn Class]
    ErrorCode:             0 = CreditCheck OK.  Non-zero value = CreditCheck failure. (See next section for Error list)
    ErrorDesc:             OK or description for CreditCheck failure.
    ConfirmCC:             Credit Check confirmation code. (8-digit number. 8th digit is a Modulo 10 Check Digit) 
                           Valid ConfirmCC must be submitted to CustomerActivation WebMethod


    ErrorCode              ErrorDesc
          0                OK
    CC10000                Credit declined. Generalized result with no specific reason provided.
    CC20000                Credit Check could not be completed by Bureau.
    CC30000                Integration Partner could not be authenticated.
    CC31100                Parameter Title missing.
    CC31200                Parameter FirstName missing.
    CC31300                Parameter LastName missing.
    CC31400                Parameter Address missing.
    CC31500                Parameter City missing.
    CC31600                Parameter State missing or invalid.
    CC31700                Parameter Zip missing or invalid.
    CC32100                Parameter PhoneHome missing or invalid.
    CC33100                Parameter SSN missing or invalid.
    CC900XX                ConfirmCCs_New SQL Stored procedure failure XX.
    CC99990                WebMethod implementation error (Actual error included).

 <webServices>
  <wsdlHelpGenerator href="WsdlHelpGenerator.aspx"/>
 </webServices>

 

<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"!

Labels: .net, webservices

Image courtesy of
Visipix.com

• 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.

• AT&T:
  FullCellPhoneNumber@mmode.com
• Cingular:
  FullCellPhoneNumber@cingularme.com
• Nextel:
  FullCellPhoneNumber@messaging.nextel.com
• SprintPCS:
  FullCellPhoneNumber@messaging.sprintpcs.com
• T-Mobile:
  FullCellPhoneNumber@tmomail.net
• Verizon:
  FullCellPhoneNumber@vtext.com
• Virgin-Mobile:
  FullCellPhoneNumber@vmobl.com

Labels: cell, wireless

Image courtesy of
Visipix.com

Labels: cell, wireless