Archive for Programming

The last 20% before shipping

What makes a new feature or product update “done” versus what makes it “really done”? At  Close.io we developed our own process to answer this question, based on years of shipping new features for our sales communication platform. Today, we want to share this checklist with you.

As soon as a new feature you’ve built is running and working on your development server, there’s a strong temptation to think it’s “done”. You want to ship it. After all, the code is working, and you know many of your users would benefit immediately from the change.

It’s important to stop and ask yourself: What else should we do other than just making a new feature functional? How can I improve the experience for users or make this feature more accessible and maintainable?

We’ve learned that when you’ve only gotten a feature working, you are at most “80% done” and that the last 20% really makes all the difference. In fact, sometimes the “last 20%” of polishing a feature can take just as long to get right as the “first 80%”, however it also is what separates good from great.

Here’s our internal checklist that we use before launching significant new features or changes. Whether for launching a new reporting feature or migrating our database to a different cluster, we’ve found this list to be really helpful.

Performance

  • Is it fast?
  • Are the database queries optimized?
  • Will it scale for a large number of records?

Code quality

  • Is the code cleaned up, organized, and properly abstracted?
  • Is it well commented / documented? Assume someone else will have to maintain it.
  • Are there relevant unit tests?

Edge cases

  • Do you consider and properly handle edge cases and invalid inputs?
  • Did you test the first time experience / no-data-yet case?
  • Is it localized? Consider timezones for anything date specific, and unicode.
  • Did you test in all the supported browsers / platforms?
  • Have you tested for potential security vulnerabilities?

Polish

  • Does the UI look polished? Is it consistent or better than the rest of your application?
  • Does the UI react to various edge cases properly?
  • Is any written text as good as it can be? Did you check for typos?

Deployment

  • Does it need any special deployment process, and is the process well documented? Any data or schema migrations necessary?
  • Is everything backwards compatible? If not, did you communicate the change to users?
  • Should it be deployed/visible to employees only to dogfood/test for a while?

Communication

  • Are the relevant API docs complete?
  • Do any FAQ docs need to be updated or written?
  • Did you write a blog post announcement, if appropriate?

There you have it. Run through this list before shipping something new and you’re guaranteed to have a better launch.

Do you have anything to add to the list? Let me know!

Comments off

Render a PDF from html using xhtml2pdf and mimerender in Flask

I’m working on invoice/receipt generation for Close.io and wanted to create simple PDFs using nothing but HTML.

Using Flask, mimerender, and xhtml2pdf, here’s how:

Comments (1)

Sweating the UI & UX details in Close.io: Emails & Email Addresses

My blog post on the Close.io blog was pretty popular (18,000 pageviews & lots of HN comments) so I wanted to cross-post it here.

Sweating the UI & UX details in Close.io: Emails & Email Addresses

We like to think of our sales software, Close.io, as having a lot of magic under the hood. When we do our jobs successfully, our users may not even notice, but their lives will be made a little easier. We try to make features just work without requiring users to think too much, even if that adds complexity in code.

Here are a few examples:

1) Entering contact details

Most CRM and address book software make you enter your contacts’ phone numbers, email addresses, and URLs in specifically chosen separate fields per data type.

We realized this sucked and now give you a contact form like this:

image

You shouldn’t have to make a choice for each phone number, email address, or URL you enter for a contact. We just give you one place to enter all their contact information and we figure out what type of data is what. (Then you can 1-click call or email this person).

Is taking a string and deciding if it’s either a phone number, email address, or URL particularly hard? No, but it’s “hard enough” that most CRMs and address books don’t do it, and we wanted to take the extra time to make our users’ lives easier, even if they don’t notice it.

2) Pasting contact email address

A recent iteration on the contact form was improving a fairly common scenario where you had email from somebody and wanted to save their email address onto a contact. Many email clients give you a string like: “John Smith” <john@example.com> when you copy the address. Originally if you tried to enter that as an email address in Close.io it would complain about it not being in the simple email format like john@example.com.

Now, when you paste that text into the email field we’ll automatically pull out the email address part and fill in the contact’s name field if it’s blank:

image

Again — not particularly difficult, but something most software doesn’t do. This is the type of magic that many users won’t even notice or think twice about, but helping users avoid validation error messages is as much of a benefit as any new feature you could make.

3) Zero configuration email sending

The first few times you try to send email in Close.io, it’s as simple as clicking the big “Email” button on a sales lead, typing a message or choosing a template, and clicking send. We already know your email address when you signed up, and we use our own Mailgun account to send email as/from you, so that it just works.

