Apple doesn’t give much guidance on this important chunk of text. “Write your Application Description with a focus on what makes the functionality or design of your app unique.” was a tip from this past June from the App Store Tips blog.

We know that 4000 characters is the limit.  And App descriptions are made up of simple text, including unicode symbols like checkboxes (✔) and more (♣☢☂).  Apple takes your unicode text and formats it for display on the web via Web Preview, in iTunes and on the iOS devices themselves (the app store).

Since you probably have very specific points you want to get across, and users have a very short attention span, you need to pay attention to how Apple will format what you write.  In this entry I discuss how to create app descriptions that look great everywhere Apple publishes your app description.

Word Wrap and the Fold

Word wrap occurs in app descriptions when enough characters fill up a line.  Each line has a maximum number of characters and when a word goes over that, it is bumped to the next line.  This is important because one word of word wrap can waste an entire line of potential ad copy.  This is important: the length of your lines in your app description affects the placement of the fold.

The fold is the point where iTunes, Web Preview or the iPad App Store app decide to make the user click or tap the More… button.  Everything below the fold is out of sight, out of mind.  Without the data to prove it, my hunch is that at least half the time, users are not bothering to click More… before deciding whether they are installing an app or not.

All this means is that you must use the space above the fold as effectively as possible.

All app purchase vectors limit the top of fold line display to three lines.  Two important rules here:

1. Blank lines count as lines.
2. Lines over 120 characters in length will lead to word wrap and the use of an additional line above the fold line.

App Description Formatting on iTunes and Web Preview

Web Preview and iTunes behave in a similar way, Web Preview is just that, a summary of your app description and screenshots along with a link to view the app in iTunes.  The final step on a computer is to have iTunes open to the page where the user clicks purchase to download the app.  A history of Web Preview and SEO implications may be found here.

Both iTunes and Web Preview show the same number of lines from your app description before the “break” point.  A break point is where all text is hidden below the fold, and the user must click the More… link to display the rest.

Let’s look at some examples. The following three shots were taken from Web Preview.  iTunes displays the same amount of information as Web Preview, however only Web Preview has fixed width.  Resize the iTunes app window, allows longer word-wrapping lines but ultimately the same amount of information above the fold as Web Preview.

Note: Click any images to see the full size.

Here the app publisher has chosen to highlight two specific sentences and put a line of space between them for readibility.  Note that if the first line was longer than 120 characters, top of fold would be a complete and a partial line (due to the wrap) and the third would simply be a blank space.

Here the app publisher has one long line of text with no carriage returns.  This means that all three allowable lines of text are the result of one word wrapped line.  This is the maximum amount of information you can cram into the top of fold, but it does not read very well here.  Wait until you see how ad copy like this looks in the iPhone’s App Store.  For your reference, this one line of text is about 343 characters in length.

Looking at the devices

Currently there are two different sizes in the iOS hardware family.  The long one, (iPhone and iPod Touch devices), and the wide one, (iPad devices).  In addition, there are three types of binaries, iPhone only apps, iPad only apps and Universal apps, which work on both iPhone (iPod Touch too) and iPad.

If your app is only for iPhone you need to focus on how it is displayed in the iPhone’s app store.  If it is only for iPad, you need to look at it there.  In either case you also need to look at how Apple’s relatively new Web Preview page displays your app description too.

App Description Formatting on the iPhone

Often users install apps directly on their device, rather than using iTunes and syncing a purchase.  It is certainly less clunky and you have instant satisfaction of getting to run the app right away.  That means your app description marketing copy should be influenced by how the lines of text look when displayed on each of these devices.

Here are some screenshots of how word wrapping of text affects readability on the iPhone App Store app.  Note that the iPhone app store app only supports portrait orientation.

Interestingly, a long line of text looks like a nice paragraph on the iPhone.  Also, Apple uses the bullet character to bullet features.

Note here that the long lines make the display of this text awkward and difficult to read.  (I use it anyhow!)

Note a few things here:

1. The first and third lines are used so Web Preview and iTunes display both lines top of fold.
2. The bulleted lists do not word wrap, (the max char per line is 45).
3. Unicode goodness makes it look crisp.
4. Attention goes to lines 17 and 18 in the app description.  They are the final ones before the user would scroll down to see the screen shots.

Here’s Rock Show’s Web Preview:

App Description Formatting on the iPad

The iPad app store app supports both landscape and portrait modes.  It also brings back the idea of the fold and its exposing link, “More…”  In this way, the iPad’s app store application is formated more like iTunes’ traditional display.  See for yourself by comparing iBooks Web Preview with the landscape view of the iPad App Store app. iBooks also happens to have a fancy custom background that 3rd party developers generally won’t have access to:

Conclusion

There isn’t an easy way to preview how your app’s text will look in all these different store fronts until after it is published , but you can at least know what you’re up against.

Experiment with your language and line length.  Every opportunity for a new installation of your software on an iOS device holds not only immediate, but residual value.  Since potential users may view your value proposition from a few different angles, pay attention to the quirks and write accordingly.

