[This post is long and meandering... apologies. But such is the state of my mind and reason for posting it. I'm trying to work out some alternative approaches with Rails, so these are not intended to be how-to examples... more background on our evolving process and links to the influences whence they come. All this related junk is spinning 'round in my head, and if I don't get it down in a readable and refutable format, I won't be accomplishing much in the sleep department for several days.]

The Code Smells

As we work on a few new Rails 3.1 projects, I keep rubbing up against things that just feel a tad… off to me. Some of them are things I’m just now realizing have made life less fun. Others have always bugged me, like messy, untestable business logic in the views (any conditionals, loop logic or awareness of model internals… form helpers, for instance).

In the second version of Capocus!, Norbert and I came up with a PagePiece concept where all that logic would take place in objects between the controller and view layer of Rails. It wasn’t very refined, and I don’t think we were even aware of Martin Fowler’s Model-View-Presenter pattern at the time (or at least I wasn’t). But PagePiece was roughly a Presenter concept except it wasn’t bound to a domain model. Basically, our idea was just smart helper objects that delivered partial views based on logic internal to the inheriting PagePiece class.

module PagePiece
  def self.included(base)
    base.delegate :current_user, :logged_in?, :has_permission?, :to=>;'(controller or nil)'
    base.send :include, InstanceMethods
  end

  module InstanceMethods
    def initialize(details={})
    @page = details[:page]
    @controller = details[:controller]
  end

  def page
    @page
  end

  def controller
    @controller
  end

  # then some methods which checked authorization privileges
  end
end

# app/pieces/admin_menu_bar.rb
class AdminMenuBar
include PagePiece
  def render_options
    can_edit? ? {:partial =>; 'layouts/admin'} : {:nothing =>; true}
  end
end

That’s a really simple example, but of course the logic could get as rich as you like… switching to different partials for different user roles, perhaps. Whatever you like. What was cool about it was you could do this in the view:

# some haml template

= display AdminMenuBar

So, our application template would look something like this:

# app/layouts/application.html.haml
!!! 5
%html
  %head
    %title = display Title
    = stylesheet_link_tag "application"
    = javascript_include_tag "application"
  %body
    = display AdminMenuBar
    = display Messages
    = yield
    = display Footer

Which was nice. No logic. Brevity. Clarity. But we still had some logic residing in the partials called by PagePiece objects for things like loops and form helpers. So that was a bit irksome. And things could get messy in that app/pieces directory if you weren’t careful, since the objects didn’t track cleanly to the MVC dealio… sorta like the JavaScript directory before Assets Pipeline came along.

So, now we have Mustache, which I’ve yet to implement, but I really really like. It solves the remaining logic concerns for us (with a little additional help regarding forms with some approach like this, or better yet, this). So that takes care of the logic in view templates, at least. And we get some nice, reusable templates for JavaScript actions to boot. Plus, I still get to use my beloved HAML. I hate writing HTML… so, sue me.

Your Dill, Vinegar and Cucumber In My Pickle

But there are still a couple of irksome things. It’s an old argument, but Rails MVC works great… until it doesn’t. Development is fast… until it isn’t. Once you have a complicated domain entity that doesn’t track cleanly to the ORM approach of ActiveRecord, things get a bit cloudy in your “model”. And in this house, we’re mostly using NoSQL these days anyway (Mongoid currently) so ActiveRecord isn’t something we have to deal with or care about (for better or worse). And that has brought out the code smells for me. What I’m realizing is I need clarification of duty wrappers.

There seems to be a lot of benefits to wrapping. Corey Haines did a wonderful talk on speeding up Rspec unit tests by simply staying in Ruby and ignoring Rails… as mother nature intended. So, he’s basically creating delegate classes, a concept I recently started wrapping my head around as I learn Objective-C for our iOS app development. Nicholas Henry is blogging pretty extensively about very similar wrappers for domain logic and has put a lot of good thought into it in my opinion (more on that in a bit). Details aside, he seems to be heading toward creating services, which is something Pat Maddox gets into in his talk on constraint-driven changes to Rails development approach. And Attila Domoko is kind enough to provide his wrapper approach.

Then there is the whole conversation going on now about framework decoupled (if not agnostic) development spurred by Uncle Bob Martin’s short video on framework prudence. The argument against that idea, expressed by a commenter, being you should either trust your framework or build your own. I don’t buy it. I love Ruby and Rails. But, I have some seriously coupled Rails 1.2.3 apps still running that I’d love to get into Rails 3 (SAME FRAMEWORK, RIGHT??!) and can’t upgrade without considerable redesign (starting over would be faster!). That’s my fault. I didn’t insulate my app from the framework. It has nothing to do with trust. Things change. We find better ways of working. So, I’d rather make my life easier in the long run… even if that means a few extra steps and potential “over-engineering” for me now (I’m good at over-engineering… or bad about it. Not a poster-child for pragmatism in that department. But I am getting counseling and we’re hoping for the best). And anyway, the extra steps to insulate my app will quickly add up to a cost of null (if not turn into a big asset) once I have faster running test and a more agile codebase. Especially once the process is down, I’ve meta-programed away duplication and built whatever generators I need. See, I’m doing a damn good job of selling this to myself.

So, let me define what I want…

I Wanna Be Free

From a broad perspective, these are the goals:

• Insulation – Separation of Concerns which are agnostic of the framework and data structure
• Domain Clarity – A clear, view-layer-agnostic API for the domain with no required knowledge of internals.
• Reasonable Test Coverage – Full stack Cucumber acceptance test of the domain, but fast, pure Ruby Rspecs to drive development.

The Stepping Stones

So, here’s the development cycle I’m moving toward (based largely off pains discovered by NOT doing it this way)

1. Start with declarative Cucumber scenarios to help discover the domain (focusing on API concerns, not view or business logic!)
2. Quickly jump into Rspec to test-drive behavior behind the API, handle failures and deal with edge cases
3. Once the API is stable, refine the view templates (if you need http) and format JSON, XML, RSS, PDF, etc. output as needed.
4. Extract all framework or database specific code into isolation wrappers, point the tests at them, get the tests fast (no Rails)
5. Repeat for all domain concerns

Peeling The Onion

Cool. Process is down. Now what am I dealing with? I have a gut feeling for how my concerns are separated to achieve both the goals and process I desire, but I can’t be sure until it’s put into practice. I reserve the right to change my mind (and you are welcome to set me straight if I’m talking crazy here), but it falls something like this:

The Data Model

So, the Rails Model? Not really a model, is it? I mean, it can be… if you want to be bound to both the framework (or its current version) and the database you chose at the project start. I have a feeling Rails will change, and I’m almost certain that I’m uncertain MongoDB will be my preference for this or every other app down the road (and hell, I may well want to use multiple databases for different purposes).

So, I’ll instead call this layer the data model. That means, only framework and database specific things go in here. It should not contain any model behavior which isn’t for some reason necessary for the framework or database. So, probably to be kept rather lean. After all, it’s the part I’m going to have to change down the road if I migrate frameworks, databases or even the mapper. I want the least work there possible. Some will be unavoidable as different databases use different find and relational strategies (those nasty custom SQL queries, yep… they go here), but the goal is to extract any of that beyond model specific scopes to a mixin… most mappers cover this pretty well as is.

The Domain Model

This is the juicy bit. Fat model, sure… but only for the stuff it needs to know about. NO VIEW RELATED LOGIC. The view has nothing to do with the domain entity. NO KNOWLEDGE OF OTHER ENTITIES. Person does not need to have inherent knowledge of AccountBalance. And there shouldn’t have to be a direct correlation between the domain model and a single data model.

For example, we’ve learned over the years that Users and People are very different things. The User model is about access (authentication and authorization) and that’s it. A Person is just that… it describes what a person is within that domain. You may have people in the domain who have no access to the domain (buyer contacts, perhaps). So, it’s silly to deal with access conditions when you don’t need them and it’s equally silly to treat users as some different kind of person. So, we delegate or use whatever method we desire in our data models to unify User and Person when we need both. But Rails’ MVC makes this sorta cloudy from a domain perspective. The domain model should only care about me (THE User) and people (all other people I am not). So, My domain model’s API should structure things likewise. And that will include a bunch of different Value Objects (as Iain Hecker described a year or so back in his article on Domain Driven Building Blocks), which are things like Address, PhoneNumber and of course AntidisestablishmentarianismStance. I suppose User is actually a Value Object of Person which deals with access… but I digress. Again.

Point is, how I organize data behind the scenes has zero value for the domain. It wants what it wants… it’s like the heart that way. *swoon*

Services

There’s been lots of talk in the last year or so about the concept of services. Their purpose, to my mind, is to deal with any task that is beyond the scope of a single domain model or involves procedures the domain model shouldn’t care about. Some examples might be RegistrationMailService, PayrollService, MessageNotificationService, etc. where the service may be interacting with a single domain model, several domain models or none. They are really models on the same level as an entity — at least, looking outside-in they should be — with their own API that can be called by a controller. Making these type of procedures stand-alone makes a lot of sense. It simplifies my domain models, it decouples domain models which otherwise might have had to interact within the “fat” model and it makes isolated testing of the service easy.

As I mentioned above, Nicholas Henry has talked of his approach to domain modeling which he splits into Facade and Use Case, which I rather like. Facade would be what I’m calling “Domain Model” and Use Case what I call “Service”… I like my terminology better. Seems more explicit and easier to follow… but a horse is a horse, of course.

Note: Likewise, some have used the “Presenter” term in this realm too… which is equally confusing to me as the name implies — though does not mean — a view context the domain/service layer should not have. More on that below.

The Controller

So this is the Sergeant Schultz of our onion… “I hear nothing, I see nothing, I know nothing!”. Okay, it knows how to route and what domain model method to call. Maybe that was a bad analogy. Regardless, It’s just a dumb traffic cop (no offense to smart traffic cops). This has become the Rails Way™ more or less, and Corey Haines has talked on numerous occasions about his rule that controllers cannot interact with ActiveRecord. Totally agree. So, somewhat conveniently, we can just call to our new domain model layer.

The View Template

I’m going to skip over a layer and jump to the end for a second: The View Template. As I discussed waaaaaay up at the top of this opus of mind-spew, view templates should be dumb dumb dumb. No logic. It spits out either formatted json or html (or rss, xml, etc.). And preferably with the same template for all (which, again, I hope to find Mustache an aid in this effort). What’s important is that, just as I want the domain model framework and database agnostic, I want the view UI agnostic. iOS, Android or other mobile device app hitting an API? Web browser hitting http? ExtJS, jQuery or whatever other layer you want to build a http web/mobile GUI with? A reader client pulling an RSS feed? Great. All the same to me. Heck, Gem up several UI approaches and give developers options.

