aha moment

noun Informal.

A point in time, event or experience when one has a sudden insight or realization:  My aha moment was when I realized asset tracking software increased my rental billings by 5%.

Suppliers using manual, paper-based systems to track rental of their portable assets often struggle with inaccurate customer rental balances. Errors occur when handwritten information is illegible, data is mis-keyed, delivery tickets get lost or order add-ons fail to be recorded.

Without good tracking, it’s easy for one or two assets to go unnoticed when delivering and returning large quantities of assets. Over time, these seemingly small errors can create a large disparity between what the rental system balance shows and what is actually with the customer.

If a customer thinks their balance is higher than it should be, they usually call to have it corrected. The supplier can burn a lot of time researching the issue, sorting through paper records and consulting with sales staff and delivery drivers. An audit may need to be performed at the customer’s site, which can result in writing off “lost” assets and rental revenue. In the end, it erodes customer trust.

This experience can lead suppliers to incorrectly conclude that asset tracking software will uncover more instances of overstated customer balances, and thus create more headaches. They fear that imbalances as small as one or two assets will add up to a significant amount when multiplied over hundreds of customers. The interesting reality is that this fear can blind suppliers to cases where mistakes favor customers, and they permanently lose out on rent that should be collected from those customers whose balances are too low.

“We discovered a number of accounts that had more cylinders than we were billing them for. When they started to exchange those assets one for one, we were able to recover and start billing for all those assets that were out in the market. We think our rental billings increased between three to five percent from that fact alone.” – Bob Ewing, President, Red Ball Oxygen

Good asset tracking software uncovers instances where a customer is being undercharged.

Consider a case where a customer actually has three assets, but due to a past error, shows a rental balance of two. If the customer always exchanges two cylinders, the supplier never becomes aware that the customer really has three assets unless they audit the customer or track the assets uniquely with an asset tracking software system. [See the infographic.]

Our experience shows that suppliers are missing out on rent for up to 5 percent of the assets at customer sites. Here are two quick formulas to determine the value an asset tracking system can offer:

Quantity of assets at customer locations
× 5% unaccounted for at customer locations
= Quantity of assets recovered by tracking software
× $ annual rent per asset
= $ rental increase

Quantity of assets recovered by tracking software
× $ value of each asset
= $ value of recovered assets

Recovering this five percent loss equates to real rental income that goes straight to the bottom line, year after year. Meanwhile, the value of the recovered assets that were unaccounted for could have disappeared completely from inventory.

You’ve decided it’s time to invest in a tracking software solution to help manage your portable assets. Whether your company is smaller and seeking to replace a manual, paper-based system or larger and finding your existing software no longer supports your business, you have similar concerns in selecting your new solution.

Making the right choice doesn’t have to be hard. The questions below will help you identify and evaluate the critical features that will provide the best return on investment now and in the future.  

Is the software easy to use?

Asset tracking software shouldn’t require extensive training. If it’s complicated or difficult to use, employees will be slow to embrace it. Easy-to-use software provides a friendly interface that works like users expect. Menu functions appear in a logical order with the most common ones presented at the top of the menu list, not buried in the hierarchy. The selection buttons on the mobile device are big enough so that larger hands or gloved hands don’t select the wrong option by mistake.

Is the system flexible?

Every business is different and you’ve developed processes that work best for your company. Choose a solution that can conform to your unique requirements, not the other way around. Flexible software is easily configurable, including how data is collected and the ability to rename fields. It allows for variations in routines and offers workarounds for occasions when exceptions occur.

How well does the system handle mistakes?

An asset tracking software system increases accuracy, but errors still can occur. Drivers forget to scan an asset. A mobile device is not synced for a few days. A situation arises when assets have duplicate serial numbers. A barcode or RFID tag falls off. The best asset tracking solutions provide simple ways to correct these inevitable errors. When you have narrowed your choices down to a short list and it’s time to see a demo, ask the vendor to include examples of how the software handles these specific scenarios.

Is the software scalable in cost and scope?

Some tracking systems require large upfront investments and long-term contracts which are not suitable for all organizations. Cloud-based tracking software allows companies to pay a monthly fee for only the service they use, with the ability to increase or decrease service at any time.

A scalable asset tracking solution provides the option of starting small and adding more features as your business requires. You can start with a module for tracking assets, then add a module for tracking rental balances (if you charge a rental fee) and later a module for recording asset maintenance actions. Keep in mind, while it might make sense to start out small, be sure the software is robust, with a proven track record of handling customers with millions of assets from multiple locations.

Does the software support a variety of mobile devices?

It’s possible that hardware requirements differ among employees and departments, so it’s important that the software can operate across different devices simultaneously. Rugged handheld computers are best for plant floor workers or delivery drivers working in harsh environments while sales reps or field service employees usually prefer smaller, more portable devices like smartphones.

Additionally, bring your own device (BYOD), the policy of permitting employees to bring personally owned laptops, tablets and smartphones to the workplace and use those devices to access privileged company information and applications, is becoming increasingly popular. Asset tracking software that can work with any of these devices offers the best return on investment.

Does the tracking software integrate with my business management software?

Properly integrating the asset tracking software with other systems will improve the way you do business by increasing productivity, efficiency and cost savings. Some tracking systems prevent integration with other software, perceiving it as a competitive threat. This can limit your ability to operate effectively, resulting in duplication of work and information. Failing to properly integrate applications increases cost by requiring painful workarounds or manual integrations and lessens the return on investment.

What are the vendor’s plans for future improvements?

It is important that the vendor has a viable vision for the future direction of the software. Ask to see the product roadmap which provides insight into ongoing development and improvements. Notice how often the vendor releases enhancements and if any of the planned enhancements are relevant to your business.

Are you currently researching asset tracking software solutions?  What questions are you asking?  Share your thoughts below.

Many forward-thinking companies are finding ways to change the game within their industries by using asset tracking software to achieve operational advantages. They’re gaining added value by fully exploiting the data collection capabilities of mobile handheld devices and doing something meaningful with the wealth of data gathered routinely from on-going system activity.

Below are some perceptions you might have about asset tracking software. Read on to learn which ones are true (but don’t tell the entire story) and which ones are false. 

Perception:  I’ll know where my assets are.

An asset tracking software solution will tell me the location of my assets. I’ll know exactly what assets are where and I’ll gain greater accountability for their usage.

Reality:  You’ll also know where your assets have been.

