Following is a follow up article to the comprehensive "Study of Multiple Listing Service Public Listings Websites" I performed earlier this year - http://www.realtown.com/mattcohen/blog/2009-mls-web-sites-study

One of the most important elements of an MLS listings web site is to have a feature that reports on the effectiveness of the site back to brokers and agents. HAR.com did a great job of this by implementing STAR (Strategic Traffic Activity Report) and IRES has produced its ColoProperty.com Usage Reports. When planning your future effort or evaluating your current one it is important to consider how you are implementing such reports.

Typically, reports show the following overall site statistics over the preceding month, quarter and year:

• MLS subscriber leads (email, phone, text, etc.)
• Hits
• Page views
• Visitor Sessions
• Unique visitors
• Average minutes spent on site
• Total visitor minutes
• Times listings viewed

Going beyond the site-wide statistics, reports to subscribers - broker and agent levels as applicable in your market - should show their own statistics over the preceding month, quarter and year:

• The number of times their listings were viewed - this could be interactive when viewed online and allow drilldown to a real-time breakdown of traffic by listing by date
• The number of click-throughs to their web site
• The number of times their email was viewed (requires use of click-to-see email addresses)
• The number of times email was sent to them via the web site
• The number of phone calls made to them (requires use of phone redirect)
• The number of text message leads sent to them (requires text message feature)

Ideally, these types of reports should be available via subscriber logins to the web site and also 'pushed' to subscribers who have listings on the site via email on a monthly (or at least a quarterly) basis.

There are many other aspects of the MLS public listings web site value that need to be communicated to subscribers - but ensuring that these type of metrics have visibility is a good starting point.

In my previous post, ("Web design: size matters" http://www.realtown.com/mattcohen/blog/web-design-size-matters) I explained why poor webdesign in terms of website page size is as much a concern for executives and other business owners as for web designers and (of course) consumers.

Now I want to bring up something that will surprise many people - executives and technical staff alike: Most industry web sites don't use valid HTML. HTML is the primary building block for the web, and it is astonishing that most web sites can't manage to use it correctly.

Why is valid HTML important?

• It helps ensure the site will work as new browsers are released
• It helps ensure a consistent experience cross-browser
• It makes web applications easier and less expensive to maintain
• It facilitates web accessibility (to differently abled individuals)
• It can enhance search engine optimization (SEO) - or at least really badly invalid HTML can have a negative impact.

If you are contracting for - or having your staff build - a web application, valid HTML should be a basic expectation!

But look at the chart  below - comparing 46 industry search sites (as discussed in my previous post) with over 350 MLS public listing sites (as discussed  in "A Study of Multiple Listing Service Public Listings Websites"  http://www.realtown.com/mattcohen/blog/2009-mls-web-sites-study). Only 1% of the MLS public listings sites and 7% of the industry search sites use valid HTML.



Some MLS vendors also talk about how important standards are - but visiting their home pages only a single MLS vendor (Stratus) is HTML standard compliant at the time of this posting.

Ironically, even RealTown (my blog host) has made it impossible for this blog to be HTML compliant - though I've asked them to  correct this and anticipate they will do so at some point. Of course my own professional web site is HTML compliant as one would expect.

Using valid HTML is an important part of building a web application - hopefully this blog post and the one previous to it have illustrated that web application best practices are not exactly universal in our industry and deserve more attention and oversight.

Test your own site here: http://validator.w3.org/

 

When developing a property listings website, basic good webmastering skills and attention to detail is important to create a good user experience. Recently a client complained to me that their site seemed slow to them – upon review I found to my horror that the home page was full of bad code and un-optimized images, and that the page topped out at over 800 kilobytes (kb)! Sub-pages weren’t any better. Even on a high-speed connection, downloading close to a megabyte to display a page is going to make a site seem sluggish. Even worse, if the site is at all popular, large page sizes increase bandwidth costs. If you are an executive, you just read the most important sentence in this blog post - there’s money at stake here!

In the example I was discussing earlier, when confronted with the review, the webmaster tried to make excuses – to paraphrase and sum up: “Look, this listings site over here is comparably large”.  Sorry, that doesn’t fly. Using the 1000 Watt Consulting list of Web 2.0 search sites and adding additional relevant sites from the Hitwise Top 20, I looked to see how large the home pages of 46 popular real estate search sites are, in terms of compressed kilobytes. The results:

The chart below shows a visual representation of the research results. Note that the X axis labels have been removed so as not to embarrass the most ridiculously poorly constructed sites.

Page load size is only one aspect of good design. For a good discussion of design, see Rob Hahn’s blog post and discussion - http://www.notorious-rob.com/2009/06/19/dear-brokers-please-spend-money-on-design/. I could go on for hours talking about all the things one should look for in web applications – I’m sure I’ll come back to some of them in future blog posts.

But for now all I’ll say is (insert shameless plug here) please consider getting a second set of eyes on your web application.