Recently both Jeff and I were asked to contribute to an article in this month’s How Magazine about working on projects that conflict with your personal ethics. Although I was just ever-so-slightly misunderstood by the writer who summarized that my “primary motivation is making money”, says article, I was thrilled to contribute. Now do not get me wrong, I like many other business people am excited by a healthy margin, but for crying in the night it is not my motivation, let alone my “primary” one.  If that were the case wouldn’t I be dealing in hedge funds or commodities or something like that?  But hell, how often do you get asked to contribute to such a great magazine, and maybe even more valuable to me, I now get to complain about being misrepresented (the italics represent a sort of douche bag tone in my voice).  So that’s something too.

Thankfully for the internet I have the luxury of publishing what was sent to them as my true views on the subject, and thankfully for my not-so-very-prolific-blogging-career, I have an article “in the can”.  So here goes:

Quite simply put, it is the designer’s job to visually convey the message they are hired to deliver.  A lot goes into doing that well, and being diametrically opposed to a project’s purpose definitely would not help.  So then even if a designer did try to set their personal beliefs aside in the spirit of “gettin’ the job done,” at what point does that become irresponsible and a disservice to the paying party?  No matter how much you loath the purpose, to me that plain disservice becomes its own isolated case of ‘wrong’ as a business value.

To me I think a number of things go into considering an assignment, and certainly personal morals and values are not the least of which that would play a part of that filter.  Obviously the more typical filters for me as the CEO are, will it enhance our brand, is it financially responsible, will it burn out the team, do we like the idea, etc…Normally the project’s nature is much more innocuous then offensive to any set of morals.  You know, selling a backpack, an mp3 player, a piece of software, and so on.

Being of the more independent mind set, I would provoke any designer, or anyone else for that matter, to simply turn down what they want to turn down for opposing any personal moral or value.  Certainly freelancers have that liberty, and as an employer I give my team that same liberty.  Now sometimes we disagree on whether a project is good for the company, and we listen to those opinions as well.

Earlier on in our history we did get approached to do a couple projects that did in fact oppose my personal beliefs.  I think I’d prefer to not get into the nitty gritty as to what and why, but they started somewhat harmless.  We took the projects, and as they progressed through development, the projects became more and more opposing.  At first I simply personally backed-off from offering my help.  One of which we finished, although I would argue not our best project ever (serving my earlier point), and the other we resigned.  From those experiences I know now to stay away from projects I do not believe in.  But again, that encompasses much more then morals and values these days.

2009 had been a challenging year for all of us.  And in a year that I would of expected to take any paying project, we have turned down more then we ever have.  That does not mean every project is a party, but it does mean to choose whether or not to accept it through some sort of filter that you (either as an independent or agency) have defined so that you, your team, your portfolio, or your bottom line is served, and then in turn the client is best served.

This morning I was watching a video about an application for the digital version of Wired magazine for tablet computers. This app is the result of a partnership between Wired and Adobe to make a compelling counterpart to traditional print magazines.
Read the rest of this entry »

In lieu of Christmas gifts, we here at Buk decided to embrace a great America commercialized holiday and send our clients and partners Valentines instead.

If you did not receive one of these little diddys, one of three things could be possible:

1. We totally blew it and forgot you

2. You are on our shit list

3. We just started hanging out and we are not on kissing terms yet

Either way, much love. josh

One of the services we provide here at BKWLD is producing brand new sites for our clients. One of the difficult things about a brand new site is getting the word out about it. I’m mainly a developer here, so I thought it might be a cool exercise to research more about SEO (Search Engine Optimization) and put it into practice on a new site we’ve built for our new product, Elastic.

About Elastic

Many of our clients are in the “Outdoor Sports” category. Elastic is a software tool that ties together retail dealers to the sales representatives of our clients so dealers can easily order product for their stores directly from our clients. Currently, the market consists of paper based order forms, catalogs, and phone calls for inventory checking. Some of the bigger players in the industry have their own custom software solutions for this, like Trek or Burton, but they can be a little unwieldy and they only work for the one brand. Other competitors in this space force clients to adhere to their limitations and conventions. We recognized an opportunity here, so Elastic was created.

