I’ve been wanting a standing desk at home, ever since our old Elastic office had standing desks. The key though is getting it to be the perfect height, and not spending a fortune. After some careful measurements I determined that my standing desk surface should be exactly 40″ from the ground, so that my arms at ~90 degree angles would fall perfectly on them when I’m standing (I’m 5’6″ or 5’7″).
I recently had to look at two different legal documents (PDFs) that were mostly the same, but I wanted to spot any differences.
My first attempt was to install the cross-platform GUI tool DiffPDF. This mostly worked but was annoying because it seemed to basically only diff within a page – so if your paragraph bumped to another page in the new version of the document, you couldn’t really spot changes.
Then I installed pdftotext with macports: “sudo port install poppler”. From there you can diff the two text files, like normal.
However the format was still not ideal in the standard FileMerge, “diff” or “vimdiff” programs (even with ignoring whitespace) because it would show an entire paragraph changing even if just one word did. And it would also show issues in all the places where text wrapping happened on. different words
So finally I found a couple other useful tools, wdiff (for word-by-word rather than line-by-line comparisons) and colordiff to colorize the output. Installed with: sudo port install wdiff colordiff. And threw in a trick to avoid needing the .txt temp files.
$ wdiff <(pdftotext old.pdf -) <(pdftotext new.pdf -) | colordiff
Beautiful! Now I can easily spot the specific words, nicely colored, that have changed.
Only thing I would improve is for it to print only the lines with changes (plus 3 context lines above/below), rather than all lines.
I’m working on invoice/receipt generation for Close.io and wanted to create simple PDFs using nothing but HTML.
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:
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” <email@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 firstname.lastname@example.org.
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:
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!
- Phil Freo
On my goals list for 2013 was to write an eBook of some sort. When I was approached to join some other Backbone.js contributors in a “book sprint” to write a book on developing a Backbone.js application, I happily accepted!
The process went fairly smoothly (all things considered, when 5 people all write a book at once, mostly over a weekend). There were some challenges with timezones and schedules, but overall the team did a great job getting it done.
We started by building our sample project, Hubbub (a GitHub Issues tracker in a Kanban format), upon which we’d base the book. We wanted to build an app that was more complex / real-world than the typical localstorage Todo list example apps out there. You can see the final project live here.
You can read more about the book on the publisher’s site here: Developing a Backbone.js Edge, or buy it from one of these locations:
Thanks to Casey Foster, Aidan Feldman, David Tonge, and Tim Branyen for co-writing it with me, and for Troy Mott for organizing the book sprint.
And now for some SEO love… I hope this book will become one of the best selling Backbone.js tutorial books out there!
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.
Originally published on the Close.io blog.
In creating Close.io software for salespeople, we rely on a number of other startups and services to do what we do. While there are alternatives to using each of the following, we have chosen them for specific reasons because we think they’re the best.
The common theme is that these services allow us to move faster and have better insight into our business. We could live without any of them, but it would mean slower iteration and less innovation.
We’ve been getting some great press and feedback since launching Close.io software for salespeople.
- GigOm: Close.io is a social context for sales communications
- PandoDaily: Elastic launches Close.io, sales software designed by salespeople
- Forbes: Y Combinator-Backed Close.io Launches Sales Software
They’ve got a couple good quotes from me in the PandoDaily article.
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.
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.