We just updated our Privacy Policy.

Previously, Section 8 (our policy towards children) included a blanket statement indicating that we do not collect information about children under 13—and that if we inadvertently did, we would delete it. However, we realized that this statement went a little too far for our customers. Many of you actually do keep records of children under 13—whether as relatives of faculty or staff, as prospects, and sometimes even as students. Not wanting to commit ourselves to deleting customer data that you're allowed to collect, we wanted to clarify the policy regarding information about children under 13.

So, the long and the short of it is that...

• It's our responsibility to delete information about children under 13 that we may take in through this site (populi.co).
• It's your responsibility to take all appropriate precautions with such information that you manage through your school's populiweb site.

If you have any questions about any of this, please don't hesitate to contact us.

Expanding on Brendan's post about designing for the “job to be done” rather than starting with a visual design, Alan Klement introduces us to the idea of using "Job Stories" instead of "User Stories":

Summed up, the problem with user stories is that it's too many assumptions and doesn't acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there's no room to ask 'why' - you're essentially locked into a particular sequence with no context.

The distinction may seem subtle at first, but it's easy to make the mistake of designing a particular interface or workflow to meet the needs of one specific “user”, when it will actually be used by different people in different roles seeking different ends. Writing a story about the job someone wants to do—rather than assuming what kind of user they are—should lead to designs that work better in the real world.

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

We've seen something like this at work in our Feature Request Forum. Users suggest features based on their own particular user stories (nothing wrong with that). But it's not until other users pile on with their own suggestions (and user stories) that the job story emerges. We've found that it often takes multiple perspectives on the problem for us to identify the job to be done.

Now available on the Students table: the "Include unfinalized courses" toggle. When checked, it factors in-progress grades from your students' unfinalized courses into the Term GPA, Cumulative Units, and Cumulative GPA columns. When unchecked, it backs unfinalized information out of those columns, giving you the same figures formerly available only on individual transcripts.

Over the years we've tuned the Students Table to show as much real-time information as we could—thus, Cumulative GPA factored in student performance in unfinalized courses. But some users informed us that they also need the Table to give them snapshots of where the students were starting from in a given term... so that unfinalized info was getting in their way.

Thus, the toggle. Now you can get two perspectives on all your current students with a single click.

Inside Intercom's The Dribbblisation of Design lambastes software designers who start with the visual design of their program without first considering the underlying layers of a well-built app.

Much of the product design work from job applicants I’ve seen recently has been superficial, created with one eye towards Dribbble [an online design community]. Things that look great but don’t work well. Perfect pixel executions of flat design, but work that doesn’t address real business goals, solve real problems people have every day, or take a full business ecosystem into consideration.

The best software design starts with the unglamorous stuff: what is the user trying to accomplish? How can the software help them do that? How can the software explain how it works to the user?

This way of thinking owes much to Clayton Christensen, a Harvard Business School professor whose ideas on management and business are summarized in his "Job To Be Done" framework.  JTBD leads with this question: what job is the user hiring this product/service to do? It has a surprising range of applications—software, household products... and even milkshakes. And there's no doubt that it has plenty of uses in designing college management software.

Sequential payment numbers

Transactions have them. Invoices have them. And now payments have them: sequential payment numbers. Every payment in your system now has a sequential number based on the order in which it was entered.

In the past we referred to payments solely by their receipt number—random alphanumerical strings like #4d5c6ce05a71a, #8b8x2nn092l3, or our personal favorite, #56oc092ma27z. But keeping track of payments like that is something better suited to computers than people. Thus, the change.

We ran a script to give every payment in your records a sequential number, starting from #1. And from here on out every new payment gets the next number in line. You can still find receipt numbers on the end of the online receipt URL shown on a given payment:

Additionally, the Financial search now checks both payment and receipt numbers, so historic receipts are still easy to look up. If you have configured a custom receipt template, contact Populi customer support to have us replace the receipt number with the new payment number.

Aging report

In July we released an Aging Report. You can find it in Billing > Reporting > Aging. It shows all of your students' unpaid invoices and how long ago you billed them, together with information about pending financial aid and last payment received.

Time tracking in courses

A new tool in Course > Reporting shows how much time your students spent in your courses on a given date.

Email bounce & spam notifications

Awhile back we released a "deliverability problem" status for email addresses. The status was triggered when email was returned as undeliverable to that address or marked as spam. Now we notify you (via automated email) when you send an email that returns a bounce or spam report.

Release notes

These are some of the highlights from the past few months of releases, which has seen a steady trickle of incremental improvements to Populi. Complete release notes are compiled on a weekly basis in our Release Notes forum, so make sure to keep an eye on that to see what we put out there.

Prospective customers sometimes ask us to sign papers that would—whether instead of or alongside our own legal documents—govern our business relationship with them. Schools with the cash to have lawyers draft stuff for them are lucrative prospects, and we should be happy sign whatever if it'll bring them aboard.

But we decline to sign every single time.*

Why? What could Isaac's signature on another piece of paper do to our business?

The answer is, We don't know. Some of these documents outsize our own by an order of magnitude. They're written by lawyers working in other states. They contradict or negate our own Terms. They oblige us to requirements totally foreign to college software. For all we know, they could cripple the way we do business, and so make things sticky for all the rest of our customers.

They're just full of potentially expensive unknowns.

We do know this: our relationship with that customer would be very different from what we enjoy with everyone else. And that's just not worth it for anyone.

The Terms of Service define our relationship with our customers, and we want that to be a relationship of trust, adaptability, and common sense. The Terms protect both Populi—our property, employees, and business—and our customers: your data, your rights, and your enjoyment of the service. They permit our ongoing release of new updates that improve the value of the service. They let us update the Terms so no one is bound to what worked in 2008 but doesn't in 2013. And they give us the leeway to not enforce the Terms in a given situation—because we wanted the right to not be hardnoses about everything.

But it's not just the relationship that's valuable. It's also the fact that the relationship is the same for everyone: every school and every user is on the same footing as every other school and user. We cherish that. It's simpler in terms of administration—managing different agreements with different customers just doesn't scale. It's simpler in terms of knowing what to do when situations arise—support issues, pricing questions, data challenges. And it's simpler in terms of development—we're not bound to develop Populi to satisfy the requirements of someone's unique contract.

In a nutshell, we like the Terms of Service because we like the relationship they foster between us and our customers.

And that's why you won't catch Isaac's signature on some other piece of paper. Trust, adaptability, and common sense are just too valuable to this relationship.

* Do pardon the rhyme.