Note, above I said view templates should be dumb. I’m not saying the view object should be dumb. While I know Rails technically has a view object, its kind of a view object by convention. We have little control over it and end up mixing logic in the view templates in favor of a little convenience. And that’s fine… until it’s not. I want to be able to quickly unit test view logic and make sweeping UI changes without having to worry about the logic therein AND without needing to know anything about the application internals. So… not having a view controller of that nature, I suppose we need one.

The View Object(s)

As I alluded at the onset with our old PagePiece thingy, there needs to be something that deals with view logic that is itself a testable object. People are using Decorators and View Presenters for this purpose. There seems to be a real lack of agreement on what one or the other is. But here is how I’m currently thinking of them (you may disagree):

1. Decorators remove view formatting from the domain model or service
2. View Presenters control the presentation of elements on your page for any given context

They are very different things. And then we may even have a third category of view object: View Resources. I know… freakin’ onions and their layers! I’ll explain…

Decorator Usage

As I understand the decorator concept, the idea is to take any view related methods out of the model… like time formatting, “fullname” methods which combine several fields, etc. Excellent… that stuff always bugged me sitting in the model. Draper is a pretty cool looking gem which uses the decorator approach. I’m not sure it will work with my abstracted domain models, but I’m going to give it a shot.

View Presenter Usage

The view presenters, how define them, are very much like our old PagePiece concept above. Given a context (my role, the current url’s section or subsection, my preference settings, etc.) should I show this bit, that bit, or no bit?

View Resource Usage

I don’t like Rails helper methods. I rarely use them… and feel dirty when I do. Just seems like — Ruby being an object oriented language — we should be working with smarty-pants objects. So View Resources are the smarty-pants alternative to Helpers. Really, you could consider Decorators and Presenters as I define them as View Resources as well, but I separate them into their own categories due to their specific behaviors. View Resources is essentially a catch-all.

This is where things like Form Backing Objects fit to me (see Jeff Dean’s article on form backers). Jeff suggests these fit in the other (non view) Presenter. Which, may make sense in their apps, but for me that would mean it is a service, which it clearly is not. Services are revealed through the domain. The user is blissfully unaware of any behind-the-scenes nonsense that makes a form work, as they should be.

It’s possible that View Resources could be mixins for Decorators or Presenters. I’m not sure how I’ll approach that yet. But in the Form Backing Object instance, it makes sense that the basic behavior could be extracted to a mixin and then the specifics of the form supplied by the domain model’s decorator, since that is a view relationship directly tied to the domain model.

Structure

Nobody likes a bunch of junk randomly stuck in lib/ worse than I. So we need to pull this all into conventional app sub-directories. We’ll leave the rails default be, of course. No need to reinvent the wagon wheel:

app/assets
app/controllers
app/helpers #bleh
app/models #remember, these are my framework specific data models
app/views #should be templates, but whatevs

and now my additions:

app/domains
app/services
app/decorators # likely mapping conventionally to domain models and services
app/presenters # mapping conventions the same as controller-to-view
app/resources #our various view object mixins and whatnot

Excellent. I think that will work.

Conclusion

You made it this far. Dang. Thanks for indulging me. I’m certainly interested in any feedback you may have (aghast, snickering or otherwise). This is a work in progress (alpha thoughts, you might say), and I’m sure I’ll look back in a few months and groan at the moronicality. But I’ll certainly try to share my experience putting this all together and my thoughts overall as they shift.

When Norbert and I started Websuasion in 2007, we already had in mind several core principles which we agreed would be the foundation of our company. In fact, we spent months throughout 2006 (hours per day) loosely defining, debating and working over what would ultimately become our ethos. It was to be a constant reference point of guidance; a rallying cry; a belief system. But we also understood this ethos needed to be abstract enough to be flexible. Things change — as I’ve learned, often drastically and without warning — and if your system breaks in the process, it’s of little value to you.

Norbert came from the very earliest days of Mindspring, and like many people who experienced that work environment, he was profoundly influenced by the company’s “Core Values and Beliefs”. He and I were also both from the post-punk underground cultural movement from which sprung the DIY (Do It Yourself) movement in music, art and technology. This mindset — that with enough information, dedication, practice and patience you could accomplish anything — is largely what attracted us to the internet in the earliest days of the web. Then, as we delved into the Ruby programming community, the concepts of Agile development made as much of an impact on our business process as it did on our programming.

This trinity of influence was the basis for the Websuasion Ethos. Our beliefs would guide our interactions with one another, with colleagues, with employees, with clients and with our day to day work. Early in 2007, we tried to boil our concepts down to a neat and concise list — similar to the “Core Values and Beliefs” — and found it far too unwieldy. We then developed it into a short book, but found we were constantly editing, rewriting and fiddling with an ever-expanding conceptual beast. So, a blog seemed the perfect place to define and expand upon our ideas over time.

Why should you care?

The Websuasion Ethos was never intended to be specific only to our organization. We wanted our company to serve as its example, but more importantly, we wanted to share our ideas openly with the larger business community. We wanted to use our beliefs as a measuring stick to gauge the work we did for our clientele. But, we also intended — somewhat audaciously — to expect our clients to make the effort to understand and operate in the spirit of these concepts. We simply felt that our core beliefs would translate to better business and greater success for all who took the time to contemplate their purpose.

