I 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.

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.

I 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.

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.

Here’s how it works. The script first adds some temporary HTML to the page to build the dialog box but hides it until it’s all set up. Next, we temporarily bind to the window’s keydown event (which is needed to capture escape and enter) and fire the associated button click event for key presses that we care about, including the “y” and “n”. For the button click events, we unbind the keydown event, destroy the dialog, and run the yes or no functions if they exist. As for the structure of the HTML and the CSS, I’ve only provided a bare minimum here to make it work, but the idea is that the div with the “modal” class fills the whole screen and prevents clicks and actions. In our app it has a semi-transparent PNG to grey out the rest of the screen. The Y and N of the yes and no buttons are also underlined to give the clue that they are keyboard shortcuts. I’m not sure how to hint that “enter” and “esc” also work, but I think in this case these behaviors are like good special effects in movies: they are best when they are so natural that they are unnoticed. A good enhancement would be to allow an arbitrary number of buttons besides “yes” and “no”, such as “Save” and “Cancel” and bind to the first unique character there. Also the best functions are jQuery plugins not in the global namespace, but this has been debated elsewhere for similar plugins.

JavaScript

function jConfirm(message, yesFn, noFn)
{
	var confHtml = '<div class="modal"><div class="confirm"><div class="message">(message here)</div>' +
	'<button class="yes_btn"><u>Y</u>es</button><button class="no_btn"><u>N</u>o</button></div></div>';
	var dialog = $(confHtml).appendTo('body').hide();

	// keyboard shortcuts
	$(document).bind('keydown', function(evt) {
		switch(evt.which) {
			case 27:	// escape
			case 78:	// letter 'n'
				$('div.confirm button.no_btn').click();
				break;
			case 13:	// enter
			case 89:	// letter 'y'
				$('div.confirm button.yes_btn').click();
				break;
		}
	});

	$('div.message', dialog).html(message);
	$('button', dialog).click(function(event){
		$(document).unbind('keydown');
		dialog.fadeOut(function() { dialog.remove(); });

		if($(this).hasClass('yes_btn')) {
			if(typeof yesFn == 'function') return yesFn(event);
		} else {
			if(typeof noFn == 'function') return noFn(event);
		}
	});
	dialog.fadeIn();
}

CSS

div.modal {
	position:absolute;
	left:0;
	top:0;
	width:100%;
	height:100%;
	z-index:100;
}

div.confirm {
	background-color:#fff;
	border: 2px solid #666;
	margin:auto;
	padding: 10px;
	position:relative;
	top: 200px;
	width: 300px;
}

div.message {
	color: #000;
	padding:10px 0px;
	text-align:left;
}

I have been working on a fun new Twilio project, and part of it involves generating TwiML markup, a specialized XML syntax. I have done this before by hooking into a Kohana controller, which worked for my other project well enough. There are other Twilio response libraries that range from quite thorough to downright minimalist.

I’m attaching my current version of a Twilio response library for PHP. It’s a single file and it will do syntax checking when it’s done. This is the best of both worlds, in my opinion.

TwiML PHP Library

Today Yahoo announced that they’re enabling OpenID on 248 million accounts, which unarguably pushes this single sign-on technology into the mainstream. In my opinion, this is also a huge win for mobile web users too, and here’s why:  signing into a mobile website on your mobile is very tedious and painful, and few (if any?) mobile browsers have integrated password management yet. Furthermore, even if you have the patience to tap out your e-mail address and password, some sites won’t take it or throw SSL errors or require JavaScript. For this reason, I have not been able to sign on to mobile Facebook through my Blackjack in, let’s see, ever.

Imagine a web where most sites are now compelled to offer OpenID as an alternate sign-in method (and who will be able to afford ignoring 248 million users?). Suppose that Yahoo makes their OpenID sign-in page incredibly mobile-friendly, a likely scenario. Signing in to web sites through your mobile will become a lot easier, which will in turn make the mobile web that much easier to use and relied upon.

I believe there are three web content related technologies that will help mobile browsing adoption increase dramatically if they become ubiquitous: OpenID (or a standard like it), microformats, and mobile alt links. Let’s see what happens.

I was just reading an article by Dave McClure entitled “Yahoo just needs to fix one thing: Monetization“. He outlines three ideas for helping Yahoo skweeze squeeze more profit out of each search: finish a new advertising platform, do Cost-Per-Action (CPA) advertising, and acquire more startups.

Skweezer could really help out Yahoo on points 2 and 3. We’ve been experimenting for the past few years with how to best monetize browsing traffic: contextual ads, teeny-tiny CPM banners, even charging for pro service outright. As a mobilizing web proxy, Skweezer is uniquely situated to complete CPA transactions because while users are shopping and bidding and searching, they never actually leave skweezer.net. Verifying completed mobile CPA transactions through Skweezer would not be difficult at all, were we to somehow start showing CPA ads. Significantly, we would not require any change to the advertiser’s existing site and there would be no tracking “leakage” (blocking or failing to download a tracking beacon). The only other type of company that has this visibility would be the user’s carrier/ISP themselves, and how many advertisers are going to do separate deals with every carrier in the world?

I wonder how general web CPA solutions such as newly announced Turn.com handle this uncertainty. Interestingly (to me anyway), it seems like they have some former AltaVista alums at the helm, but I doubt they remember or ever crossed paths with me or Kevin from back in the day when we worked at Shopping.com. Small world, and I wish them well.