Archive by Author

Introducing Widget Bakery

After 8 very productive hours with my designer today, I have a bit to show.  We worked at his house and, in between random banter with his wife and eating some very nice Japanese-style pizza, he banged away at the design of the page and default widget behavior and I got to work on some heavy duty Rails/Javascript magic.  Sadly he is much better at design than I am at web programming, so I did not progress quite as far, but things are looking up.

So the project name, which I haven’t mentioned to anybody yet, is Widget Bakery.  I’d encourage you to go open that up in another window — there is a full design for the front page posted, less much of the content.  As should be obvious, everything is heavily in development so don’t expect you’ll see any of the verbiage or design work stay there permanently, but I thought I would get the ball rolling so that people didn’t think I had completely abandoned the Sprint.

On the functionality front, I’m afraid that because Widget Bakery’s fundamental behavior involves being responsible for content on 3rd party websites, I really can’t show you anything useful this early in development.  Database schema and whatnot are still in a state of flux and anything which I post, and which you might subsequently post to your blog, could suddenly break.

Plus I would really, really hate if one of my widgets actually became popular before I had, oh, put indexes on the table ids or turned on caching… almost melted my poor laptop today during testing.  Word to the wise, kiddies: despite it being so obviously necessary you’d expect them to do it for you, Rails will not automatically slap database indexes on your id columns, and then you get to do full table scans every time you pull in linked objects.  Gotcha!

So in lieu of live functionality I give you this screenshot of a widget which does actually function:

Sample Widget

As you can see I sort of have my work cut out for me on the CSS front, to get that footer text working properly.  You can’t see all the “fun” I had playing with iFrames, Javascript, and the DOM model to be able to inject that sucker into (just about) any page on the Internet and have that plus button bring up a Lightbox in the middle of their page to give instructions on how to embed the widget.  There still needs to be quite a bit more tuning done there — if you don’t hit the “close” button for the Lightbox at the moment there is no way to cancel out of it, which is quite unfriendly to the user.  (I’d like to get back the old “click anywhere to dismiss” Lightbox functionality, which is going to require further DOM spelunking.)

The RSS parsing, though, is done.  It needs to have error handling and some caching added, but after that I’ll have one widget ready of the baker’s dozen I hope to launch with.  Unfortunately, at the moment actually making that widget requires access to the server console and typing things like

@widget.version.latest.options[:rss_url] = “http://www.example.com/rss”

I’m going to have to get that functioning in a nice, easy to use GUI.  And then repeat or reuse that GUI for each type of widget, while making their internal differences fairly transparent to the user.  Lots of work to do, no time to do it — time to shake and bake!

Leveraging OSS As A Software Developer

Cards on the table: I sell proprietary software, do occasional OSS work on both a volunteer and paid basis. and have been known to post to Slashdot on occasion about my love of Windows Vista.  This either means I’m sort of an agnostic in the wars of religion over software business models, or that I really love making enemies.  But I’m more of a fan of making friends, so I’m perpetually trying to convince members of both warring camps that they can get a lot of what they want out of the others.

One perpetual worry on the Business of Software forums is that some OSS developer (invariably a grungy, marginally employed coder with Jolt stains on his T-shirt) is going to come along, clone your application, and eat your lunch.  As a result there is a certain amount of hostility among small software developers towards OSS, which is a shame.  I spent some time earlier trying to address myths about it, but I thought I’d go one better and focus on ways OSS can make you money.

Concentrate On What You Do Best.  Let Other People Do Everything Else

Currently I’m finally getting restarted on my latest project, which is a web service that helps small businesses do content syndication across the Internet.  There are a number of interesting technical challenges here, including both server-side (“How do I let a person who is potentially only paying me $9 a month generate tens of thousands of pageviews without the server bills putting me in the poorhouse?”) and client side (“How do I use Javascript to make the whole process pain-free for non-technical end users?”). 