Elastic is based on Adobe Air technology, so the software runs on the desktop (Mac or PC), but  can also run in an offline mode. We designed it this way because typically sales reps would have the software loaded up on their laptop and bring it to the dealers directly. WiFi isn’t exactly pervasive yet in these environments, so always having an Internet connection is not an option. Sales Reps also travel a lot, so not relying on the Internet directly keeps them productive on the ground or in the air. Once the sales rep reconnects their laptop to the Internet, orders are placed and inventory totals are synced.

After the break we’ll get into it!

Read the rest of this entry »

WebGrind is a great tool for analyzing your PHP app and finding where slow down is occurring.  As stated on the Google Code site for the project, it is a “ Xdebug profiling web frontend.”  Here’s the steps I took getting it working in MAMP.

Install xdebug (taken from debuggable):

1. Download the latest Xdebug binaries for your OS from Komodo.  They will be labeled as “PHP Remote Debugging” for Mac OS X.  When you unzip it, you’ll see the xedbug.so file.
2. Copy the xdebug.so for your PHP version to your extensions directory (/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so)
3. Find your php.ini file (Applications/MAMP/conf/php5/php.ini)
4. Add the following lines to your php.ini configuration (MAMP):

[xdebug]
zend_extension=/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20050922/xdebug.so

Enable xdebug
Note, you don’t want to do this in a production environment.  Add the following to your php.ini file:

xdebug.profiler_enable = 1

Install webgrind (from the install wiki)

1. Download webgrind
2. Extract to a directory in the web root
3. Browse pages of your site
4. View the directory webgrind lives in.

That’s it!  There is some useful additional ini settings I found in this blog post:

# Set the filenames generated by xdebug to use REQUEST_URI instead
# of the apache process number
# so all requests to the same page end up in the same file.
xdebug.profiler_output_name = cachegrind.out.%R
# Set xdebug to append data to files instead of overwriting,
# this means you can view aggregate
# function calls over multiple requests.
xdebug.profiler_append = TRUE

I’ve already found some major instances of slowdown that can be cleaned up in the application I’m testing.

The SEA office flew down to Sacramento before the holidays to meet in person as a group, plan the next year, and have fun together over 4 days.  My shoulder was (and is) out of commission (bike accident) so I missed this years ski trip to Tahoe; it sounded like everyone got along fine without me though.  Going up to Tahoe is sort of a BKWLD tradition at this point, I think this was the 4th or 5th time.   Of all the photos I took, these came out the least blurry, which is pretty sad.  If someone with more skills and a better camera has some shots, please replace mine in this post!

Happy New Year everyone, looking forward to an amazing 2010!

Amen!

Brace yourself – a lot of the people at BKWLD play and love video games. I know, shocker right? From PC to consoles, to MMOs to handhelds, like most interactive shops and people of our age group, we all play and love games. So it’s no surprise that we enjoy making online/web games, whether as full fledged mini-sites, or in banner ads.

Recently we were interviewed by .net Magazine and one of the questions was what sort of things we felt made an online/web game successful. I enjoyed the question, and thought I would expand on it a bit in a blog about what Robert and I shared with them.

We basically boiled it down to four points we felt made for fun and success.

1. Competition & Recognition
If there’s one thing Twitter, Facebook and frankly, this blog proves, it’s that people love attention. Even while I am typing this, I am hoping you are enjoying reading this! So it’s not a surprise that people love to see their name at the top of a scoreboard, or to blast on their ‘wall’ that they just gained a level in Farmville. A game that doesn’t allow someone to ‘tell a friend’ about their score and challenge that friend to beat them is missing out.

2. Variables
I remember about 4 years ago we made a game for the California Tourism Committee that had you skiing against Governor Schwarzenegger down a mountain. Almost immediately, every high score on the board was “14 seconds”, because once you figured out the best path, that was the absolute best score you could get. Not very fun.

