About the Author:

How Good C# Habits can Encourage Bad JavaScript Habits: Part 1

May 25th, 2017
This is the first post in a multi-part series covering common mistakes C# developers tend to make when they first start learning JavaScript.

Introduction

Many people come to jQuery and believe that their knowledge of a previous classical language (C#, Java, etc) will help them be successful at client-side scripting. You can use your classical language skills to accomplish a large amount of functionality with jQuery. However, the more client-side code you write you will find yourself uncovering strange bugs because you didn’t take adequate time to learn JavaScript properly.

“…it turns out that if you have absolutely no idea what you’re doing in the language you can still generally make things work.” –Douglas Crockford, Yahoo!’s JavaScript Architect, Douglas on JavaScript — Chapter 2: And Then There Was JavaScript

This article is targeted for developers that use jQuery but haven’t invested the time necessary to learn JavaScript. The intent is to help you avoid some common mistakes when moving from a classical language (Java, C#, etc) to JavaScript.

jQuery is a library that is written in JavaScript. It is important to remember that you will always be writing in JavaScript when using jQuery. It is inevitable that you will run into native JavaScript concepts that are foreign to the classical language proficient developer. Taking the time now to be proficient in JavaScript will increase your client-side code quality, efficiency, and decrease code maintenance.

(more…)

About the Author:

jQuery Ajax and JSON Envelopes

March 28th, 2015

This is post 3 in a series on creating a JavaScript component for handling your Ajax requests in front-end development across your enterprise. You can find all the other posts here:

In the last post we covered using the publish/subscribe pattern along with some error handling code to add some loosely coupled error messaging and load notifications. We ended with the following code for the component:

var mySiteAjax = ( function( $ ) {
var standardError = "Oops. Sorry about that. Please try again.";

return {
getViaAjax: function( params ) {
var settings = $.extend({
url: '',
spinner: undefined,
dataType: 'html',
cache: false,
success: function(){}
}, params);

var retries = 0;
function ajaxRequest ( ) {
$.ajax({
beforeSend: function(){
$(document).trigger( "ui-load-start.message",
[{ spinner: settings.spinner }] );
},
url: settings.url,
dataType: settings.dataType,
success: settings.success,
complete: function(){
$(document).trigger( "ui-load-end.message",
[{ spinner: settings.spinner }] );
},
error: function( xhr, tStatus, err ) {
if( xhr.Status === "401" || xhr.Status === "403" ) {
//redirect action here
} else if ( xhr.Status === "504" && !retries++ ) {
ajaxRequest();
}
$(document).trigger( "ui-flash.message",
[{ message: standardError }] );
} // end error handler
}); // end $.ajax()
}; // end ajaxRequest()
ajaxRequest();
} // end getViaAjax()
}; // end return statement
})(jQuery);

In this post we are going to take this code and add on some explicit functionality for handling a JSON envelope.

## What is a JSON Envelope
A JSON envelope is a wrapper around JSON returning from the server. The wrapper serves to communicate any failures or messages back to the client along with the appropriate data if the request succeeded.

Consider a scenario where you are sending the server a few parameters and hope to receive a JSON structure back. What happens if you were to send a parameter which was invalid? The server would not be able to respond with the appropriate data and a failure should be communicated.

This is different from an HTTP status code as we were able to communicate with the server successfully. We need a solution to communicate any issues which may have occurred in the server code providing a successful response to our request.

A JSON envelope is a simple mechanism to communicate messages and failures to the client as part of a JSON response. Typically the intended data for the client is wrapped in an object. The JSON object sent back to the client includes this wrapped data if successful. If not the object sent back includes a message. In all cases the response object contains a status indicator.

A typical successful JSON enveloped response might look like this:

{
"status": "ok",
"data": {
"myData": "someData"
}
}

An error response contains a status property as well as a message property indicating the issue:

{
"status": "fail",
"message": "You did not supply the correct input data."
}

Another advantage of using a JSON envelope is that the object wrapper will alleviate a subtle JSON vulnerability (outlined [here](https://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx) by Phil Haack).

### JSON Envelopes in use today

Many public services are implementing JSON envelopes for simple messages and error communication. The [Flickr API](https://www.flickr.com/services/api/) has a JSON envelope in place for simple communication of failures. You can find more information on the [JSON response format](https://www.flickr.com/services/api/response.json.html) page as well as example of [success](https://www.flickr.com/services/rest/?method=flickr.test.echo&format=json&api_key=560f2f65e11cef441ba757d2b509b157) and [failure](https://www.flickr.com/services/rest/?method=flickr.blogs.getList&format=json&api_key=560f2f65e11cef441ba757d2b509b157) responses.

## Handling a JSON Envelope

Our first step is to handle the JSON envelope in our Ajax utility component and take action if a failure occurred. If the envelope indicates a successful response we need to invoke the success callback. As a reminder from last post `settings.success` is the success callback provider by the calling code (or an empty function if none was provided):

var mySiteAjax = ( function( $ ) {
//..
$.ajax({
//...
success: function(wrapper, tStatus, xhr) {
if(!settings.type.match(/^json/i)) {
return settings.success.call( this, wrapper,
tStatus, xhr);
if(wrapper.status === "success") {
return settings.success.call( this, wrapper.data,
tStatus, xhr);
}
$(document).trigger( "ui-flash.message",
[{message: wrapper.message}] );
},
//...
});
//...
})(jQuery);

We have created a success function callback that will be run when the response returns from the server. We will inspect the envelope for a status and will take action if the status is not successful. If it is a success, we will call the success callback provided in our settings.

The code snippet `return settings.success.call( this, wrapper, tStatus, xhr);` is particularly interesting. This may be the first time you have seen the `functionName.call()` method in JavaScript. This method allows us to set the context of the `this` argument in the function call. We could have done the following:

//...
if(wrapper.status === "success") {
setting.success(wrapper.data, tStatus, xhr);
}
//...

But what is the context of `this` in that case? Probably not what the `settings.success` callback would expect. If instead we use the `functionName.call()` JavaScript function we can set the context of `this` as well as all the other arguments for the function call. This allows us to precisely supply the context expected by the `settings.success` function.

To handle the error message we added the following action:

//...
$(document).trigger( "ui-flash.message",
[{message: wrapper.message}] );
//...

We are “publishing” by using jQuery events with a custom event name. Our “message topic” indicates that there is information that should be shared with the user. It is up to another component on our page to have subscribed to this topic and to take the appropriate action. We do not have to care if the message is actually published to the user, or how it is done. We have achieved separation of concerns. Doesn’t it feel nice?

## Handling different JSON Envelopes
Different JSON envelope implementations mean different JavaScript properties and success/failure statuses to deal with. Some sites may not have a JSON envelope. Our utility component needs to handle all these cases.

To do this we will add global settings. This will allow the user to set global defaults while using arguments specified to `mySiteAjax()` if a specific call involves a different JSON envelope.

To handle global setting we will add a settings property onto our mySiteAjax object. The code snippet below is long, but bear with me. We will break it down below.

var mySiteAjax = ( function( $ ) {
var standardError = "Oops. Sorry about that. Please try again.";

// create new Ajax utility as a "private" variable
var myAjax = function( params ) {

// add together global settings with arguments
var params = $.extend({},
myAjax.settings, params);

var retries = 0;

function ajaxRequest ( ) {

$.ajax({
// publish "local" loading start message
beforeSend: function(){
$(document).trigger( "ui-load-start.message",
[{ spinner: params.spinner }] );
},
type: params.type,
url: params.url,
data: params.data,
dataType: params.dataType,
success: function(wrapper, tStatus, xhr) {

// if json is the data type and the json wrapper exists
if( (/^json/i).test(params.dataType)
&& params.env.hasEnv) {
if(wrapper[params.env.statName]
=== params.env.successInd) {

// since wrapper indicated a success,
// call original success callback with the
// unwrapped JSON contents
return params.success.call( this,
wrapper[params.env.dataName],
tStatus, xhr);
}

// success wasn't indicated, publish
// message
$(document).trigger( "ui-flash.message",
[{message: wrapper[params.env.msgName]} ] );
} else {

// return unwrapped if response wasn't json or no envelope
// was specified
return params.success.call( this, wrapper,
tStatus, xhr);
}

},

// publish "local" loading end message
complete: function(){
$(document).trigger( "ui-load-end.message",
[{ spinner: params.spinner }] );
},
error: function( xhr, tStatus, err ) {
if( xhr.Status === "401" || xhr.Status === "403" ) {
//redirect action here
} else if ( xhr.Status === "504" && !retries++ ) {
ajaxRequest();
}
$(document).trigger( "ui-flash.message",
[{ message: standardError }] );
} // end error handler
}); // end $.ajax()
}; // end ajaxRequest()
ajaxRequest();
};

// settings which are global and attached
// to the myAjax function as a property
myAjax.settings = {
url: "",
spinner: undefined,
dataType: "json",
cache: false,
type: "GET",
success: function(){},
env: {
hasEnv: true,
statName: "status",
successInd: "success",
dataName: "data",
msgName: "message"
}
};

//returns the newly created function with the properties attached.
return myAjax;

})(jQuery);

You’ll notice we moved around things. The function is now specified as a named function (although the scope is still within our component code only). We’ve also moved our settings to a property of our main utility function. Since JavaScript functions are objects augmenting it with properties is valid. You’ll also notice that we have an empty object literal as the first parameter to `$.extend()`. This is because the extend method will merge all of the object together and replace the first object with the merged results. We do not want to overwrite our global setting object each time!

Exposing our settings as a property gives us a clean way to specify defaults for a specific page. For example we can set the default HTTP action to POST with minimal effort:

myAjax.setting.type = "POST";

We’ve added settings for the JavaScript envelope. With our settings we can determine whether or not an envelope is used and how to leverage the envelope. Turning off the envelope functionality is now a one line setting:

myAjax.setting.env.hasEnv = false;

In our wrapper code we have changed the way we access objects. For example there is now this snippet:

//...
if( wrapper[params.env.statName]
=== params.env.successInd ) {
//...

Remember that we can access object properties through dot notation or bracket notation. Bracket notation allows you to specify the name of the property as a string. In our above example, with our default global setting of “success” as our status name, the code would evaluate to `wrapper[“success”]`. This would access the success property of the wrapper object. So using this piece of functionality we do not even need to know the names of the properties of our JSON object until runtime!

We now have a working Ajax Utility Component which includes a JSON envelope! I’ve set up a few examples and a playground for the component as a [jsFiddle](https://jsfiddle.net/YLKUz/1/). Please play around and ask questions in the comments!

About the Author:

Brainstorming a Creative Project Part 4: Conclusion

October 16th, 2014

So far in this series on creative project brainstorming, we have looked at the type of questions and exploration techniques you could use when you’re in the challenge phase of your project. In this last part, though short, we’ll cover how to close the project discovery and let you do the actual work.

Closing an exploration phase doesn’t mean the close of the entire project discovery. In fact, until you and your team have come to a final decision on how your initial goal will be reached, you’ll probably be closing many different exploration phases. To help with semantics, think of the discovery phase of your project as one big (opening –> exploration –> closing) group with many, many smaller, similar groups inside of it. It’s not uncommon to have an ‘open, explore, and closing’ group for a every single topic in your project.

Closing a topic is meant to be the end of the topic at this stage. Your best solution right now may need some modifications later, and that’s okay. It’s helpful to keep this fact in mind when you are brainstorming. It’s fairly common to revisit old ideas to make sure your new ideas are conflicting with them. Even if they do, it’s fair to start a new round of questioning and exploration on that topic. You may do this without even realizing it.

Closing Questions

You close a topic by asking closing questions. Remember how we talked about opening questions and that were intentionally vague and used to create discussions? Of course you do. Closing questions are the opposite of that. Questions like, “Which of these options is the best solution for this problem?”, are designed to get people thinking about a single solution, in this case from a list of choices, that they can agree on.

Idea_Pool

You and your team have already had many discussions on whether your ideas are viable and consistent with your goal. Closing questions should also create discussion, but of a different sort. Up until now, you’ve been asking questions to figure out aspects of the project. Now, you’re trying to figure out which of those aspect ideas are the best, or at least the best right now.

That’s really all there is to it, actually. Make sure you and your team are aware of when you have ‘enough’ ideas and are ready to close a topic. Otherwise you may have some confused people.

Series Conclusion

In this article series, we didn’t talk about anything technical or code related, but rather techniques that can be used to help a team come together and brainstorm on a creative project.

Vague opening questions can help you determine where you want to go with your initial idea and help you define your goal. Keep in mind that you need allow yourself and your group to have discussions to open up the exploration phase of the topic and get all ideas on the table, and I mean ALL. Make sure your team members’ voices are heard and instigate anyone that seems like they are holding back. There are (almost) no bad ideas.

If you follow these guidelines, you are going to have an innovative, user-friendly, robust application. I hope you take some ideas from this series on Brainstorming a Creative Project to apply to your own endeavor.

About the Author:

Brainstorming a Creative Project Part 3: The Exploration Phase

October 2nd, 2014

In Part 2 of this series, you learned what being in the challenge space means and about some of the overall techniques used while there. Now begins Part 3 which will take you deeper into the exploration phase of brainstorming your creative project by investigating on more granular level.

Types of Questions

We spent some time over the last two parts in this series talking about the questions that you and your team ask when trying to determine the goal of your project and when you are exploring the challenge space. It’s important to have a plan of attack when you are preparing your questions for the team, even if the plan is spontaneous. Knowing what kind of questions you are asking can lead to results faster than not. Let’s take a look at some common types of questions that relate to brainstorming a creative project.

Instigating Questions

Instigating questions, or opening questions as some call them, serve as that spark when you and your team are firestarting a topic. They are meant to be very open-ended to create a divergence in thought; to force you to think of all the ways you can accomplish the same thing. In web development, the number of ways to do the same task seems infinite and opening questions help you see that.

Directional Questions

For obvious reasons, questions that try to find a path or put you on a certain path are called directional (or navigational) questions. By starting with a vague question like, “What pages does our web application have?”, your team can get off track due to all the possibilities that could be. It’s important for whomever the team leader is to interject with a question that takes the currently discussed idea and finds out whether or not it’s viable. “Is this discussion going to move us along?” is an example of a directional question. It may seem simple, but it makes people think about whether or not the topic is helpful. The answer could be yes or no, and if it’s ‘no’, the team needs to either start a new topic or another directional question like, “Is the next item on our list still a possible solution?” is needed.

Exploring Questions

It’s time to fully explore any and all ideas during the challenge phase. Exploring is about following a line or flow of ideas to a solution, or at least a common endpoint. It’s also about testing and examining whether or not an idea is viable, kind of like the scientific method.

Let’s say you want to come up with a way to get a user from a landing page to the checkout process. That’s pretty open-ended so you could either take a few suggestions about the first step of the user interaction, or you could take suggestions on entire paths and examine it. You can do this by diving deeper into a subject and looking closer at how something works; not how something might work, but how it does work. You may simply ask, “How does it work?”, when a team member suggests an image carousel. If someone wants all the buttons in the application to have a hover effect, “What is the purpose of the effect?”, is a good way to examine the idea.

Another subtype of exploring questions is testing questions (or sometimes referred to as experimental). Conversely, we use these questions to define how something might work. Oftentimes you experiment with something directly after examining, but sometimes the idea is vague enough that you can go right into the experimental step. For example, if you want to experiment with the button hover effect in different ways, you might ask, “What types of styles make sense for this application?”, for a design experiment, and, “What else can this button do when a user hovers over it?”, for a functionality experiment.

After experimenting a little with each idea, it may be helpful to go back and examine them again depending on the time and budget for the project. Re-examining may prove beneficial.

Closing Questions

These types of questions are used to bring all the explorative ideas to a ‘close’, meaning, they should finalize a topic to a solution. You may have more than one solution if you need to have redundancy, but your team should still be converging on those solutions without any remaining ideas on how to solve the problem.

More on Exploration

Now that you’ve seen a few examples of the types of questions that are useful when brainstorming a creative project, let’s take a closer look at exploring your ideas as a team.

One thing you should always keep in mind is topic scope. It’s important to not venture out of the idea zone. If your team is on the topic of what kind of options a product has, don’t offer ideas on how to display those options. That is a separate issue and it has it’s own scope. Write it down and deal with it later. You may be thinking that the content of a dropdown is just as important as the way it’s displayed. I’m not saying that it isn’t, since there are plenty of cases where the two go hand-in-hand, but functionality, design, and content are three distinct things and should be separated accordingly. True, there may be a web of dependencies, but the topics are different and can be explored separately without affecting each other.

Relative Space

Sometimes when scientists or psychologists research something, they will categorize the flow of their methods into two categories: precision and ordering. This helps them determine what is more important: knowing in which order they did the experiments and/or what methods provided them with results. Sometimes it’s more important to know when something happened after or before something else rather than during the task. In other cases, the opposite is true and in rare cases, both are true. When you are exploring your creative idea with your team, you may find yourself developing a flow for a user to follow. In the case of a web application, this might be the path a consumer follows from the home page to the checkout page.

Think about what’s more important for your application. Do you care more about the number of steps it took to get to the checkout page with one or more products or are the products that are added to cart more important?

Below, we see a flow of generic steps that you want a user to take to reach your goal. In this case, the larger picture is more of a concern than what the user was doing in between the steps.

Ordering Focus

order_focus

In a precision focused approach, the basic steps are the same, but there are minuet steps within those larger steps that are important to us. In this case, the focus is more on what options are chosen rather than speed.

Precision Focus

precision_focus

To be clear, you do not need to decide if only one of these approaches is better for your entire project. Use them both! You may find that one topic needs to be thought of in an ordered sense, while another could use some precision thinking. Heck, use the ordered approach to get a grasp of the general idea and break into precision mode if you still have unanswered questions.

Part 3 Wrap Up

When you’re in the challenge space and the project needs to be explored, it’s important to understand the different types of questions you need to ask when properly examining and experimenting with your idea while keeping yourself and your team in line with the goals you’ve set.

About the Author:

Brainstorming a Creative Project Part 2: The Challenge Space

September 25th, 2014

In Part 1 of this series we talked about how to set goals and how to avoid the challenge space. In this section we will go into what exactly the challenge space is and how to use it effectively.

The Challenge Space

The Challenge Space is the phase of a creative project during which you task yourself and your team with finding the many paths to the end goal. Up until now you have only defined and redefined what your goal is in your project. For example purposes, we’ll continue with the web application project.

Let’s say that we have defined the goal of our web application to be ‘sell our product online’. With such an open goal, we can use the challenge space to define how the consumer will do this in several different ways. The challenge space is also going to be used for application design and the user’s flow throughout the search and checkout processes.

So how do we effectively use the challenge space? We explore. We explore all possible ways to achieve the end result and since our goal is pretty vague, there are going to be a lot of options! The trick is, and you’ll begin to understand whether or not this is true for your project, to determine how many paths to the end goal there could be. In some projects, you may want to only identify the paths and plans for users following any of them. In other cases, you may want to reduce the number of paths to one or two.

Start Some Fires

A common way to kick off this phase of a creative project is called firestarting; a term used because of the way events happen when questions are asked. You simply ask a question that could have many answers and spurs discussion amongst the team. There are no ‘wrong’ answers, so write everything down that actually answers the question directly. There are, however, right questions. There are plenty of probing questions that don’t do you any good, like asking off-topic question; you need to identify those early and make sure to stop them before they start any fires. Ask specific questions to get a feeling of what your team members think about a certain aspect of the project.

Use firestarting to your advantage early in this phase. Some questions you might ask for the example web application could be:

  • How does the application look and feel?
  • What is the target demographic for our product and does this affect the look and feel?
  • What is the checkout process?
  • What is the item selection process?

Organizing Your Flames

Asking and answering questions is just the start. You need to keep the outpouring of ideas from those answers organized, or in some cases dis-organized. Either way, you need to write down all the ideas that came from the firestarting questions. As you’re gathering ideas from your sparking questions, you want to try and keep your brush fire under control by organizing the team’s thoughts.

Idea Nodes

You may have heard of mind-mapping before. This is a concept that uses another concept of idea nodes. Basically, you take a core idea and work your way out to finer and finer points until there are no more questions to be asked on the topic. For our web app, we may start with the question, “What pages are included in the application?”. In the figure below you can see how you might continue on this line of questioning to “What sections are there in each page?” and even further with “What does each section contain?”

type_flow_mapping

This type of ‘flow’ mapping is great, but don’t forget about others as well. Sometimes it makes sense to use a web for mapping so you can see how each page relates to one another. UML diagrams are excellent for this purpose and are used by a lot of software developers when they want to see how database tables will interact, but using them to map the application is just as helpful.

Artifacts

A lot of creative projects use what are called artifacts. Artifacts are things that contain or represent information in a organized way. If you wanted to write down all of your firestarting ideas on post-it notes, those would be your artifacts. Many creative project directors find that physical artifacts are easier and more fun to work with than a digital whiteboard of sorts. If you put your ideas down on movable artifacts like post-it notes, you can get physically involved with a non-physical project and that could get your team motivated to participate if they aren’t already. If you don’t have the capability to use physical media for idea artifacts, maybe you can find or create a digital analog that achieves the same results. There’s plenty of collaborative software out there like Google Drive and mind-mapping applications that let users edit the same document at once. Once you have one of those, you only need a meeting space like Google Hangouts, GoTo Meeting, or Join.me.

Be Random

It’s been said that the human brain works on patterns and that we humans will make patterns from anything. We fill in the unknown subconsciously, however, the ideas that come from your firestarting questions are undoubtedly random.

When that first question is asked, about what pages should be included in the application, the Cart, ToS, and Checkout pages are probably the first to be uttered by the team, but those pages are clearly not browsed by a user in that order, nor will they be the first pages to be coded. At this point, it doesn’t matter in what order they happen. In terms of this phase of the project, you simply want to know that they exist and what content they have. Make your patterns after you are done with the first firestarting phase, but right now, just get the thoughts on paper in any order. In short, don’t try to organize your thoughts, just let them come out. This is one of the key values in a creative project. You can always update them or have further conversation on them later.

(Un)Categorize Your Ideas

Sometimes it’s difficult to organize different ideas coming from all the team members. It may be best not to create any named charts at first. After a question is asked and all answers from each team member have been explored, create some artifacts to hold those ideas, mix them up and put them all in the same space. Next, provide two or three other areas and try to lump the ideas together using only those areas. It’s best if you do not name or categorize the secondary groupings and squash any argument that they should be categorized. At first, this is difficult, but as you put the artifacts into secondary groups, you’ll start to see a pattern and it becomes much easier. After all the artifacts have been moved, name the groups, if you even need to.

Make a Model

When you’re firestarting your project, it may be helpful to draw what the team is suggesting. Use a whiteboard or something similar that can easily be changed. One team member may say, “I think the home page should look like this…” and then draw his thoughts. Another member may say, “I agree, but we should change {this} to {that}.” and that person will make an incremental change to the drawing. In a sense, the whiteboard will be your knowledge artifact. It holds the collaborative information for the team to share and you can take this artifact model one step further by breaking it up into sections like the sections of the web application. Perhaps the sidebar can be used in more than one place, or the ‘featured product’ is a module that can be used over and over too. When you draw your model, keep this stuff in mind. Start a new fire with each smaller section of the model.

Explore the Possibilities

What can be said here? Your project is a creative one. You aren’t confined to preconceived notions of what a web application should look like or perform like. Never limit yourself. Explore all possibilities. Don’t stop at the ‘good idea’. Your creative process is a journey. Don’t stop believing.

Part 2 Wrap Up

Don’t forget that this early phase of your creative endeavor is all about exploring and nothing is set in stone except your final goal. Even if you are on a time budget, early discussion and planning are extremely important. Building a web application can have many blocking mechanisms, but if you’ve planned extensively and gone over all the ‘what-ifs’ before you begin coding, you’ll find that your project will go much smoother later on. Be sure to get all your ideas out in the open, even if no one agrees, it’s still a good idea and may be of some use later on.

About the Author:

Brainstorming a Creative Project Part 1: Getting Started

September 17th, 2014

Introduction

The process of creating something can follow a very difficult and winding path. Many people have fantastic ideas, but lack the follow through to see the project to completion. Many times, this is because there is a lack of understanding on how to go about the creative process. We unconsciously think the project will take care of itself and all we need to do is have the idea. We don’t realize the amount of work and TLC that makes a creative project what it is. Over the next few posts we’ll dive into a creative project, from beginning to end, finding out ways to approach the different steps in the adventure!

What is a Creative Project?

Creative, as defined by many dictionaries, involves implementing imagination and/or original pieces of work for an end. Usually it is defined as an artistic endeavor, but you may be surprised that many business related problems can also be solved in creative ways.

The problem you’re attempting to solve may not be as apparent to others as it is to you. If you want to make a game, the problem you are solving may be boredom, or a lack of intriguing entertainment. If you want to write a novel, perhaps the problem is that you find there aren’t stories out there that you want to read (and other people feel the same way).

If you’re anything like me, you have some great ideas for creative projects. Perhaps you have an innovative idea for a web application that could help many people, or you have a great game idea, or maybe you just want to write a novel.

In short, if you want to make something innovative or better, then your project is a creative one.

You need a team

There are a lot of things you can do on your own, but many believe that a creative project of any capacity is not one of them. To truly be creative, you need to be questioned or have the capacity to ask questions. To really make something that’s innovative you need other people. These people should be there to help you realize your project in several ways. These people need to be part of your team.

What is a team, really? A team can be two or more people who share a single purpose or goal. Team members may have a different perspective on what that goal is or even how to get there, but the essence of the goal remains the same. It’s these different perspectives your team members bring to the table that give them value. Secondly, your team is meant to be a group of people that are not afraid to raise questions about what is happening on the project.

Build your team

Picking members of a team should be deliberate. You certainly don’t want people involved that don’t share your vision. If you are the only person on the project team, then you don’t have a problem with this, but when you pick out who is going to join your creative project you need to get a feel for their intentions and whether they are going to be a good fit. Be sure to explain your goal and an overall direction of your project to better grasp if they feel the same way you do. After all, a creative project must come from a passion.

Defining team roles

In addition to simply finding people who are invested in your goal, you need to determine what kind of role you want them to play. If you want to go about your creative project on your own, understand that you must take on all the roles needed; you must be the manager, facilitator, quality assurance, illustrator, and writer all in one. You may not need all these roles, but you may need more than that depending on the scope of your project. Figure out who on the team is best suited to take on each role. You may even have someone who is dedicated to keeping the team on task and does nothing else, after all, if you’re not on task, you’re not getting anything done and your dream will quickly fade away.

Goals

The fact that you want to create something means you believe you already have a goal in mind. You want to solve a problem that you or others have. But there’s an issue: most initial goals are flawed. Yes, you certainly have an idea of what you want to accomplish, but may not have thought of how to get there. This is where your carefully picked team comes into play for the first time. Your team should be questioning your initial goal to find out if it’s really what you want. We will cover into this topic later, but having a conversation around your goal will help the vetting process and single out what the absolute goal is.

Many creative professionals understand something that others may not and that is your goal is going to change. You may not think it is, but as you and your team are developing the means to an end, you will find that your initial goal is impossible or at the very least unreachable with your current assets. You’re going to have to change the goal ever so slightly over the course of the project. Problems will arise that you did not think of or you may have altered your perception of the problem and therefore must alter your end result.

But that’s okay! That is part of brainstorming and it happens in nearly every creative (and even not-creative) projects.

Let’s say you want to build a web application. You probably already have an idea of what demographic your online solution targets, or maybe what you want is a place online to sell a product. These are very common scenarios, so exactly what is the goal of this project? Is it to simply sell a product or was there something about a web application that will make your product be more enticing? Most people might say that all web applications need a purpose and that purpose is your goal. While that’s true, think about what you wanted to accomplish when you had this creative idea in the first place. Break the original idea down into parts that don’t depend on each other.

Getting your goals on the table

To be clear, when you are trying to refine your goal, you need to try and stay away from how you are going to get there. The first couple of times that you enter the goal refining phase of your creative projects, preventing yourself and your team from entering the ‘challenge space’ can be…challenging. Refining your goal should be a conversation amongst everyone. If you find that one person is not contributing, but only agreeing or disagreeing with other suggestions, find out why they doing that and perhaps you will spawn a new line of thinking. The thing to remember while conversing about the goal of the project is to stop any line of thought that contains phrases like “what happens if…”, and any other phrase that could be linked to a process or scenario.

Fuzzy goals are one approach to refining your goal. Think about our web application project. The initial goal may have been to sell your product online. That is a fuzzy goal because it defines an end result (for customers to spend money on something you created) but remains vague enough to allow many ways to reach it.

It may turn out that your goal remains fuzzy for the duration of the project. Depending on the type of creative project, that could be just what you want. If you’re making a board game, you may say, “the person with the most points wins!”.

Process oriented goals are just as helpful as fuzzy goals. In your online store, you may want a very specific user experience and in that case your ‘challenge space’ is meant to find the path that leads them to purchase a product or that your goal is to create a very simple web application that leads users to buy something without deviation. If you have a game that needs ‘the most points to win’, perhaps you find that your ‘challenge space’ would be better served if you knew what the points represented; like, “the person with the most resources at the end wins”, where you might define ‘resources’ as money, personnel, land, or even documents. How the player gathers those resources is what the ‘challenge space’ is for.

Let’s say I have a awesome idea of producing the number 5. If I wanted a fuzzy goal I would leave it just as it is, because it’s specific but it remains yet to be seen how to reach it. If I want a process oriented goal I might say, “I want the user to add the numbers 2 and 3 to make the number 5.” You can see how process goals appear to describe 2 goals instead of just one, where one goal is partially how you got to the other. However, we haven’t quite entered the ‘challenge space’ just yet because we haven’t defined how the user gets the numbers 2 and 3. Maybe they got the number 3 first, or maybe they had to add 1 and 2 to get the 3. These are topics that the goal does not care about. In the process oriented goal type you a specific set of things to happen to reach a result. The actual goal is to add 2 and 3 together, not to produce the number 5.

It’s possible that a project does indeed have more than one goal. That’s just fine too, especially if you are creating a game that may have more than one way to win. Just be clear that you are not defining how to approach the goal.

Part 1 Wrap Up

Beginning a creative project is an awesome feat, but can also be defeating if you don’t prepare properly. Gathering team members, defining what role each person plays, and defining your real goal are probably the most important parts of the project. Remember that it’s okay to change up your goal and not be afraid to do so when it makes sense.

I’ve used the term ‘challenge space’ several times in this chapter, so in the next we’ll talk about developing the core of the project and the many ways you can go about it. This is the ‘challenge space’. It’s the area/time of the project where you define how a user, whether that be a reader of your novel or player of the game, reaches the goal you have set.

About the Author:

How Good C# Habits can Encourage Bad JavaScript Habits: Part 3 – Function Scope, Hoisting, & Closures

October 21st, 2010

This is the third post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

The first post covered the following topics:

  • 1. Having Variables & Functions in Global Scope
  • 2. Not Declaring Arrays & Objects Correctly

The second post covered the following topics:

  • 3. Not Understanding False-y Values
  • 4. Not Testing & Setting Default Values Correctly
  • 5. Using the Wrong Comparison Operators
  • 6. Not Using the for…in Statement Correctly

Introduction

This post continues to focus on areas where C# developers tend to make bad JavaScript decisions based on their previous training. The languages are similar enough syntactically that C# developers tend to not invest the time to learn JavaScript’s differences.

The following post points out several misunderstandings that can get you into some confusing situations.

(more…)

About the Author:

How Good C# Habits can Encourage Bad JavaScript Habits: Part 2 – False-y, Testing and Default Values, Comparisons, and Looping

October 13th, 2010

This is the second post in a multi-part series covering common mistakes C# developers tend to make when they first start writing JavaScript.

The first post covered the following topics:

  • 1. Having Variables & Functions in Global Scope
  • 2. Not Declaring Arrays & Objects Correctly

Introduction

This post continues to focus on areas where C# developers tend to make poor decisions when writing JavaScript based on their previous training. The languages are syntactically similar enough that C# developers tend to not invest the time to learn JavaScript’s differences.

The following post points out several misunderstandings that can get you into some confusing situations.

(more…)

About the Author:

How Good C# Habits can Encourage Bad JavaScript Habits: Part 1

October 7th, 2010
This is the first post in a multi-part series covering common mistakes C# developers tend to make when they first start learning JavaScript.

Introduction

Many people come to jQuery and believe that their knowledge of a previous classical language (C#, Java, etc) will help them be successful at client-side scripting. You can use your classical language skills to accomplish a large amount of functionality with jQuery. However, the more client-side code you write you will find yourself uncovering strange bugs because you didn’t take adequate time to learn JavaScript properly.

“…it turns out that if you have absolutely no idea what you’re doing in the language you can still generally make things work.” –Douglas Crockford, Yahoo!’s JavaScript Architect, Douglas on JavaScript — Chapter 2: And Then There Was JavaScript

This article is targeted for developers that use jQuery but haven’t invested the time necessary to learn JavaScript. The intent is to help you avoid some common mistakes when moving from a classical language (Java, C#, etc) to JavaScript.

jQuery is a library that is written in JavaScript. It is important to remember that you will always be writing in JavaScript when using jQuery. It is inevitable that you will run into native JavaScript concepts that are foreign to the classical language proficient developer. Taking the time now to be proficient in JavaScript will increase your client-side code quality, efficiency, and decrease code maintenance.

(more…)

About the Author:

Creating an Ajax Component:Handling Errors and Loading Notifications with Publish and Subscribe

September 28th, 2010
This is the second post in a multi-part series on creating a JavaScript component for handling your Ajax requests in front-end development across your enterprise. You can find the first post here:

In the last post we covered some introductory topics for creating your own JavaScript utility library, which wraps functionality for Ajax. We’ll start where we left off. Our first step will be to add a few tweaks to our library to make it more usable:

var mySiteAjax = ( function( $ ) {
  return (
     function( params ){
      var settings = $.extend({
        url: "",
        spinner:  undefined,
        dataType: "html",
        data: "",
        type: "GET",
        cache:  false,
        success:  function() { }
      }, params );
 
  $.ajax({
      beforeSend: function() {
        $( settings.spinner ).show();
      },
      url: settings.url,
      dataType: settings.dataType,
      type: settings.type,
      data: setting.data,
      success: settings.success,
      complete: function() {
          $( settings.spinner ).hide();
        }
    });
}
 

);
})(jQuery);

We’ve done two things to our old example. We’ve added new parameters for type and data that could be passed in. Additionally, we’ve removed a named function and returned an object literal. This enables easier usage:

mySiteAjax({
  url: "myUrl",
  success: function( data ) {
    //do something with the data here
  }
});

Although a good start, this solution is not yet satisfactory as we are not yet handling errors in any capacity. How do we handle errors and display messages to the user? Additionally showing and hiding of loading notification images is present but not customizable. What if a page doesn’t want to do a simple showing and hiding of load images? How can we decouple the notifications from our Ajax component library?

(more…)