Search engines put these rules in place early on to combat the number of spammers out there and create a more user-friendly experience by increasing the quality of the search result. Since search engines know it is generally in human nature to lie, cheat and steal, they started penalizing those for doing the same with SEO and “black hat” tactics.

What are black hat tactics, and how do you avoid them?

In SEO, black hat tactics are used to get a website to rank higher on the search engine result page (SERP) that do not follow the rules search engines have put into place. These tactics are in no way illegal, but do pose the threat to be penalized by the search engine. Examples of such tactics include:

1. Cloaking: hiding your website, keywords, links or images from the search engine spider or user
2. Link buying: attaining or purchasing links from lower quality websites or link farms just to bring up your link count
3. Keyword stuffing: using keywords in your content unnaturally and excessively

Black hat tactics aren’t just unethical; they can also cause search engines to remove your website completely from their index, just ask J.C. Penny. That means even if someone searches for your website by name, you will not rank. It is reversible, but it takes a lot of time to remove all the penalties from your site.

So how do you avoid black hat tactics? Well, it’s quite simple really—only use tactics considered to be white hat. White hat tactics are used in SEO to influence ranking by improving internal and external factors on your website. The search engine will never penalize you if you are white hat, and it will help to improve your website, rankings and content. Examples of white hat tactics include:

1. Link magnets: create quality content people want to link to instead of buying links
2. Stemming keywords: use keywords naturally in your content and variations of those keywords when appropriate (manage, managing, management)
3. Constantly add new content: search engines will reward you for frequently updating your site with fresh content that is useful to your visitors

Remember to follow the rules set in place by search engines to avoid penalties, and your site will have a better chance at ranking for the keywords for which you are optimizing. Whether you are doing your own SEO or hiring a company to do if for you, remember to ask what types of tactics they use and always stay away from black hat!

Fortunately for all of us, the lack of really great native app prototyping tools has not gone unnoticed and coming May 1st is a revolutionary tool in creating functional prototypes of native applications for rapid iteration. Rather than bore you with a bunch of long-winded explanations in words on why this technology is so cool, I think the demo video the team behind it cooked up does a better job than I ever could in showing just how groundbreaking this really is.

Introducing Briefs

This is not a flash-in-the-pan either. Briefs is a serious, multi-year labor of love by its creator after running into challenges with the previous version and Apple’s review process. This new iteration—humorously dubbed “Briefs 2″—completes the vision Rob Rhyne set out on years ago, and we look forward to adding it to our arsenal when it is released.

1. Create a completely new authentication system
2. Utilize the existing Salesforce portal authentication system

The first option would would involve developing a new authentication system and require our client to create thousands of new credentials to roll out to partners. The resulting cost and disruption to the business made this option very unattractive to say the least. Thus, utilizing the existing Salesforce portal authentication system was the only practical way to proceed. Several strategies were evaluated for implementation; however, the best solution was to leverage the functionality provided by the Salesforce SOAP API for authentication. This approach offered two highly desirable features:

1. No new authentication system was required, as Salesforce would conduct the actual authentication
2. Users could retain their existing credentials, making the transition to the new portal seamless

The Salesforce SOAP API provides a toolkit enabling developers to build applications that interact with Salesforce.com in various ways. For example, a client can develop an application on their server, connect to Salesforce to extract leads or contact data, manipulate the data and present it on a custom-written web page. These types of applications—similar to our authentication solution—are hosted on a client’s server, not on Salesforce.com. In addition, the flexibility seems virtually endless; applications can be built in Java or C#, can be based on example code from Salesforce and code can be translated to PHP if desired—although not without some effort as Salesforce generally only provides sample code for Java and C#.

Sample Implementation

The overall architecture of our client solution is shown below, with the relationship between the remote site and Salesforce.com (SFDC).

Architecture of Client Solution with SFDC Authentication

1. User logs into the remote site; login credentials are passed to custom Java app
2. Java app makes login request to SFDC Web Services using the SOAP API
3. SFDC Web Services issues a response with session ID if user if successfully authenticated
4. Custom app redirects to a landing page and displays a “login success” message
5. Custom app seamlessly redirects user to an SFDC page (optional)

By utilizing SFDC authentication in this way, users have valid session IDs that can be used to seamlessly redirect to pages on Salesforce.com without the need to log in again. This, in effect, becomes a single sign-on (SSO) solution for the remote site and Salesforce.com, although limited to a one-way path from the remote site to Salesforce. Engineers always appreciate a well-designed system and I have to say the Salesforce technical team did an excellent job in developing the SOAP API. However, the documentation for the API is a bit sparse and generally assumes the reader already has a good grasp on the workings of the system. To help you, I describe the fundamental steps to developing an application that will utilize the SOAP API for authentication a bit further below.

