This whole geotagging concept has me thinking quite a bit.  One of the things that I’ve been concerned about is usability.  This is one of the major factors that comes into play when building any sort of website or webapp.  If you check out the geotagging concept you’ll notice that making a selection in the list centers the map and shows the appropriate info window.  It would be cool to allow users to use their up/down arrow keys to scroll through the list and center the map on the selected tag.  I consider this expected behavior when viewing any sort of information in list format.  The problem is that this isn’t always the easy thing to achieve.

Frameworks such as Adobe Flex and standard HTML select lists ship with this functionality.  When you roll your own (which I’ve done here) then you’re out of luck.  You have to come up with some fairly extensive code to accomplish this task.  With that being said I’m currently looking into a few different options that will prevent me from reinventing the wheel.  I’m not interested in a Flex solution for this app, although Adobe’s UI components do rock.  We use them extensively at work.  Adobe’s Spry framework looks promising although it’s currently in its infancy.  I’ll definitely be keeping an eye on it and many other Ajax components that could do the job.

The benefit of rolling your own code is that you understand it, therefore easier debugging.  Not only that, it’s generally pretty lightweight since you’re writing code to perform a certain task and not serve the masses of developers who may use it.

In regards to List/Map interaction I also think it’s expected behavior for a selection on the map to trigger a selection in the list.  Once again, with frameworks this is easy because someone else has already solved the problem.  Trying to accomplish this through standard HTML, JavaScript, and CSS can get tricky fast.  This obviously means I’ll spend some time looking into it

As more and more apps utilize mapping I think this will become a common UI pattern.  Users like to be given a context of where they are and provided with some level of feedback.  If you access my geotagging concept and select something in the list you’ll see the map recenter.  Now select a different marker on the map, nothing happens in the list.  The previous selection is highlighted, which is very misleading.  I’ll be working to get that fixed soon.
This may seem like common sense, but I see this type of stuff overlooked all the time.  Although the solution seems pretty straightforward, it can be a mammoth to code.  At any rate, I’ll be digging around for possible solutions and will continue to post my progress.

I’ve been doing a fair amount of research comparing JSON to XML. We do a good bit of XML transactions at work so it seems appropriate to research alternatives. While this post isn’t really about which approach is better I do want to share a couple of thoughts. First off, JSON appears to be much more lightweight and a bit easier to read than XML. I recently converted my RSS feed from XML, which at the time was about 46kB, to 23kB in JSON format. A pretty decent savings in size.

I’ve noticed a lot of JSON initiatives and the fact that many people are writing parsers appears to be a good sign. For a list of supported languages check out the bottom of this page. Even Yahoo and Zimbra are supporting JSON. I hate to jump on any sort of bandwagon, but in the Web industry if you don’t get on a bandwagon you get left behind. It’s always good to be open-minded about new approaches and that’s why I’m continuously researching alternatives. One of the oldies, but goodies, is Flash Remoting (a tough one to beat).

Today I stumbled across this great article that outlines a few pros and cons with XML and JSON. The author makes some great points that go beyond file sizes and parsing overhead. JSON is attractive because functions can be sent to the client and JavaScript code can be easily executed using the eval function. XML is attractive since it integrates so seamlessly with Ajax. I highly suggest reading the article and some great points are made about each technology.

While I’m not ready to jump from the XML ship I will definitely be experimenting more with JSON and will post more here. One thing’s for sure, JSON seems to be much more compliant with Flash since ActionScript is based from the same ECMA spec as JavaScript. That’s a pretty good thing since I tend to be a Flash junkie.

My dear friend Auburn sent my one of the funniest links I’ve received in a long time. CareerBuilder has implemented a personalized monkey email that allows you to type a message or even use your microphone to record one. Using text-to-speech technology the monkey can then dictate what you typed. The monkey’s lips move rather accurately to what you’ve typed, unlike the old kung-fu movies. You can check it out here.

Auburn was taunting me of our recent trip to Miami, but don’t always believe what a monkey tells you. You can check out an image of the monkey making fun of me below.

Stupid monkey. At any rate, I’d like to mention the technology used to implement this is Adobe’s Flash and Oddcast’s text to speech engine. I know Ajax has been receiving a ton of buzz lately, but this is one thing that Ajax will never be able to touch. Flash truly shines when it comes to highly interactive multimedia that attracts eyeballs. This is not an Flash vs. Ajax post since each technology serves a purpose for a given task. As a Flash advocate it’s always exciting to see these type of ad campaigns crop up.