So by adding in some crazy score multipliers or jackpots, and things that might only show up in 1 out of every 100 games, you’re easily injecting not only variability, but also giving players a reason to keep trying.

Additionally, throwing in ‘bad’ items like point subtractions also helps make the game not about just trying to gobble up every item on the screen, but gets a little strategy into play.

3. Incentives
This is probably the most obvious of them all, but when someone is playing for an iPod/Corvette/cheeseburger, they are going to play. And play. And play. And tell their grandma to play too.

I think giving stuff away should be two pronged though – give something to the best, but also just give something randomly. In other words, you can give the Corvette to the person with the highest score, but also have 2nd and 3rd place prizes, and even a ‘boobie prize’ where any person who plays, has a chance to win that cheeseburger.

4. Keep it simple stupid
There’s a time and a place for an 80 hour epic gaming adventure. And that place is certainly not in a 300 x 250 banner on yahoo.com. If ever there was a time for a game to be ‘pick up and play’ it’s when it’s a banner or a minisite game. I think a good rule of thumb is if you need more than one page of instructions, it’s going to be too complicated for a ‘casual gamer’ and not complicated enough for a ‘hardcore gamer’.

Overall, there’s plenty of examples however where a game shines in just ONE of these categories, and that’s enough to keep people playing. But if you try to intertwine all of these into your next game (and let’s not forget about the actual ‘design’ of the game) you should have a winner on your hands.

We love making games, and for a while we always had at least one in development.  The demand has waned in the past year as companies focused on more direct kinds of marketing.  Here’s hoping we get more excuses opportunities to make games in the new year!

PS – here’s some of my faves we’ve done over the years.

• http://funnevergrowsold.com/game/
• http://www.whodouwant2b.com/game/
• http://yourcowtown.com/game/index.htm
• http://bkwld.com/work/indiana-jones-the-staff-of-kings
• http://www.firstbank.bkwlddev.com/728×315.php

Those familiar with the Mac OS dock will know that clicking the dock icon of a minimized application will restore that application to it’s pre-minimized state. This is a nice little feature as the minimize/tray area of the dock can quickly become a disorganized mess if you keep a lot of apps open. Those familiar with developing AIR apps will also know that AIR apps don’t do this out of the box. This kinda sucks.

Fortunately there is a fairly easy way to implement this feature for yourself. All you need to do is setup two event listeners and two properties.

The two properties you need are “isMinimized” and “isMaximized”. Both are booleans, the first indicating the application is … drumroll … minimized and the section maximized. While you could get away with just one of these having both offers more flexibility in the future should you need it. For example: it is possible for an app to be neither maximized nor minimized.

The two events you need to listen for are NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING and InvokeEvent.INVOKE. The first event is dispatched when the application’s display state changes (i.e., when maximized or minimized). The second is dispatched when the dock icon is clicked.

With those few things all you need to do now is a few start up things:

/**
 * Event handler for the application's creationComplete event
 */
private function init():void
{
         // Check to see if we have a dock available for clicking
         if (NativeApplication.supportsDockIcon)
         {
               // Wire up a listener for the dock icon's invoke event
               NativeApplication.nativeApplication.addEventListener(InvokeEvent.INVOKE, onDockIconClick);
         }

         // Effectively, listen for minimize and maximize event.
         this.addEventListener(NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING, onChanging);
}

/**
 * Event handler for display state change events
 */
private function onChanging(event:NativeWindowDisplayStateEvent):void
{
      switch (event.afterDisplayState) // <-- our new state
      {
	case "minimized":
		isMaximized = false;
		isMinimized = true;
		break;

	case "maximized":
		isMaximized = true;
		isMinimized = false;
		break;
	}
}

/**
  * Called when the dock icon is clicked.
  */
private function onDockIconClick(event:InvokeEvent):void
{
	if (isMinimized)
	{
		// If the app is minimized call this
		stage.nativeWindow.restore();
		isMaximized = true;
		isMinimized = false;
	}
}

