This post is about the rapidly changing mobile industry and how it is impacting staffing and the Tempworks product line, but before I get into that let me get a little braggadocio out about our current offering.
Tempworks Mobile is a game-changer for the staffing industry. It unglues you from your desktop and makes it super-convenient to get 90% of the information you need while on the road with your iPad, Android or iPhone.
Now that I’ve cracked a rib patting myself on the back, let me say that all is not well with Tempworks Mobile
If you’re a sales person, it helps you win deals. If you’re a recruiter, it makes it convenient to stay tight with candidates. If you’re a business owner, it keeps your finger on the pulse of your business whether you’re on the golf course or at a board meeting.
I personally use Tempworks Mobile all the time and am especially keen of the website analytics feature that lets me monitor how the world wide web interacts with our brand via our web properties.
Now that I’ve cracked a rib patting myself on the back, let me say that all is not well with Tempworks Mobile. The reality is that the mobile industry is changing so fast that our current product which we originally did in 2003 and redeveloped from scratch last year is already outdated in that it fails to take advantage of HTML5 and what some refer to as unobtrusive JavaScript.
Meanwhile in just this last year, the use of HTML5 compatible mobile browsers (read: iPhone and Android) has skyrocketed. This makes things very interesting for users and developers alike.
For users, it’s now possible for mobile apps to respond lightning fast. Users get updates instantaneously without waiting for round-trips from the server. Since so much less data gets passed back and forth, you can save money on your cell phone plan if metered.
For developers, we have the chance to build our mobile apps with the same solid frameworks that we’ve been building hard-core enterprise apps like payroll. Designers can create and change user interfaces without interfering with the work of developers.
Users get updates instantaneously without waiting for round-trips from server
For us at Tempworks that means rebuilding mobile from the ground up with a new foundation that improves usability and separates code from design.
Let me illustrate the difference of the old vs. new using a popular feature in Tempworks Mobile that lets sales managers see the most recent messages posted by account reps.
In our 2010 version, the mobile browser makes a request to the server to return the 10 most recent sales messages. The server responds by sending down all the information – JavaScript code, html, data – basically all mixed together. Often code that was already downloaded gets downloaded again, making the response slower than it needs to be.
In the new version, things happen much more efficiently. By caching the html and JavaScript on the phone, only data gets sent across the wire. And that data is sent asynchronously in a data format called JSON (technically, JSONP). By downloading less data, the transfer gets done more quickly and saves on your phones power consumption as well.
Yes technically certain devices like the iPhone flush their cache when rebooted, but that’s a minor point when you consider that the newer phones which are actually powerful computers let you do cool things with that JSON data. For example, they can take each chunk of JSON data and use it to inject the necessary JavaScript and html into the DOM output to create supremely attractive and helpful displays.
As a byproduct of using these latest platform improvements, we’re also able to create a user interface that works equally well across all mobile devices including tablets without having to write separate views for each of them. That’s a huge time saver that lets us focus more on delivering the absolute best app.
Previously we could only protect the data using HTTPS by invoking it from the address bar
For the security minded, we can encrypt the JSON data with the HTTPS protocol, thus protecting it from being understood by anyone monitoring your line (no sense in letting a competitor spy on you). Previously we could only protect the data using HTTPS by invoking it from the address bar, or, alternatively, we were hampered by limitations in some browsers (namely certain versions of IE) that made it impossible to mix HTTP and HTTPS. Bottom line: by using HTTPS only when required, we make the website quicker and don’t lose on security. And it’s ALL FREE TODAY!
Users will note the improvement in validation for example when they add a new cell number to a contact record. Instead of dealing with inconsistent client-side code or waiting for the server to send back an error message, the user gets uniform, convenient indications along the way, much like you get using a well-written desktop user interface. For developers, writing client-side validation code was messy and led to what we call ‘spaghetti code’. Now it can be done via simple annotations.
bottom line: thanks to HTML5 our mobile customers are about to enjoy huge performance in usability
The bottom line in all this for our customers is that their mobile apps are about to enjoy huge performance in usability and our developers are going to be able to spend more of their time creating the new features you need instead of hassling with the draconian and immature web standards that were previously in place.




Why are you using JSONP and not JSON? JSONP is typically used for a cross domain scenario.
hey Andy…two thoughts on the jsonp and yes it’s for cross-domain.
one case is where it is actually cross domain, say getting the data from api.myserver.com
the other is if down the road we encountered a browser objecting to http and https being combined in this way, considering it cross-domain
Ask five economists and you will get five different answers – six if someone went along to Harvard.
Success or failure operational is caused more by the mental attitude even than by mental capacities.