Setting Up the Toolkit

The basic requirements for a development environment are:

• Java 6—must be available in the development environment
• J2EE application server, such as Tomcat—you can use Java 7 with Tomcat, if desired
• Java development tool, such as Eclipse
• SFDC account for testing and administration—Salesforce will provide a developer account for free, which will work fine
• Appropriate WSDL file for your organization
• Salesforce Web Service Connector (WSC) toolkit

The SOAP API toolkit is not available as a binary download—you have to generate it yourself, based on your organization’s SFDC Web Service Definition Language (WSDL) file. The WSDL essentially defines all of the API calls and data fields available for your organization. The details of the WSDL may vary between different organizations, as they may have access to different services. They can also define “custom fields” that appear in the underlying SFDC database. Hence, each organization’s WSDL is potentially unique, and the API toolkit must be built for a specific WSDL. If you sign up for the free developer account, your “organization” will just be you. Your organization’s WSDL is available in Salesforce.com and can be obtained as follows:

1. Log in to Salesforce—this may be SFDC, the “sandbox” test.salesforce.com site or developer.salesforce.com
2. In the top right corner of the home page, click the down arrow next to your name and choose “Setup”
3. From the menu on the left side of the page, under “App Setup”, click the down arrow next to “Develop”, then click “API”
4. On the “API WSDL” page, click “Generate Enterprise WSDL”—you should then see a page of XML, save the XML in a file on your local machine and name it something like “enterprise.wsdl”

The Salesforce WSC toolkit is used to generate a JAR file containing all the classes and methods your custom application will require. You can obtain the Salesforce WSC toolkit from http://code.google.com/p/sfdc-wsc/downloads/list. At the time of writing, the latest version of the WSC is “wsc-22.jar”. Now is where Java 6 is needed because the “wsc-22-jdk-1.7.jar” file on the Google Code page appears unable to generate the desired JAR file when executed under Java 7. Once the JAR is created, it may be deployed in Tomcat running under Java 7, but it must be initially built using Java 6. For Windows users, it is quite easy to have two different JDKs installed on the same machine. For Mac users, this can be a little problematic as a recent OSX update removed the “Java Preferences” utility that enabled different versions of the JDK to be swapped in and out. Although my Mac has Java 7 installed, I found Java 6 was still present in the folder “/System/Library/Frameworks/JavaVM.framework/Home/bin/java”. This can be tested in a command window as follows:

mymac$ /System/Library/Frameworks/JavaVM.framework/Home/bin/java -version

The system should respond with something like:

java version “1.6.0_37″ Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)

Assuming you are able to get access to Java 6 and the WSDL file is named “enterprise.wsdl”, the command to generate the JAR file is:

/Java6 path/java -classpath wsc-22.jar com.sforce.ws.tools.wsdlc enterprise.wsdl enterprise.jar

After success completion of that step, you will have a file named “enterprise.jar”. Using your IDE of choice, create a web application and drop the JAR file into the WEB-INF/lib folder. The JAR file will contain various classes with methods that you can call to interact with Salesforce.com.

Using the SOAP API for Authentication

The pieces of data required for you to connect to SFDC include:

• Salesforce username and password for testing purposes (obtained from SFDC)
• Authorization endpoint
• Service endpoint

The latter two values are URLs containing the server you will use for authentication and the appropriate version of the API. The appropriate server name for your circumstance can be determined by logging into the relevant Salesforce account—developer, test or production—and noting the URL to which you are redirected. For example, my developer login is redirected to “https://na9.salesforce.com/…”. The current version of the API is 26, so the authorization and service endpoint URLs—in my case—are both going to be “https://na9.salesforce.com/services/Soap/c/26.0″. We now have everything we need to write an application to interact with SFDC. Let’s look at the basic skeleton code to do a simple login authentication.

//Do some imports from our enterprise .jar file. 
import com.sforce.soap.enterprise.Connector; 
import com.sforce.soap.enterprise.EnterpriseConnection; 
import com.sforce.soap.enterpriseGetUserInfoResult; 
import com.sforce.ws.ConnectionException;
import com.sforce.ws.ConnectorConfig;

