Lately, there’s been a lot of hype around Pinterest overtaking LinkedIn to own the number three spot in the list of top social media networks. In fact, a recent report from Shareaholic states Pinterest drives more traffic than Google+, LinkedIn and YouTube combined. So, it’s no surprise that brands are rushing to figure out how they can benefit from this exploding social channel. But the reality is that Pinterest isn’t for everyone, and it isn’t for every brand. Here, we’ll take a look at what makes Pinterest different, who stands to get the most from using it and how to do it right.

What Makes Pinterest Different

Understanding what makes Pinterest different than other social platforms provides valuable insight into its allure and provides clues on how to best leverage it successfully.

1. It’s Visually Driven

The most obvious difference is that Pinterest is completely visually driven. Pinners make immediate decisions about whether or not they are going to view or pin something based on the visuals alone. For brands that have products or services that shine visually, Pinterest is an excellent choice.

2. Motivation is Around Inspiration and Discovery

Unlike other social networks that are focused on what you’re doing right now, Pinterest concentrates more on what you want to be, where you want to go, what you want to build in the future. In that vein, it’s very inspirational and represents a real opportunity for the right brands. Let’s say you’re building a house. Pinterest can provide a vast library of ideas around architectural styles, color palettes, flooring and other design features. Pinners collect ideas on boards for inspiration and when they’re ready to buy, all they have to do is click on the image to get to its original source and purchase.

To read more about what makes Pinterest different, read the full newsletter on ThoughtMatrix.

Is Pinterest Right for You?

You’ve probably already started to form some ideas around whether or not Pinterest is good for your brand. If you’re still not sure, here are some questions to consider. If the answer is no to any of them, then Pinterest may not be right for you.

1. Do you have a unique brand personality that can be conveyed through images?

This is a bit of trick question because the answer isn’t as obvious as you might think. For example, you might not think Whole Foods would have a brand personality that could be conveyed visually, but they absolutely do. They do it through compelling visuals best thought of as “food porn”—images of mouthwatering produce and recipes, ideas for edible celebrations, food as delicious art, etc.—all of which are designed to communicate their core values of “selling the highest quality natural and organic products available” and “satisfying and delighting our customers”.

2. Is your product or service a source of inspiration or motivation for others?

You might not think of paint as being an interesting or inspirational subject on its own, but when it’s the paint color that completely makes the look of a room then it certainly can be. Using the Pinterest Pins source lookup feature (www.pinterest.com/source/yourwebsite) you can easily see that visitors to BenjaminMoore.com are finding plenty of inspiration.

Using this feature not only lets you see what people are pinning, it also gives you some insight into why they’re interested in these images by reading the comments. No other social media network provides this level of collected, curated comments on a brand’s products or services. It’s important to note though that Benjamin Moore clearly included inspirational imagery as part of their content strategy.

To read more about if Pinterest is right for your brand, read the full newsletter on ThoughtMatrix.

Ideas for Getting Started with Pinterest

So what does all this mean for you? If you’ve got an existing library of appealing imagery, Pinterest represents a real opportunity to break out in an exploding social channel. Some other ways you might begin to leverage Pinterest include:

Pinterest Contest

For brands with good product imagery, you can easily invite users—via email, Facebook, Twitter and your website—to create pinboards highlighting the products you offer that they like most. Incent sharing by giving points for the most repins, which are essentially votes. This tactic doesn’t even require you to create your own pinboard, making it easy for you to test the waters of Pinterest while driving awareness and advocacy of your brand.

Mood Board

Don’t have products that lend themselves to pinning? Then consider creating a pinboard of things representative of your brand’s personality. It could include charitable causes you support, content around the science behind your product or service or even highlights from partner brands. You never know who may discover—and ultimately come to respect—your brand because of a mutual interest.

To find more ideas on how to get started with Pinterest, read the full newsletter on ThoughtMatrix.

Pinterest Demands that You Be Interesting

Ultimately your success on Pinterest will hinge on a good content strategy, because without interesting content, no one is going to pin it. This is good advice in general though since providing a rich, well-rounded user experience online is the key to everything from lead generation to search engine optimization to customer engagement. ThoughtMatrix has a knowledgeable team of content strategists, graphic artists and UX designers who can help you develop online experiences that are not just worthy of being pinned but that also ensure that your users engage with your brand on a deeper level. Contact us.

The Trade Lingo

VPS – Virtual Private Server: This is a common term for a hosting server that actually lives on a shared physical server. The server acts like a ‘real’ server, but is actually sharing the underlying physical hardware with several other virtual servers using virtualization technology. Not surprisingly, this economical use of physical hardware translates into cheaper rental rates for the customer. However, using a VPS brings the increased risk of sharing the hardware with a ‘noisy neighbor’. That is, you need to be sure that you are not sharing the physical server with another virtual server that is resource hungry and prevents your server from getting to the CPU or other physical resources in a timely manner. Clearly, when choosing a VPS-based solution, the fine details of the offering should be examined to ensure there is fair and equitable provisioning of server resources among virtual nodes.

Dev Ops or Sys Admin: Technical resources who can deploy and manage the website on the hosting provider. Sometimes these are in-house experts at your organization, or you may utilize hired resources provided at extra cost by the hosting provider. More commonly, the web developer who built the application for you is forced to serve as an ad hoc Sys Admin. This is not a good route to follow as development of a website and deployment of a website are separate disciplines with conflicting priorities.

PaaS – Platform-as-a-Service: Some hosting choices actually offer a complete Dev Ops function with them. That is, they have built the offering out to allow for auto-managed deployment of your application or site. Think of it, in very rough terms, as offering the ability to upload and deploy a site in much the same way as you would upload a batch of photographs from your local computer to an online photo browser. Sites running on a PaaS provider are often amazingly maintenance free, but PaaS does impose restrictions on what your application can or cannot do, and how often it can do it.

Elasticity , or Elastic Cloud Computing: Refers to a strategy of dynamically providing additional capacity to your hosted applications as they experience more demand. This is an approach popularized by Amazon Web Services and adopted by many others. This strategy allows you to avoid having to pay for redundant capacity, which is a traditional way of dealing with scaling issues. Elastic cloud computing is a brilliant concept, but one that only the world’s most popular and heavily trafficked sites need to consider.