As it turns out, I’m a fair hand at some portions of the puzzle, but portions of it are complex.  Very complex.  You have no idea how far down the rabbit hole goes in web development, Alice.  I honestly think that it is impossible, flat out impossible, for any one person to be expert at all the technologies which are implicated by a trivial web application running on a modern web stack.  This includes everything from HTTP to the DOM model to Javascript to the database to relative velocities of the little spinning bits of metal that make everything work. 

Thankfully, programmers get this lovely tool called abstraction, which means we can concentrate on one bit of the problem at a time and treat the rest of the world as a Solved Problem.  For example, when I’m working on Rails, I am not thinking about the L1 cache policy on the server.  In fact, although I really appreciate my $150,000 CS degree, it is entirely possible that I will grow old and die without ever once worrying about L1 cache.  Smarter people take care of that stuff for me.

OSS Is About Smarter People Taking Care Of That Stuff For You

One key feature of my content syndication widgets is that they be able to spread without requiring user action away from the host site, to avoid antagonizing hosting site owners.  This was going to require some serious work on my part to achieve — probably several days worth, as Javascript is not my bag.  As it turns out, Lightbox Gone Wild (a variant of the Lightbox project which I’ve previously used to business-enhancing effect) took this from several days of work to about five minutes of integration. 

Lightbox Gone Wild is made by Wufoo, a company which doesn’t specialize in wild-and-crazy Javascript, but rather in selling a service which makes data collection easy for people.  Note that key word selling – OSS developers are typically not poor aesthetics who need to beg for their next cup of coffee.  Since wild-and-crazy Javascript doesn’t make Wufoo money directly, they release it back into the ecosystem for someone to extend (much as how they themselves extended the previous Lightbox project), with the added benefit that they may get to incorporate the extensions later and in the meantime people who have no interest in HTML forms nonetheless say good things about them.  (If you need form input and HTML scares you, go to Wufoo.  There, did my good deed for the day.)

In turn, I’m going to tweak their script a few times to add usability enhancing features (like backporting my “escape button closes the layer” tweak to the original Lightbox, which is a big win for non-technical customers), which increases the aggregate value of free OSS available but still gets me incrementally closer to making money from my paying customers. 

In fact, taking stock over what I’ve accomplished so far, I realize I’m doing a whole lot of this borrowing from OSS.  From classic infrastructure components (database, web server, application stack) to user interface elements (editing controls, charts) to a zillion pieces of behind the scenes wizardry, I’m probably literally using several thousand man months worth of software, adding two man months worth of glue and secret sauce, and then if all goes according to plan making a bit of money off of it.

Code Base By Writer

That’s the OSS Business Model

I often hear folks wondering whether they’ll make more money if they stop charging for their main application and OSS it.  Survey says no in most cases.  Rather than being engaged 100% in the production of OSS, you can OSS contributions you make which are boring, routine, and only tangentially connected to the main business of solving specific problems for your customers.  This allows you to lower development costs very modestly, but the social benefits are very nice for a bootstrapped software company. 

Giving away free stuff directly to your customers is a time-worn capitalist tradition, but giving away free stuff to other people works pretty decently too.  We live in an era where, for better or worse, GoogleBot is a judge of character and strongly prefers people who share.  (OSS users/developers have, on average, extraordinarily high levels of technical expertise and are solidly members of the linkerati.  They make good folks to influence from an SEO perspective.  You also get direct benefits from having vocal, technically capable, engaged people interested in you personally — although those direct benefits may not extend into them actually buying your software, but then again they weren’t in your niche to begin with so no harm done.)

OSS as a Barrier To Entry

But wait, there’s more.  It seems funny to say, since OSS is making it vastly easier for me to build my website, but I think that it functions as a barrier to entry for competitors.  You can’t just whistle your fingers and snap together 15 diverse and unconnected OSS projects into a usable application — the design and integration of complex systems is still a skill, and it is one that is in many ways more difficult than straight-up application development in some domains.  This turns skill with particular OSS projects, or generalized methods and patterns of integration, into one more competitive wedge you’ve got in your arsenal.