public class SFDCAuthenticator {
     public ProfileObject doLogin (String username, String password) {
          EnterpriseConnection connection;
          ProfileObject profileObject = new ProfileObject();
          ConnectorConfig config = new ConnectorConfig();
          config.setUsername(ussername);
          config.setPassword(password);
          try {
             config.setAuthEndpoint
               ("https://na9.salesforce.com/services/Soap/c/26.0");
             config.setServiceEndpoint
               ("https://na9.salesforce.com/services/Soap/c/26.0"); 

            //Create a new connection
            connection = Connector.newConnection (config);
            System.out.println("Yay! Login successful!");
            profileObject.setStatus(true);
            profileObject.setSessionId(config.getSessionId());
            profileObject.setServerUrl(config.getServiceEndpoint());

            //Do something else here
        }
        catch (ConnectionException ce) {
           System.out.println("Failed to connect or login");
           ce.printStackTrack();
           profileObject.setStatus(false);
        }
        catch (Exception e) {
           System.out.println("Something bad happened");
           e.printStackTrace();
           profileObject.setStatus(false);
        }
        return profileObject;
    }
}

This class takes a username, password, authorization endpoint and service endpoint, and sets values in a ConnectorConfig object. When we create the new connection, the login is performed by the API toolkit. We could have simply returned a boolean value of “true or false” to indicate login success or failure, but we would usually want to build a user profile and return that to the method’s caller. There is nothing special about the “ProfileObject class; it’s a Java bean I created with string members to store the user data.

Now, let’s consider some things we might like to do under the “Do something else here” comment in the above example.

//Obtain some details about the user from the GetUserInfoResult object
GetUserInfoResult userInfo = connection.getUserInfo();
profileObject.setLanguage(userInfo.getUserLanguage());
profileObject.setTimeZone(userInfo.getUserTimeZone());

//Obtain information about the user's login session
profileObject.setValidTime(userInfo.getSessionSecondsValid());

For a complete description of the SFDC API functionality, refer to the “SOAP API Developer’s Guide” at http://www.salesforce.com/us/developer/docs/api/index.htm

The API toolkit also provides access to the SFDC database, along with the “Salesforce Object Query Language” (SOQL) that behaves mostly like SQL. A developer can perform SQL-like queries against the database as well as retrieve the results using the toolkit objects and methods.

Returning to the code example, you may have noticed two lines in the section where we created the connection:

profileObject.setSessionID(config.getSessionID());
profileObject.setServerURL(config.getServiceEndpoint());;

The session ID and the service endpoint can be used to add functionality that gives some polish to the authentication system. There are two basic features we should add:

1. Session refresh
2. Logout

The “session refresh” functionality is particularly important in our situation. Looking back at the overview diagram, the authentication request is initiated by our remote web site. This site will presumably have plenty of interesting resources to keep users engaged after they’re logged in; however, the authentication functionality is provided by services on Salesforce.com. In a typical use case, a user logs into our site, is authenticated via Salesforce and then proceeds to surf around. Meanwhile, the Salesforce server doesn’t receive any indication of the user being active. When the session timer expires. Salesforce terminates the session; this goes unnoticed by our portal until the user attempts a “seamless redirect” to Salesforce or accesses some Salesforce data and is then confronted by a login page again. Hence, our site must be able to keep the session alive as long as our user is active.

The code to perform the refresh is similar to the login example above, except the required parameters are not username and password—to refresh the session, input the session ID and the service endpoint URL. This is why those values were obtained from the ConnectorConfig object after the connection was made; they were stored in the profile object and returned to the calling application so the site could make use of them for this purpose. Here is a code sample, abbreviated to include only the essential statements:

public boolean doRefresh (String sessionId, String serverURL) {
     EnterpriseConnection connection;
     try {
          ConnectorConfig config = new ConnectorConfig();
          config.setSessionId(sessionId);
          config.setServiceEndpoint(serverUrl);
          connection = Connector.newConnection(config);
          return true;
          }
          catch (ConnectionException ce) {
               return false;
          }
}

In order to refresh the session, take the session ID and server URL, set them in a ConnectorConfig object and then make a method call for a new connection. This will not create a new session ID, but will revitalize the old one and set the session countdown back to the default value—determined by your Salesforce account settings. You cannot refresh a session that has already expired, so you will need to call this method at regular intervals.

The logout functionality is similar to the refresh; however, it calls a special method to invalidate the session. After this is performed, the session ID will no longer be valid and the user is logged out by SFDC. Our site will need to keep track of the user’s login status, making sure we don’t allow access to the site when the SFDC session is no longer active. Here is an abbreviated logout code sample:

public boolean doLogout (String sessionId, String serverURL) {
     EnterpriseConnection connection;
     try {
          String{} sessionIds = new String[1];
          sessionIds[0] = session Id;
          ConnectorConfig config = new ConnectorConfig();
          config.setSessionId(sessionId);
          config.setServiceEndpoint(serverUrl);
          connection = Connector.newConnection(config);
          connection.invalidateSessions(sessionIds);
          return (true);
     }
     catch (ConnectionException ce) {
          return (false);
     }
}

The doLogout method uses the session ID and server URL to create a new connect, then calls the “invalidateSessions” method to destroy the session. It may seem odd to effectively perform a “refresh” operation on the session and then destroy it, but it’s because we’re twisting the original purpose of this part of the toolkit for our web-based remote site. These methods are better suited for “batch” modes, where a program creates a user session, performs some data extraction operations then destroys the session without user intervention.

The Salesforce SOAP API toolkit takes a bit of effort to set up. That being said, it offers a vast array of features and functionality, and the authentication system described here is just one potential use of the toolkit—perhaps one which will whet your appetite for more exploration!

]]> http://www.netwhisperer.com/2013/04/26/using-salesforce-for-authentication/feed/ 0 http://www.netwhisperer.com/2013/04/25/linkedin-html5-mobile-app-development/ http://www.netwhisperer.com/2013/04/25/linkedin-html5-mobile-app-development/#comments Thu, 25 Apr 2013 15:36:28 +0000 John Tumminaro http://www.netwhisperer.com/?p=2164 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.

I take some satisfaction in having recognized this trend early having given up most hybrid development two years ago, but not for the usual ideological reasons most people cite. Rather, I knew very well we heard the same “write-once run-anywhere” promise from Java apps in the late 90s…how did that work out again?

Server applications—one area where Java has been very successful—are a different ballgame entirely, but consumer apps live or die based on their UI and how well executed it is. And like it or not, when you design a cross platform UI you really have three choices:

1. Build a custom UI framework to standardize across platforms. Forget it, pretty much only Adobe does this or can afford to. Sure, games get away with it, but games have very few actual UI components—3D engines are extremely advanced and completely different than a text field or navigation bar. This produces good results in only very select situations where you want someone trained in a complex program—like Solidworks, Maya or Photoshop—to be able to work on any platform and not worry about the underlying OS.
2. Use a third-party cross-platform library. This sounds like a decent option except that universally it not been very successful, especially on mobile. Things like Qt and Adobe Air have their place, but in consumer apps—where you need to deliver the most cutting-edge features in the best presentation possible—you are always going to be catering to the lowest common denominator.
3. Leverage HTML5/JS frameworks, like Sencha Touch and jQuery Mobile. These are both excellent choices for web apps and lower budget projects that need a large footprint at low cost, but they can’t compete with apps that are custom built for the platform and tuned by a seasoned developer who knows how to maximize the capabilities of the platform they are working on.

LinkedIn eventually gave up, but not without a valiant effort and certainly quite an investment—from contributing their best engineering talent to trying to drum up industry support even after Facebook threw in the towel. There are many reasons why native is a better solution, but this is a pretty common refrain. Developers are abandoning Cordova for medium to high-end development in droves, much like the sputtering of Java Desktop apps that landed with a thud and then retreated never to be heard from again.

What’s this mean for you and your business? Find good mobile developers with specialization in a platform and treat them well—they are perhaps the single most important variable in you being able to realize a successful mobile product.

No matter how you looked at it, the salesperson was responsible for capturing a potential customer early in their buying cycle and moving them through the proverbial funnel. Every company and executive sales leader subscribed to some sort of sales and marketing funnel.

This was the “Holy Grail.” I used to sit through, and even conduct, funnel management meetings dissecting how each customer was moving through, or out of, the funnel and devising strategies to address those that were not. Was this an accurate assessment of how purchase decisions were made? I am not so sure it was then, but it certainly is not today.

Traditional funnels assume an unrealistic linear flow

Customers just don’t move methodically through five to seven steps, checking off each item and making a purchase decision. They move back and forth, up and down. Consider the last time you made a significant purchase. Chances are you researched options online—should I buy a sedan, wagon or dreaded minivan, for example—then talked with friends, or colleagues, who have already purchased something similar. Then armed with new knowledge, back online you went but this time on your smartphone while killing time in line at the market. You may have also read some new media reviews. Back and forth, up and down. It’s highly likely that along the way, you saw the same company get the best ratings, coverage and more. Whether overt or subtle, your needs were slowly shaped. Then, once you felt confident you knew as much as you could without talking to a salesperson, you finally engaged with one to either negotiate the deal—but you were already “sold”—or get your final elusive questions answered.