Issues To Consider Up Front

Generally, the choice is narrowed down to a few options by answering these three questions first:

1. Do you have a Development Operations or Systems Admin group you can lean on?

2. What is your project’s technical ‘stack’?

Your website or application will be programmed in a specific language, and live on top of a specific set of complementing frameworks, such as a database and a web server. This combination of technologies is generally referred to as the ‘stack’. The choice of stack is important when choosing a hosting platform. Some hosts cater to a specific stack, whilst others are agnostic. For instance, Acquia is the dominant player for Drupal-based site hosting, whilst Heroku enjoys similar hegemony in the Rails world.

3. What kind of regulation and compliance restrictions are you subject to?

Recommended Hosting Providers

With these thoughts in mind, let’s move on to an assessment of the current market offerings with which I am familiar and often recommend to clients. I’ll break out the listing in to three segments: PaaS, VPS and ‘niche’ providers. I’ve also included some basic pricing information, as well as a information on which tech stack the solution is best suited to:

PaaS Options

1. DotCloud

Pros : Supports a wide variety of technical stacks and features, and has a simple command-like deployment toolset that makes it trivially easy to get your application ‘live’.

Cons : Relatively new service that has not been exstensively road tested or endorsed by major brands.

Summary: Well worth serious consideration if you are looking to standardize on a PaaS offering across several projects and languages, and you have $100 or more a month to spend on hosting costs.

2. Heroku

Pros: Has great support in the Ruby-on-Rails community, and is diversifying across other languages and frameworks very quickly. It is now part of large enterprise vendor (Salesforce.com). Offers a large ecosystem of plugins that allow developers to add specific services to their sites without having to manage those services directly (e.g. content caching to speed up site performance).

Cons: Static IP addresses are very expensive on this host, which can hamper your efforts to run a secure website or integrate with third-party systems. It also has suprisingly poor Salesforce.com integration considering they are the same company now.

Summary: Should be your go-to option if your primary development language is Ruby-on-Rails and you run small-to-medium sized sites. Not recommended for an e-commerce operation or something requiring heavy security. Should also be on the shortlist if you do Java-based web development. Will run about $50 a month for a basic site, but costs grow quickly as application requirements become more sophisticated (e.g. caching, monitoring, large data storage).

3. Google App Engine

Pros: Free service tier; fairly mature offering; easy to get a very simple static site up on it.

Cons: Limited to Python language, only supports a subset of Java.

Summary: In general, very heavy on constraints and has a surprisingly limited auxilliary toolset (data import/export tools etc). Ideal for a light static website with limited or zero database interaction (for example, a small corporate website or a restaurant website) that you want to run for a next-to-nothing monthly cost.

4. Acquia

Pros: De facto choice for deploying Drupal sites, with a very healthy portfolio of brands under their roof. Choose between a managed or independently managed instance.

Cons: You have to run with their Drupal stack (version, plugin library, etc.) rather than the particular flavor your team developed against.

Summary: Basic hosting with Acquia will cost at least $50 a month, but this is money well spent if you are building your sites on Drupal and have little or no in-house Dev-Ops support.

VPS Options

1. Amazon Web Services

Pros: The marquee name in website hosting that offers a plethora of add-ons and secondary services to it’s core VPS instances.

Cons: Complicated to administer and complicated to price. Furthermore, elastic cloud features are not needed by most sites.

Summary: The go-to option for enterprise-grade website initiatives that have a need to develop an ecosystem of web ‘parts’ in the cloud. AWS has you covered for such auxilliary technologies as elasticity, caching, content-delivery-network, workflow engine, monitoring…and the list goes on, with new services in the pipeline all the time.

2. Rackspace

Pros: Offers a wide variety of hosting services for different budgets and different uses cases. Managed hosting is available, as is self-service VPS, or a hybrid model of both.

Cons: Rackspace is one of the biggest hosting providers in the world, with thousands of paying customers, so don’t expect detailed personal attention to your account or focussed customer service.

Summary: A very strong variety of offerings at competitive prices. Expect to pay $50 or below for a simple website, and $100 or so more a month if you want them to manage your server for you (hint, you probably want this option if you dont have a dedicated Dev Ops team).

3. RimuHosting

Pros: Friendly yet professional boutique hosting provider that has some excellent rates on VPS and non-shared instances. Arguably the best customer service in the industry.

Cons: Despite great customer service, still primarily a do-it-yourself offering that will require some familiarity with working at the command line and managing a website in production.

Summary: If you are new to VPS hosting, and have a limited budget, Rimu is a great place to start. A typical WordPress-style website can be up and running for about $25 a month, with stellar technical support from the provider if you run in to problems.

4. Linode

Pros: Affordable service with wide choice of location hosts and a good set of self-service admin tools (such as back-up servers, clone servers, etc.). Can choose to which continent to deploy your website at no extra cost.

Cons: Doesn’t offer dedicated non-shared server instances. Limited technical support.

Summary: You can’t go too far wrong with these guys if you are looking to host a site or multiple sites for around $30 a month, and gain some light Dev Ops capability.

Niche Players

1. Firehost

Pros: Offers a plethora of enhanced security options for full HIPAA compliance, such as encrypted file systems for protecting ‘at rest’ data. Ideal for healthcare and insurance providers who handle confidential medical records.

Cons: Expensive option that still leaves a lot of configuration details to the end user. You will need top-notch Sys Admin support to use this service.

Summary: This is a true niche option, that caters to that subset of corporations that want to store and protect medical records in the cloud.

2. Force.com

Pros: Salesforce.com customers, and there are lot of them out there, can build out their own custom applications on the Salesforce.com platform. You may want to use this option to build out specific websites against your Salesforce.com data (for example, a custom marketing campaign microsite that harvests lead info and siphons it directly into Salesforce.com). You can also enjoy virtually zero Dev Ops overhead as this pure-platform play allows a developer to build out web applications directly on the servers that are managed by the Salesforce.com Dev Ops team.

Cons: Although simple sites are free on force.com, it will cost you to add users to your site, and this can get very costly. There are other usage constraints that should be thoroughly investigated before using this platform. Lastly, your web developer(s) will have to work with the force.com toolset, which although improving all the time, is not on a par with tools they would regularly use to build a website.

