Why subscribe to the SDW newsletter?

  • Insight on business technology trends and news.
  • Case studies on ground-breaking innovation.
  • Invitations to SDW events and webinars.
  • Other worthy dispatches from our expert team.
  • No spam. Just cool stuff.

Please leave this field empty.

Go back to skookum.com



Simple Game Physics @BarcampClt

With html5 gaming initiatives popping up all over the place, many web developers will soon build their first game. One of the most common pain points for new game developers is physics, so I demo’d a simple game physics primer for Barcamp Charlotte.

Working Demo

It implements some of the most common game physics in a minimalist fashion for new html5 game developers. Check it out.

(also includes more complex examples)

If you’re interested in the Barcamp Charlotte Un-conference, which is part community-building and part presentation-making, check out Jeremy’s coverage of the day’s events.

Leave a comment

Practical canvas test, CharlotteJS

While developing canvas code for clients and demos, I discovered through painful trial-and-error that, in canvas, many paths can take you where you want to go, but at hugely different speeds.


Working Demo

Practical-canvas-test implements canvas rendering of a particle simulation, benchmarked with a practical set of real-life drawing operations. Some initial findings from CharlotteJS:

Clearing Techniques

clearRect (0, 0, canvas.width, canvas.height)

The standard, documented method. Fast on a small canvas (say, 600×400), slows down quickly once you start fullscreening your rendering surface.

canvas.width = canvas.width

Undocumented, works like clearRect, but much faster. Aliasing bug in Chrome can leave trails; to fix it, just draw one clear pixel in the upper-left and one in the lower-right (#hacktastic).

clearRect on individual sprites

Blazingly fast with a relatively low “total sprite widthxheight” value, slows down as sprite number/size increases. The trick here is to build object-oriented sprites that can both draw and erase themselves. Then, follow a standard clear, update, draw loop and you only erase the “dirty” parts of your rendering each frame. Try the canvas test with this method and run through low/high number of sprites to see the effects.


Using images behind your canvas (instead of solid fills) has only a minor performance impact, except in Chrome, which totally chokes. Strangely, Safari handles background images fine so it’s Chrome’s issue rather than WebKit’s.

Force integers

A few people suggested I round drawing operations to integers for performance; as far as I have tested, this delivers no speed increase. However, the nature of this simulation uses a matrix rotation which will generate floating point transformation results, so maybe this tip is applicable in non-scaled, non-rotated scenes.

Alpha Fills

< 1.0 Alpha values give a very small performance penalty when used excessively.

CSS Transformations vs Canvas transformations

<canvas>, like <img>, has both native pixel dimensions and properties and applied css layout. However, applying dimensions and effects to a canvas via css enormously decreases overall performance.

Please test your own browser/OS combinations and leave feedback to help guide the community in high-performance canvas implementations!


2 Things I don’t like about NodeJS

First, let me say this: most of the projects I’m doing these days, I’m cobbling together with NodeJS + ExpressJS. I welcome JavaScript to the server-side and I enjoy the simplicity of Express’s Sinatra imitation.

However, there are a handful of things that bug me about Node. Here are two that bothered me this morning:

  1. To me, that’s kind of ugly. I see this in most peoples’ code and it seems to be the accepted idiom in Node, but I could see this as a turn-off to many.

  2. I also get error messages that I consider unhelpful at finding exactly where I went wrong. For example, this error began at the line:

    … which is my code; I would love to see that at the bottom of the stack trace, but instead it starts with “Module._compile,” and errors on a library function that I didn’t write. I’m sure there’s a good internal reason for this, but to me it’s frustrating for debugging.

I’d love to hear tips on either issue. Back to coding for now…


Get App Savvy

I have been working with O’Reilly author Ken Yarmosh for the past six months as a technical reviewer and contributor for his new book App Savvy: Turning Ideas into iPad and iPhone Apps Customers Really Want.

App Savvy is the definitive guide for launching successful iPhone apps. It is chocked full of practical advice on vetting app ideas, differentiation, building a team, marketing, and more. Along with Ken’s insights from his own experience building apps, he has included interviews with nearly thirty of the most successful folks in the field.

If you’ve ever wanted to hear more about how I marketed my own app, Grades, you can find an interview with me in the chapter on marketing.

Read my full review over on my personal blog and pick up a copy of App Savvy for $20 on Amazon – you won’t regret it.

Leave a comment

Your company should NOT build an app

If you know me, you are probably itching to know why on earth I would write an article with such a title.

I am the iPhone guy. I am heavily involved in an upcoming book about apps. My future is altogether wrapped up in the app business. I admit, the title is a bit hyperbolic so please read to the end—this article is really about determining the best possible mobile strategy for your brand. It could save you a lot of pain.

Craig Hockenberry recently wrote an excellent article entitled Apps vs. the Web. He outlined some great reasons why web developers and companies should be motivated to bite the bullet and eat the initial extra cost of learning native iPhone development—Objective-C, Cocoa, the iPhone SDK—rather than simply optimizing their website for mobile using standard web technologies. It boils down to three things:

1. Native apps generally have the better User Experience—faster, smoother, familiar, more functional.

2. Native apps are easier and more efficient to code and maintain in the long run and have fewer technical limitations.

3. Native apps have the marketing advantage of being in the app store marketplace and are easier to make money from due to Apple’s seamless, built-in payment system.

I agree with all these points and as an iPhone developer, hey, more power to me if companies decide they need a native solution.

With articles like this one from Wired which says “The Web is Dead” the app frenzy is at full boil and all of a sudden every company NEEDS a native iPhone and Android app. Please don’t get me wrong. I love apps — they are my passion. Your company very well may benefit from an app and don’t be shy about asking Skookum to help you build one.


I feel like one matter still needs to be addressed, a word that is often overlooked but too important to ignore:


Apps require commitment. Web apps don’t—at least they don’t require as much, usually.

To use an app I need to be passionate enough about the brand to

  1. Know that the app exists
  2. Search for it on the app store on my device
  3. Pay for it or at very least type in my iTunes password to get it for free
  4. Wait for the app to download to my device
  5. Tap the app and hope I don’t have to sign up for an account
  6. Be okay with the fact that this new app just clogged up my home screens that much more.

I’m okay with doing that for apps that I am very passionate about or think I could be passionate about, but get ready for this, it could be devastating:

Maybe I don’t LOVE your brand.

Not that I don’t like your brand. Hey, I actually like Wired. I don’t have their app, though. I’m not passionate enough about that brand. In this case, though, I know Wired has thousands of dedicated readers who *are* passionate about their brand. They know they get value from Wired so downloading the Wired app is a no-brainer.

Unless you are Wired, though, you really have to question, does my brand have enough followers who would be committed enough to download and keep my app? Don’t overvalue your brand. It is very likely that your semi-known brand or the niche brand that you are working for simply doesn’t have the passionate following that would make it worth shelling $20,000 for a custom built app that is essentially a mirror of your webpage. Think about your users: realistically, do they access your content or service frequently enough for them to download your app? Or would they prefer just to visit your website and be delighted to see that it works great on their mobile device?

Don’t build an app…

An icon in the app store is meaningless unless enough people are passionate enough about your brand’s content or service to download and keep it.

…Build a remarkable app

So say you don’t have enough fans who would go and download your app simply because they love your service. Don’t get discouraged — this is actually a tremendous opportunity. Instead of “my brand needs an app”, you should ask “how can my brand build an app that a lot of people would really want to use?”

Let me illustrate. IMPACK Productions did it right. They didn’t say, “hey, we need an app so that potential music students can learn more about our studio right from their iPhone!” That is the kind of thing I am warning you against. Think about it, potential students aren’t searching “voice lessons” on the app store, that is what Google is for. They don’t want an app to learn more about your company; they want a website for that.

So what did IMPACK Productions do? They partnered up with Kimad Productions and a talented designer and built Voice Tutor, an amazing app that does on the spot voice training. It was beautiful. It was unique. People talked about it and it even got featured on the app store home page. Brilliant!

Instead of building a self-centered, brand focused app, IMPACK Productions used their expertise to produce a unique app that did something people really wanted. It worked. They not only sold lots of copies but I’m sure more than a few people checked out their professional lessons after going through the lessons in the app.

Bottom line

Apps require a greater level of commitment than websites. Don’t build a self-centered app unless a lot of people care about your product or service enough to make it worth it. Instead, use your expertise to build something unique — something that meets a real need on the app store. Making a killer app could do wonders for your brand. The question then is, how do you build and market a killer app? That, my friend, is something I will be addressing in the future so don’t touch that dial (i.e. subscribe to this blog).

Leave a comment

Atlantic General Hospital: There’s an app for that

Atlantic General Hospital follows a 30-minute ER promise to ensure all patients will start to receive care within 30 minutes of arriving to the hospital.

This promise is a great step towards better patient care so we wanted to work out a way for people to access the times regardless of where they were.

Before starting the project, we worked with Mullin/Ashley Associates to develop 3 goals to keep in mind:

  • Make the hospital data available across as many platforms as possible
  • Create a way to push updated times to the user
  • Immediately display only the information necessary, allowing faster download speeds and quick access

AGH in the AppStore

The matchup: BlackBerry, Android, & iPhone

We started with the goal to make this app work universally on different platforms from the start. Team iPhone and Android battle it out in the office, but we couldn’t forget about the BlackBerry or all of the other mobile phones that have a poor excuse for a web browser. To achieve this, we started by building a fallback web app that can be navigated as a webpage optimized for mobile browsers.

To give a more native experience on the phone we decided to go out and make a version freely available for download in the appropriate app store. The most difficult part of the development process was to make the app look and function as similarly on all the platforms as possible. Apple has very strict user interface principles that we had to follow, when others like BlackBerry and Android have less strict policies.

The Command Center

It was vital that all of the apps use the same calculated waiting times, this way we would know that each phone would display the same exact information. We decided the best way to do this was to use a custom API (Application Programming Interface) that would do all the heavy work for us. With the processing done in a centralized location, we could then call this from each of the mobile devices. In order to keep it as lightweight as possible, when the app requests updated times, only the necessary information is returned.


After Apple?s team of reviewers carefully examined the app, all of the versions were ready to go! In order to easily download the app we created a QR code that can be scanned right on a phone to take users to a download page. Left with a lightweight app, the final product displays the times for the ER, X-Ray and Lab Services. It fetches time updates twice a minute to ensure the estimated wait times are as accurate as possible. We’re proud of the results and glad that the community has taken interest in this mobile friendly initiative from the hospital to better serve their patients.


Custom Mapping with SVG and RaphaelJS

This week we faced a very interesting challenge; to create a custom designed map that supports plotting points given their latitude and longitude. There were a couple of caveats that made implementation difficult…

  1. Due to it’s custom design, the map could not utilize the Google Maps nor their API.
  2. The map only represented the United States.
  3. The states of Alaska and Hawaii were to be moved.

The Problem

The problem with developing a map meeting the aforementioned criteria and supporting plotted points may not at first be apparent. Given specific coordinates, the Google Maps API is able to easily plot points due to the fact the map references the entire world. The world map utilizes a very specific projection, the Mercator projection, which enables mathematical calculations for converting coordinates to points on the map. Quoted from Wikipedia:

While the linear scale is constant in all directions around any point, thus preserving the angles and the shapes of small objects, the Mercator projection distorts the size and shape of large objects, as the scale increases from the Equator to the poles, where it becomes infinite.

In order for us to apply coordinate conversion calculations, we would have to find a suitable map in the Mercator projection. Not only would we need a map of the United States, but we would also need a map of the entire world to use as a reference point for our calculations. Given these two maps, we would have all of the tools necessary for calculating [x,y] coordinates for plotting map markers on the custom map.

The Solution

Given the task of finding both US and world maps in Mercator projection which were proportionate to one another proved to be quite a task. Eventually, we settled upon using a very nifty service called indiemapper. Indiemapper has a default bank of SVG maps which can be loaded, heavily tweaked, and exported for further modification in Adobe Illustrator. What we did is load both a world map and a country map overlay and export to SVG. This is what gave us the referential scale of the United States to the world for calculating coordinates.

With this new map, we shifted the United States to a position of [0,0] within the world map and calculated the [x,y] delta. The delta values were to be used to transpose marker points from their initial calculated position to their new position. The next step was to copy the United States and create a new independent SVG. We could then utilize an algorithm for calculating a [lat,lon] to [x,y] conversion and shifting the resulting point with our calculated delta values. The algorithm itself is based on the dimensions of the entire world map in Mercator projection. Since we only wanted to display a map of the United States, it only makes sense that we’d position it at an offset of [0,0] and transpose the calculated point to this new position.

Converting the SVG to RaphaelJS

In order to get our SVG to display properly in current browsers, we needed to implement a solution for converting the image to a canvas element. This is where RaphaëlJS comes in.

Raphaël is a small JavaScript library that should simplify your work with vector graphics on the web.

There happens to be a nifty little PHP class for converting SVG files into a fully executable block of javascript utilizing RaphaëlJS called svgToRaphaelParser. This tool is a lifesaver and saves you a ridiculous amount of time copying and pasting path strings. After utilizing the class, it only takes a couple of quick modifications and you have yourself a fully functional canvas element displayed in your browser courtesy of RaphaëlJS code. You’re then free to alter the paths to your hearts content.


And that, folks, is how we mapped the United States and calculated the corresponding marker positions. Perhaps at a future date we’ll cover how we went about scaling and transposing the states of Alaska and Hawaii in Raphaël. Not only that, but how we re-mapped the marker points to those two states after they had been scaled and transposed.

Want to see a working demo? Hammer us with some feedback expressing your interest.


Contemplating new features for our devices and software..

“If I had asked my customers what they wanted, they would have said a faster horse.”Henry Ford

When buying something new, whether its something large like a laptop or HDTV or simply a software suite to manage our bills, what is one of the biggest factors we like to consider when researching the purchase? We like features. We want our new “thing” to slice, dice, and maybe even mow our lawn. With the proliferation of ways to research items online, we read reviews from consumers, online magazines, field “experts”, and even the marketing fluff from the product’s website.

In Feature Presentation, James Surowiecki talks about feature creep and how the inclusion of more and more unnecessary features costs the consumer money and time. He states:

“You might think, then, that companies could avoid feature creep by just paying attention to what customers really want. But that’s where the trouble begins, because although consumers find overloaded gadgets unmanageable, they also find them attractive. It turns out that when we look at a new product in a store we tend to think that the more features there are, the better. It’s only once we get the product home and try to use it that we realize the virtues of simplicity.

He also mentions a study where consumers were given the task to pick an item from a choice of three and then add up to 25 additional features. A large majority of them picked the one with the most features and then added an average of 20 additional custom features. When asked to use the device, however, they quickly became frustrated and switched to a simpler model.

This leaves companies with important decisions when it comes to designing a new product. Do they aim for simplicity and risk being seen as “cheap and underpowered”, or do they pile on as many features as possible and hope to at least make the product relatively usable. The problem revolved around the tested idea that people are poor at deciding what they will need for a future product. The product needs to have all the bells and whistles to entice buyers to choose the product, but must also be well designed to be highly usable. The iPhone is a popular product that has taken this approach.

In a recent blog, Photoshop Senior Product Manager John Nack spoke about this issue as it relates to Adobe when designing new versions of Photoshop. It came from an earlier post by Scott Kelby, president of the National Association for Photoshop Professionals where he proposed that Adobe have a way for users to submit official ideas for the next version of the software. He stated that Adobe would show everyone the top 10 ideas and that those would always make it into the next version. Nack responds by pointing out that if Adobe only focused on giving users what they want, they would never get what they don’t realize they want. So, although they want to give the users what they want now, they are also focusing as much time on giving us the next big thing so that they can stay ahead of the curve and continue to revolutionize their software.

Next time your looking at buying a new product, give a closer look to how you will actually use the product. Try to realize if your choosing one particular model because it has more features you will really use, or just plain has more features. Though, as studies have shown, we don’t really know what we’ll use and will generally choose poorly. So, maybe pick the opposite of what you’ve initially chosen, or just pick the baddest mofo on the shelf and enjoy wrangling it around while searching through a manual the size of an encyclopedia.

Page 8 of 8« First...45678