In addition to knowing an asset’s current location, you will have an historical record spanning the life of the asset. Not only will you know where each asset has been, you also will know every transaction that has occurred. This detailed history is helpful in providing evidence to settle customer disputes, documentation for government regulations and product recalls, and verification of maintenance performed for warranties.

Following a major hurricane, one company received a number of medical oxygen cylinders that likely were contaminated by hydrocarbons from overflowing fuel tanks. The company used the history stored in the asset tracking system to back-trace the cylinders to the customer who originally received them.  The company was able to prevent a catastrophe by warning the customer of the potential dangers of cylinders that might still be at their location.

Perception:  Accuracy and efficiency will improve.

My manual, paper-based processes are time-consuming and error-prone. I’ve heard that automating these processes will minimize mistakes, increase compliance with established workflows and eliminate unnecessary steps.

Reality:  Visibility across the entire business will improve.

With asset tracking, it’s easy to determine cycle times for key processes, pinpoint production slowdowns and identify customers who are costing you money. In short, companies can respond quicker to changing conditions and customer needs.

Consider an industrial gas distributor who regularly delivers cylinders to and receives empties from a customer. An asset tracking report can alert the distributor if the customer suddenly begins returning all empty cylinders. This could be an indication that the customer is preparing to switch suppliers. The distributor can attempt to retain the business by responding quickly and addressing any issues with the customer.

Perception:  I’ll better manage my assets.

I know that automated data collection will help me capture data that will help me utilize my assets more efficiently. I’ll better allocate assets between locations to prevent shortages and ensure orders are filled.

Reality:  Invoicing is better managed.

While asset tracking enables better asset utilization, it’s important to get paid for the orders that are delivered. Deliveries can go unbilled with a paper-based system as documents often get lost or mishandled. Asset tracking software eliminates lost documents since transactions are recorded with a mobile device and enter the business system in real time.

Evidence shows that companies are catching and fixing billing mistakes on as much as 4% of all deliveries. One company reported fixing enough billing errors to pay for their entire asset tracking software solution.

Perception:  I don’t have time to initialize all my assets into the tracking system.

I have thousands of assets. It’s going to take a long time to attach a barcode or RFID tag to each one and initialize them into the tracking system. I’m not sure I can afford the time.

Reality:  Better utilization results in substantial savings.

Many companies have an idea of how many assets they own, but few have an exact count.  It takes only a minute or so to initialize each asset using a mobile device, and once it’s done, the number of under-utilized assets in inventory is often surprising.

Asset tracking software enables companies to easily determine which assets have been at a customer site longer than expected. When a company is short on assets, the tracking software finds the assets that could be returned and reused. One company reported one-time savings of $250,000 because they found so many assets that they didn’t need to purchase new ones for an entire year.

Perception:  I could lose money.

When my customers call about a billing error, they usually complain that I’ve overcharged them. Any improvement in accuracy will favor my customers and I’ll find that my revenues are less than I thought.

Reality:  Revenues increase.

Customers rarely call when you’ve undercharged them. Companies that charge rent on their assets and use an asset tracking software solution increase rental revenue by finding hidden assets sitting at customer sites.

Consider a case where a customer has three of your assets onsite, but due to a past error shows a rental balance of only two. If the customer always evenly exchanges two assets, you will never know that the customer really has three unless you either audit the customer or track your equipment with asset tracking software. Experience shows that companies that implement tracking software can increase rental billings by as much as 8%. 

Perception:  I’ll see the status of my business in real-time.

It’s difficult to trust the data from my manual tracking system. It’s only as up-to-date as when the information is keyed in, and even then, human errors occur frequently. I’m sure an asset tracking software solution will provide more accurate data when I need it.

Reality:  Customer loyalty increases.

Because asset tracking software reduces errors and captures data in real time, companies have confidence in the data and are able to share it with customers in real time. This helps to eliminate balance and billing disputes. Some even give customers user IDs and passwords so they can view their asset information online.

Asset tracking software provides a single view of the truth. Customers appreciate the transparency of information, which enhances trust and accountability and strengthens relationships. Because customers recognize the value, companies can add a tracking fee to customer rental invoices.

Perception:  Employees will resist the change.

Many of my employees are not computer savvy. The thought of learning new technology scares them. They’ll see this new system as extra work. It’s not worth the risk of upsetting the staff. Maybe it’s better to stick to the current paper-based process so we don’t rock the boat.

Reality:  Employees take pride in a culture of accuracy.

Employees learn that an automated system means less manual work because things are done right the first time. They trust that the work they’re doing is accurate. Teamwork thrives as they all understand the importance of their roles.

Warehouse workers and drivers can learn how to use a tracking system in less than 20 minutes, and they actually appreciate the elimination of time-consuming paperwork. One company went a step further and incentivized data accuracy by awarding employees with quarterly bonuses earned by keeping mistakes to a minimum.

What are your perceptions about asset tracking? Did any of the ones above hit home for you? Share your comments below. We’d love to hear from you.

Live to Code, Code to Live

I’ve written previously about our policy of giving our developers self-directed time each sprint to scratch an itch, sharpen the saw, study, etc. I recently took some self-directed time myself to scratch my own itch.

As CTO of TrackAbout, I don’t get to write code like I used to. In the early years of TrackAbout, I would spend 90% of my conscious time coding, from rolling out of bed until the time I passed out around 2AM (minus meals, bio breaks and an occasional trip to the gym). Programming is my first love but other duties now keep me from it. Yet every so often I find an opportunity to flex my atrophying coding muscle.

Delivering Email is Hard

Our web application, like most, sends email. It sends email to employees at TrackAbout, to our users, and to people of our users’ choosing.

Getting email delivered is significantly harder than you might think, largely because you have zero control over the whims of the receiving email server. One ill-configured, over-zealous “network security device” on the other end and your email gets eaten and your IP address lands on some global blacklist, impacting deliverability to all your other customers (I’m looking at you, Barracuda).

About a year and a half ago, we decided to outsource the sending of email to someone who was doing it right, SendGrid. Prior, we’d been sending email through a basic SMTP mailer service. It provided little visibility into drops and bounces and did nothing to help us understand if we were on blacklists. It also wouldn’t DKIM sign our email, which is an important ingredient in ensuring successful delivery (see also: SPF DNS records). We could have built up capabilities around our existing SMTP service or chosen a new email server, but we’re not in the business of writing email tools or managing email servers. SendGrid is.

Even with SendGrid, the mail doesn’t always get through. When it fails, SendGrid gives us some really nice reports to determine the cause of various kinds of failures. Often, a user has fat-fingered an email address, and it’s just not routable. That mail will never get there.

