This whole post is pretty funny in light of my ribbing of Google the other day over the lack of integration between Reader, Gmail and Dashboard. But, it was just a ribbing and my point still stands: getting software right is hard. The announcement today by Google of Google Gears, however, may be a huge step towards solving one of the most intractable computing problems around: on-line and off-line access to data through a browser application.
There certainly are other development platforms that have promised this holy grail, and there are those who think off-line access is unnecessary, but I think Gears has the potential to be very valuable, particularly in the MLS space. We’ve had an off-line companion to flexmls Web for some time (it’s called flexmls PC), but that essentially has meant maintaining two sets of code and limiting flexmls PC to Windows users. Though we have a lot of research to do regarding Gears and its capabilities, I’m hopeful Gears will prove very useful and maybe even allow us to move towards a single set of code for both on-line and off-line use in any operating system and create possibilities for entirely new feature sets as well.
I think there are many MLS functions that will benefit from off-line access. Though smart-phones and wifi cards are making Internet access from the car and other places easier, the reality is that, today, such access is often more frustrating than rewarding. Being able to sync a significant number of listings or searches to your laptop or tablet before going to meet a client will be very cool. Other possibilities are syncing up CMA presentations, listing tours, electronic forms, and your contact database. What MLS functions do you think would be advantageous to have off-line?
To help generate some ideas, I downloaded Gears for myself today, which Google has already integrated to Reader and thought I’d show you a bit how it works in practice. First, Gears includes a browser plugin for syncing and a local database, the key to storing data off-line. Once Gear is downloaded, going to Google Reader in my browser (Firefox) immediately recognized that I had Gears installed:
Once Gears is allowed, Reader adds a new option in the upper-right corner to go off-line:
Clicking the offline mode, Reader starts downloading 2,000 of your messages to the local database:
That’s all there was to it. Once the data was downloaded (took less than a minute or two), I was in offline mode and could turn off my wireless and read through all 2,000 messages if I wanted. One thing I noticed was that the sync didn’t work quite right, because there were several messages marked as unread that I actually had already read. As soon as I went back on-line, the messages were properly marked as read.
Another not-too-suprising issue is that posts with pictures, video and other media only show the text. I’m hopeful that will be a limitation that can be worked around as the inability to sync images and other media would be a bummer for an MLS application. Generally, though, issues like image syncing in a manageable manner will be some of the core design decisions that will make this type of development challenging and fun. In flexmls PC, we give the user choices to download a variety of levels of photos, but I think a browser application will have to be even more limited in the photos that can be stored off-line. Perhaps that leads right back to the question of how practical it is to deal with huge databases off-line and what functions will prove beneficial to agents in the field.
Let us know what you think.
Check out instacalc.com for some easy to use calculators that can be shared easily. I created two calculators to compare investment in a 401K plan with a company match versus investment with after-tax dollars in a tax-sheltered investment vehicle like a Roth IRA. These types of calculators may not be the best for agents communicating with consumers, but they are easy to do some quick yet sophisticated math in a very flexible format for sharing on the web.
This is another take on the question posed a few weeks ago about why MLSs don’t innovate. In this case, let’s take on Google. What? I can’t be serious, right? Google, a lack of innovation? Well, yes, I am serious. Case in point: Why doesn’t Google Reader support authenticated feeds? This should be a trivial task, right? I love Reader but it frustrates me that it doesn’t handle the authenticated feed from our private intranet. Worse, Google’s own Gmail application throws off a feed that can’t be read by Google Reader. Hmmm.
Clearly, the problem is greater than at first appears. Even Google is subject to the complexities of disparate applications not working well together. Different teams have developed Gmail and Reader. This same disparity is evident between Gmail and Google Dashboard, as the two just don’t play well together. Undoubtedly, there are a myriad reasons why Google hasn’t implemented authentication into Reader yet and why Gmail and Reader and Dashboard don’t work well together yet, but they boil down to this: When Gmail was written, no one had thought about Reader or Dashboard yet. So, decisions were made back then that make integrating them difficult today. This will only get more and more difficult as Google’s applications mature and as they buy more products from other companies. The bigger you get and the more products you have, the more difficult it is to make things work together easily and one more reason software is hard.
Today, we remember, with the many others,
Henry Kampa,
Our friends in the New River Valley and Roanoke areas,
Our troops,
and to love.
Here’s a blog post on O’Reilly suggesting that sticking to web conventions for web apps (e.g., gmail) is better than trying to emulate the desktop UI for web apps (e.g., Zimbra). Interesting. I don’t think I agree. I think users want a full desktop UI in their web apps (drag and drop, etc.), and have just been willing to put up with the limited web UI because of the benefits of anywhere, anytime access. I especially think this is true in daily use business applications like MLS systems or contact management systems (e.g., Salesforce, etc.). What do you think, should web apps be limited to the web UI or shoot for more of a desktop UI?
Tangentially, here’s a post about not letting marketing derail the software development process with too many incremental “wouldn’t it be great if(s)…” As we march toward our next major release this fall, I best remember that. I’m hopeful our clients and developers will help me stay focused on what’s important as I want more and more and more! 
Last week, I posted about a mystery e-mail one of our clients received soliciting a poll about a national MLS. One of the comments noted the name Luis Cancel on the URL registration, and another FBS employee pointed me to this real estate company in Florida run by a Luis Cancel. This doesn’t really seem to solve the mystery, because it isn’t apparent from their web site, anyway, why they are interested in a national MLS (or even if this Luis Cancel is the same one who registered the mlssurvey.com domain). Or does anyone see or know anything else I’m missing?
Here’s a “welcome to the RE.net” post for blogs by Matthew McGuire and Ryan Bonham, who are both on the RETS Governance task force with me.
Ryan is CEO of Transparent Technologies, which is a real estate software development company focused on IDX systems and RETS programming. I look forward to having Ryan join the fray regarding RETS-related issues.
Matthew’s blog actually isn’t new but it is new to me. Also, Matthew notes that his blog is personal (i.e., not related to his position at Marketlinx, the biggest of big MLS vendors) and his posts so far are focused on software design and development generally, and Debian Linux specifically. So, it remains to be seen whether Matthew will dig into MLS issues or not, but it would be great if he did.
On Monday, we were flying to Arizona and got diverted by weather to Sydney, Nebraska, where we were fueled by a real racer. Despite this highlight, what was supposed to be six hours of travel time turned into nearly eight, with lots of bumping along the way due to the weather.
On our way home on Tuesday, the first leg of our flight was awesome. Smooth sailing at 25,000 feet with a tail wind pushing us to 280 knots (about 320 MPH), which looks like this.
Combined with the serendipity of the iPod shuffle producing the perfect song to go along with our high flying, this was an awesome ride.
Unfortunately, weather got the better of us later in the day, diverting us this time into Bismarck, North Dakota, where we had to stay the night. Of course, we had no extra change of clothes, so the flight back this morning was a bit . . . dirty. It is nice to be home, though, and I still feel elevated from the awesome flight yesterday.
TechCrunch reports that Google is negotiating some content licensing deals with news organizations in Europe, and that Google already has licensed the Associated Press feed. This brings back to my mind an analogy between the MLS data feed (particularly if it includes sold information) and a data feed from the stock exchanges, which also are paid-for licensed content. With Zillow and Cyberhomes apparently now negotiating with brokers for data feeds, perhaps consideration should be given to licensing the sold information on a paid for basis similar to how it is licensed from the stock exchanges. This approach failed with REBIG some time ago, but that may have been more of a leadership, execution and timing problem than a concept failure. The MLS sold information clearly is of value and some MLSs are already publishing sold information, and so the question is whether the data should be licensed to others or not. This may be better than dealing with a variety of firms joining MLSs only to get access to a “free” data feed.
Update (10:58 a.m. Central): Inman posts a video discussion on who is winning the listings war.
Also worth serious consideration on this issue is a post from Matt Cohen on listing syndication.
Bernice Ross posts over at Inman Blog today that Saul Klein explained at the NAR mid-year conference what Greg Swann has been saying for months:
Right under our noses, Zillow.com has effected a similarly radical shift in the way we think about real estate databases. All of the dead-bots-walking I named above — Trulia, PropSmart, Google Base, Realtor.com, and every local MLS system — every one of them treats data in the same way: There is an on-going application that will be effected using temporarily-stored data.The Zillow.com paradigm is exactly the opposite: We are accumulating a database of permanently-stored data that can be deployed for any number of temporary, interchangeable applications.
I’ve previously explained why I think Zillow’s “entered only here’ approach actually is old school, and not revolutionary, but I also think credit should be given where credit is due. Greg explained Zillow’s approach long ago and anyone who missed it just needs to read more or better.
(Oh, yeah, I almost forgot, also announced at mid-year, Zillow apparently is now trying to work with brokers on listing data feeds. That’s certainly an interesting development and one on which I’ll be interested to hear Greg’s views.
P.S. I missed the mid-year convention this year to be with my family, and I was surprised how much I personally missed being at the event. At first I thought it wouldn’t matter, but the mid-year show is a great place to hook up with our clients and friends, and stay on top of what’s going on in the industry. I do love this business!)