Push technology has been around for what seems like a decade and in the late ’90s it was supposed to revolutionize the web. It has become extremely useful for instant messaging, but there seem to be very few applications that use push in a web browser. About 5 years ago Macromedia released Flash Communication Server (now Flash Media Server), which enabled developers to easily create persistent connections between a client and server. This was all capable using the ubiquitous Flash Player. Since version 5 of the Flash player developers have been able to create socket servers that push data to clients.

This evening I stumbled across Lightstreamer and decided to dig into their product a bit. It appears they’re doing an Ajax push that updates the page without having to manually refresh. You can view some of their demos by clicking here. This is accomplished by creating an HTTP stream to the client. With as much buzz Ajax has received over the past year I’m certain this will create even more hype. The term Comet has been coined for Ajax push applications and I’m interested in seeing what innovative applications will leverage the technology.

I know that we could potentially leverage push at SensorLogic where we build enterprise applications for remote asset management. All sorts of devices and machines can talk to our platform over many different wireless networks. Some of these devices report frequently where operators need to monitor their condition or location. This data is made accessible to the operator through a standard web browser. Now think about the operator having to refresh to look for new data every couple of minutes or so. It would be nice to have the interface automatically when new data is received. A lot of technology is involved to make this happen, but that’s the concept.

Back on track. I know of a few push initiatives that seem pretty interesting:

1. Pushlets
2. Realtime on Rails
3. Lightstreamer

I’m sure there are plenty of others, but these are the ones that stand out in my mind. Stay tuned into the World Wide Web of Push.

I’ve been spending a good amount of time lately with Ruby on Rails partials. If you’re not familiar with the concept of a partial they’re similar to include files, but seem a lot more powerful. A partial allows developers to easily reuse code in multiple places. A perfect example would be a list of most recent blog posts. Partials enable this code to be easily integrated into every page of the application without having to worry about repeating it. If you’re familiar with ColdFusion, then partials are very similar to using the cfinclude tag. Having code that is modularized into partials and components makes development a less daunting task.

I wanted to take a minute and write about dual purpose partials. I say “dual purpose” because this was the first time I ran into the scenario I’m about to describe. Prior to this most of my partials where fairly static, which means I didn’t have a need for using this technique. I’ll start by showing you the basic code to render a partial:

<%= render(:partial => “notesrow”, :collection => @notes) %>

This assumes a partial with a file name of _notesrow.rhtml that resides within the current views directory. The name of the partial is notesrow and I created an instance variable called @notes. This variable is passed as a collection to the partial where it will then be automatically enumerated.

Now the interesting part is that within this partial there’s a local variable called notesrow which contains a notes object. One notes object for each iteration of the loop. Therefore the partial code would look something like:

[div]
The subject of this note is <%= notesrow.subject %>
The description of this note is <%= notesrow.description %>
[/div]

This code is enumerated until there are no more notes records. Therefore the notesrow partial has two purposes:

1. Assign a partial called notesrow that links to the file _notesrow.rhtml
2. Creates a local variable called notesrow that contains the current notes object

Partials also make it very easy to do Ajaxy things with your applications. Not to say that you can’t do it without partials, but they simplify the code you have to manage for a given task. For more information about RoR partials feel free to check out the following book:

I recently posted about the ExternalInterface class in Flash 8, which allows for tight integration of Flash and JavaScript. Adobe (formerly Macromedia) announced today the Flex/Ajax bridge. This will provide even tighter integration of the two environments. I call them environments from the simple fact that they didn’t use to play so well together.

Developers can now access any ActionScript functionality directly from JavaScript…this is HUGE. I can only imagine using Flex to layout the application and letting JavaScript handle all the client-side logic. Actually, forget that, JavaScript could be used to dynamically instantiate Flex objects so technically all you would need is a Flex shell. The instantiation of a Flex chart from JavaScript looks like:

var chart = FABridge.swf.create(“mx.charts.ColumnChart”);

You can see a demonstration of the FABridge in action by clicking here and be sure you have the Flash 8.5 player.  There’s been insane buzz around Ajax over the last year and it’s exciting to see Adobe step up to the plate. I believe enabling developers to leverage both Flex and Ajax will lead to more compelling applications. Nonetheless, it will be interesting to see the adoption rate since there are die-hard advocates of each technology.