One solution to this problem would be to create image files containing stylized text and then rasterize them and allow the user to page through them.  The problem with this is that you can’t have tappable URLs or links embedded in the text.

David Peixotto, coding ninja and my business partner for Neutrinos, suggested we look at using a Webview or HTML view and put an imageview in the background.  The trick is telling the iPhone to display a UIWebView with a transparent background.  I looked around for the solution to this and came across this helpful post in the iPhone Developer SDK forums.

Step one of getting a transparent web view in interface builder is to create HTML in the controller.m for the view containing the webview that contains the CSS line: <body style=”background-color:transparent”> Inside the <head> </head> sections of the html.

Step two is to set the background color of the webview to clear or transparent:  myWebView.backgroundColor = [UIColor clearColor];

Step three is to make sure that the “Opaque” box on the inspector of properties of the WebView is unchecked.

That should be all you need to do.  Drop a UIImageView behind the newly transparented web view object and you should be able to use a scrollable rich text with hyperlinks.  Horray.

If this helped you or confused you more, please post in the comments!  We do have it working on 3.0 much to the happiness of our client.

Salesforce does not explain how its clients should go about crafting a quality Contact Us web page.

What is a quality Contact Us web page?  

Generally you’ll find the same type of fields on Contact Us pages across the web.  You are asked for your first and last name, job title, complete address and something specific about your query, like Where did you hear about us? Or What model Range Rover are you interested in?

 What’s the use of having their name if you don’t have their phone number?  Usually, a company will want to set specific form fields to required. Checking whether a potential customer has filled out a required answer is called form validation.

An Overview of Form Validation

There are two ways to validate form data, client side and server side.  While doing both client and server side validation may be a best practice, my experience is that only one method is chosen.

In general, Javascript is used to validate forms on the client side (in browser).  When a potential customer forgets to enter their phone number, javacript pops a small dialog box reminding them they screwed up.  The user fixes their error and tries submitting again.

Server side validation occurs when the potential customer submits a form and a new page loads, typically with a warning in red saying what information they forgot to enter.  The user then clicks back to return and complete the form.

Limitations of Data Validation on Salesforce Powered Contact Us Forms

Salesforce does not allow server-side data verification.  My understanding is that all users of Salesforce submit form data to the same encrypted URL: https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8

A unique customer ID accompanies all data posted to Salesforce which routes it into your personal silo of the great CRM cloud in the sky.  Since you don’t control this servlet page on salesforce.com, you can’t do anything once the form is submitted.

This means that a client side check, using javascript, is your only real alternative for validating forms used to feed data into Salesforce.

Implementation

There are many examples on the web of how perform simple form validation with Javascript.  If you want to get really fancy, here’s the javascript SalesForce uses for validating its own forms.  It includes checking for the email address to be formed properly and if the phone number is valid.  A screenshot of the page the above jscript was taken from is below.

Keeping it simple, you can simply ensure something was typed into individual fields like so:

<script type=”text/javascript”>