We recently had a situation where an employee of TrackAbout configured a demo instance with a fake but routable email address, which caused us to send gobs of email to an unsuspecting company, to a user/mailbox that doesn’t exist. It’s a great way to get blacklisted for bad behavior. Don’t recommend it.

We’ve also had users set up email alerts in our application that trigger based on some event happening with their tracked assets. When the intended target leaves their company, the email starts to fail. Again, pounding an innocent mail server can get you blacklisted.

Having a member of our Support staff monitor SendGrid reports is one way to stay on top of these kind of email failures. But a push notification system would be much nicer.

Here comes my itch.

Building a Better Mousetrap

We learned that SendGrid, in addition to having a comprehensive REST-based web API, has this wonderful feature called a “web hook”. The gist is that you can make SendGrid call a URL of your choosing when email is processed, dropped, deferred, delivered, bounced, clicked, opened, unsubscribed from or marked as spam.

We use HipChat as our chat room solution at TrackAbout and we love it. We’re in there all day. How nice would it be to have a chat room for being notified of SendGrid mail failure events? Very nice indeed.

So what I wanted was a lightweight service to receive web hook calls from SendGrid and transform the posted data into a HipChat message to the room of my choosing.

There are some cool new companies out there that hook various cloud services together. The two big ones I know about are If This Then That and Zapier.  Neither supported the exact scenario I wanted, and besides, this isn’t a terribly hard problem to solve by rolling your own. And I had this itch.

Enter Node

I have been following the burgeoning Node.js community and I’ve wanted to try writing a simple service using it. I brushed up on my JavaScript skills, plowed through a couple of beginner Node.js books and got to hacking.

The result of eight highly-interrupted hours of effort is now live and working. The project, sendgrid-webhook-server, is available on GitHub and open sourced under the MIT license.

I began writing my service using a model of an HTTP server application as laid out in Manuel Kiessling’s The Node Beginner Book. I ultimately bought the bundle including his book and Hands-On Node.js by Pedro Teixeira. Once I felt I understood the basic HTTP server model and had my solution working, I gutted it and rewrote it using the Express framework. A ton of code fell away.

I began coding using the excellent text editor Sublime Text with the SublimeCodeIntel package to gain Intellisense features. I’m more familiar and facile with Visual Studio and soon migrated to VS2012. VS2012 does well enough with JavaScript Intellisense. I added the JSLint extension and followed some simple tips that enabled launching my Node app with Ctrl-F5.

I used the Chrome Advanced REST client for testing the service.

Huge thanks to the brilliant Nate Kohari for his node-hipchat package which did most of my work for me.

Although we’re using Mercurial (Hg) internally for DVCS, I put the code on GitHub to enable me to deploy the live service easily to Heroku and to facilitate the ultimate open-sourcing of the project. If Heroku ever starts costing real money, I can run Node on any one of our existing TrackAbout servers easily enough. It was fun learning how to quickly deploy code from GitHub to Heroku.

The code isn’t perfect and I make no warranties or representations about it. Unit tests are sorely needed. Pull requests are welcome. See the README for to dos. As I get time, I’ll extend and improve the project further. Our support manager already wants us to funnel the events into our trouble ticketing system so that we can track each issue to resolution.

Until the next itch…

Larry Silverman
Chief Technology Officer
TrackAbout, Inc.

With reimbursements falling, sometimes steeply, home medical equipment (HME) companies are urgently turning their attention to cutting costs. Unlike less palatable choices, such as layoffs or buying lower-quality equipment, implementing the right technology can not only increase HME operating efficiencies, but also substantially improve performance and position companies for growth in an era of accountable care.

Asset tracking software provides this type of opportunity. With equipment as one of their biggest expenses, HME companies must ensure their assets are working as hard as possible and thus delivering an optimal return on investment.

By implementing dedicated asset tracking software, HME companies can establish an easy-to-use, highly efficient, and effective process for managing and maintaining equipment that maximizes the use and the useful life of their critical assets. Electronically tracking, sorting, and aggregating equipment data and producing reports enables HME companies to become more valuable partners to accountable care organizations (ACOs) that rely on electronic systems to knit together providers across the continuum of care.

Read the white paper.

TrackAbout is evaluating cross-platform mobile application development frameworks for the next version of our mobile software. There are more than a dozen competing frameworks, with more appearing every week. It’s daunting to place a bet in a marketplace with this much flux.

Recognizing the confusion in the marketplace and choosing to do something about it are the people behind the PropertyCross web site. You can read about their goals on their web site, but the short version is that they’ve published a spec for a modest mobile application and are soliciting developers to implement the spec using as many frameworks as possible. This is an invaluable resource for those trying make sense out of the options.

Source code for all implementations is available on Github as is the specification for the PropertyCross example application.

In February 2013, I downloaded all of the Android implementations published on the PropertyCross site and sideloaded them onto my Verizon Galaxy Nexus. I then used every feature of each app in an effort to get a feel of the differences between the cross-platform mobile application frameworks.

The PropertyCross implementations reviewed (in no particular order) were:

• Android Native (Java)
• jQuery Mobile (PhoneGap)
• JQTouch (PhoneGap)
• RhoMobile
• Xamarin
• Titanium
• Sencha Touch 2 (PhoneGap)
• Adobe Air

“Methodology” (Caveats)

This was not a rigorously controlled experiment. I didn’t make any special efforts to install each app onto a factory-reset stock device with no other apps or background services running. Unrelated background processes can impact the perceived performance of apps. Whenever I sensed a slowdown, I looked for bad actors in the background. I repeated the same activity to raise my confidence that what I was seeing was due to the app itself.

I did not test on multiple devices or OSes. I don’t have an iOS device to test with, but even if I did, the PropertyCross applications are not code signed. I’d have to go about signing them myself to load them, making such an endeavor considerably more time consuming.

This was a comparative review in which I tested multiple implementations on the same device to get a feel for how they differed. This was sufficient for my needs. Because some of the implementations use webview frameworks, they rely on the built-in WebKit browser on the device. Anyone attempting a similar exercise should be aware of this, and that the older the version of the OS, the older the built-in WebKit engine is going to be and the slower the webview frameworks will perform.

I worry that this blog post will inevitably grow stale or misleading. Issues I report here may be resolved in future PropertyCross releases or by the framework providers. Therefore, please note the date of this blog post and try the latest builds of the apps on the frameworks you care about before arriving at your own conclusions. At the time of writing, the team was not publishing version numbers of the apps, so the publishing date is going to be your best marker.

