Online mapping services like Bing Maps and Google Maps are an outstanding addition to just about any website that has a physical tie to planet Earth.
The fact that both require no software purchase and have fairly complete API’s (that’s Application Programming Interface – it lets our programmers hook into all that mapping information easily), and offer compelling mobile experiences only help in their adoption. We’ve used them in the past with quality results.
We’re just about ready to launch a project that has some pretty heavy Bing Maps functionality built into the user interface. The client’s Location Search is built almost entirely around it (with, of course, a non-map based alternative for users who can’t see the map and for browsers who can’t handle it).
It’s been an effort influenced by almost every group here at Atlantic BT with User Experience, Design, Marketing and most definitely Programming contributing to the outcome.
We spent considerable time working out how this map’s output could be interacted with by the site’s users:
Does clicking on a map “pin” take the user to the location page? Bing Maps has no default action for pin clicks, but the more popular Google Maps does. Do our users even know that they’re looking at a “Bing” map, or is it just an interactive map to them?
Does sliding the map around update the text results adjacent to it?
How does the search radius change when the user rolls their mouse scroll wheel?
And the most important question – how far can we safely deviate from what the users expect the map to do? Where is that sweet spot between allowing exciting new features and not frustrating uses?
Our discussions brought up two really important points that we want to remember going forward:
Highly interactive and open-ended page elements like embedded Bing and Google maps require extensive planning if you want them to be truly awesome and if you want them to feel like a natural part of your site.
These services’ wide adoption rate means a wide range of user types with different skills and very different expectations. What we make needs to be flexible and forgiving for many different types of users.
Are there differences in application architecture that are important for the cloud?
It is important to build applications and workloads specifically for the cloud. You will want to carefully consider what services the cloud provider of your choice has to offer and how your application leverages those services.
What’s the benefit of hosting in the cloud vs. traditional options?
Reasons not to host in the cloud are few and far between. If you don't host in the cloud, you will spend more in both CapEx and OpEx to manage your applications or websites in a traditional environment.
How can I improve the performance of my application?
There are several primary reasons that applications perform poorly, and in some cases it’s a combination of several. 1) Data latency: If your application is making calls to a data source (whether it’s an API or a direct call) and there is latency at the data provider, your application performance will suffer.
The answer is ‘probably yes’. There aren’t many reasons for an application to be hosted elsewhere, aside from occasional compliance standards, or requirements to integrate with local services that would require large amounts of data to move from on-premise to cloud.