Summary: Good choice if you are committed to the Salesforce.com platform and want to build out additional public facing sites on top of your data there. Beware of hidden costs, however.

Summary

I hope this precis of the hosting providers I normally recommend has been useful to you if you are looking to choose a host yourself, or are working with a development team that is doing so on your behalf. To recap in brief; if you have a lot of definite bleeding-edge requirements and a very commited Dev Ops team, Amazon is a clear choice, but otherwise Rackspace is your best bet…at least for generic VPS hosting. If you are looking for a more personalized service, I heartily endorse Rimu, closely followed by Linode (especially if you plan to run your site out of various global locations). On the PaaS side of things, I am very excited about DotCloud. They have executed well so far on their vision to provide a seamless platform that web developers on the most popular stacks can easily deploy to without the need to specifically engage a Dev Ops team.

Thanks for reading, I welcome your comments on my suggestions!

For an introduction to responsive design, see Part One in this series.

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.

Before diving into a responsive design workflow, we’ll explore some of responsive design’s shortcomings, and examine some of the current strategies to address them.

One Image Shouldn’t Fit All

The fluid resizing of images, which is one of responsive design’s hallmarks, is also its Achilles heel. Mobile networks are bandwidth constrained, and speed matters more for mobile users on cellular networks than it does for their landline-connected counterparts.

In many cases large desktop images, such as home page banners, are up to 80% larger than the same image optimized for a mobile display. Browser resizing of images is CPU intensive, which causes phones to slow down and consume precious battery resources.

Worse, mobile webkit (Safari Mobile and Android Browsers) will force-download images that were only intended for the desktop version of the site, even if media queries and CSS are used to hide or prevent those image assets from displaying.

Fortunately, there is work being done to solve this problem. Responsive Images is a javascript-based stopgap approach, which delivers mobile-first images as the default, then uses javascript to deliver the larger desktop images. Adaptive Images is an easy to implement server-side solution that detects the visitor’s screen size, then creates, caches and delivers the appropriately sized image. It even detects retina displays, on devices like the new iPad or the iPhone, and can serve high resolution images to just those devices. If serving retina-sized images is your primary concern, check out retina.js, a javascript progressive enhancer which scans image directories for “@2x” images and automatically swaps the low resolution images with high resolution images on the appropriate devices.

As devices and high resolutions screens become commonplace, a long-term, native solution will be necessary. Such a solution has been proposed, but it will require standards organizations and browser makers to get on board before it can be successful. Until then, designers, developers and website owners are left to work through the trade-offs on a case-by-case basis.

Some Devices Don’t Support Media Queries

Media queries – the technology that allowed for the creation of responsive design, in the first place, is not natively supported on several important browsers, including Internet Explorer 8 and older; IE Mobile (Windows Phone 7 and earlier); Blackberry; and some proprietary browsers from phone manufacturers such as Sony Erikson and LG.

As with fluid image resizing, there is a javascript polyfill fix for older versions of desktop Internet Explorer, but Blackberry and IE Mobile browsers are still unsupported.

However, if responsive design is approached from a mobile-first design strategy, this shouldn’t be a problem, since the default stylesheet for the site would be tailored for mobile users, and media queries would then be used to progressively enhance for tablets and desktops. We will discuss the advantages of using a mobile-first design approach in part 3 of this series.

Third-Party Content Often Breaks Responsive Layouts

Careful planning and evaluation needs to take place if your site is heavily reliant on third-party content and widgets – social media plug-ins; iframed content such as outsourced job postings and investor relations sections; or embedded e-commerce widgets. Most third-party widgets are not designed with fluid layouts in mind, and often lack customization options to adapt the layout to a responsive design.

If this is the case with your plugin or outsourced content, there is no easy answer. Solutions vary and may require serving up the iframe-specific content in a static, non-responsive template, or working with vendors to create an adaptive template for their content.

Your agency or content partner can help you navigate these issues as you plan your migration to a responsive design.

Responsive Design Ignores Context

Designing a site specifically for mobile has its advantages, particularly if your user’s context is important to your business. A good mobile site will take advantage of geolocation and a mobile layout to serve up content uniquely suited for users on the go.

An oft-used example is restaurateurs. Desktop visitors may want to learn more about the history and ambiance, read the wine list, view chef bios and see large photos. Mobile users often want directions, easy access to the phone number, and a simple means to read the menu or quickly make reservations.

When considering mobile users, starting from the ground up to build a uniquely mobile solution may be a better strategy than the “one size fits all” approach that responsive design offers.

It ain’t all bad

Responsive design offers a lot of advantages that mostly outweigh the disadvantages. In the next part of this series, we’ll discuss planning and implementation strategies for both new sites and existing sites. In the meantime, if you have an immediate need to discuss how responsive design might work for you, ThoughtMatrix is happy to help. Just contact us.

Simplicity = Accessibility

I was pleasantly surprised at the simplicity of Google Play. I think iTunes is the defacto “media outlet” these days, but there is so much content there that it’s easy to get lost. Google has done a nice job of keeping their offerings simple and easy to navigate with quick choices like; My Music, My Books, My Movies and My Android Apps, making it is very easy to dive in.

Going mobile with Google Play is challenging since there are different options for consuming the content of choice, depending on what type of media you want. For My Movies, you can watch via the Chrome browser or a downloadable Android app. My Books offers choices for reading with a browser, an iPhone, iPad or Android app. My Music can be accessed via the browser or by downloading Music Manager. It would be nice to have one user experience rule them all, regardless of device, similar to what Apple has done. My guess is we will see that level of accessibility grow as their store matures.

There are a few other kinks keep the user experience from being fully baked. For example, if you go to My Books while listening to music, the audio stops. I think it would be a big win to allow the music to keep playing in a dedicated player while the user is browsing other parts of the store. The Google Play home icon doesn’t actually take you to Google Play home page from every page. For example, when on the My Music page, it just seems to refresh that page. This is a small annoyance, but a low-hanging usability issue that, when fixed, would make a much nicer experience for the less-savvy user.

Missed Opportunity for Google?

Google Play doesn’t go so far as to offer TV shows like iTunes does, giving Apple the advantage by capturing engaged users who want to keep up with serial television episodes. Not getting that repeat business is a loss for Google.

