Our Billing and Financial Aid users have probably noticed by now that we've re-jiggered Populi Billing a little bit. Here's a rundown of the new features.

1. The new Chart of Accounts lets you define and manage all of your accounts directly, improving on our previous use of "external accounts" which reconciled Populi with your main accounting package.
2. Piggybacking on that, by entering all your bank accounts as Asset accounts, you can record exactly where each student payment should be deposited.
3. For deposit reconciliation, Populi's new General Ledger report lets you choose a custom timeframe and see the total debits and credits for that period. Assuming that payments have been recorded in the appropriate accounts, you can verify the amount of tuition/fees you're taking to the bank.
4. Financial Aid awards are now linked to Liability accounts, allowing you to more accurately trace the flow of Financial Aid money from the source to the student.

Other, numerous improvements to Billing mean that Populi, used in concert with a good fund-based accounting package, will more fully manage your General Fund—in particular, your Accounts Receivable. And with the automation between Academics and Billing going even further, hopefully your day will be that much easier.

Our development guys put in a late night last night to push a number of updates live. This is a pretty far-reaching release, encompassing everything from minor interface-jiggering to substantial hardware updates. All in all, Populi is now more stable, quite a bit swifter, and more usable than it was the last time you logged in. We've got some of the higher-profile items listed after the jump, and a full list available for our users to read in our help system. Some of these updates trickled out over the past few weeks in response to customer needs, so maybe some of this is old news. Anyway, without further ado:

As mentioned before, we've adopted a Privacy Notice, Copyright Policy, and Terms of Service which govern the day-to-day use of Populi.

New servers: Our page hits have been doubling every month, and we’ve been experiencing some growing pains. So we've obtained a new server cluster which considerably improves our speed and stability, while also affording us some much-needed room to grow. These upgrades included a brand-new, dedicated Email server. Email is a storage and performance hog, and putting it on its own server substantially streamlines the workload for our other servers. Email's a lot snappier, and so is Populi as a whole.

Unicode Support: Need to write an email in, say, Hebrew? Now you can. We've added UTF-8/Unicode support to Email (and throughout Populi, for that matter).

We've beefed up course cloning so it better reflects and enables the kind of usage our customers need from this feature. Faculty can now clone courses right from the course instance page, with the ability to clone only specific items. Even bigger, Registrars can use the new Import Courses feature to clone some or all courses from one academic term to another. Populate an entire term with courses in a few clicks. You can even include course data (assignments, reading lists, etc. ... everything but faculty, students, and schedule) in the import.

Export your Gradebook to Excel, and import a .CSV database/spreadsheet into your gradebook. This means you can, among other things, import Scantron test scores straight into Populi.

Again, check the November 23, 2009 Release Notes in the help system for a complete list of updates.

If you're in the habit of scrolling all the way to the bottom of the website, you probably noticed three new pages: our Privacy Notice, Copyright Policy, and Terms of Service.

The Privacy Notice covers this website and Populi itself. It elaborates on this basic idea: "You have a right to keep Your personal information private and You may reasonably expect us to respect that right and use Your information responsibly." In other words, we're not gonna sell your email address or turn it over to spammers for any other reason, and the only information we gather from you (that you don't actively volunteer) is anonymous stuff like what pages you looked at.

The Copyright Policy is in place in the event that a copyright owner discovers that a Populi user has infringed upon the copyright inside the program somewhere and wants to complain to us about it. It describes the process such a one must go through, who to contact, and what information is required of the complainant. To sum it up, send us an email with the details, and we'll see what we can do.

The Terms of Service are probably the most important of the three new pages. If you're a college wondering what signing up with Populi gets you into, just read them. If you're a Populi user curious about our relationship, have a look—the Terms define it pretty clearly. Some of the language is stentorian and scary-looking (some parts, apparently,  are legally required to be in ALL CAPS), but all it does is codify the arrangement between us and the people we serve. We were not frowning at any point during the writing of the Terms.

