Process and plans are attempts to control the future by studying the past. Trouble is, past experiences are not tomorrow’s work. The popular formula of “discovery, design, execution, and launch” work on paper, but the inevitable bullet points that follow each step only work if you write the points yourself. Even in the same project, client and team will vary over lifespan of development. Creative projects demand improvisation.

Instead of a process, when working on a digital project like a site or an app, I have questions.

Lifespan of the digital project

• Is the digital project meeting its goals?
• Is the digital project meeting goals that you didn’t know you had?
• What questions do you have?
  You’re free to ask these questions. You’ll learn more if you ask your own.

Process and plans are attempts to control the future by studying the past. Trouble is, past experiences are not tomorrow’s work. The popular formula of “discovery, design, execution, and launch” work on paper, but the inevitable bullet points that follow each step only work if you write the points yourself. Even in the same project, client and team will vary over lifespan of development. Creative projects demand improvisation.

Instead of a process, when working on a digital project like a site or an app, I have questions.

During and after launch

• Apps: Assuming it’s an iOS app, have you followed Apple’s criteria?
• How will you celebrate?
  This isn’t trivial. Unexpected, tangible pats on the back are critical for long-term team morale.
• Do you have a regular checkup plan?

Process and plans are attempts to control the future by studying the past. Trouble is, past experiences are not tomorrow’s work. The popular formula of “discovery, design, execution, and launch” work on paper, but the inevitable bullet points that follow each step only work if you write the points yourself. Even in the same project, client and team will vary over lifespan of development. Creative projects demand improvisation.

Instead of a process, when working on a digital project like a site or an app, I have questions.

During testing

• In what unexpected ways did people use the digital project?
• How did people’s expectations differ from what their experience? Were they delighted or frustrated?
• What did the user get done without hesitation?
  (Hint: That’s where you’re doing well.)
• Did they compliment the digital project?
  If so, then it needs more work. But if they focus on getting something done, then you’re doing well. “Nice app” is bad. “Look what I did” is good.
• If someone pokes fun at your digital project, pay attention.
  The ridiculous can be eye-opening.
• Is the team still actively engaged?
  Lackluster projects often stem from a team just trying to fulfill a someone else’s requirements.

Process and plans are attempts to control the future by studying the past. Trouble is, past experiences are not tomorrow’s work. The popular formula of “discovery, design, execution, and launch” work on paper, but the inevitable bullet points that follow each step only work if you write the points yourself. Even in the same project, client and team will vary over lifespan of development. Creative projects demand improvisation.

Instead of a process, when working on a digital project like a site or an app, I have questions.

During development

• How can the design make information easy to understand or manipulate?
• How does the project visually communicate its goals?
• What details can you add that people won’t notice at first glance, but won’t detract from the user experience?
• Apps: Does the app “feel” ergonomic, unobtrusive and useful?
  App design is not website design. Think of the app as a handheld object, like a kitchen utensil or a garden tool.
• Does everyone who gets their hands dirty in code/graphics/UX/management have a say in the digital project’s outcome?
  A team who works with someone is worlds better than a team who works for someone. “What do you think?” is good to ask. “Hey, I had this idea…” is good to hear.

Process and plans are attempts to control the future by studying the past. Trouble is, past experiences are not tomorrow’s work. The popular formula of “discovery, design, execution, and launch” work on paper, but the inevitable bullet points that follow each step only work if you write the points yourself. Even in the same project, client and team will vary over lifespan of development. Creative projects demand improvisation.

Instead of a process, when working on a digital project like a site or an app, I have questions.

Concept

• What problem(s) does this digital project solve?
  Great apps make a task easier, or fill a need that people (not the client) have.
• Is the digital project more fun or more serious?
  The difference will inform its “persona.”
• Is the digital project more of a utility or more of a game?
  Good utilities fulfill a need; good games hold attention.
• When will the digital project launch?
  Nothing sets priorities like a deadline with consequences.
• How will you promote the digital project?
  Word of mouth is great, but often requires a sustained kickstart.
• How will you measure the success of (or lack of) the digital project?
• On which platform(s) will this digital project run?
  There’s a difference in designing for desktop browsers, screen readers, iPhones, iPads, or a combination thereof.
• Who is responsible for what?
• Do the stakeholders want to educate, entertain or empower people, or do they want an digital project?
  Solutions without problems can work, but rarely thrive.
• Does the client want to copy the success of others?
  “Isn’t there a better way to…?” is good. “I love this app/website/graphic/tool/gimmick. Can you make one?” is bad.

Two different clients had two different uses for days/months/years. One was to browse an archive, the other was to let users schedule an event. Both wanted it done quickly and neither wanted to pay for adding years after every New Year’s Eve party.

Solution

As part of my forward-thinking strategy — Preventing Problems is Good — I wrote a JavaScript function to automatically add years as necessary. Specifically, the code below creates <option> elements with years in a given <select>.