I am now charged with bringing our ethos to light as best I can. These concepts have grown in my mind to be more important than ourselves… more important than our company. I realize now that the ideological seeds Norbert and I planted together in 2006 have helped me to weather tough times and provided me clearer vision for the future of this company. I’ve seen clients (often initially skeptical) find their own success though many of these principles. Going forward with this blog, I hope you find value in these concepts. As we wade though together topic by topic, I welcome your comments, debate, suggestions, etc.

Slowly, over the last few weeks, I’ve been cleaning out my Twitter “Followers”. Yes, followers… by simply blocking them. I’m not doing this lightly. I realize that on the surface, this flies in the face of the open, embracing love-in that social media is purported by so many to be. And it also dramatically drives down that superficial impression that I’m a highly respected professional in my field who has six digits of data points hanging on my every word. I mean, anyone with thousands of followers must have incredible “thought leader” foo, right?

I manage several personal Twitter accounts. Some are very active, other infrequently tended (like @websuasion_ryan of late) and still others laying in wait for back-burnered project momentum to kick back in as time allows. When looking at my most active profiles, one thing is incredibly clear: those accounts are managed with unwavering scrutiny. I’m only following people who I actually know, who I respect, who inform my decisions, who are emotionally or intellectually like-minded and who challenge me to think. In short, I follow real people who add value to my day. And likewise, now I intend to manage my followers with the same scrutiny. You need to be following for legitimate reasons.

Discerning valid followers means actually reviewing the profile, posts and links of every single twitter account that follows me. It’s tedious work. It’s draining. It has occasionally made me incredibly sad. Incredibly frustrated. It has occasionally raised questions regarding the true nature and value of social networking. I’ve wondered if all Twits are just that… self-serving, robotic, press-release-link spewing cogs foolishly chasing the veneer of relevance and wasting everyone’s time in the process. What do you get when 100,000 deaf marketing gurus, life-coaches, automated bloggers and countless other self-proclaimed niche experts all follow one another? Noise. You get mind-numbing noise… consisting mostly of Mashable retweets.

Thankfully, that’s just the chaff. And there’s a lot of chaff. A painful lot. But once the noisemakers are blocked into submission, I’m finding that I have a very clean and amazing resource of my own design. A resource that I actually enjoy logging into.

Maybe you are wondering “Why bother blocking your followers, though. They don’t show up in your feed unless you follow back. Can’t you just ignore who you want to ignore?” True. And like many others, I’ve done that for a long time. Now, I’ve decided that’s a half-assed approach. Here’s why:

I doubt your commitment to Sparkle Motion: I want to know how many relevant followers I have. If I’m building a community, I need to be able to gauge my performance with that community. Are my thoughts, opinions, articles, retweets, replies, jokes or personal anecdotes adding value to their day? It’s a tricky thing to measure even with the cleanest of follower lists, but it’s absolutely impossible to measure when you can’t trust the numbers. If 80% of my followers obviously are not listening or interacting, then how do I get at the legitimate measure? This alone has me convinced that the social marketing metrics used by most companies are useless.

The forest of junk timber is obscuring my precious hardwoods: Glance over a few thousand followers. Go ahead, I’ll wait. *makes a sandwich* *builds a home addition* Okay, you back? I’m guessing you found some followers are easy to eliminate… obvious spammers, dead accounts, misguided corporate branding efforts, etc. But some are really tough decisions. Some people are really bad about providing a clear bio. But once you dig in a bit, they share some really interesting perspectives. I missed some really great people over the last couple of years because their needle of a profile didn’t pop out of the haystack. Having a smaller base makes it easier to find the gems.

Approachability and celebrity are mutually exclusive: Who am I going to do business with: a socialite who seems to be a the toast of the internet and dispenses how-to generalities; or an accessible everyman who displays expertise in their field and can make the things I need happen? Maybe corporations focus the internet-famous. Most small businesses want the job done well, on time and on budget. They don’t care how many Tweetups someone is speaking at. Chasing the numbers is just bad business for most working professionals. Building a tight core of strong relationships is what’s important. Our relationship to colleagues, peers and clients is everything. And in my experience, accessibility is the first step to building those relationships.

The downside of all of this is potentially limiting that accessibility inadvertently to someone who does care and is relevant. Unfortunately, blocking is the only real option Twitter provides to manage followers. So, if you’ve found yourself wrongly blocked by me, I apologize. Please feel free to reply to me. I’ll pick it up in my Tweetdeck search, remove the block and consider following back.

I’ve been away from blogging, social media and the like with respect to Websuasion for a while now. I feel a bit awkward coming back to it without explaining what caused the hiatus, what we’ve been doing since and where things are heading now.

On Memorial Day of 2009, my long-time friend and business partner, Norbert Taylor, passed away. I won’t go into detail, but it was a terrible shock to his family, friends and colleagues. For me personally, it was devastating. Though we were separated by the over 700 miles between Atlanta and Chicago, we spent large portions of every day working together on our business. It was the most perfect intellectual working relationship I’ve ever experienced — a true partnership. We were so much alike, we could finish one another’s sentences. And yet, our strengths stood in sharp, complementary contrast. We shared a clear vision of what we wanted to accomplish, and I was honored to work with him. Most importantly, he was my closest friend.