If good fences make good neighbors, then good agreements make for good business. Agreements spell out protections, describe who does what, when and how it should be done, demarcate responsibilities, and limit liabilities (among other things). In case of a dispute or disagreement, they provide a basis for appeal and give the wronged party recourse before the law. Almost every company we can think of has Terms on their website: 37signals, Zendesk, Freshbooks—even the Starbucks website, which just tells you where you can buy their stuff.

And again, it bears repeating that the Terms don't introduce anything substantively new to our existing customers and users (to whom these apply). They just put into words things that are, by and large, understood and accepted already.

If you have any comments or questions about any of these pages, feel free to get a hold of us.

When it comes to security, we would happily agree with the 37signals team’s recently-adopted dictum, "Perfect security is a moving target." Any company that thinks and says otherwise has another thing coming—and so do their customers, unfortunately.

The first page of this Campus Technology article describes what’s at stake: colleges collect “more sensitive data about students than a Fortune 500 company does about customers.” The article goes on to describe why this is such a problem at the University of Nebraska:

"Unfortunately, confidential information at many institutions routinely leaves the campus in a steady stream, not because of hackers, but through accidental e-mail exposure by users, most of whom are ignorant of good data security policies. [F]aculty and staff . . . were routinely sending e-mails with confidential data including Social Security numbers, spreadsheets with credit card numbers, and other sensitive items."

Later in the article we learn that even outside vendors were doing the same thing.

The University bought software from Symantec to help their IT staff zero in on problem users, and it brought all sorts of lapses and breaches to light. Nonetheless, late in the article we read that, even with the software in place, a user still wrote an email to a staff member, saying, “’I was a little bit hesitant to include Social Security numbers in an e-mail, . . . but as long as you delete this message when you are done, we should be fine.’”

Why is perfect security a moving target? Because of people. People do things like fall for phishing scams, write malicious code, tape their login info to their monitors, design an SIS using SSNs as identifiers... sometimes people even do something like "misplace information for over 103,000 students". Security technology can ameliorate some of these problems, but as the University of Nebraska learned, people will work around it as soon as they figure out how—whether it's users coping with a new software hassle, or intruders having a look through an otherwise unseen security hole.

Software security requires three basic disciplines. The first is a vigilant and proactive posture against software intruders. This is a necessarily defensive position; hackers seek out weaknesses and then invent ways to exploit them, and developers can't really pre-empt attacks that haven't been invented—or tried—yet. When a threat emerges, good developers stay nimble, locating the holes in their code and releasing security updates, pronto. That, incidentally, is one of web-based software's chief strengths: turnaround time on updates is far swifter, more effective, and less burdensome to users, than for any kind of locally-hosted software (whether a local server or a desktop).

The second is designing software so it incorporates good, basic security practices wherever possible. Part of this effort goes towards coaxing users into good habits—like requiring complex passwords. And the rest of it guards against common problems, attacks, and disasters—things like modern browser support, SSL encryption, regular backups, active monitoring, password-hashing. These measures are written into Populi's DNA, as it were, but you'd be amazed how much enterprise software ignores some of these basic things.

The third, and most important—because it can undo all of a developer's work in a matter of seconds—is for users to develop good habits themselves. A developer can require a complex password, encrypt the transmission, and run it through a hashing algorithm... but if a user goes and sticks their password to their monitor, well, why bother with secure passwords? If someone leaves for a lunch break with their account open on a public computer, why restrict access to login info? If someone sends sensitive spreadsheets to their personal email to work on them from home, why build a web-based application?

The University of Nebraska's experience underscores that security technology, while certainly useful and worth the investment, almost pales in importance to how much your people's software habits matter. That seems to be the one constant in software security, and there's no sign of that changing. We like to think that we run a realistic, open-eyed company here. We’reivacy of the sensitive data we help you manage will still rise and fall on the vigilance and habits of our users.

We built Populi to give small colleges an information system that fit them properly. Homegrown might fit the budget. Enterprise might fit some of the functions. Neither really fits the needs and proportions of schools that need good information but don't have resources to lavish upon it. Many of our customers have migrated over to Populi from homegrown systems, and have been reaping the benefits. Central Baptist Theological Seminary, of Plymouth, Minnesota, came over after using one of the big systems for several years. We spoke with CBTS' Registrar, Eric White, about the experience. The short version: "It's gone very well," said Eric.

