Announcing Village Properties’ new mobile property search application

Village Properties RealtorsWe are pleased to announce the release of the new Village Properties mobile property search application, which we launched at the end of this past October. Village Properties is the largest independent brokerage in Santa Barbara, CA, and they were the #1 Real Estate firm by sales volume in the area for 2012.

Goals and Approach

Village Properties mobile website home page comparison

Click image to enlarge

When we began the project with Village Properties earlier this year, they already had a dedicated mobile site that had a responsive website design feel to it. A navigation menu was presented across the top of the page, and the user navigated the site as they would a standard desktop site. The design was functional, but it did not take full advantage of many of the features and capabilities of today’s mobile devices such as location and touch events.

Our goal with the upgrade was to improve the user interface, create a more engaging design, and incorporate more mobile device functionality into the app. To achieve these goals, we migrated the interface toward a more “native” look-and-feel while maintaining a web-based approach, which we were able to do through our use of the Sencha Touch framework. We also preserved the Village Properties branding by using the same color schemes from their website in the mobile app and provided a consistent user experience for their clients by providing similar options for things like property searches.

Providing a “native” mobile web experience

We were able to achieve a more “native” look-and-feel by doing the following:

Village Properties Mobile Web Application Navigation

  • Flattening navigation of the app
    Keeping the page hierarchy and navigation of the application as flat as possible allowed us to utilize a tabbed structure for navigating the app, similar to a native design. Once the app is loaded, the user is presented with direct access to the four key sections of the app – Search Nearby Properties, Search All Properties, Agents, and Contact Village. Once in the app, these four areas are always accessible via a tab bar at the bottom of the screen, while tabs across the top allow for navigation within each section (see right). Deep navigation occurs only when the user is viewing property search results or individual property details.
  • Limiting server side interaction
    Due to the variability in the speed and quality of mobile connections, communication between a mobile device and the server can significantly impact and limit the performance of a web-based app. Therefore, we made it a point to limit the amount of interaction required between the mobile device and the server. After the initial load, the app only communicates with the server to request data, such as property listings and details. By limiting the interaction, the web-based app performs similar to a native app, particularly when switching back and forth between tabs, or sections.
  • Using touch events and gestures
    The app was designed from the ground app with touch in mind. Buttons are used throughout to make it visually clear where actions can be taken, gestures are implemented where appropriate (such as swiping through photos), and typing is kept to a minimum through the use of selection boxes and dropdowns.

Incorporating mobile functionality

We also took advantage of mobile-specific areas of functionality by including the following in the app:

Mapping integration in the Village Properties mobile app

Click image to enlarge

  • Location
    By utilizing the location capabilities of the mobile device, we included the option to search for properties by location. This feature allows the user to simply press a button from anywhere within the app to receive a list of properties that are located around them.
  • Text messaging capability
    In addition to standard contact functionality such as phone and email, we provide a method for people to connect with agents via text message through the app. Clients have the ability to use the method of communication they prefer and can communicate with agents or submit property inquiries via phone, email or text with the press of a button.
  • Access to phone applications
    Besides including access to obvious device applications such as the phone dialer and email application, we also provided access to other apps such as maps and driving directions. For example, when searching for a Village Properties office, we provide direct access to the mapping application which provides directions to the office from the user’s current location.

Results thus far

In the three weeks since we’ve launched the app, usage and engagement has improved over the previous design. Visits to the site over mobile devices have nearly doubled, bounce rates are much lower at ~35%, and time on the site is averaging about 5 minutes per visit. More importantly, large numbers of searches are being performed, property details pages are being viewed, and contact buttons are being used on both the agent directory and property details pages. One of the most surprising results is that property searches are being dominated by location, which is in contrast to the other real estate apps we’ve deployed where advanced searches dominate the search type.

Going forward

Mobile is moving fast, and so are the requirements for apps. We’re planning to work with Village Properties over the next 12-18 months on a number of feature enhancements and upgrades. We will also be keeping a close eye on the analytics and measuring the performance in support of their mission, which is “to continually ‘raise-the-bar’ of excellence in the Santa Barbara Real Estate industry.”

View our latest mobile web-based app on any iPhone and Android device by opening your web’s browser and going to You will be automagically redirected to the mobile app. Once loaded, you can start searching properties in the Santa Barbara area, contact Village Properties or get in touch with one of their agents for assistance!


What’s the deal with Sencha Touch generated getters and setters?

