DC PostgreSQL User Group, June 2018

Many thanks to Stephen Frost of Crunchy Data and Brad Sneade of LiveSafe for inviting me to speak about my book Practical SQL at the DC PostgreSQL User Group in early June! The night featured good food, fun conversations, and tales from me on how a journalist came to write a book about PostgreSQL and data analysis.

I shared tips I picked up along the way on using PostGIS, crosstabs, statistics functions, and Python within PostgreSQL—all topics I cover in the book.

The DC PostgreSQL Users Group features a warm, inviting atmosphere. Check out its Meetup page and consider stopping in if you’re in the region.

A few tweets from the evening:

Next time, I will bring a bigger screen …

‘Practical SQL’ Available in Bookstores!

I’m thrilled to say that Practical SQL: A Beginner’s Guide to Storytelling with Data is officially released today! The title is published by No Starch Press and distributed via Penguin Random House, which means you can find it wherever books are sold.

From the description:

Practical SQL is an approachable and fast-paced guide to SQL (Structured Query Language), the standard programming language for defining, organizing, and exploring data in relational databases. The book focuses on using SQL to find the story your data tells, with the popular open-source database PostgreSQL and the pgAdmin interface as its primary tools.

Practical SQL Anthony DeBarrosMuch of Practical SQL is based on the years I spent in newsrooms, including USA TODAY, poring over data sets in search of a story. SQL-driven databases were a central part of my toolkit, allowing me to organize, clean, and find meaning in data sets ranging from a handful of rows up to millions of records across dozens of tables. Today, the language is still widely used, powering thousands upon thousands of software applications.

Please check out the bundle from No Starch that includes a print copy plus ebook versions (PDF, .mobi, and .epub). No Starch Press is a thoughtful company that supports the open source software community, so you can feel good backing them. No Starch often runs promotions, so follow the company on Twitter or get their newsletter for deals.

Of course, you can also order the book through Amazon, and copies should be on shelves at Barnes & Noble or your favorite independent local bookstore.

In coming weeks, I’ll announce some special giveaways, sharing tips from the book, and booking some in-store appearances. Stay tuned.

‘Practical SQL’ Book in Early Release

My first book, Practical SQL: A Beginner’s Guide to Storytelling with Data, is out in early release from No Starch Press starting today! If you pre-order from No Starch, you can download the Introduction and first four chapters now. You’ll get additional chapters regularly until the final version comes out in February 2018.

Practical SQL is for people who encounter data in their everyday lives and want to know how to analyze or transform it. The book covers real-world data and scenarios, from analyzing U.S. Census demographics to the duration of taxi rides in New York City. I’ve aimed the exercises at beginning SQL coders, and all the code and data can be downloaded via No Starch’s site.

That database you’ll use is the free, open-source PostgreSQL, along with the pgAdmin 4 graphical user interface. We cover all the basics you’ll find in standard ANSI SQL along with PostgreSQL-specific features such as full text search and GIS.

More to come as additional chapters hit early release!

NoVa-Py Talk: Building a Python Package

One of the most popular uses of the API for DocumentCloud, the document research/publishing platform where I work, is to bulk-upload hundreds or thousands of documents. People usually hack their own code together to do this, sometimes using the Python or Ruby wrappers for the API.

After talking with users and hearing their thoughts about the workflow — a desire to have a record of each file’s URL once uploaded, for example — I saw an opportunity to add some luxury to the process. A couple of months, a lot of research, and a few bruises later, I had my first Python package: pneumatic.

pneumatic does a few things to make life easier. It grabs information about each uploaded file and saves it in a SQLite database, which you can dump to csv. It uses Python’s multiprocessing module to try to add some speed (recognizing that this is a network-bound task). And it scans all subfolders for files, which is handy when you obtain a collection of files organized that way.

Learning about Python packaging was as much a part of the project as creating the library itself. The folks at the Northern Virginia Python Users Group were kind enough to invite me to share what I learned recently. Click through the title card to view the slides.

BaPP

 

A Hierarchy of User Experience Needs

Remember Abraham Maslow’s hierarchy of needs? In the 1940s, the Brooklyn-born psychologist plotted categories of human motivation on a continuum. He theorized that our first desires are to secure basic physical needs, such as food and shelter. Once we satisfy those, we’re free to seek higher things. Think love and belonging, or well-being.

