June 20, 2013

iOS7

It has been over a week since Apple first showed off their Jony Ive redesign of iOS7, and I've had time to think (and more importantly, use). My gut reaction was simple — after 37 years, that is the sum of Apple's design ability?

But given more thought, I realized I never tend to find Apple's designs particularly attractive. Look at iOS's purple beveled alerts or periwinkle gradient default topbar. Or look at how long OSX was rocking the brushed metal look.

Apple has a unique ability to create ugly designs, but to do so with such confidence and panache that it somehow becomes attractive. They're the Steve Buscemi of design.

In fact, the beauty in Apple's design has never been on its own merit, but rather in how it inspires. The default Apple iOS app template may be ugly, but it has bogotten beautiful apps of various flavors, ranging from Path to Mailbox to Rdio — not to mention thousands of lesser known but stunningly beautiful apps.

They've managed to find the right balance between freedom and constraint in their iOS Human Interface Guidelines, inspiring amazing derivatives while keeping the entire system unified. The apps are incredibly unique and different, yet still feel similar. Android's stance is far too lax and makes the system feel disjointed, while Metro has taken an approach that is entirely way too restrictive.

Jane McGonigal was talking about games, but it applies here as well: in golf, the object is to get the ball in the hole. Starting 300 yards away and using a stick are unnecessary constraints, however often these obstacles provoke curosity and creativity1. Design is all about limits, which counterintuitively enable creativity rather than stifle it.

One interesting change is that their design language this time is almost exclusively motion. The static visual design will only be a small part of the puzzle, and we'll soon start seeing the title of Motion Designer on business cards. Traditional tools like Photoshop or Illustrator aren't going to cut it anymore, and a lot of designers are going to be left with inadequate technical skillsets to produce mockups. However, it does give developers and designers an entirely new dimension to work with.

This is a huge step for iOS, which has remained virtually unchanged over the past 7 years. The original iOS design was effectively timeless — 7 years is an eternity in the tech world. We'll have to wait to see what apps iOS7 inspires before we can really judge if they've done it again.

So, no, I'm still not a fan. I think the psychedelic palate and the wireframey look leave a lot to be desired. But maybe that's exactly the point.

June 09, 2013

Hacking Hackathons

I've seen hackathons from pretty much every angle — I've organized them, judged them and participated in them. Given the range of perspectives, here's my thoughts on how to make the most of a hackathon.

Preperation

A lot of the heavy lifting should happen before the hackathon even starts. Almost every hackathon bars you from writing code before the event, but most encourage you to plan (and sometimes design) beforehand.

Before you walk into the event, the following should be decided and agreed upon:

  • The idea
  • The branding (name, tagline, domain purchased, etc)
  • Wireframes of every single page you plan on making
  • The technology stack (Rails? Python? Parse/Firebase?)
  • Who is responsible for each task? Use Trello beforehand to assign tasks
  • The overall strategy
  • The pitch

Some Hackathons (including AngelHack) allow you to work on your design prior to the event. Take advantage of this! If you're allowed, you should walk into the hackathon with every single page completely designed. Design takes a lot of time, especially when the developers are waiting on it.

Before showing up, set up everyone's dev environment (github, domains+hosting, etc). You should be able to start coding as soon as the hackathon begins.

Simplify your concept, and then simplify it more. No matter how basic your idea is, you're going to end up running out of time by the end.

Perfect your pitch before the event. Sometimes, you're required to pitch your idea at the start of the competition. Even if you aren't, it makes sense to have your pitch nailed down. Over the weekend, it can act like a mission statement when deciding which features need to be dropped due to time constraints. Additionally, most people will be trying to put together their pitch after 48 hours of sleep deprivation and programming — having a polished pitch ready to go will make a huge difference.

The Idea

The idea should be small enough that you can create a MVP in a weekend, but big enough to involve some sort of "business plan". You don't necessarily have to make enough features that you could charge by the end of the weekend, but you should be able to show and discuss the "bigger picture" for your product.

If your hackathon is hosted by a company looking for you to use their product, be creative. Use the product in the most creative way possible — hackathons based around a specific product have a tendency to result in boring products. Remember, the organizers want winners that show off their technologies in a central and creative way.

When in doubt, add a philanthropic spin to a basic idea. An app that lets you put text over images? Uninspired and lacking a business plan. But spin this app so that people can show off causes and solicit donations? It becomes inspring and useful.

Make something that the judges can relate to. If they've never had the problem you're fixing, you'll have a much harder time winning.

When picking an idea, remember that organizers want winners they can brag about. Create something that makes them look good and that they'll be proud to show off.

To Bring