Additionally, OSS raises something of a quality cliff in front of prospective competitors who are not using as much as you.  Consider the typical graph of development effort expended versus value to the customer.  Typically, this gently slopes upwards for the first portion of the graph (“20% of the effort secures 80% of the value”), and then it plateus for a very long time as the easy wins are exhausted and the long, arduous process of software development begins. 

The curve for a developer using lots of OSS doesn’t look different in asymptotic behavior, but it contains numerous discontinuities along the way.  Every time you spend a small quantum of effort to integrate a new feature (that you didn’t have to write), your user-perceived quality gaps up.  Someone running along on your old curve, trying to keep up, runs straight into the quality cliff-face. 

Example: assume you and hypothetical competitor Bob include analytics in your application.  Both of you decide, sensibly, that the screens require a visual component.  Bob starts coding his.  You quickly integrate Google Charts, which while not strictly speaking OSS is the same general principle.  Now Bob isn’t just running the race against you — he’s running against the team at Google doing the Charts development and you’re already done and busy working on your next feature.  It makes OSS a great force multiplier.

Sidenote

Speaking of Google Charts: wonderful output, neatly solves the problem of graphing without requiring massive server-side resources or Flash-capable browsers.  Terrible, terrible API from a programming standpoint — you write uber-ugly incomprehensible URLs and their servers return the appropriate charts.  Luckily, folks have already extended it by offering wrappers in many popular programming languages (I mentioned the Ruby one already), which is another example of collaboration making a good thing better. 

I’m planning on eventually releasing a bit of magic myself, which will let you treat the charts as if they were being produced locally.  (There are decent reasons for this, from branding issues to future-proofing your site in case Google decides to cancel the charts project and you don’t want holes developing in all your old content all of a sudden.)

Bad News and Bad News and Good News

A situation that has been really stressing me out recently has resolved itself.  Sadly, it did not resolve itself to my benefit, but it is no longer hanging in the air, which means I can get on with life.  Unfortunately, as I’m looking at the remaining days on the calendar, it looks impossible to recover the time I lost these last two weeks worrying about it, so I’m likely not going to have a saleable application at the end of 30 days.  Ahh well.  I’ll throw myself into the work again from tomorrow, and continue supporting the rest of y’all, with the new goal to have something to show in public by the 1st and then do the actual release sometime after that. 

I would happily launch with a half-finished app that doesn’t even have billing integrated, but the nature of widgets is that they exist on third party sites, and half-finished could very well mean that widgets break on third party sites, which is just not good behavior.

Eight Amazingly Productive Hours

Keith and I just put in a full day’s work on the program.  It is shaping up nicely — well, the design at any rate.  I spent most of the day fighting old, outdated versions of Capistrano and Deprec to let me get Rails to a deployable state from my Vista workstation to my shiny new 512 MB Slicehost slice.  I expect that I’m going to really, really need the extra memory to have enough MemCaching and Mongrels available to serve all the requests, since many of them will be originating off-site and the entire point of the system is to help people go viral.  (Hopefully not TOO viral…)

I also found some wonderful OSS to integrate in with my planned features today.  More news on that later, as I think some of them will not hit the shipping window, and I only want to show off stuff that will, for the moment.

My rough sketch of the implementation agenda:

  1. Skeletal widget implementation (i.e. what I have for BCC, except generic)
  2. Widget rototype including the Lightbox implementation
  3. Widget creation workflow
  4. Widget maintenance page
  5. Account creation
  6. Account/user management
  7. Billing (ugh — not even decided on a payment processor)
  8. Admin backend
  9. Stats tracking, graphs, and all that jazz
  10. Emails
  11. Periodic tasks
  12. Home-rolled Analytics

Day 13: Early Proof of Concept

Finally I got a chance to do some programming!  I have worked the kinks out of my incredibly edibly basic early proof of concept of the widget functionality and have incorporated it into the live Bingo Card Creator site. 

