Author Archives: Barnabas

CodeIgniter Starter project

Posted by on July 14, 2011 3 comments

Update: As requested, here’s a demo site.

In preparation for a new CodeIgniter project starting very soon, I prepared a new project template. While CI gives you a great library and framework, out of the “box” it is missing a few things that are necessary for 90% of web applications. Specifically, user registration and authentication, menus, templates, a CSS base, etc. Other frameworks, such as Yii or Django, address this with generators. I think there is some value in creating one’s own. A fine alternative would be to go with another CI-based project framework, especially FUEL CMS, or perhaps PyroCMS.

I am very intrigued by the Sparks initiative also; I think it’s a great idea and a good way to let developers like me pick and choose open libraries, as well as give back. So my first shot at this involves setting up Sparks, integrating a few useful ones, and making a basic site with templates, navigation, registration and login. Everything else will be project-specific, I imagine.

In any event, here’s what I included in my first version:

PyroCMS Modules

Posted by on June 16, 2011 Comments Off

At White Lion, we had use of an in-house framework built on Kohana that made starting a new site very easy. Since I’m back on my own I can’t use their framework for my own projects but I see the value of using a full-blown CMS system as a starter, not just a framework. There are a few CodeIgniter-based CMS projects with some traction, but PyroCMS and Fuel CMS both grabbed my attention. PyroCMS won out because it’s reached 1.2 and module development is very simple, and I’m a fan of Phil Sturgeon.

I have so far tried my hand at developing two modules for PyroCMS: one is a sitemap module which outputs both a human readable and search engine friendly XML sitemap of all pages and blog posts, and the second is a blog importer, mainly for moving my content on this blog from WordPress to PyroCMS. I dutifully submitted both to the add-on store, but both haven’t been accepted after a week or so of sitting around “waiting for approval”. So, temporarily, I will offer both downloads here as a trial: (these are now live on the add-on section, links have been updated)

If you’re a PyroCMS user or developer, please check them out and let me know what you think on the forum. As for future plugins, I’m thinking of doing a Lucerne search plugin, or a simple Google Checkout/Cart module, or maybe a call-me widget based on Twilio’s API.

I am a freelance web developer, and if you want to hire me to build something for your website, please get in touch.

White Lion Home Page

Posted by on June 8, 2011 Comments Off

For two months this spring I had an awesome time working at White Lion in Austin, Texas. Steve Kahle has a fine group of people working for him over there, and there were many interesting projects to complete. I certainly hope I’ll be able to work with them again. Sadly, we couldn’t stay in Austin due to health issues and so we’re back in Wisconsin right now.

One interesting project I spent a few hours on was to see if there was anything to do about the White Lion home page. It is currently an eye-catching Flash image of thumbnails of different clients and case studies. When you hover over one, the thumbnail image moves about while the others fade out. It seemed to me there was nothing about it that specifically required Flash other than the monochrome effect, and even that’s technically possible without Flash. I set about trying to implement the same effect with JavaScript, HTML, and CSS. Here is a static version of my effort.

While it looks and behaves similarly to the current home page, the difference is apparent on every page load after the first, especially if you use the back button. My version is nearly instant while the Flash version always does some reloading. Why? In the current site, the Flash element does not contain any images. Instead, when loaded it always makes another network call to http://wlion.com/home/portfolios, which returns some XML that is then parsed to build the image grid. While this means White Lion can change the home page portfolio listing easily, it also slows down the whole page. The Flash element will not start loading images until after it has itself finished loading, and has retrieved and parsed the protfolio XML.

In my version, the images are just normal IMG tags. If you turn off JavaScript, it still looks and functions similarly, except there’s no movement and the mouse over is a little strange. The advantage is that the images start loading right after the HTML is parsed. On a normal connection, this alone shaves two seconds off the overall load. I believe it would be possible to keep the current design but get the initial page load down to less than 1 second with a few more tricks, such as image spriting and using a CDN host for static assets, or even just using CloudFlare as a reverse proxy. While White Lion decided to keep the Flash element in place for now, certain .htaccess changes also sped things up too, like using GZip and enabling expiration.

The takeaway is that there may be ways to shave precious seconds from your home page load without altering the design. Building a snappy first page is a good investment.

E-Commerce CRM

Posted by on October 20, 2010 Comments Off

Shopify logo in flamesI am researching doing a CRM-related mashup with one or more hosted e-commerce platforms. I have been doing some work with a BigCommerce store lately, and except for the fact that their API is read-only (big frustration there) it is a very nice system both on the front-end and the back office. I was also interested in developing for Shopify’s API because unlike BC, they have a two-way API and a third-party app store which makes it very easy to plug in and get paid seamlessly.