Let’s face it, since the dawn of time salespeople were the gateway to information. Sure, customers could reach out to industry analysts and others for their opinions, but that was and still is costly and time consuming. Even still, they could only acquire limited information about a company and its products and services, and ultimately they would need to talk to a salesperson.

That was then, and this is now. Regardless of whose numbers you believe—a recent study by Google and the CEB puts it at 57%—the majority of the sales process begins well before the customer engages with a salesperson. Sure, there are those lucky times when a customer is just sitting in their office waiting for a salesperson to enlighten them on how their business could be transformed with their product, and they weren’t even thinking about such a product or service, but…well you get it.

(SOURCE: CEB Marketing Leadership Council 2012 Customer Purchase Decision-Making Survey)

In today’s connected world, content in every form is available to prospective customers, and they use it. Whether you provide content or it comes from your competitors, media, analysts or the myriad of pundits that create content—biased or not—continuously, your target customers are consuming it.

So the question is what are you doing about it? If a large percentage of the decision is made before your salespeople are really engaged, what is a sales and marketing organization to do? I would submit there are three things every marketing-driven organization must be doing and refining.

Commit to becoming a content driven organization.

While prospective customers are not interested in talking with your salespeople on day one—or day 75 for that matter—they are interested in your expert knowledge. In both B2B and B2C transactions, there’s a learning process and that’s the first opportunity to begin shaping their opinions in your favor. Even though your prospective customer’s journey is not linear, it does exist and they do consume content throughout the journey. Your job is to continually create content to help inform them along the way.

Take it personally and make it personal.

It’s a dialogue, not a monologue. While it’s not feasible to have one-on-one conversations—and of course, as I’ve mentioned they don’t want to—they still want information as relevant to them as possible. It’s no longer sufficient to create one size fits all experiences and hope for the best. Each engagement from campaign responses to search is creating an invaluable trail of individualized information. Capture it, and harness it. Create dynamically driven content for each customer, or at least each customer segment or persona.

Syndicate everywhere.

Sure, mobile can no longer be ignored, but it’s much bigger than devices and browser sizes. Customers rely on different sites, forums, communities and even offline to shape their opinions. Each of these touch points is an opportunity. Continually monitor and measure as many touch points as you can, and create content that is touch point appropriate and engage in mutually beneficial dialogue.

While the customer may be bouncing around the so-called funnel like BBs in a boxcar, there’s a great opportunity for your brand to be where they land each time. Being there with relevant, informative content is your best opportunity to help customers qualify themselves and make your sales force as efficient as possible.

New Features

Personal Information Center - Activities and Tasks

The Personal Information Center—located at the top right on the CME interface—is a new feature that allows Activities and Tasks to go through the workflow process. You can also kick off a workflow without an actual item associated with it.

Bundles

This is a new concept altogether and a new Schema type. The CMS  is basically allowing you to group a bunch of related components, pages and such to create a bundle. An example/use case would be the grouping of all the related items for a release (e.g., you can use this for workflow or publishing). In addition, this new functionality allows you to place a bundle inside bundle.

Bundle in a Workflow

Add Item to a Bundle

Other Improvements

Other improved functional areas include:

• Experience Manager UI, Ambient Visitor Intelligence and Footprint Preview
• Built-in Device Preview Capability
• Multi-item Workflow and the Task Workflow
• Translation for Metadata of Multimedia Assets

Architecture Changes

The 2013 version now boasts a fully consolidated .NET architecture on the CME side. All the legacy items that uses VB6, COM+ have been removed from the default installation. If there is a specific need for these they are made available as a ‘Legacy apps Install’.

The Power Shell support on the CME has been improved, as now all Tridion databases can be installed by running scripts thru the Power Shell. In addition, XSLT Mediator is now part of the core product.

External Content Libraries (ECL)

The Undo Publishing feature provide the ability to undo an item based on its publish transaction ID. The Content Manager API now enables you to undo a publish transaction. Its main purpose is for use in the Automatic Activities in Workflow Process. This will require a little bit of configuration on the CD side, but otherwise it’s quite nice.

Other Improvements

Other improved technical areas include:

• Session preview
• Core Services API 2013
• Read and Write public .NET API

All these upgrades makes the Tridion CMS super fun to work with (both functional and technical alike). A big congratulations to the SDL team for all the new goodies! Exciting stuff.

Instagram: Mihai & Alvin @ SDL Bootcamp

In this post, I’m going to examine some of the existing technologies for cross-platform development of mobile apps, with an emphasis on determining when they might be appropriate for an app or business and when they might not.

What’s out there…

