One of my tweets is featured in an article on Mention.com:
Check it out!
One of my tweets is featured in an article on Mention.com:
Check it out!
I built a quick mashup/integration between two services that I love using, that I thought would be “better together”. It’s live at ArticleListen.com.
I use Pocket to save a queue of any article (blog post, news story, etc.) that I see on Hacker News, Twitter, Facebook, etc. There’s a web & mobile browser extensions for saving articles you see, and Mac & iOS apps for reading these articles later all in one place, even offline.
Using Pocket can be good for productivity because you may see a headline that interests you, but you really shouldn’t be reading it now. By saving it to Pocket you know you can easily find and read it later. I’ve got a few hundred articles saved from over the past couple years. I often read a few articles at a time, but they still build up.
I also use Umano, which is a service that has professional voice actors record narrated articles from across the web. It’s perfect for commuting. Many of the articles are only a few minutes long, so even a quick trip to the store or walking to the train can be enough to hear an article or two about something that interests you. Tech, current news, etc.
Umano has some article discovery built in (a “popular” page and a way to see which articles your Facebook friends on Umano liked), however they have thousands of articles already recorded and so finding what you really want to listen to is still difficult.
Then I realized that all the articles I wanted to read or listen to were already saved in my Pocket queue, so during part of a couple weekends I put together this site to do a few things:
Umano does have a Chrome extension (and generic bookmarklet) for “voting” for articles, but I wanted my primary queue to be something like Pocket, which is better built for general purpose article saving, I didn’t want to have to save every article to two places, and I mostly wanted to listen to the articles that were already in my queue.
Check it out: ArticleListen.com
Feedback is welcome.
Built using Python/Flask and Bootstrap.
Future improvements I’d like to make: It should continually monitor a Pocket queue for new articles ongoing – looking for matches and adding them to Umano without any user interaction. At the moment you just have to login to the site occasionally.
I just finished reading “The Elements of User Onboarding” by Samuel Hulick. I discovered the book through the excellent site UserOnboard.com which has chronicled every screen in the onboarding process of several web and mobile apps and added great commentary (positive & negative) on each screen.
If you help make a web/desktop/mobile app, I highly recommend going through a few of these teardowns, as they alone will make you re-think some parts of your onboarding process. These teardowns together with the book have given me lots of great ideas for drastically improving the liklihood that a new user of Close.io will become successful.
For each chapter, I wrote down a brief summary or simply something that stood out to me. By all means, this isn’t a replacement for getting the book – but a teaser and reminder to myself what I read!
Sales 4 Startups published an interview with me about Close.io.
Interview: Phil Freo, Engineering Lead @Close.ioSales4StartUps: Tell us about the Close.io story. How was it started? What problem were you trying to solve?
Phil: Close.io was developed as an internal product to make our own salespeople at ElasticSales more efficient. Our company was doing sales for a bunch of companies (with different types of sales processes and needs) and through all these difference sales campaigns we recognized a lack of good software geared at the day-to-day tasks a salesperson faces. Our team needed to be able to make many phone calls quickly, send more emails, and see a history of sales activity for any given lead without having to do a bunch of manual data entry, and surprisingly none of the solutions we tried seem to actually be designed to make salespeople’s lives better in these ways.
After several of our customers asked if their salespeople could use our software (since they saw our productivity improvements from it), we decided to focus on productizing it, and Close.io was born.
Coinbase is one of the best Bitcoin related sites/services. They’re certainly the easiest way to buy or sell Bitcoin if you have a U.S. bank account. When I saw their Bug Bounty program where they offer $1,000 USD worth of Bitcoin if you find a security vulnerability, it improved my trust in their security, but of course also made me want to look for security bugs…
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!