Reflections on Marketing Class: Using Apple as a Case Study in Marketing Channels

Today in my marketing class at Melbourne Business School, we examined distribution channels vis-à-vis marketing. Not surprising, we examined the distribution of music, tracing it from a technological standpoint (vinyl to MP3) and its channels (independent shops to iTunes).

The lecturer's main point with regards to Apple's success was the control over the hardware, software, and content of their "ecosystem" which allows them to control the channels of music distribution. While I don't disagree with Apple's dominant position, I take issue with some of comments and perceptions with regard to Apple's technology approach that were made in passing.

Primarily, the point was made that Apple is successful because their system is "closed", as compared with Microsoft that must struggle to handle software from a multitude of vendors. In fact, the underlying assumption, it seems, was that you simply could not develop any custom software for a Mac. Of course, this is simply not true.

Let me briefly explore the development options for both systems.

Unlike Windows where developers need to spend hundreds of dollars on software development products like Visual Studio, all Macs come bundled with X-Code, their development environment for building Mac software. One could argue that this alone makes it easier for a developer to create software for a Mac compared to a Windows PC.

Of course, it doesn't stop there. There was many who would argue that the Mac development environment is superior to Windows in other respects. The Cocoa framework seems to be a very elegant paradigm for developing applications, and Mac applications can often be created without writing any code. This doesn't mean anyone can create software for a Mac, but it does mean that more software can be created faster with fewer defects. (As an aside, Automator for Mac does mean that some tasks can be automated by someone without any development knowledge, and there simply isn't anything like it on Windows).

Steve Jobs understood the benefits of having a superior development environment (as well as other marketing principles such as segmentation, targeting and positioning) as demonstrated on this now-famous video from when he was at Next:

This philosophy was brought to Apple when they purchased Next, and brought Jobs back into the fold. Mac OS X is based on Next technology.

In class, it was also mentioned that the iPhone is Apple's first device which supports third-party applications. This, too, is not true (although it is the first iPod which can supports third-party applications). The Newton supported application development,although I don't know if it was a good environment or not.

Finally, Apple has success not just on Macs, but also on PCs with their iTunes software, showing they can success even when they don't control the hardware. Microsoft, too, has had success on Macs. Internet Explorer was highly regarded, and Office for Mac is sometimes regarded as superior to its Windows counterpart.

In summary, I'm making the point that Apple computers and devices are not closed systems; they do support software development, and provide a robust environment at that. Steve Jobs not doubt continues to realize the contribution that software developers make to the value proposition of a computing platform.

Using Application.cfc as your application controller

A few months ago, I was experimenting with Model-Glue for an application. One thing that struck me as odd was that certain events which are normally handled by the Application.cfc (onRequestStart, onRequestEnd) were handled by Model-Glue controllers.

Rather than moving custom application event handling logic in a seperate controller, why not handle them with the Application.cfc? After all, the Application.cfc framework is a well-documented, frequently used ColdFusion features which already handles many application-level events.

To that end, I've written yet another ColdFusion MVC framework I call "Boca", which is Rails-esque insofar as mapping event names to controller methods (handlers) to view pages without configuration. But what makes Boca unique (and uniquely ColdFusion) is that Application.cfc serves as the controller for all application events. A sample Application.cfc would like this:


<cfcomponent displayname="My Great Application" extends="BaseApplicationController">


<cffunction name="onApplicationStart" ...

<cffunction name="onSessionStart" ...

<!--- Custom Event Handlers --->

<cffunction name="addToCart" access="public" returntype="void">

<cfargument name="productId" type="numeric" required="true">
<!--- Do application logic here --->

</cffunction>

<cffunction name="signIn" access="public" returntype="void">

<cfargument name="username" type="string" required="true">
<cfargument name="password" type="string" required="true">
<!--- Do application logic here --->

</cffunction>


</cfcomponent>

While I cannot make the source code public, I can offer insight on how to accomplish this in your application. The secret is using the onRequest function in Application.cfc to intercept calls, call the appropriate function within the Application.cfc, and include the corrent view page(s). This can all be done in less than 100 lines of code. To reuse this filter across Application.cfc files within your site, simply extend the base component which implements the onRequest method, and don't override that method.

If, like in other MVC frameworks, the event contains the union of FORM and URL scopes, I suggest invoking the event handlers using the event as the argument collection of the handler method like so:


<cfset event = StructNew() />
<cfset StructAppend(event, URL) />
<cfset StructAppend(event, FORM) />
<cfinvoke method="#action#" argumentcollection="#event#" />

You the get better event documentation by enumerating the arguments and types for your event handler (although this is optional, since ColdFusion supports dynamic arguments, and will also preserve the name-value pairs passed in). See the sample component above for an example.

A consequence of this approach is that variables set (and not var-scoped) within the event handlers are available in the view pages included within the onRequest method (this is a well-documented Application.cfc behaviour), saving Model-Glue like usage of event and view-state components across controllers and views.