What are the available cross-platform tools (CPTs)?

There are many—at least 100+—of these CPTs in today’s market, though we only typically hear of a few. Those with the most usage include:

• Adobe PhoneGap
• Sencha Touch
• Mono
• Appcelerator Titanium
• Unity
• Corona
• AppMobi
• RunRev
• MoSync

The most prominent of the bunch and the ones I’m most familiar with are:

PhoneGap

PhoneGap uses HTML5 inside of a WebView on your device. It essentially creates a mobile “web app” that sits inside a native application wrapper. The web code is packaged with a library that bridges web code to native functionality. PhoneGap is open source (free) and supports iOS, Android, BlackBerry (not yet 10), WebOS, Windows Phone 7, Symbian and Bada.

PhoneGap developers report advantages—such as low barrier to entry (HTML/JavaScript/CSS is the only skill needed to get started), a single code base for all platforms and rapid testing and deployment. Reported disadvantages include poor performance—there’s only so much you can get out of a WebView on any platform—and lack of support for native UI elements and widgets. Reports indicate graphically-intensive applications are not a good fit for PhoneGap.

Appcelerator Titanium

Titanium is similar to PhoneGap (it’s free), but not exactly the same. The main difference lies in device support—it’s built to produce iOS, Android and web apps only. It actually compiles the JavaScript code into a native binary—converting the JavaScript into native class and object files—whereas PhoneGap simply renders a WebView with the code being interpreted inside.

“So, a simple way to think about it is that your JS code is compiled almost one-to-one into the representative symbols in nativeland. There’s still an interpreter running in interpreted mode, otherwise things like dynamic code wouldn’t work. However, it’s much faster, much more compact and it’s about as close to pure native mapping as you can get,” states Jeff Haynie, CEO of Appcelerator.

Proponents of Titanium argue performance is not an issue because the app is compiled as a native app. They say using native UI elements—as opposed to PhoneGap, which creates its own—allows apps to more closely resemble the look and feel of a native app. This is probably as close as you can get to having a CPT app resemble an actual native app.

Unity

Unity focuses on gaming on other graphically-intensive applications. It currently supports Windows, Mac, Unity Web Player, iOS, Android, Nintendo, Wii, PlayStation 3 and Xbox 360, with upcoming support for Adobe Flash Player, Linux, Windows 8, Windows Phone 8 and Nintendo Wii U. It is essentially the industry standard for game development.

Unity provides a development environment with which graphics, physics and sound can be programmed. According to its Wikipedia article, “Game scripting comes via Mono. Scripting is built on Mono, the open source implementation of the .NET framework. Programmers can use UnityScript (a custom language with ECMAScript-inspired syntax), C# or Boo (which has a Python-inspired syntax).”

The downside of Unity is that it tends to be expensive by comparison particularly when you add in the cost of plug ins used to build on multiple platforms. However, Unity is as close as you will see to an industry standard, so clearly someone feels the cost is worth it.

When Considering a Cross-Platform Tool

Here are a few things to take into account when considering whether to use a CPT:

Design

There are design differences among mobile platforms—iPhone: the tabs go on the bottom, Android: the tabs are on top, Windows 8: everything scrolls horizontally. Custom icons are made at different sizes, and there are multiple screen resolutions and aspect ratios to consider as well as multiple screen densities and image sizes to account for. What if an app’s requirements include the need to perfectly fit an iPad screen right up to the edges, support the iPhone—including retina and non-retina graphics—and must also fit perfectly on a Samsung Galaxy smartphone and tablet of varying sizes and ratios? The designer for that app needs to be skilled in both iPhone and Android design, and the designs could conceivably be different enough to warrant two completely separate code streams.

Technical Limitations—Playing “Catch Up”

Each cross-platform solution can logically only ever support a subset of the functionality included in each native platform. When new features come out, developers must wait until the CPT developers have a chance to incorporate them into the API. Without the control of being able to incorporate new capabilities as soon as they’re introduced into each native platform, you run the risk of major lost opportunity (e.g., being first to use a new feature is far more compelling than becoming a “me too” app). In addition, there’s a decent chance certain required functionality will require the development of “plug-ins” for each platform, which can become an unanticipated, costly and time-consuming part of the project. The only surefire way to ensure an apps is built within the appropriate, and most efficient, technological parameters is to build it natively.

Risk

What if Apple stops accepting PhoneGap apps? What if an app’s requirements change, and now PhoneGap or Titanium won’t work? How hard will it be to “port” the CPT code into a native app? These are all questions you need to ask to assess the risk associated with using any CPT before embarking any project.

