In developing the flexmls® Web system, we work very hard to support as many browsers as we can by focusing on current industry standards for our development. However, that doesn’t mean all the browser vendors have made that same commitment or that we are all interpreting the standards in the same way. In fact, the entire area of standards development and compliance is often rife with debate.
The upshot of this debate is that there is not “one true standard” against which you can develop (oh, we only wish!) and magically have all browsers supported. Instead, developing cross-browser support really is about what browsers you test against and the results of those tests. This topic recently came up on the NewARMLS blog, with a user commenting:
On the FlexMLS web site they state FlexMLS will work with Internet Explorer, Mozilla and Opera. One of my biggest complaints with Marketlinx is that it is ASP/VBScript based, which means many of teh “extended functions†of the MLS do not work on any platform other than MS Windows. For those wishing to use a Linux System running the Opera or Mozilla Web browsers, will we still be facing those types of limitations.
I then responded:
James, thanks for pointing out that we need to update our web site. The two currently supported browsers today for flexmls Web are Internet Explorer and Firefox.
Generally, in discussing browser compatibility, it’s important to distinguish between the development strategy toward cross-browser support and the testing and support strategy. FBS works very hard to develop all of our products toward open web standards. Accordingly, most every browser will work with flexmls Web.
However, we currently only test against Internet Explorer, Firefox and Safari. Because we know there are some functions, like the custom report writer, that do not work in Safari, we do not officially support Safari, but we do actively test all functionality against it as well as Firefox and Internet Explorer.
In contrast, we do not test against Opera or other browsers, because they do not have sufficient market share to warrant testing and compliance. This does not mean these other browsers won’t work. In fact, they may. We just don’t claim they do and if someone calls indicating that something doesn’t work in one of these other browsers, our recommended solution is to use a supported browser.
Incidentally, the issue of browser support is, thanks to Firefox, largely independent of the OS. The key is the browser. You can run pretty much any Linux distribution or Mac OS and use Firefox to access the flexmls Web system.
I’m hopeful this clarifies our strategy for developing flexmls Web to support as many browsers as possible in a practical way.
In my last post, I highlighted a virtual tour on one of the listings in our system. Now, let me draw your attention to the fact that the virtual tour is located on what we call the Media tab. The term media was chosen because: (1) the tab can host photos, videos and virtual tours; and (2) we thought multi-media was too long. Since the release, however, we’ve received feedback that users are having a hard time finding the photos, i.e., they don’t immediately recognize Media as the place to click for photos. Because photos are the primary content (we still only have a few innovators linking video), we’re considering renaming the tab Photos. What do you think would be the best name?
We also have a tab called Grid, which contains a row/column (spreadsheet) view of the listings.
This tab also has produced feedback that the word Grid is confusing to users, some thinking it’s a map, others a graph, and others simply not knowing. So, we’re considering changing the Grid tab to be called List or Results or something else. What do you think would be best?
Thanks for participating in the polls and for any comments you have.
The FBS Blog is no stranger to discussions on standards (here, here, here, and here this year alone), so I thought I’d interject some discussion of standards of a different kind. Like RETS, web standards are designed to create a world where developers can create an application once and have confidence it will run on all platforms. Here’s a line borrowed from the About RETS page that could easily be applied to web standards as well:
This means lower costs, more products, more competition among vendors, and faster implementations of new systems, all of which directly benefit people who work with real estate information as a living.
If web standards are so good, then why have we seen such poor standardization among web browser companies?
Michael has posted previous that monopolies are not efficient at innovating MLS software. It turns out that this maxim applies to software in general. Microsoft’s web browser monopoly lulled them into a false sense of security. Instead of innovating new features and increasing their standards compliance, they built their own “standards” and rested on their laurels for over five years. Many web companies took advantage of these “features”, even though they were not standard, because IE was in the hands of so many of their users.
This all changed with the advent of Firefox. Once a browser began stripping away Internet Explorer’s market share, Microsoft needed to become more cognizant of web standard. Developers like myself rejoiced when IE 7 shipped a little over one year ago because it was supposed to be more standards compliant. Others predicted that IE 7 would break the web and to some degree they were right. Many sites were broken as developers scrambled to fix portions of their non-standard code. While cross-browser apps like flexmls Web were just fine (we’d been testing and fixing for months prior to the release), the screaming from the other side was loud and clear.
Last week, an article made its way around the web outlining what Microsoft is planning to do differently with IE 8 to remedy this problem. Their plan is to implement a new way for developers to flag which version of IE they’re developing for. This way, Microsoft can update IE and sites that haven’t been updated would continue to function as if nothing happened. Sounds quite reasonable, until you realize the absolute horror show this will create.
First of all, adding all this extra weight to a web browser is a flawed strategy. In IE’s case, they’ll essentially need to have 2 web browsers wrapped into one. This leads to confusion, slower downloads, almost certainly slower page rendering, and increased chances for errors. When it comes to software, Occam’s razor most definitely applies.
Second, web browsers should not be in the business of rewarding bad behavior. Developers writing bad code should be greeted with broken sites. No matter how many times you tell developers to stop using some crazy workaround, they will continue to use it until you take it away. Developers, like most people, are creatures of habit and many times can be resistant to change. Microsoft shipped IE 7 in October of 2006 and shipped their first IE 7 beta in August of 2005! That’s over one year for developers to see the changes and prepare themselves (they even shipped an Internet Explorer Readiness Toolkit in July of 2006). How much more of a head start could Microsoft have given?
Third, other browser companies won’t support this because there’s no reason to do so. Firefox, Safari, and Opera all support many broad standards. As these browsers are updated, they don’t have the crazy code nightmares from which IE suffers. This has led some to dub Microsoft’s new browser flag as the X-IE-VERSION-FREEZE.
Lastly, the only thing this proposal accomplishes is delaying the inevitable pain. What will Microsoft do when IE 9 comes out, still keep versions 7 and 8 wrapped in? How about IE 10? Either IE will get so bloated and become a nightmare to download and maintain or they’ll have to drop support for past browsers. It seems to me that sooner or later those crazy IE hacks are going to go away. Why not just pay the piper now?
In conclusion, we need to embrace standards, even if it hurts for some of us in the developer community. I’m proud of our cross-browser support here at FBS, as we’ve supported Firefox since its humble beginnings. As a dedicated Mac user, standards are especially important to me. Developers should be on notice, support common browser standards or face the consequences.
On December 11, 2007, I gave a presentation to a group of Association and MLS executives as well as brokers and agents in Minnesota, who are exploring data sharing among MLSs in Minnesota. Below is a video re-enactment of my presentation.
(If the embedding doesn’t work, you can view the video here.)
Also presenting to the Minnesota group were Art Carter from CA-RETS, Gregg Larson from Clareity Consulting and Security, David Charron from MRIS, and Ed Newman of RMLS-MN (Northstar) standing in for Rob Overman from FNRES who wasn’t able to make it because of ice storms. Art Carter discussed the political and technical processes the many MLSs from Southern California are going through as they ramp up the new CARETS system, which is an example of the repository approach. David Charron also talked about the repository approach being pursued in Wisconsin (WIREX), on the east coast, and elsewhere with their Cornerstone system.
All the perspectives from these presenters were very valuable for the group in Minnesota and we had some great conversations afterward as well. The MLSs in Minnesota are trying to solve some serious challenges and it’s heartening to see RETS at the center of the many solutions being offered. There is no doubt that broad and deep data standards are the key to moving the MLS industry forward in a competitive environment, as opposed to forcing MLSs through painful mergers and into data silos that will inevitably frustrate innovation.
Until today, I maintained my calendar exclusively on my Treo 700p. Today, however, one of my co-workers, David, told me about Lightning, a calendar extension for the Thunderbird e-mail client, which will sync with Google Calendar. A few minutes later, I discovered GooSync, which syncs my Treo over the air with my Google calendar. So, now my calendar is synced with my laptop and phone and changes on any populate to all. Better yet, I’ve shared my Google calendar with my wife and given her edit privileges, so any changes she makes are automatically synced to my phone and computer, too. This was so easy and is so cool and cost me only $40 for a year of the pro version of GooSync. To get this level of syncing typically requires using Outlook on every machine and all sorts of complications with Exchange servers and whatnot. Instead, I got it going within a matter of minutes for a pittance, largely because of data standards.
I’m not going to offer a purported answer now, I’m just asking questions, specifically: Why is real estate immune from the ideas being debated in other industries? Doc Searls wrote some time ago:
To really take advantage of open source, he explained, you need to value ubiquity in your marketplace at least as much as you value scarcity in your product portfolio. In fact, your smartest move may be to take some of the products you’re selling, and make them ubiquitous by moving them from proprietary/closed to open/public domain — literally, from scarcity to ubiquity:
This same theme is picked up by Alex Iksold at Read/Write Web in an analysis of how Google’s OpenSocial initiative could impact FaceBook:
Open Social paves a way to a potentially new kind of web culture. In that culture, companies would recognize that users are entitled to their information. It should be importable and exportable. It should not be locked in.
Why is real estate sales through the MLS excepted from this general idea? I’m not asking this rhetorically, I honestly don’t know and wonder about the answer. Interestingly enough, the idea that data should not be locked in applies just as much to companies like Zillow as it does to MLSs, maybe more so. So, what do you think is the answer? Where is MLS data on the curve towards ubiquity and commoditization?
This post continues the discussion regarding listings as advertising or information and brings in days on market, data accuracy, long-tail search, hot sheets, and improving listing promotion inside and outside the MLS.
There’s a belief in the MLS world that the MLS data is the most accurate data regarding home sales. This is a nice statement of faith but often is frustrated by the members of the MLS themselves who are intent on trying to “promote” their listing and are willing to distort the data to do so. This point was driven home by David Harris, the Director of IT for FMLS in Atlanta, in his post The Listing: Advertising or Information, where he says:
Each day our compliance department has to address issues where the property may not be described accurately or the listing may contain information that does not pertain to that property (ie. a picture of the list agent as the 4th property photo
David then also alludes to the mess that is days on market when he says:
I would love to set up a ‘history’ link on a listing so you can click to see any past times it has been on market to allow for an event better idea of the property, but that could be a concern with some agents as well.
(Emphasis added.) Of course, this is the perennial issue of days on market and the desire of agents to have a low number for marketing purposes. But, as Jonathan Miller of Matrix pointed out some time ago, days on market requires one to determine “what market”, which fundamentally is dependent on price. The “market” for $1,000,000 homes is different than the market for $250,000 homes. Accordingly, Miller prefers to measure DOM:
DOM From Last List Date – Measured from the last time the list price was changed, if ever. The calculation is: Last List Date Change – Contract Date. This is the more useful of the two methods because it shows the market’s ability to absorb a property once it actually enters the market. Essentially, its the list price of the property just before it goes to contract. In other words, its the list price that brought the property into the correct market segment and attracted buyers.
Of course, Mr. Miller is coming at this from his perspective as an appraiser, which is more focused on the information. Yet DOM has become a tool for advertising, despite the idiosyncracies involved in determining “the market” and calculating an accurate DOM. So, now we have MLSs everywhere trying to figure out a better formula for DOM to tie various listings together but the real problem is that members want a low number and will often manipulate the data in order to get it, whether that’s canceling an existing contract and re-listing the property or shifting the listing to another agent in their office or a myriad of other approaches. Regardless of the rules developed by the MLS, the clever agent will find a way around it, because they are more focused on an “advertising” mentality than an “information” mentality.
Jim Duncan posts about this as well:
If Realtors could develop a product that had all of the information – All of it – They could use that as a tool to gain what everybody wants – consumers’ trust. (just having the information is not sufficient to earn trust) Everyone else is doing that (Zillow, Trulia, etc.) but for now, Realtors have the best data – for how long?
But what’s to trust about days on market or other data that is manipulated for advertising purposes?
This same issue came up following our recent release and some changes we made to the hot sheet. One user wrote to me and said that the new format frustrated her efforts to promote her listings, because users were now less likely to click on the text change section of the hot sheet, which she often used just to promote her listings. In other words, she was making changes to the text just to get it on the hot sheet, even though those changes had no substantive value. Of course, these manipulations make the hot sheet less, not more, useful.
One of the comments to Jim Duncan’s post tied these issues back to the revolution being wrought by the web for consumers:
I think the internet has changed the entire concept of selling things, but some less visionary people still don’t get it. I think the old methodology of selling things was just to cast a wide net, hoping that someone would see your ad and be convinced to buy. The power of the internet is that it allows people to be far more specific about what they purchase.
My question is whether it’s possible for MLS operators and vendors to leverage the desire to promote the property into creating more, instead of less, data accuracy. For example, could listings with more property details or photos be promoted on the hot sheet more or longer than other listings? Can listing addresses that are validated by a geo-coding proces or GPS be promoted more or longer? Or will these approaches simply result in more manipulation? Are fines the only approach to help members “get it” when it comes to data accuracy?
All of this has a lot to do with data standards, of course, and one of the better conversations I had this last week at the NAR convention involved the idea that the RETS standards and the new RESO governing body may want to consider extending the discussion to MLS rules in addition to data, as the two are inextricably intertwined. Data standards require rules about data validation. I believe that its possible to establish a “base” set of rules and data standards that allow for “blind” entry of a listing into any MLS system and move us toward true enter once, distribute everywhere. Without such a “base” standard, single data entry isn’t possible unless there is only one MLS, which, of course, is just another, more complicated and expensive, way of creating a “base” standard.
The “base” standard could involve tiers of validation that would promote listings more or less within an MLS system, as described above, such that those with more accurate and broader and deeper data would get more prominent and longer promotion in the MLS. There could be search fields for rule compliance or validation levels, for example, so that users could search only on more or less validated listings. Of course, the trick is in defining what is validated or not and that’s why broadening the discussion among the MLS community over standards is so important. There is no question in my mind that the future for MLSs requires exploring new ideas for encouraging data accuracy over manipulation and moving from advertising, which inevitably seems to involve manipulation, to becoming the trusted source for accurate and detailed listing information.
Postscript: It just struck me: Wouldn’t making the information more public be one of the best incentives for creating accurate data? After all, while agents may be willing to deceive their fellow MLS members, are they also willing to risk deceiving the public if it’s easy for them to be found out? Listing history is a great example. Why not make the detailed listing history public as David suggests? Facts are facts, to be judged objectively. Disclose them and the need for accuracy increases dramatically.
Google announced OpenSocial a week or so ago and some prominent voices quickly responded with a big yawn, primarily because OpenSocial doesn’t address data portability. Here’s Tim O’Reilly:
This is SO wrong. And it shows a fundamental failure to understand two key principles of Web 2.0:
- It’s the data, stupid. (Formerly “Data is the Intel Inside”)
- Small pieces loosely joined.
Let’s start with the first one. If all OpenSocial does is allow developers to port their applications more easily from one social network to another, that’s a big win for the developer, as they get to shop their application to users of every participating social network. But it provides little incremental value to the user, the real target. We don’t want to have the same application on multiple social networks. We want applications that can use data from multiple social networks.
And data mobility is a key to that.
I love that. Data mobility is key. It really doesn’t get any clearer than that: Data mobility is key.
But let’s take a step back for a minute and ask why data mobility is key and what it means. First, data mobility is key so users can make choices in the applications they use. If data is locked into one system, there are no choices. Choice means competition, which begets innovation. No choice, no competition, no innovation.
Second, data mobility requires standards, so that different applications can easily exchange and use the data whether it was created by that application or not. In the social networking business, the data that needs standardizing is pretty straight-forward: your profile, your friends network, and your and your friends activity streams.
Of course, these exact same issues have been and are being confronted by the real estate industry. Interestingly enough, however, the real estate industry is well ahead on the path toward data standards and data mobility with RETS and the now-being-formed Real Estate Standards Organization. (If you’re going to be at the NAR convention in Las Vegas, be sure to stop by the RETS booth.) In contrast, these issues are just now being addressed by the social networking sites, with the momentum going both towards and against data silos like Facebook.
Of course, the same issues folks complain about with regard to MLS silos, are also the complaints being made about social network silos. Who wants to enter their data more than once? How can I get my data out once the data is in the silo? What is the silo going to do with the data once they have it? So, even though the real estate industry supposedly is filled with technologically backwards dinosaurs, the super-hip, hyper-technologically advanced web 2.0 world has created and is now facing the exact same issues as the MLS world, put simply:
How do you aggregate data and make it portable at the same time?
You see, whether it’s in an MLS or a social network, the value is in having the data together or aggregated. Yet, once you aggregate the data, in an MLS system or Facebook or wherever, the immediate question is how you can get it back out to be used elsewhere, by other applications, because choice is desired and the aggregation stifles choice.
This is a non-trivial problem. The ideal answer is in the web itself. As Tim O’Reilly puts it, “Small pieces loosely joined.” Yet the web, in its current form, doesn’t address all the concerns, because yet to be defined are permission or privacy or identity schemes. In other words, who owns the data, who can access it, and what can they do with it when they do access it? The answers to these questions so far have been defined by silos, like MLS systems and social networks, but we’re now seeing that isn’t the long-term answer, rather standards are.
In the real estate space, one part of the solution is to have a broad and deep agreement (standard) on the minimum data necessary to constitute a listing. This is close to reality with the RETS payloads. Equally necessary, however, is a standard for defining who can access the listing and the terms of use for doing so. The first attempts at some terms of use in the real estate space led to the lawsuit against the NAR by the DOJ, which necessarily but unfortunately has caused the conversation to grind to a halt as the status quo is sought to be preserved. But the work on these terms of use needs to continue, either to resolve the litigation or end-run it.
Ideally, the terms of use should be dictated by the owner of the data on an individual basis. Again, “small pieces loosely joined.” Yet the challenge is gaining broad enough agreement to create the aggregation that produces the value in the data in the first instance. One listing, on its own, is nearly worthless. Similarly, in the social networking world, a personal profile without friends is nearly worthless. The aggregation and network is what provides value and in the real estate space, the aggregation needs to be really large; ideally complete, or someone misses out on their dream home.
All of which brings us back to the silo, for that is where the aggregation occurs most easily, at least in the short term. This is why I have recommended a national repository with contributory right of download. If an MLS puts data in, the MLS can take data out, which could make MLSs competitors to each other in a very short period of time using existing technology and infrastructure while also preserving the cooperation necessary to create the aggregation in the first instance.
Our release last week proved to me yet again why competition is necessary. Users who didn’t want to learn the new upgrade or thought that our old system was better were most upset because they didn’t have a choice. Users want and deserve choice. Yet the MLS makes the decision on what system to use for the entire membership. If the data were portable, however, competition and choice would ensue. If users don’t like a system, they can choose another one. Simple.
I left practicing law ten years ago because I wanted to be in business, where supposedly people choose to work together instead of being forced to work together as most often the case in litigation. It’s about time that end users choose their MLS system, too, and I’m going to do whatever I can to make MLS data more portable so that choice abounds. If you’re interested in this, too, visit the RETS booth in Vegas or come to the next meeting in Miami and start participating in the process. A lot is going to be happening in the next several months and years to lay the foundation for the future of real estate, and it all starts with standards.
That’s a question I heard a lot this week following our upgrade. Implicit in the question was frustration the user was experiencing shifting from what they knew with the old system to the new one. One of the primary purposes of the upgrade was to give our clients the ability to deliver high-end content to their clients, like interactive maps, big photos, videos, and rich data, like this:
All of this raises an interesting question. Can an important piece of business software like an MLS system serve both consumers and agents? Can these two worlds merge together into one? Or are they forever to be separated, with distinct purposes? Our belief is that the two can, and indeed must, merge.
Of course, the private side of an MLS system has to meet the needs of an agent and those needs are, at times, different from what a consumer wants or needs to see. The agent uses the system every day, and it needs to respond to those needs. But, in the end, the MLS system is only for agents only if agents are the ones buying and selling the property. If not, then the system most definitely is there to serve consumers, whether the agent is the intermediary or not, because, in the end, the consumers are the ones doing the buying and selling.