Each PropertyCross implementation had its shortcomings. In many cases it was difficult to tell which issues were due to developer choices versus framework limitations. I enlisted the help of PropertyCross site founder Colin Eberhardt, Sam Hogarth, and other members of the PropertyCross team to help me better understand my observations and incorporated their feedback. They were forthcoming and helpful.

On “View Bouncing”: In several of the implementations, if you swipe a view up or down, the whole screen bounces. It’s the iOS overscroll effect intended for lists, but it makes no sense in certain contexts like static forms. I made a note of wherever I saw this effect when I thought it didn’t belong.

On “Overscroll Glow”: This is the expected Android overscroll effect. When scrolling to the beginning or end of a list, the top or bottom edge glows.

See examples of both iOS and Android overscroll effects here and here.

I have categorized all issues I noticed thus:

[FRM] – The issue being noted is due to the underlying framework.
[DEV] – The issue being noted is due to a choice by the developer.
[?] – Could not determine.

Native (Java)

Source code: 1,383 KB
APK size: 607 KB

Initial Load Time

• Fast, under 2 seconds.

List Scrolling:

• Very responsive scrolling, no touch delays.
• Implemented the overscroll glow.
• There’s no accidental highlighting of list items touched while scrolling as occurs in several webview frameworks reviewed.

View Bouncing:

• None (I’d only expect this in a webview app)

Button Responsiveness:

• Excellent

View Transition Speed and Quality:

• [DEV] View transitions are very fast, but images on property view should be preloaded before showing the screen.

Of Note:

• Upon clicking Go to start a search, the Go and My Locations are disabled, signaling (1) that a search is underway and (2) that additional taps are not necessary (or possible). This disabling of input buttons was also done when clicking on a recent search in the recent searches list.
• [DEV] Upon the start of the application, the cursor was in the search textbox, and the on-screen keyboard was presented automatically. On one hand, this is nice if my first action is to perform a new search. If I wish to access Recent Searches, then the keyboard is in my way. On my Galaxy Nexus, the onscreen keyboard obscures the Recent Searches block. The search view does not support scrolling to allow me to access Recent Searches without first hiding the keyboard.

Shortcomings:

• [DEV] The Recent Searches are not being remembered from run to run.
• [DEV] Property images are not being pre-loaded or cached. Scrolling down in the list view reveals images being loaded on-demand. Scrolling back up to properties already viewed, I notice images that were shown previously are now lost and must be reloaded. That is wasteful.
• [DEV] Defect: I searched on “London ” with a trailing space. Clicking on “Go” button, nothing happens. Delete the space, the search is conducted successfully. Trimming input is very important because most predictive text keyboards (I use Swiftkey) automatically insert a space after each word.
• [DEV] On the list view, there is no visual feedback when tapping “Tap to load more…” area — can’t tell if it’s working or not, and can’t discern what area is technically tappable.
• [DEV] Clicked My Location — app was unable to determine my location. GPS and wifi are both on. I’m in the United States, and the properties are not. Ideally, the application would report that there are no properties available in my region.

Final Thoughts:

As the Native implementation, this should be the “gold standard” implementation against which the multi-platform development frameworks are compared. All the shortcomings expressed are developer issues to resolve, not framework issues. I’d like to see all the shortcomings resolved and then see if the team can bring the rest of the implementations up to this standard.

jQuery Mobile (PhoneGap)

Source code: 7,724 KB
APK size: 1,523 KB

Initial Load Time:

• [FRM] Slow, 4-5 seconds.

List Scrolling:

• [FRM] List view takes several hundred milliseconds to register a swipe before it starts scrolling. JQTouch Phonegap implementation doesn’t seem to suffer from this.
• [FRM] Swiping the list view up or down causes a highlight on a list item. This is likely a shortcoming of the webview framework being bad at determining a tap/double-tap/swipe.
• [FRM] List does not implement the Android overscroll glow. Instead it bounces like iOS.

View Bouncing:

• [FRM] All views bounce up or down when swiped. Likely an artifact of the webview nature of the framework.

Button Responsiveness:

• [FRM] Poor. There’s a responsiveness delay when hitting any button: back, favorite. Colin pointed out this is most likely due to the way mobile browsers handle tap events, delaying to determine if a tap will become a double-tap. For more info, see https://developers.google.com/mobile/articles/fast_buttons

View Transition Speed and Quality:

• Search to List View: Always going to be slow due to the query. Would need to do profiling to determine how much is due to the framework vs. the query.
• List to Property View: Fast
• Property View back to List View: Slower, probably due to a large list being displayed. Not outrageous.
• Search to Favorites: Fast enough

Shortcomings:

• [FRM] Menu button in the navigation row, even though it does nothing. Apparently this is difficult or impossible to hide in Phonegap.
• [?] I left the app while viewing the Property View, then returned later and was left staring at a blank canvas. I tapped the screen and the Property View appeared instantly.
• [DEV] “Load more” in the list view doesn’t provide feedback when tapped.
• [?] Android “Back” button behavior acts more like a browser than an app. I expect that when on the search screen, back would exit the app, but it keeps going back through screen history.

Final Thoughts:

This implementation isn’t competitive as-is. Probably jQuery Mobile could be made better through tricks, tweaks and different javascript library choices. There are many ways to make an app using PhoneGap or other webview frameworks. A lighter weight library like Zepto.js could be used in place of jQuery, perhaps. Knockout.js was used in both this implementation and JQTouch, but there can be bad choices made using any framework or library which can make an app slow.

JQTouch (PhoneGap)

Source code: 1,526 KB
APK size: 1,507 KB

Initial Load Time:

• Around or under 3 seconds. Quicker than jQuery Mobile. Shows a splash screen. Acceptable speed. Since both this and the jQuery Mobile rely on the WebKit browser engine, I am guessing the speed delta is due to differences in the javascript libraries and UI frameworks being used.

List Scrolling:

• Smooth. Increases my confidence that a webview framework can deliver on performance.
• Android overscroll glow was implemented.

View Bouncing:

• No bouncing of views when swiped. Good.

Button Responsiveness:

• [DEV] Acceptable speed, but somewhat variable amount of visual feedback provided throughout the app. The Back button on the Property View doesn’t provide any tap feedback. In other places, buttons flash green.

View Transition Speed and Quality:

• Search to List View: Always going to be slow due to the query. Would need to do profiling to determine how much is due to the framework vs. the query.
• List to Property View: Fast
• Property View back to List View: Pretty fast.
• Search to Favorites: Fast enough

Shortcomings:

• [FRM] Menu button in the navigation row, even though it does nothing. Apparently this is difficult or impossible to hide in Phonegap.
• [DEV] Styling and colors are pretty bad in this implementation. Black text on dark grey? Skeuomorphic faux-leather background? Colin tells me this may be the default style of JQTouch, and where possible, they wanted to use whatever default styling the framework provided. I’ll call this a DEV shortcoming because it could be modified and therefore shouldn’t count against the framework.
• [FRM] List items flash/highlight when swiped. JQuery Mobile did this too, but it’s much more pronounced and noticeable with JQTouch.

Final Thoughts:

Overall I’d be satisfied with this level of performance, minus the style choices. This implementation shows me that a webview framework can deliver on performance.

RhoMobile

Source code: 2,223 KB
APK size: 3,348 KB

Initial Load Time:

• Around or under 3 seconds.

List Scrolling:

• [FRM] There’s the tell-tale slight delay in registering a swipe to scroll. Seems faster than the jQuery implementation, but still not instantaneous or even close to the JQTouch implementation.
• [FRM] Scrolling is not smooth. Jittery, jumpy.

View Bouncing:

• None.

Button Responsiveness:

• [FRM] Buttons seem responsive when they work. But intermittently, they don’t work.
• [FRM] Odd artifact: When tapping on a list view item, first it changes style slightly (inversion of 3D perspective) indicating the tap, then it highlights in blue, then the view changes. Odd.

View Transition Speed and Quality:

• [?] Views have a slide transition, making them seem slower than other implementations.
• [FRM] Transition from list to property view has a slight delay following a tap. Likewise going back from property view to list.

Shortcomings:

• [?] This app runs “full screen” and makes it impossible to access the Android notifications area at the top of the screen. I hope this is configurable by the developer.
• [DEV] In places, the app lacks progress indicators (spinners) letting you know it’s doing something.
• [?] On search view, typed in London, hit Go, saw a brief “Searching” message then nothing. Tried Liverpool, then got some results.
• [?] Several times, the search the query has not worked. Almost like the web request timeout is too short by default and the developer isn’t providing feedback on failures.
• [?] Intermittent loss of button clicks. Sometimes button presses just seem to get swallowed, lost. Looking at a single property, hit the Back button, it flashed registering the tap, then nothing happened. Clicked the Fave button, it didn’t change status. Went all the way back, looked at my faves and the property was there. Clicked it to go to property view and now the Fave button reflects that it’s a fave.
• [DEV] When I went back from a property view to the list view, the properties I’d loaded using a Load More action were gone and I was back to the original list, having to do Load More again. The state of the list view is not being maintained.
• [DEV] Menu button actually does something in this implementation. It brings up a menu containing: Home, Refresh, Sync, Options, Log and Close. Home and Refresh work. Sync does nothing. Options throws a 404 Not Found and hitting Back exits the app. Log shows a console log. Close does what you’d think. My money says this is a default Rho menu structure which all Rho apps would have if not hidden or modified.

Final Thoughts:

This is the worst implementation of the bunch. I suspect it’s largely the developer’s fault. If I were Motorola Solutions, I’d be trying to get this implementation improved

Side Note: Spoke to three reps from Motorola Solutions on Feb 21, 2013, suggested they get someone to contribute.

Side Note 2: Colin tells me the developers who built this version would be submitting updates. Not in time for publication, however.

Xamarin

Source code: 12,456 KB
APK size: 6,756 KB

Initial Load Time:

• Around 2 seconds.

List Scrolling:

• Smooth.
• Implemented the Android overscroll glow.
• [DEV] Loading of property images in the list view is not optimal. Images are being loaded on-demand as the user scrolls instead of prefetched. There appears to be no caching of images. If you scroll down then back up, images are being reloaded over and over again. Sam told me there are options for improving this implementation, so it’s not a framework limitation.
• List memory was maintained when returning from a single property view.

View Bouncing:

• None

Button Responsiveness:

• Excellent overall
• [DEV] Good touch feedback on the Go search button. Switched to a “loading” spinner which let me know something was happening, but then dropped back to the Search view for a moment before loading the property lists. Sam later told me he’d remove the search spinner in favor of an implementation that more closely follows that of other frameworks.
• Excellent touch responsiveness on the Fave button. Good implementation with the star metaphor.

View Transition Speed and Quality:

• Nice fade effect when switching between screens. Fast and not annoying.
• [DEV] Failure to prefetch and cache the property images is hurting the property view.

Shortcomings:

• [DEV] The app forgot my recent searches between launches. This was a bug and will be fixed in a new release.

Final Thoughts:

App is responsive. Even while simultaneously loading list view images, clicking on a property immediately changes to the property view. Nice.

Overall, excellent implementation and speeds are comparable to Native.

Titanium

Source code: 315 KB
APK size: 7,552 KB

Initial Load Time:

• Around 3 seconds.

List Scrolling:

• [FRM] Scrolling is jittery.
• Android overscroll glow was implemented.
• Property images appear to be getting cached and reused for the property view, which is good.

View Bouncing:

• None

Button Responsiveness:

• Excellent. In some cases, from the list view, the property view is shown even before the list item tap highlight can be rendered.

View Transition Speed and Quality:

• Switching between list view and property view is fast.
• View to view navigation is smooth and quick everywhere.

Shortcomings:

• [?] App force-quit the first time I launched it. Launched successfully the second time. Can’t say it’s the framework’s fault, but it’s the only time this happened in all my testing.
• [DEV] I typed “London ” with a trailing space by accident. It wasn’t recognized. Sloppy programming on the part of the developer who didn’t bother to trim the input, and on the web service provider who also didn’t bother to trim the input. UI showed a lat/long in the text box after the failed request.
• [DEV] Favorites feature is hidden behind the Android Menu button, which is a different implementation than all the others.

Final Thoughts:

Overall, snappy app. Competitive.

Sencha Touch 2 (PhoneGap)

Source code: 18,259 KB (most of this is an sdk folder)
APK size: 645 KB

Initial Load Time:

• 4-5 seconds. A bit slow.

List Scrolling:

• [FRM] Scrolling is not smooth, jumpy.
• [DEV] Developer implemented pull-to-load more in the property list view — the only implementation to do that. Colin tells me the developers did it because it was easy with Sencha. There’s debate on the PropertyCross team as to whether it should be left as-is, or whether the implementation of “Load more” for the list view should be standardized.

View Bouncing:

• [FRM] Every view bounces when swiped, including the list view.

Button Responsiveness:

• [FRM] Bad touch feedback. Slow to register touches. Typical of webview implementations.