However, there is a glaring difference between BigCommerce and Shopify which doesn’t leap out in the comparisons that I’ve seen elsewhere, and that is this: Shopify has no CRM. For customers, there is no concept of “Log In” to a Shopify store, no “see my previous orders” or “update my address book”, nothing. Every time you order from a Shopify hosted store, you will enter  your information all over again. If you are a band which sells only five things or a company which makes and sells only one product, that is probably OK. For repeat customers and developers like me who want to do something useful with customer data, it’s a disaster.

If I were starting a store, I would require a platform with a two-way API with basic CRM. Besides my current favorite BigCommerce, I’ve  identified Business Catalyst (formerly GoodBarry), Volusion, and 3dCart as potential integration targets because they have a SOAP or REST API and CRM data that I can access through the API. Any other suggestions are welcome, and I’ll update here. While a Shopify-style app store would be nice to build for, it’s not a deal breaker to move ahead with my project.

BigCommerce and LoganCreekSoap.com

Posted by on September 21, 2010 Comments Off

I recently set up and relaunched LoganCreekSoap.com using the BigCommerce store hosting platform. I have to say: e-commerce (and web applications in general) has come a long way in the last decade. The previous platform and setup that they were using before was simply awful for both usability and aesthetically. It really was a shame because they make beautiful handcrafted soap and their store simply didn’t reflect their high quality product.

BigCommerce offered many features that were especially convenient for them to manage as store owners, such as a nice back-end management interface, lots of reports, plug-ins to several third-party systems (like Google Base and Facebook) and a great order fulfillment process flow. As a developer, I was fascinated by the API and started working on a little project to make buying postage a little easier (using Stamps.com’s API), but I was highly disappointed that the BigCommerce API is presently read-only. This is a tiny downside in the vast upside that is BigCommerce. Customers will get many shopping features that they frankly expect, such as seeing order status and history, wish lists, instant shipping and tax estimates, and coupons.

The serious competitor to BigCommerce is Shopify right now. Shopify’s API is better and their app store is highly enticing to me as a developer (nothing like that currently exists for BigCommerce sadly). I couldn’t recommend Shopify for Logan Creek Soap, however, mainly because Shopify takes a percentage of each sale in addition to their monthly fee, while BigCommerce does not. Personally, I intend to find some more local merchants and see if they’d like to let me help them upgrade their stores to BigCommerce. If you’d like my help or advice in setting up your store, please contact me.

OpenVBX Launched

Posted by on June 15, 2010 Comments Off

I am very pleased that Twilio’s OpenVBX launched today. This is a project that I had the great pleasure of working on last year for several months with the fine folks at Twilio. When I last touched it, I thought it was 99% ready to go and felt a little frustrated that it wasn’t launched sooner.

Now that I see what they’ve been working on in the meantime I understand. A great deal of refinement and documentation has made this product so much better than what it was. They even made a very Apple-esque intro video to describe what it is and why it is a win for businesses. I am installing it now on my server and will update with my impressions soon.

While not yet advertised anywhere, OpenVBX is based on CodeIgniter, a very popular PHP framework. Even if you are more familiar with other frameworks like CakePHP, Kohana, Silverlight, etc., you should find the code easy to understand.

Commenters on this news at HN have been oddly upset over Twilio’s reasonable per-minute charge, which is not new. “Why pay 3¢ a minute when you can roll your own PBX with Asterisk and pay 0.0000000000000001¢ per minute with some VOIP provider?” they ask. Fair enough. But when you go eat a burger for lunch today, ask yourself why you didn’t raise and slaughter your own beef, grind the meat, and fry your own patties? Why pay a farmer, butcher, grocer, and restauranteur to do what you could have done yourself?

By the way, when it the last time someone has successfully used the word “restauranteur” in a sentence?

Learning About HR

Posted by on October 29, 2009 2 comments

Related to my last post about setting up an automated phone screening application, I thought I’d ask HR professionals on LinkedIn what they thought about they idea. As of now, here are some sample replies:

  • “The hiring process is already de-humanized why add more humiliation/ tortire [sic] to it”
  • “I can’t imagine interviewing my candidates via an automated voice system. It’s far too impersonal and I think many of them would find it insulting.”
  • “Quite frankly, if I were to encounter an automated pre-screening system like this, I would hit the off button before the first question is finished.”
  • “I wouldn’t feel comfortable in using a system such as you suggest. [...] A voice automated system might put off too many candidates to make it worth the investment to get to the qualified candidate a little quicker.”
  • “What kind of a person who is interested in Human Resources would use a machine to perform this work. This type of machine is ideal for checking on your packages and airline arrival time. People are not packages or planes.”
  • “Why on earth would you want to dehumanize an already stressed out sector of the population?! As an employer, I would never insult my potential employees by using a system as such.”
  • “As a recruiter I really strongly dislike this idea. I would never use it. And I think it adds another layer of torture for both candidates and recruiters.”