Another area of missed opportunity is not offering discounts for users who “+1” purchases to their Google+ accounts. This seems like an obvious way to leverage their existing social network, and an area that both Facebook and iTunes have had no success in because they don’t “own” both sides of the equation. Google has the unique opportunity to deliver an instant, seamless audio/video social experience from sharing to purchasing. Spotify has come the closest in this regard but that’s just audio. In the flip side, the social gap may be that not everyone wants to share what they watch and listen to. People don’t refer to watching trash tv as a guilty pleasure for nothing!

Overall, Google has done a solid job of creating enough offerings to get users interested in shopping for media content on their site, including offering both affordable and the more-pricey content. If they could  find a way to leverage Google +, this could really be groundbreaking.

It can start with “The birth of the human race” if you want it to. Facebook’s timeline allows you to post before you joined Facebook, before the Internet was born, even before Mark Zuckerberg was born (way back in the mid 80s).

2. When loading up historical Milestones, hide them from the newsfeed.

Here’s a great example of what not to do when creating a timeline. Dos Equis has been updating their timeline and it’s flooding my personal wall, drawing a lot of negative comments. If they want me to stay thirsty for Dos Equis, they need to respect my personal space. When creating a timeline, and especially when loading a lot of historical entries at once, don’t forget to check the “Hide from newsfeed” option so that your users don’t get flooded with old events.

3. Make sure your cover photo is sized at 851 x 315 pixels.

It looks unprofessional and unattractive to have a pixilated, scaled-up, or improperly framed picture. If you don’t have a designer, you can use a free app like: http://timelinecoverbanner.com to make your cover photo look positively smashing.

Some other useful dimensions:

• Profile photo should be sized at 180 x 180 pixels (scale down to 30 X 30 pixels)
• Custom tab image photos should be 111 x 74 pixels

So, why would you want to develop on GAE? For most people the answer is likely to be that GAE provides a great platform for growth. If you plan to expand or add functionality over time and need something that can easily leverage the toolset available within Google, then GAE is a good option to consider.

The GAE provides a framework for Java, Python and Google’s Go experimental language. For this blog entry, I will be using the Java framework. Yes, even though I may not be utilizing any Java code in favor of only HTML/CSS/Javascript, the framework provides all Java GAE components service aspects as well as providing a consistent deployment framework using Maven. And if I wish to further evolve the site, I can easily use additional frameworks on top of the Java platform.

This is just one way to skin the cat.  There is a great blog post on using GAE as your CDN via Python.

Environment Setup

There are a couple of dependencies that you will need to get your environment going:

• Java SE 1.6+ SDK
• Maven 2.2.1 or 3.x+
• Google Gmail Account

Once you have acquired the above dependencies you should be ready to prepare a stubbed-out site project. Maven will pull the remaining dependencies from here on out.

Using the Mavin GAE plugin, there are a variety of Boilerplate/Archetypes available to define what type of structure will be generated.

Here is a list of those available:

• Plain JSP based example -DarchetypeArtifactId=gae-archetype-jsp
• Wicket based example -DarchetypeArtifactId=gae-archetype-wicket
• GWT based example -DarchetypeArtifactId=gae-archetype-gwt
• JSF based example -DarchetypeArtifactId=gae-archetype-jsf

Also, you can use JAppStart or Spring Roo as tools to generate various project frameworks for the Google App Engine environment within the Java platform umbrella. But for our example we will generate a plain JSP project and then modify the structure for an even simpler structure for our HTML-only environment.

From your command line run the following command →

$ mvn archetype:generate -DarchetypeGroupId=net.kindleit \

-DarchetypeArtifactId=gae-archetype-jsp \

-DarchetypeVersion=0.9.2 \

-DgroupId=com.mydomain.mysite -DartifactId=test-tmatrix-app001

run output →

You will be prompted for several items. Selecting the defaults should be fine, except for the GAE version. This should be set to the latest and greatest of the GAE SDK. Currently, it is 1.6.2.1

[INFO] Scanning for projects...

[INFO] Searching repository for plugin with prefix: 'archetype'.

[INFO] ------------------------------------------------------------------------

[INFO] Building Maven Default Project

[INFO]    task-segment: [archetype:generate] (aggregator-style)

[INFO] ------------------------------------------------------------------------

[INFO] Preparing archetype:generate

[INFO] No goals needed for project - skipping

[INFO] [archetype:generate {execution: default-cli}]

[INFO] Generating project in Interactive mode

[INFO] Archetype repository missing. Using the one from [net.kindleit:gae-archetype-jsp:0.9.2] found in catalog remote

Downloading: http://repo1.maven.org/maven2/net/kindleit/gae-archetype-jsp/0.9.2/gae-archetype-jsp-0.9.2.jar

Downloading: http://repo1.maven.org/maven2/net/kindleit/gae-archetype-jsp/0.9.2/gae-archetype-jsp-0.9.2.pom

[INFO] Using property: groupId = com.mydomain.mysite

[INFO] Using property: artifactId = test-tmatrix-app001

Define value for property 'version': 1.0-SNAPSHOT: 

[INFO] Using property: package = com.mydomain.mysite

[INFO] Using property: package = com.mydomain.mysite

Define value for property 'gaeApplicationName': : test-tmatrix-app001

[INFO] Using property: gaeApplicationVersion = test

[INFO] Using property: gaePluginVersion = 0.9.2

[INFO] Using property: gaeVersion = 1.5.3

Confirm properties configuration:

groupId: com.mydomain.mysite

artifactId: testapp

version: 1.0-SNAPSHOT

package: com.mydomain.mysite

package: com.mydomain.mysite

gaeApplicationName: testapp

gaeApplicationVersion: test

gaePluginVersion: 0.9.2

gaeVersion: 1.5.3

Y: n <-- Reject to override gaeVersion.

[INFO] Using property: groupId = com.mydomain.mysite

[INFO] Using property: artifactId = testapp

Define value for property 'version': 1.0-SNAPSHOT: 

Define value for property 'package': com.mydomain.mysite: 

[INFO] Using property: package = com.mydomain.mysite

Define value for property 'gaeApplicationName': : test-tmatrix-app001

Define value for property 'gaeApplicationVersion': test: 

Define value for property 'gaePluginVersion': 0.9.2: 

Define value for property 'gaeVersion': 1.5.3: 1.6.2.1

Confirm properties configuration:

groupId: com.mydomain.mysite

artifactId: test-tmatrix-app001

version: 1.0-SNAPSHOT

package: com.mydomain.mysite

package: com.mydomain.mysite

gaeApplicationName: test-tmatrix-app001

gaeApplicationVersion: test

gaePluginVersion: 0.9.2

gaeVersion: 1.6.2.1

Y: 

[INFO] ----------------------------------------------------------------------------

[INFO] Using following parameters for creating project from Archetype: gae-archetype-jsp:0.9.2

[INFO] ----------------------------------------------------------------------------

[INFO] Parameter: groupId, Value: com.mydomain.mysite

[INFO] Parameter: artifactId, Value: testapp

[INFO] Parameter: version, Value: 1.0-SNAPSHOT

[INFO] Parameter: package, Value: com.mydomain.mysite

[INFO] Parameter: packageInPathFormat, Value: com/mydomain/mysite

[INFO] Parameter: gaePluginVersion, Value: 0.9.2

[INFO] Parameter: package, Value: com.mydomain.mysite

[INFO] Parameter: version, Value: 1.0-SNAPSHOT

[INFO] Parameter: gaeApplicationName, Value: test-tmatrix-app001

[INFO] Parameter: groupId, Value: com.mydomain.mysite

[INFO] Parameter: gaeApplicationVersion, Value: test

[INFO] Parameter: gaeVersion, Value: 1.6.2.1

[INFO] Parameter: artifactId, Value: testapp

[INFO] project created from Archetype in dir: ~/test-tmatrix-app001

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESSFUL

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 1 minute 16 seconds

[INFO] Finished at: Wed Feb 22 19:57:08 PST 2012

[INFO] Final Memory: 49M/3925M

[INFO] ------------------------------------------------------------------------

Jeff-Schenks-MacBook-Pro:SANDBOX jeffschenk$ 

Finalize Environment Setup – Directory Structure

Now you have a stubbed-out file system hierarchy for your project as well as a new Maven POM for the project with the necessary dependencies specified.

Depicted below is the file system after the initial Maven generate command. Now you need to prune and create some directories. First change to the directory of the application that you just created: cd test-tmatrix-app001. You should see a structure like this:

All of the items marked in red have been removed as this microsite does not using any data or message services.

Your directory structure should now resemble the following:

Now you need to create the following directories for serving the static HTML/CSS and Javascript:

webapp/public

webapp/public/css

webapp/public/fonts

webapp/public/images

webapp/public/js

Create your index.html under webapp/public/ and place your necessary HTML/CSS/Javascript and images in the appropriate directories you have just created. Also, create a new app.yaml file, which will contain a very simple GAE configuration. Your directory structure should now resemble the following:

Edit the webapp/WEB-INF/app.yaml to contain the following:

You also need to edit the web.xml source file to remove the generated servlet, which is not necessary.  The web.xml should resemble the following:

Click image to enlarge

The Maven WAR Packaging plugin requires a web.xml. This one is actually overridden by using the app.yaml configuration file, which when recognized by the GAE plugin will generate the web.xml and the necessary appengine-web.xml.

Finalize Environment Setup – Maven pom.xml

Ok, you’re almost there. Now you need to modify the pom.xml so you can remove some dependencies that are not needed—such as data persistence and other frameworks, which are not being using at the moment. Please see the following edits to remove the JDO and other unnecessary dependencies:

Click image to enlarge

Click image to enlarge

Click image to enlarge

Obtaining GAE SDK

Now you can download the GAE SDK into this environment. From the command line within the application, run –> test-tmatrix-app001 jeffschenk$mvn gae:unpack

After a series of downloads you should see the following messages indicating that the GAE SDK has been successfully downloaded and extracted into your local Maven repository.

[INFO] Extracting GAE SDK file: /Users/jeffschenk/.m2/repository/com/google/appengine/appengine-java-sdk/1.6.2.1/appengine-java-sdk-1.6.2.1.zip

[INFO] To path:/Users/jeffschenk/.m2/repository/com/google/appengine/appengine-java-sdk/1.6.2.1

[INFO] ————————————————————————

[INFO] BUILD SUCCESSFUL

Now you need to obtain access to GAE from Google before you can deploy the site.

Obtaining GAE Access

Go to URL: http://code.google.com/appengine/ to obtain access to the Google App Engine.

Step 1

Sign up for a Google App Engine account. Here is where your Gmail account will be necessary.

Step 2

Once you have verified access to the Google App Engine, go to URL: https://appengine.google.com/ to access your App Engine Dashboard. If you have multiple Google accounts, simply select the Google account for which you want to create a new application.

Click image to enlarge

Step 3

You will see a list of existing applications. Select the “Create Application” button to begin creating a new application.

Click image to enlarge

Step 4

Enter the appropriate unique application identifier. For this example it is test-tmatrix-app01.

Click image to enlarge

Step 5

Create application.

Click image to enlarge

Step 6

Confirmation of application registered successfully.

Click image to enlarge

Step 7

Using the application Dashboard.

Click image to enlarge

Now you have your GAE instance bucket for your application defined and are ready to deploy an application version to the instance.

Deploy to GAE

Assuming that you have placed your HTML/CSS/Javascript in the appropriate directory structure, you can now deploy your initial version to GAE. From the command line simply enter the following:

$ mvn gae:deploy

[INFO] Scanning for projects…

[INFO] ————————————————————————

[INFO] Building test-tmatrix-app001

[INFO]    task-segment: [gae:deploy]

[INFO] ————————————————————————

[INFO] Preparing gae:deploy

[INFO] [resources:resources {execution: default-resources}]

[INFO] Using ‘UTF-8′ encoding to copy filtered resources.

[INFO] Copying 2 resources

[INFO] [compiler:compile {execution: default-compile}]

[INFO] Nothing to compile – all classes are up to date

[INFO] [resources:testResources {execution: default-testResources}]

[INFO] Using ‘UTF-8′ encoding to copy filtered resources.

[INFO] skip non existing resourceDirectory /Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/src/test/resources

[INFO] [compiler:testCompile {execution: default-testCompile}]

[INFO] No sources to compile

[INFO] [surefire:test {execution: default-test}]

[INFO] No tests to run.

[INFO] [war:war {execution: default-war}]

[INFO] Packaging webapp

[INFO] Assembling webapp [test-tmatrix-app001] in [/Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/target/test-tmatrix-app001-1.0-SNAPSHOT]

[INFO] Processing war project

[INFO] Copying webapp webResources [/Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/src/main/webapp] to [/Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/target/test-tmatrix-app001-1.0-SNAPSHOT]

[INFO] Copying webapp resources [/Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/src/main/webapp]

[INFO] Webapp assembled in [321 msecs]

[INFO] Building war: /Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/target/test-tmatrix-app001-1.0-SNAPSHOT.war

[INFO] WEB-INF/web.xml already added, skipping

[INFO] [gae:deploy {execution: default-cli}]

[INFO] Updating Google App Engine Server…

Reading application configuration data…

Feb 27, 2012 1:04:06 PM com.google.apphosting.utils.config.AppEngineWebXmlReader readAppEngineWebXml

INFO: Successfully processed /Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/target/test-tmatrix-app001-1.0-SNAPSHOT/WEB-INF/appengine-web.xml

Feb 27, 2012 1:04:06 PM com.google.apphosting.utils.config.AbstractConfigXmlReader readConfigXml

INFO: Successfully processed /Users/jeffschenk/jas/MyWorkspaces/GOOGLE/SANDBOX/test-tmatrix-app001/target/test-tmatrix-app001-1.0-SNAPSHOT/WEB-INF/web.xml

Beginning server interaction for test-tmatrix-app001…

Email: <gmail account>@gmail.com   <– Enter Your Gmail Account Email Address

Password for <gmail account>@gmail.com: <– Enter Your Gmail Account Password

0% Created staging directory at: ‘/var/folders/p7/h7p294_j60b0gxy80_2tx0bc0000gn/T/appcfg8864957916118846892.tmp’

5% Scanning for jsp files.

20% Scanning files on local disk.

25% Initiating update.

28% Cloning 5 static files.

31% Cloning 23 application files.

40% Uploading 12 files.

52% Uploaded 3 files.

61% Uploaded 6 files.

68% Uploaded 9 files.

73% Uploaded 12 files.

77% Initializing precompilation…

80% Sending batch containing 8 file(s) totaling 20KB.

82% Sending batch containing 4 blob(s) totaling 15KB.

90% Deploying new version.

95% Will check again in 1 seconds.

98% Will check again in 2 seconds.

99% Will check again in 4 seconds.

99% Closing update: new version is ready to start serving.

99% Uploading index definitions.

Update completed successfully.

Success.

Cleaning up temporary files…

[INFO] ————————————————————————

[INFO] BUILD SUCCESSFUL

[INFO] ————————————————————————

[INFO] Total time: 51 seconds

[INFO] Finished at: Mon Feb 27 13:04:49 PST 2012

[INFO] Final Memory: 36M/3925M

[INFO] ————————————————————————

Jeff-Schenks-MacBook-Pro:test-tmatrix-app001 jeffschenk$

Now go to the Versions tab for your GAE account and see the uploaded Version:

Click image to enlarge

Take advantage of the GAE version capability for easy deployment and the ability to deploy and then set the default version when ready to launch.

You have now successfully built out an HTML/CSS/Javascript microsite with version control, full monitoring and an efficient and continuous deployment process.

Conclusion

If you do not need a back end that’s rich with services and you are only serving native HTML, CSS and Javascript, your microsite has been deployed and you are done! If any changes are required, simply apply or accept those changes via the normal deployment lifecycle.  There is a little bit of work involved to create your first Google App Engine application, but after that you should be able to clone and add necessary dependencies if and where needed. Also, adding a job to your Jenkins / Hudson or continuous-build environment will allow for timed deployment, automatic release and version updates. Review the Maven GAE plugin documentation for more information on available maven goals for interacting with the Google App Engine’s versioning and release management.

If you are interested in using GAE back-end services to evolve the site, you can easily use Java Spring JSP, GWT, JSF or even GAElyk, a Groovy toolkit for GAE.  However, care should be taken to monitor your service usage as how your application is developed using GAE back-end service will cost based upon usage.

References

• Google App Engine Home
• Java Development App Engine Server
• Using Eclipse Plugin for App Engine
• Building GAE Java Projects with Maven
• GAElyk — is a lightweight Groovy toolkit for Google App Engine Java.
• Write your GAE Apps in Groovy
• GRails and Google App Engine Beginners Guide

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.

Let me throw some facts out there that should cause pause:

• This past quarter, Apple sold 62 million iOS devices – and  over 100,000 more iPhones were sold per day than people born in the world per day. In December, Android activations also outpaced births by around 2:1. Apple had the second most-profitable quarter in the history of the US, and was averaging $144,444.44 in profits per day, mostly from the sale of iOS devices.
• During this past year’s holiday season, purchases made via a mobile device grew by 172.9%, and 7% of online purchases were made via an iPad – a device that didn’t exist 18 months earlier.
• YouTube says that the switch from primarily PC use to mobile use for online video will definitely happen by 2013, and may happen sooner.
• app.ft.com, the iOS only version of the Financial Times, has over 1 million registered users, who account for 20% of all page views and 15% of new digital subscriptions. Those who register their device are 2.5 times more likely to subscribe, and 45% of users add the app to their home screen.
• The Weather Channel had 1.3 billion mobile page views in October 2011, compared to 1.1 billion desktop views. They predict that mobile use will outpace TV in less than two years.
• And Facebook says that 350 million of their 800 million monthly active users are checking their statuses via a mobile device. CTO Bret Taylor says, “A few years from now, most every single person at Facebook who works there is going to be working on mobile almost exclusively.” and “Companies really need to redefine themselves in this world of devices rather than browsers on people’s laptops.”

A great transition is happening on the web right now, as our devices redefine how we consume and use information. Due to location and context capabilities, mobile users will want different things from your site, so simply making a mobile copy of your desktop website may not be enough.

Luckily, the tools and knowledge are available to help your company become mobile-friendly. Building a mobile-ready site doesn’t have to be expensive and cumbersome, but it does need to be a priority… probably your top priority.

Related: Check out our What is Responsive Design? series for strategies to build a site that looks great on all devices.

Our client’s requirements were as follows:

1. Create two “site regions” (languages): North America and Europe
2. Provide the ability to translate a node for each region
3. Automatically detect location of user by IP address and redirect them to either the North American or European translated site based on a mapped list of countries

In this post, I address client requirements #1 and #2 listed above, with details on #3 coming in a subsequent post down the road.

Step 1: Create Two Predefined Regions—North America and Europe

In order to create “Regions,” the “Locale” module—part of Drupal core—must be enabled. Technically, the “Locale” module enables the ability to add “Languages,” which I used as “Regions.”

In the configuration of the “Locale” module (/admin/config/regional/language), I was able to change the default name of the “English” language to “North America” as well as add an “English, British” language that I renamed to “Europe.”

Part of the client’s requirements were that the language be determined via a path prefix (e.g., http://example.com/en/, or http://example.com/en-gb/), accomplished by selecting the “Determine the language from the URL (Path prefix or domain)” check box in the “Detection and Selection” tab of the “Locale” configuration page.

Step 2: Content Translation

After reading, Drupal 7′s new multilingual systems compilation, I was certain the Content Translation module (d7 core) was all that was needed to serve region- (language) specific content. After enabling and configuring the “Content Translation” module as well as editing the “Multilingual” support section of my content types so that they were translatable, it appeared that everything was working as desired. I was now able to create a node, assign a node to a particular language and create the corresponding translation.

To test the translations, I enabled the “Language Switcher” block that is automatically created by the “Content Translation” module. Now while viewing a node, located at http://example.com/my-node, if I clicked “Europe” on the “Language Switcher” block, the URL changed to http://example.com/en-gb/my-node and the Europe translation is displayed. WINNING, right?! Just as I was ready to mark my Bugzilla ticket as completed, I realized a show stopper. Menus…

Since “Content Translation” actually creates an entirely new node for each translation, there was no way for me to have one menu item that would link to the corresponding node translation depending on which region is selected. The test node I created previously had a menu item titled “My Node,” assigned to the North America language translation, and I gave both translations the same exact path alias—my-node—assuming the Drupal menu system would be smart enough to handle the node translations, but the results were not as I desired.

When on a page in my Drupal site without a language path prefix (e.g., http://example.com, and I click my menu item, “My Node”), I am taken to the nodes page, http://example.com/my-node. Now when I click the Europe link in my “Language Switcher” block, I am taken to http://example.com/en-gb/my-node. Here was my issue—now when I click on my “My Node” menu item, it takes me to http://example.com/en-gb/node/1 (1 being the node ID of my North American translation). I was expecting to be taken to the same page I was currently on, or at the least taken to the North America translation for the node using the correct path: http://example.com/my-node.

Up until now, I had been fairly calm and the process had been, for lack of a better word, painless. But the pain had just started. I began to research/search/scour the web in hopes of finding a similar situation and solution. Unfortunately, the only “solution” I found was to use the “i18n Menu Translation” module, which essentially requires you to duplicate EVERY menu item, child-item, etc… Now, I’m furious. Really, Drupal? While going the “Menu Translation” route may work for a site with a simple one-level main menu, the menu in this project was about three levels deep, not to mention that on some of the Panel pages, we were displaying menu segments that were path specific. Just as I was about to throw my hands in the air and surrender/purchase Joomla stock/apply for a job at In-N-Out Burger, I stumbled across a magical module called Entity Translation!

Entity Translation FTW!

The difference between the “Entity Translation” module and d7′s core “Content Translation” module is that the former does NOT create additional nodes for translations, it translates on a field-able entity level. Now, this made much more sense to me. I would have one node with translated fields as opposed to two separate nodes with the “Content Translation” module.

It was during this process that I also discovered the “Path Translation” module, part of the i18n collection.

Winning Combo: Entity Translation + i18n Path Translation

After countless hours, I had finally found my winning solution. With both the “Entity Translation” and “i18n Path Translation” modules enabled, I changed the “Multilingual” support section of my content type to “Enabled with field translation.” I cleared my Drupal cache, refresh, and… boom! A single menu item per node regardless of how many translations it has. Translated content is displayed based on the URL’s path prefix, and correct path aliases are used. Success, I can mark my Bugzilla ticket as completed, sell my Joomla stock and politely decline my employment offer from In-N-Out!

While I am no expert on creating Multilingual Drupal 7 sites, I don’t understand why/when one would use “Content Translation” over “Entity Translation.” The whole concept of translating on an entity level rather than a node level just made more sense to me. I cannot see any benefit of creating an entirely new node just for a translation.

I hope somebody finds this post useful as I wish it existed when I first started on this task. For more on our thoughts about Drupal, check out our Drupal page.

The keyboard and mouse are no longer the predominant input tools, and we have gone from designing for three major desktop browsers to a myriad of devices ranging from touch-based tablets and phones; smartphones with tiny keyboards; video game controllers and television remotes. In the near future, high-resolution tablets and computer displays will be on the market, and this change will require that pixel-based web design be completely rethought.

Over the past two years, our clients have requested sites built for specific devices—a “main” site for desktops, a “mobile” version with a specific design intended for smartphones, and more recently an “iPad” version—which is really a simplified version of their desktop site. As you can imagine, this strategy introduces a lot of management complexity and cost into the web design and content management process.

Fortunately, there is is a solution. The recent adoption of HTML5 and CSS3 by browser makers, in addition to some JavaScript-based fallback methods, have introduced what some consider to be the holy grail of inter-device design compatibility: responsive design.

Responsive Design: One Site Fits All (Devices)

Simply put, responsive design is a flexible, device-independent technique that allows a single site layout to automatically “shift and adapt” to any size of browser window on any device, at any screen resolution.

In other words, your site’s design layout will readjust to best fit the screen on which it is being viewed. This is accomplished by shifting the location of navigation and content on the page, adding or removing content, and increasing or decreasing image and font sizes so the site automatically provides the best layout for any screen.

Responsive design isn’t a single technology; it represents a radically different strategic design approach and development workflow. We believe it to be so beneficial that we are often recommending that many of our clients consider responsive design for their content-managed sites.

These are some of the benefits that responsive design offers:

• Adapts your site to a specific range of devices without needing to create a separate device-specific site, or without having to change your content.
• Works in every browser, with native support from IE 9 (which is now being actively pushed to users by Microsoft), Firefox, Chrome, Safari, and via JavaScript-based fallback support for IE 6, 7 and 8.
• Is a process that is compatible with content management systems.
• It is significantly less expensive to maintain and deploy than developing and maintaining separate device-specific versions of your site (even if it does initially require more planning and work than a simple desktop site).

Now that you know what responsive design is, it’s time to learn how to drive implementation within your organization. After the holidays, I’ll discuss drawbacks, introduce you to the responsive design workflow and introduce a strategy for integrating responsive design into your existing sites.

This post will be updated with links to the subsequent articles.

Mobile Payments Accelerate

Wallet? What wallet? I have my phone.

There is no doubt the penetration of smartphones has changed the way we communicate, inform and entertain each other. Mobile devices have also changed the way we shop—helping us locate, evaluate and recommend every kind of product or services imaginable, but we still have to pull out the plastic (yeah, some still carry cash) to transact… Well, that final frontier of the commerce experience is also changing, and fast.

The first step has been the easy one. With the proliferation of mobile browsers, e-commerce purveyors have been releasing mobile-friendly sites to attract customers on the go and help them make the final purchase on their devices. Some firms—like BestBuy—have mobile versions of their sites, while others—such as eBay and Amazon—offer mobile web apps and fully native mobile applications. During the next year, you can expect to see every company that is serious about their e-commerce presence, launch or improve their mobile offering.

The next step, which offers the biggest benefit to most consumers, is mobile payment at retail. Whether shopping at a large retailer, a boutique, the farmers’ market or dining at your favorite restaurant, the POS terminal is becoming your phone. While mobile payments at retail have experienced slower adoption in the US, we expect to see dramatic growth in the coming year. In fact, it has already begun.

• The major players in the both the tech and banking industries have been fast at work to create systems that allow consumers to use their phones for payments. PayPal and Google (in conjunction with CitiCards and MasterCard) are offering services today; and we can expect American Express, VISA and others to release new mobile payment offerings soon.
• Less than a year after Starbucks launched an app that allows customer to pay with their phone, the company had hosted 26 million mobile transactions on iOS, BlackBerry and Android.
• During the recent Black Friday annual shopping bonanza, PayPal announced a 516% increase in mobile payments.
• GSI Commerce, a company that manages the online sales and fulfillment for many retailers, announced an increase of 254%.
• Gartner forecasted a global increase in mobile payment volume of 76% to $86 billion with much of the growth coming from North America.
• Each of the top smartphone developers (sans the one most are waiting on) have smartphones that include Near Field Communications (NFC, a wireless technology that provides data transfer between devices in close proximity such as less that 10 centimeters).

Contextual Services Find Their Way

Behavioral tracking, targeted marketing and more… oh joy!

With the proliferation of mobile Internet-enabled devices, we’ve become accustomed to instant access to information no matter where we are. The problem is that we often have to proactively search for this information.

Enter Contextual Services—the ability for your mobile device to be “aware” of the context around you and behave differently as your environment changes. In the next year, we believe it will become commonplace for your device to proactively change settings and notify you of relevant information based on your location and needs. For example,

• If you’re near an electronics store, you’ll automatically get coupons for the HDTV you were researching last night.
• You’ll be able to transfer information between your computer screen to your tablet, simply by placing the devices in proximity to each other and gesturing.
• As you walk into the cleverly named conference room, your phone will automatically silence itself and pull up the online meeting information from your calendar.

The mobile device is one of the few electronics that is typically a single-owner object. Therefore, as your mobile device becomes more integrated in your daily routine, the more personally relevant contextual results you’ll receive. We expect to see personally relevant contextual services emerge in a convergence between mobile advertising, advanced artificial intelligence (such as Apple’s Siri), gaming, shopping, directory assistance and opportunity discovery.

Contextual services are already blazing trails in the marketplace. Gartner estimates contextual awareness will be a “$12 billion market by 2012“. Startups like Urban Airship and hipui are building advanced tools to help your business take advantage of contextual awareness. Apple already uses contextual awareness in their stores to help associates spot customers in need of assistance. Nokia is experimenting with highly personalized contextual awareness via Nokia Situations.

Mobile Website As Apps

The lines between mobile websites and apps are blurring.

Mobile apps are now a high priority for our clients, which is no surprise given that Morgan Stanley expects mobile Internet usage to surpass desktop Internet usage by 2014. Deploying a best in class mobile solution used to mean writing separate native applications for iOS, Android, BlackBerry, Windows Phone 7 and others. But in the past year, that’s all changed.

Recent advances in JavaScript libraries—such as jQuery Mobile and Sencha Touch—combined with near-universal support for HTML5 and CSS3 make cross-platform, best-in-class web applications a viable option over traditional native applications. We are counseling our clients to keep a keen eye on web apps because they provide several key advantages:

• Web apps are often significantly less costly to develop and maintain
• Users can place a web app icon on the home screen, and the app will behave similarly to a native app
• Unlike native apps, separate web apps do not need to be developed for individual platforms
• There are no app store or marketplace restrictions on content or functionality
• The burden to install and manually upgrade the app no longer falls on the user

The Financial Times made a bold move this past year and eschewed the native app in favor of a sophisticated web application to deliver their daily news content. Their primary motivation was to avoid Apple’s 30% in-app subscription tax, but they also reaped the benefits of lower maintenance costs and instant feature releases. Amazon brought their popular Kindle reading platform to Safari for the iPad with Kindle Cloud Reader, with promises to support more mobile browsers shortly. Google has also put a strong emphasis on mobile web apps for all of their major products, with best in class offerings for Search, Google+, Picassa, Gmail, Google Docs and YouTube.

Certainly, there are still cases where a native app might make more sense than a web app, particularly in areas where rich business logic, advanced graphics or visualization is required. But for most information consumption scenarios, we predict that web apps will become the de facto choice for deployment.

From all of us at ThoughtMatrix, we wish you a very Happy Holiday and anticipate connecting with you again in the New Year.