We started Websuasion, in part, because of our mutual love (as both web developers and users) for the internet. We were mesmerized by the opportunities web technology can offer when done well. But, we were often frustrated by the vast chasms separating technical expertise, effective marketing and successful business models. The best practitioners of each seemed to be unaware of one another or unable to communicate their knowledge and experience outside their own community.

We noticed that great business models were often hampered by poor choice of technology. We saw exciting technical innovation failing to communicate their opportunities to businesses and going unrecognized. And, we saw an ocean of old-guard marketers assuming the traditional approaches would work in the internet medium while failing to understand how technology could be used to more appropriately and efficiently connect with users. In short, we felt there wasn’t anyone out there translating between these factions, and… well, teaching.

So, Websuasion grew into two areas of focus. Internally, we would develop our own web application platform on which we could build quality sites and web services for our clients quickly and cost-effectively. Externally, we would do our best to impart why businesses should care about good web development practices; teach web marketing and PR departments how to better utilize the tools available to engage their customers; help commercial, nonprofit and government organizations to understand what constitutes a strong technical and customer strategy; explain the necessary roles and appropriate expectations business should have when hiring a web team; demonstrate how best to ensure their technical plan falls into place on time and on budget; and finally, stress the importance of continuously measuring their success.

Capocus

We’ve spent several years developing our own web application platform, called Capocus. We’ve launched several large-scale websites with it and learned a lot about flexible application design, usability and the basic functionality needed for most successful web implementations. Our previous versions have been proprietary releases, but it was always our intention to release Capocus as open source software. Before his death, Norbert spent the last several months completely re-designing our software armed with all that we’d learned. Since his death, I’ve picked up and moved that work forward with the help of our friends and fellow IBG cooperative members at Twelve Foot Guru. There is still a lot to be done, but we hope to unveil a beta release of Capocus 3.0 by summer.

Podcast

Just before Norbert’s death, he and I recorded several episodes of a podcast aimed at doing some of the teaching work we felt was needed. They were never released for obvious reasons. But now, I want to rectify that. I’ll be posting up the first couple of episodes next week. They are a bit dated, but the information is still relevant. And I just really think they should see the light of day.

Moving Forward

Moving Websuasion forward over the last few months has been daunting. As I told a friend recently, “It’s much more difficult to rebuild a company than it is to build one.” Our development and client work has continued, but I needed time to rediscover the heart of Websuasion’s message. That’s becoming clearer each day, and I hope that I can use this spot on the web to provide a narrative of experiences and ideas which you might find helpful. You can aid me in that goal by offering topic suggestions (click the tab to the left) and sharing your comments on Twitter, Facebook, LinkedIn and below. I look forward to the ongoing conversation, and thank you for reading!

Is the iPad worth all the fuss? I think probably it is. It won’t be perfect out of the gate, but from my perspective, there is a need for a such a device… something to stand between SmartPhone and Power Computing. Especially if it can simultaneously provide two things particularly well with which those other two computing categories have difficulty: immersive experience and tactile usability.

And, of course, Apple has done it twice before.

The iPod

Granted, the iPod did not change my life. It did, however, put a large swath of my beloved music collection on my hip. That, in turn, frequently brightened my day, my car ride, my yardwork, etc. It can be argued that any mp3 player would have done the same. But, being a Mac user, the choice was mainly convenience and brand trust. And as I became a fan of podcasts, the iTunes store subscriptions became a further convenience. iPod designs have come a long way in a short time, and Apple has quickly learned from their mistakes. And all that led to a real revolution.

The iPhone

I resisted the iPhone until the 3G model appeared. Before that, I had a Blackberry, which I was loathed to use. I checked email only when stuck without a better option. The usability was horrendous. The support (particularly on Mac) was even worse. I finally relented — paying both the high iPhone price tag and the significant monthly plan upgrade. And, to my surprise, it actually did change the way I work and live. Significantly.

Now, so much of my life is tied to the iPhone. It’s my alarm clock throughout the day. It’s replaced my iPod as default mobile music player except on the longest of trips. I capture song ideas, ramble voice memos to myself or record on-the-spot audio for use in podcasts… all with 4Tracks Lite. I plan my tasks with Things; track my mileage with MileBug Lite; and I even spec website implementations and software development with MobiTracker as ideas strike me on the go.  And of course, I can check my email, Twitter, LinkedIn, Facebook and all that other social and networking stuff. The iPhone is even a decent stand-in for an eBook and PDF reader with the Stanza and Kindle apps.

The iPhone can pull a surprising amount of weight. But there are times when it begins to push its limits. I currently much prefer to deal with social networking and email correspondence on the laptop/desktop. The keyboard and screen real estate is just so much more efficient and practical. And while I hate (and I mean hate) reading eBooks on the laptop, the iPhone’s screen real estate is somewhat limiting here as well — as is its battery life.

The obvious limitations of the iPhone, because of its size, has lead Apple to the next stage.

The iPad

There is a ceiling of usability that the iPhone hits. And that’s where I see the iPad making a big difference in my life. Not just for reading electronic publications, but for reading blogs, interacting with communities and simply enjoying the web and multimedia. As a web developer, internet activity can be a big distraction to productivity. So I’d love nothing more than for my laptop/desktop time to be productive work time; my iPad time to be networking, social and leisure time; and my iPhone to fill in the gaps with the utilitarian, on-the-go applications it preforms so well. For me, I think it may be a contextual trifecta of computing… the best tool for each job.

