Archives

November, 2012

Why Did Google Buy BufferBox? Because The Entire Mail And Package Delivery System Is Broken

4372183674_874289f939_z

Today, Google bought an Ontario-based company called BufferBox. In a way, it kind of came out of left field. Since it’s a Google Ventures company, one can guess that those on Google’s campus were very familiar with the service, which provides an easy alternative to waiting around for packages at your house.

Not only is package delivery a bummer, because things get lost, hitting up your mailbox when you get home isn’t that much fun either. The worst is when you don’t even have a mailbox and you come home to twenty pieces of junkmail slipped under your door. The mail delivery system is broken and old. It’s ripe for…disruption. How broken? The US Post Office lost $15.9B in 2012.

So at first blush, one could say that Google wants to compete with the likes of shipping magicians like Amazon and UPS, but I think that it goes a bit deeper than that. This doesn’t feel like an “e-commerce” play. Google has the knack of honing in on verticals that are a pain for people in the real physical world. Don’t want to drive your car? Maybe one day it’ll drive itself thanks to Google.

Back to BufferBox, the YCombinator company that currently only operates in Canada. It’s an area that is great to test things out in, away from our needy grubby hands in the United States. Google also rolled out its Fiber product in Kansas City, away from us geeks in San Francisco and New York, so that it could perfect its product before unleashing it on the universe.

This is how BufferBox describes itself on its website:

Today’s parcel delivery system is outdated – missing package deliveries is crazy! You’re not home during the day, so stop shipping parcels there! Ship them to your closest BufferBox instead! We’re a network of parcel pick-up stations that are conveniently located, allowing you to grab parcels securely and on your schedule!

Google challenging the Post Office? Altruistic? Kind of. Business savvy? You betcha. Sounds like it’s right up Google’s alley. What does a company have to have to take over the mail routing system? Brilliant mapping technology.

One day, I could see a world where we don’t have mailmen and women coming to our houses every single day to deliver junkmail. These things can be dropped off in a box in a place that’s more convenient for you, say by your office. That way, you can pick it up when you want to, and come home to a nice relaxing home, and clean doorstep. Let’s not forget to mention the anxiety of worrying about a package being stolen by a neighbor. It happens.

So in a nutshell, one must only wonder why Google picked up BufferBox, because Google never really goes into great detail on why it acquires companies. It doesn’t really have to, for competitive reasons. Just know that everything at Google tends to happen as part of a master plan, and this particular acquisition could lead to a massive master plan.

Remember when Google bought GrandCentral? It turned into Google Voice. The service that could one day compete with the likes of AT&T and Verizon. That acquisition was led by Google’s Wesley Chan, now a partner at Google Ventures. He thinks big, so does Google. Just when you thought the GrandCentral acquisition was going nowhere, Google Voice was launched.

Searching all of the world’s information, free or cheaper Internet for all, free phone numbers and voicemail, devices like laptops that are priced fairly for Education and lower-income families running powerhouse open-source software, services that make everything we do online feel more intimate and social, both at work and home, reinventing television…there is an obvious pattern. Google wants to help reshape, and evolve, the world.

You’ve got Google Mail.



Enterprise Apps Are Moving To Single-Page Design

zendesk-logo

Editor’s note: Alexander Aghassipour is chief product officer and co-founder of Zendesk. Shajith Chacko is lead software engineer at Zendesk. Both contributed to the development of the new Zendesk product. 

The Web is a far different place than it was when Zendesk launched six years ago. As more and more people use consumer apps like Twitter and Facebook, enterprise applications need to build an interactive experience that doesn’t look old or slow when compared to the rest of the real-time Web.

As a cloud help-desk software provider, we recognized that our customers’ needs were also changing. A few years ago, web support meant email. Today there’s chat and click-to-talk voice support, and most customers demand instant answers and help. These real-time channels benefit from a more modern application approach than our original HTML application afforded. From the support side, customer support agents might be chatting with one customer while simultaneously updating another customer’s files. Meanwhile, large support teams need to collaborate in real time. The platform can’t slow the pace of work.

As our customer expectations have grown over the years, so has the application. Any evolving application reaches the point where another incremental change just won’t do. Rip and replace was the only option in order to balance the complexity of features with the simplicity of design. Moving to a single-page, JavaScript-based app enabled us to create an interactive, real- time experience that’s streamlined and agile.

Selecting A JavaScript Framework

From a technical perspective, a single-page Web application is delivered as one page to the browser and typically does not require the page to be reloaded as the user navigates to different parts of the application. This results in faster navigation, more efficient network transfers, and better overall performance for the end user.

When it comes to designing single-page applications, there are several JavaScript frameworks available to facilitate the task of writing complex client-side applications. While the choice of frameworks is a rather subjective decision (and each developer will have his or her own opinion), we ultimately went with the Ember JavaScript Framework due to several key reasons:

  • Ember.js is constructed with large applications in mind and fits a larger team and project like Zendesk.
  • Ember.js has more conventions and structure, and these established conventions make it easier to bring new developers on board.
  • Ember.js is primarily based on dynamic bindings that automatically update the UI when data changes; this allows us to easily describe UI that knows when to update.
  • Ember has a vibrant, growing community of very clever people.

Other Technical Considerations

In addition to selecting a JavaScript framework, there are a few other things to keep in mind if you’re considering a similar move to a single-page app.

  • Before we could begin writing in JavaScript, we needed to significantly build out the API to cover everything. Modern one-page apps have a really effective API with the JavaScript client written on top. This was a large task, but the final API can now be used by the whole Zendesk community.
  • A JavaScript application relies on browser features, such as advanced CSS. Therefore, supporting advanced features requires a fairly modern browser. Early on, we decided not to support IE8 and below in order to keep our development costs down. It’s important to define the supported (and not supported) browsers from the start.
  • While JavaScript tools are maturing by leaps and bounds, they aren’t quite on par with what developers may be accustomed to using with HTML. For example, we didn’t find an out-of-the-box testing automation tool to use, so developers needed to rely on manual testing or writing their own test scripts for testing in the browser.