View Transition Speed and Quality:

• [FRM] Really slow to go back from list to search view. So slow I’m not sure whether I hit the button or not.
• [FRM] Sliding view transition makes view changes seem slower than other implementations. This is the framework default.

Shortcomings:

• [FRM] Menu button in the navigation row, even though it does nothing. Apparently this is difficult or impossible to hide in Phonegap.
• [FRM] Seems that some button presses are registered but just lost. I hit the Back button, I’m sure I did, but nothing happened. Likewise with Fave. Next time, it worked.
• [FRM] By default, Sencha seeks to provide the look and feel of an iOS native app. This is apparent in the shape of the Back button and in the transparent progress spinner overlay which looks exactly like many I’ve seen on iOS. This will undoubtedly look foreign to users on other platforms.

Final Thoughts:

This implementation is roughly on par with the jQuery Mobile implementation, which is to say it’s not particularly impressive.

Adobe Air

Source on disk: 547 KB
APK size: 9,584 KB

Initial Load Time:

• Slow, around 7-8 seconds. 5 seconds just to show the splash screen. Likely due to the overhead of starting the Air runtime.

List Scrolling:

• Scrolling is a little jittery.
• Android overscroll glow was not implemented.

View Bouncing:

• [FRM] The contents of the Recent Searches list box bounces when swiped. There’s no utility in this.
• [FRM] The list view bounces when swiped at the top or bottom.

Button Responsiveness:

• Snappy. Excellent touch feedback.

View Transition Speed and Quality:

• Fairly quick from list view to property view.
• [?] Slow coming back from property view to list view. However, the quantity of loaded properties and their images were remembered and maintained.
• [?] Slow navigating back from list view to search view.

Shortcomings:

• [DEV] Clicking “My location” on search view did nothing.
• [DEV] Clicking “Go” with an empty search box resulted in an error: “No converter registered for converting class Error to class mx.rpc::Fault”. This also rendered the Recent Searches inaccessible until a successful search is conducted, at which point it re-appears.

Final Thoughts:

• Overall, a respectable implementation, although the APK size is is ten times that of the smallest implementations. Colin tells me the size of the APK is mainly due to the one-time hit of the AIR runtime, but the use of the Flex framework (and to a lesser extent the Parsley framework) also contribute one-time hits to the APK size.
• Startup time is the worst of the bunch.
• Noticeable delays coming “back” from the various views.

Conclusions

I wasn’t planning on publishing the results of this exercise, but I was encouraged to by Colin Eberhardt. He felt it made “interesting reading” and might benefit others. Colin and his team have been very receptive to my feedback and they are actively working on improving and normalizing all of the implementations.

I’d like to see the shortcomings resolved in the Native Android implementation so that it can truly be the “gold standard” by which the other implementations are judged. The rest of the implementations should be brought as close to the Native implementation as possible. This would give the community the most insight into what level of performance and parity is possible with each framework.

The PropertyCross specification could be more prescriptive. There are several differences in how features were implemented. For example:

• The Titanium implementation relies on using the Android Menu button to add Favorites and view them later, where every other implementation uses dedicated on-screen buttons.
• The “load more properties” implementation at the bottom of the properties list view is implemented slightly differently by one app, supporting a pull-to-load-more paradigm.
• The use of button labels versus icons for the favorites feature varied.
• Things like input trimming, validation and how to best handle error conditions should be explicitly defined. Without consistency in error handling, it’s difficult to determine whether the framework flaked out or the developer did.

There are tricks upon tricks developers can employ to make non-native frameworks perform closer to native levels. For example, webview frameworks like PhoneGap and RhoMobile suffer from a 300 ms delay whenever the user taps the screen. This delay exists to help a web browser determine the user’s intent — is the user scrolling? pinching? double-tapping? This issue doesn’t exist in native frameworks and as a result, native apps feel more responsive. There’s a popular javascript library which can nearly eliminate this 300ms delay called FastClick. Should all PropertyCross HTML-based frameworks implement FastClick or something similar? I leave it to Colin and his team to decide that based on their goals for PropertyCross.

It would be valuable to the developer community to understand how much extra effort, study and experimentation it takes to get a non-native app to approach native levels of performance. I recognize that new tricks are being explored and exploited every day to improve the end user experience for non-native frameworks, so this is a bit of a tall order. Understanding the ins and outs of any particular framework in order to maximize performance is a full time job. Knowing that coding tricks are needed to make a framework truly perform is valuable.

I would have liked to read about each developer’s experience working with each framework. What were the challenges? How long did it take to figure it out? Did you take advantage of the developer community for that particular framework, and how helpful were they? Obviously this would be subjective and based on each developers’ level of experience. Nonetheless, I’d find it interesting reading.

There are wide variations in the size of each APK (the Android application package file, or basically, the installer). For example, there is a 10x difference in size between the smallest packages (Native and Sencha) and the largest (Titanium and Air). Colin explained that some frameworks require the inclusion of a run-time or virtual machine engine. Users routinely install games on their smartphones that consume tens of megabytes. Regardless, when making an enterprise application, my preference (as I’m sure is everyone’s) is to keep the package size to a minimum so that future upgrades will not consume significant bandwidth and waste users’ time.

In summary, I commend Colin, Sam and the rest for undertaking PropertyCross. It’s a fantastic idea and a valuable resource for everyone out there trying to make sense of the dozens of choices in mobile application frameworks out there. I hope my work has contributed to their goals in a useful way.

A modern asset management solution can give you better control over your assets and greater visibility into your operations. Experience shows that through improved management, companies purchase fewer new assets, recover lost rent, fix billing mistakes, reduce theft, avoid customer disputes, deploy assets more effectively, improve safety, win new business and retain existing customers.

Simply implementing a tracking system doesn’t guarantee success. Following these best practices can help maximize the value of your new asset management solution.  

Best Practice #1:  Define which asset attributes are vital to your business.

Take time to review which asset attributes are key to providing the information you need. Collecting the right data from the start will save time later, while collecting every possible attribute “just in case” will slow you down and drown you in a sea of statistics that don’t provide much insight. Focus only on the information that has the most impact on your business.

Best Practice #2:  Use a unique tracking number, not the asset’s serial number.

It’s possible that an asset’s serial number will be identical to that of another asset. If the serial number is used as the tracking number, the duplicate numbers will cause confusion because there is no way to tell the two assets apart. This can compromise data integrity and lead to inaccurate customer balances and inventory, reduce your rental income and impact customer satisfaction. Using a unique tracking number different from the serial number eliminates these problems. In the rare event that a tracking number is lost, the asset still can be looked up using its serial number and re-labeled properly to retain the asset’s history.