I originally underestimated the power of the iPhone because I didn’t immediately recognize the power of the Apple App Store and 3rd party development. The variety and prevalence of the App Store is what ultimately sets that device apart from all other SmartPhones (time will tell if Android can do something similar). But, iPad detractors should be careful not to miss this point: allowing immediate access for the iPad to most of the iPhone applications — and then making the SDK easily modifiable for developers to take full advantage of the iPad interface with their existing apps — is, frankly, a masterstroke by Apple. And by doing so, they bolster not only iPad adoption, but continued development for the iPhone as well. Complain all you want about the iPad’s lack of e-ink technology… few will care. Apple aren’t trying to simply be a Kindle/Sony/B&N eReader competitor. They are trying to introduce an evolution in interface. While I don’t think it will change everything, I think time will show that there is a place for such a tablet.

There is a point between serious power-computing needs (programming, audio and video production, graphic processing, word processing, configurability, serious gaming, etc.) and the swiss army knife of simple mobile device applications. There are untapped benefits provided by a large, intimate, tactile application interface. Demos like the iWork preview for iPad gave us an indication of where this might go, but it’s only the tip of the iceberg. Imagine being able to comfortably sit anywhere and manage any number of interface-intensive applications by simply running multiple fingers across a touch screen. A good half of the applications I currently use on the iPhone and laptop will, I imagine, be far more convenient and usable on the iPad equivalents — especially when developers begin designing those applications specifically for the interface. Things, iCal, MobiTracker, etc. all can be made far more productive; movies, TV shows and screencasts can be much more intimate; social conversation can be much more engaging and fluid; interaction with music, photographs and art can be more immersive.

I’m excited to see what happens. And if I find the time, I may try my hand at an app or two myself.

(lame song reference attempt… sure)

My involvement with “social media” really started in 1992. At that time, the internet was really all about the usenet and community email lists. They were incredibly noisy, geeky and (at times) downright confrontational. But boy were they engaging! You were thrown directly in the pit with all the lions. If you held your own and gained their respect, you really got to learn a lot about each individual. Friendships and (yes) business relationships I made back in those days still persist to this day. And that longevity is something I directly attribute to the in-depth debates, conversations and running jokes we all shared.

Then came the great blog migration.

My exodus from the usenet/email communities to blogging happened in 2001. I went willingly… looking for a way to reduce the signal to noise ratio in my life. Blogging allowed me to spout off whatever was on my mind in detail without (too much) concern over impacting the bandwidth, topic restrictions or guidelines of any particular community. RSS feeds and community filters allowed me to control what I read. It was great. I had so much more free time to, you know, work.

But looking back, I now realize that I lost the depth of individual engagement I had previously. Sure, friends and colleagues would comment. And I would read their posts and comment. That’s all great, but that method of communication is rather truncated and static. It’s primarily one way. It’s yelling into a crowd and hearing a few shouts back.

Blogs are not engaging. I don’t care who tells you otherwise. They can be compelling, moving, informative… all good and important stuff. They tell your story and share your mindset in detail, which is fantastic. But they are not, on their own, going to help you build relationships with individuals. Best you can hope for is some useful feedback and some trackbacks from other bloggers. Most of the time, a post’s author only has an exchange with the first few people who bother to comment (if at all).

From the perspective of building relationships, blogging was 3 steps back.

Micro-blogging is potentially 2 steps forward and 1 step back.

The 2 forward: We now have this wonderful real-time, worldwide conversation stream. We have the ability to connect with people and entities who would never have dabbled in the older discussion formats. We can seek them out. Easily. We have every opportunity to engage.

The 1 back: Now we are down to 140 characters of space for building relationships. That’s a real challenge. It can be done over time though. I’m not faulting the networks, and there are certainly people out there who get it. In combination with blogging, micro-blogging can go a long way to filling that relationship-building void.

The issue is that business is new and pretty baffled by this engagement concept. They, by and large, were not involved in the old usenet days and don’t realize how that level of interaction could be relevant to what they are trying to achieve. They’ve only just started wrapping their heads around blogs… under the assumption they are press release repositories. So, it’s no wonder that most twitter and facebook page feeds by business are a constant refrain of “here’s our link… hey, here’s our link… oh yeah, you seen our link?”.

The challenge is to ensure you aren’t taking that backwards step. Simply, that means you need to talk with the community you build. Not at. Get to know them. Let them get to know you. You may be surprised just how many opportunities arise due to your participation. It takes a greater effort, interesting ideas and (*gasp*) personality. But using the traditional mass-marketing models on-line is a mistake. Garbage in. Garbage out. Or, to quote McCartney: “and in the end, the love you take is equal to the love you make”.

Image: Simon Howden / FreeDigitalPhotos.net

For a long time I’ve concluded that you should never schedule actions more than a day or two ahead of time. A few days at the most. There are exceptions to this of course… meetings, vacations, hard deadlines, etc. But still, those things are rarely specific enough to be actions in of themselves. Typically they are larger projects, sub-projects or events. I’ll even go so far as saying that an action should never even grace your calendar. There’s nothing more annoying to me than a long to-do list cluttering up a perfectly good calendar.

