A common mistake that I read on blogs is when it comes to today’s “modern” user interfaces: fewer features we offer to the user’s interface the better… make it simple! This common misconception is happening in some of even the largest software companies. For example, the Windows Vista defragger changed dramatically from XP as it is now a single button… no options, no status, and no detailed view on defragmentation process. Hence, you click this button to start the process- only to end up waiting hours while it drills on with little options or any understanding on what is happening. What if the user just wanted a ‘fast’ defrag and doesn’t want to wait a lengthy process at the time…. maybe they want to defragment a single file. I believe fewer interface elements are better- NOT fewer features.

The future I would say is intelligent interfaces that adapt to user’s expectations. The application’s functionality should be able to tailor itself to the user’s expectations. Users want interfaces that are simple to use but powerful in functionality. However this usually translates into a UI that understands the user and knows the correct action to take at the time they are called. One of the primary reasons why the iPhone become popular was the simple interface was able to perform a hefty amount of functionality. Just as Google will customize search results based the user’s history like showing restaurant matches in your area in the order of perceived user food preference, GUI interfaces should try to adapt to their user, consolidate similar functionality, and choose the correct action in the appropriate situation.

With that, I close this Friday with Psychologist Barry Schwartz’s speech from TED talking about peoples distress from having too many options available to them at any one time. Options are good I believe… just not when they are all advertised (viewed) as equal options to choose from. Obvious solutions for individuals should have priority above others to avoid frustration… but elimination of options I believe is not the right answer here.

Tags: theory

One of the most fascinating concepts I believe in programming is recursive logic (aside from reflection which I will be posting about soon, but I digress). Recursive operations are pieces of functionality that can execute themselves until a desired outcome is achieved. For example, what if you had a random number generator from 1-100 but did not want to include the number 17 if it was chosen? The function could check to see if the random number made was 17 and re-call itself to choose yet another number. Buiding on this idea, quicksorting is a programming methodology for reordering arrays based on value using recursive techniques. The concept partitions out pivots from an input array and recursively rearranged each partition until the entire array is sorted.

Tags: theory

What most users overlook from what I can see on forums and written articles is on the subject of unit testing functions that produce inherently non-concrete returns. For example, how would one go about unit testing a function that generates random numbers? It would be futile to try to only gaged a single outcome of the function as there is no way to anticipate what the return would be. However, this is where pattern matching comes into play. If the function is designed to generate numbers 1-100, run the function 100,000+ times and analyze the results. Did the function return a number higher or lower than 1-100? Did the function return a unique number way more times than randomly likely (for example, the number “20″ was returned 50,000 times)? Was a non-number or decimal number returned? Did each call to the function become progressively slower indicating a memory leak?
While this was a simple example, do not be discouraged of making a unit testing against something seemingly chaotic in design. Most things that seem random are usually rather predictable when viewed from a distance.

Link to Flash and Flex Unit Testing package: http://code.google.com/p/as3flexunitlib/

Tags: theory, unit testing

While working on a class recently, I have discovered an interesting design pattern where a singleton class is able to create instances of itself to perform RPC actions. For example, you could create a singleton called

LoadAndPlaySound.gi.play(
          url:String,
          onLoad:Function,
          onSoundPlayed:Function)

This class would then be able to create an instance of itself for handing the loading process for the sound, any manipulation, or other processes like handing storing and executing callback variables. You will need to lock down the singleton using a kind of enforcer technique so that only the singleton can replicate itself.

Disclaimer: I general do discourage singletons though as if used improperly (like stuffing every variable in an application into it for the point of easy access), it can cause more headaches than they relieve.

Tags: theory

I have been musing about the best practical way for giving NPCs (non player characters) a clear set of directives for living in its environment using simple AI logic. Based on the notion that any character’s environment is dynamic, en-queuing a character’s broad set of daily actions seems impractical. Instead, it would seem more logical that a NPC is assigned a range of actions they are able or willing to perform and given a rule on when they are ‘prone’ to each action based on different weights. For example, instead of having a NPC eat exactly three times a day, the NPC would have a hunger counter and when the value reached so high- they would seek out food. This would allow a higher dynamic range of actions for the character as they could eat more or less during the day based on things like how much physical activity they where doing or if they ate something that reduced their hunger for the next meal.

Tags: theory

Science&Code: Actionscript optimization

Posting on FinalFinal.com on the makings of the Red Invaders Flash Game.

Casual Game Development Blog – Techniques and Algorithms (most theories can be applied to Actionscript)

Tags: as3, theory

After pondering the matter, an example API for such a function would be:

function subscribe():void {
   Pipes.get("chat pipe").subscribe(callBack);
   // See below for the callBack function that
   // gets executed when a message is sent
}
function callBack(message:*):void {
   // Maybe when creating a pipe, it would be
  //  possible to lock the message type?
}
function sendPipeMessage():void {
   // creates a new pipe is one doesn't exist
   var myPipe:PipeSender = Pipes.get("chat pipe");
   myPipe.send(someObject);
}
function joinOrSplitPipe():void {
   Pipes.get("chat pipe").join("ui pipe");
   Pipes.get("chat pipe").split("ui pipe");
}

So you might be thinking the same thing I was… why use pipes over event listeners??
Well, here are the pros and cons that I can see off-hand…

Pipes function the same as events except:

• Pipes can reach any level of the application… not just parents like events do when they bubble
• Pipes can be setup to enforce a one-way message system to an API or client class
• Pipes can be merged or split
• Pipes can be layered easily by using a new set of unique ids for the pipes. Events, on the other hand, bubble around the application globally climbing up parents which can cause major issues in an application that requires an easy reset, duplication, or tiered structure.

Link to the original article: Pipes theory pt. 1

Tags: theory

Joshua Ostrom posted an interesting article about using PureMVC Multicore with ‘Pipes’. After reading over the implementation, I have to say that there seems to be much easier ways to accomplish what they are trying to do.

With the ‘pipes’ concept, the following conditions need to be met I see:

1. Pipes are only one way
2. Pipe subscribers listen to the pipe for messages pushed through
3. Pipes can be merged together or split
4. For organization, pipes should have a reference lookup string so that application layers can be used

This pipes theory really intrigues me… I will post again on this to suggest with what I can envision as a more straight forward API.

Part 2: http://www.jadbox.com/?p=161

Tags: theory