Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 1

Infinite scrolling inside a div with CoffeeScript & Kaminari

November 14th, 2012 · 5 Comments

I created a form with a hidden field called ‘page’ in my div where I want infinite scrolling to happen. Then I set up my controller action for the action in the normal way with pagination by kaminari:

def campaign
  @testimonials =[:page])

  respond_to do |format|

In campaign.js.erb I simply append the new results to the bottom of the div.

The last bit is to write some coffeescript that increments the page field and submits the form when you scroll to the bottom of the div:

loading = false

$('.testimonials').scroll -> 
  if $(@).scrollTop() + $(@).innerHeight() >= $(@)[0].scrollHeight
    unless loading == true
      loading = true
      page = parseInt($(@).find('#page').val())
      loading = false

Oh, yeah, the page field needs to start out with a value of 1.

Bam. Easy infinite scrolling in a div.

→ 5 CommentsTags: Uncategorized

How to Use a Spinner with Turbolinks

October 12th, 2012 · 2 Comments

This is dead simple, but it’s an important improvement if you are using turbolinks on your Rails app. It’s most relevant if you have pages that have some significant database heavy lifting to do because without it your users won’t know that your app is working. A tiny bit of really simple javascript is all you need to add a spinner or some other alert to your site:

$(document).on('page:fetch', function() {
$(document).on('page:change', function() {

Put whatever suits your fancy in #page_loading and you are off to the races.

Hat tip to Matt DeLeon who helped me figure out all the changes TroopTrack needed to work with Turbolinks.

→ 2 CommentsTags: Uncategorized

Using the Audited Gem to Audit a Model Under Certain Circumstances

July 31st, 2012 · No Comments

I have a situation where I need to turn auditing on once a model reaches a certain state. Google didn’t seem to know how to do it, so I thought I’d post how I did it for posterity.

The setup is simple – just add audited to your model just as you normally would, then override your save method, something like this:

  def save
    if Business.audited_statuses.include? status 
      without_auditing { super }

Note: You will probably need to change this up a bit if you want to be able to save with options (like :validate => false).

→ No CommentsTags: Uncategorized

How to replace formtastic inline hints with tooltips

July 26th, 2012 · No Comments

This little bit of coffeescript can be used to replace inline hints from formtastic with a tooltip that appears whenever the user hovers over an image.

$('.formtastic p.inline-hints').each (index) -> 
    label = $(this).siblings('label')
        "<a href='#' title='" + 
           $(this).html() + 
           "' class='hint_modal'>
           <img src='/assets/qm_small.png' 
           style='vertical-align: middle;'/>

→ No CommentsTags: Uncategorized

How to Re-size Images that are Too Large on-the-fly with Paperclip and Rails

July 9th, 2012 · 2 Comments

One of my users recently complained (rightly so) that my limit on photo sizes of 2MB meant they had to re-size every photo before uploading them because almost no modern cameras create photo files that small. So he requested that I re-size them on the fly the way our cell phones do when we send photos via text.

I really only wanted to re-size photos larger than 2MB and leave smaller photos alone. This turned out to be pretty straightforward – the only part that took some experimentation was how to leave the smaller photos alone. It turns out that if you just return an empty string for the style, paperclip will leave the original alone. Here’s the code.

class TroopPhoto < ActiveRecord::Base
  belongs_to :troop
  belongs_to :photo_album
  has_attached_file :photo,
    :styles => {
    :original => { |instance| instance.resize }, #stupid emoticon. That is colon original! 
    :large => "800x800#",
    :medium => "240x160#",
    :small => "100x100#"
    :storage => :s3,
    :s3_credentials => "#{Rails.root}/config/s3.yml"
  attr_protected :photo_file_name, :photo_content_type, :photo_file_size, :troop_id, :photo_album_id
  validates_attachment_presence :photo
  validates_attachment_size :photo, :less_than => 5.megabytes, :message => "Photo size exceeds size limitation of 5MB"
  def resize
    if self.photo_file_size > 2000000

Someone is probably going to point out that 2400 x 2400 is quite a bit smaller than 2MB and I could probably resize anything larger than 1MB to 2400 x 2400 without causing problems.

My response is … yup. I’m gonna play with it a bit to see what the best cutoff size is. But this works for now.

→ 2 CommentsTags: Uncategorized

Creating a User Guide, the Lean Bootstrap Way

June 12th, 2012 · 2 Comments

If You Need a User Guide You Have Already Screwed Up
This is a pretty commonly held belief among designers, and it rings true because there is some truth to it. I would amend this platitude to read as follows:

If you need a user guide BECAUSE YOUR SOFTWARE IS HARD TO USE, you have already screwed up

I have resisted multiple requests to provide my TroopTrack users a user guide over the last four years for exactly this reason. When my users asked questions, it was mostly because parts of TroopTrack were poorly designed. So, most of the time, instead of writing a user guide, I would simply use their input to guide a re-design of the feature in question. This was educational for them and for me, and it was absolutely critical in the learning-process as a product owner for me. This back and forth design cycle between the users and myself helped me to understand their problems well enough to build a product that is, in my opinion, the best scouting software on the planet.

There are Other Reasons For Needing a User Guide
I frequently call trial users and ask them how things are going and if I can help them get started. Perhaps this was just a freak coincidence, but two customers in a row told me the exact same thing:

Your software looks nice but we went with because they have a user guide.

These interactions taught me that there are other reasons for having a user guide that have nothing to do with software design.

  • Reason #1: A user guide is frequently an important item on the evaluator’s checklist, whether your software needs one or not. Not having a user guide often means they won’t even consider your product.
  • Reason #2: Purchasers of scout software have to convince a committee that my product is the right one and the lack of a user guide makes that a more difficult task.
  • Reason #3: A user guide is often perused by potential buyers as a way of seeing what your software is able to do for them.
  • Reason #4: No matter how well designed your software is, some users prefer learning through demonstration over learning through experimentation. Those users need a guide, or a video, or something.

Why You Should Just Roll Your Own User Guide Infrastructure
There are solutions out there building wikis and user guides etc. Some of them are free and many of them are not. I’ve tried lots of different things over the years, including:

  • RedMine – too painful and ugly
  • ZenDesk forums – forums aren’t user guides and users leave my site
  • Atlassian Confluence – lovely but expensive
  • Comatose – the gem is dead, unmaintained, and stale
  • Refinery CMS – I don’t want a separate admin tool for help pages (otherwise I lourve Refinery CMS)
  • ActiveAdmin + Awesome Nested Set + CK Editor – User guide bits and bites delivered in less than an hour!

I already had active admin, and it’s super easy to add CK editor to active admin forms, so all I had to do was create a simple model with a title, body, and the ability to nest pages. With Rails, I was able to do that in about a half an hour, but I rounded up to an hour cuz I don’t want to seem vain. :)

What About the Content? Let the questions be your guide
I use ZenDesk for my support tickets, and about half of them are questions. I’ve fallen into a pattern with these support tickets that I think is very lean. Here’s an example:

Hi John,
Based on your question, I put together a new page in the User Guide this morning to show how to edit user info such as birth date and phone number. Here’s a link:

Please check that out and let me know if it doesn’t work.


Dave Christiansen,

I like this approach because it doesn’t duplicate effort and I know the content is needed. The problem with this is one I experienced when I was trying to use ZenDesk forums in the same way – it’s easy to end up with an unstructured mess unless you give the user guide a structural smackdown as you go.

I started out with a skeleton that mimics the structure of my application. This is a pretty common approach and let’s face it, there’s no huge need to be innovative here. A user guide that is structured like the application is pretty intuitive. It might be more artsy to write it like a novel, but … (Oh, hang on, I find myself tempted to try that).

A Page a Day Keeps the Wrackspurts Away

I went on a bender one weekend and wrote about ten pages in a day. That drained me of all energy for writing for about a week, and I suspect it is not a sustainable way to do it. I’ve since switched to a page-per-day approach. Sometimes I will write more if I have user questions to answer, but if I don’t I stop myself at one. At one page a day I will have a fairly comprehensive user guide by the end of June.

Don’t Over-Invest, Mis-Invest, or Pre-Invest
A few years ago I was part of a project that hired a technical writer to write a comprehensive user guide. We paid her thousands of dollars and she did a very nice job, but I’m not sure the user guide was ever really put to much use. We still got lots of questions that weren’t covered by the user guide, and our customers started asking for the ability to customize the user guide for their particular policies. We had over-invested, mis-invested, and pre-invested in the user guide. All of these were mistakes.

The meaning of over-investing is probably obvious. Spending more on a user guide than is needed. Mis-investing and pre-investing may not be so obvious.

Mis-investing is spending your user guide investment on the wrong things. Our tech writer set out to cover every single feature of our software, from logging in to logging out. There were lots and lots of pages that I reviewed that merely re-stated what was obvious from the user interface. This was a mis-investment.

Pre-investing is spending your user guide investment BEFORE your product is stable enough to be documented inexpensively OR before you really know what users are confused about. Pre-investing and mis-investing usually go hand-in-hand because you are GUESSING what documentation is needed and you are going to be wrong some large percentage of the time.

User Guides Can Be Good Investments if You’re Careful
Needing a user guide doesn’t necessarily mean you screwed up. But you should be certain that investing time and money into a user guide is the right thing to do. It is very often the case that you should be fixing your crappy software instead. That was definitely the case with TroopTrack for several years, and even now I don’t try to “user guide” my way around a feature that is poorly designed. I just fix the feature.

Also, don’t spend money on user guide pages you don’t need. Let users show you the way so that you don’t mis-invest. Only add pages you imagined up to meet a marketing or structural need.

If you’re curious, you can check out the user guide infrastructure I cooked up for TroopTrack (in less than an hour!) here:

→ 2 CommentsTags: Uncategorized

Re-imagining TroopTrack in a Use-Case-Centric Architecture

May 16th, 2012 · 1 Comment

Please read this first if you are a TroopTrack user
My blog is read, not only by coders like me, but also by a pretty decent number of TroopTrack users. I just put them through a fairly horrible major release, after which I swore I would never do an X.0 release again, so I need to start this post with an assurance. Please don’t interpret this post as a sign of things to come regarding TroopTrack. This is merely a hypothetical discussion to help me understand a concept being advocated by a fellow programmer whom I respect but whose ideas have troubled and frustrated me for the last year or so. There will NEVER be another major TroopTrack release. All changes will be incremental as previously promised.

Throwing the gauntlet down with Uncle Bob
This post is a follow on to an earlier post which was a response to a post by Uncle Bob Martin, author of Clean Code and other noteworthy books about software development. There were some tweets involved as well, but to make things easier and get you caught up if you haven’t been following along, just read these posts first:

Perhaps I Got It More than I Knew
About a year ago I embarked on a major re-design of TroopTrack. One of the changes I made was to group functionality in the five major uses cases of my software. This grouping is evident in the UI:

And in the code:

I show here the controllers folder, but if you looked in the views folder you would see something very similar – I’ve namespaced my application based on the major use cases of my system. Like FitNesse, there is plenty of cruft in there and, since it’s a rails app, things are pretty much glued to HTTP.

This may seem like a relatively small change, but it has had a dramatic improvement on TroopTrack overall. For one thing, TroopTrack’s “first glance” grade improves significantly. It’s a lot easier to see what TroopTrack does than pre-namespacing, when everything was just lumped in one sloppy bucket. For another thing, this improves separation of concerns at a higher level and lets me think about the same bits of data differently in different contexts.

Let’s Be Honest Here
Namespacing TroopTrack this way is nice, but let’s not call it a use-case-centric architecture. It’s not. It’s simply more use-case centric than it was. Whoop-dee-doo.

One of the frustrations I encountered in TroopTrack 3.0 was that I couldn’t namespace models. The “user” I deal with in Communicate is rather different than the “user” I deal with in Manage. Perhaps it would be more accurate to say that I wish they were different, in spite of the fact that underneath it all is a database structure that they share. You see, in Communicate I really only care about a few things related to the user:

  • Their name (not the parts of it)
  • Their email address
  • Mailing lists they belong to
  • Their privileges related to editing web sites, uploading documents, sending messages, and sharing links

In Manage, I have a much larger set of stuff I am interested in:

  • First name
  • Middle name
  • Last name
  • Household they belong to
  • Birthday
  • When they joined scouts
  • What scouting unit they belong to
  • Their avatar image
  • Medical information about them
  • All their privileges
  • Their access level
  • etc.

It bothered me that I couldn’t namespace my models the same way I namespaced my views and controllers. Why can’t I have a different set of validations, accessible attributes, methods, etc for a different high level use case?

Note: this is a rhetorical question. In rails, you can in fact accomplish at least some of these things by adding logic to your validations and adding :as => namespace to your accessible attributes. But it’s not what I would call clean and, since all this stuff would wind up being in the same model file as every other namespace it would murkify intent in significant ways.

What I’d Like to Have
At some point in the future, I’d like to bust open my source code and see something like this:

I’m not 100% sure what the controllers here would look like. It might be nice to un-marry them from HTTP, but the pragmatic part of me is not totally sold on that. I might just call them HTTP controllers or something, just so there is semantic congruence between what they are called and what they are.

I like the convention for naming views in a way that shows their action, format, and the language used to implement them, like so:

  • show.html.haml
  • show.pdf.haml
  • show.json.erb
  • etc

It would be important to be able to disconnect the views and controllers from HTTP if needed, so that I could continue to use them with other protocols. The pragmatist in me says “leave that step until you need it, just leave room for it for now”, and I agree with him at the mo. It would also be important to put some thought into keeping the views from being too married to models, but I think this might have more to do with the models than the views.

Neither of these things are a HUGE departure from things we’ve seen before. In fact, you could probably take different parts of Rails and bend them to your will to support an approach like this.

The problem is, you could go this far and still end up with an architecture that is fundamentally data-centric. In order to be truly use-case centric, you need to have models that reflect the use case as much as your views and controllers do.

The Models are the Big Deal
For the most part, models tend to be 1:1 matches to the way the data is stored. A model’s class usually represents a table and an instance is a row. The model you build just adds behavior on top of that data. This is convenient, especially in a framework like rails where active record adds some magic for all sorts of stuff, but the 1:1 mating of a model to a table is limiting.

Ultimately, it might be valuable to break both this 1:1 mapping and the tight database coupling to allow for a model to be “storable” in multiple ways. I can think of cool uses for this including an often-requested feature that TroopTrack currently doesn’t have – the ability for a scouting group to get/restore a csv or sql or json backup of all their data (TroopTrack is a multi-tenant application).

That’s all well and good, but I think there is a simpler advancement that is needed that is also more important. I mentioned it earlier in my example about how I care about different aspects of users depending on whether I am in the manage use case or the communicate use case. I think it boils down to something simple.

Models need to be a reflection of the use case rather than a reflection of the columns on a table plus a generalized set of behaviors.

At this point I can hear Bob Martin cackling ruthlessly. It’s what he’s been saying all along. Sometimes, you just gotta see some code to believe it.

→ 1 CommentTags: Uncategorized

Dear Uncle Bob: Please, please show me the code

May 15th, 2012 · 9 Comments

Focusing on the Use Case Appeals to Me
I really liked your recent post about use-case-centric architectures. It’s not the first time I’ve witnessed you rant about your frustration with database-centric architectures, but for lots of reasons this time it resonated with me more than in the past. In my view, this was the best explanation of your viewpoint yet and I appreciated the lack of theatrics and irrelevancies that are common in rants. It was a well-reasoned rant. Or is that an oxymoron?

Also, like the previous times I’ve been exposed to your mantra, I found myself wanting to try it. I want to build an application that is focused on the use case. I want to go to a source code folder, pop it open, and know immediately what the app is all about. Really. I think that would be AWESOME.

My Use Cases have My Process Wrapped Around Their Finger*
Use cases drive my development process. They are where we start and they are the core bits of our workflow. We don’t start development by defining a data model – we start off by asking “What do you want to do?”. Over and over and over. It’s the most fun you can possibly have on an untethered ferris wheel, like rolling down a hill inside a tractor tire.

This is perhaps THE reason why the idea of architecture and code revolving around a use case is very intriguing to me. It seems to work pretty well on the process side, wouldn’t it be cool if it also worked on the coding side?

Heck yes it would.

*As long as you are willing to include user stories as a form of use case this is true anyway.

This is Where the Party Ends
I won’t lie. As much a I want my architecture to revolve around my use case, I really can’t imagine up how to do it, and I’m no dummy. When you complain about the way rails apps are structured in a way that communicates only that they are a rails app, that the architecture doesn’t say anything about what the software REALLY is, I can’t help but wonder what it SHOULD look like. And I have no answers.

Seeing is Believing
Clean Code showed me how code can be. It’s an epic work, in large part because it SHOWS you how to write clean code. Seeing code go from crap to clean helps readers understand the principles behind clean code. It’s the best way to teach, and frankly, based on my limited exposure to the things you’ve written, it’s your best work.

The Gauntlet
You’ve been harping on about data-centric architectures sucking and how use-case-centric architectures are the hypothetical shizzle for a while now. I started paying attention to it about a year ago, but I’m pretty sure your lost-architecture thesis predates even that. I don’t have a problem with the idea, I just have a problem figuring out how to use the idea.

So, how about you show me? Show everyone, for that matter. Build a use-case-centric application so that next time SCNA rolls around you can follow up your picture of a rails app and its root directory structure with an example that doesn’t suck. Make it work on the web, and throw in an api for mobile for good measure. As you’ve mentioned in the past, these are trivial issues anyway and shouldn’t dictate architectures. But we still need apps that use these mediums, and we don’t have solutions that make the use case king.

So, there. That’s the gauntlet. I’m throwing it down. Please, please, please, put up.


Dave Christiansen

→ 9 CommentsTags: Uncategorized

Kick Sprint Reviews to the Curb

May 11th, 2012 · No Comments

User Stories Suck for the Last Mile

Yeah, that’s right. I said it. User stories suck for the last mile. What’s the last mile you say? It’s a term borrowed from my telco days, when Sprint had a U-verse-like offering that was way ahead of its time and you could only get in Kansas City. It was awesome. But it died, because getting the last mile of networking was proving to be too expensive. The last mile, in this case, was the distance between Sprint’s closest network terminal and your house.

For user stories, the last mile is the distance between the story being functionally complete (i.e. everything works as expected) and accepted (i.e. and it looks the way I want it too). It is often a long list of layout and style changes like “left-justify X” and “make the margins line up between Y & Z”. These changes are often hard to communicate via written words, but more importantly the delay between feedback and development is too long and, since the changes tend to be small, the cost of switching tasks between all the stories that need tweaking can be pretty spendy.

Sprint Reviews Can Make This Worse

If most of your feedback collecting occurs at the sprint review, this only becomes worse because the person recording comments is frequently not the person giving feedback. Usually, one team member takes notes while the other team member demos stories and the product owner(s) discuss changes. As a result, you create this huge backlog of bugs, tweaks, chores, or whatever you call them that you do prior to the stories being accepted and you starting new ones.

Years ago I started a practice of implementing as many of the tweaks as I could immediately following the sprint review while they were fresh in my mind, but it’s still not optimal. Why?

Because the sprint isn’t finished. We walked out of the sprint review with more stuff to do prior to the stories being accepted. This is a bit discouraging, especially if even more problems are found after the initial round of tweaks go in. If you end up going through cycle after cycle of tweaks, discouragement turns into frustration.

“Peer” Programming Works

About two months ago I gave up on sprint reviews. Instead, when I finished a story I simply skyped at my product owners that I was done, even before I pushed my code or marked the story delivered. I shared my screen with them, gave a demo, then they would just type changes at me in Skype, which I would implement in real time. Because we were using IM and screensharing, they could keep doing other stuff while I made the changes. When I was done, I’d IM them back and we’d start over. After a while, the feature was done. I’d push the code, the CI server would update test, they’d give it a final run through and accept the story. Piece of cake.

I call this peer programming rather than pair programming just because only one of us is actually programming, but the peers are giving feedback in real time. It’s very, very efficient, and we haven’t had a sprint review since we started doing this.

Take It Up a Notch for the Big Event

Earlier this week I spent three days onsite “peer programming” with the product owners. We set up shop around a table in the Developer Town offices with my second monitor where everyone could see it and went through the application one feature at a time tweaking features prior to ‘soft’ launching the new product on Wednesday afternoon. It was exhausting, but the end product is totally awesome.

This kind of pre-launch peer programming is a perfect way to efficiently get all the little details right. It’s very effective communication because the feedback loop is super short and the people with questions and answers are together. It’s a lot better than a sprint review because, among other things, the story gets accepted at the end of the session.

Making it Productive

Here are some pointers for making peer programming work well:

Have the product owner verify that features are “functionally complete” prior to the peer programming session. They can make sure the workflow is working in a relatively bug-free manner so that the changes that are left are going to be primarily small changes to the design and layout.
Use developer-tools to make CSS changes in real time, then copy them into your code once the change you are making looks right. This minimizes the amount of time between code change and feedback (you don’t even have to refresh your browzah).
Peer program as soon as a story is functional. That way, your mind is still in the code and you don’t have to re-acclimate yourself. This has the added benefit of avoiding a deliver-reject-restart cycle, which is a bit demoralizing.
Take breaks when you need to. Peer programming is tiring, so step away from it every now and then if you are in a marathon session of it. If you get worn out you will also get stupid.
Crack some jokes and don’t get all mad. Peer programming can be hard for a certain type of person. You know who you are. You don’t like criticism and every little change is a personal attack. You’re in the wrong business. Okay, seriously, there aren’t many people like that and most of them work in corporate IT environments, but it’s easy after really long peer programming sessions to start getting frustrated and worried that you’ll never get it right. Just take a deep breath and hang in there. Slog on through, and try to crack a joke or two if you start feeling defensive.
Peer programming throughout a sprint is definitely more effective than using a sprint review as a periodic feedback point. If you can’t get your product owner to review stories during the sprint, just replace the sprint review meeting with a peer programming session and get through as many of the stories as you can. When you run out of time, schedule some more time. Wait – we just said they didn’t have time during the sprint – why can we schedule it now? Because peer programming is something most product owners will really like. They get to see the site change in real time and find lots of value in this. Everybody can find time for the things that matter to them, and once product owners get it they will free up time.

Sprint Reviews without Demos

So, we just kicked sprint reviews to the curb, but should we really abandon them altogether?

Maybe. It’s very easy for demo-less sprint reviews to become meetings with high ceremony and low value. It’s probably better to not have them than to have those types of sprint reviews. I would only hold a sprint review if there are meaningful issues to be discussed, and then I would plan retrospective activities to help work through the issues. Rote sprint reviews are a waste of time. Make them meaningful or toss them.

→ No CommentsTags: Uncategorized

Predicting who will convert from a trial customer to a paying one

April 19th, 2012 · 2 Comments

Like a lot of Software-as-a-Service products, TroopTrack gives potential users a chance to try it out for free for thirty days. After 30 days, if the customer likes, they buy a subscription.

TroopTrack conversion rates vary from month to month, but at a minimum, 10% of my trial customers convert to paying customers. I’ve been trying to figure out ways to improve that number over the years and some of my experiments have yielded fruit. For example, if I am able to reach a trial customer by phone early in the trial they are dramatically more likely to convert than those I never talk to. The conversion rate (anecdotally) is upwards of 70%. Basically, almost everyone I talk to ends up buying. They don’t forget the one product they tried where the owner actually called them.

I’m very interested in figuring out how to increase the likelihood a customer will convert, but I’m also very interested in predicting whether they will. To this end, I’ve been gradually developing a model for measuring their engagement.

It all started with login counts
A couple of years ago I started displaying how many times the person who signed up for an account has logged in. This was immediately insightful – at that time 90% of my trial customers were logging in once and then never logging in again. Of the 10% who were left, most of them bought a subscription.

This intrigued me and I started calling customers, as I mentioned above. I was really trying to figure out why they never logged back in after signing up, but I got distracted by the effect calling customers had on their purchasing decision and stopped asking about why they hadn’t logged back in. My logic then was simple – calling them had created an incentive to look more thoughtfully at TroopTrack so why bother figuring out why they’d given up the first time?

Engagement is more than just how many times the account owner logs in
Since that discovery way back when I’ve watched login counts quite carefully, if not formally. If the person who signed up for TroopTrack (i.e. the account owner) logs in a second time, I have a dramatically better shot at signing them up. I began to wonder what else I could look at to figure out how engaged my customers are during their trial period. So I added another metric – the total number of users in a troop and the number of times they had logged in.

New observations emerge
The user count helped me understand something new about my customer’s behavior. Most trial accounts that don’t convert only create one other user – a scout. It makes sense to do this – they want to see what info we track for a scout right away so they go there first. That seems to be the general first milestone: Add a Scout.

The next milestone I’ve observed on the path to purchase is similar: the account owner adds another adult user and invites them to check out TroopTrack. If this person logs in more than once then things look good. How good? No clue yet.

There’s one more milestone that I can currently see that is important: loading users en masse. At some point in the trial a troop adds more scouts and adults and invites them all to check out TroopTrack. At this point they have pretty much already made a decision to purchase and they are just waiting for the trial to expire and for me to ask them to pay up.

The Engagement Metric
This morning I decided to add a new metric to my admin console. I call it the activity score. There are a lot of things a troop can do during their trial period, and I’ve decided to give them points for each of them. The points aren’t weighted (yet) but they may be later on. Basically, I assign an activity point every time a troop member does something I care about, like log in, add a user, record an award, upload a photo, plan an event, etc. I aggregate these points in my admin console and I plan to keep a record of the number of points a troop has on the last day of their trial period as well as the outcome of their trial (purchased, didn’t purchased). It will be interesting to see what I learn from this.

I’m also thinking of adding a features used / not used list for each trial account. That will help me know what to talk about when I give a troop leader a call and offer to help. If a troop isn’t using event management, I can talk with them about that. They might be having trouble figuring out the features they aren’t using and I can help them out with it. I hope that will help.

PayPal sends me more emails than anyone else except pivotal tracker, and that’s awesome
Right now I get an email from PayPal almost every day. Yeah, you got it – someone sends me money almost every single day. It’s pretty cool. It’s not a lot of money, from $5 – $200, with the average being significantly closer to $5 than the latter.

I’m not entirely sure how relevant that little aside is to my rambling about engagement, but it’s important to me. After four years of plugging away on TroopTrack, I still believe, and the evidence that I should believe gets a little better every day. Just sayin’.

→ 2 CommentsTags: Uncategorized