ArcGIS support Direct Access to Spatial DBMSs

According to ESRI, "At 10.1, ArcGIS will support direct SQL access to all the leading DBMSs including SQL Server, DB2, Oracle, and Postgres. This will include direct access to native spatial data types in each of these systems. ArcGIS will support working with these spatial databases as easily as it works with geodatabases. For more complex spatial data and transactions, users will use the ArcGIS geodatabase environment ( i.e., topology, rasters, networks, replication, and archiving)."

Also, finally, "No. ArcIMS 10 was the last release.  Its entire functionality has been replaced by ArcGIS Server. ArcIMS users have been provided upgrade paths to ArcGIS Server for a number of years. There are many reasons to migrate to ArcGIS Server including performance, capability, quality of mapping, functionality, and ease of administration."

Canvas maps from ESRI - Neutral Basemaps

By Mamata Akella, Esri Design Cartographer, and Kenneth Field, Esri Research Cartographer

Online web mapping is fast becoming the de facto format for authoring, sharing and publishing authoritative geospatial information. With the introduction of platforms such as ArcGIS.com as well as Esri’s JavaScript, Flex, and Silverlight APIs, the mechanisms to create high quality web maps are in place and provide extensive tools for the design and production of great online content. As several members of the Mapping Center team played a significant role in the design and production of this map, we would like to begin telling you about the new Esri Canvas Maps. In the first of two blog entries we share with you the idea behind Canvas Maps: a new set of online basemaps specifically designed to give users a neutral ‘canvas’ on which to better display data. Here, we explain the philosophy behind the cartographic design of the Canvas Maps. In Part II we will illustrate some specific ways in which you can use the new Canvas Maps effectively.

Online mapping places demands on basemaps to provide the backdrop to user data and the operational overlays they want to map. Basemaps should provide a way of supporting communication of operational overlays which, in turn, is crucial in supporting effective delivery of the map’s message. From a designer’s perspective the goal is this: make a visually compelling map that tells a story about a place or a theme of information and that most importantly, helps its user’s understand the story being told. This is a core concept in designing maps whether they are for print or web and Canvas Maps are an exciting new way in which user data can shine more brightly.

In any map, the graphical structure of the map content goes a long way to determining how effective the map is. We achieve that by varying the relationship between a figural component (the foreground of the map) and the background contextual detail. We might also establish certain hierarchies amongst map components, modify symbols to make certain ones more visible in the composition or we might visually contrast certain components to modify a component’s visibility. This is often a complex iterative process and usually requires full control over all the layers of data to organize them effectively.

With online maps we’re often using a published basemap service which we have very little control over. Esri publishes a range of basemaps to support online web mapping. Many of these have been used very successfully but they do not function for all mapping needs. This limitation means many web maps contain too much information that competes for visual attention which makes it difficult to see all of the interesting patterns in the operational overlays. Not every theme of information is meant to be mashed-up with a street map or a topographic reference map both of which have specific uses. Canvas Maps are different in that they provide a way for users to build better graphical structure into their maps simply by using a different type of basemap. The cartography of the basemap has been designed to be subtle and provide a more effective basemap for operational overlays to shine. Let’s take a closer look over at the basemap deli counter and see what the new Canvas Maps look like.

Less is more…by design

The fundamental idea behind Canvas Maps is that less is more. Excluding information by design provides a true canvas from which you can start working. By using fewer colors as well as displaying and labeling fewer features, we’ve built into the basemap a way to support improved figure-ground relationships and visual contrast in relation to the operational overlays. The figure (important map object or theme) is reserved for your information while the ground (less important object or theme) is the basemap and this has the important function of drawing more attention to the map’s main theme. Because the colors in the first of our new Canvas Maps are toned down and based around a light gray palette this also assists in creating effective visual contrast between the basemap and operational overlays.

To illustrate this concept, figure 1 shows the Global Distribution of Seagrass overlaid on the World Street Map basemap (right) compared to the same data (and same symbols) overlaid on the new Canvas Maps Light Gray edition. With Canvas Maps Light Gray (left), the distribution of global Seagrass is clearly the” figure” and the base information sits unobtrusively in the “ground” while still providing geographic context to associate with the theme. There is a much improved contrast between the operational overlay and basemap which supports legibility. In contrast, Seagrass distribution lacks legibility and visibility on the World Street Map (right) because the basemap simply isn’t suited to display the data as it is too detailed and colorful.

Figure 1: A comparison view of global seagrass distribution overlaid on Canvas Maps Light Gray (left) and World Street Map (right).

Figure 2 illustrates how we’ve drastically decreased the amount of content on Canvas Maps in comparison to our other online basemaps like the World Topographic Map. At each scale, we carefully selected colors, features, and labels that would provide a subtle background on top of which thematic information would ‘pop’; a term we use to describe how operational overlays can be made to be vibrant and immediately seen by the user.

Figure 2: Feature and label density are greatly reduced with Canvas Maps