You can see the distribution of the proof-of-concept widget at my most popular bingo cards page and the actual widget itself displayed on my stripped-down mock-up page.  Before you click there, let me warn you: it is boring as all heck.  I would like to say that is because I wanted cross-website compatibility, but mainly it is because I am not meeting Keith (my good friend and the CSS guy who will be assisting me a bit this month) until tomorrow and, independently, I have the artistic ability of paint.  Not MSPaint, no, just paint.

I also took out the embedded viral distribution for the proof of concept because a) its late and b) I’m lazy.

Hopefully this shows off why a small businessman would want to pay for this functionality.  Imagine that spread over a few dozen teacher blogs — it propagates itself, for no marginal cost whatsoever, spreads the content I spent so much time and money creating, and gets me new visitors and eventually customers at a bare fraction of the cost of CPC advertising… all the while allowing me to deepen my relationship with my core followers by giving them free stuff that they like.  That is a win-win-win. 

Now if I can just generalize it and make it possible to do without a few hours of Rails programming, I can start printing money hats.  Small, modest money hats to start with. 

Antair Moving On And Moving Up

I had been wondering what happened to the Antair guys.  It appears they’re striking out for the big leagues, moving in to brand new digs and everything.  Why don’t you go over to wave and congratulate them on their successes?

I remember back when Andrey was still comparing his sales to mine to see if he was on a good track.  Suffice it to say that he’s since made it necessary for me to play a wee bit of catchup.

How To Use E-Junkie Without Your Customers Seeing It

Hideho folks.  I’m taking a bit of a break from progress updates on the 30 Day Sprint (not progressing as much as I wanted to but I have Saturday blocked off with a designer buddy to get some stuff together) in order to answer a common question. 

I love e-junkie, the service.  So much so that I have been called Robin’s local sales rep.  And that is probably closer to the truth than I would like it to be.  But I really, really can’t stand the name — it says absolutely nothing positive to my customers about my business.  So I go to some pains to avoid them seeing it.  Since it will help other uISVs and e-junkie, I thought I’d give a rundown.

Issue: Customer lands on e-junkie page after checkout, to receive CD key

Resolution:

1)  Go to your e-junkie product settings. 

2)  Click the box next to “Product Requires: … Redirection”.

3)  Click Next.

4)  Fill in the Redirection URL.  Point it to a page on your own web server.

5)  On the page on your web server, you will want to display the CD key and instructions for installing it, plus regurgitating all the other stuff you put in your thank you mail.  (Make it big and bold because people do not read this page unless you give them a darn obvious reason to.  Getting them to read it saves you support costs, trust me.)  You can handle the content.  If e-junkie has a CD key, for example if you uploaded a list to them or they run a script to generate one for you, they’ll put the CD key in a URL variable “key”.  So if your URL was http://www.example.com/thanks.htm, your customer will end up seeing http://www.example.com/thanks.htm?something=here&somethingelse=here&key=yourkey .  Your mission is to get that key onto the displayable page.  If you can do server side programming, for example in PHP, this is pretty trivial.  If you can’t, you can grab it with a bit of Javascript

Either way, please secure your website against ye-olde insert-arbitrary-content-by-rewriting-the-URL trick.  You’ll thank me later.

Issue: Customer’s mail server is throwing out your mail

1)  e-junkie generated mail originates from one of (as of the last time I checked) three e-junkie.com servers.  It carries your name as the sender.  Bad news bears, this means that many automated checks on that email will say “e-junkie.com is spoofing honestmicroisv.com, oh no, its spaaaaam!”  What you need to do is publish an SPF record telling the world that e-junkie.com is a legitimate source of email for you.

2)  You’ll probably want to read the docs for your individual web hosting company on how to do an SPF record.  GoDaddy‘s interface is rather sweet.

Issue: You have links to www.e-junkie.com all over your page.

1)  You aren’t using the Fat Free Cart?  OK, fix that right now.  (And watch your conversion rise!)