When you plan with too much detail, you are constantly having to rearrange your schedule. Something unanticipated always materializes requiring your immediate attention, and it can turn your week into an ongoing process of rescheduling. So, until recently, I hardly ever used calendar software like iCal. I’d toss meetings and deadlines on it. I’d reference it every few days to roughly scope out my week, but that’s it.

Like many self-employed folks, I have a very wide range of activities that I do. And working from home over the years, my days have tended to be rather unstructured with regard to what I do when. I’ve worked loosely by priority, which has worked out okay of course… my responsibilities get completed more or less on time. But I’ve noticed that such lack of structure can make me feel like my head is spinning by mid-day. What’s next? It’s all so freeform… I never really know. Just grab the next action and run. That lack of structure tends to zap my energy a bit sometimes, causing me to have to regroup for a while before switching gears and deciding what my next task should be.

My business partner and I often chat about approaches to productivity, because we both actually enjoy that kind of stuff. We’re weird. A few weeks back, we were discussing the use of context in our organizational systems, and he pointed me to a 43Folders post that I’d missed which addressed simplifying context.

I agree with Merlin Mann that contexts should be simple. I myself have been guilty of setting logical yet unhelpful contexts like @email and @calls. However, there was still something about Mann’s idea of context being strictly “what tools, resources, opportunities, and limitations are unique to this situation” that didn’t sit right with me. Defining context in such a way does not help me mentally structure my day. In fact, for me, simply knowing I’ll be at my laptop and online doesn’t help me much at all because 90% of the time that is the case.

Then, I was pointed to a particularly interesting comment on the article (emphasis mine):

I’m a writer working at home, so @computer, @phone, @home never really worked for me. Instead, I’ve matched my contexts to the way I structure my workday. The morning, from 8am – noon is for writing and editing. The afternoon, from 1 – 5 is for research, reading, email, website maintenance, etc. The evening is for entertainment and housework.

As simple as that is, it was pretty eye opening for me and illuminated some of the issues I was running into with both scheduling and context. My day was one big tornado of random high priority tasks which I had selected from my system. There was no dire problem with my daily actions list, but something was missing in-between. I needed to break my time into more manageable contextual chunks.

Schedule Buckets
Lately, I’m framing my day into what I call schedule buckets. I’ve gone into iCal and sectioned my day into several of these rather generic daily reoccurring blocks of time. Two things are outlined by these blocks… the locale and the general task type. For instance, I might have:

Home:Exercise 5AM-6AM
Home:Reading 7AM-8:00AM
Office:Writing 9AM-11AM
Studio:Production 11AM-1PM
Office:Development 1:30PM-5PM
Home:Flextime 6PM-9PM (this for odds and ends)

These buckets cover the broad activities which I feel I should be doing on a regular basis. Something like “Writing” may cross over all client projects, personal projects, internal documentation, etc. And it may encompass writing articles, lyrics, storyboarding a videocast or outlining talking points for a podcast. The specifics don’t matter. I just know I have 2 hours set aside for writing, and today I can use that time to do {fill in the blank}. And the location is set, so I know that the tools to preform the task will be available to me when that is relevant.

These buckets are all flexible of course. I can skip, extend or reduce any of the buckets as needed when my day changes. If a major project is due tomorrow which involves ruby coding, the day may become one big “Development” bucket. But at least the following day I can be directed back to focus again on all my other activities.

When something does change, I don’t have to shift dozens of granular tasks around over the next several days. I can, in fact, wait until just before a schedule bucket starts to choose the tasks to fill that bucket. Which is a wonderfully powerful compromise between my desire not to granularly over-schedule and my need for a more structured day.

Other benefits I’m seeing is how much easier it is to initially process actions in my system. I just figure out which bucket an action fits into and roughly how long it will take to do. I’m also finding projects progress more consistently and incrementally. Where before I might get lost in a single activity for a few days and come out of that feeling I needed to play catchup on the other activities, now I feel I’m covering everything pretty well day to day. I’m also less likely to overbook my schedule by taking on too much at once because I see my time in smaller, more limited chunks. That is maybe the biggest hidden benefit.

