My First Hackathon

Election HackathonThis past weekend, I went to the Washington Post’s Election Hackathon. I hadn’t been to one before, but my friend Oscar had the idea that it would be a good way to possibly get a little more exposure for Musketeers.me. If nothing else, we’d get a nice portfolio piece.

CandiData.me: Get information about 2012 US national candidatesAnd we did indeed: Candidata.me. Check out Oscar’s piece on its creation and some ideas for going forward. It was a good example for how quickly you can get a site together using Treb, the framework we built for mojoLive.

We didn’t win, partially as there were some really awesome ideas done by others at the hackathon, but partially because we misjudged the criteria for the site and provided something potentially useful but stopped early to polish it rather than really digging into the APIs to uncover some insights. With only a few hours of designer assistance from Kevin, the polish worked well, but the judges went for incomplete ideas with potential. As the Musketeer with the occasional appellation “product guy,” ultimately that’s my fault. On the other hand, I got to dust off some programming chops that had been put on the shelf while I pursued funding at mojoLive and gladhanded for clients for the Musketeers.

Presenting CandiData.me

We did get selected to present our app. You can totally identify Oscar, right?

One other note: Oscar will expand on it, but I think we did demonstrate good principles if you’re going to design something to be responsive: keep the design clean with simple boxes and rows that could reflow rather than try to replicate the report-ish layout that websites have aspired to since the 90s and that are the bane of the nonprofit world. The site still looks good on a desktop browser, but it also works really well on an iPhone.

Design for your medium, people. Don’t try to force it to be something it’s not. And as “product guy” I will take a little credit for that part.

Posted in Personal Stuff, Political Stuff, Web Stuff | 1 Comment

Help Kickstart BubbleSorter and GridSorter

I’ve always been careful to say that my new company, Musketeers.me, is a consulting and product company. Today we’re getting closer to the second (but to us, first) part of our mission. We’re launching a Kickstarter campaign to build two products: GridSorter and BubbleSorter.

GridSorter

GridSorter is best explained by relating the story of how Eli White first created the prototype: ever have a list of things that need doing around the house? Or worse, a honey-do list? Eli had that problem, and he’d already ranked everything by most important to least important. The problem was that when he had some spare time, he would look at the first thing on the list, which was a weekend-long project. So he’d put it down, and go do something else instead, and nothing was getting done. He quickly realized that he needed to categorize his tasks by both how long they’d take and how important they were.

Being a programmer, he naturally sat down and hacked out a solution: put his tasks on a grid, with one axis being importance and the other axis being time required. So now when he had an evening, he could simply look down the “takes an evening” column and grab the first task off the list, knowing he was getting the most important thing he could do with that time.

We’ve realized that a lot of you might have that problem, and the principle is even more powerful than just tasks versus time: you might have any number of things you need to sort by two different categories: for mojoLive we categorized our last push of features by importance versus user engagement, and picked the most important features that would also engage users. So the final product will have the ability to pick your two categories and drag and drop your list accordingly.

BubbleSorterBut what if you’re having trouble figuring out what’s important? Once I was trying to get a client to give us a prioritized list of tasks so we could ensure we did the most important things first, since the budget was tight and the list was long. They came back and said, “Well, everything here is Priority 1.” Not too helpful. But when I started asking, “Would you like to put more effort into Feature A or Feature B?” the client would quickly reply, “Feature B.” Out of that inspiration comes BubbleSorter.

While even just bringing in a list and prioritizing it is useful—and we’re going to give you that for free—it’s really useful when you have groups of people who are having trouble agreeing on a list of priorities. So for a low yearly subscription, you’ll be able to invite others to come in and perform the same ranking, and then using an algorithm we’ll be able to tell you what the group’s collective priorities are. This is really powerful if you’re regularly trying to get consensus in teams.

So help us make these products a reality: watch the video, see what you will get for each backing level, and join our Kickstarter.

Posted in Personal Stuff, Web Stuff | Leave a comment

Monday Morning Kodi Blogging

Kodi decides I make a good pillow

Nap buddy.

Posted in Personal Stuff | Leave a comment

Newer Venture: Musketeers.me

Precision Web Application DevelopmentIn addition to my personal consulting in strategy, I’m excited to announce that, together with Eli White, Oscar Merida, and Kevin Bruce, I’ve become a part of Musketeers.me. We’re focused on building cool web applications for others and for ourselves. So if you need an experienced team to build something challenging, let us know.

Posted in Personal Stuff, Web Stuff | Leave a comment

Over at the new blog, I show how starting with the phrase “How hard would it be to make a button…” usually ends up costing extra and frustrating everybody. Try instead to say, “Here’s the problem I’m having. What can we do?” You’ll be amazed at the results.

Posted on by Sandy | Leave a comment

Again at my new blog, I have a post about the importance of working with a developer when planning your site, and continuing to work with them throughout the life of your site.

Posted on by Sandy | Leave a comment

At my new blog, I look at how trying to tie all your applications together with one login (Single Sign-on (SSO)) is usually a complete waste of money and look at alternatives.

Posted on by Sandy | Leave a comment

New Venture: Helping organizations work with web devs

On the side, I’ve started a new blog and consulting practice. Since I’ve worked as a web dev but have business, strategy, and policy experience, I’m in a good position to help organizations help themselves when they contract with web developers and web development shops.

So if you need some help figuring out how to get the best results out of your next web engagement, contact me.

Posted in Personal Stuff, Web Stuff | Leave a comment

Wednesday Afternoon Kodi Blogging

By request, Kodi discovers the lake. And splashes at the edge and proceeds to roll around in the muck instead.