Caffeine. Hackathons tend to start off strong with coffee in the morning, but lack caffeine when people start getting groggy. Bring a few Red Bulls or Five Hour Energies in case of emergency. (I find Five Hour Energies to be great for situations like this: they're small and don't need to be refridgerated, and they personally don't make me jittery. Use them sparingly, and only drink a few sips at a time.)

Headphones. Hackathons tend to get noisy and distracting.

Mouse/keyboard. For me, I work better with a separate mouse and keyboard. Go with what you're used to.

Chargers. Make sure your computer and phone is charged. Don't worry about running out of plugs: for $25, the Belkin surge protector is worth every penny.

Your Team

You should work with a team you've worked with before. You're short on time, and you'll do much better if you don't have to worry about figuring out how to work together.

A lot of people try to get an extra designer/programmer/etc once they're there, and most hackathons encourage this. Unless absolutely necessary, avoid this. The time it takes to get new members on the same page will definitely hurt more than it helps.

It may seem better to have as many developers as possible, but that's not true. Communication time grows exponentially as you add new people, and you'll end up either stepping on each other's toes or widening the scope of the project.

I've found the ideal team is as follows. There's more information about each role later in the article.

  • One designer
  • One frontend developer ("polisher")
  • One backend developer ("creator")
  • One coordinator

If you can find someone good at design and frontend, the first two can easily be combined.

Everyone should be familiar with the technologies being used. Now isn't the time to learn a new technology — a small issue you can't figure out could easily cost you hours.

Unless necessary, don't interrupt each other. Just do your part; everyone doesn't need to be informed or have to sign off on everything. Distractions kill productivity.

There should be one person that takes on the role of "coordinator". The coordinator should be responsible for the following:

  • Feedback for designers or developers
  • Removing absolutely all roadblocks and obstacles for the rest of the team
  • Settling disagreements
  • Coordinating and acting as the hub for all information
  • Making sure everyone is physically where they need to be
  • Making sure all the proper things are submitted on time
  • Working on the pitch, and making sure the demo being created matches the pitch
  • Set up all necessary accounts (social media accounts, services being used, etc)
  • Keeping everyone on track

Strategy

Given the lack of time, you should focus on building a cohesive "demo flow" as opposed to a "releasable product". Write code that gets you through the flow first, and then go back to polish.

Your team should be split into three parts: creators, polishers and a coordinator.

The creators have one goal: get all the functionality in place, starting at the begining of the flow and finishing at the end. This will probably be your backend developer.

Once the creators have finished a particular step, the polishers can spend time to make it look good. Using this model, the polishers won't be stepping on the creators' toes — the creators should be ahead of the polishers.

As mentioned above, the coordinator's main job is to remove obstacles for the creators and polishers. Making sure everything is running smoothly, everyone is on track, and everything is submitted on time.

Anddddd... Go!

Many people make the mistake of focusing too much on "hard" programming. The judges don't care how accurate your algorithm is, or how tricky that particular bug was. They only care about what they can see.

The importance, in order:

  1. Design
  2. The pitch
  3. Frontend code
  4. What's for lunch
  5. Backend code

I've seen people win after presenting nothing more than a design; I've never seen anyone win based on an "algorithm". Nobody will see your code, so don't spend too much time on it. You only have a few hours, so it's not like you can do anything too impressive anyway.

Use Parse/Firebase/FilePicker/etc as much as possible; this goes double if they're sponsors. Outsource the time-intensive boilerplate stuff (authentication, modeling a DB, etc) to existing products so you can focus on the important stuff.

Don't argue as a team. The judges will only see your project for a few minutes — they don't care about usability, specific copy or colors, etc. Pretty much all that matters is a general sense of "polish". If an argument lasts more than 2 minutes, do a vote. If it's a tie, either defer to the coordinator or flip a coin.

If you get stuck on a programming problem for more than 20 minutes, fake it and move on. Hard code things, make dummy buttons appear to work, etc.

I've never attended a hackathon that I didn't sneak away from. Working from home is great: you're used to the setup, it's more comfortable, there are way fewer distrations, etc. Just be careful of two things: it's easy to get too comfortable, and oftentimes hackathons make important verbal announcements.

The Pitch

Before you walk in to the hackathon, you should have the pitch nailed down. Pitch to a few people before, and get their feedback.

Know the format. Sometimes you're on a stage, other times you're sitting next to the judges. Different formats require entirely different styles.

You need to answer the following question: how do you save people time, money or stress? Even though you only had 24-48 hours, the judges will probably want to know your business plan or how you'll compete with bigger companies in your field. These are stupid questions since you've only been working for a weekend, but you'll need a good answer.

Pitches work best if one person presents, and another person "drives" the computer. It may seem "fair" to let everyone talk, however it tends to come across as unsteady and uneven. You only have a few minutes, which doesn't leave much time for switching speakers — it ruins the flow of the pitch. Various teammates will have time to talk during the question/answer portion.

"Nobody care about the plumbing." Unless a judge specifically asks, don't spend more than a few seconds (if at all) talking about the technology. You only had a few hours, so it's unlikely you did anything technologically impressive.

If you can manage to get testimonials, business development deals or sales, do it! Judges always love that. Remember that most things are closed on weekends, so you may want to do this prior to the hackathon.

Get the judges involved. Make it as much of a conversation as possible. Get them excited. Show how it helps them. Never argue with a judge — a two minute pitch isn't the time for proving a judge wrong. By agreeing and excitedly building on their ideas, you're getting them invested in your idea. I once saw a team win not because of the product itself, but because the judges got so excited about their own ideas.

Reasons for Going

This article assumes you're looking to win, but there are a number of totally valid reasons to do a hackathon:

  • See if you work well with a potential co-founder
  • Finally break ground on a project you've been wanting to do
  • Learn a new technology
  • Something fun to do on a weekend
  • Free coffee

If this is the case, feel free to ignore the previous advice! Just make sure everyone is on the same page.

You probably won't win

No matter how much you prepare or how good your product/pitch is, odds are against you. Judging is completely subjective: a different set of judges or even just a different weekend means a whole different set of winners.

So do your best to win, but make sure you have fun.

Thanks to Ian Mikutel, my cohort in both running and participating, for help with this article.

January 29, 2013

AngularJS

After reading the recent article Step by step from jQuery to Backbone, I was a bit put off about how the 16 lines of readable jQuery was transformed into 43 lines of mostly incomprehensible Backbone. Something struck me about it: it often seemed to be abstraction for the sake of abstraction, with few benefits. I had recently begun playing with AngularJS, and wanted to do a similar tutorial. I'll start with the same jQuery, and transform it into Angular code.

In a way, this is comparing apples to oranges. The authors of the Backbone version took the refactoring to the extremes. I'm more interested in creating a simplified version, to show how quickly you can use Angular to make a relatively advanced app.

Note: The Angular code in this tutorial is heavily taken from the tutorials on AngularJS.org, which is completely worth checking out.

Original jQuery

We've started with the same exact code as the original article, with a few slight modifications:

  1. The HTML is important in Angular, so we're using JSFiddle to show both HTML and JS (as well as a demo).
  2. In order to make the code run-able, we had to make some small modifications to work with JSFiddle's AJAX API.

Let's make things more interesting

As it turns out, this original example is too trivial to really show off the power of Angular. We want to show off some cool Angular features, so let's turn this into a todo list. (And, for those of you who have followed the tutorials on AngularJS.org, you know my secret motive: their main example is a todo list.)

Let's add a checkbox before each item, as well as a counter of remaining tasks at the top. We also want to append "Done!" to the end of each completed task. While admittedly not the most optimized jQuery example, you can still note how much DOM manipulation is required for these relatively simple tasks.

Setting up an Angular Controller and a repeater

From here on out, make sure you look at the HTML. While jQuery or Backbone don't really need HTML to illustrate their core concepts, Angular moves most of the logic into the HTML.

We start by adding ng-app to the parent-most div, to indicate the active portion of the app. Most apps would put this on the <html> tag, however we'll put it on a wrapper div for the sake of JSFiddle.

Next, we define the controller by adding ng-controller="TodoCtrl" to the section of the page we want to work with. The naming is unimportant, however it conventionally ends with "Controller" or "Ctrl". It just has to match up with the name of a function in our JS.

In the JavaScript, we define TodoCtrl. Note how we pass in $scope as the first paramater. We also define $scope.todos, which could be seeded with data if we wanted to. (I tend to have an AJAX call here to get existing data out of the database.)

We've given the checkbox a ng-model, which we'll talk about in a bit.

Next, we're going to add a repeater into the HTML. Any changes we make to $scope.todos will be reflected in the HTML.

A repeater is basically just a foreach loop, embedded right into the HTML. We create one <li ng-repeat='todo in todos'>, which will be used as the template for everything in $scope.todos.

We can then reference todo inside the looping element: for example, we do {{todo.text}} to print out the text.

Think of these as templates: except rather than writing HTML inside the JS files, we write them right in the HTML &mdas; arguably where it should be.

Note: Unfortunately, this demo doesn't work since we're only halfway there.

Implementing the Form

At this point, we'll completely remove the form submission from the jQuery version, and replace it with our own.

We put a ng-submit="addTodo()" into the HTML, and define it in the JavaScript as $scope.addTodo()

We can add a new <li> simply by pushing it to the $scope.todos array.

Note how we don't have to do $('#new-status').val() to get/set the value of that text box. We've bound it to $scope.todoText by giving it a ng-model="todoText". If you update either the variable or the input field, the changes will be synced.

Note how before, we gave each checkbox in the repeater a ng-model. This tells angular that the value of the checkbox should mirror todo.done. If we were to update todo.done in the JavaScript, the checkbox would become checked. If we toggle the checkbox, the value of todo.done stays in sync in the JavaScript.

Update remaining Todos

We're already come pretty far, with minimal JavaScript. To add a count of the remaining todos, we just put {{ remaining() }} right into the HTML. Angular will update it whenever a new todo is added.

The remaining() implementation is relatively straightforward.

Show "Done!" on checked items

Almost the same as above, but inside the repeater.

Talking to the server

Okay, you caught me: I left out the AJAX part. We could have used Angular's $http to quickly do AJAX requests, however it's really just a watered down version of jQuery's $ajax. So, instead, check out the official tutorial: Wire up a Backend. It uses MongoLab to keep the page in sync with the server.

Other awesome stuff

Let's look at some other cool things we can do with only a few lines of code.

First, we're going to order the todos alphabetically by adding | orderBy:'text' to the repeatable. With a minor HTML change and no changes to our JavaScript, we can order our list however we please — in this case, alphabetically by 'text'.

Next, we're going to make the list filterable by "all", "done" and "not done". We simply define $scope.filterCriteria={} in the JS, add | filter:filterCriteria to the repeatable, and add links with the approperiate variant of ng-click="filterCriteria.done=true" as an attribute. With just a few lines of code, we have a filter that works like a charm.

In conclusion…

When learning Backbone (and again when reading the article in question), I couldn't shake the feeling that Backbone was often abstraction for the sake of abstraction. It never really made my code easier to write or read; it simply gave me a skeleton for how things could be abstracted.

I also couldn't shake the feeling that the jQuery could presented would be better reimplemented in Angular.

The point of this article isn't to give a fair, one-to-one comparison of syntax or line count between Backbone and Angular. Rather, the point is to show off how different the approaches of the two frameworks are. Angular's two way data binding is nothing short of magical. Note that not once did we manually touch the DOM. In fact, if you're touching the DOM at any point, you're probably doing something wrong. Rather, you update the "models" (in this example, just an array of JSON) and everything is kept in sync.

Naturally, this is a pretty basic implementation: I wanted to show off what Angular can do, not necessarily to show off best practices. Things get a little more complicated when you, say, start building a real app that syncs data to a server.

Hopefully this quick introduction to Angular piqued your interest. Check out AngularJS.org for much more complete tutorials.

April 24, 2012

BugzillaJS Updates

BugzillaJS 3.0 is out! It comes with a bunch of new features aimed at helping Bugzilla power users get around Bugzilla as quick as possible.

Keyboard Navigation

Keyboard shortcuts save you time by allowing you to navigate Bugzilla without having to take your hands off the keyboard to use the moouse. Anyone who uses the keyboard shortcuts in GMail or GitHub knows how nice this is.

To enable keyboard shortcuts and view the various commands, just hit the "?" key on any Bugzilla page. When in a list of bugs, you'll now see an arrow to the left of the bug number. You can move it up and down using j and k, and go to the selected row by hitting <enter>. Once in a bug, skip to the next or previous bug with J or K, respectively.

There are a bunch of shortcuts, so make sure you hit ? to see what's possible. If you have an idea for a new shortcut, let me know.

File It

A few weeks ago, my coworker Heather Arthur created a simple shortcut called File It. It makes filing a bug in the proper product and component much simplier. I shamelessly ported it over to BugzillaJS. When you go to the "New Bug" page, there's now a box at the top of the page that you can start typing into. Or you can simply hit n on any Bugzilla page, and a File It box will pop up (requires Keyboard Shortcuts; hit "?" to enable them).

New Feature Notification

In order for people to take advantage of the new features, I added a notification when important new features were added to BugzillaJS. A little bubble with a number in it shows up when there are new features. If you open up the preferences, new features will be marked. You can dismiss the notification by saving the preferences.

Redone Preferences

Preferences have been organized by category, rather than the jumbled mess they were before. It should make it easier to find what feature you're looking for.

Works on any Bugzilla

This feature actually came out in the previous version, however I didn't mention it here. BugzillaJS now works for any Bugzilla installation — not just Mozilla's. You can add additional Bugzilla URLs in the add-on settings. To get to it, go to Ctrl+Shift+A > Extensions > BugzillaJS > Preferences.

March 07, 2012

Firefoxes

Quite often, I find myself wanting to run multiple versions of Firefox: to test out a new feature in Nightly, make sure my add-ons work in Aurora or maybe track down a bug in an earlier version. Using the Profile Manager, it's possible to have numerous versions of Firefox running side by side.

I started writing a tutorial, but it quickly got too complicated. So, I decided to write a script that would download, install and set up profiles for any version of Firefox. About halfway through, I stumbled upon a script called "install-all-firefox" by Max Glenister. It did a lot of what I wanted, so I forked it and worked from there.

OSX Dock

How To Use It

Note: Currently this is OSX only curl -L -O https://github.com/omgmog/install-all-firefox/raw/master/firefoxes.sh chmod +x firefoxes.sh ./firefoxes.sh [version] [locale] [no_prompt]

Version and locale are option. If you don't use a locale, it will try to figure out your locale. If you don't have a version, it will install all available versions of Firefox.

If you want to see what's available (and what you have installed):

./firefoxes.sh

What It Does

  1. Figures out your locale (or allows you to specify it).
  2. Finds the file on the FTP server, and then downloads and installs it.
  3. Sets up a new profile and modifies the launcher to open the Firefox version with that profile.
  4. For versions using the same icon (Firefox 4 and Firefox Beta use the same icon, for example), it adds the version to the icon and name.
  5. Changes the settings so future versions (Nightly, Aurora, etc) check for updates regularly while numbered versions (4.0, 5.0, etc) stay where they are.
February 18, 2012

Cognitive Burden

When you create a website or other product, you eat, sleep and breathe it. You become an expert who understands the subtle nuances of your creation. It's like being able to tell a Merlot from a Cabernet by taste.

Users don't. They just see two red wines.

It's tempting to try to solve this dissonance with education. After all, everything is obvious to you — so it isn't too much to ask your user to have this same knowledge. However, this causes a dangerous shift of the cognitive burden to the user.

Rather, why bother making the distinction in the first place? Unless it's vital, you are just unnecessarily giving people one more thing to think about, no matter how simple the explanation is.

Imagine someone knows nothing about wine. You ask if they would prefer a Merlot or a Cabernet, and they respond with a confused look. Both are types of red wine, you tell them.

Just call them both red and be done with it. Wine is an art, and people care about the difference because they enjoy it. Your product doesn't have that luxury.

It's not that users are stupid or lazy. They just have more important things to care about. You aren't competing only with similar products — you're competing with last night's episode of The Bachelor and that cute girl at the coffee shop and elections and taxes and jobs and families and emails.

This is why simplicity wins.

There is so much noise that people have become fatigued.

So don't ask the user if they want a PlusPro Upgrade™; simply ask if they want more space. Don't make them figure out they need to log in with a username rather than an email address; let them do either. Don't make them read instructions; simplify the process.

Even if it's subconscious, everyone appreciates when the cognitive burden isn't on them. Users shouldn't have to understand the product like you do in order to use it. People are so overwhelmed already that anything that seems even slightly confusing is perceived as a straw waiting to break the camels back.

When making something, stop and think — what's literally the worst that will happen if I simplify things even more?

November 19, 2011

Piracy

There’s a subtle but important difference between “how can you stop piracy?” and “how can you make it so people can’t pirate?”. The former is the question we should be answering; the latter is the question bills like SOPA and PROTECT IP [1] try to answer.

There are always going to be people who pirate content, for any variety of creative pseudo-philosophical reasons and justifications that mostly just boil down to being cheap. Forget these people. Much like if a CD is stolen off a shelf, this falls under shrinkage. It sucks and is unfair, but censorship sucks more.

Instead, focus on the people who don’t care where things come from. They just want to watch a movie or listen to music and don’t want to think.

Most people download illegally for a simple reason — it’s the easiest way to consume content. This new legislation will hurt these people, while doing nothing to stop the true pirates. Forget the pirates, focus on real people.

The average consumer isn’t trying to make a political statement. She just want to watch last night’s Glee. Let her watch it on her TV or laptop or iPad or iPhone. Don’t make her wait a week after it airs — by then, all her friends will be talking about the following episode already. Don’t make her hunt for it or have to install plugins or deal with with low quality. Let her listen to music from the episode on her computer or iPod or car stereo. Let her burn her boyfriend a mixtape of songs that reminds her of him. Let her show off her carefully curated playlists to her friends. Don’t take away her movies or music in a few weeks due to contract disputes.

Yes, there are legal ways to find content online. Personally, I have never pirated anything I could find on Hulu, Netflix or Rdio — all of which I happily pay for. However, the content owners put more effort into restricting the content than they do into letting people consume it. Netflix streaming is largely just bargin bin movies. Hulu makes you wait a week for most shows, and you still have to watch ads even if you pay. Rdio only works on certain devices, and doesn’t give people a sense of ownership or permanence.

Technology will win in the end. Legally or not, people will consume what they want, when the want, how they want. With an unlimited supply of free options that allow for this, it’s unreasonable for content providers to expect anyone will want to pay for the pleasure of abiding by their restrictions and whims. Short of declaring computers illegal, piracy can’t be stopped by force. The solution isn’t to use the government as muscle; it’s to give consumers what they want so they have no reason to pirate. Content providers should be looking to the tech industry for help, not declaring war on it.

I know it isn’t this easy. After all, industries are largely made up of middlemen looking for a cut. The Internet would make most of them redundant. However, we shouldn’t be censoring the Internet, holding back innovation and hurting consumers just so Comcast and the like can stay in business.

Nobody will pay for the actual content anymore — they can already get that for free from any number of illegal sites. What they will pay for, however, is the experience. Money is the easiest thing to get people to give up. Save them time and effort, and they won’t be able to keep their credit cards in their wallets. Don’t make them think. Don’t make them understand different services and devices. Give them something that they don’t have to hunt for or unzip or install or sync. Give them something simple. Something that just works.

Just let them press play. That’s how you stop piracy.

  1. Mozilla’s overview of Internet blacklist legislation []
November 08, 2011

Usable Context Menus

Today, Mozilla released a version of Firefox that includes the ability for a website to add options to the context menu (bug 617528). It has awesome potential, however I had trouble getting it to do what I wanted.

I found a demo by Paul Rouget, however it assumes that there’s only one image on the page. The way context menu has been implemented means there’s no good way to figure out what element has been right clicked. The this binded to the callback is for the menuitem, not the element that was right clicked. This works fine if you don’t plan on making more than one element right-clickable. Imagine you have a list of, say, emails. You want the user to be able to right click and delete/archive/star each email separately. With the current implementation, each email would need it’s own <menu> — and that’s a lot of excess code.

So, I threw together a quick jQuery plugin prototype [demogithub]. It lets you add menu items using a familiar syntax, and most importantly binds the this in the callback to the element that was right clicked (as opposed to the menuitem that is selected).

It’s very buggy and missing important features (such as sub menus, separators, control over ordering and control over events and bubbling). Consider it version 0.1, if you will. However, it makes it very easy to add menu items.

One thing I didn’t want to do is make a polyfill. This will only work in Firefox 8. I didn’t want to override the menu bar in browsers that don’t support it. If you’re looking for that, a polyfill already exists.

Check it out »

August 30, 2011

One Year

I started at Mozilla a year ago today. It’s hard to believe it’s been twelve months already. Indulge me, if you will, as I take a quick self-centered trip down memory lane.

New Technologies

When I was hired, I was a PHP developer on Windows. Pretty much every language and tool we use here was brand new to me. I even wrote a Firefox extension!

  • Python from PHP
  • Django from CodeIgniter
  • OSX from Windows
  • Git from SVN
  • Github from private repos
  • Vim from Netbeans
  • LESS from plain CSS
  • Command-line from GUIs upon GUIs
  • Nose (Unit Testing) from, uh, not writing tests

In hindsight, I cannot believe I worked with most of these technologies for so long. PHP? Windows? SVN? I’ll never go back.

By The Numbers

After all, nothing says mushy quite like a quantitative look at the past 365 days.

  • 295 bugs closed in AMO
  • 447 git commits
  • 30,298 lines of code added
  • 10,443 lines of code deleted
  • 16 git repositories contributed to

It’s been a great year. I’ve had the opportunity to work with brilliant people on awesome projects. I can’t imagine a place I’d rather be.

That’s enough reminiscing for now, though. There’s code to be written. Time to get started on year two.

August 23, 2011

BugzillaJS

This morning, BMO (Mozilla’s installation of Bugzilla) finally added inline history — a feature that was sorely needed for the past few years. A few Firefox extensions (such as Bugzilla Tweaks and my add-on, BugzillaJS) popped up to fill this void, however it’s great that BMO is finally getting it natively.

This is a huge step forward for Bugzilla, however it doesn’t mean Bugzilla-related Firefox extensions are obsolete. Most Mozillians spend a good part of their day in Bugzilla, and BugzillaJS adds a number of helpful features that make it a much more plesant experience. Here’s a list of features BugzillaJS has that Bugzilla still doesn’t. (Note: All features are optional, and can be turned off from the preferences.)

  • Image attachments or links to images are shown inline as thumbnails.
  • View images as a lightbox.
  • Turn timestamps into relative dates (“Three hours ago”).
  • Styled comments that make the text easier to read.
  • Github commits are shown inline if linked to in the comment.
  • Gravatars next to comments.
  • Add a scroll bar if the text in the comment is too wide.
  • Remove flags, status and blocking options (off by default).
  • Remove access keys (off by default).
  • Automatically select component and product for “Clone Bug” link.
  • Add “new” link to depends and blocks fields
  • Don’t guess OS or Hardware (off by default).
  • Hide the first comment if there’s nothing in it.
  • Option to hide “nobody@” bugs from bug lists.
  • Remove “Bug” from the title, so it’s easier to see the bug number with a lot of tabs.

Download BugzillaJS Now!

BugzillaJS is open source, so I’d love to have you contribute. Currently it only works on BMO (bugzilla.mozilla.org), however I have plans to support any version of Bugzilla as soon as the Jetpack SDK will support it.

July 30, 2011

Anchoring

How much would you pay for unlimited, instant access to every movie ever created?

When you look at it that way, it seems absurd that people would be outraged a company would have the audacity to charge $15 a month. Yet when Netflix announced they were bumping up the prices, that’s exactly what happened. (Okay, I know DVD rentals aren’t instant and right now streaming doesn’t have the greatest selection — but within a few years, we’ll be streaming everything.)

I’ve heard a lot of talk about why Netflix raised their prices. Maybe the studios are greedy, or perhaps Netflix cares more about stockholders than customers. No matter the reason, we can probably assume it’s financially motivated. The reaction from customers, however, is not — which makes it a great deal more interesting.

A few decades ago, the naturalist Konrad Lorenz discovered that goslings, upon breaking out of their eggs, become attached to the first moving object they encounter (which is generally their mother). Lorenz knew this because in one experiment he became the first thing they saw, and they followed him loyally from then on through adolescence.
Dan Ariely, Predictably Irrational, Chapter 2

When it comes to prices, we are no different from goslings. We become imprinted with the first price we see. With Netflix, most customers first saw the $10 price tag (despite the fact that it originally started closer to $20, and there was no streaming).

Nobody sat down and thought about it logically. Buying a single DVD? About $15. Going to a 3D movie by yourself? About $15. At $16, unlimited rentals and streaming should be considered a great deal. However, Netflix is supposed to be $10. That’s the price we latched onto, that’s what we think it’s worth and that’s all we’re willing to pay.

It gets even more interesting. Let’s say I found someone who had never heard of Netflix and had no clue how much it should cost. I could have them write down the last two digits of their social security number as a dollar amount, and then ask them if they would be willing to pay that amount for a monthly Netflix subscription. Some would say yes, some would say no. Then, I could ask them to write down the maximum they would pay for Netflix. Despite the anchor being completely arbitrary, people who started with a higher number would be more likely to pay a higher monthly price for Netflix. That’s how deeply affected we are by price anchoring and imprinting.

This, then, is what we call arbitrary coherence. Initial prices are largely "arbitrary" and can be influenced by responses to random questions; but once those prices are established in our minds, they shape not only what we are willing to pay for an item, but also how much we are willing to pay for related products (this makes them coherent).
Dan Ariely, Predictably Irrational, Chapter 2

Netflix isn’t just a victim of a psychology, however. They screwed up their announcement. Acting like they were doing the user a favor, and calling it their lowest prices ever despite basic math proving the contrary? Probably not the best game plan. They should have announced something big at the same time, such as we just signed Sony! or you can now use Netflix streaming on Android! By offering a significant upgrade to the product, the established anchors would have been a bit more flexible. Instead, people saw it as a price increase with no new benefits.

If you haven’t yet, definitely check out Predictibly Irrational. It’s a facinating look at behavioral economics.

July 25, 2011

Blogging

Let’s try this whole blogging thing again, shall we? It’s been over a year since my last post. In that time, I moved 3,000 miles and started work at Mozilla. There’s not much to say while living in Schaghticoke, NY. Silicon Valley has proven to be a much more provoking muse.

So, it’s about time I pick up my pen again. This post is mainly to highlight the fact that any older post is over a year old and shall be taken with a grain of salt.

(If you're looking to follow along via RSS, there’s a feed available.)

June 11, 2010

Change

In just a few short months, I will be moving to California to start work at Mozilla.

There are a ton of changes I need to make. I need to find a new apartment, a new route to work, and more. One weird thing I have noticed, however, is how predisposed I now am to making smaller changes.

For example, I get toiletries from the local store. I will be living right next to a Target, which will sell the same stuff the same price. However, I decided to switch to Alice when I move there. I am not doing it out of necessity— I am doing it merely because I am already making one big change in my life. There are a number of other things I plan on changing when I move— simply because I am in "change mode."

So, what is the takeaway? Try marketing to people who are already making big changes. Buy ads with apartment realtors or moving companies. If someone is in change mode (move, big purchase, etc), they are more likely to change the little things, too.

June 08, 2010

Five Minute Rule

When asking for advice, implement a five minute rule. Don't let anyone advise you until they've thought about it for at least five minutes.

It is amazing that people take five minutes to decide what they want from the McDonald's Dollar Menu, yet they are ready to jump in with their take on life or business decisions before you are even done talking.

It doesn't have to be five minutes— thirty seconds, an hour, or a day all work. The important part is that you are asking the person to think first.

Remember this rule when you are giving advice, too. Take time to think, and you will instantly become much more helpful.

June 07, 2010

The Necessity of Fat Startups

Recently, there has been an ongoing debate on which is better— the lean or fat startup. A lot has been said for both sides. Honestly, it comes down to what is best for the given situation.

One thing we have to look out for that hasn't yet been mentioned: massive offline companies. They have a ton of money. To put the $100k or $1 million investments we see announced on TechCrunch all the time into perspective: Goldman Sachs CEO Lloyd Blankfein got a $53.4 million bonus in 2006. Imagine what a tech start-up could do with $53.4 million— and that was just one bonus. Once these big companies— especially the old media companies— figure this Internet thing out, lean start-ups are out of luck.

Don't believe me? Take a look at the story behind Hulu. Imagine a lean start-up doing what Hulu managed to do. You'd end up with, well, Joost or Yidio. Pretty soon, every company will realize they need their own Jason Kilar. Imagine if some brilliant, budding entrepreneur had the half a billion dollars News Corp spent on mySpace to create their own social network. Had Rupert Murdoch found a man with a vision to fund, rather than pouring all that cash into the massive dying social network? Facebook would have some serious competition.

Quite frankly, the problem with lean start-ups comes down to quality. Can it be done? Yes, it can. But imagine how much faster and better a start-up could be created if they had a few bucks in their bank account. Money doesn't buy brilliance, but in the right hands it can make it possible.

Have an idea for a start-up? No need to be a starving entrepreneur anymore. Now might be a good time to skip the VC route and head straight to the old media offices. They certainly have the money, and they are starting to believe this Internet thing just might take off.

June 04, 2010

Make Promises

I am bad at answering emails. After all, it is so easy to procrastinate. "In a few hours" becomes "I'll get to it tonight," which turns into "tomorrow morning."

I really liked this line on a contact form I saw on the website of a freelance developer:

I'll get back to you within 24 hours.

That simple sentence guarantees two things:

  1. The developer won't procrastinate when answering emails, since a few hours will make a difference.
  2. People are more comfortable emailing him, since he has made email slightly less asynchronous.

By making a public promise with absolute numbers, you are forcing yourself to adhere to it. Using a relative time frame such as "as soon as possible" affords endless procrastination— "24 hours" does not. This technique is not limited to just email, either. You can use it for workouts ("three miles a day" rather than "exercising often"), blog posts ("new blog post every day" rather than "regular posts"), or making plans ("by the end of the week" rather than "soon")- basically, anything that involves some sort of self control.

Does it work? I'm not sure, I would have to ask him. I'll know by this time tomorrow.

June 02, 2010

Job Descriptions

Job descriptions tell employees what they can't do. Take the average job description for a programmer: it relegates them to their IDE, saying they can't do marketing, biz dev, sales, writing or project management.

What this does is put employees in silos— just like a programmer wouldn't take coding advice from a sales guy, marketers won't listen to a techie.

So, how about using this as a job description?

Wanted: People who can help us create a kick-ass startup.

Yes, you need people who can program. And you need people who can balance the books, talk to investors or design the site. So, throw in something like "____ experience encouraged" at the end.

It reminds me of how they cast the show Lost:

A lot of the casting came out of, like, finding actors they wanted to work with, rather than necessarily fill in a roll.
Jorge Garcia, Hurley on Lost (via Hulu)

The producers didn't have jobs for much of the cast— many of the characters were created simply because they liked the actor.

What is my point? When starting a company, don't tie people down to certain tasks. Ideas and talent will be wasted, and they will eventually get bored. Let people decide for themselves how they can best use their talents to help the company. Sure, some things have to be done to keep the lights on. Code needs to be written and meetings need to be attended. However, if you give people the freedom to manage themselves and decide what needs to be done, you might be surprised. A good enough team will rise to the occasion, and do more than just keep the lights on.

May 31, 2010

The Lowest Common Denominator

Over and over again, I see the same misconception: "Lowest Common Denominator" means "dumb." That is how people criticize stupid comedies on TV or lolcats on Digg- they said they are catering to the lowest common denominator.

Most of us learned in middle school how to figure out the lowest (or least) common denominator. It is the smallest positive integer that the given set of numbers all evenly fit into. That is exactly what finding the lowest common denominator for a piece of content does— it tries to find the smallest integer (or, most interesting content) that the set of numbers (or, the people consuming the content) can fit into (or, enjoy together).

So, to use an example: let's say we have a biologist and a chemist. Their "Lowest Common Denominator" might be science— the highest level topic that they both agree is interesting. Throw in an economist, and the LCD might become math. Throw in an artist, a construction worker, a computer geek, a WalMart greeter, a stay at home mom and a professional athlete, and you find that Two and a Half Men and funny cat pictures are all they really have in common.

Lowest Common Denominator doesn't mean stupid— it merely means "this is the highest level that everyone involved can agree on."

This brings us to Digg. Digg started out as a place for tech news, and it attracted a geeky following. It caught on, and soon found itself getting popular. As more people joined, the diversity of topics expanded— political and scientific stories started to seep in more. Digg had two choices— either stay dedicated to tech news, or do whatever it could to increase its popularity.

Eventually, the interesting domain specific stories couldn't make it to the front page anymore because not enough people on the site were interested. Instead, funny pictures became the lingua franca on Digg.

So, how do we fix this? Digg v4 aims to rectify this problem by making it so you follow people rather than everything. This means the death of the Digg Effect— no longer will we all see the same thing, but rather, we will just see what our friends post. This does not fix the problem, however. Let's say you are a chemist— unless all your friends on Digg are chemists, and all their friends are chemists, chemistry articles will still have to be diluted (either in terms of quantity or level of depth). It doesn't even have to be based on profession&mdash I'm from RIT and want to hear RIT news, yet that will never find its way onto my Digg front page. On top of that, this leaves you with a very closed source of information. You will only get news from people who you follow— people who think the same way you do, and have the same beliefs.

In order to fix Digg (or any other large site), it is important to understand and embrace the Lowest Common Denominator. If you could follow and post to topics, rather than people, the problem would be reduced. Digg, Reddit stole your concept six years ago. They are onto something with their subreddits, and they owe you one. Take the subreddit concept, and improve on it— for example, maybe add advanced filtering controls?

I want to be able to say: "Digg, my front page should show me all posts about RIT or programming. Also, show me anything from the World News topic that has more than 600 Diggs, and any funny pictures my friends have dugg." That is what would make Digg useful for me— not just the Facebook/Twitter/Google Reader clone they are about to launch.

May 17, 2010

An Arms Length

A few summers ago, I found myself selling 50-50 tickets at a Little League game. The average was about $100 per game — not a bad haul, but I thought I could do better.

I told everyone there was a special that night- two for the price of one. A dollar would get you two tickets instead of one, and you could get two arm lengths for ten dollars.

Everyone received twice the amount of tickets, so there was absolutely no change in odds. Everyone knew the deal was offered to anyone buying tickets, so nobody was tricked into thinking they had a special advantage. People buying tickets had absolutely no advantage over any other night. However, it worked— we sold over $350 in tickets that night.

In the physical world, it is rare we have a chance to double what we are offering without suffering some sort of loss in profits. Best Buy cannot sell you two TVs for the price of one, and McDonalds loses money if they give you two burgers when you only paid for one.

People react positively to getting twice what they paid for. Companies lose money on buy-one-get-one-free offers, knowing that it will get enough people through the door to make up the difference.

However, this only works to a certain extent with physical items. Online, it is easy and cheap. Take a look at how the "freemium" model works— customers get a certain amount of something for free, and have to pay for more. Often, a pro account costs a company just as much to run as a free account. A scarcity of supply is created for the sake of making money.

What if you doubled your offer? If your "premium" level includes 15 users, make it 30. If customers only get five gigabytes of space, make it ten. And make a big deal about it— don't just quietly change it on the site. Make it obvious to potential customers that you're offering a promotion— even if it is a permanent change.

Take Gmail, for example. The service is constantly adding space, even though most people won't come close to the original 2GB Gmail initially offered.

Anyone who comes to your site thinks they will be getting a great deal if they sign up, and it costs you absolutely nothing.

February 26, 2010

PCMP Lesson 2: You Can't Trust Users

Over the weekend, I created a small app called PleaseCallMyPhone.com. It does just that— it calls your phone. I made it as a remedy for lost phones, however it is simple enough that you could use it for other things. It only took me a day to make, however I wanted to share a few quick lessons I learned from making it.

I created Please Call My Phone for me— I kept losing my phone, so I needed a way to find it. I decided to spruce it up, however, and throw it in my portfolio. After all, it couldn't hurt.

Deciding to let anyone use it, however, meant having to cut a few features. I could no longer let people enter in their own messages, since I knew I'd end up sending out a large number of monotone text-to-speech "I'm going to kill you" messages to unsuspecting recipients.

I figured my friendly "Hey, this is Gregory from PleaseCallMyPhone.com" message would be enough to dissuade people from using the application for nefarious purposes. Sure, people could still call their friends numbers- but, why? What would be the benefit of sending friends a phone call that clearly explains what it is, and how they can block the number?

I could have limited the calls per phone, or the calls per IP. But what if someone really couldn't find their phone? They might need to call it 2-3 times, especially if it's on vibrate (I recommend people add the number to their phones and set the ringer to a non-vibrating one, although I know most people won't be that proactive). I wanted my application to be as useful as possible.

I was wrong to trust people. The amount of people (both friends and people I don't know) who abused the system was unbelievable. So, I had to take the service offline temporarily until I have time to lock it down.

I know I should learn, but I'm still surprised by peoples boredom— everything from weird emails from my contact form to finding SQL injection attempts saved in my signup forms. It's a shame I couldn't make a simple little toy, and have people use it the way I intended it.

But that is my problem, I suppose.

February 22, 2010

PCMP Lesson 1: Easy Isn't Easy

Over the weekend, I created a small app called PleaseCallMyPhone.com. It does just that- it calls your phone. I made it as a remedy for lost phones, however it is simple enough that you could use it for other things. It only took me a day to make, however I wanted to share a few quick lessons I learned from making it.

A few weeks ago, I was talking to Eric Willis and he said something I really liked:

Everything that's easy isn't if you do a good job.

Take a look at Please Call My Phone. I used Twilio (my super-easy-to-use obsession), which did most of the heavy lifting. In fact, I got a "prototype" working in about ten minutes. So, then, why did it take me a whole day to get the finished product out the door?

It is the little things that take the time. The Pareto principle plays a big part in it— 20% of the work always does seem to take up at least 80% of the time.

My original, ten minute version had just a text box that called a phone. Every little tweak and change took time, though. Each little addition (scheduling, the design, better error handling, link to my site and Twilio link, JavaScript enhancements, etc) added up quickly.

There are a lot of hidden time sinks, too. Take a look at scheduling, for example— little things like handling time zones took a ton of time, and nobody will even notice.

People notice when something is done wrong, not when it is done right.

So, remember— if what you are doing is quick and easy, you are probably not doing a good enough job.

January 08, 2010

Amature Evangelists

Everyone who visits your site is a potential evangelist for your product — someone who will go out and vouch for it to their friends. This is more than just a simple recommendation. Evangelizing is a step up; more personal and more passionate. This is the best form of marketing- it's free, and the message comes from someone the potential user trusts.

So, how can you transform users into evangelists for your product? Think about the sites you evangelize- what are some things they all have in common?

For me, my list is relatively short. If we ignore the big ones (Facebook, Gmail, etc), there is Twilio, Grooveshark, Doodle and A Story Before Bed.

Here are some common characteristics:

They are easy to share

These products make it easy for users to share content. Doodle makes it painless to send your polls to people, while Grooveshark makes sharing music extremely easy. Most importantly, you can share on your own terms— via email, social networks, or just a link.

LinkedIn's "Join My Network" emails are annoying— they are a form of sharing, however they don't offer the user anything (at least, not in the short term). Doodle and Grooveshark offer the users something they benefit from, instantly.

Both also do a great job of converting people. Next time someone wants to set up a meeting, they will turn to Doodle. Next time someones looking to play a song, they will turn to Grooveshark.

Let's look at the competition. There is a site called TimeBridge, which runs circles around Doodle in terms of features. However, it is such a pain to use that very few people will ever want to put themselves through it again. With Grooveshark, sharing music has been around for ages— but rarely has it been so easy or pleasant.

They conform to the user

Many products try to improve our lives by adding features. My favorite products, however, just work. They don not ask me to change my workflow, or do things their way. They simply fill a void; no more, no less.

Many startups have an "our way is better!" philosophy. However, this asks us to leave our comfort zones and do things a different way. Evernote, for example, is a great product. However, they ask users to go out of their way (even if it is only a minimal amount). The products I tend to like, rather, merely fill a frustrating void.

Sharing music and scheduling events are all things we do regularly, yet do not have an efficient way to do it. Bridging a website with a telephone is something many applications need, but never had a way to do.

This is a subtle distinction, and I am not entirely sure I have illustrated it properly. I think the subtle nature is why most startups fail to nail it, however. They feel that they are enhancing users lives, and users should be grateful for the privilege to use their product. It is a subconscious mentality, but it is there.

Rather, they should be doing everything they can to conform to the users existing workflow, and make the experience as seamless as possible. Startups need to realize that the users are doing them the favor, and not the other way around.

No login

Doodle and Grooveshark don't make people sign up. Even for the person creating the poll or sending the music, no signup is required. This is the reason Craigslist is so huge- nobody has to sign up. Doodle acts just like Craigslist- you sign up, and you get a link so you can administer your poll. Unless you really need users to sign up- and, I mean, really need them to- there's no reason to make them.

Give users extra features if they sign up- but don't require it if you don't have to.

Simple

Twilio not only fills a void- it does it in a way that is impressively simple. I wasn't amazed by the functionality- I was amazed by how unbelievably simple it is to use.

Lets say you wanted a way for your customers to call a number, and have a voice tell them (for example) the current weather. Six months ago, I would have laughed at you. Now, I can do it in 30 seconds, thanks to Twilio:

<?xml version="1.0" encoding="UTF-8" ?> <Response>   <Say>Hello World.</Say> </Response>

Doodle polls are just as simple. Grooveshark is not as minimalistic as Twilio or Doodle, however the interface is still dead simple.

The Experience

So far, I am yet to mention A Story Before Bed. This is because I like it for different reasons. It might be simple to use, or any of the other characteristics I have mentioned before. However, the reason I like it is the experience. It is a beautiful site, with a consistent theme.

The Conclusion

What makes you want to tell everyone you know about a site? Think about that, and do your best to replicate it.

January 06, 2010

Textbooks

Textbooks are a cop out.

Sure, some classes require it. You can't teach a math or science class without assigning a textbook full of math problems and dry explanations.

However, for the courses dealing with the softer parts of science, teachers who assign textbooks are taking the easy way out. Why don't teachers assign actual books? They are cheaper, more enjoyable, and do a better job of getting the point across.

Marketing classes should assign Seth Godin, business classes should read Chris Anderson, and my class about technology diffusion should be centered around Malcom Gladwells' Tipping Point.

Yes, these authors offer one-sided views of marketing, business and technology.

However, what is wrong with that? I have never seen a discussion break out in a classroom over a textbook. Textbooks present things in a matter-of-fact manner. Books, on the other hand, spark debate. After all, look at how bloggers took sides when Malcom Gladwell wrote his scathing review of Chris Anderson's Free.

Maybe I'm biased. However, you can learn a lot more from the so-called Airport Books, the "elite class of business titles that I see sold in airport newsstands next to the magazines and crappy romance novels"((Coined by Anil Dash, Free Criticism, Science After Data, and Airport Books)) than you can from the expensive, monotonous textbook teachers feel obligated to assign.

There is a silver lining, however. Go and read on your own. You will be a few steps ahead of the people stuck reading textbooks.

January 04, 2010

Delivery

Two hunters are out in the woods when one of them collapses. He doesn't seem to be breathing and his eyes are glazed. The other guy whips out his phone and calls the emergency services. He gasps, "My friend is dead! What can I do?". The operator says "Calm down. I can help. First, let's make sure he's dead." There is a silence, then a shot is heard. Back on the phone, the guy says "OK, now what?

Have you ever retold a joke you found funny, only to have it bomb? Lots of things can go wrong— too verbose, amiss tone, bad buildup, wrong mood.

Badly executed websites are just like a bad joke— all the parts might be there, but something didn't click. Merely doing something doesn't mean you deserve those metaphorical laughs.

Explaining the joke never works— at best, you will get a pity laugh from listeners who want you to stop. If users are telling you they prefer a similar product, you can show them yours does the same thing if you go into the settings, click the link on the top left, scroll down, and blah blah blah. But it won't work. They will nod their heads, but won't be sold.

You need a solid product, appealing ascetics and effective marketing. Showing up is not enough. All the hours you put in and money you spent are irrelevant. Best intentions don't justify praise.

Take a look at the joke at the beginning of this post is. According to research by Richard Wiseman of the University of Hertfordshire((Spike 'wrote world's best joke', BBC)), it is the world's funniest joke. Even with that notable distinction, however, just retelling it is not guaranteed to garner a favorable reaction.

Get the joke right. Merely telling it does not mean you are entitled to laughs.

December 14, 2009

Freelancers From Hell

Recently, a Tumblelog called Clients From Hell popped up. It is a collection of stories about clients clueless about web design. At first, I enjoyed reading the stories. After all, anyone who ever worked with a client has heard "I can't pay you, but it will look good on your resume." However, the more I read the daily posts, the more I started to realize that freelancers are probably a pain. From the clients perspective, some of these freelancers are dead wrong.

Biased Stories

Take a look at the following story:

Your designs are too pretty, too beautiful looking. I need them to look more like I designed them. For example, instead of using a green box to highlight a chunk of copy, instead I would put green trees all over the page. You should try and be more creative like me and stop trying to make everything look so good all the time.

I would imagine that this is what the freelancer heard, not what the client actually said. After all, who would say a design is "too beautiful looking"?

I imagine the conversation went more like this:

Your designs are beautiful, but I need them more like I designed them. For example, instead of using a green box to highlight a chunk of copy, instead I would use these green trees. You should try and be more creative like me, rather than just going for something that looks good.

This isn't to say the designer is bad— he or she might be great. But either way, the design he produced wasn't what the person paying for it wanted. People want to get what they paid for— and it is evident that the designer ignored the clients initial suggestions.

Which brings us to our next point…

Clients Know Their Audience

Sure, freelancers may know "Web 2.0" inside and out. They may be able to make a beautiful, standards compliant website that would impress even the best of web designers. But the client undoubtedly knows their audience better. If the client thinks that their users would rather green trees, he is probably right. Maybe not from a design standpoint, however the client is closer to their own clients.

For example:

I m not a Graphic Designer but I redesiged your brochure in MS Publisher. This is kind of how I d like it to look

Do I find MS Publisher brochures attractive? Not at all. However, it is likely that this clients audience consists of other people who use MS Publisher. There's no reason to scoff at a client requesting Word— why shouldn't they be able to edit the documents they're paying for? I once had to redo my resume in Word once, and was pleasantly surprised at how similar it was to my InDesign version- and you didn't need a degree in graphic design to edit it.

Lack of Work

These stories are anonymous, so it is hard for submitters to upload work. But wouldn't it be nice to see the work in question? What if the designer created something truly horrid?

I have met a lot of people who complained about clients not appreciating their work, when their work was simply bad. We have no context.

Back to the story about the trees. What if the site was about nature, and the trees were tasteful vector images that subtly highlighted the message? Maybe the client wanted to get away from a plain green box- after all, very few sites can pull of a square, solid green box. Feel free to attempt to prove me wrong.

Car Mechanic Problem

Car Mechanics have a reputation for overcharging. When something breaks on my car, I know my uneducated "estimate" is always much lower than the actual cost. I have a superficial understanding of cars— there are a ton of factors I overlook. Are there a few mechanics out there that overcharge? Of course. However, overall, I would argue that normal people merely don't have a proper understanding of what repairs entail.

Customer: Our budget is $4,000 but it is not so complex what we want. Have you used Outlook?
Me: Yes
Customer: We want exactly that functionality in our site plus some other stuff.

Many of the posts on Clients From Hell are about lowballing clients. If a client offers you $100 and gives you two days, it isn't because they are insulting. They have no frame of reference, and they value the benefits of a website at $100 and two days of work. Do your best to make your case, but remember they aren't trying to screw you over— they just don't know any better.

For the few that involve the freelancer getting screwed— well, that's the freelancers fault. The client was wrong, but so was the freelancer.

We know your photos have been on our website for six months, but we re only going to pay you 1/4 of your invoice because we don t think the quality is there.

Get a contract, and get money up front.

Conclusion

My biggest problem is the name— Clients From Hell. I get it— clients like Comic Sans, ugly colors and Microsoft Word. But does this mean we should vilify them? We are dealing with people who don't know our trade— much like how we don't know theirs.

Wouldn't it be less bitter if the site was instead called "Clients Say The Darndest Things"?

There are two sides to each story. While these stories make for a good (despite repetitive) read, it would be fun to hear clients talk about their horrible hires.

Freelancers From Hell, anyone?

December 02, 2009

The MySpace Mentality

Over the past few months, I have been redesigning the website for my high school. I spent hours making sure it was exactly how I wanted it, right down to the last pixel. In my opinion, it came out really well. It was huge improvement over the current website, and probably my favorite design I have ever done.

Proud of my work, I began to show it off to people from my high school. Their reactions varied— some thought it was okay, while others said they hated it. Nobody, however, liked it.

I was outraged— how could they think the current clunky 1990s-style Dreamweaver-made eyesore was better than my clean, usable redesign?

But the more I thought about it, though, the more I realized they were not wrong. I was. I have spent too much time looking at web startups and CSS galleries, and am out of touch with how real people perceive web design.

People in the tech world mock MySpace, and the horrible layouts it hosts. However, most people have a "MySpace Mentality" in regards to design. After all, every designer has a Geocities site to prove they started the same way.

When people saw my redesign, they thought it was "plain" and "not colorful enough." What I thought of as white space, they thought of as room for a few more blinking GIFs. What I saw as good typography, a subtle color pallet, and usable navigation, they saw as boring.

In the real world, people like Comic Sans— it's playful. They like moving and flashing things— it's engrossing. They like clashing bright colors— it's eye catching.

It was depressing to realize this. What I considered a beautiful layout was considered plain and boring by everyone else. Non designers have a "more is better" approach when it comes to design. The more information and images and colors you can fit into the browser, the better the layout.

People don't make "bad" MySpace layouts because they can't do any better— they do it because they actually like it that way.

So, my high schools site is now being redesigned and implemented by a non-developer and non-designer, and it's going to be done in Dreamweaver. And most people will probably like it more.

Hey, at least now I have something nice for my portfolio.

November 30, 2009

The Broken Window Theory

The "Broken Window Theory" says that windows are more likely to be broken if one is already broken. From the original article "Broken Windows" by James Q. Wilson and George L. Kelling:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it's unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of trash from take-out restaurants there or breaking into cars.

The theory is that people are more likely to do something bad if someone did it before them. For example, cleaning up graffiti as soon as it happened supposedly lead to a huge decrease in crime in NYC.

This works with comments and message boards, too. If a post is offensive or badly written, delete it. Having only thought out and civil comments will lead to more thought out and civil comments.

There is a lot of criticism of the Broken Window Theory. However, look at comments on various sites. You will never see a YouTube-like comment on a site like Hacker News, and you will have a hard time finding a thought-provoking message anywhere on YouTube.

Expectations of quality are set by previous comments, and it is important to consistently maintain a high standard.

So, free speech be damned. Delete offending comments, or risk having the quality of your sites' comments go downhill.

November 26, 2009

The Value of Google Docs

Whenever I have an idea for a new company or project, I start a new Google Doc. I have a few dozen of them— some have full business models and mock ups, while others are merely a line or two.

It is a great habit to get into. It is great inspiration to go back to. There are many ideas I had months ago, but never could get right enough to start on. Sometimes, months later, the idea finally clicks. There was something you were missing before, or an angle you did not look at it from.

That Google Doc will store all your ideas, and you can go back and see what you thought of before.

When executing an idea, things change. The more you think about it and work on it, the further from the original idea you get. Sometimes, it is useful to go back and see your original ideas. Often, in your rush to go in a new direction, you forgot a cool feature or idea from the original plan.

You do not have to execute every idea you write down— that is a fools errand. However, it is useful to have a reference, since some day it might become relevant.

November 25, 2009

"I had that idea, too"

The more I talk to people, the more I hear and say the phrase "I had that idea, too." I rarely hear "I did that", though.

Ideas are easy. You can come up with ten good ideas right now.

The problem is you did not execute. That is not a bad thing— nobody has time to make every idea they think of happen.

The people who succeed are the ones who pick the best of their ideas, and let the rest go.

So, next time someone tells you their idea, do not reply "I had that idea, too." Instead, be proud of the ideas you did pick to execute.

And, do not feel bad if you tell someone your idea, and they say "I had that idea, too." It does not cheapen your idea. If anything, it is confirmation it might have a market, since someone else thought of it. They were not the right person to execute the idea— if they were, they would have.

If you are the right person, make it happen.

October 07, 2009

A Dying Protocol

I don't like speculative posts. It is easy to come up with the perfect solution, and outline it in a blog post. Thousands of people have figured out how to fix the financial crisis, and how to perfect health care— if only the president would read their blog. There is no shortage of "How to save…" posts. The newspaper industry, the music industry, Yahoo!— the list goes on and on. And even when these ideas do pass a speculative stage, and get backed by proper research, they still don't always work out- such as EBay buying Skype, Google buying Dodgeball and Jaiku, or Time Warner merging with AOL.

The beauty of speculative posts is that they can't be proven wrong. That is also their downfall— they are too easy to do. After all, it is easy to justify on paper, when millions of dollars are not at stake.

That being said, here I go. Here is my suggestion on how to save Instant Messaging.

Instant Messaging has always been a mess— from the beginning, the major IM protocols have promised they would someday all work together. It would be absurd for Hotmail users to not be able to email GMail users, or Verizon customers to not be able to text AT&T customers— yet over a decade later, we still cannot IM someone using Yahoo! Messenger with our AIM screen name.

We do have a bit of a fix, however— clients like Digsby, Pidgin and Meebo bridge this gap by letting us use multiple protocols at once. Not idea, however it works.

I was talking to a few people, and they said they don't really use AIM anymore. It got me thinking— there has to be a way to save AIM (and all Instant Message protocols). AOL has tried— they keep throwing features at AIM, in order to make it better. But in the process, they are slowly just making it worse by creating a bloated program. AIM is dying, in the same way that MySpace is dying— it is far from dead and never will be, but it is not exactly picking up steam.

So, if I may indulge myself in a little speculation— who can "save" them?

Facebook. And Meebo.

Rather than start up their own protocol, Facebook should have bought Meebo. This way, they could allow people to IM their friends right from Facebook, without having to add another "protocol" to the already large and unruly list of current protocols.

Here is why it makes sense:

  • Facebook already has everyones screen names: Facebook probably has the worlds largest database of personal contact information— so they could attach some privacy settings to them, and allow users to IM their friends AIM/Yahoo!/MSN screen names right from the site. They already have everyone's screen names, so they could easily populate the buddy lists for anyone using Facebook.com.
  • Screen Name and Facebook Taboos: A negative of having screen names on Facebook is that it's somewhat awkward to IM someone using a screen name you got from Facebook. There's a stigma attached to "Facebook Stalking"— even though people willingly divulge information on Facebook and consume it obsessively. Can you get away with IMing someone and saying "I got your username on Facebook"? Yes, if you must. However, it's still a taboo. IMing someone on Facebook is much more acceptable, for whatever reason— so if AIM and Facebook were combined, maybe it would be easier to start up a casual conversation without seeming like a creep. "I saw you were online" is a lot less creepy than "I went to your profile, copied your IM screen name onto my buddy list, and waited until you signed on."
  • Time on Facebook.com: Right now, a majority of people can only use Facebook chat from Facebook.com. You can of course use a third party client like Digsby, however most people go to the site. Clearly, this is intentional— Facebook wants people to stay on their site as long as possible. However, the problem is that you can only talk to people on Facebook.com. I may be on a computer for a few hours, but if I only check Facebook once in a while for a few minutes at a time, it will be hard to catch me.
  • Facebook Connect: Facebook could take Facebook connect a step further by combining it with Meebo for Sites. In my opinion, is this a benefit to me? Not really. But Facebook is always looking for ways to seep into other websites.

So, there is my speculation on how AOL could have salvaged AIM, one of its last remaining relevant properties. Would it have worked?

I guess we will never know.

October 05, 2009

Marketing Awareness

A few summers ago, I worked for a small company that made custom travel guides. They had the traditional information about your destination, but they also had information such as weather and events for the dates you would be there. All this was packaged into a professionally printed book, which showed up at your door a few days before you left.

It is a great idea, with a great product to back it up— and it showed up on the first page of Google if you search for something like "custom travel guide." But here's the problem— who searches for that?

Sure, you can advertise— but what's the point of buying keywords from Google? You are still only reaching an audience who's searching for or reading about travel guides.

That is a huge problem with start ups— the more clever the idea, the harder it is to advertise. Who knew they needed forecasts for sports and concert tickets, a place to manage and share referrals or even personalized travel guides? All of these, and just about every other start up ever created, is useful. But people do not know they need them.

Traditionally, marketing has always been based on conditioned reflexes— marketers do their best to associate happiness, trust or other desirable feelings with their products, so we will choose their brand when standing in the store looking for detergent.

Products like this are not limited to bits and bytes, however— turn on the TV at 3am, and you will find a ton of infomercials trying to sell you stuff you never knew you needed. Nobody thinks they need a Snuggie or an Apple Machine Peeler Corer or a Hercules Hook. Every one of these products would come in handy if you had them and used them— but unless the infomercial happens to come on right as you are doing a task that would be made easier by it, odds of you ever getting the product are low.

With start ups, we are not just convincing people that, say, your company sells the best "personalized, up to date travel guides" available— you are trying to convince people that "personalized, up to date travel guides" exist, and that they actually need one.

September 14, 2009

Blogging is Hard

There is a joke I have heard a few times, that says most blogs have only two posts— one introducing the blogger and hyping up the blog, and the second, a few months later, apologizing for not posting more often. At the risk of sounding cliché— this post is the latter.

After all, blogging is hard. It is a lot like working out— you can get as strong as you want, but a few days off is all it takes to start regressing. If you take a few months off, you can easily lose everything you worked for. That is a lot of pressure— knowing you need to post interesting commentaries consistently to avoid slipping into even more into obscurity. Very few bloggers manage to ever write an article with a shelf life longer than a carton of milk— so I really admire the bloggers who stick with it and post constantly.

Like most things, there is a lesson to be learned. Most of us do not have the stamina to churn out a steady stream of content. So when you start your next company or project, don't pick something that requires you— you will wear yourself out. Very few projects can remain untouched for years and still be relevant, however you should aim for doing something that can survive with no updates for a few months.

If your entire project relies on you to continuously being active, odds are you will not be able to keep up. And it will show. Much like this blog.

August 19, 2009

The Price Might Not Be Right

My brother's 18th birthday was coming up, and I needed a card. Since Hallmark doesn't seem to have made it to San Francisco, I went with Papyrus. I found the birthday cards, and spent ten minutes picking one out. None of the cards had prices on them- but it was just a card. How much could it be?

I headed to the counter, where I got my answer— eight dollars. Eight dollars? For a birthday card for my brother? I bought the card (after all, I was invested in it— I had spent some time deciding on it), and left.

If you look at any of the A/B tests I have run on larger commercial sites, you would see a similar trend. People are much more likely to go through with a purchase if you do not show them the price until the last possible moment. Why is this? Google Analytics is always a bit fuzzy on the why, but we can guess. Maybe it is because they are already invested in the product? Maybe it is because the more they see, the less they think the price is unreasonable?

There is a time and a place for eight dollar cards— however, my brothers birthday was not one of them. Rather than turning to Papyrus when I do need an expensive card, however, I am now bitter towards them. Had I walked in and saw the cards were a bit pricey, I would have left and made a mental note that it's a great place for a nice anniversary card. That is one of the problems with A/B tests— you cannot quantify the most important variables. While my purchase shows up as a conversion for the store, they lost me as a future customer. An A/B test would count my visit as a success, and would never have known Papyrus lost out on my yearly Mothers Day business.

Statistics cannot track when people tell their friends "it was a bit expensive for me, but you should check it out." Statistics cannot track when someone thinks "this is not what I am looking for, but these are reasonably priced— I'll come back later."

So, before you take the price off your online products just because they numbers say you should, think about what is more important— your brand, or making a few bucks off a conversion.

And if people are still leaving your site when they see the price— maybe you are charging too much? Lower your price, don't resort to tricking your potential customers.

August 14, 2009

Hire Developers

I am biased. As a developer, of course I am pro-developer. However, I do not see any reason why you should not hire a developer for as many positions as possible. They do not have to be the world's greatest programmers, they just need a solid understanding of how to do things on their own.

All companies have little (yet important) tasks for developers. Gathering statistics, setting up ads, doing A/B tests. And rather than taking one person X amount of time, it takes two people that same X amount of time. These things are slightly too hard for non developers (HTML? Databases?), but a time-suck for developers working on bigger projects.

With any decent sized company, everyone has little jobs for the developers. These jobs pile up— the developers have to spend time doing these tasks, while everyone else loses time waiting for them.

So, why not hire a developer to do that sales, project management, analytics, or marketing in the first place?

August 03, 2009

Don Not Be An Idea Person

Probably the worst thing you can be is an idea person. I constantly meet people who will tell me about their next big thing. So, I ask, how will you implement it? Oh, I am just the idea person, they smugly reply, I will leave that to the programmers. There are humble idea people, no doubt. I am just yet to meet any. They all seem to treat programmers and designers as lowly tools, waiting for an idea person to save them.

Coming up with ideas is easy— I have come up with a good half a dozen ideas today. I am sure you have, too. And I could not even begin to count how many times I have read about a company on TechCrunch or GigaOM, and thought to myself— wow, I thought of that idea a while ago.

But ideas are the easy part— anyone can come up with a few dozen ideas in no time. The impressive part is sticking with the idea. Finding the right people to help with it. Making it. Selling it. Tweaking the little aspects to perfection.

There is no pride in coming up with an idea. Ideas take a few seconds. Making it happen takes years of hard work.

Do not be an idea person.

July 27, 2009

PHP: MVC By Nature?

After spending hours upon hours fighting with frameworks, I got fed up. They are certainly tempting, since they take care of the initial structuring of your program. However, once you get past that— what do they bring to the table? Are they really worth the inevitable aggravation?

Some people will have thought about this thoroughly, and come to a different conclusion than me. Others will have just a gut reaction to me saying that procedural programming still has a place in PHP. Either way, a lot of people are going to disagree.

So, with that, here goes my argument that PHP is already MVC-ready.

Views

PHP is unique from many compiled, desktop-centric languages in that all presentation is done using a separate language (a markup language, but a language none the less). Short of XML output and the like, all PHP needs to be echo'd and print'd out among longhand HTML. Even in my earliest, blissfully-ignorant-to-MVC days, it was apparent that it made more sense to separate the HTML from the PHP. (Of course, there is a subtle yet distinct difference between separating the PHP from the HTML, and the logic from the presentation— but remember, I was still MVC-ignorant back then). A simple include does the job. So, why do we need a framework to do this for us?

Of course, you could argue the merits or disadvantages of using a templating engine like Smarty, but the point is moot- none of the major PHP frameworks really have any templating features beyond what an include can do.

Models

Models are covered by objects— they take care of the data. More often than not, the job of the model is to convert raw data (often from a database) into something the controller can work with. Models take care of the tedious business logic, creating a bridge between the data and the code. Writing out SQL statements in the controller quickly gets messy— models make it easy to keep the data all in sync, across the entire program.

One thing that has always bugged me is that in frameworks, you have to load a model before you can use it. Why? With PHP, you can automate this— going through a framework just makes debugging even harder. That's not to say that extending a generic Model class can't help your models— however, we don't need a full framework for that.

Controller

With me so far? Well, here is where I will probably lose you.

First, let's make something clear. I can't say enough good things about OOP— so I'm not even going to bother trying. Barring "Hello World," I can't think of a single program that would not benefit from OOP.

However, here's a quote from the creator of PHP:

PHP has traditionally been a procedural language, and OOP features have crept in over the years to the point where PHP can be used as a decent OOP language.
Rasmus Ledorf, creator of PHP

I never understood why we are so fond of using OOP for the controller portion of MVC. I understand the arguments for it— however, given the bland, generic way frameworks currently utilize OOP in controllers, it seems it is used more for the sake of being object oriented than because it is the right tool for the job.

How about this for an alternative: One index.php file, that takes care of routing. It can be more flexible, in my opinion, than the regex-based routing implementations in most frameworks. Yes, I do agree that programming is easier when we can look at a URL and instantly know the class and method the code is in. However, I also feel there's merit in dropping the "automagic" that happens when a framework handles our routing. (And honestly, I've never worked on a framework based project that had a URL structure that mapped directly to the class-defined structure anyway.)

If we do it this way, we can move the structure from the classes to actual folders. We can split the PHP up among a bunch of smaller, procedural files. On top of that, if we commit to mirroring the URL structure, we don't lose anything in the way of navigating code.

Libraries and Helpers

In the spirit of not reusing code, we can still make liberal use of libraries and helpers— basically, classes or functions that handle any code we may need to use more than once. These would have to be include'd on a use-by-use basis, of course— but how hard is that?

In my opinion, the biggest problem with frameworks is they're not very good at letting you do things your way. For a team of inexperienced or lazy programmers? This is great, as it makes sure everyone is on the same page and does things the "right" way. However, more often than not, I find it annoying that I am suck doing things the framework's way.

JavaScript framework/libraries have it right— you can use them as much as you want, but if for whatever reason you want to use straight JavaScript? They stay out of your way. Why can't PHP do it this way? We should worth with PHP libraries, not frameworks.

The Benefits

  • Libraries no longer have to be framework-specific. This opens us up to a lot more prewritten code that we can utilize.
  • Faster. No matter how fast frameworks are, they're still slower than straight PHP.
  • Easier to follow the code, if you don't have to loop in and out of foreign code to debug it. Using a frameworks loader will often break most PHP IDEs and debuggers.
  • Less things that can go wrong. If something breaks with just PHP, it is either PHP or you (and, more than likely, it is you). If you are using a framework, there is a third party that could also be at fault.

Conclusion

Model-View-Controller architectures and Object Oriented programming are fundamental to making intelligent, easy to read applications in PHP. When we start a program, we need to take the time to think about how we can structure the code in a comprehensible way. However, we don't necessarily need an MVC framework in order to keep our program separated into models, views and controllers. PHP is already MVC-ready— so rather than focus on frameworks (which, in my opinion, tend to be lacking), we should create our own well-thought-out architectures and use libraries for the code we want to outsource to open source.

Sure, it's not as glamorous or trendy as an MVC PHP framework. But at least one person agrees with me.

July 22, 2009

A Solution To E-Mail Validation

Whenever it comes time to validate an email address, I always end up going through the same exact process.

I start with a simple regular expression— for example, this:

(.+)@[\w]+\.[a-zA-Z]+

It works great for a majority of email addresses— however, it is not perfect. It lets through a lot of invalid email addresses. For example, ".name@something.a" is considered a valid email address by this regular expression. So, let's take a few steps to correct this:

([-a-zA-Z0-9])([-.a-zA-Z0-9])*@[\w]+\.[a-zA-Z]{2,5}

A bit better, right? But what about valid email addresses, such as john+smith@mail.something.com and $A12345@example.mobile? Same goes for the seemingly invalid email addresses such as "Abc\@def"@example.com. But, alas, these are all valid.

No, I am not going to even attempt a regex that accommodates these. Others have tried. However, it is futile; email validation ends up either being too strict with what it rejects, or too liberal with what it lets through. Or, in many cases— both.

But for the sake of argument, let's assume we do create a regex that follows the RFC perfectly. That still doesn't stop people from getting through with something like youre.bad@validation.com. Sure, we could even go as far as checking to make sure it is a real, actual email address. But even then, there is no stopping johnsmith@gmail.com— an email address that surely exists, however probably is not owned by the person filling out the form.

Depressing, huh?

Well, what about this one:

(.+)@(.+)

Here's the secret. This is not a programming problem- it's a usability issue. If the user benefits from giving you their real email address, they will. If not, you should not be asking for an email address.

It is that simple, really. Just make sure they at least attempted an email address (otherwise, they may mix up the fields), and throw in a good reason to hand it over- and you will never have a problem.

Thanks to Chancey Matthews for reminding me checking for an @ symbol is good enough, and haacked.com for reading the RTC so I didn't have to.

July 20, 2009

What Kind of Company Are You?

The biggest problem inside companies is self interest. The sales team wants to make money, the writers want editorial integrity, the legal team wants to avoid lawsuits, the engineering team wants to use cool technology— the list goes on and on.

Does every company need a little bit of everything? Of course. However, it is important for companies to decide which is the most important for them. Otherwise, every department is fighting for the spotlight— and they all end up being at odds with each other.

A company needs to pick that one attribute it wants to strive for— and if it is done well enough, the other qualities will come naturally. It is important it only goes for one— trying for numerous of these attributes from the start will result in a company with an unclear direction, which is apparent to consumers.

July 15, 2009

I've Been Had!

After ten years of using the same password, using strange programs and logging in on public computers, it finally happened- someone broke into all my accounts.

It was a long time coming- I started to get a bit cocky about my online security, after all. Same passwords everywhere, no spyware programs running, no encryption anywhere. But hey- ten years without anything going wrong? You let your guard down.

First Sign: PayPal Email

Last night, I got an email from PayPal asking me to confirm a purchase. Honestly, I probably wouldn't have really thought twice about it (given how many fake PayPal emails I get), had I not enabled GMails new anti-phishing plugin literally minutes before. Convenient, huh?

So, I checked it out. I had a $30 charge- and I hadn't bought anything recently. Thinking it was possible I may have bought something and forgotten about it (a subscription or pre-order, perhaps?), I investigated a bit further. It was for a "digital credit card" on EBay- nope, definitely not mine. Nothing in my eBay account about it, either- so, it was just a PayPal problem.

Virtual Credit Cards on EBayEBay knows me so well now

Not a big deal- PayPal's good at stuff like that, right? So I disputed the charge, and went to bed.

Up Next: Locked Out of GMail

The next morning, as usual, I went to check my email. Whoops, wrong password. That's cool- it was early and I was still half asleep. So I tried again. Still nothing. And again. Maybe it was a GMail issue? After all, they've been down a few times recently. So, I hit Twitter to get the scoop- nothing.

That's when I started getting a bit worried.

I tried to reset my password, and logged into my old Hotmail account (the account I had when I first got GMail) to get the reset link. Nothing. (As I would later find out, Hotmail does this thing where it shuts down your account and deletes all your emails if you don't use it for a while. So, Google did try to send it to me, it just never got sent.)

That's when I started to get really worried.

Google Knows A Lot About Me

I never really worried about Google having a ton of information about me- I trusted them. But I never realized how much they know about me, until it mattered. Among other things, they have a list of every site I've visited in the past few years, every email I've sent or received, copies of my social security card and drivers license, most of my files (as I use GMail as a thumb-drive replacement), a lot of my passwords (or the ability to reset passwords via email), email addresses of everyone I've ever contacted, my home address- the list goes on and on.

I also never realized how much I relied on Google, either. The first form I filled out said I had to wait 24 hours to reset my account. Better than nothing, right? Then I realized how much I used Google- that's 24 hours without all my emails, files, and documents. And I couldn't even IM people about it- I was locked out of Google Talk, too.

GMail Emergency Account Recovery Form

Not wanting to wait 24 hours, I kept looking. I eventually found their account recovery form- it asks you a bunch of questions only you can answer (and not of the "Favorite high school teacher?" variety), and apparently analyzes your answers.

I was pretty impressed by this form. It asked for things like five people I contact often, four of my GMail labels, approximately when I signed up for GMail, and the most recent password I could remember. It also used my IP address, to make sure I've accessed the account before. I guess I passed the test, as it emailed me about a half hour later to let me know how to reset my password.

GMail, like every other site I'm going to mention, did a great job of helping me out. I really liked the recovery form- it was incredibly logical, and seemed safe to me.

Google Knows A Lot About Them, Too

After logging in, I checked GMails logs- someone or something, with an IP in NYC, accessed my account at 12:30, 1:21 and 1:40. That's all the info Google was willing to part with- but at least it confirmed my account was indeed compromised, and not just a random glitch.

And, they did some searches for "buy vcc with paypal" (VCC stands for Virtual Credit Card):

buy vcc with paypal

Spooky that Google logs all that, huh? But mighty useful.

PayPal Round Two

In my newly unlocked inbox was another email from PayPal, telling me they were locking down my account due to suspicious activity- while it clearly meant this was far from over, it was a bit of a relief. This means they were in it for the money- I knew I could get my money back through PayPal or my credit cards, it was all the data in my account I was really worried about.

So, I went to PayPal to figure that out. They of course did a wonderful job- it wasn't a fun process, but it certainly was thorough. I had to do things like confirm my location via a land line, and enter in my card information. I managed to clear that up (I had two charges; one from the night before was still pending investigation, while the second one was automatically refunded by PayPal), and changed my password.

Next Up: Amazon

Of course, I checked all the big sites I have accounts with as soon as I realized there was a problem. On Amazon, there was nothing in my list of recent purchases- so, I just assumed I got lucky there.

Of course, I couldn't have been so lucky- I got a call at about 10am from a lady at Amazon, asking me to confirm some purchases. A few went through (straight to my credit card; so I have to wait 24 hours before I can dispute them), however Amazon managed to catch it before I was charged $500 for a bunch of $50 "XBox Game Points." Seems Amazon has a separate list of bought digital items- which I never would have noticed had they not called me.

The lady told me she had to close my account- which was fine with me, I was just grateful Amazon was nice enough to call me.

The Aftermath

Overall? Seems like it's all going to be fine. I'll keep an eye on my credit cards, but overall I think I dodged a bullet, thanks to the wonderful companies I dealt with today. Google, PayPal and Amazon all made it easy for me to take my accounts back, and keep charges down to a minimum.

One thing that bothered me still, though, was why they needed my Google passwords. After all, I couldn't find anything around the time my account was "hacked" that indicated they had touched anything.

So, I was determined to figure it out- and eventually I did. They had been deleting confirmation emails from Amazon for a while. Not enough to flag any system (Amazon, PayPal or my banks), or raise any suspicions from me. And it was working, too.

Then, they (presumably) got greedy- they started taking more, and (most importantly) changed my GMail account. So they went from possibly getting away with a few hundred, to getting nothing. Whoops.

How'd It Happen?

I used the a few of the same passwords over and over again- I know it's not a good idea, but it saved time when typing passwords in. I didn't have to think, I just typed. If you add up the seconds it takes to remember your password for a given site (or, the minutes it would take to either get it wrong a few times, or to look it up)- over the past 10 years, I've probably saved a lot of time. And, nothing bad every happened, so why not?

There's a lot of things that could have done it. A virus, or maybe a good phishing attack. I got caught by the FBAction.net phishing scheme- I opened it on purpose because I wanted to see if it was any good, forgot I opened it, and later instinctively put in my Facebook username and password. Not my proudest moment, but maybe that was it?

Or maybe at some point I used my email username and password on some sort of site that eventually got hacked. Whoever did it could have easily run all the usernames and passwords through a variety of common sites, hoping to get in.

Either way, it could have been a lot worse. So, thanks Google, Amazon and PayPal. I owe you one.

July 13, 2009

Some CodeIgniter Gotcha's

Maybe I'm doing something wrong. In fact, for the sake of programming, I hope I am. But for the life of me, I can't find a single benefit of PHP frameworks that isn't overshadowed by the negatives.

(Update: I have made the switch to Python/Django, and have no intentions of looking back.)

PHP frameworks make it easy to start out— meaning that, when facing a new project, they seem like a good idea. You don't have to do all the boring stuff at first— and when you are starting a new project, that is a tempting proposition.

This topic deserves a much more thorough analysis (which many before me have done, and I am sure I someday will), however after spending the weekend struggling with CodeIgniter, I figured I wouldd mention some CodeIgniter-specific problems I have come across.

Debugging

When I started programming, things took me a while. I didn't use frameworks- I did everything from scratch. However, despite the time commitment, I was making progress- it was time consuming, but it wasn't frustrating. It felt rewarding- plugging along in Notepad.exe, making slow but steady progress. Then, things changed. I started using PHP frameworks- and things started to go downhill. Rather than investing my time in programming, I started spending more and more time debugging. And debugging became harder- after all, frameworks tend to break native error reporting to a certain extent.

Here is the code:

$this->load->model('whatever');

Here's the problem- IDEs and even PHP itself has a hard time following that. A lot of times, errors will show up as being in the Load or Model classes- not helpful, when you know the actual problem is in your code.

Like, this error:

Filename: libraries/Model.php Line Number: 70

The error is in my code, not the file/line given. Where is it? Your guess is as good as mine- CodeIgniter isn't telling.

Conventions

CodeIgniter almost seems to take pride in being illogical when it comes to conventions. While PHP's conventions may be laughable, CodeIgniter's are prohibitive.

For example, what is the output of this code? (And, let's assume these two lines are on separate pages- otherwise, the cookie wouldn't yet be set.)

set_cookie('test', 'value'); echo get_cookie('test');

I know what you're thinking- and you're wrong. It's not "test." For whatever reason (which isn't documented in the documentation), set_cookie() automatically appends the prefix from the config files, while get_cookie() does not. So, you would have to do the following to get the expected results:

set_cookie('test', 'value'); echo get_cookie('prefix_test');

Great, huh? I'm sure the reason is so that you can read any cookie, however it makes the whole thing incredibly confusing.

Another example is callbacks. Maybe this is a standard practice, who knows. But I don't like it. In CodeIgniter, for validation, you can specify a rule. So, something like this:

$rules['email'] = "required|valid_email|unique_email";

The "unique_email" part is a custom function- and it has to be called unique_email_callback. I have two problems with this. One, it's not easy to figure out unless you read the docs- code should be easy to follow. And, secondly, why are these callback functions written as strings? This is code- I shouldn't be writing out function names as strings. It makes it much harder to follow.

Attaching Libraries/Models/etc To Everything

Maybe the biggest problem is that if you load any sort of library, view, or model- it's attached to every single object. So, let's say you have an object, with a property called "parent."

So, this code works:

echo $whatever->parent; // Prints out '3'

Now, somewhere else on your page, in a completely different object, having nothing to do with $whatever, you do this:

$this->load->model('parent');

Your old code? No longer works:

echo $whatever->parent; // No longer '3'

Does this make sense, to a certain extent? Yes. Logically, yes. But, it is incredibly— you can't have, for example, a model with a 'section' attribute and also have a 'section' model. This has caused things to break for me more often that anything else- a perfect example of how changing something in one part of the code can affect something completely unrelated. Something that doesn't happen with straight up PHP.

And there's more

There's more. Lots more. And maybe someday, I will document more of the problems I have with frameworks. Or maybe I'll switch to something better. (Edit: Django!) But either way- I hate spending a day programming, only to get nothing done. PHP frameworks are bad at getting out of your way. Before frameworks, a day of programming may not have resulted in much, but it went at a steady pace and I knew X hours of programming would equal Y results. Now, I can spend a whole day trying to get something stupid simple working, with no results.

And I promise- whatever I write for Wednesday, it will be more upbeat!

July 10, 2009

The Portfolio Rule

I have a simple rule when it comes to deciding if a design is finished: would I put it in my portfolio?

I used to be pretty good at convincing myself my latest work was "good enough"- deadlines, boredom and difficulty definitely encourage such rationalization. I used to ignore that voice in the back of my mind that said it just wasn't there yet. Since I started trusting my gut instinct, I've found myself asking "what was I thinking?" a lot less often.

Everyone will tell you "bad isn't the enemy of good, perfection is"- and that's definitely true. But all to often, it's used as a cop-out. An excuse to release something that's not quite up to par.

So, next time you're wondering if you're done- is it good enough to land you your next gig? Are proud enough to put it in your portfolio? And, of course- remember to be honest.

July 08, 2009

Masking Passwords?

Recently, usability expert Jakob Nielsen made the case that we need to stop password masking. After a few days of mulling over the suggestion, here is what I came up with.

Whose Job Is It?

In his post, Nielsen implied that the unmasking of passwords should be put into effect by the web developers. However, his suggestions would work better if implemented at the browser level. This way, users could easily and globally toggle the feature on and off, and decide for themselves if they want it. (And, of course, there's already a Firefox plugin that makes the whole argument moot- users who prefer this functionality can already choose to use it.)

Usability Concerns

Consistency is one of the most basic usability principles. If users know that the same command or the same action will always have the same effect, they will feel more confident in using the system[...]
Usability Engineering by Jakob Nielsen, p 132

Nielsen himself claims that consistency is important- so how can users feel confident, if some password boxes protect their passwords while others do not? Not only is this an argument for it being a feature in browsers rather than websites, it's an argument why it's dangerous for web developers to even attempt it. It would be one thing if all passwords were unmasked- however, Nielsen is calling for it's implementation on a site-by-site basis.

Breaks Browers

By removing the type="password" from the input element, we make it so that browsers won't be able to tell the submitted field is a password- effectively breaking the "Save password" feature that saves us from having to type in passwords constantly. And, even if this didn't break the feature- would you want your saved password popping up in plain text every time you hit a site with a login box? (Of course, saved passwords could be shown masked- but this is again a browser-level feature, as well as defeating the purpose of plain text passwords.)

Perceived Security

It's true that masking makes no no difference in real security, however Nielsen has completely ignored perceived security. Users don't understand that the only thing masked passwords protect them from are people physically standing behind them- having their password show up in plain text will no doubt result in many users believing anyone anywhere can nab it.

Icon

As made obvious by the press this suggestion has gotten, people listen when Jakob Nielsen talks. If he was serious about people implementing this, he should have attached some sort of pseudo-standards to his post. Had he created small masked/unmasked icons, he could have done for this what the little orange icon did for RSS. People could have seen the icon, and known right away that the password field was unmasked (and known that clicking the icon would turn masking on). Rather, anyone who implements it now has to individually explain to the users what's going on, and how to toggle it.

Testing

One thing that always impressed me about UseIt.com was the research that went into every alert. He always seems to have statistics to back up everything he said. In this post, there was none. Had he found 20 people with various degrees of computer know-how, asked them to register for a mock site, and recorded their reactions? Then we could be confident one way or another. He's forgotten that one of the basic principles of the field of usability is that even the experts can't be confident until they observe actual users.

My Conclusion

We have to forgive him a little, though- his perspective is from that of usability only, and nobody can disagree that it is easier to type a password when you can see it. That being said, I would argue that his view of this was too narrow; if he did indeed look at it from a broader context, he didn't let it show in his post. Even from a usability standpoint, it's easy to see how this could be a potential problem. He answered a very black-and-white question- "Is it easier to type when you can see what you're typing?"- and the answer is, of course, yes. While he does spend a paragraph conceding, almost reluctantly, that "sometimes security should win," overall he stays away from exploring the ramifications of removing password masking- writing it off as Geocities-era "legacy design."

He is right about one thing, though- those reset buttons need to go.

July 06, 2009

The Medium is the Message

When Marshall McLuhan wrote his famous phrase, "the medium is the message," he was talking about about TVs, newspapers and radios. However, his insights into how the medium influences how we perceive the message can just as easily be applied to modern day RSS feeds.

When running a website, a lot of work goes into creating an atmosphere. The colors, fonts and layout of elements are carefully chosen to convey a certain tone to the reader. When we use RSS, we strip out everything but just the words. While no doubt an extreme example, it's a bit like reading just the manuscript for a movie.

There are a lot of good things to be said about RSS- it's an incredible example of how web standards can lead to innovation, and it can keep us from having to refresh our favorite websites constantly. However, when we rip the text from the site, we lose a lot of visual cues- everything from quality to credibility can be gleaned from just looking at a layout. The design of a website is just as important as the content- and often exceeds it.

So, as a blogger, how can you get people to go to your site rather than subscribe? Try adding features that can't be reproduced using RSS- Digg has an RSS feed, however I would wager that most people go straight to the site. Or, try posting on a rigid schedule (and keeping it!). Users will know exactly when to check your site to get fresh content (and don't ever add "extra", unscheduled posts- it may seem like a treat for your users, however it defeats the whole purpose).