The people who use software products also have needs, and they too come in something of a continuum. This fact’s not often well-articulated by users, but it shows up in bug reports, support requests and casual conversations. Let’s call it a Hierarchy of User Experience Needs. Consider these statements:

  • “Tried logging in and got an error message.”
  • “An option to customize menu colors would be great.”
  • “How are you planning to handle integration with [Hot New Service X]?”

If we pay attention, we can place each of those comments along a continuum. Some reflect needs that fall toward the basic and immediate; others are more aesthetic and emotional. Over time, if feedback bunches up at any point, that’s a cue to address that part of your product with an appropriate response.

As a proposal (while not ignoring all the other takes on the idea), let’s explore a hierarchy that plots these needs:

Vision
Partnership
Beauty
Speed
Function
Invitation

Here it is in detail, starting from the bottom:

1. Invitation: The Product Welcomes.

Let’s start at the life-or-death end of the hierarchy. Before users sign up, before they download a single file or enter a credit card, they need a gut-level feeling about your product: assurance that it’s going to work with them and for them — not against them.

They’ll know just by exploring. Is the interface simple or jumbled? Is there ample documentation? Is it written for brainiacs or for everyone? Does the cost reflect the value of the problem your product solves? Will you give help?

Hints that your product fails here include a level of engagement that falls off sharply from initial interest. If something’s turning people away before they really get started, dig to find out what that is.

2. Function: The Product Works, or Else.

Available, functioning software also resides at the food-and-shelter end of user needs. Throw a roadblock here — a site that won’t load, a procedure that hangs, results that are inaccurate — and not much else matters. Users will exit towards an alternative.

Feedback at this point on the continuum usually carries a desperate tone — some form of, “Help!” But be on the lookout for low-grade annoyances that surface in conversations such as complaints that a search didn’t return expected results or that it’s nigh impossible to access a menu. Not all product failures are equivalently spectacular, but it’s perilous to ignore even small ones.

3. Speed: It’s a Need.

It’s amazing that a spinning beach ball can become annoying after about 4 seconds, but it does. The best of the Internet is fast, and that’s the bar users expect — that a product will do its thing Right Away. So, if your mapping application’s data layer takes forever to render on top of base tiles, that’s disappointing. If a search takes 20 seconds to return a query, that’s a lifetime compared with the expectation Google search delivers.

Optimization is hard, but at this side of the Hierarchy of User Experience Needs, where fulfillment is still more life-and-death than nicety, it’s worth watching. Recently, a fast food place opened in our neighborhood, and after two tries in which a drive-thru purchase took 20 minutes, we’ve started saying, “Let’s find something else.” Don’t let your users do the same.

4. Beauty: The Product is Pleasing.

Once you satisfy a user’s basic needs for fast, functional, easy-to-grok software, they can look for the product to meet higher-order, less-tangible needs. One is a simple desire for the product to delight. More than the simple friendliness expressed in the basic Invitation need, at this point in the hierarchy users want to have their senses tingled.

This means your product pays attention to how it looks, how it interacts and communicates, and even how it sounds. If possible, it should evoke some sense of wonder. Nothing should be jarring or too raw (unless that’s part of the appeal). The team message client Slack is an exemplary model here.

5. Partnership: We’re In this Together.

Heading towards even-higher needs, the next is a sense that the team behind the product is at the user’s side, sharing their concerns and invested in their success. Call it empathy.

This need’s expressed less in complaints and more in desire. When users talk about wanting to hear from the team, whether in a forum, on Twitter or via a blog post, that’s a tip they’re seeking connection. Even users of a wildly successful product will chafe against lengthy absences of communication from the project’s owner.

Miss meeting this need and you miss an opportunity for building loyalty and lasting bonds.

6. Vision: We’ll Grow Together

This final need is about hope. No one using your product really wants to be in the same place next year, doing the same things and trying to solve the same problems. (Even if they think they do, they don’t.) In this top-most part of the Hierarchy of User Experience Needs, users join their personal aspirations with those of the product in hope of growing together.

To meet this, product owners must communicate vision. Where is the product going? How will it anticipate next year’s needs? How has it done so in the past?

Vision is as critical to retaining customers as the sense of Partnership. Fulfill it, and your users will have confidence to renew subscriptions, suggest your product to colleagues, and resist the temptation to defect to some other shiny object.

Your thoughts?

Add your ideas and share what you’ve learned!