IMG_0479

Posted in Personal Stuff | 5 Comments

CMS, Framework, or DIY: How do you choose?

Web developers and web development companies frequently start each project as if they only things that need to be built require merely different types of nails, and luckily they have a hammer. In fact, they often call themselves “Drupal developers” or “Ruby on Rails developers” rather than Web developers (or software engineers). The opposite also happens, where someone will approach each project as a custom, ground-up web development project. Wars inevitably break out over what platform is “best” for web development. Purists slag framework devs as lazy and imprecise, framework devs slag CMS developers the same way and purists as wheel-reinventors, and CMS devs slag the others as wheel-reinventors and one another as using an “inferior” CMS.

The best developers I know may have favorite tools, but they either put them aside when they’re the wrong tool or pass on inappropriate jobs in favor of projects that match their preferred development niche. Others simply choose the best tool for the task at hand…but that choice can be the first point of blank page syndrome. What follows are questions to ask yourself and how the answers can influence your choice.

What does the client expect?

Every project has a client. Even if that client is yourself or your boss, let alone someone who is paying you for a bespoke web application. Sometimes they have particular ideas, for good or ill. You can try to argue the choice if you think it’s wrong, but ultimately the person paying will have to approve your choice. Obviously if you’re adding on to a Drupal website, you have to make a pretty strong argument that Zend Framework is the right choice. (Though I’ve seen it done.) In the nonprofit sector, for example, there’s a huge preference in favor of Drupal for anything larger than a basic site or blog. A previous company I worked for tried to argue for a different solution, but ultimately had to deliver what clients wanted as many dropped non-Drupal proposals immediately.

What is the legacy technology stack?

It’s been a decade since the average web development project was “helping an organization finally get on the web.” Even new projects in existing organizations are often project-specific websites in addition to the main organizational site. Sometimes organizations have a large infrastructure dedicated to serving other sites. While in general I’m not a fan of people hosting their own sites and often throw out the sunk cost fallacy in arguments, sometimes it’s easier to reuse existing equipment and experience than introduce a new technology stack. So if an organization has a ton of ExpressionEngine sites, asking them to host a Drupal site may not end well if they’re not familiar with keeping Drupal up to date or staff need a lot of handholding to use a new system.

What does the end product mostly do?

Even if the excitement is around a small application on the site, if the bulk of the requested functionality revolves around managing web pages, articles, and comments, then starting with a CMS may be the responsible thing to do. While every CMS entails design tradeoffs and limitations that often drive experienced developers nuts, I’d rather focus my development effort on getting that one web application right and adapting it to the CMS’s module structure and API than rebuilding page, menu, login, admin, and comment functionality again.

What will the application do over time?

Small organization sites may live forever as a basic set of rarely-updated pages. Most restaurant pages only need to update menus and maybe an events calendar. Intranet applications will tend to get added on to and fixed over time but never have a vast number of users. And that social networking site may become Facebook.

While lots of startups jumped on the Ruby on Rails bandwagon after Twitter took off, Twitter ended up rewriting most of their site as they scaled. The tradeoff was a quick minimum viable product versus a platform they could easily grow as time went on, and there was a period in which had another service arisen on a more reliable stack, we’d remember Twitter the way we remember Friendster. At mojoLive, we looked seriously at Zend Framework since it was built to have any individual component thrown out for a custom replacement as was needed for scaling, but ultimately it didn’t help us do enough of the hard things easily and would require a significant learning curve to build something we knew was going to be thrown away. Building a custom app based on some code Eli had lying around with a minimal MVC layer didn’t slow us down appreciably over picking up a new framework.

Startups and large enterprise applications also have developers working on them all the time, unlike small organization sites. In the latter case, a well-known CMS is going to be a lot easier than a custom-built CMS for someone to come along and update when you’ve gone on to bigger and better things.

What do you know?

Unless you’re doing a project specifically to learn a technology (and it’s either personal or the client has approved you taking on something you don’t already know because they’re awesome, desperate, or you gave them a big discount), it’s rarely a good idea to start with something you don’t know. Even if you know PHP inside and out, Zend Framework and Drupal have layers of best practices specific to those environments that take time to learn. And jumping from an object-oriented or imperative language to a functional language is…challenging, to say the least.

When is the project due? What’s the budget?

There’s no point in building a new CMS that’s going to take over the world just to churn out a 3-page site due end of the week. The less time you have, the more you’re going to want built for you. Similarly, you’re going to want to stick closer to what you know.

TL; DR

There is, unfortunately, a lot of overlap in the capabilities of systems. Obviously you can ground-up write any app in existence, if you have enough time and budget. (And skill and experience and…) That being said, you can make Drupal into a 300+ mini site system with overlapping permissions, 12,000+ shared users, and single signon with Salesforce. It wasn’t my first choice, but the mix of familiarity, budget, and client expectations led me there. That being said, it was a huge pain and the gains of the CMS components were probably overwhelmed by trying to shove a very idiosyncratic enterprise-level set of requirements onto a CMS whose sweet spot is rapidly building middling complexity content management sites with community features.

In general, though, sites that primarily content belong to CMSes, sites that are primarily web apps with tighter deadlines or without huge growth requirements are better off with frameworks, and sites that are going to be constantly developed and scale rapidly are likely best ground-up. You can find exceptions to all of these, and there are clever people who’ve built simple ground-up CMS apps and made WordPress run massively complex sites, but that rule of thumb should keep your next project from being a cautionary tale of trying to hammer in screws.

Posted in Web Stuff | Leave a comment