Should your company have a mobile website?
Here at ThoughtMatrix, we do a considerable amount of PHP development. We work with everything from Drupal and WordPress to Zend Framework, Concrete5, CodeIgniter and custom home-grown apps. It’s necessary for me to have a local LAMP environment so I can quickly and efficiently set up and work on new and existing projects. About four years ago, I made the switch to MAMP. The fact that MAMP was a completely self-contained LAMP stack appealed to me as I’ve had some bad experiences in the past using Mac’s native PHP and Apache—OS updates would wipe out the customizations I had made. Shortly after starting to use MAMP, I became sick of manually editing my hosts file and adding new Virtual Host directives to MAMP’s Apache config. Enter MAMP PRO.
It’s no secret that prototyping mobile applications is hard. HTML5 doesn’t really provide a great facsimile for native apps—you just don’t get the responsiveness or layout that makes you want to develop native in the first place—and a lot of tools that are great for web functional prototypes, like our much beloved Axure RP, are not necessarily ideal for prototyping native mobile applications depending on the UI complexity. We, here at ThoughtMatrix, are huge fans of Axure which is not going to change anytime soon, but we do realize its limitations for certain types of applications.
We experienced quite the extraordinary turn of events this past week, though not entirely surprising to those up on industry trends. Simply put, LinkedIn—the company who just last year espoused how HTML5 client development was still extremely relevant—released a major new update to their application and without any forewarning quietly let it slip that they have moved from a hybrid application to an all native design.
Given the current proliferation of mobile touchpoints, we are often tasked with helping clients create mobile roadmaps and strategies. Inevitably, we are asked if there is a way to build content or functionality once and deploy it on a variety of different mobile platforms. The answer, of course, is yes. In fact, there are several ways, and the benefits of doing so vary from a more streamlined development process to higher adoption rates to lower costs. However, when is the right time to use cross-platform solution? What kind of requirements lend themselves to this simpler approach? When is the cross-platform approach actually simpler than developing for native applications?
I may be a bit of a creature of habit; I tend to do about three things when I use my smartphone—email, then over to Facebook and then maybe check stocks or an ESPN app to check scores, but that sadly feels like the extent of it. Oh, I’m sure I do other things here and there that make smartphone ownership great; I use maps when I’m lost, Yelp when I’m hungry, Google Voice for texting and Evernote. Yet, rarely do I go out of the way to read news and fun content on my phone because it usually requires a lot of slow loading, phone turning, pinching and zooming.
As you’re surfing the Internet you see a fantastic article about how to make the perfect cat video. You also want to save some photos from Google Image Search and store them somewhere you can access on the go. What about recipes? Do you have a recipe box gathering dust because you search the Internet now for recipes? Where do you keep all this stuff so you can easily reference it later?
So yesterday Microsoft unveiled it’s entrant into the tablet market with the new Surface. First, if that name sounds familiar, it should. In 2007 the Redmond juggernaut released the tabletop touch computer that has primarily been used in retail, hospitality and restaurants. In case you care, they are still selling it, but changed the name to PixelSense (yeah, how about “makes no sense”).
In our first article, we discussed the amazing flexibility that responsive design offers. But this flexibility comes with a price that might negatively affect your fastest-growing audiences – mobile and tablet users. While offering a flexible layout, responsive design requires the latest browsers, more code, and large images. In short, responsive layouts can be bandwidth hogs and resource-intensive to render. This affects users on the move, where bandwidth is the scarcest, and where processors lack the raw power of their desktop predecessors.
With mobile smartphone use growing at such an astounding pace, I’m constantly amazed that there are still so many top-tier companies that do not have a dedicated mobile website experience. I believe that this rapid growth seems to be outpacing many IT and marketing executives’ ability to digest and grasp how mobile is going to drastically affect their business growth – particularly in the consumer space.
With mobile, the year 2012 will be a unique parallel to 1996-97, when many industry titans were caught with their pants down by the speed at which web use grew, and were unable to launch a compelling website faster than their competitors.