[note: this is an older post from a previous blog which I've decided to migrate over to here. I have since this time fallen in love with Things for OSX. Nothing compares to it.]

I’m a productivity nut by necessity. I have a lot of widely varying projects and activities, and if they are not carefully managed, life becomes about reacting to problems rather taking actions toward progress. A few years ago I dug into the “Getting Things Done” system and, like many others, found it to be a major positive change. Now, I don’t follow or agree with every aspect of GTD to the letter, but I do feel the basic principle and the general psychology behind it is solid. The idea of getting everything out of your head and into a system you trust in effort to relieve stress and overload is fairly profound in my opinion.

The problem is, finding the right tools to manage your system is tough. Especially if you are a relentless long-term planner with a lot of wacky, grand ideas. For a couple of years I’ve used a simple, physical notecard system to collect all my actions. It seemed to work the best for me for a long time, but as projects increased in size and I got more into applying context to my day, the physical system became cumbersome and inefficient. I needed something digital, searchable, and clean.

Applications like that weren’t really available until quite recently. Now there seems to be a glut of GTD focused applications out there. And a lot of them are pretty good. I’ve been using a free one called ThinkingRock, and they get a lot of things right.

First, let me define the various modes of a good system as I see it:

Collection – essentially brainstorming and getting any thought you have out of your head and into the system. You should never expect yourself to remember something any more than a couple of minutes in my opinion. Think of it, dump it out.

Processing – This is where you look at the pile of thoughts and ideas and decide where they go, if they are indeed actionable, steps you might have forgotten, the overall sequence of actions (we’ll get to that in a bit), the context of an action, time it will take to do, priority, etc. Really, you are just making sense out of the mess and the result is a huge amount of data amounting to your next several days, weeks, months and even years of activity and pipe-dreams.

Planning – This is where reality sets in. You know you have a finite amount of time in your day. You pick from the huge library of actions in your system resulting in a short list of things you can focus on for the day (in my opnion, this should be a daily thing at least).

Doing – Well, just that. Knocking out the actions one at a time. And while your system may not actually do this for you, it should help to focus you on those tasks.

The collection aspects of ThinkingRock are quite good. Maybe a little more cumbersome than necessary, but still, their approach is good. And frankly, several applications seem to get this more or less right. And for the most part, processing is good as well.

But, like every other GTD app I’ve tried, ThinkingRock gets two major things flat out wrong. There is an important oversight in processing and there is no assistance in planning and doing.

What my dream system would have, and I’ve yet to see, is self-aware sequencing of action and daily planning mode.

Self-Aware Sequencing – What I mean by this, simply, is that typically there is a sequence of actions that must happen for a project to be complete. Doing x allows you to do y which allows you to do z. Now, most systems will let you position the order of actions in a list to approximate sequence, but this is problematic. The whole point to me of the “processing” mode is to figure out which individual actions need to be done and in what order they fall to complete the project. So, why be forced to take that sequencing into consideration (part of the “processing” mode) when you are in the “doing” mode? I just want to know what the “next action” is for completing that project. And when I complete that, I should be shown the next action after that. I care not to know what is five steps down the line. If anything, that just stresses me out. Especially when looking across 10 different projects. That means, consciously or subconsciously, you are being forced to acknowledge potentially 50-100 actions that are in your view! Which brings me to…

Daily Planning Mode – As I said, just show me what’s next for each project. If I have 10 projects (or even 2 main projects each with 2 sub-projects), that means I’ll be looking at only 10 potential actions. If I only have time for 5, I should be able to hide the others for that day. Because, other than when you are in the processing mode (or perhaps a periodic review of your entire system) you shouldn’t have to see things that you can’t do yet. Some people may consider those actions “deferred”, but I’ll get into why I think deferred actions are a bad idea in a future post.

And both these features play heavily into the “doing” mode. Only showing you a short list of easily accomplished things can really help motivate you to knock them out quickly. Showing you more than that (and especially a LOT more than that) can make you feel like Sisyphus eternally rolling a boulder up a hill only to have it roll back to its original position. You never feel a sense of completion.

And one last item for the tool wishlist. Do all this in a web app, not a only local app. I want to access my system from any computer anywhere I go. Or even from my phone. Extra points certainly if you can have a local client for when you are off-line, but having this all on the web so you can keep synced is essential.

All that said, ThinkingRock is worth your attention, and I only use them as an example because that’s the system I’m currently using. And like I said, everyone else gets those points wrong as well. Let me know if you’ve found a tool that does them.

Call me Ryan. Sure, it’s not as snappy as “Ishmael”, but a good enough start to this spot of the web. Before getting to any real morsels of content, I figured I should give myself an informal introduction and explain what this blog will be about.

I am a co-founder of Websuasion, LLC, an Atlanta & Chicago based web development and web marketing firm. Beyond the general day to day activities required to properly run a small business, my primary focus is as Director of Customer Engagement Strategies. That dips heavily into pretty much everything a business does from the online strategies we develop for each client, to the technologies used in their business online and off, to brand/reputation management, consistency of message, presence building, etc. Anything that ultimately connects businesses with their customers, well, it’s something I obsess over.

But, despite the myriad of technical things we do for clients, we view the web (and internet in general) as being about one thing… communication.

That’s an important point. It might seem obvious. But if it were, then most sites wouldn’t be sitting around on the web like outdated billboards would they? And they wouldn’t broadcast at an audience. They would instead have conversations with their customers.

And why is this important? Because, frankly, you should be using all means necessary to build real relationships with your customers, colleagues, partner businesses and peers.

The internet, and particularly social media, is quite powerful at this kind of relationship building. And it’s my job to show you just how amazing it can be, how you should approach it and how you can measure it to clearly understand your ROI. So that’s what I’ll hopefully be doing with the help of my business partner Norbert Taylor.

In the next week we will be launching Presence: The Websuasion Podcast, and our first episode will begin to discuss using social media to improve your business. We’ll also be posting some articles to our Websuasion blog, which I will excerpt here. But I also plan to share my miscellaneous thoughts on social marketing, web design, productivity and all kinds of fun stuff. So please add me to your RSS feed if you are into that kind of thing. Also, be sure to connect with me on LinkedIn, Twitter, Facebook, FriendFeed, MySpace, Delicious, Tumblr and all those networky type places.

In addition, I’ll be doing some seminars, speaking engagements, panel discussions, webinars and the like. I’ll post any events here. If you are part of a business association or meetup group and would like to chat about “the value of web presence” and “improving customer engagement” in the Greater Atlanta area, give me a shout (ryan.williams[at]websuasion[dot]com). It’s quite affordable (read: generally free)… it’s the conversation that ‘s important to us.
.