Transitioning Developers From HTML To JavaScript

Before we began the shift to a single-page application, only about 10 percent of our engineering resources went toward JavaScript coding. That was about to change dramatically. We ended up hiring just two JavaScript-only programmers, and for the rest we relied on ramping up the JavaScript skills in our existing engineering staff.

While learning any new skill takes time, we got buy-in from the engineers early on. Convincing our engineering teams to take on this challenge was relatively easy. This transition gives everyone the enviable opportunity to work with modern methodologies and tools. However, there still is a learning curve that must be factored into the project schedule.

Preparing For The Adjustment Period

No matter how fantastic the next-generation application may be, the simple fact is that existing end users have been happily accustomed to doing things a certain way. Getting used to changes to the status quo takes time.

To help ease the transition, we rolled out the new version of Zendesk for new accounts and trials. Existing customers are free to stay with the original Zendesk version for the time being. In addition, we started with a soft launch to a small subset of customers. This was followed by a four-month beta period, which allowed us to see how customers responded to the new design and workflow.

Ripping down an application to rebuild is a risky proposition. However, it’s sometimes the only way to move forward. The journey requires a commitment from all involved – including end users and developers. A major project of this scope won’t happen overnight, but the agility, performance, and real-time nature of the results are well worth the effort.



Enterprise Apps Are Moving To Single-Page Design

zendesk-logo

Editor’s note: Alexander Aghassipour is chief product officer and co-founder of Zendesk. Shajith Chacko is lead software engineer at Zendesk. Both contributed to the development of the new Zendesk product. 

The Web is a far different place than it was when Zendesk launched six years ago. As more and more people use consumer apps like Twitter and Facebook, enterprise applications need to build an interactive experience that doesn’t look old or slow when compared to the rest of the real-time Web.

As a cloud help-desk software provider, we recognized that our customers’ needs were also changing. A few years ago, web support meant email. Today there’s chat and click-to-talk voice support, and most customers demand instant answers and help. These real-time channels benefit from a more modern application approach than our original HTML application afforded. Fron the support side, customer support agents might be chatting with one customer while simultaneously updating another customer’s files. Meanwhile, large support teams need to collaborate in real time. The platform can’t slow the pace of work.

As our customer expectations have grown over the years, so has the application. Any evolving application reaches the point where another incremental change just won’t do. Rip and replace was the only option in order to balance the complexity of features with the simplicity of design. Moving to a single-page, Java-based app enabled us to create an interactive, real- time experience that’s streamlined and agile.

Selecting A JavaScript Framework

From a technical perspective, a single-page Web application is delivered as one page to the browser and typically does not require the page to be reloaded as the user navigates to different parts of the application. This results in faster navigation, more efficient network transfers, and better overall performance for the end user.

When it comes to designing single-page applications, there are several JavaScript frameworks available to facilitate the task of writing complex client-side applications. While the choice of frameworks is a rather subjective decision (and each developer will have his or her own opinion), we ultimately went with the Ember JavaScript Framework due to several key reasons:

  • Ember.js is constructed with large applications in mind and fits a larger team and project like Zendesk.
  • Ember.js has more conventions and structure, and these established conventions make it easier to bring new developers on board.
  • Ember.js is primarily based on dynamic bindings that automatically update the UI when data changes; this allows us to easily describe UI that knows when to update.
  • Ember has a vibrant, growing community of very clever people.

Other Technical Considerations

In addition to selecting a JavaScript framework, there are a few other things to keep in mind if you’re considering a similar move to a single-page app.

  • Before we could begin writing in JavaScript, we needed to significantly build out the API to cover everything. Modern one-page apps have a really effective API with the JavaScript client written on top. This was a large task, but the final API can now be used by the whole Zendesk community.
  • A JavaScript application relies on browser features, such as advanced CSS. Therefore, supporting advanced features requires a fairly modern browser. Early on, we decided not to support IE8 and below in order to keep our development costs down. It’s important to define the supported (and not supported) browsers from the start.
  • While JavaScript tools are maturing by leaps and bounds, they aren’t quite on par with what developers may be accustomed to using with HTML. For example, we didn’t find an out-of-the-box testing automation tool to use, so developers needed to rely on manual testing or writing their own test scripts for testing in the browser.

Transitioning Developers From HTML To Java

Before we began the shift to a single-page application, only about 10 percent of our engineering resources went toward JavaScript coding. That was about to change dramatically. We ended up hiring just two JavaScript-only programmers, and for the rest we relied on ramping up the JavaScript skills in our existing engineering staff.

While learning any new skill takes time, we got buy-in from the engineers early on. Convincing our engineering teams to take on this challenge was relatively easy. This transition gives everyone the enviable opportunity to work with modern methodologies and tools. However, there still is a learning curve that must be factored into the project schedule.

Preparing For The Adjustment Period

No matter how fantastic the next-generation application may be, the simple fact is that existing end users have been happily accustomed to doing things a certain way. Getting used to changes to the status quo takes time.

To help ease the transition, we rolled out the new version of Zendesk for new accounts and trials. Existing customers are free to stay with the original Zendesk version for the time being. In addition, we started with a soft launch to a small subset of customers. This was followed by a four-month beta period, which allowed us to see how customers responded to the new design and workflow.

Ripping down an application to rebuild is a risky proposition. However, it’s sometimes the only way to move forward. The journey requires a commitment from all involved – including end users and developers. A major project of this scope won’t happen overnight, but the agility, performance, and real-time nature of the results are well worth the effort.