We do put a cap on the number of emails you can send without entering your own SMTP credentials (which will also give you better email deliverability), but for users just checking out Close.io, it’s one less configuration step in the beginning.

4) Magic email tracking from all your email clients

Forget having to BCC/Foward all emails with sales prospects to some random CRM email address. Plug your IMAP credentials once into Close.io and we automatically track your sent and received sales emails regardless of how/where you send them.

Much more to do…

We have a long list of other little UI/UX improvements we need to make, but hopefully this was enough to encourage you to think twice about the tools you’re using and discover opportunities for improvement.

And if you’re a software developer… be sure to sweat the details – it takes more time, but it makes for happier users!

We’d love to hear your reactions… follow @closeio and @philfreo

– Phil Freo

Comments off

The problem with pull requests / code reviews

We use git and GitHub’s Pull Requests fairly heavily in developing Close.io sales software. My main problem with pull requests as code review is that it focuses my attention too much on the specific lines of code added/removed/modified, but not enough on the context of where they were added/removed.

Read the rest of this entry »

Comments (7)

End of 2012 Review

At the end of a year I like looking back and seeing what I’ve accomplished and what new technologies I started working with in the year. Here’s a little summary.

Read the rest of this entry »

Comments (2)

Manage GitHub Issues milestones in Trello

In doing product management on an engineering-led project, GitHub Issues rock. The killer features are that it’s a) really simple, b) tightly integrated with code (you can reference/close issues via commit messages), and c) facilitates discussion of issues just like it does of code.

What GitHub Issues suck at is being able to get a high-level view, where you can see more than 30 issues at a time, and broken out by milestone or by person. (You can only filter to see issues for one milestone or one person, but not easily move multiple issues between them.)

I’d really like to see a Trello-style interface for managing GitHub Issues. Some very limited integrations exist, but what I’m looking for would let you quickly move issues around between milestones. This would help plan a product roadmap and be able to visualize what the upcoming milestones look like in one place.

Read the rest of this entry »

Comments (6)

How to unit test AJAX Requests with QUnit and Sinon.JS

We write QUnit tests for Close.io, a big Backbone.js app, to help avoid introducing bugs. Pretty quickly when testing front-end JavaScript code you’ll have to deal with how to test asynchronous callbacks and especially code related to AJAX/XHR requests and how their responses are handled. Here are some basic examples of how to use Sinon.JS to handle this.
Read the rest of this entry »

Comments (3)

Mac Software I Use

I just got a sweet new MacBook Pro Retina – way faster than my old MBP. I wanted to do a clean install rather than restoring from a TimeMachine backup, which meant reinstalling software and manually transferring stuff over that I really needed. I kept a list…

Read the rest of this entry »

Comments off

Uploading static assets (CSS/JS) to S3 for CloudFront CDN

For a new Backbone.js + Flask project I’m using grunt + grunt-contrib, RequireJS’s r.js, Flask-Assets / webassets for static file (LESS/CSS, JS) compilation. But I needed a good way to get my nicely optimized static files onto a CDN and serving proper HTTP headers.

Using the excellent s3cmd tool, here’s what I came up with.

This example will break for browsers/proxies that don’t support gzip, but this is fine for my needs. Any other solution would either require a custom origin web server or writing different filenames in HTML depending on the request coming in. But since I want to use S3 as my origin this is the easiest/simplest solution.

Since all assets are “built” with a md5 version number hash in the file name, I want far futures headers to cache permanently.

Comments off

How to upgrade MacPorts to OS X 10.8 Mountain Lion

This weekend I upgraded OS X from Lion to Mountain Lion. Documenting steps I had to do to get all my development environments working with MacPorts.

Steps:

  • First installed the latest XCode via the Mac App Store
  • Downloaded/Installed Mountain Lion
  • Launched XCode one to so I could agree to license, etc.
  • MacPorts also requires the XCode Command Line tools which are a separate install. Inside XCode preferences: “Instead, they can be installed optionally using the Components tab of the Downloads preferences panel as shown in” (source)
  • Had to run “sudo xcodebuild -license” after getting “Error: org.macports.build for port libunwind-headers returned: command execution failed”. Run this, scroll down, type agree.
  • sudo port selfupdate
  • sudo port upgrade outdated
  • Everything finished and worked properly except MongoDB. Currently there’s a bug and the easiest/best work around seems to be just manually installing the latest stable OS X version from http://www.mongodb.org/downloads and manually copying the binaries into /opt/local

Comments (4)

« Previous entries Next Page » Next Page »