2)  You might be worried about folks seeing the links by looking at their address bar really closely after clicking on the links.  Personally, I doubt my customers are nearly that savvy, but maybe yours are.  What you need to do is publish a CNAME DNS record, aliasing store.bingocardcreator.com (example) to www.e-junkie.com .  Then, every time the GoDaddy docs say e-junkie.com, you just subsitute your local alias.  This will not work with https (customers don’t know what that is, either) but it will get rid of the e-junkie.com in the URL bar in most browsers that I am aware of (some might resolve the CNAME and then update — I don’t know which off the top of my head), and it will get rid of the URL on hover in every browser.

And that is your tip for the day.  Check back this weekend, I’ll be back to coding and writing up a storm.

Tech Time Got Eaten

Sadly, I did not get my prototype done today.  There were a few reasons — the most glaring is that my limited stock of willingness to debug code on a Sunday was eaten by getting an archaic VBulletin moved from its previous location to one of my VPSes, as a favor to my college buddies.  Nice update interface, very user friendly — a pity about it taking 400 clickthroughs to complete installation (I kept track). 

Still, its done and now the server is hardened so that we don’t get owned by every exploit on the Internet.  I wanted to cry when I saw its previous state — using an outdated PHP and MySql running as root, naturally, with a four letter password the same as the name of the previous site owner.  Sigh.  Suffice it to say I got a lot of use out of rand() today.

On a note at least semi-related to uISVs: I continue to be amazed by how awesome it is to have a VPS over shared hosting, provided that you have some skill in Linux administration.  If you do, totally amazing — I got to hack together that forum without disrupting either of the blogs running on the same machine and I can host them all with admirable performance for $20 a month.  Then I use a second VPS with the same company (Slicehost) to run Bingo Card Creator.  I’m probably going to get a third one to host this project and, if my expectations are correct, it may need to be a little bigger than the 256 MB $20 a month variety…  Hopefully much bigger…  First Prayer of Computer Programmers with Business Sense: Please Lord, send me scaleability issues.

Best App Name Among Sprinters

Don’t Wreck My PC.  While I personally really appreciate the ability to have keywords in program name, because it will be far and away the most common anchor text, for sheer brandability and selling the program, that name just rocks.  (Your program name is also your USP.  Sweet deal) 

I also love the logo — bright and colorful does great things in B2C.  Suggestion: skin the app so that it uses this same color pallete and general style for buttons & etc.  Oh crikey does that help conversions (by about 50% when I made my app look more Fisher Pricey).

Don't Wreck My PC

30 Day Sprint: Houston We Have a Prototype

I’ve been sadly neglecting my blogging duties (long week) but thanks to some Javascript magic inspired by Lightbox I have managed to solve one of the key challenges for the widget itself, namely, how to make them trivially viral.  The key was finding Lightbox Gone Wild, which is like the standard Lightbox used by Bingo Card Creator for displaying screenshots, except it allows arbitrary HTML content in the lightbox. 

I love it when other people do my work for me.

Anyhow, this lets me include a little unobtrusive link on every widget to tell you about it and get the widget source code, which will display the code inline on the target page, both encouraging folks with sites to not be annoyed by the widgets (since I am not siphoning off their viewers) and encouraging spread of the widgets (because you don’t have to drop what you’re doing to learn about the widget). 

As mentioned, I have a prototype — essentially, its the Javascript front-end to generic widget display and virality.  Unfortunately, at the moment, I don’t have the back end ready, which makes the front end difficult to show.  So here is one of my tasks for the weekend: I can trivially get a back end working specific to Bingo Card Creator, which will allow me to code up a Top Bingo Cards widget. and show folks all the spiffy interface goodness with perfectly servicable widget code.  My hope is to have that up in the next two days, suitable for production use by blogging teachers and bingo enthusiasts everywhere.  (Plus, score, it will start driving business value for me even without having the widget creator website up.)

Then I get back to work writing the web application that allows user friendly creation of widgets without having to do the backend in Rails yourself.  I’ll also need all the ancillary stuff — account management, billing, homebrewed analytics to supplement Google Analytics and Clicky (no point in being viral if you can’t tell how viral you are), scaleability, marketing copy, a blog and some evergreen articles to start it off, yadda yadda yadda.

I’m going to be very busy this weekend but I’m loving it.