Archives for category: UX

This is part 1 of a series about recent redesigns on LunchTable.

I’ve been taking LunchTable in a very different direction from its initial vector as a social networking site. Though it maintains its core ideals, I’ve had to progress it forward naturally; these are where I made my decisions.

Try first

This is the largest new feature: the ability to try it first. These days, so many services want you to read what makes them so great (as told by them, of course), and instantly hand over your email and name to enjoy the honor of using their system. How do you even know if that service will be of use to you? How can you imagine it through abstract explanations and marketing hyperbole?

I navigated to Pinterest the other week for the first time to try it and see what it actually does, and was presented by a wall of infinitely-scrolling images. I had to navigate to Help to get a simple English description of the site, and that didn’t truly give me a good idea of what I could do with it. I clicked an image, and out of curiosity clicked Like on it. I was directed immediately to a sign-up page–diverting my previous train of thought from what a nice picture to: do I really want to hand over my email address? I’d imagine a similar bewilderment if I was asked for my contact information before trying on clothes at a store, especially after being led to believe it wouldn’t happen.

There are plenty of free services that let you use them without registering with them. I used jsFiddle almost every day for my previous web development job; Jottit is another amazing service I recently discovered. There are myriad other sites like these. But to me, these services are reminiscent of the early internet days, when people seemed to prefer to make something cool so perhaps you’d click their flashing banner ad, instead of, for example, cajoling you into sharing your most intimate details with people you already know (and the man in the middle). Most importantly, they enable you to use a product first-hand before you hand over any money or even just your email address– something I personally hold just as valuable.

Jump right in

For a site that normally relies on the interactions of personally-tied identities, the initial implementation of a registration-free LunchTable was hard to conceive. But once I let go of the hope for a near-1:1 representation, I afforded myself some flexibility and creativity. After all, the idea was to demonstrate LT’s abilities as far as possible within the restrictions of a free-roaming experience. So these key features were put in place:

  • Anyone can join a table someone else has created, simply with a link. (This was a given; without this, there would be no interaction element).
  • Users can make posts and chat. (These demonstrate real-time functionality).
  • Users can customize their Table to their liking. (This allows some hands-on experience with similar editing abilities they’ll see later, should they sign up).

Trial .’s

The 90s called, and they want their software marketing strategies back. No one likes to have a ticking clock hanging over his or her head. Why 30 or 60 or 90 days, anyway? Will you run out of bits to send me, and you’ll need to order more? You wouldn’t kick a customer out of the store because they take more than an hour to find what they’re looking for, so why do you do it with software?

I’m of the mind that the more arbitrary limits you put on your software, the more people will either try to circumvent your protections, or will quickly shy away from your product because you’re greedy and don’t like to share. Shouldn’t people want to pay you for this amazing thing you’ve created anyway, instead of feeling they have to?

Shut up and take my money

It helps to trust that people have good taste, and if they see something they like, they will want to pay for it.

If instead you warmly welcome them into your service, let them poke around and even use you a little more than you’d hope to offer, you’ve done a good thing for them, and in one way or another for you too. And it will make more sense to them when you offer a little extra functionality for a little bit of money. Just be ready to catch them when they start reaching for their wallets.

You can give LunchTable a whirl (without signing up) on Android, and you’ll soon enjoy the same on the web.

Advertisements

Recently LunchTable received an influx of spam registrations: marked by similar-looking nonsensical usernames, “real names” that didn’t match their gender, and email addresses on adult sites. I didn’t want to use CAPTCHA to mitigate this, because I personally die a little inside at each CAPTCHA encounter, so I took another route.

With a little help from StackOverflow (can’t find the link now, will update), I found a clever solution that banks on spam scripts not executing Javascript. Less than 12 hours of being live captured and prevented two spam registrations. I start by adding a hidden input field to my registration form and filling it with default text:

<input type="hidden" id="robot" name="beep-beep-boop" value="iamspam" />

Next, I add a little Javascript to change this value to a numeric value, and subsequently increment it every second (this will come in handy later):

var botZapper = function() {
    if (document.getElementById("robot")) {
        a = document.getElementById("robot");
        if (isNaN(a.value) == true) {
            a.value = 0;
        } else {
            a.value = parseInt(a.value) + 1;
        }
    }
    setTimeout(botZapper, 1000);
}
botZapper();

Finally, on the server side, I do a simply check (in PHP):

$botTest = $_POST['beep-beep-boop'];
if ( $botTest == "iamspam" || !is_numeric($botTest) || $botTest < 10) {
    // This appears to be spam!
    header("Location: /");
    exit;
}
// ...database INSERT code untouched by bots...

This checks if any of the conditions are true, indicating a bot:

  • First, if the value hasn’t changed; meaning the user didn’t have Javascript enabled.
  • If the submitted value is other textual information we didn’t expect.
  • If JS was enabled, but the form was submitted within 10 seconds.

If these tests fail, I mercilessly redirect the bot to the home page with no “fail” message! My scorn is certainly felt.

Your time threshold will definitely vary depending on the length of your form, and you will need to accommodate users without Javascript enabled at all. However, at the time of this sentence’s writing, I’ve captured four attempted spammings from China, all who never updated the hidden input field (failing at the first test).

$ logout