Further, you might hire a team of developers to create an app using a CPT; halfway through the project timeline, you may realize there’s a significant piece of functionality that requires native code or plug-ins—which you thought, due to the marketing materials, was supported by the tool you’re using. Now, you need to hire an iOS or Android expert in order to keep the project moving forward. The time spent hiring, designing and coding around the issue could turn out to be very costly.

These are very real considerations. At the same time, the advantages of cost savings and time to market when using CPTs can also be very real. That’s why these decisions should not be made lightly.

Scenarios to Consider

What are some real world examples of times when it might be appropriate to use CPT’s and which ones might be appropriate?

Online Store

A retailer of online widgets wishes to create a mobile app. They want to have a presence on as many platforms as possible—including iOS, Android, Windows Phone and BlackBerry. The app is not deemed to be graphically-intensive, and the initial design wireframes require a conventional mobile app layout. The design is similar—though responsive—whether viewed on a phone or a tablet.

This is the sort of app for which I would consider a platform such as PhoneGap or Titanium. The decision between the two would likely be based on the question, “Just how much do you want to support devices other than iOS and Android?” If the answer is “we really want to support other device types,” then PhoneGap wins. Otherwise, the improved performance and “native” compiling of Titanium would win out.

Social Networking App with Lots of Cool Features

A fresh new startup wants to create a social networking app that incorporates location-based functionality, camera usage, some cool graphical animations and sound interactions. The app should also be optimized for tablets where appropriate.

For this app, a careful approach must be taken. Location-based functionality is available in most CPTs, yet each OS truly has different ways of handling location accuracy and performance. Camera usage is included as a service in each CPT, yet if you want to bring advanced functionality—such as augmented reality or even take advantage of built-in editing features—the cross-platform approach might yield even more work than building separate versions.

Video Game—Two Scenarios

A mobile gaming company wants to make a video game for multiple mobile platforms. In one scenario, the company is small and doesn’t have a big budget for tools and software. It might be okay to use an open source, free framework—like cocos-2d or cocos-3d—to build the app on one platform and then port it to the other. I have personally ported a game created with cocos-2d for iPhone in only three days. Since the code is so similar, a straight port isn’t that hard. The downside, of course, is multiple code streams in multiple languages, which essentially makes for multiple products.

In a second scenario, the company is large enough to spend on equipment. In this case, I’d recommend they invest in Unity, which I mentioned earlier is the industry standard for game creation on multiple platforms and seems to be the perfect tool for the task.

Conclusions and Recommendations

In conclusion, when considering whether to use a CPT instead of native mobile development, some important deciding factors include:

• Platform requirements—which platforms must the app support and which platforms are considered “nice to haves”
• Technology requirements—which mobile device features must the app support and which are “nice to haves”
• Performance requirements—are there aspects of the conceptual apps where performance, especially graphical or computational, a consideration
• Design constraints—how disparate are the designs for different device types

If these parameters fall squarely within the capabilities of a particular CPT, then consider yourself one of the lucky ones and use that CPT. Otherwise, in my opinion, making the case for being risk-averse and using proven technologies with which each platform natively ships seems the least scary solution for those about to invest time and money on creating a mobile experience.

“Our content stays away from the hard sell,” said Bill Boland, Patagonia’s digital creative director. “But we are finding that our customers are interested in talking about our products.

In the content marketing biz remember that value is king. If your brand message is too overt it can easily siphon the value from content. Without value, a message is only as good as the first round of eyeballs it attracts. Your tentacles are short and enthusiasm is muted. Remember, if your content creates enthusiasm, your brand will benefit. I’ve never had a client come to me and say that they are producing great content and the readers are passionate and enthusiastic about the content but brand awareness is down. I’m sure the above happens, but it’s definitely the exception and is comparatively easy problem to solve. Stay in the right voice and talk about subjects that speak to brand values and your customers will get the association. You don’t have to beat them over the head with it.

Where's the sale? Where's the contest? Where's the special offer?

“We’re just trying to figure out operationally how we should be going about planning our content strategy. Currently, it’s very organic, and I’d like for it to get to a point where it’s more formalized, much like a newsroom is run. This way we know what’s coming, and we could even put together an editorial calendar. We need more structure.”

Make an investment in structure and resourcing. There is no simpler way to put it. The tools and methods are out there. The benefits are clear.

Patagonia also thumbs its nose at the current obsession with analytics. Boland thinks that if you allow the metrics to be your only guide, you’re setting yourself up for disaster. Instead, he preaches the long view.