Canvas Maps still contain a lot of contextual detail though. They contain administrative boundaries, hydrography, transportation, and cultural features yet the detail has been carefully stripped down to the bare minimum to provide a relevant contextual backdrop for overlaid data. Figure 3 illustrates which basemap layers are used at a particular scale level. You’ll note that up until the caching scale of approximately 1:144,000 we do not include many local area features which supports thematic (particularly statistical) map design at mid and small scales. The feature and label content that is added at larger scales is symbolized in a subtle way so the basemap continues to serve as a canvas but with greater detail to give context to larger scale map of a local area (figure 4).

Figure 3: Feature and label patterns at each Canvas Map caching scale

Figure 4: More content is added to the basemap at larger scales but symbolized in such a way to still support the effective depiction of operational overlays.

Canvas Map Light Gray uses a predominantly monochromatic color palette. By designing the map this way, we are promoting visual contrast between the basemap and operational overlay by design. By taking this approach we have opened a wider range of color space for use in operational overlay design. Quite simply, users have more colors to work with without fear of creating a clash with those on the basemap. Our blog post Designing Operational Overlays for the ArcMap and ArcGIS Online Basemap is a great resource to learn more about basemap and operational overlay design which discusses this philosophy. The Light Gray Canvas Map works particularly well with operational overlays that are symbolized using colors that are higher in saturation and/or lower in value. Such maps are clean and modern in appearance and work particularly well online to create eye-catching visualizations of your data.

Canvas Maps Anatomy

In a previous blog post about the Map Sandwich we described the release of our Terrain with Labels service on ArcGIS Online and how the design allowed you to insert data between a basemap and the textual components provided as separate services. Canvas Maps are also a type of Map Sandwich. The bottom map service depicts land, water, administrative boundaries, and labels for all features other than cities. The top map service holds city labels with thematic information (your operational overlays) sandwiched in between these two services – hence the sandwich metaphor. Consider the Canvas Maps as a development of a new range of artisan sandwiches…a sandwich for the connoisseur now available at the Esri basemap deli counter

Using this pattern, there is always geographic context associated with the operational overlay. Figure 5 is an example of the Light Gray Canvas Map mashed up with votes from the Esri FanMap Bracketography Edition web map application. Not only are we able to clearly see the patterns in voting due to the use of the Light Gray basemap, we also see voting patterns by city because the city labels sit on top of our theme.

Figure 5: Canvas Map Light Gray as a new artisan styled map sandwich

One of the main uses for the Canvas Maps will be to support improved online thematic mapping for which topographic detail is rarely required. Statistical maps are often most useful when the basemap recedes into the background. The ability to show choropleths, proportional symbols, dot maps and other common thematic detail will be greatly supported by the ability to do so using the new Canvas Maps.

Availabilty

Currently, Canvas Map Light Gray covers the world to the caching scale of approximately 1:2,000,000. Coverage extends in North America to approximately 1:9,000. Over the next few months, we will add more coverage for the world to align with our other ArcGIS Online basemaps.

This web map will be added to the basemaps available in the ArcGIS.com map viewer and ArcGIS Explorer Online soon. Simply click one of those links to launch the interactive application of your choice, and then choose Light Gray Canvas from the basemap control to start using this service. In the meantime you can access Canvas Map Light Gray here. In the near future you will also find this service in the basemap gallery in ArcGIS Explorer Desktop and ArcGIS Desktop 10.

As we mentioned at the outset of the blog, Canvas Maps is a collection of maps and Light Gray is the first release. We are currently working on Canvas Maps Slate edition which many of you might have seen in some of Mapping Center’s recent web map applications including our Super Bowl FanMap and our FanMap Bracketography Edition. Canvas Maps Slate will follow the same design philosophy as Light Gray. The only difference between the two maps is the color palette used to symbolize the map to create a dark backdrop in support of those who wish to explore a more radical design approach. Figure 6 gives you a sneak preview of Canvas Maps Slate.

Figure 6. Forthcoming Canvas Maps Slate Edition showing small and large scale excerpts.

The best maps are about… the theme being mapped. For most themes, less is actually more and the basemap should be a support to the map, not detract from its ability to communicate. Canvas Maps have an elegant, clean and minimalist design that enables users to build, share and publish high quality web maps with a fresh appearance; and one that fundamentally supports figure-ground and visual contrast out-of-the-box. Let us know how you get on with this new basemap and look out for Part II of this blog that explores ways of using the Canvas Map Light Gray Edition to support your cartography.

Canvas Maps are created by Mamata Akella, Wesley Jones, Andrew Skinner, Corey LaMar, James Shimota, Jim Herries and Robert Jensen.