Best Practice #3:  Train staff to initialize the assets properly.

Adding assets to the tracking system can be tedious work, but it’s important to pay attention to the details. Mistakes here could pollute your data and lead to inaccuracies in customer balances, inventory, billing and safety and compliance. Whether your employees perform this task or you hire temporary workers, be sure to train and monitor the staff appropriately. It’s a good idea to spot check assets to catch errors before they take a lot of time to fix.

Best Practice #4:  Make the actions on the mobile device as simple as possible.

For the tracking system to be effective, workflows must be simple and easy for workers to follow. Otherwise, you might not record the data you need to support your operations or meet reporting and auditing requirements. Customize the handheld computer application to support your processes. Automated task sequencing eliminates unnecessary steps, increases worker compliance with defined operating procedures and standardizes workflows yielding to improved process control.

Best Practice #5:  It’s OK to start small.

Don’t think that you have to deploy the tracking system to all your operations at once. You might want to start by tracking just one or two types of assets. Or you might want to track assets delivered to certain customers who require tracking. More and more, companies issue requests for proposals that include an asset tracking requirement. You could install a tracking system solely to win that business and then roll out the system to your other customers at your own pace.

Jessica Wolbert

In this new role, Wolbert will consult with TrackAbout clients to analyze business processes and identify technical requirements to ensure full utilization of the TrackAbout solution.  She also will work closely with TrackAbout’s product management team to provide direction for the company’s Android and iOS applications as well as long term product development.  

Wolbert came to TrackAbout in 2011 as Support Specialist, providing clients with day to day front line assistance and professional services including implementation for new clients and development of custom reports.

“Jessica has a sincere interest in the welfare of our clients,” said Tim Fusco, co-founder and CEO of TrackAbout.  “Her unfailing drive, attention to detail and problem-solving abilities are sure to have a positive impact on their success.”

Prior to joining TrackAbout, Wolbert dedicated seven years to the U.S. Department of Defense, mostly at MacDill Air Force Base in Tampa, FL.  Most recently, she worked as an Intelligence Analyst studying counterterrorism and the sociocultural dynamics of the indigenous people of Afghanistan.  Wolbert served two years active duty for the U.S. Army, earning the rank of Specialist.  She holds a B.A. degree in International Politics from Penn State University.

About TrackAbout

TrackAbout^® is a scalable software-as-a-service (SaaS) solution to track, manage, maintain and optionally rent portable physical assets.  Items are tagged using barcodes or RFID tags.  Data is collected using rugged handheld scanners, smartphones, tablets or integration from other systems.  Dynamic fields and forms may be easily added to support a company’s unique workflows.  TrackAbout integrates all of this information with existing enterprise systems.  Founded in 2000, TrackAbout has evolved through an active relationship with our customer base which includes world-class organizations in eight countries.  For additional information, visit www.trackabout.com.

Contact

Christine Span, Marketing Specialist
TrackAbout
412.269.1872 x118

# # #

This comes shortly after Motorola Solutions’ acquisition of rugged device manufacturer Psion,  announced in June 2012 and completed in October 2012.

The year 2012 has been one of consolidation, but not innovation. We’ve been anxiously awaiting a sign that the rugged device market would adopt more modern operating system platforms than the Windows Embedded platform we’ve been stuck on for so many years.  The two most obvious directions to head for these manufacturers would be Android and Windows 8 Embedded.

In February 2012, Intermec’s longtime CTO Arvin Danielson had some harsh words for Microsoft and their handling of the forthcoming release of Windows 8. Read the article for the full quotation, but the sentiment was that Arvin and Intermec had been stymied waiting for Microsoft to clue them in as to when Windows 8 would be available to OEMs. As a result, to this day there is no news that Windows 8 RT (the version of Windows 8 that runs on ARM CPUs) or Windows 8 Embedded is coming to rugged devices any time soon. The earliest we’ve been told to expect Windows 8 Embedded from Motorola is 2014.

Will the market wait until 2014 for Windows 8 Embedded, or will Android become the dominant platform for the rugged space in 2013?

Several Android rugged devices with scanning capabilities now exist:

• Honeywell Dolphin 7800
• Motorola Solutions MC40 and MC45, which can’t be found anywhere on their site, but Google returned this pdf containing no specs
• SDG Systems / Juniper RAMPAGE 6
• Pidion by Bluebird will have 4 Android devices soon.
• BP70 10.1" tablet IP65
• BP50 7" tablet IP65
• BIP-6000 handheld
• BM-70 smartphone

There are other manufacturers in the game as well.  I found a thorough rugged Android device list. Most do not have scanning capability but could work with an external Bluetooth scanner.

Motorola and Honeywell are now the two remaining big players. They have done some experimentation and hedging with Android devices while waiting for Microsoft to get its story straight for Windows 8 Embedded. They are in the best position to know whether the market is really hungry for alternative OS devices, and we’ll be watching their next moves closely.

Please see my post On Hiring Developers for background regarding how our hiring process has evolved and some of the tools we use.

The Statistics

Codility

I’m really glad we introduced Codility. It added useful information to the process. Can someone follow directions? Solve a problem elegantly? Is their code readable? Did they name their variables and functions well? Did they optimize for performance? Did they anticipate every edge case?

Some candidates felt the test problems were a bit too “computer science-y”, like puzzles. They felt they weren’t like typical problems you’d have to solve in business application programming.

Other candidates said they enjoy challenges like Codility. They like solving puzzles. Give me a developer who enjoys challenges and solving puzzles for fun any day.

Some candidates realized they weren’t up to the task, and bowed out gracefully. One wrote, “I started through the coding tests, and realized that I really need to improve my chops if I want to work with this caliber of programming … humbling as it is, it’s honest. Thank you so very much for the opportunity and taking the time to talk to me the other day. I really appreciate it.”

Quite a few candidates emailed me after Codility to tell me it was fun and that they were impressed and happy that we ask candidates to actually code before hiring. Many employers hire developers without checking that they can code, crazy as that sounds.

Some candidates realized after the fact that they had screwed up the test. They continued to think about the problems after taking the test, or they did some research and realized their mistake. Several candidates sent me modified solutions via email to correct what they got wrong on the test. It carried weight with me that they cared enough to do so.

It’s unfortunate, but many of the tests in Codility are Google-able. It’s difficult to know whether a candidate cheated or not. I’m not sure if it matters. When faced with a challenging problem, a person should use all the (legal) resources available to prevail.