There are clearly some really strong feelings of revulsion about this idea. I especially enjoy comments that allude to yet another layer of torture, which seems to acknowledge that recruiting is already torturous. Also I think there’s a lot of speculation on how much people would hate it. I would like to find some job seekers who have been out of work for a while and ask them: “would you avoid working for a company that put all applicants though an automated phone screening process?” I think that if anything, an applicant will commit to 20-30 minutes of recording answers only for a job they really want, as opposed to the minimal investment in blitzing out your digital resume to 300 openings a day.

A Free Phone Screen/Interview App With Twilio

Posted by on October 21, 2009 2 comments

I have thoroughly enjoyed working with Twilio for the last 6 months or so on an open-source project that will soon be released (can’t wait!). Now that my part in that project has wrapped up, I’ve got some extra time to play around with my own projects and look for my next job. Over on the Twilio support forums, someone recently requested help, and it caught my eye:

I have to conduct a lot of phone interviews every year for my company with fairly standard questions. Would there be a way to use Twilio to manage this in an automated fashion? I don’t want to spend the time actually conducting the interviews but would rather listen to them when I have a chance. [...]
During the call, I would like to have the user enter the # sign or something when they have finished answering the question, to prompt the next question. This way, I could have my 10 standard questions recorded in Mp3, and then have the whole process managed through Twilio ideally where i enter the interviewee’s phone number and a time for the call ideally.

Someone posted a link there that lead me to this service: VoiceScreener which starts at $169/month. Yikes! Twilio, on the other hand, is 3¢/minute and $5/month/phone number. I got to thinking: this is incredibly easy to set up with Twilio’s API; why not just whip it up? So I did.

Here’s a demo where you can try a sample phone interview and here’s where you can download the code. To install and customize it, just follow these directions:

  1. Unzip the file to a directory on a web server that runs PHP 5
  2. Edit the file inc/config.php with your own Twilio authentication credentials and the email address that will receive reports.
  3. I have included my sample MP3 files in the files directory, but you should replace them with your own. The file names should be self explanatory: intro.mp3, thanks.mp3, conclusion.mp3, and question_XX.mp3, where XX is a two-digit number.

As it is written now, this works without any database at all because we can use Twilio’s REST API to query the call details and list of associated recordings. This project is more of a starter and proof of concept, although for simple interview scenarios it would work just fine. Other possible upgrades (some requiring a database) could be:

  • Account for unanswered questions in the report
  • Allow interviewers to hang up in the middle of the interview and call back later to pick up where they left off
  • Allow the interviewer to review their answer and re-record
  • Allow for question branching, where the user enters a touch-tone response for yes/no on some answers and is asked only relevant questions from then on
  • Set up multiple types of interviews
  • Show the text of the question in the interviewer’s web browser  while they are listening to it on the phone using AJAX
  • Make the interview conclusion a menu, as in: “To hear more about the company, press 1. To hear more about this position, press 2…”

If you are interested in having me work on this for you, please contact me and I’d be happy to help you out. If you have any suggestions or improvements, please send them my way too.

Trying out Typekit

Posted by on August 19, 2009 Comments Off

typekit-logoI got an invite code to Typekit today and I am trying out two fonts on this site. They are currently Share Regular (headings) and Droid Serif (paragraphs and lists). Interesting concept, this iTunes for fonts. I hope it takes off and there is robust competition. Until then, there are workarounds like Cufón and sIFR.

Adding keyboard shortcuts with jQuery

Posted by on July 23, 2009 Comments Off

I was privileged to spend a yesterday at OSCON with everyone at Twilio, and I managed to catch a few talks. I heard Sigurd Magnusson (of Silverstripe fame) give the talk “10 Usability Epiphanies for your Open-Source Web App” which focused on how to improve usability. Point 10 was “Keyboard”, and one suggestion was to allow enter and escape to proceed and cancel just like native dialog boxes. It just so happens that the web app I’m working on uses a non-native confirm dialog box with “yes” and “no” buttons, so on the plane home I changed the behavior to implement this small but crucial usability enhancement. You know, I like it. Small details like this will really improve the overall experience, and I thought I’d share the essentials of my now-enhanced jQuery dialog function here.

Read more »