function validate_required(field,alerttxt) {

with (field)

{

if (value==null||value==”")

{alert(alerttxt);return false;}

else {return true}

}

}

function validate_form(thisform)

{

with (thisform)

{

if (validate_required(first_name,”Please fill out your first name.”)==false)

  {first_name.focus();return false;}

}

}

</script>

The matching form element would be:

<label for=”first_name”>First Name: *</label>

<input  id=”first_name” maxlength=”40″ name=”first_name” size=”25″ type=”text” /> 

And finally the <form> tag needs to run the javascript:

<form action=”https://www.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8″ onsubmit=”return validate_form(this)” method=”post”>

Voila.  You have performed client-side data validation.  

Caveats and Other Madness

This example uses the standard Salesforce field “first name” and its associated id, first_name.  If you use custom fields in Salesforce, you’re going to have to deal with weird id’s, like 000004fsx02.  In these cases you will need to construct form elements with different ID and Name values, since the javascript that I used did not accept DOM names that began with numbers.  

My research suggests that this is against convention, but you do what you’ve got to do.  Maybe you can write better javascript that will take these funky salesforce custom field id’s.  If you can, please post your solution here.

I should also mention that occasionally you want to hard code data for passing into custom fields in Salesforce.  In these cases you must still use the form data spit out by web-to-form, only set the only response to what you want and set the item to hidden.

Suggestions for Salesforce

Salesforce disowns anything you do with the HTML that the web to form functionality kicks out for you.  They do not support creation of contact us forms, and provide no advice on technologies or methods to validate data inbound to their CRM.  Asking their customer support staff  if their CRM has the ability to perform server side validation will be met with confusion.

Salesforce needs to provide better support for this important aspect of lead origin into its client’s sales processes.  Undoubtedly, SF likely has elegant methods for working with data using its SDK.  If it is going to actually reach startups and smaller businesses with a $9 per user subscription plans, it needs to better support the most basic functionality of passing data into the system.

If Salesforce does not better address the down market, it will lose against startups like Zoho that offers a similarly priced CRM and a comprehensive set of other web applications and that has a user community willing to create how-to videos for things like Contact Us form creation.

At a minimum an explanatory page should be available in Salesforce’s online help to explain the basic methods for building and validating web form data.

I hope this has been helpful, please post your experience!

Follow me on twitter.

Developers working on emerging software platforms are a flexible bunch.  They’re used to having theirapplications break so long as the platform overall is being improved.  A better platform means more users, which means greater opportunity for 3rd party developers.  One thing developers do not like, however is having their software tools gobbled up an encorporated into the core of the platform.

I wrote about how this was happening in my blog post, Nationalization or Expropriation? Independent Facebook Application Developers Continue to Face Uncertainty.  Something entirely different is happening right now on the Touch platform, however.

It all started with the an application called, “Pull My Finger,” which allowed people to touch illustrated fingers in order to play back audio of flatulence.  You see, Apple, unlike Facebook, will only allow applications to become available to run on the Touch Platform devices (the iPhone and iPod Touch) after they have been reviewed by hand by an Apple employee.

Let’s take a look at the normal application development cycle for getting an application up onto the Apple Touch platform:

Now let’s take a look at the alternate scenerio:

As you can see, the developer has two choices when their application is rejected from the iTunes store.  A redesign scenerio could occur when their application breaks a minor rule.  For instance, early on Apple was rejecting applications that mis-used the vibration function on the iPhone.  A developer could rectify this problem by taming down their application’s vibration and re-submitting.

The give-up scenerio is based on a different type of rejection from Apple.  There have been two well-documented cases of Touch Platform application rejections by Apple because the fundamental basis of applications was rejected.  As mentioned, the Pull My Finger application was rejected because “[Apple] determined that this application is of limited utility to the broad iPhone and iPod touch user community, and will not be published to the App Store.”

More recently another rejection was delivered to someone who had created a podcasting application.  In this case Apple rejected it “since Podcaster assists in the distribution of podcasts, it duplicates the functionality of the Podcast section of iTunes.”

The problem faced by developers is uncertainty.  How can they know what is and what is not ok before investing development time and resources into creating an application.  The problem for Apple is that if they define exactly what the rules are for approval, there will always be exceptions.  Plus, Apple may still not know what their rules are.

Some of the blame lies with developers and their desire to play on the edges of what a reasonable and rational iPhone application idea might be. For instance, designing low-brow flatulence applications or tools that replicate existing functionality does not show a lot of creativity on the developer’s part.

In addition, the I’m Rich application made it past Apple’s application approval group initially, but when it made headlines, it was an embarassment for Apple.  Can we really blame them for being more careful now?

But just as Facebook application developers grew angry over the integration of functionality they had developed into the Facebook core, Touch platform developers deserve great communication from Apple on what is and is not ok, in order to avoid wasted effort.  Developers have indicated that applications that violate non-Apple trademarks have successfully been approved and listed for sale in iTunes.

One developer fed up with Apple’s approval ambiguity has given a number of suggestions for improving the situation, including Apple hiring a a 3rd party developer champion or evangelist, someone who can perform official coaching or pre-approval on application ideas prior to beginning a development effort in earnest.

For now, developers will have to stick to common sense in coming up with ideas for new applications for  the Touch platform.

[Update 9/20/08: I found a more detailed flowchart on the approval process here.  Also, I made a minor edit to  second flowchart to reflect the possibility that the app is approved]

Neutrinos just wrapped its second iPhone application, it is a 20 questions trivia game called iQ.  It is great step from our first app, TipTotaler.  For iQ, I took on the user interface design for the application in addition to my normal website design and marketing.

The amount of graphic design and image handling in iPhone development is extensive and I’ve already blogged about a tool to assist in the 3d iPhone application icon design.  But the most interesting stuff is happening in Interface Builder and in xCode that I’m not supposed to talk about here.

Apple has an NDA up with all developers that they can not talk about their experience with the SDK.

5. Confidentiality
5.1 Information Deemed Confidential
You agree that the SDK licensed hereunder, the terms and conditions of this Agreement, and any
other non-public information that You learn about Apple’s products, designs, research,
development, know-how, or Apple’s business, finances or personnel, or non-public third party
information, in connection with this Agreement or in connection with Your use of any part of the
SDK will be deemed “Apple Confidential Information” under this Agreement.

 Here’s a shout to Rob Teel who would appreciate the intersection of tech and law here.  Anyhow, there are a lot of people speaking up about the gag order that has been imposed on people who are developing for the iPhone.  ARS Technica condemned it with an article with weird images in it.  The leading macrumor right now is that it has to do with multi-touch patents.

Whatever the reason, the NDA hasn’t kept some people from posting insights and portions of source code they aren’t supposed to.  Yet, Apple isn’t closing the threads and I haven’t read any reports of people being kicked out for it.  The drama of coding within a new platform was there when I started working with Facebook applications.  But Facebook didn’t have this secrecy thing going on, which makes this a little cooler.  Analyst expectations that Apple will sell 4.47 milliion more 3G iPhones makes it hot.

If you or someone you know has an iPhone–tell them about  iQ.