This project was a new venture so we got a lot of support from many others including Clint Brown, Allen Carroll, Charlie Frye, Deane Kensok, Kenny Ling, Damien Demaj, Kenneth Field, Bern Szukalski, Aileen Buckley, Tim Daly, Laurie Fitzpatrick, Elena Bulat, Carla Wheeler, Craig McCabe, David Asbury, Ginger McKay, Rupert Essinger, Keith Mann, Lisa Thouas, Maria Lomoro, Mark Smithgall, Owen Evans, Victoria Kouyoumjian and Vivek Gupta. Thanks!

Flash vs. HTML5

HTML5 is hot.  The echo chamber is loud and everywhere you turn; blogs, social media, trade magazines, and corporations, are heralding it as the silver-bullet for everything—and more. It’s magical.

But what is the current reality of HTML5 for Advertising Agencies and their Digital Production partners? And what does it mean for those concepting and developing real client campaigns with real business goals? The question isn’t “Is Flash Dead?” But rather “What’s the best solution to this problem?” Both HTML5 and Flash are amazing solutions to our web executions, each with their own pros and cons.

Let’s Flash-back

It’s difficult to have this discussion without first looking at Flash and where it has fit into the picture for the past decade. After all, this is what HTML5 is slated to replace:

For the agency teams working on a digital concept for the next big campaign, targeting Flash as the development platform meant they could focus on the concept and creative rather than the technology.  Once Flash had matured, there was a solid track record of prior art showing that just about anything they could come up with was possible and could be built by the right production partner. And if there wasn’t a clear way, the best developers would come up with one. Papervision 3D was a great example of that. Flash did not have 3D capabilities built in, but the top developers in the community made it happen. And when they did, 3D in Flash was now possible in every browser on every operating system, immediately.

It was a great ecosystem for those involved.  Creatives could come up with big ideas and feel confident they were possible, without having to worry too much about the technology.  Developers were pushed to do some amazing work and often did amazing work on their own, which lead creatives to great new ideas.  One developer invents PaperVision 3D, another one figures out Augmented Reality Markers and next thing you know we have a live Big Foot interacting with you live on your webcam (www.livingsasquatch.com).

With any new project brief there are several things we want to look at to decide if it is a project we’d want to pursue. The core of which are:

1. How will we do it?
2. How much time will it take?
3. How do those two items compare to the available budget and timeline?

Budgets will vary, but timelines are rarely long enough.  Flash gave us the luxury of predicability.  We could predictably estimate the time a project would take and the development techniques used to achieve the end result were generally clear.  Rather than targeting and customizing a launch for a slew of unpredictable browsers, we are only targeting one platform: the Flash runtime, which will run with 99% consistency across all browsers.

And we knew that rarely would someone come to us with a crazy cool idea that wouldn’t be possible. Whether it involved 3D, user generated content, webcams, sound, microphones, interactive video, Facebook integration, or whatever other wild campaign ideas our partners or us dreamt up. It was rare that we felt limited by technology when targeting the Flash platform.

The HTML5 catalyst

Mobile has been the true driver of HTML5 on the desktop and elsewhere.  Without the success of the mobile platform, pioneered by Apple, then followed by Steve Jobs infamous words against Flash, the methodology of how sites should be built for the desktop would not have changed from 3 years ago.

Prior to mobile’s success, there have always been sites with requirements making them best suited for HTML.  They are easy to identify and usually are heavy on content, light on interactivity, animation, sound, and video.  Because these are generally simple sites, browser incompatibility tends to require minor work arounds and has limited impact on time and budget. On the flip side, for any site intended to be highly interactive, Flash was always the clear choice. Allowing you to develop freely, forgetting about browser compatibility.  However, now mobile is big and must be considered with most projects, and Flash usually isn’t an option on mobile browsers.

Is HTML5 the Flash Killer?