In the above code it’s assumed that init will be called by the app’s creationComplete event. init then checks to see if the platform on which the app is running supports dock icons (that is, is Mac OS). If it is we add an event listener for the InvokeEvent which is dispatched when the app’s dock icon is clicked. After that init wires up a second event listener, this time listening for the NativeWindowDisplayStateEvent.DISPLAY_STATE_CHANGING event. This event is dispatched when the app is minimized or maximized.

onChanging is our event handler for the display state change event. We use this method to keep track of whether our app is maximized or minimized. onDockIconClick is our event handler for the app’s InvokeEvent that will be dispatched when the dock icon is clicked. This method checks to see if the app is currently minimized, and if it is it calls the window’s restore method.

Adobe AIR is a great tool for quickly creating cross platform desktop applications.  For the most part you can code once and deploy on any OS that AIR supports and you app will look and feel like a native app.  There are a few caveats of course and one of them is working with menus.  In particular menus are handled somewhat differently in Mac OS than they are in Windows. This post won’t get into the nitty gritty of actually creating and modifying menu items as that is covered quite nicely in Adobe’s documentation on the subject, but I will tell you how to create native menus on Mac OS that are indistinguishable from those of native Mac apps.

First, the Differences

In Windows menus belong to each window. So File, Edit, View and such are items in each open window of an application. In AIR this corresponds to the menu property of a NativeWindow.

In Mac OS the corresponding menu is called an application menu and there is only one for all windows of the application. In AIR this corresponds to the NativeApplication’s menu property.

So what you say? AIR has features that let you handle Windows vs. Mac menu differences quite easily. This is true, a quick check of the docs will reveal how quickly this can be accomplished. However, you’ll notice in the above screen grab that application menus on Mac OS list the application name in bold. There is nothing in the AIR docs about how to accomplish this.

What To Do?

You can just ignore this and create a menu like the (quite nice) SQLite administration tool Lita. Note Lita has “Lita” in the menu but it’s not bolded.

Or you can not even bother with the application name like the (also extremely useful) MonsterDebugger.

Both of these approaches are completely valid. After all both Lita and MonsterDebugger are incredibly useful applications that make my life as a developer much easier and lacking a proper Mac OS application menu doesn’t detract from their utility in any way. However it’s also quite simple to create application menus that look identical to a true native application.

Creating Seamless Application Menus For Mac OS

It’s so simple to create seamless application menus on Mac OS that you don’t even have to do anything! That’s right, just create an application and AIR makes one for you:

Everything you see above you get for free (note: adl is the AIR debugger. If I were to publish a release build and install the application you’d see the name set in the application descriptor xml file). You might now be saying that this is all good and well but what if you want to customize the menu at all? The good news is you can, it just take a tad more work.

To start you’ll need to note that AIR gives us three menu items in addition to the “Application Name” item (the bold one). For this example I’ll assume you’re only interested in keeping the app name item so we’ll just get rid of everything but that one.

First you’ll need to get a reference to the application’s menu:


// Get a reference to the NativeApplication's menu, if this is Mac OS
// Note: you'll need to handle menus differently if you are on Mac OS or Windows.
// See the AIR docs related to creating native menus for details.
if (NativeApplication.nativeApplication.supportsMenu)
{
var appMenu:NativeMenu = NativeApplication.nativeApplication.menu;
}


If you were to loop over this you’d see all of the menu items from the above screen grab. You’ll also notice that each of the items is a NativeMenuItem (more on this later). Since we only want the first one we can now remove all the others:


// Get rid of our unwanted menu items
// The app name item is the first one
while (appMenu.items.length > 1)
{
menu.removeItemAt(menu.items.length - 1);
}


At this point our menu consists of one item: the application name menu item. This menu item is pre-populated with some standard elements like “About” and “Quit”. If you’re happy with this as-is, you can now freely add your own menu items. If you need to customize this application name menu item a bit simply take advantage of the fact that it’s a NativeMenuItem and go nuts.

Using this method you’ll now see your application’s name (that is, the name you set in the application descriptor xml file) up in bold when you publish a release build and install. Here at BKWLD we’ve recently used this technique and here are the results: