Great news!  3 Titanium templates are available on CodeCanyon right now.  The three templates available are:

• BizApp – A brochure style app with things like service  / product pages, coverflow portfolio, and more.
• Get It Done – A boilerplate GTD app
• Move Reviews – A great app for cutting your teeth on Titanium.

Titanium framework for chainable methods from Beauty in Design on Vimeo.

Here’s a brief overview of a framework I’m working on for Titanium. It’s a jQuery / Mootools-esque framework that allows you to chain the creation of UI elements together. Follow it or contribute on Github!

A mobile web app is not the same as a mobile native app

A lot of people think that Titanium and PhoneGap are in competition with Sencha Touch and jQuery Mobile. They aren’t the same thing. I’m sure I’m going to get some comments on this but think of a mobile web app as a website. Think of it as Basecamphq.com or Twitter.com. A mobile web app runs in your browser. Almost all of the app’s resources are remote, stored on some server somewhere. Sure there might be some local storage happening but at the end of the day it’s a website application.

A native app runs on your device. All of it’s resources are installed locally on your machine. A native app uses platform and language specific API’s native to that device. You can’t run NSString in a mobile web app. A native app has access to local resources while a mobile web app cannot.

“So what’s the difference between what’s out there?” Here’s the difference:

Sencha Touch and jQuery Mobile

These are mobile web frameworks. You can use these technologies to create web-based, mobile apps. They don’t have access to any native API’s. Both of these projects run in javascript. Both projects have totally separate ways of tackling similar problems but they are similar in that they are for the mobile web.

You can use Sencha Touch and jQuery Mobile inside both PhoneGap and Titanium. If you decide your html/js is cool as a native app too, you can use either PhoneGap or Titanium to wrap a browser around your app and put it in the app store or marketplace. This is where, I think, the confusion comes. Putting your Sencha Touch or jQuery Mobile apps in a native wrapper doesn’t make it a native app. It makes it appear as if it is a native app. You might get some extra functionality from PhoneGap or Titanium API’s, but it’s still not necessarily a ‘native’ app. It’s a web app running locally on the device. It’s a great way to use web technologies inside a native-like area.

PhoneGap and Titanium

PhoneGap and Titanium are not similar to Sencha Touch and jQuery Mobile. In fact, I would go as far and say that PhoneGap and Titanium aren’t all that similar. Both allow you to distribute native or native-like apps. Both don’t need to “build support” for Sencha Touch or jQuery Mobile. Why? Because the devices they support come with browsers. Remember, Sencha Touch and jQuery Mobile run in the browser. Since both PhoneGap and Titanium allow you to run things in a given device’s browser, they already have support for Sencha Touch and jQuery Mobile.

The biggest difference with PhoneGap and Titanium is what they offer. PhoneGap serves as a wrapper for the browser. It appears as if it’s a native app but it’s really an html/javascript app. Titanium can do the exact same thing via “webViews” but Titanium takes it a step further by offering a slew of native APIs for Cocoa Touch outside the browser. The two apps I have in the app store are 95% non-web based.

In Titanium you code in javascript, using Titanium’s unique API. The end result, at the app’s runtime, is native performance, native UI’s, etc. In simplest terms: You code in javascript and it ends up being Objective-C (in the case of iOS apps).

I’m still skeptical of the “end of native” chant going around. After building apps for the browser and for the device I think that there is a lot of room for both to still exist together. Understanding the differences of the technologies out there will help clear that up.

There. I said it. Now that I’ve got that out of the way here’s the obligatory paragraph of introduction:

The open source CMS world is booming. CMS communities empower millions of websites for small business owners, web designers, developers, marketing firms, IT departments, corporations, and governments. Everyday businesses use open source CMSs to do things that would not otherwise be possible for them. Everyday many web designers, developers, and marketing firms bill their clients for something they could not otherwise deliver without an open source CMS…at least at the budget it was delivered. Open source CMSs empower massive amounts of websites. To this point I say: AWESOME. However, with any type of empowerment yields issues that communities must navigate. This blog post will address one such issue: the service industry and how open source CMSs affect it.

An open source CMS usually represents a community. It empowers millions of people to run a website or blog. It cultivates worldwide business through service and training. It generates revenue from the oddest of sources. It has groupies. It’s featured in magazines. CTOs salvage their over-paid jobs with it. Techs get promoted for it. An open source CMS is many things but it is first and foremost a tool.

Yes, an open source CMS is a tool. It is no different than my neighbor’s tools he uses everyday to work with drywall. They perform a specific purpose. They complete a specific task. Maybe my neighbor goes to a conference that showcases the latest and greatest tools. He meets some peers, feels accepted, thinks his tool is cool, and is told “if you use this tool you’ll be rich”. “Yeah right”, you say?  In the end he still has to go home, plug-in that power tool, and put in a hard day’s work.  It doesn’t magically cut drywall for him.   It doesn’t mystically measure his corners. He has to use his brain, his common sense. He has to use his knowledge and experience while using his tool. He has to (ahem) work at it.

I’ll say it again: an open source CMS is a tool like my neighbor’s drywall tools. It doesn’t matter if you go to that super-narcissistic guy’s one-day conference and he tells you “Use WordPress and you’ll make millions like me”. It doesn’t matter if your friend built a website with “Joomla” and gets to sit at home the rest of his life. It’s not a passage to paradise. It doesn’t automagically make your business successful. It’s a tool.

My neighbor’s drywall tools don’t make his business successful. They help him do his job efficiently but they don’t give him business advice. His tools don’t even teach him how to do his business. Does his cutter teach him how to estimate? Does his saw help him assess the right solution for his client? Does his pencil make up for experience and understanding in a situation?  It reminds me of the movie “Bolt”.  Bolt asks the ambitious hamster, Rhino, if he thinks he can handle the rough road ahead.  Rhino replies, “I have a ball”.  As if that has anything to do with the rough journey ahead.  It’s the same with businesses.  ”It’s a lot of work, maintaining a blog,” says the web designer.  The business person replies, “Yes, but I have a CMS”.  Having a CMS doesn’t negate the work involved.

It’s no different for everyone out there using an open source CMS. If you don’t know what you’re doing you’re only going to go so far. If you build your candidate’s website in Drupal, because that’s what Obama did, that doesn’t mean your candidate is going to win his election (much to the chagrin of many). Like any other tool, it’s only as effective as the hard work, knowledge, experience, and understanding that’s behind it. And like any other tool, it can become dangerous to the person that doesn’t know how to use it (You should see me try to cut drywall. Be afraid).

A big problem with the open source CMS community is there are gobs of people that think they know what they’re doing. They think because they can install WordPress on to a site by clicking that cool “Fantastico” button they’re the Master of the Universe. Some think that because they know how to setup modules on a Joomla site they have an instant formula for success. And if they get to the end of their knowledge they decide to find someone smarter than them saying, “My ‘tool’ doesn’t do this. I’d be willing to pay $10 to include this in the tool.” Imagine their reaction when they’re told “Oh, that feature will cost $3,200 to implement.” It’s never a friendly response back. This is partly because they just don’t know what they don’t know and other times it’s because some would-be web designer never took the time to educate their client. Sometimes, when a person doesn’t understand their tool they leave nasty remarks on that tool’s forum. They say things like, “I can’t believe you idiots didn’t think of this! Why don’t you support my 20 other requests for this feature. You don’t care about your customers. You’re losing money!” (as if they paid for their tool in the first place).

I see the problem as two-fold: 1) Businesses need to be educated and informed by industry experts.  2) Faux-web designers and developers need to stop pretending to hold the keys to Trump-like success tactics.

#1 is common in any industry. People and businesses don’t have the time to keep up with the trends of every tool they’re using. They only know what they’re told or what they’ve learned from peers and vendors. If they’ve been told that an open source CMS is free – that usually means they think some dude in his basement released it and it’s crap. Nevertheless they decide to use it because their web designer (#2) taught them that it only costs $199 to implement and the tool itself will get them to the top of Google.

My solutions:
#1. Educate: It’s a travesty not to educate clients on the value of something like Joomla, Drupal, WordPress, etc. The millions of dollars of man hours that have gone in to something like these open source CMSs is amazing. Tell Andrew Eddie that Joomla was free to develop. Tell Dries Buytaert that Drupal is cheap because it’s free. Tell your clients it’s free and you’re educating them that it’s of little value. Why not start with teaching them that a global community that includes small business to large enterprises have invested their time and effort in to developing this amazing tool. Educate them that it’s been tried and true through many scenarios. Teach them that you’re not going anywhere because you’re invested in the project as well. Teach them the value of open source CMSs.

Please do not stop there! Teach them that their pep-rally of a business conference was a joke and “WordPress” and an email signup form do not bring about world peace (and pull in millions of dollars after you install it on a server). Teach them that it’s a tool and like any other tool in the world, you have to know how to use it. Teach them that there is work they have to put forth.

If you’re one of those business people out there where the above applies: Educate yourself on what open source CMSs really mean. Understand that there’s no such thing as an “easy” buck. You have to work at it. Attend a good conference that will teach you how to use the tool in context of your own business. Understand that if you’re going to build a house you have to consider the costs of everything. An AC unit doesn’t cost $10 and neither does that custom plugin you need for your site. Get some understanding and knowledge behind that zeal.

#2. Educate: “Wha…what? You just repeated yourself Rick”. Yes. I did. For all the would-be web designers out there: Your tool doesn’t make you any smarter. In fact it probably makes you dumber. Yes I’m serious. Your open source CMS tool probably has inhibited you from learning things you need to learn. Not a designer? Don’t want to learn HTML? “Oh I’ll just use that template”. What happens when the tool doesn’t do what you want? What happens when the client wants something that your template doesn’t offer? Do you blame it on your tool?  Do you cuss out your template provider?  Don’t take out your lack of knowledge on others.  It’s fine if you don’t know what to do. Everyone at every level of life has to deal with this. What you do at the cross road determines the type of web designer / developer you are. Are you going to learn or are you going to blame your tool? If you don’t have time to learn contract it out to someone who knows what they’re doing, just please, I’m begging you, don’t blame it on the people that know what they’re doing.

The obligatory paragraphs of conclusion:

The open source CMS world has diluted the service industry’s quality of work. It hasn’t done this directly or on purpose. It’s natural for such amazing things to empower good people, bad people, honest people, dishonest people, educated people and uneducated people. Making things more accessible will inevitably dilute the pool. Drupal web firms retain a high quality of work because it isn’t as accessible to a lower-functioning / educated firm. WordPress and Joomla spread the gamut between awesome work and the worst stuff on the web. For every quality firm like Komrade and Zuno in existence there are 1,000 faux-web design firms out there that steer their clients in the wrong direction.

The ironic thing? I don’t necessarily see this as a bad thing. I’m sick of these faux-firms polluting the web but it’s necessary. The crap work out there accentuates those who really know what they’re doing. It makes them more desirable. It also creates an opportunity for others, who don’t know what they’re doing, to learn and understand and get to the point where they do know what they’re doing. I’m glad those who know nothing about the web can enter the arena via an open source CMS. They have a chance to learn and help the industry through their knowledge.

If you’re one of those people: Keep learning. Don’t blame your open source CMS. Be humble. Learn the web technologies surrounding your tool. Don’t sacrifice business wisdom and savvy because you have a CMS.

If you’re an established web design firm: Help the communities out by educating your clients on the value of open source CMSs. Teach them that work isn’t cheap. Teach them to count the costs of their web site.

Talking with a few leads today got me thinking about maintaining a group of iPhone apps for several clients, specifically the design and layout.  Having to push out updates to the App Store just for a design change is so procedural.  Good news is there is a way around it!

Here’s some code to demonstrate the technique (note: the Ajax class used here is just a wrapper for Titanium’s XHR method.  It just makes it easier for me and the code a lot cleaner):

Remote JSON Source

Changing the search bar:

Easy right? You can even inject functions and call them from the app as well (Does this pose any security issues?):

Remote JSON Source

Source Code:

UPDATE: Since placing this post a few people have pointed out that the function in the JSON source above probably breaks Apple’s 2.8 guideline

Before continuing, let me qualify this blog post: It is not about nit-picky, un-educated statements like “WordPress is better for SEO” or “Your business will be more successful if you use Joomla”. I will not even go as far as to say which is more ‘user friendly’ as I feel it’s not a fair comparison. Instead, this blog post is a comparison through my personal experiences in finding the right solution for the job.

So there’s no mistake of my background: the large majority of solutions we provide customers revolve around Joomla. I’ve done Joomla! training since it was Mambo. If I sit down to write a custom framework, I think in the Joomla-esque MVC approach with all it’s factory methods, etc. I can create 10 Joomla templates faster than any one WordPress theme I’ve ever worked on. So as you, mister WordPress fanatic, start sharpening your pitch fork and prepare to cry “See! Bias Opinion! Let slip the dogs of war…” – Put down your weapon and hear me out for just a few minutes (remember, I have a battle axe). And you, Joomla ninja, stay your shuriken throwing stars from WordPress for just a minute…this is a blog built on WordPress after all.

MY JOURNEY

It all started earlier this year when we needed a multi-site solution for a SaaS platform we setup (Yes Mr. Samurai, SaaS means Software as a Service). By nature, we instantly started looking in to Joomla solutions and even what it would take to do it custom. We looked at JMS. It works, though a little confusing at times. It duplicates sites off of a mother-site (if you so choose), creating symbolic links back to the core files. It also modifies core files in order for it to work – bad, bad, bad. I did some testing and realized it would not fit within our requirements. There were too many things that could and did go wrong throughout the discovery phase.

Joomla Multi Site

JoomlaPlace has a sort-of-like-a-multi-site group of extensions. They work and from what I’ve seen, have some of the coolest ideas so far. But too many things could go wrong (like totally overwriting 100 customers’ content table by pushing the wrong button).

Then there’s Jentla. An awesome system which beats any open-source multi-site solution hands down…if you needed enterprise-level features that is. Jentla is perfect for big corps / enterprises, hospitals, etc. For what we needed it was too complicated, too expensive, and not enough control could be handed off to an individual site.

The Right One

After a month of the discovery phase, I did a quick install of WordPress MU to see what it was all about. I heard of MU in the past but never looked at it. It was amazing to me. Easily create and duplicate sites as fast as typing in the domain name and pressing SUBMIT. Jump to other sites all from within the admin area; site users can see all “Their sites” and do the same. Easily manage site updates since it’s all one code base. Push out a new plugin to all the sites with a touch of a button. Let certain users have access to specific themes…the list goes on. I literally slapped my forehead and said “You’ve got to be kidding me!”. I almost had tears in my eyes it was so beautiful, so flawless, and so effortless.

Tons of Awesome Stuff

I immediately dug deeper, seeing what’s possible, how it could scale, etc: Need database sharding? I mean like….4000 databases? Yeh they got that. Need to separate a site from the rest of the group because it just gets more traffic (VIP sites)? Yeh, they got that too. What if you need to run each site on remote databases? Uh huh, sure can. Want to run a social network on top of your multi-site instance? Yup, covered. What if we want to automatically create a site when a user signs up and then charge them for it too? And then, charge them for upgraded features? Yes we can!

There are some great CDN plugins too. When a user uploads an image, video, or file, it will automatically get placed in an Amazon s3 bucket (without them even knowing). Even as the user is going back to his media manager to place something in a page, it’s so transparent it looks like it’s just stuff on his site but it’s really on a CDN. You can even put your themes and plugins on the CDN if you want! Obviously this saves your server from a lot of headache.

Domain mapping is effortless. Upgrading the system is easy-peasy. Pushing out new plugins to your users is a matter of uploading the plugin and pushing “Network Activate” or if you want that cool “events” plugin to be available for just a handful of sites, you can do that too.

Is it apparent yet what we chose for the multi-site platform? There were a few caveats due to the NOOB factor. Migrating sites / databases to/from domains is more of a headache than an instance of Joomla. This is because of how WordPress stores the site configurations. In setting up an MU instance it’s important to know where it’s going to reside from here to eternity and fairly important that the instance is in a root directory. If you wanted to have fine-grain control to push out data to multiple sites WordPress MU isn’t for you. That’s more of an enterprise level feature. Jentla is more suitable for that. (BTW, I using the term MU even though it’s the older term. I know multi-site capability now comes with every version of WordPress and just has to be enabled; it’s easier to refer to the difference as MU though)

Now for the juicy stuff. I’m going to start with Joomla! first.

JOOMLA!

Joomla! is in need of something like WordPress Multi-Site. I’ve looked at the solutions out there and nothing comes close. Joomla, to me, has a lot more over WordPress but when it comes to managing multiple sites WordPress wins.

Speaking strictly from a single-site instance: The learning curve in a Joomla! implementation is a little more complex; that’s simply because Joomla is a more in-depth platform than WordPress. I venture to say you can do anything you want with both platforms (I’m allowed to venture, I have a battle axe). However it doesn’t mean you should. Using WordPress to create a site that has a document repository of 50,000 files, e-commerce and POS integration, and integration in to a CRM  would quickly become a ginormous monstrosity. Joomla does a good job at separating those features out and makes it much easier to manage as a developer; I don’t know why you would use WP over J! in that case.

Separation of Stuff from Stuff

Joomla’s strong point is in how it’s built. Separation of the template area from the actually functionality of the system is a much better idea than WordPress’s implementation. It still baffles me that you can build an entire application inside a WordPress theme – yes, a theme. This might be easier for the user in the on-set but it’s not a good long-term idea for any business. I equate WordPress’s idea of a theme like inline styles in HTML. Yes you can do it. Yes it might be easier if you’re in the HTML and you want to put some styling in there real quick but in the long run it’s a horrible idea. A theme/template is the design shell of the site. It should not include things like galleries, slideshows, contact forms, job boards, or the ability to create CCK-ish functionality. Those things should be completely separated from a theme/template (Yes that’s my opinion. Remember, I have a battle axe).

More Stuff Separation Please

Though Joomla’s separation is much better than WordPress I still think some more needs to be done. I lost a bid on a large job recently because you can’t put the core files somewhere other than the root of the site (like you can with Drupal, WordPress, or frameworks such as Kohana). Losing the bid was my fault for recommending a Joomla solution but that’s another topic. The fancy-pants J! devs will disagree and say “Yes you can do that if…”. Face it, Joomla is not built to do that. The CMS application needs to be separated more from the framework.

I would like to see Joomla! implement some things WordPress does. I really like how you activate / disable plugins (the equivalent to either Joomla components, modules, or plugins). We lock down a lot of our files in a Joomla instance so when we need to install a new group of extensions we have to do a few minor things in order for the install manager to work. What’s cool with how WordPress does it is you upload the plugins to the plugins directory and it shows in a list of available plugins in the admin. From there you choose whether to enable it and install the new database tables or not. Currently, you can do that with templates in Joomla! but I’m not aware of a way to do that with any other extensions. Am I wrong? You can upload a zip and enter the URL in to the install manager but that is not nearly as friendly as WP’s implementation.

WORDPRESS

WordPress is an interesting case. I love working with it. Building plugins are a piece of cake. Their api is easy to use. They have hooks for practically everything. I needed to write several plugins for the SaaS setup we did and it was easy, quick, and gobs of documentation were available if I ran in to a question.

Oddities

I did, however, feel dirty at times. No matter how hard I tried to separate things in classes or use an MVC-esque architecture I was always confronted with the fact that WordPress is not MVC-based. I’m sure WordPress fans will say it doesn’t need to be MVC. Whether that’s right or wrong more separation or flexibility would be nice.

Little things like the hooks/ actions drive me nuts. Consider the following:

add_action( 'admin_head', 'myFunction' );

The second argument is a call to a function. Did you notice it’s a string? Yeh. Me too. There’s no way of doing something like:

add_action( 'admin_head', $someObj->myFunction(someArg) );

This is really frustrating to me as there’s no way of programmatically creating these actions within something, like a class. It ends up leading to just a plain ole’ long list of functions. I don’t know a way around this currently. You have to pass a string in to that argument.

In Defense

I mentioned earlier that WordPress is not MVC-based and you can build practically a full application within a theme. In it’s defense it was built originally as a blogging platform. It grew to things like custom-post types and building full-scale applications. I’m sure if they had things to do over again they would’ve planned some things differently but as a platform grows in to new features it has to carry the existing code base with it. I really do like WordPress’s hook system and it’s API. It can be better but I do understand probably why things are the way they are.

Joomla could learn a few things from WordPress 3.0′s new custom post types. I know it’s a moot point whether Joomla! should have a CCK or custom fields built in but the way a WordPress dev can create custom post types is just totally cool. Picture something like the JHTML class but for adding new fields to the article manager.

THE DIFFERENCE

So what’s the difference between the two? The difference is the need.

We chose WordPress’s multi-site capabilities over Joomla’s superior architecture because it would save time, money, and we probably couldn’t have built a better implementation in to Joomla. WordPress’s multi-site platform is proven to scale too so to us it was a no-brainer.

Though I’m a Joomla guy this blog is built in WordPress. There are other Joomla-ers that do the same. I would never use WordPress as an E-Commerce platform or for an application where multi-tiered user level access is required.

Despite the great experience we’re having with WordPress right now we’ll continue to use Joomla! for the custom sites we build. If a client has a reason to manage multiple sites or if the client’s site is a few pages and a blog, we’d use WordPress. Why? Because I have a battle axe.

Unless you’ve been living under a rock you’d know that Wufoo put on a very cool competition last month.  The contestant entries were announced the past week and the winners were announced Tuesday…AND MY iPHONE APP WON!

My entry is Pico: An iPhone app that integrates with almost every API call Wufoo offers.  You can manage your forms, check and search entries, create entries, view your reports, and even check on your Wufoo users.  Read more about it or better yet go right to iTunes and buy it (Or else I’ll whip my new battle axe on you)!

Make sure you check out the 2nd and 3rd place prizes.  Very cool and useful stuff for Wufoodom.  Also, if you’re a Joomla user, I made a quick component that integrates with Wufoo’s API.  Get it here.

A big thanks goes out to those that made it possible:

• The folks at Wufoo for throwing such a cool competition and creating an amazing API and product.  There are other competitions going on right now but Wufoo’s was just cooler to get in on.
• Appcelerator for making Titanium, the platform I used for building the app
• My wife and kids, for letting me work on the app over the weekend.
• Marco, for the cool logo
• God, for always providing at the right time.

Remember, this is a J! 1.5 starting point for your template, just as Paul’s boilerplate is a starting point.  There’s no fancy template framework, grid system, or anything that isn’t present in Paul’s template.  It’s the same thing with some Joomla! goodness attached.

For those that are interested, someone is working on HTML5 overrides for Joomla templates.  I briefly looked at it but didn’t implement them here as I have some questions on the semantic implementation of the ‘header’ and ‘section’ use in the overrides.  The overrides use them for the different J! articles, blogs, etc.  Everything I’ve read indicates ‘header’ and ‘sections’ elements should be used differently but I’m not 100% convinced either…so I’m going to make that your decision to implement.  For more information on the ‘section’ element, read here, information on the ‘header’ element read here.

I took an hour and converted my old test template “Usability” using the boilerplate.  It was easy, quick, and works flawlessly in IE (though I haven’t tested in IE6 yet).  I didn’t take the time to strip out the old CSS overrides from the Blueprint framework but the boilerplates’ are still used.

Download the Joomla 1.5 optimized version of Paul Irish’s Boilerplate here

Download the HTML5 version of Usability here.

Thanks to:

• Paul Irish’s HTML5 Boilerplate (of course)
• Brian Teeman (The first time I heard of the setGenerator() method was from his blog)

Surprisingly, it took just a few minutes to port the Usability template, found on this site, over to 1.6.  The biggest caveats that I ran in to were the template params being renamed “fields” and “fieldset”s and the template overrides changing.  I didn’t dig in to the template overrides yet but a quick glance told me they are the biggest change.  Below is a video with my findings, enjoy! (don’t forget to turn on HD to watch it in it’s best quality!)

Click here to view the embedded video.

It is a social event

Ironically, the last FOWA conference I attended was about all aspects of social web apps however no social interaction went on!  After the main speakers gave their lectures everyone went to the four corners of the auditorium and digressed to the great social past-time of glaring at a computer screen.  There was very little human interaction or stimulation.  Contrast that with the CMS Expo, people interacted with each other all day long (and all night long too).  At one point, Kyle Ledbetter, from JoomlaPraise came over to a group of us and said “Alright guys let’s talk about something cool.  Forget this technical talk…we do that on Skype…”.

The point is, CMSX is not just a great place for a technical conference but a haven for all those that need assurance there is life outside of geekdom.

Actual business goes on

At previous conferences I’ve attended, very little business went on and if it did it was one-sided.  To be fair, it’s probably because most the attendees at other conferences were not business people.  I venture to say that the majority of the CMSX attendees are business owners or people with drive to start a business.  The multi-faceted purpose of the expo really lends itself to not just small breakout meetings regarding the latest technology or development standards but engaging debates and conversations on running a web business, or selling software, or how to scale your business (not just your server).  I learned just as much about business as I did anything technical.

The small sessions are the strong point

In other conferences I’ve attended, the main events were the large keynotes.  The CMSX had a handful of general talks, such as Dries Buytaert’s inspiring rally for the Open Source community.  However, the real gem of the expo is in it’s small sessions.  The sessions are not an after thought like many conferences but rather the focus.  It offered a wide range of sessions for it’s attendees.  For coders that need to sharpen their business wit, there was a business tract.  For those looking to broaden their services to another CMS, they had opportunity to get good training in CMSs such as Drupal, Joomla, Plone, and WordPress.   There were even some good overview sessions for lesser known CMSs such as EZPublish.

As someone who typically is skeptical at the value of conferences, I can highly recommend the CMS Expo to anyone.  Plan on attending next year!