At ThoughtMatrix, we love analytics. We love Key Performance Indicators. We love technology that draws relationships between different metrics and gives us new ways to visual data. Statistical analysis is a key component to the paradigm shift that digital media has produced. But, metrics are a guild to help you navigate. They have no intrinsic value. Great statistics don’t equal great value. Statistics help you quickly spot trends that you couldn’t see qualitatively. They don’t diminish or eliminate the value of qualitative analysis; they support the value of qualitative analysis. Pardon my sports metaphor, but there is nothing a coach in any sport hates more than a stat stuffer, someone who measures their achievement using statistics rather than victories.

Finally, if you want to see Patagonia’s web marketing strategy in its simplest form, visit their website www.patagonia.com. The front page consists of five hero images. They tell stories, they invoke emotion, they don’t sell. There is no mention of Patagonia’s spring line, no sales or contests. If the Patagonia lifestyle and story is engaging, the product will sell itself. Virtually every client I have could benefit from that philosophy.

Enter my two new favorite apps.

Feedly

I happened upon Feedly about a month ago—a beautifully designed, easy-to-use Google Reader app. The cool part is, since I already use Google Reader, the app pulled in all my content feeds. Even for those that aren’t Google Reader users, with a few clicks, you can have gorgeously displayed content that is visually represented with a photo or thumbnail, no ads and tons of content to flick through. Some articles are truncated so you have to finish them on the originating site, but that is to be expected and altogether reasonable.

Another nice thing about Feedly is that if you use Google Reader on your computer, feedly.com is a great way to use your Google Reader account.

Flipboard

The second app—which is very similar—is Flipboard. This works on mainly the same premise— you pick a few things to get served to you, but the ultimate win of this app is that it pulls your Facebook and Twitter accounts into an integrated place where you can visually skim through posts, news and more in a beautifully designed user interface. CEO Mike McCue says, “Flipboard is on a quest to transform how people discover, view and share content by combining the beauty of and ease of print with the power of social media.”

Give em’ a shot!

Both offer suggested content, which is great for discovering new content that may not be on your radar. So if you’re not reading the news and other great content because it seems like more work on your smartphone than it should be, give one—or both of these apps—a try and let us know which you like more and why!

Feedly is available for: iOS and Android.

Flipboard is available for: iOS, Android, Kindle Fire and NOOK.

Time Savings

• Preparation — Because location isn’t an issue, the pool of potential test subjects is exponentially larger and the burden of participation generally much lower. We also find prep times can be cut by as much as 80%.
• Testing — Lab testing facilities can be very expensive to rent, or maintain, and generally aren’t designed to do simultaneous testing. Because remote testing is virtual and simultaneous it can shorten testing time from days to hours.
• Results — It stands to reason the faster you can test, the faster you can get results; most of the data points are reported in near real-time.

Money Savings

The adage “time is money” certainly holds true when it comes to usability testing. In our experience, remote testing costs about 10% of what lab testing costs.

• Remote Testing: $35–$50 per test
• Lab Testing: $500–$1,500 per test (does not include travel expenses)

When to Lab Test?

Based on the numbers alone, remote testing appears to be the way to go, particularly since the short timeline is appealing for agile development environments. However, there are situations where lab testing is still needed.

At ThoughtMatrix, we use a cause-and-effect diagram to help us decide which testing method to use. In the example below if we need to work with any of the parameters in blue, we generally recommend in-person testing.

Elements of Usability Testing

Causes that Require Lab Testing

User (People)

No Web Access
A good example of this is kiosk testing, which often allows for little or no Internet access. Remote testing is by definition web-based.

Interaction Type (Method)

Sensitive Information
Private information — such as medical or financial history — may require a controlled testing environment.

Intellectual Property
In some cases, the site may contain top secret content, where sharing information that could be screen captured may be an unacceptable risk.

Eye-tracking
Eye-tracking requires special equipment that is generally not available with remote testing sites.

Physical Movements
Testing that involves physical movements on a grander scale than swiping a touch screen, or tilting a tablet, are unlikely to be caught by remote cameras.

Specialized Application
Some applications need additional software, or specialized hardware, in order to work and are usually better suited to the lab.

Availability

Although just three or four years ago remote testing applications were few and far between, today there are testing apps for a variety of scenarios, needs and budgets. Below are some of the more popular options, but many more exist depending on what kind of testing you want to do.

• UserTesting
• Whatusersdo
• IntuitionHQ
• Usabilla
• TryMyUI
• Userlytics

With so many clear benefits and options in the marketplace, remote usability testing has become our preferred choice in most cases.

So remember, test early, test often and consider testing remotely.