Design and Development

You’ll now find that all Ronin accounts come with a simple expense tracking feature. It’s straightforward and the goal is simple: To allow you to track expenses incurred on behalf of clients and re-bill them during invoicing.

The interface is self explanatory:

You can easily add new expenses and view them under the “Expenses” tab.

Where it gets interesting is when it comes time to invoice your client, you’ll find that Ronin automatically detects any outstanding expenses that have not been invoiced:

Along with time tracking, we hope this provides a comprehensive tool for tracking what you’re owed so you never have to go through the trouble of under-invoicing.

As a team grows, it can often become more difficult to track the total hours spent in the last week or month how much much of it is left to bill. The more readily available this information, the easier it is to make sure invoices are sent at regular intervals.

For example, do you know off the top of your head how many billable hours you or your team has put in this week? How about how many of those hours are left to bill to your clients? Do you know how much money you’re leaving on the table on a monthly basis?

Ronin helps answer these questions at a glance with our new Projects dashboard numbers. The screenshot below really summarizes all you need to know about it:

What’s also neat about this dashboard is that it shows you your oldest unbilled hours. For example, if you know you have $1,000 unbilled over 15 days, that means you’ve got unbilled hours from 15 days ago that you haven’t translated into an invoice.

When it comes to getting paid, the closer the services render is to the invoice date, the less likely you’ll have invoice disputes. Factoring in any payment leeway you might offer your clients (e.g. Net 30), this gives you a good idea of how long the cycle is from doing the work to receiving the payment.

This is a new feature that’s available for all accounts, free or paid (although paid accounts will benefit a little more from it, since it becomes more useful with more staff), so make sure you take a look!

Paid accounts will find a new goodie available just in time for taxes (if you live in the US): invoice and payment reporting capabilities. We’ve always been focused on keep the main Ronin invoice UI as simple as possible. Unfortunately, that’s meant that it hasn’t been as easy as needed to slice and dice the numbers. In particular, it’s hard to break down incoming (accrued or cash) by a given week, month, or year.

Now, with the release of reporting, this functionality is available under a new “Reports” tab:

Of course, there’s more to come. We’re certainly planning to release more reporting functionality in the near future. But, hopefully, this gets our users started with the most important aspect of invoicing: tracking your income!

The world-wide response to the earthquake in Haiti has been encouraging. However, it’s sometimes easy to forget that the effort will be ongoing. Rebuilding a country that has been so damaged by this disaster is not something that will only require our help for a few weeks.

Buy Ronin. Donate to Haiti. Win-win.

Here at Ronin, we want to pitch in in our own little way. From the publishing of this post to the end of February, Ronin will be donating all proceeds from the first month of new accounts to the recovery effort in Haiti.

Learn More about the Haiti Relief Effort

Google has set up a page where you can learn more about the effort in Haiti: http://www.google.com/relief/haitiearthquake/. They’ve got some Google Earth imagery that offers a glimpse into the post-earthquake condition of Haiti. There are also numerous links there that offer information on various ways you can get involved directly either by cash or in-kind donations.

It’s easy to get involved

You can also help immediately by donating to the Red Cross to assist the relief effort. Contribute online to the Red Cross, or donate $10 to be charged to your cell phone bill by texting “HAITI” to “90999.”

We run plenty of usability studies here at Ronin. We run them so commonly, that we think of them as taste tests - it’s only any good if it fits the palettes of the everyday user. A certain magic happens when you combine the rich feedback mechanism that is usability studies with the instant gratification medium of the web applications.

Everytime we conduct a study, we walk away with plenty of improvement ideas. Then, we sort them in priority (including bonus points for biggest-bang-for-buck features) and we add them into the product, usually within one or two days. Simple as that. While that may seem mundane, it’s really only possible with the appliction distribution model of web-based applications. Instead of building and compiling the next version of software as an incremental release that our users have to download, we can ship it to them without them even knowing.

Case in point, after the last round of usability studies, we’ve made the following improvements, all of which were released Sunday evening, waiting for use on Monday morning:

• The ‘amount’ field during adding of payments is automatically filled out with the remaining balance of the invoice. This is so often the case, and it’s a big win for efficiency.
• Removed requirement that a ‘note’ be filled out during payment creation.
• Added two links to edit “from address” (and other additional informational fields, like tax ID) and “to address” right in the invoice interface. The most common case of client creation is during the invoice creation flow and additional address information is usually a necessary addition afterwards.
• Change the invoice summary section to read “Total Due” instead of “Remaining Balance” when there haven’t been any payments, partial or whole. Removed unnecessary tax information from the invoice summary when the invoice is taxless.
• Improved the invoice comments UI by moving up next to payments as a column. We noticed a lot of users mentally filtered out the comments section because it was so low and hidden on the page.

This is just one set of improvements we’ve made, but changes like this happen almost on a daily basis. Sometimes they’re big, sometimes they’re small, but they’re hopefully always a step in the right direction.

We’ve recently added integration with Authorize.Net, one of the more popular payment gateways. For the impatient, there’s no need to read further - just log in to your account and the option will be waiting for you under the “PayPal/Auth.Net Integration” link.

Integrating with Authorize.Net is fairly straightforward - with one caveat - Authorize.Net only handles USD (United States Dollars) as the currency for every transaction. We’ve held back on the integration until now simply for the reason that we wanted solutions that would appeal to every Ronin user, of whom lots are international, particularly in the UK and rest of Europe. One of Ronin’s strengths is the ability to handle multiple currencies, even within one account and we wanted to make sure we “do it right, or don’t do it at all.” However, there were simply too many requests for Authorize.Net integration to ignore.

With that, we’ve decided to integrate Authorize.Net with the option to still fallback on PayPal (which handles more currencies). So, if you enable both, your USD invoices will simply accept credit cards via Authorize.Net and your other non-USD (CAD, EUR, GBP, etc) invoices will still go through PayPal. You’ll get paid sooner, your clients will be offered the convenience of paying online when applicable, and everyone ends up happier!

Start sending out those invoices! Enjoy!

We’ve been asked many times whether or not recurring invoices was possible with Ronin. For a while, we’ve had to say “No” or “This feature is under development.” We always planned to build in this feature, but we wanted to make sure it felt right - that it felt no less intuitive than creating a single invoice.

We eventually built the feature, but decided to hold off on releasing it until we did enough user testing before releasing the feature. As it turns out, the first iteration of it, indeed, wasn’t ideal. What we had designed was a “schedule” that you could assign to many clients. The idea was that freelancers and firms would have standard packages (say a retainer for $x/month) and that you could then put clients into that schedule. Furthermore, it was thought that this would allow the most effecient way of managing the schedules - you would never have to create too many, there would only be a few that you assigned to clients.

After some testing, we realized being technically neat didn’t necessarily make a product more intuitive. In fact, it often works in reverse. The end result just didn’t fit a typical workflow. There were a whole host of issues, but chief among them were that:

1. It made recurring schedules feel like too much of a “first-class” feature. We want Ronin to revolve around clients, but the initial design made it feel like schedules owned clients, not the other way around.
2. Maintenance of schedules was actually harder, not easier. Once we started considering the ability to “pause” and “resume” schedules, it became a nightmare to display the status of the combination of a schedule and its clients in an intuitive way.
3. It was overkill. We realized that it wasn’t very common to have two clients share the exact same schedule (including date, item naming, price, etc.)

Instead, we eventually went back to basics. Creating a recurring schedule is as easy as creating a normal invoice and it’s tracked just like one as well.

Finally, you can now create recurring invoices with Ronin. Enjoy.

The best way to improve an application’s usability is to run extensive studies - they allow you to get an idea of what it’s like to walk a mile in your users’ shoes. Sometimes, just the practice of sitting down with another human being and verbally walking through your application’s features brings out certain perspectives you may not have considered before. This is especially true if you wear many hats during the development cycle.

At Ronin, we run a usability study every few weeks, focusing on new features. We’re usually very considerate of our users throughout our application design process, but you’d be surprised how much slips through when you’ve looked at the source code of your application longer than you’ve looked at the actual interface. Running a usability study is an exercise that usually brings in a large list of low hanging fruit and a moderate list of long term application improvements.

That said, from our experience running these studies, there are a few things we realized you can never fully understand from just the studies themselves.

User patience

When a study participant sits down next to you to walk through your application, they’re in no hurry. They’ve committed the next 30 minutes to 1 hour of their lives to the purpose of completing the study. Compared to the average 9 second attention span you’re likely to get from a real world user, this is too distant from reality to simulate.