function populate_years(min,max,target){

	// What year is it?
	var d = new Date();
	var this_year = d.getFullYear();

	// Loop through the years.
	for ( i=(this_year+min); i<(this_year+max); i++){
		$('#'+target).append('<option value="y'+i+'"&gt'+i+'&lt/option&gt');
	}
}

How it works

1. Extract the current year from a JavaScript date object.
2. Start at a certain number of years before the current year and count forward until you reach a sufficiently distant future.
3. Add each year as an HTML option element to the given user interface widget.

Portable code

Whenever writing a function PHP, JavaScript, or jQuery (and handlers in AppleScript), I try to write “portable” code that I can reuse in different projects. Ideally, portable code does not use global variables because that ties the function to a given project. Likewise, functions should never directly display (echo, print, sprintf) anything to the screen. I can’t tell you how many times I’ve had to track down an errant space that killed some PHP include. Functions should take arguments, do something, and return results. End of story.

Sample usage

} .action-button:active { background: -webkit-gradient( linear, left bottom, left top, from(#86aceb), to(#347ee2) /* Gradient colors, inverted. */ ); position: relative; top: 3px; /* Give it that "depressed button" look. */ }

Tap me

Here’s a quick style I wrote for creating buttons that look tappable.

.action-button {
	display: block;
	width: 120px;
	padding: 7px;
	text-align: center;
	color: #fff;
	font-size: 15px;
	font-family: 'hevetica neue',helvetica,arial,sans-serif;
	cursor: pointer;
	text-shadow: #145ec2 0 -1px 0;
	background: -webkit-gradient(
		linear, left bottom, left top,
		from(#347ee2), to(#86aceb),
		color-stop(0.5, #347ee2), /* Dark value */
		color-stop(0.5, #548fe5) /* Medium value */
	);
	-webkit-border-radius: 4px; /*  */
	-moz-border-radius: 4px; /*  */
	border-radius: 4px; /*  */

}
.action-button:active {
	background: -webkit-gradient(
		linear, left bottom, left top,
		from(#86aceb), to(#347ee2) /* Gradient colors, inverted. */
	);
	position: relative;
	top: 3px; /* Give it that "depressed button" look. */
}

How it works

• Set the width to whatever fits your requirements.
• For testing in a desktop browser.
• Shadow color should be a shade darker than your darkest gradient.
• Lightest color, in this case, pale blue.
• Medium value creates the illusion of a chrome-like reflection.
• For Webkit browsers like Chrome and Safari.
• For Gecko browsers like FireFox.
• For future browsers.

Regular expression, or “regex,” is a means to seek patterns in a string of text. PHP has several regex functions that coders may use to see if a string fits certain conditions. In this example, we’ll see if a string fits the standards for a real email address.

function validate_email($address='',$regex=''){

	// A regular expression to check email validity.
	if ( !$regex ) {
		$regex = "^[a-z0-9-_\.]+(\.[a-z0-9-_\.]+)*@

			[a-z0-9-_\.]+(\.[a-z0-9-_\.]+)+$"
	}
	if ( $address ) {
		if (eregi($regex, $email)) {
			return true;
		}
	}
	// We don't need an "else" condition. If the
	// script gets this far, it's because $address
	// didn't exist or didn't fit the regular
	// expression in eregi().
	return false;
}

From regex to English

Here’s how it works:

^[a-z0-9-_\.]+(\.[a-z0-9-_\.]+)*@

[a-z0-9-_\.]+(\.[a-z0-9-_\.]+)+$

1. Start with at least one letter, number, hyphen, dot or underscore.
2. After one optional dot, look for one or more optional letter, number, hyphen, dot or underscore.
3. At this point, there should be an atmark followed by at least one letter, number, hyphen, dot or underscore.
4. Valid email addresses should end with a dot that’s followed by at least one letter, number, hyphen, dot or underscore. There will be at least one set, maybe more (like “.something.com” rather than just “.com”).

Bulletproof? No. But it covers most cases.

One benefit of soft keyboards is their ability to change on context. Email addresses, for example, need different characters composing emails.

Appcelerator Titanium has many ways to choose different iOS keyboards by property:

A typical Titanium text field might be written:

var name_field = Titanium.UI.createTextField({
  height:35, top:40, left:20, width:280,
  borderStyle:Titanium.UI.INPUT_BORDERSTYLE_ROUNDED,
  keyboardType:Titanium.UI.KEYBOARD_ASCII,
  enableReturnKey:true,
  returnKeyType:Titanium.UI.RETURNKEY_DONE
});

Click each sample below to put it in the sample code above.

The angle gradients create clockwise blends of color around the point a user clicks. Most people stop there. But when combined with other techniques and some creativity, the angled gradient has some surprising uses.

Read the full article I wrote at Webdesigner Depot.