Eric took the position with CBTS in 2002. As  Registrar, he had more contact with the Seminary's outdated enterprise information system than anyone else at CBTS. Fortunately, his background in IT and basic programming equipped him to deal with it.  So for several more years, he made the system work for their admissions and registrar offices. But it was challenging. “Their database was messy, and the vendor was very slow with development...” Eric told us, “...not to mention, customer support.”

For instance, “Online registration almost worked.” Eric said, “Students could register for courses online, and the system produced an enrollment spreadsheet that could be uploaded to the database itself. But the file upload never worked and we had to enter the data by hand. And that effectively eliminated the benefit of having students register online.”

Degree Audits were as pleasant as unanaesthetized dentistry. Eric put it simply, “I wonder sometimes if our old system was built for K-12 schools. Degree audits would have been easier with a pen and paper than to make the system do it.”

Eric explored the options to make the software work for the Seminary. The software vendor sold an upgrade that would have ameliorated some of the issues, but there was a pretty big catch. “An IT department is expensive, and that is what it would have taken to implement the upgrade.” With the system too old and clunky to work for CBTS—and too costly to update—Eric took a look at the other systems on the market. Of the systems that might have worked for the Seminary, most of them were in the six-figure range, and thus were out of the question for CBTS.

But when he saw Populi, Eric saw something that fit CBTS' needs and budget. “I found Populi to be very user-oriented, and the database—well, you guys know what you're doing. And what's more, it was in our price range." Populi's price wasn't the only cost-saver—since it's hosted off-site, the Seminary didn't have to figure in any ongoing expenses for new IT hardware or personnel. Implementation fit the bill, too. Populi staff imported the legacy system's databases, cleaning up and simplifying the bloatier parts of the database, at no extra charge to the Seminary. The result was a lither dataset in a much more usable system than before.

Eric has been very pleased with Populi. One reason is that it just works—the online registration and degree audits, for instance,  don't make him do all his work over by hand. Another is the customer service. "It's a really easy system to use, so I don't have to request help that often. But when I do, I’ve been impressed with the support and the quick turnaround on my requests."

Cleaner data, easier workflows, lower costs: CBTS' experience illustrates how small colleges can get a better fit with Populi.

We occasionally like to share snapshots of how Populi is easing the workload for our customers. We recently spoke with Daniel Humphreys at Zion Christian University in Clearwater, Florida, who uses Populi to share information across an international network of ZCU-affiliated colleges.

It started with ZCU's Global Network program which connects the University with Bible schools, missionaries, and churches that wish to use ZCU's curriculum to train their own students. Affiliates have access to counsel, coursework, textbooks, and other resources; further, they offer their students certificates, diplomas, and degrees issued by ZCU.

Well, it's difficult enough to keep track of your own students' degree audits. But put yourself in Daniel's shoes and imagine doing so for students at other institutions around the world! Starting off with a homegrown database, and later moving on to an unwieldy academic software tool, Daniel was stuck manually entering all sorts of academic information for each student—students located in places all around the world. You can imagine the complexity of this very routine task.

Things have gotten a lot simpler since he started using Populi.

Once ZCU's course catalog was migrated into Populi during implementation, Daniel was free to set up all of ZCU's degree requirements up front. With Populi accessible via the web, he simply gave access to designated users at ZCU's various global affiliates. They then entered their own students' information, and Populi handled the rest. As students completed courses and earned degree credit, Populi kept track of it all—with no effort on Daniel's part—on each student's Degree Audit. Now Daniel—not to mention the students and their advisors—can see any student's completed courses, what remains to be taken, and how close each student is to earning their degree, all with one click.

The Degree Audit has saved Daniel a ton of time, which is what Populi is all about.

If you'd like to share ways that you are using Populi, please let us know. We'd love to hear from you.

For more information about ZCU's Global Network, check out their website.