Why are Homebuilder Websites so behind the times? How can they improve?

Posted on
by Adam Albrecht

I have a special regard and a very strong opinion on a certain niche of the web: Homebuilder Websites. For 3+ years, I worked as a consultant at a large Homebuilder where my primary responsibility was their public-facing website - working on behalf of both IT and Marketing. Unfortunately, it's an industry that has always been a little behind when it comes to technology, which was only compounded during the housing crisis. But there is still hope! The housing market is starting to rebound and the personal computing landscape is shifting towards mobile, which levels the playing field a bit for everyone going forward. A well-designed, easy-to-use website will generate more leads, more customers, and pay for itself in no time.

Why are websites important to Builders?

The importance of a website to a business in any industry cannot be understated. For an increasingly large percentage of your potential home-buying customers, this is the first point of contact. And thus it is also their first significant impression of your brand. And tech-saavy customers (particularly younger ones) are informing themselves and comparing builders long before they ever talk to a salesperson. So your website must also be functional, easy-to-use, and present the proper information. In general, your website is the front-line of your overall sales strategy. And perhaps the most important piece.

Why so bad? How can they improve?

With the housing market crash, it's no surprise that the Marketing and IT budgets at Homebuilders have taken a nose dive. But the problem is rooted deeper than this. Building and construction has never been a tech-saavy industry. But this doesn't translate to their customers, who cut through all demographics and, in an age of Google, iPhones, and Facebook, have come to expect that all products and services to reach a certain level of design and technical sophistication.

But what's wrong with today's crop of Homebuilder websites? I reviewed 25 of the 2011 Builder 100 and the following 6 features (or lack thereof) jumped out at me:

#1: Modern Design

Most builder sites look like they were designed in the late 90's... Because a lot of them were. As I said above, your website is often the first brand impression for your potential customers, so don't skimp on the design and don't do it in-house. Take a look at the new KBHome.com. Then go to your website and, based solely on design and initial brand impression, who would you choose?

KBHome.com Homepage

#2: Photos, Photos, Photos

A few days ago, my girlfriend and I were in line to order food at a local Panera. Our conversation went something like this:

Her: "I think I'm going to get the something something grilled cheese and tomato soup."

Me: "You mean the exact 2 items in the giant photo next to the menu?"

Her: "Yep. I'm way more likely to buy food I see a giant photo of it."

This is not unique to my girlfriend. Nor to food. Large, high-quality photos can do wonders in moving a casual website visitor to one who fills out a contact form or picks up a phone. Plus, they add to the perception of your brand. So don't hide them behind extra clicks. Put them front and center.

#3: Page Speed

Studies have shown that 40% of web visitors will leave a page if it takes longer than 3 seconds to load. And every 1 second delay decreases visitor satisfaction by 16%. And a more satisfied visitor is much more likely to fill out a contact form. There are a number of ways the speed of your website. Talk to a developer and make this a priority!

#4: Frictionless Contact Forms

Did you know that eliminating 1 field on your contact form will, on average, increase conversions by 50%. Read that again! 50%! There is a tendency among homebuilders to try to get as much information as possible about their leads via contact forms. The idea is that a lead who gives a name and phone number and address is more likely to convert. And this is probably true. But how many potential leads are you missing out on because of the additional friction that each contact field adds? Even if you're not ready to go to an email-only contact form, at least try it out with a subset of your users. By doing an A-B test, you try out different configurations of your contact form and figure out which one performs best among your site's visitors.

#5: As Few Clicks as Possible

Take out your iPod and navigate to a specific song. You probably clicked on the artist, then the album, and then the song. And it probably only took you 10 seconds or less to choose 1 song out of thousands. Homebuilders have a similarly hierarchical data flow and you should be able to navigate to a desired community or spec just as quickly. So make sure your navigation system is extremely fast and simple.

And you can even take this a step further. Did you know that as soon as your visitor hits the homepage, your website is capable of knowing their location to within a few miles? And if your web visitor is in Houston, Texas, the chances of them buying a house in Cincinnati, Ohio is pretty slim. So you can skip a step and take them directly to your Houston page! Sure, a few users will have to click to another page, but they will be the vast minority. And you can save this preference for later when they come back to their site.

#6: No More Mixed Messages

It's okay to put out new and changing marketing messages on your site, but don't go overboard like many homebuilders do. They may seem to perform well individually, but when you have so many of them, they lower the customer's impression your brand. At a certain point, your website starts to look more like a Nascar driver than a well-respected builder of Homes. So take it easy on the marketing promotions.

#7: Mobile & Tablet Friendliness