However, in life and business, the right answer is not always Google-able. The best coding test would be one that is unique, which we define ourselves, and which tests the kind of coding that we require on the job. There’s a company in beta called HackerHires which I’ve been told is working on this, but they haven’t launched yet. Nevertheless, Codility does the job weeding out those people who really can’t program and who aren’t resourceful enough to find an answer in time.

I’m not sure why 14 candidates fell off the face of the Earth after being sent to Codility. It may have been lack of human touch, that I didn’t attempt to speak to them beforehand. It may have been something in the tone of my email, which I edited iteratively until I came up with something I was happy with.

At some point after introducing Codility, I began taking the approach that if I had time in my schedule and the candidate looked especially promising, I’d reach out for a brief phone screen before throwing them to Codility. This wasn’t always possible.

The Resumator

I exercised much more of the functionality of The Resumator this hiring round.

I created several Custom Message Templates once I found myself writing the same messages again and again.

I created some other canned emails which I keep in Evernote for communications outside The Resumator.

I also created a custom workflow in The Resumator so I could more accurately track the status of each candidate.

That last status, “Filled Job Before Contact” is for tagging those candidates who came into the pipeline late. I’ll review their submissions and if they pass muster, reach out to them first when we have open positions in the future.

I created browser bookmarks for filtered views in The Resumator based on the above statuses. This allowed me to more quickly check the candidates in each status.

I realized pretty late in the game that I should have created a custom URL for the job posting so The Resumator could automatically track referral sources. I couldn’t always tell when candidates came in from our Careers 2.0 job posting versus cross-posted sources if the candidate didn’t fill in the referral field. The Resumator has a link builder for just this purpose. Next time.

Careers 2.0

I’ve been using Careers 2.0 as my only paid job board when hiring developers. I’ve written about why in a previous blog post.

The Resumator can cross post for free to job boards like FlexJobs, Indeed and SimplyHired. This round of hiring further cemented my impression that candidates who come to us by way of those sources are nowhere near as good as those coming from Careers 2.0. There is the occasional gem, but they’re few and far between.

Paying extra for “Featured” treatment for our Careers 2.0 job posting seemed to boost our traffic immediately following. But it’s difficult to draw a direct correlation over such a short time period. There’s no argument it makes the job listing stand out a bit among the others.

I spoke to the Careers people about other ways they could help us get in front of more developers. They have an advertising model where your job posting appears in the side bar of Stack Overflow questions. However, those ads are targeted based on the user’s location. Our developers are telecommuters and so our job posting doesn’t have a single set location. Careers told me that using the ad model wouldn’t make sense. Kudos to them for not trying to sell it to me anyway. I wasn’t particularly attracted to an ad-based model anyway.

Scheduling Meetings

I miss tungle.me, the old scheduling service we used to use before RIM bought it and tanked it. It worked.

I tried the free edition of Doodle, but many of the appointments that got scheduled using Doodle didn’t contain any identifying information about the candidate. No email, name, phone number, nothing. Usually it’d just be a calendar entry with a generic title and no other info. Perhaps this was due to the free license level, but it didn’t entice me to pay for better.

ScheduleOnce seems to work well enough.

I’ve heard from the developers who have to coordinate three-person technical interviews that they’ve resigned themselves to using email because neither Doodle nor ScheduleOnce is sufficient for coordinating three peoples’ schedules.

Blogging + Hacker News

The On Hiring Developers blog post which I cross posted to Hacker News seemed to change the behavior of the campaign. This is anecdotal, but I feel like the caliber of the candidates who applied improved after I started blogging about our process. Many candidates mentioned the posts, citing them as positively influencing in their desire to work here.

Several candidates stated they’ve read some of our own developers’ independent blogs, or that they follow them on Twitter. Some candidates cited blog posts by developers who they know used to work here. The fact that our developers (past and present) have public personas outside of work seems to work for us. Good devs want to work with good devs, and getting a glimpse into the kind of talent we have helps.

I recall a pretty funny moment in one interview. A candidate was telling me about something he’d read on the blog of this awesome developer he’s been following for ages, and it sounded familiar. I said, “Oh, I know that post. That’s John Sonmez. He works here.” Mind: blown.

Our Corporate Site

I can’t wait for our new site design to go live sometime in the next couple of months. I feel compelled in interviews to work in an apologetic joke about how our corporate site is so very 2005, and the candidates laugh and say, “Yeah…” They know it, we know it, and I am thrilled we’re updating it.

Checking References

I always check a candidate’s references. In the past I’ve been overly deferential in scheduling times to check references. I’d send out emails with a link to a scheduling tool, do the whole, “When’s good for you?” thing. It takes forever, and for what? A 10 minute call?

This time around, I went old school. I just called the candidate’s references trying to catch them when they had 10 minutes to spare. It worked, and I got through the reference checks much more quickly. I guess this is what they did before email.

Trello

I knew I wanted to collect metrics about this round of hiring. I used a Trello board to manage the Codility candidate flow. This allowed me to easily track how many people I sent there, how many went dark, how many passed and how many failed.

We used another Trello board for managing the technical interview process, and it worked really well. It provided transparency and allowed for developers to sign up to interview candidates effectively. I could drag and drop candidate resumes and blog links right into the Trello card.

There were downsides of integrating Trello into the process. In the final analysis, I wanted to gather statistics by counting the various cards in their lists and come up with a spreadsheet that would tell the story of how many candidates got first interviews, second interviews, etc. Trello doesn’t do counting or filtering very well.  Also, in some cases, developers took their names off cards because they didn’t want the notifications, and that meant I had to go through card by card to get the right counts.

Keeping candidate statuses in sync between Trello and The Resumator was also a bit of a chore. I looked for integration possibilities, but it wasn’t feasible.

On Face-to-Face Meetings

Our developers work from home, 100% virtual. That means we don’t meet in person at any point in the interview process. I won’t usually even see the candidates’ faces until after they show up to work.

Part of me feels it’s kind of strange hiring people sight unseen.

On the flip side, these developers are all going to be working remotely, and rarely showing their faces while doing so. What’s important is that they can communicate well and demonstrate their ability to work remotely with members of our team. That is going to be their day-to-day existence for as long as they work here.

I didn’t feel strongly enough it to insist that we conduct a video conference at some point in the interview process. This may be a reflection of my own introverted nature, but for now I’m going to allow myself to focus on the results of the hiring process, that we have an awesome team, and not dwell too much on this one point.

Larry Silverman
Chief Technology Officer
TrackAbout, Inc.