So here we are today where a belief has been manifested that HTML5 can do everything that Flash can do and it works the same across desktop and mobile. So Flash is dead?  An article on a popular blog was recently linked to in my twitter feed, it proposed a list of “7 Killer Flash sites that should be remade with HTML5 and CSS3.” (http://tnw.co/wJfrjm)

Unfortunately this isn’t a reality and articles such as this continue to spread a fallacy of HTML5 being the new answer for everything. It remains far more complex of an issue and HTML5 cannot do everything Flash can.  In reality trying to create these sites in HTML5 is more like “Mission Impossible” and most of them would need to be re-concepted from the ground up; with creative and user experience design that was tailored to HTML5′s capabilities.  Could the ’Ethan Hunt’ of HTML5 Development pull it off? Maybe in a few cases, but what would be the cost and what percentage of the target audience will be able to view the site?  I know that with Flash sites, most clients were unwilling to allow a site published in the latest version of the Flash player until it reaches higher that 95% penetration.  Will a WebGL site that 50% of your visitors can use really be acceptable?  And we’ll often get briefs for Flash projects that have as little as a two or three week development timeline. Good luck with that in HTML5.

Ironically, most of the cutting edge, Flash-like HTML5 sites you see these days don’t work on tablets or smart phones either.  They either use HTML5 features that aren’t available in mobile browsers (WebGL), offer poor performance (Canvas),  or the layout and user experience design does not work properly.  This is perplexing since the primary argument for dropping Flash is compatibility on Mobile.

The technology aside, there are other fundamental problems with trying to make one site fit all. Screen resolutions are all over the place. Can you really expect to design something for a  22″ desktop screen that will look good on a 10″ tablet (iPad), a 7″ tablet (Kindle fire) and 3.5″ screen (average smartphone)? You also may not want the same amount of content on your mobile site, as lots of people like to find necessary information quickly and prefer more immersive experiences on a large screen when they’re sitting comfortably.

Finally, you have the point-and-click world versus the touch-and-slide; this will affect everything from the size of a button (you’d make it larger for a finger than for a mouse cursor) to the user experience (sliding through a photo gallery on an iPad is a lot easier than clicking and sliding images with your mouse on a desktop site).

The best-case scenario would be to have the time and budget to create a specific site for each target. The best smartphone sites out there were designed specifically for the small form factor. That can be said about the best tablet sites (and apps), as well as the best desktop sites. This is rarely a realistic option for client budgets, though. We believe that right now when budget is a factor (and it almost always is), your best bet is to create 2 versions of a site. Target 2 platforms/devices with 1 version. Example: Make a HTML5 site that looks great on your desktop and works well on your tablet, then make a specific smartphone only site. Or, make a basic HTML site that works fine on tablets and smartphones, then make a specific desktop-only site that breaks the mould and delivers a unique experience. And in this case, why not use Flash?

The Graceful Degradation

We’ve noticed an interesting phenomenon as a side effect of the HTML5 buzz explosion.  Industry folk and the developer community seem to be expecting and accepting less from HTML5 sites than their Flash brethren.  Essentially, it takes far less robust of an end user experience for an HTML5 site to receive critical acclaim than with a Flash site; a sort of “HTML5 Affirmative Action.” You can see this in examples such as this: You have two “Graphic Novel” themed sites. The first an FWA award winning HTML5 site on January 30th, 2012 (http://www.soul-reaper.com/). The site features lovely illustration and a single auto scrolling page with some simple animations; continuing the “Single Scrolling Page” theme we are becoming accustomed to seeing day in and day out. To the non-techy end user, this is a nice looking site, but it doesn’t offer much in the way of an experience. Now compare that with the second “Graphic Novel” themed Flash site from 2009: Team Geist. Also an FWA award winning site, it features a uniquely concepted game that combines Live Action Cinema, 3D, Visual Effects, Game Strategy, Social Integration, all in a tightly woven package built in Flash. It required a large production and development team across multiple disciplines; as seen in the Behind the Scenes features here: http://www.northkingdom.com/case-studies/adidas-teamgeist/.

Truth be told, this has actually created a solid advantage for using HTML5 as a means of generating buzz in the developer communities. It takes far less of a commitment of time, resources, and innovative thinking to create a site deemed buzz and award-worthy (though a chunk of time will now need to be devoted to debugging and browser compatibility solves).  This, however, assumes your target audience are those in the community around you, who care mostly about the trends and the nitty gritty tech of how a site was built. If that is not your target audience, then you may not be meeting your client’s goals of reaching a larger non-tech savvy audience. How long this phenomenon will last is still uncertain.  If the innovation hits a ceiling due to technical limitations or continued browser limitations, we could see a shift back before the next 100 parallax scrolling single page HTML5 sites hit the web.

.NET magazine recently released an article about the “15 top web design development trends for 2012” in which seasoned designer Tom Muller predicts Flash will surely survive, certainly in the near-term. He explains that during 2011, he was involved in 3 major projects that relied on Flash, simply because it remains the best tool for interactive video, animation and 3D online. He added, “Web designers and developers sometimes lose sight of what works and is demanded by a larger audience, due to preferring what’s considered ‘cool’ in their bubble”, and that “More big brands will shift from Flash, testing the water with HTML5 and CSS3 for focussed campaigns. But for entertainment sites, Flash is – and will remain – the predominant tool of choice to create engaging experiences.”

One certainty in HTML5′s future is that the pace of innovation will be slower than anyone would like.  Instead of a situation where we rely on one company to innovate and release new features (in the way that Adobe does with Flash or Apple does with iOS), we are relying on a standards board to decide on features and then four browser manufactures to implement them.

Furthermore, once the browser manufacturers implement them, users of each browser need to get the latest upgrade. And finally, with each browser comes a new set of bugs that developers need to create work arounds for.  For an inside look at how convoluted the web standards process can be, have a look at the following excerpt from the book HTML5 For Web Designers – by Jeremy Keith.  The excerpt is from the opening of the book and details how HTML5 came to exist, it describes all the infighting going on behind the scenes. It is a true nerd war, including the big decision on whether it should be “HTML5″ or “HTML 5″ with a space.  Critical stuff.

For developers we have sites like http://html5please.us/ which tell us the features of HTML5 we can safely use and those that are broken or don’t work in specific browsers and need fallbacks. And while this site may be seen as a handy resource for developers, the fact that it exists at all should be a warning to anyone seeking to have a cutting edge HTML5 site developed. To look at this from another perspective:  Can you imagine if you wanted to build an iPhone application and as you dug in and referred to Apple’s documentation for various functions, you discovered that 80% of them didn’t work properly and you had to use work arounds, or did not work at all? That would be completely unacceptable. The reality is that closed development platforms such as iOS or Flash provide developers with an enjoyable and predictable experience.  If a bug arises with a feature of the platform, you only have to find a work around for one platform, not several browsers on two different operating systems.  Furthermore Apple and Adobe fix these bugs quickly in next release of their runtimes.  In HTML5 you rely on multiple browser manufacturers to fix bugs and broken features, and often this can take years. As in cases where Microsoft took as many as 10 years to fix a small issue.

The development community eventually comes up with work arounds as you can see on the html5please site, but what happens in the middle of a project when you discover a bug across multiple browsers that hasn’t been uncovered and solved by the development community?  Is everyone prepared to add weeks to a project timeline, and the correlating cost, to accommodate such scenarios?

A Hole In HTML5’s Video Armor

The HTML5 video tag is another good example of these headaches.  I’m going to single this out since so many of the award winning Flash sites of the past 5+ years have relied on video for the overall experience (Live Action and/or rendered video animations). And simply playing video in a self contained player is unarguably one of the core requirements of web sites, yet it is still extremely convoluted and time consuming to implement in HTML5.  Previously in Flash you simply rendered out one video file and loaded it in to play in your Flash video player.  It was guaranteed to work for 98% of desktop users.

Today with Mobile and HTML5 in the mix it is no longer so streamlined. Developer and author, Robert Reinhardt, recently wrote a blog post titled “The World of Pain that is HTML5 Video”  in which he discussed the issues with HTML5 video. At the core of it is the fact that the various browser vendors are pushing different encoding formats and there is no single format compatible with the current popular browsers; meaning you have to encode three different videos for desktop and then also mobile versions.

On a recent project we had roughly 30 different video animations in queue at any given time.  Having to encode three different versions of each, every time a creative revision came in, would have blown up our pipeline and caused us to miss deadlines.  You can just skim his blog post to get the idea of how complicated this issue is and in the end his conclusion is that currently the best strategy is Flash video on the desktop with fallback to HTML5, allowing you to encode in one format.  But this still relies on Flash to simplify things. If your site experience relies on using interactive or alpha channel video (pretty much anything other than playing video in a standard player), forget HTML5.  I personally know how complicated programming Flash video interactivity for a site can be, like our www.bankrungame.com site for example, and trying to do something like this in HTML5 will be 10 times more difficult; if not impossible in its current state.

In Closing

What we’ve tried to do is give a realistic look at what it will mean to target HTML5 for upcoming campaigns.  Based on the current buzz around it, people may not have a clear idea of the challenges involved with working around its limitations.  You want to make sure you chose the right tool for the job.

HTML5 is here to stay and often it will be the right tool, but if you try to force the technology on a project its not right for, it may come back to bite you.  Possibly via missed deadlines, budget overages, poor metrics due to limited compatibility, or a campaign that goes live full of bugs and a phone ringing off the hook with an upset client.

It may feel like overall tone of this article is negative on using HTML5.  That’s not the case, as we think it’s a great option for the majority of sites on the web. We simply aren’t excited about it as a definitive replacement for Flash.  HTML5 in its current state allows us to do less creatively with far more work, so we prefer the absolute creative freedom that platforms like Flash or iOS provide. We also don’t care about web standards.  Not to say they don’t have importance, but it is not what we are focused on. We are focused on concept, execution, and doing work that is motivating and enjoyable. Strategically we’ll continue to develop our HTML5 portfolio and use it when it makes business sense for our clients. Though we would be more excited about it if it allowed us to create end-user experiences that hadn’t already been possible at some time in the last decade.

Finally, here are a few logical guidelines when considering a strategy for new campaigns:

• Don’t decide on the technology until you figure out your audience. Is the primary target mobile or desktop? What percent of your audience is on HTML5 compatible browsers?
• Figure out your clients goals. Are they ok with you targeting a smaller audience for the sake of industry buzz and awards? Or are they more concerned with overall reach to consumers.
• Creatives concepting HTML5 sites need to learn more about the technology and limitations.  You can’t assume everything you would have concepted for a Flash targeted site will be possible in HTML5.  Especially if it is running on tablets and smart phones.
• If the goal is a highly interactive site on the desktop that will reach a maximum audience, use Flash.
• If a site uses interactive video and/or alpha channel video, use Flash and don’t expect the same type of experience to be possible on mobile.
• If the site only requires basic animations (think animating layers of a photoshop document) and video in contained players, use HTML5.
• Deep content/copy heavy portals, corporate sites, and blogs should be HTML. This has always been a good rule.
• If the same site needs to work on the desktop and tablet expect less (in terms of interactivity, animation, and innovative UX).
• If the same site needs to work on the desktop, tablet, and smart phones, expect a lot less.
• Be careful not to expect a robust HTML5 site to be built on a tight timeline. Extra time will be needed for build and more importantly QA/bug fixes. i.e. Don’t plan on approving creative two weeks before a site needs to go live.
• Understand that not all HTML5 features are created equal. Some work on mobile, but not desktop. Some work on desktop, but not mobile.  WebGL is a good example.  Currently it is not enabled in mobile browsers and Internet Explorer on the desktop.

Source:http://aarra.com/

GIS Mobile Developers

Is geo-spatial or location based mobile application development just a niche? Maybe most application development companies are focused on general mobile app development? Perhaps its because mobile is so new, that both clients and software development companies are still trying to fit mobile into their overall plan.

Mobile Location Services

The mobile location sector is very fragmented at the moment. On one side we have ESRI, the worlds biggest GIS company. They were slow in entering the Web, they are moving quicker with mobile, but their world remains GIS focused. And that is a niche no doubt. They have yet to broaden their appeal beyond their core, mostly public, GIS community.

Figure 1: ESRI ArcGIS running on the IPad

The location based sector is more dynamic. Its somewhat a bubble at the minute, with tonnes of VC money pouring into some frankly daft ideas. But there are some gems within that world. Like the dot com boom and bust, many will fall but some real innovation will come from this sector. There are huge opportunities to build location based applications, classed as location based services (LBS), to use in marketing, advertising and beyond on mobile devices. At present this sector is narrowly focused on consumers. Broadening solutions to the enterprise offers mouth watering possibilities. Figure 2 below shows a mobile check-in and data collection application which allows field service techs, surveyors, water utility workers, indeed any workers in the field to utilize mobile in their daily work routines.

MapQuest have an interesting offering. They were one of the the earliest companies to put maps on the Web. Initially focused on routing/directions, and traffic, they have broadened their offering to to include local search, marker and map overlays. In October they announce their Flash mobile API release. This is a big deal. More about Flash in a minute. But the MapQuest offering is in many ways made for mobile. Imagine being able to access routing and up to date traffic information while on the road. Look ahead and see accidents on your route and avoid them. Conduct local searches; find venues near you. Overlay KML and GeoRSS markers on the map to see points of interest (POI). Tonnes of possibilities.

Figure 2: MapQuest Enterprise Check-In and Data Collection App

Location Based Cross Platform Mobile Development

Objective C has become one of the most in demand programming languages. This relates to the popularity of Apple mobile devices. Most of the apps in the Apple App Store are written in Objective C. Successful mobile application development shops are filled with Objective C developers. But the game is changing. Android, and other mobile platforms are becoming increasingly more popular. Where does that leave your beautiful Objective C application? Only running on Apple products that’s where! You’ll need to rewrite it for Android, BlackBerry, Windows!

Now, thankfully there are cross platform solutions. Two of the most notable are Adobe AIR and PhoneGap. With AIR you can take your existing Flex or Flash apps and convert it to a mobile applications. Or build your AIR mobile app from scratch. But, most importantly, run the app on all mobile platforms. With PhoneGap take your Javascript application and do the same. That is one code base, which runs across mobile platforms. Simple.

Geo-Spatial Cross Platform Mobile Development

We have digressed slightly from our original topic. The future of mobile is very interesting, and filled with opportunities. Location will be at the core of many, if not most mobile applications. One day it might be pointless for companies such as us to target location based cross platform application development. But at the minute it seems to make tonnes of sense. Mobiles devices are computers with ever changing locations. Taking advantage of location to provide dynamic data – traffic ahead, what or who is near me, analysis by current location – has endless possibilities. Cross platform too. Who has the money or time to build multiple versions of the same application to run across each mobile platform? Build it once and deploy it to all would seem to be the future.

We might be wrong. But we are going to stay focused on cross platform location based mobile application solutions.

Source:GISCafe.com

GIS Mobile Development: Flex or HTML5?

“JavaScript not Flex/Silverlight — Yeah, it isn’t much of a surprise, open source users aren’t big Flex or Silverlight users, but JavaScript HTML5 web apps are everywhere and doing everything Flex/Silverlight can do, but work everywhere …. At this point it is safe to call every Flex/Silverlight location app as legacy as nobody in their right mind would be coding with those tools in 2012.”

Spatially Adjusted blog

 Slideshare Blog:

“Ditching Flash for HTML5 feels like the right choice for us for a number of engineering reasons.

1. The exact same HTML5 documents work on the iPhone / iPad, Android phones/tablets, and modern desktop browsers. This is great from an operations perspective. This saves us from extra storage costs, and maximizes the cache hit ration on our CDN (since a desktop request fills the cache for a mobile request, and vice-versa). It’s also great from a software engineering perspective, because we can put all our energy into supporting one format and making it really great.

2. Documents load 30% faster and are 40% smaller. ‘Nuff said on that front, faster is ALWAYS better.

3. The documents are semantic and accessible. Google can parse it and index the documents, and so can any other bot, scraper, spider, or screen-reader. This means that you can write code that does interesting things with the text on the slideshare pages. You can even copy and paste text from a SlideShare document, something that was always a pain with Flash.”

These types of discussions have been going on since the dawn of the Web. New technologies replacing old. The advent of mobile certainly presents new challenges, and may well alter the landscape. But the end of Flash or Flex has been called wrongly so many times.

Adobe are an innovative company. There are ever more developers moving over to learn and use their Flex and Air products. And frankly, as somebody who has worked with these technologies since their inception, they are just fantastic for building the next generation of Web and mobile apps.

But will the decision by both Apple and now Windows, to not allow plug-ins on their mobile browsers end Flex as we know it? Remember Flex needs the Flash plug-in installed to run in any Web browser. 

At the moment Flex development continues strongly on the the PC based Web, where the Apple and Windows restrictions do not apply. HTML5 development continues in parallel. But, as many of us continue to believe, if mobile devices do take over from the PC, the mobile Web may well be all about HTML5.

Adobe Air started out life named Apollo. When it was launched, many in the development community could see the thinking behind the release, but never a good place to build Air apps in the PC world. 

That has all now changed. 

Air is an installed application, not relying on any browser plug-ins. Mobile Air offers the only cross platform mobile (installed) solution on the market today. No more building mobile apps in 3 different languages or more for each mobile platform. One code base runs on Apple IOS, Android and Blackberry. No need for third party conversions as provided by the likes of PhoneGap for HTML5. Adobe mobile Air apps are both fast and able to interact directly with native code.

Adobe Air and Flex are nearly identical. So looking forward, if Flex becomes less popular due to business decisions made by Apple and Windows; Adobe Air is about to see enormous growth. So maybe there is some truth in those who say its the end of Flex. But its just the beginning of Adobe mobile Air!

The Best IDE For ArcGIS API for JavaScript, HTML5 with Code assist

1.Aptana Studio 2

If you want to do some professional development then Aptana Studio would be a decent choice and best of all, it’s free! You can use Aptana as a plugin with your Eclipse or you can download the standalone Aptana Studio. If you already use Eclipse then the Aptana plugin would be the natural choice.

Aptana Studio is pretty simple compared with Visual Web Developer + VS2010. You can Debug your JS using Firefox+Firebug. What’s really cool about it is the support for popular JS libraries like Dojo, Yahoo! UI etc. If you’re planning on using 3rd party JS libraries then you should choose Aptana Studio. It also comes with a nice FTP client integrated into it which comes in handy when you want to do live-development. Moreover, you can also preview your JS in action right inside it using the integrated browser view (it supports IE, Firefox and Safari).

With Aptana Studio 2 installed, there still are some steps to getting it set up to perform code assist. The ArcGIS JavaScript API is build on top of the Dojo Toolkit. As a result, support is needed for both Dojo Toolkit and the ArcGIS JavaScript API.

Setting up Dojo code assist can be accomplished by installing the plug-in directly from Aptana Studio. Go to Help > Install Aptana Features. In the dialog, expand the JavaScript Libraries section, check the box next to Dojo and click the Install button at the bottom of the dialog. Aptana will download and install support for Dojo. Code assist is now working for the Dojo Toolkit, but support for the ArcGIS JavaScript API still needs to be installed.

To get code assist working for the ArcGIS JavaScript API, a jar file needs to be downloaded from Esri and installed into Aptana Studio. The download and installation directions can be found on the ArcGIS Resource Center as well. There is only one problem. The directions are for setting up code assist if you have installed Aptana as part of the larger Eclipse IDE. This was not the case for me. I installed it for only myself on the computer. It took a bit of exploration to figure out how to get this installed correctly.

Successfully installing this jar file requires unzipping the zipped archive, copying the jar file into the Aptana plugins folder and enabling it in Aptana. If like myself and installing Aptana for only the current user, the plugin folder can be difficult to locate. Instead of being located in the C:/Programs directory where all other programs installed on a Windows computer are, Aptana is installed in C:/Users//AppData/Local/Aptana Studio 2.0. Inside this folder is located inside the Aptana folder at C:/Users//AppData/Local/Aptana Studio 2.0/plugins. Copy the jar file from the zipped archive downloaded from Esri into this directory.

With the jar file copied into the plugins directory, enable the plugin from within Aptana Studio. Go to Window > Show View > References to open the References dialog. In the References Dialog, open the Global References and check the box next to ArcGIS JSAPI.

This is what it takes to get an IDE with code assist for working with the ArcGIS JavaScript API: download and install Aptana Studio 2, enable the Dojo plugin, download the jar file from Esri, copy the jar file into the plugins directory and enable the JSAPI plugin. Although it takes a bit of tinkering to get it done, the upside is this IDE is completely free and provides code assist for the API I prefer to learn.

Download and Install

1. Download and install Aptana Studio.
2. Install the Dojo plug-in using the Help > Install Aptana Features menu option. In the Aptana Features dialog expand JavaScript libraries and select Dojo to install the Dojo libraries.
3. Download and install the JavaScript API code assist plug-in from the ArcGIS Resource Center.

2. Visual Studio 2010 with Visual Web Developer (Windows)

If you’re already writing your code in Visual Studio then this would be an ideal option. Visual Web Developer does not come by default in the VS 2010 installation so you will have to add it separately. To start off with, you can download and install the Express edition (free) of Visual Web Developer from here. Not only can you write and debug JS in VWD 2010 Express but you can also write RIA (Rich InternetApplications), WPF (Windows Presentation Foundation), in fact write a complete web-application.

3. Firefox + Firebug (Windows, Linux, Mac OS X)

If you do not want another heavy installation and just want to write plain JS and test it right inside your browser, you can do that with Firebug installed over Firefox. If you do not have Firefox then downloadinstall the latest version (3.6.13 at the time of writing this) and then download and install the Firebug plugin for Firefox from here (Or you can go to Tools –> Add-Ons –> Get Add-Ons and type in Firebugand install it). This is by far one of the most popular and most download Firefox Add-on too which speaks for itself.

Here’s a simple starter for writing and live-debugging JS using Firebug:

Fire up Firefox and open the JavaScipt that you want to inspect and debug.

If you have installed Firebug then a small bug icon will appear at the bottom-right corner of Firefox, that’s where you will open Firebug right inside Firefox. Since we’re inspecting JS, you need to click theScript button in the Firebug button panel:

You can set break point, conditional breakpoints and also profile your JS in addition to a couple of other features. This is a nice place to get started with Firebug.

Since Firebug does not include a Text Editor in which you can write code but you can add any text editor (preferably Notepad++) by going to Tools –> Firebug –> Open With Text Editor –> Add New Editor

 4.Komodo IDE (Windows, Linux, Mac OS X)

Even though Komodo is not free but it’s worth your money if you write JS (or web apps for that matter) for a living. Komodo IDE comes packed with a code editor that supports almost every language in which you can write web apps. Besides all the usual features you can integrate almost any source control into the IDE. It also includes Database Explorer which lets you dig into your website’s database right from the IDE. If you’re developing web apps then you know how handy this could be. You can find the whole list of features on here.

5. Komodo Edit (Free) (Windows, Linux, Mac OS X)

Komodo Edit is the free version of Komodo IDE minus the integrated debugger and a couple more less-important features. I would recommend trying out your hands on Komodo Edit first before going for the Komodo IDE since it would give you a feel of working in Komodo. It is free and open-source unlike the Komodo IDE. You still get a code editor, intelli-sense and it also integrates nicely with Firefox+Firebug. You can get Komodo Editor from here.

6. Eclipse + JSEclipse Plugin (Windows, Linux, Mac OS X)

JSEclipse is a nice plugin for Eclipse so if you’re already developing on Eclipse then this would be a natural choice. However, I should warn that since Adobe acquired Interakt, the company that made JSEclipse, active development has stopped on JSEclipse as of late December 2010. But still if you want to just try out writing JS then it will be a good start since it can easily integrate with Firefox+Firebug. When I say that it can integrate, what I mean is that you can use it’s source editor as a text editor for Firebug. Find out more about JSEclipse on here.

7. NetBeans (Windows, Linux, Mac OS X and Solaris)

NetBeans also has some great support for writing simple as well as complex JavaScript. It sports a source code editor with auto-complete and intelli-sense and a debugger that integrates well with Internet Explorer as well as Firefox. And just like Aptana Studio, it has extensive support for integrating popular AJAX, JS libraries like Yahoo! UI, Prototype, Script.aculo.us etc into your code. You can target your JS, in fact your complete app for the whole range of popular browsers and check separately for each browser right inside it. There’s a very nice tutorial on getting started with writing Web Services that would come in hand. You can view it here. Click here to read more about the JS support in the NetBeans IDE.

8. WebStorm (Windows, Linux, Mac OS X)

WebStorm by the JetBrains has to be the latest JavaScript IDE. It’s light-weight and sports a JS code editor, debugger (support for putting breakpoints, conditional breakpoints, step-in, step-over etc). You can also integrate Firebug with WebStorm to debug right inside Firefox. It also has good support for writing HTML5 and just like Aptana Studio you can connect to an FTP server to sync your scripts. I wish they had support for some popular Source Control plugins since without it we cannot write largeapplications. Find out more about WebStorm’s JavaScript support on here. You can try out the 45-day trial.