I think everyone knows the importance of this by now, but too few Homebuilder sites are optimized for what is becoming the primary computing device for most people. You probably already have potential customers who are in their cars driving around communities with their smartphone in hand as their research tool. If your site isn't mobile and tablet friendly already, make this a huge priority. There are multiple ways to accomplish this, so talk to a developer as soon as possible!

And on another note, you do not need a native mobile app. A mobile-friendly website will reach a much wider audience because consumers don't like to download apps they won't need for an extended period of time. And if you still feel compelled to have a presence in the Apple or Google app stores, the mobile website can be wrapped inside a native application. (For more info on doing this, check out our blog post from earlier this month)

Conclusion

Homebuilder websites have become essential to new home marketing and sales. They have become the primary point of contact for a large percentange of customers and often their first impression of your brand. So don't undervalue their importance! A well-designed, easy-to-use website will generate more leads, more customers, and pay for itself in no time.

So if you're in the market for re-design or even just want some advice on how to fix up your current site, we'd love to talk! We're passionate about the web and passionate about Homebuilding.


Getting Started with Sencha Touch

Posted on
by Mez Gebre

Last week, I was talking to a potential client at his place of business. I told him about my line of work and suggested that a mobile app could help his business’. He replied that he already had an iPhone app, but needed an Android version and asked if I could do it. I wanted to tell him Yes, but I couldn’t in good conscience because the truth was that I had never done any substantial android development. We went on to discuss his other needs, but the fact that I had to turn down good work left me with a sour taste in my mouth.

So the next day, in an effort to help out this client, I started looking into alternative ways of creating Android apps without having to rely on Java, one of my least favorite programming languages. While I normally prefer 100% native apps, the app this client was requesting was mostly static content and data meant to be consumed. There was very little user interaction and the most complex feature was simply showing the client’s business on a map.

Because of these rather simple requirements, this app could be developed with standard web technology (HTML, CSS, and Javascript) and then wrapped into a native phone app. While there are several frameworks available to serve this purpose, I will be focusing on Sencha Touch 2. This framework allows you to create HTML5-based mobile apps that work great on Android, iOS, and Blackberry and give the user a native-app-like experience. If you have done any iOS development, this framework will feel familiar to you, minus the verboseness of Objective-C. Sencha also uses the MVC pattern, and if you have used Ruby-on-Rails or other similar frameworks, you’ll appreciate the convention over configuration approach of Sencha Touch.

For this introduction, I’ll quickly go through installation and a simple app to get started. Then I'll give my impressions of Sencha Touch as well as point you in the right direction to learn more about the topic.

Installation

I'll be showing you how to do this on a mac, so if you’re using Windows, you may want to reference these instructions. To install and use Sencha, it is helpful to have a local web server running. I personally like and use nginx, which is extremely easy to install with Homebrew. Simply run:

'brew install nginx'

Once installed, it will place the Nginx configuration file in /usr/local/etc/nginx. Edit the nginx.conf to make sure you have the web root directory in a place you know. What I did was create a symbolic link of my sencha dev directory into the web root folder. I am not going into detail of the web server install because that is a topic you can easily google. Download the Sencha Touch SDK and place that in your root folder that you defined earlier. Instead of the SDK Tools, go ahead and download Sencha Cmd. This is an excellent command line tool used to generate a lot of boilerplate code for you. Coming from a Rails background, this was a huge win for me. Once you have Sencha Cmd, go ahead and run the following from your terminal of choice (I prefer iTerm 2).

sencha generate app HelloSencha /path/to/directory/HelloSencha

If you run that command from the Sencha SDK directory then the generator will know where the framework src is, which it needs. I did not do this at first and it was not obvious that I had to run that command from the sencha SDK folder. Fortunately I found a flag I could use to tell the generator where the framework was located. Using the -s option I was able to pass in where I installed the sencha framework. So, for example I did the following:

sencha -s path/to/sencha2.1.0 generate app HelloSencha ./HelloSencha

Now you should have a basic Hello World project setup and we can do some real coding.

Building a Quick App

A good place to start is the Sencha Building Your First App tutorial. The instructions were, for the most part, straight-forward and help you get an app together in 15 min. But one thing you may have trouble with is trying to style the home page like they do. What I did to solve this issue was open app.css and append the following to the end of the file:

.home{text-align:center}
.home h1{font-weight:bold;font-size:1.2em}
.home p{color:#666;font-size:0.8em;line-height:1.6em;margin:10px 20px 20px 20px}
.home img{margin-top:-10px}
.home h2{color:#999;font-size:0.7em}
.blog p{color:#555;padding:20px 20px 0 20px;font-size:1em;line-height:1.4em}

This aligned and styled the home screen like they show in their demo. The getting started app they showed was OK, but I feel a real novice would of had many questions. I got through with the example with minimal issues because I have experience with other front end frameworks.

Packager

One awesome feature that comes with the framework is the packager tool. Watch this video to get a run down on the feature. The guy giving the talk was a bit wordy, but there is some good stuff in there. The way the packager works is as follows. First you need a json file that tells the packager what environment to deploy to. Once you have your json file defined just run the following command:

sencha package run <config.json>

If you do native packaging you can get access to the native APIs, such as the camera and gyroscope! Access to the native APIs is done with the Ext.device which is just a wrapper to a third party solution like PhoneGap which is now known as Apache Callback.

Debugging

Debugging can be a pain in the ass when you package a web app inside a native wrapper. One awesome tool that you can use to help out is Weinre (pronounced like the word “winery”). The documentation for this tool is pretty straight-forward.

Overall Impression

Overall, my first impression of sencha touch 2 was definitely positive. The class system with the mixins and config support makes for a really easy to understand and clean APIs to work with. I also really enjoyed the extensive and clear documentation, although the introductory docs were a bit lacking, particularly if you're not an experienced app developer. To a beginner, I could see it feeling a bit overwhelming. I also wish there was better support for html-based templates out of the box because I'm not a big fan of rendering HTML within Javascript. So you may want to look into some 3rd-party templating libraries such as Handlebars.js.

More Reading

I would personally recommend the following order to read the Sencha Docs for best understanding:

  • Sencha Touch Videos - watch all of the videos in the concepts especially the MVC in Depth part 1 and 2. I liked the addition of the Store concept that automatically binds to the views and updated views automatically when models in the stores changed. I did not have to wire up any events for binding which was nice.

  • Sencha Touch Guide - This has a number of articles on all aspects of the Sencha Touch platform.

Stay Tuned

Sencha Touch is a huge library with tons of documentation and I hope that I at least got you pointed in the right direction. The next article I'm planning to write is on making these web apps native. Follow me on twitter @mez_gebre and please let me know if you have any questions or comments. Thanks!


Our Startup Weekend Columbus Experience

Posted on
by Adam Albrecht

Background

Last weekend, the JetCode team decided to participate in one of my favorite events ever: Startup Weekend. What is Startup Weekend? It's a 54-hour seat-and-caffeine-fueled collaboration of developers, designers, business folks, and other passionate individuals to create a business in a weekend.

The first Startup Weeekend took place in Boulder, CO in 2007 when Andrew Hyde decided that he wanted to get together with some friends and build a business over the weekend. It took off and they started holding Startup Weekend events all over the country and, eventually, the world.

The event works like this: On Friday evening, a whole bunch of people (50 or so at our event) get up in front of everyone and quickly pitch a business idea. Then everyone votes on the ideas, although this doesn't really matter. Afterward, everyone walks around and talks and then teams are formed organically. Next, the teams work furiously over the course of the weekend until presentations Sunday evening where the teams demonstrate their idea, business model, and prototype. Winners are picked by a local panel of business people and entrepreneurs.

Project Lytehouse

I had done a Startup Weekend a year ago in Cincinnati, but this was Mez's first time. While Mez did decide to pitch an idea at the last second, we didn't plan on working on any of our own ideas. We were more interested in hearing the ideas of others so we could try to think outside our own personal and professional bubbles. After hearing all of the idea pitches, neither of us were particularly impressed and so we briefly thought about working on something alone. But an enthusiastic 5th-year senior at Ohio State named Sai finally convinced us to work with him on his idea of a somewhat strange iPhone app called Lytehouse. It was an almost geocache-like system where people would check into locations and pickup digital contents, often in situations where people would normally use flyers.

Right off the bat, Mez and I knew this idea needed to be dramatically re-worked to be a decent business, but we liked idea of doing something based on location. After bouncing ideas for a couple hours, we finally settled on a super simple file sharing app that allowed you to share files in social settings without having to know a person's name or contact info. You just share a file at a location and anyone around can go to the website and immediately access it. The plan was to use Dropbox as the source for sharing files since most of our tech-saavy audience probably uses Dropbox already. The file you choose would then be shown on the homepage for anyone nearby. No clicking around, no signup.

So Saturday morning, after I came up with some quick mockups, Mez and I worked furiously at what was now a mobile web app that used HTML5 geo-location API's to access a person's location.

Lytehouse Quick Mockups

We built it as a Rails app and used the recently released Ratchet library to make it user-friendly Meanwhile, Sai and Ben (our 4th team member, an excellent graphic designer) worked on the business strategy and branding.

The end-product, amazingly enough, looks almost identical to the original mockups and was pretty slick. And while it wasn't completely polished, the basic use case of sharing a file nearby was totally functional and useful (we even used it a couple times as we worked on the project).

Lytehouse Screenshots

And here's a video of our presentation:

Results

So we gave our presentation on Sunday and, believe it or not, we were chosen by the panel of judges as the First-Place team! But even if we hadn't come in first place, I would still rave about the experience we had at Startup Weekend. Mez didn't quite get what the fuss was all about, but by the end of the weekend, he was an admitted Startup Weekend addict!

Going Forward

So what will happen to Lytehouse? Well, we haven't quite decided yet. I think it's a pretty useful app that a lot of people would use. I'm not so sure about the business model, but I bet we can come up with something decent enough. So I think the current plan of action is to get it to a stable 1.0 and then put it out there for the world to see. If they like it, then it'll be full-speed ahead!

The LyteHouse team from Startup Weekend Columbus, OH 2012


Attach a Blog to your Rails 3 App with PostMarkdown

Posted on
by Adam Albrecht

Today I finally decided to add the missing piece to the JetCode website: a blog. I am almost always in favor of rolling my own solution, but since blog functionality has been solved over and over and over, I figured my time would be better spent elsewhere. My criteria for selecting a blog platform would be the following:

  • Lean and minimal. (No fancy Wordpress features needed)
  • Support Markdown
  • Integrates well with Rails 3

Pretty simple requirements and I had no problem finding multiple solutions that most likely would have worked, but a gem called PostMarkdown seemed to fit the bill best. There's no database involved with Postmarkdown. You simply write your posts as flat markdown files with some meta-data such as a title, author, summary, etc and then re-deploy your site and, boom, a new blog post. And since you're presumably using Git (or version control system), you get free version control of your blog content.

Setup

Setup was ridiculously easy: Since Postmarkdown was built as a Rails 3 Engine, just add to your gemfile and run a provided generator and you're good to go.

gem 'postmarkdown'

bundle install

rails generate postmarkdown:install

And with that, you have a basic blog going. It creates a directory at app/posts to store all your posts (as markdown files), a few overridable routes, and an example post.

Next, because I wanted my blog to be located at /blog rather than /posts and skip the dates in the URL for individual posts, I changed the provided route from just a simple postmarkdown to postmarkdown as: :blog, permalink_format: :slug.

Writing Posts in Markdown

To generate a new post, you could create a file manually in app/posts with a filename formated as follows: yyyy-mm-dd-this-is-the-posts-url-slug.md, but an easier way is to simply run the post generator that PostMarkdown provides:

rails generate postmarkdown:post test-post --date=2012-11-15

This will generate a properly named post that contains some sample markdown text you can play around with. And the Date option is not required and will default to the current date.

If you aren't familiar with Markdown, it's extremely easy to learn. There are plenty of rules, but here are some of the basics:

  • Normal text blocks are converted to <p></p> tags,
  • # converts to <h1></h1>, ## to <h2></h2>, etc
  • Use * for un-ordered lists
  • Use numbers for ordered lists
  • Make words italic by surrounding with asterisks *Hello!*
  • Make words bold by surrounding with 2 underscores __bold word!__
  • Create a link using this format [The Link Text](http://the-link-url.com)

You can learn more about Markdown here.

While writing your post, you can run your rails server locally and, after saving the .md file, simply refresh the page to see your nicely formatted blog post.

Customization

PostMarkdown produces very clean and semantic html, so it's very easy to style your blog just to your liking. But if you do want to customize some of the markup, there is a provided generator that will override the default views.

rails generate postmarkdown:override --views

This will produce a new directory of haml files under app/views/posts. In my case, I just wanted to change the format of the date and add a class to a particular element in the header of post, so I edited the app/views/posts/_post.html.haml to my liking, refreshed the page, and it reflected my change without even re-starting the server.

You can override other parts of the blog engine, as well, including the post model, the controller, or the optional default theme that it comes with. See the documentation for more info.

Conclusion

That's really all there is to it. Nice, simple blog functionality with a quick setup and version-controlled formatted posts. On an old personal site, I implemented all these features myself and it probably took me a good half-day to finish. But Setting up this blog engine and customizing it to my liking took no longer than 15 minutes. Highly recommended!



Contact Us

There are no strangers here; Only friends you haven't yet met. - William Butler Yeats


JetCode
544 South Front st
Unit 217
Columbus, OH 43215

(614) 636-2633
contact@jetcode.io