Unfortunately, there isn’t much you can do to recreate a frantic in-the-wild scenario. This negatively affects the ability to learn about edge-cases and error handling the most. A usability study user is likely to run into some errors that they are patient enough to figure out during a study, but would otherwise cause them to throw their hands up in disgust. To counteract this, its best to read between the lines when it comes to negative reactions. Multiply observed frustration during studies by many magnitudes to really understand how a user may react.

Also, try to develop an understanding of how user patience can be a big factor. Spend time testing your home, promo, and marketing pages with an emphasis on asking for a stream of consciousness verbal description of what they see with a time limit. After all, if they stick around long enough to try your application, you’ve won half the battle when it comes to user patience.

User attentiveness

Another problem is that study participants are usually more alert and attentive than their real-world counterparts. They’re willing to take their time and figure out a problem. They’re willing to devote their undivided attention to the task at hand. Compare this to the more likely scenario of an actual user trying out your application at 2 a.m. with the TV running in the background and after surfing to your promo page by coincidence. It’s night and day.

To counteract this, make sure you get immediate verbal feedback after each action they take, to get a sense for what they’re thinking before the interface has had time to soak in their consciousness.

User skepticism

Most deceiving of all is the mindset of a usability user. Depending on what your relationship is with the user (stranger, guest, friend, acquaintance, co-worker from another department, spouse, child) you need to realize they’re walking into the study with some intentions. Sometimes they’re participating because you’ve promised to pay them; other times they’re participating because they want to help you out. Whatever the case, nothing simulates user skepticism.

When a random user hits your site or application (say from Google), they’re coming with a guarded mindset. They’re cautious more than curious and they’ll immediately look for warning signs. A poorly designed interface with no obvious indications that there is active support or lack of no-obligation demos or screenshots are an immediate turn off. If they eventually try your application or dig deeper into your site, they’ll probably be less willing to try anything but the most obvious of features.

When a user hits your site or application from a referral or other more qualified method, they’re coming with a curious mindset. They want to dive right in and see what all the fuss is about. They’re also likely to be the ones who have heard of alternatives or are currently using an alternative and now they’re using your application to do some feature comparisons.

When a user participates in your user study, you get none of this. They’re neither overly guarded nor overly cautious. It is more likely that they feel you are working together in unison towards a common experimental cause. You really don’t get the stinging skepticism that a real world user carries.

It helps to keep these things in mind when conducting usability studies. Sometimes it’s too easy to pretend that you’ve aggregated all the feedback you can by running a well-designed series of studies. Even armed with that data, keep in mind that the best feedback is silent feedback. Make sure to analyze your logs. Don’t dismiss your analytics tools. Look over real user data from real users in the wild. Couple that data with usability studies and only then do you have a good macro- and micro- level understanding of your own application.

We’ve recently added support for four more currencies: JPY (Japanese Yen), INR (Indian Rupees), CHF (Swiss Francs) and NZD (New Zealand Dollars). You can now send those invoices in 10 different currencies.

In adding support for more currencies, we wanted to make sure we included currencies that are “the most popular” (whatever that means). Surprisingly, there was no definitive resource that lists out the most popular currencies by any decent metric, unlike say, languages, where the list is easy to find. We did run across this discussion which seems to indicate that this is a question that people want answered.

Eventually, we ran into the list of the top 8 most traded currencies in the foreign exchange. Not surprisingly, that list looks very similar to the list of supported currencies in Ronin. Oddly enough, the Russian Ruble and the Brazilian Real were not present, despite being high up on the top economies list.

We’re always looking to improve our offering here at Ronin, and one feature we’ve received several requests for was the ability to send estimates. Unfortunately, everyone’s daily workflow is different - drafting and sending estimates is no exception. We’ve tried to incorporate as much feedback as possible, and while we’d love to including every feature detail from numerous email threads about this feature with our customers, sometimes we have to call the shots that make sense.

So log in to your Ronin account and you’ll notice a new estimates tab. Hit the “New Estimate” button and you’re on your way. After drafting the estimate, hit “Send Estimate” and your client will receive the estimate in his or her email. The client can then respond by leaving comments, accepting or declining your estimate.

Estimates can easily be accessed from the main interface

Send estimates to clients via email

Clients can accept or decline estimates right in the web interface.

It’s all very simple (we hope) and there isn’t too much different about drafting an estimate and an invoice. We hope we’ve nailed it, but we’d love to hear any feedback.