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.

Aaron Fechter the President of Creative Engineering, Inc has been reprogramming a working animatronic bear-band set up.  It looks like the company created it for a line of restraunts similar to Chuck E. Cheese.  He’s currently taking cash bids to do syncing or “choreography” for the band members.

The way the performance is filmed and presented are awesome.  Shakey prolonged shots, quick pulls outward.  The overall video quality is low and the colors look a bit washed out.  Everything is blurry and the bear with the guitar has a spooky shadow.   Great media.

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.

Dynamically built webpages, (especially applications), require time to load and visual feedback that something is happening.  The most famous example is the gmail loading page:

Gmail uses a more sophisticated progress bar to represent the loading of the webpage.  I found an article on yensDesign that gives some great advice on how to do this, if you want to get really fancy.

If you have a dynamically built page that you’d like to give a loading message to that doesn’t require a full progress bar, I recommend simply displaying a message and an animated gif.

The Method

The trick to accomplishing this is a small mix of JavaScript and CSS.  You don’t have to be using <div>’s to display your content, but you should.  My example uses <div>’s.

Let’s begin by assuming you have the majority of your page’s content within a series of nested DIV’s, where the outermost DIV is called “container.”

 <div id="container">
    <div id="heading">
       ...heading content...
     </div>
     <div id="body">
       ...body content...
     </div>
  </div>

Normally, the dynamic content in your container would be rendered by the browser after it has downloaded and performed the main JavaScript routines.  What we want to do is hide the container when the page is first loaded and instead display a DIV that contains a waiting message and a little animated gif icon.

Begin by using the CSS display property to hide the container DIV like so:

  <div id="container" style="display:none">

Next, you need to add a new DIV that contains your “Please Wait, loading…” message.  I chose to include an animated gif icon of a twirling circle, which I easily created using the AjaxLoad.info, a site created by Catherine Roman.   If you want to download my animated loading gif, you can get it here.

Here is an additional set of nested DIV’s that contain the loading content.  This should be placed outside the container DIV:

      <div id='siteLoader'> 
        <div id='siteDetailLoader'> 
        <img src='/path/to/your/animated/gif/loading.gif' border='0'> 
        Please wait while the page loads...<br /> <br /> 
        </div> 
      </div> 

You’ll note that the display property is not set on siteLoader because it is visible by default.  This is what we want.  The trick now is to make the siteLoader DIV dissappear once the dynamic page content is done loading while simultaneously displaying the container DIV with the real page content.

This is handled using the global event handler onLoad.  There a few ways to make use of the onLoad event, I recommend including an external JavaScript file.  Do this by saving a new text file called actions.js in the same directory as the page you’re changing.  Just after your <title> tag on your document include this external JavaScript  file using:

<script src=”actions.js” type=”text/javascript”></script>

Inside actions.js, you need to include a function based on window.onload as follows:

window.onload = function() {
   document.getElementById("siteLoader").style.display = "none";
   document.getElementById("container").style.display = "block";
}

What this is doing is saying to the browser, “as soon as you’re done loading the webpage, you should hide the ‘please wait’ stuff and show the meat and potatos of my webpage.”

To view all of this in action, have a look at my recently updated online portfolio which of course, talks up what a great person I am.  I hope this has been helpful, as always–please post your comments!

For further reading on busy indicators and the important visual feedback and attention cueing needed to be successful with the display of heavy dynamic webpages, have a look at the article series on SAP Design Guild by Gerd Waloszek called “Waiting at the Computer: Busy Indicators and System Feedback.”   There is a wonderful table giving guidelines on the type of feedback that should be displayed based on user wait time.

I was just doing a ShareThis icon for a client I’m working with and found that how to properly style the button is poorly documented.  In order to replace the whole icon and text, you are supposed to use the developer API.

I only wanted to style the text, so I was hunting for some CSS to style the text and could not find the right classes to call.  Some hunting turned up the following:

.stbuttontext – This class will allow you to change the look of the text, ShareThis.  You can style it with any normal styling like color or font-family but text-decoration does not seem to work. :p

.stico_default – This class allows you to style the icon itself.  An example on how to replace the ShareThis icon with your own site’s favicon webmonkey is: 