When you first start using the Sencha Touch framework you will hear about config blocks and the automatically generated getters and setters for the properties you define in them. But what does that really mean?

To review: properties you define inside a config block get framework generated getters and setters. Outside the block they are just plain javascript.

Ext.define('App.view.About', {
   extend: 'Ext.Container',
   xtype: 'aboutus',

   requires: [

   myPlainProperty: null,

   config: {

      myConfigProperty: null,

      items: [
             html: 'Hello World'


If your background is object oriented (OO) development then it has been ingrained into you that accessing properties directly breaks encapsulation so you will probably default to defining your custom class properties inside the config block so you can take advantage of the generated getter and setter. For example: var foo = this.getMyConfigProperty(); and this.setMyConfigProperty("foo");

OK, now the first time you need some “logic” in a property you might resort to pulling it out of the config block and write your own getter and setter functions backed with a class instance variable like myPlainProperty above.

But as you continue to work with the framework and dive into the source code (as you inevitably will either to learn or stepping into it during debugging) you will continually see applyPropertyName and updatePropertyName methods in the Sencha code.

And these are the answer to avoiding the above hand written functions, the Sencha Class system supports two functions matching the name of your property that gives you hooks to add logic into the process.
Here are the method signatures:

  • appliedValue = applyMyConfigProperty(newValue, oldValue)
  • updateMyConfigProperty(appliedValue, oldValue)

So there you have it, put your code that does validation or filtering in the apply and take actions that depend on this property in the update!

This methodology is powerful and is used extensively in the Sencha framework so you have a wealth of code to see it in use.

For more information see the docs:
v2.2.1 Class System
and slide 32, 33 from this presentation:
Sencha Class System, Jacky Nguyen

Sencha Touch list with page numbered dividers

For a recent project I needed a list that displayed how many items were in a “page” and how many items there were in total. This way as the user scrolled they could visually keep track of where they were and how far they had to go.

This is common practice in desktop web sites with the pager links and information at the top and/or bottom of the page but in mobile we generally present a vertically scrolling list to save space and because it is easier for a touch device to drag the screen up or down than to tap a next/prev link.

Here is a screen capture of the finished product:
List screen capture

Initially I expected the solution to involve inserting “pseudo” elements into the list between the pages to contain the item counts and total or to avoid the Ext.dataview.List all together and build the layout template from scratch with raw DataItem’s. I also artificially restricted myself to the useSimpleItems=true list configuration as our dataset could be quite large and the Sencha Touch documentation warns about potential performance problems.

The other problem I was struggling with even if I could insert extra items into the list was how to not break the relationship to the store the list was bound to. In addition sorting had to be considered as that would change the item indexes and their relationship to the DOM elements.

While I was digging around in the Sencha source code to solve these problems it dawned on me I could do this with grouping! So after some trial and error a customer grouper function was all that was needed.

Here is the code you would put in the store the list is bound to:

grouper: {
    groupFn: function (record) {
        var store = record.stores[0],
            pageSize = store.getPageSize(),
            cachedCount = store.getAllCount(),
            totalCount = store.getTotalCount(),
            index = store.indexOf(record) + 1,
            totalPages = Math.ceil(cachedCount / pageSize),
            pageIndex = 0,

        for (pageIndex = 0; pageIndex <= totalPages; pageIndex++) {
            lower = (pageIndex * pageSize) + 1;
            upper = (pageIndex * pageSize) + pageSize;
            if (upper > cachedCount) { upper = cachedCount; }
            if (index >= lower && index <= upper) {
               return "Properties " + lower + " - " + upper + " of " + totalCount;

While the code is not that elegant and there is probably a small performance impact the advantage of this simple solution is it satisfied the visual requirements and does not require a departure from the standard well known Sencha Touch list component.

Store code available from our GitHub repository.

Mobile is a competition for people’s time

When looking at user behavior on mobile devices, it can be simplified into an equation. On one side is the number of mobile applications available, and on the other side is the amount of time a user has. On the number of apps side of the equation, the number continues to grow on a daily basis, seemingly exponentially. On the amount of time a user has side of the equation, the number is relatively fixed and under constant downward pressure. This imbalance led to an astute observation by Waze CEO Noam Bardin when he said, in reference to how the future of mobile will play out, “the next five years will be about fighting for time with users.”

It means that developing for mobile is only an entry point for success on mobile these days. The bigger challenge is figuring out how to engage users so they will spend their most valuable commodity, their time, with you. In other words, how do you create user engagement on a mobile device?

#1: Understand why consumers would want to access your mobile presence
Taking your desktop website and stuffing it into a mobile form factor is NOT the right answer. Neither is building your mobile presence around what people do on your desktop site. Mobile is a completely different beast, and context is king. Think like your target user(s), label a few cases, and identify under what conditions, or context, a user would access your mobile presence.

#2: Identify the goals consumers want to accomplish
Once you’ve determined the conditions, the next step is to identify what they want to do. The goals can range from extremely big, like storing information about everything in the case of Evernote, to small tasks-oriented items, like finding directions and store hours in the case of a retail store. In either case, you want to make sure your users can accomplish their primary goal(s) as quickly as possible. Mobile users are looking to complete targeted tasks, which is very different from desktop users who are more likely to engage in research related, time consuming activities.

#3: Determine how users will find your mobile presence
Will users learn about your presence through word-of-mouth,online blogs and websites, social media, Google searches, voice-based searches such as Siri and Google Now, or offline print media and ads? While you may not care, it will have a huge impact on the type of mobile presence you decide to create. For example, if you expect the majority of your traffic to come from Google searches, an easy to navigate and use mobile website should be your top priority (although I would content that a well functioning mobile website should be at the top of everyone’s list, but I digress).

#4: Select a mobile presence that fits with what your users expect
For example, if I’m developing a game for mobile, users expect that it will be a native app. If I intend to use your application multiple times a day or week, I would prefer the convenience of an app. If I only need to use your presence occasionally, or just once, than I just need a usable, well-designed mobile website.

#5: Create some “magic” through the user experience
Of all these points, this one is the most difficult. The best apps create a complete user experience that embodies not only mobile but also your desktop, social media, and offline entities. They include mobile as part of their overall user experience instead of treating it as a completely separate object. Unfortunately, there aren’t any hard rules or formulas that you can apply to create a magical user experience. You have to look at your brand and your users (and/or customers), apply some creativity, and determine the design and features that will make people want to engage with your mobile presence.


In the early days of mobile, creating a mobile website or native app was enough to succeed. It isn’t anymore. The mobile space has become too crowded. You need a strategy that determines how you will engage the user and win the on-going battle that is the competition for their time.

Mobile Web or Native App: The Debate Continues

In addition to the debate between responsive web design (RWD) and dedicated mobile websites, which I discussed last week, another great mobile debate is the choice between developing a mobile web application/site or a native application. As with all great debates, this is not an either/or decision. Just like the RWD versus dedicated mobile website issue, it requires analyzing the desired goals and outcomes and choosing the right tool for the job.

Why do we have native apps?

In order to understand and frame the debate, it’s important to understand how we got here by understanding why mobile apps exist.

When the original iPhone was launched in 2007, native apps were not part of the plan. The original plan was to have all third party applications run through the browser over the web. Unfortunately, there were a number of issues that developers ran into when they tried to write feature-rich, web-based mobile applications:

  • Network speed
    In 2007, wireless providers were still filling out their 3G footprints and improving capacity. For example, AT&T’s network went through a lot of growing pains, which I’m sure early iPhone users still painfully remember. Network limitations made access to apps difficult and had a large impact on performance.
  • Web features and capabilities
    Web technologies such as HTML5 and CSS3 were still in their infancy at that time and not fully baked nor supported consistently across mobile browsers. Plus, access to phone hardware and offline capability, didn’t exist or weren’t ready for prime-time.
  • Access to hardware and operating system
    In order to maintain security, the mobile phone and OS manufacturers closed off access to the hardware and operating system features.
  • Screen sizes
    Native apps were the best way to make use of the small of amount of available screen real estate on those first smartphones.

So why build for the mobile web?

If native apps have these inherent advantages, why would one want to build a mobile website or mobile web application? Well, a lot of the limitations that native apps addressed have been resolved over the last five years. Carriers have upgraded their networks to be more reliable, offer better coverage, and, with LTE, provide much higher speeds. Web standards have evolved and are supported across mobile platforms, and they continue to get better every day. Some of the latest advancements in the standards are providing developers with better access to hardware features such as the camera, accelerator and gyroscope, and graphics capabilities. Screens have also evolved, and while screen real estate is still at a premium in mobile, the average screen size has grown over an inch from 3.5″ to close to 5″ with high definition resolutions of up to 1080p on some models.

With these limitations solved, there are some inherent advantages that the mobile web has over native applications:

  • Discovery
    Instead of having to sift through the native app stores, discovering a mobile website or application can be done using standard web searches, which consumers are very familiar with. Common SEO techniques and practices can be used to make sure your mobile web presence ranks properly, and you aren’t subjected to the promotion practices and policies of the controlled and curated app stores. In addition, as more people use Siri, Google Now, and other voice search systems, which are geared toward crawling the web, there’s a better chance that someone will find your mobile web presence through a voice search.
  • APIs and data mashups
    Using web standards and open APIs, it can be easier to create richer applications by sharing data via web services and to migrate between devices and platforms. Native applications, on the other hand, are more likely to store data locally, which makes it harder to interact with other services and to upgrade or change between devices and platforms, creating a lock-in effect for the end user.
  • Cost and efficiency
    Since HTML5 is well supported across mobile browsers, mobile web solutions can be built once and immediately distributed across all platforms – iOS, Android, Windows Phone and BlackBerry. There is no need to go through the cost of developing for each mobile platform or of waiting for the approval of each app store. Also, if new platforms emerge, such as FireFox OS or Ubuntu, there’s a much better chance that your application will be available on these platforms with little or no change required.

So does the general public care?

The answer is no. The user really doesn’t care whether the app is web or native. They just want to access information or complete their task  in the most efficient way possible. The people who care most about the mobile web versus native debate are the hardware/software manufacturers and developers, each of which have a vested interest in the discussion. Therefore, depending on what is best for their well being, that is the side that they are likely to push.

How should you decide what to do?

To get you started, I would suggest looking at the four primary activities that people perform online as outlined in a 2012 Pew Research Report:

  • Accessing information
    If the primary goal of your mobile presence is information access, then a web-based strategy works best. The primary reason is for discovery and updating. You’ll want to make sure that people can easily find and access your latest and greatest content without having to worry about it being buried in an app store.
  • Learning
    If your site is geared toward learning, I would recommend a mobile web first strategy since it will be the easiest way for people to find and access your information. However, if you’re doing a lot of static course-based material, such as a university course, a native app may allow you to create a more specific, richer learning interface using a dedicated piece of hardware, such as a tablet.
  • Entertainment
    Typically, this will be better in a native app interface because you can get deeper access to the hardware and operating system to better utilize the graphics, video and audio capabilities of the device. It will also be easier to monetize your entertainment or gaming app through the app store than it will be over the web since users are generally conditioned to pay for this type of content. However, for simpler projects where monetization is not important, a web-based approach may work better.
  • Content Creation
    For creating content, I’d recommend a native app. Again, there may be some web-based tools, but content creation can be very challenging on a mobile device. Therefore, it is recommended that you develop a native app that makes usage of the guidelines and input methods of the operating system and the hardware.

Overall, the best advice I can give is to determine why users want to access your content on a mobile device, what actions or goals the user wants to accomplish, and what goals and outcomes you want to achieve from your mobile presence (visits, leads, sales, etc). Then decide which platform, web or native, works best.

In conclusion

The simplest answer to the web versus native debate is that you should always start out designing for the mobile web, since you have control over that presence and it is where the majority of people will start their search. Then you can evaluate whether a native app will help you to further achieve your mobile goals.

However, there are a few exceptions to the mobile web first rule. If you fall into one of the following categories, I would suggest going native as your primary mobile presence:

  1. High performance gaming
    HTML5 graphics capability has come a long way, but to get the best performance from your game, you’ll want direct access to a phone’s graphics hardware and any acceleration capabilities, which are more reliably accessed through a native application.
  2. High engagement/repetitive-task based apps
    If your application is something a user will make use of everyday, or multiple times a day, then a native app is the way to go. The most compelling reason is that native applications support push notifications, even when the app isn’t running. This allows you to alert users to new messages, send them reminders, or otherwise keep them engaged.
  3. Enterprise applications
    If you’re building a dedicated application that will be used solely by your business and its employees on a daily basis, then a native app would make the most sense. It will be easier to justify the investment in the native technology, it will provide your IT with control over the hardware, and you’ll be able to control the user experience. You will also get the benefit of being able to design a more secure application.

No matter what your specific case is, be comforted in knowing that the mobile web is not going away anytime soon, and neither are native apps. Both have there place in mobile and will continue to co-exist over the long-term. When deciding what to do, identify what your goals and desired outcomes are, and then choose the right tool for the job.

And if you need help, feel free to contact us. That’s what we’re here for!