{
	background: transparent url(http://www.banagale.com/favicon.ico) no-repeat scroll 0px 0px !important;
}

I’m interested in any other css that can be used to style the ShareThis button without requiring API calls (if there are any).   if you know of additional classes, or this helped you please post a reply.

Follow me on Twitter

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.

One of my tasks with the release of our recently submitted iPhone application, TipTotaler was to select an icon for our app.  As you may be aware from Apple’s iPhone application submission guidelines, you must include a flat 57 x 57 pixel and 512 x 512 pixel image for use on the iPhone and iPod Touch home screen and for the iTunes store.

There are a couple of challenges for iPhone Application icon graphic designers:  First, it isn’t always easy to tell what will look good at both 512×512 and 57×57.  Second, having the developer rebuild and send updated screenshots is laborious as is monkeying around in Photoshop to eyeball how the images look at lower resolution with 3D effects.

In order to speed up the process, I put together an Adobe Photoshop macro aka ‘action’ that will quickly take any square image and apply similar 3D effects that Apple uses.  The 3D effects used on buttons on the iPhone home screen and the iTunes store application pages include rounded corners and a light sheen over rounded across the top third to one half of the button.  My macro automatically transforms any image into a 3D iPhone Application icon with these characteristics.

I’ve recorded a screen cast demonstration of how to use the macro using Jing.  You can view the screencast here.  Click the link below to download a zip file containing the Photoshop action macro and iPhone gallery image to test out your 3D button on.

Remember, your starting image must be a perfect square of any size prior to running the macro.  Questions? Watch the screencast above or post a comment.

->  Download iPhone Application Icon Preview Macro

What might the goals of a union of Facebook application developers be? It would help to look at what has stirred the pot recently. About two weeks ago someone posted a complaint that Facebook had unfairly bent the rules to give CBS’s Sports NCAA bracket application advantages for faster viral spread across the Facebook user base. Adding insult to injury, the thread also pointed out that the CBS Sports NCAA bracket application had a poor user rating.

Two days ago another developer posted a thread titled, “Facebook has stolen my idea!” which describes the recently added “Do you know these people?” page on Facebook. The developer suggests he feels “cheated” because the new Facebook page duplicates his own application’s functionality. The developer’s application was forced to comply with platform development rules that required an obstructive approval process in order work correctly.

Facebook’s “Do you know these people?” page circumvents this approval process because it is not subject to the rules independent application developers must follow. Facebook made a better version of the application a part of the Facebook experience by bending the rules that crippled the original developer’s work.

These examples illustrate that Facebook considers it a duty to nationalize or expropriate functionality if it is considered good for Facebook. Rather than something that needs to be declared, Facebook makes this right clear in the Facebook Developers Terms of Service:

“…You hereby grant us a worldwide, perpetual, irrevocable, non-exclusive right and license, with the right to sublicense, to: (a) access, reproduce, display, distribute, perform, and store on our servers your Facebook Platform Application and any Facebook Platform Application Content, and to create derivative works of Facebook Platform Application Content, as may be necessary or desirable to make such Facebook Platform Application and Facebook Platform Application Content available to Facebook Users in accordance with the terms of this Agreement and the Facebook Platform Documentation and the Facebook Platform Application Guidelines; and (b) otherwise access, use and analyze any Facebook Platform Application Content for our internal business purposes (e.g., for the purposes of targeting delivery of advertisements or other content to persons who have viewed particular types of Facebook Platform Application Content).”

This paragraph basically says that Facebook can duplicate and meet parity or run with your application’s functionality and then integrate it into the basic Facebook experience. The second part basically says that Facebook reserves the right to monitor how much your application would be worth if Facebook were to take your idea.

I think a lot of independent developers get to sleep at night with the belief that Facebook wouldn’t expropriate their applications. These developers comfort themselves with the idea that “it happens occasionally–but only to applications with functionality that obviously belongs in the platform.”

The board of directors for the copper companies were probably counting the same sheep prior to the sweeping expropriation of copper mines by the Chilean government in the early 1970s. The result of that disagreement was that the United States pushed for and succeeded achieving economic sanctions against Chile. But the Facebook development community doesn’t exactly have sanctions on its list of tools of influence. What does it have?

For one, it would have to be part of a greater independent community of developers for all open social platforms. Only by having a union of developers that canvas’s all major platforms could it hold sway against any particular one. Such an organized group might hold sway by steering technical offerings, such as beginner guides, away from platforms that have a history of expropriating applications functionality unfairly. A strong independent application developer union might also be able dissuade or at least condemn social platforms that repeatedly expropriate functionality.

Representation at the table would help, when the biggest social networking application companies, RockYou!, are getting all of the attention. RockYou! has funding from Sequoia Capital, a company that wouldn’t take wholesale expropriation of their software lightly.