Attachment Fixes, Chat Stability
Apr 14, 2014
and Upcoming Beta
Summary: This week we fixed a couple issues that were slowing down agents working with attachments, strengthened our Live Chat app, and prepared to launch our new beta environment.
The week started with an odd attachments bug that was slowing down agents that work with a lot of files. The first report that led us to the problem complained that their browser always made them choose which application to use with an attachment:
Not a huge issue if you only open an attachment once in a while, but it’s a major pain if your day revolves around emailing files.
Then we received another report asking why all their attachments had the same filename when downloaded, and the lightbulb went off.
We were losing every word after a space in a filename! After a quick fix, files like “4th quarter sales.xls” no longer lost the “.xls” and “sales-january.xls” and “sales-february.xls” were no longer both just “sales.”
This week also brought a couple improvements to the Live Chat app. First, there was a small bug that caused the “Chat with Us” button to show temporarily when the browser couldn’t connect to the server in a timely manner.While the button was only on the screen for a couple seconds, it definitely looked amateurish and had to be fixed.
We’re happy to say, it won’t happen again.
We also spent some time on the Live Chat backend. Chat and real-time updates run on NodeJS servers that are separate from our main app. Every time a change is made in the database, our main servers send this information over to the NodeJS servers and vice versa.
We noticed a couple of bottlenecks in these communications that were causing them to take much longer than necessary. We won’t bore you with the technical details, but the end result is snappier updates all around.
Back to Beta
As a few customers have noted, beta features have been missing in action over the last six weeks. We’re happy to say, our new beta environment is almost ready again! We’ll be testing it thoroughly this week and hope to relaunch it to the public afterwards.
It’s been a long couple of months putting the fun stuff aside to harden our infrastructure and knock out bugs. Spring cleaning is done though, and we can’t wait to show you some of the new features we’ve been working on like:
easier forwarding with autocomplete
private emails with third parties inside tickets
redesigned Trends dashboard
And a few more that have to stay under wraps a little longer. It’s going to be a fun Summer!
Better Routing, Account Switching
Apr 7, 2014
and Easier Integration
Summary: Accounts broken into groups, such as sales and developers, can now route incoming emails directly to the right type of agent. Logging into multiple accounts just got a whole lot easier, and we even made some improvements for our developer friends.
Assign to Next Available Agent in Group
We added the ability to automatically assign incoming emails to the next available agent a few months back. It’s a great way for small teams to break up the workload, because emails are assigned to the agent w/ the least number of open tickets. However, it breaks down when companies are broken into groups by responsibility.
As of last Monday, accounts with groups can create rules that assign emails to the next available agent in a specific group. This way emails from new prospects can go to a salesperson while technical questions are routed straight to a developer.
A lot of our customers run multiple businesses through Groove, and most choose to run all of their email through a single Groove account. There are a few that prefer, mainly for legal or accounting reasons, to keep their businesses completely separate.
It turns out that these customers would get stuck in a particular account if they didn’t first sign-out before trying to sign-in to another account. They were jumping through all of kinds of hoops just to use Groove including running:
- Chrome in incognito mode
- Chrome and Safari side by side
- two completely separate computers(!?!)
All because of one little cookie! It was a simple fix, and now customers are seamlessly signed-out before trying to sign-in to a different account.
Easier to Integrate Widget
Developers using the latest version of Rails will be happy to know the Widget now works as expected with turbolinks! The Widget always worked if you included at the end of your <body> tag like:
But it would disappear if it was included in the <head> tag. To make it possible to include the widget in the <head> tag we added two new utility methods:
We’ll be updating our knowledge base later this week, but it only takes a few lines of code to get everything working:
We also added the ability to temporarily remove the Widget from the page if needed. This has been the most requested addition to the widget, and we’d love to hear how you use it.
Fewer Email Notifications, More Markdown, and Better ReliabilityAdded on Mar 31, 2014
Summary: It was customer request week at Groove. We fixed an annoying bug with email notifications, extended Markdown support for Knowledge Base articles, and continued to increase reliability.
A lot of Groove agents rely on email notifications to keep up with support requests, and we try our best to keep their inboxes manageable by skipping needless notifications. This week we found one that we could eliminate for agents that are part of a group.
Every time an agent assigned a ticket to their own group, they would receive an email stating the obvious fact that they assigned a ticket to the group. We nixed that and would like to think inboxes everywhere are happier because of it.
Tables in Markdown
We’ve always supported Markdown for writing Knowledge Base articles. If you don’t know much about it, Markdown is a great way to format articles and blog posts without having to write HTML. It’s a favorite among developers with sore fingers like us.
In the past, we’ve only supported the original Markdown specification, which doesn’t include HTML tables. The guys over at StatusPage.io alerted us to this last week, and we added support for tables over the weekend.
We started seeing an increased number of dropped requests during peak traffic periods last week. Thankfully it affected less than 1% of users, but we’d prefer zero. After some spelunking, we found our app servers were slowly leaking memory.
We’ve always had monitoring in place to restart an individual process when it got too greedy. It did the job, just a little too aggressively. Requests were getting dropped because the server was being killed mid-request.
Thanks to the wonderful world of open-source; we found a much smarter solution that restarts the process after the current request is finished. Which means happier servers and happier customers.
Customer Names, Nested Replies
Mar 25, 2014
and More Polishing
Summary: We had a rollercoaster week that started with a simple bug affecting customer profiles. Things escalated quickly as we fought an ever-growing number of nested inline replies that slowed outgoing email beyond acceptable levels (i.e., at all). We closed the week out giving the app a much needed polish.
Quick Customer Profile Fix
An odd bug was reported with customer names this week. A number of messages were showing customer email addresses instead of first names:
We’ve always defaulted to showing a customer’s email address if we didn’t know their name. However, we’d never seen this before. Every time we see a new customer, we send their email address to FullContact to build a social profile for them. This is also our backup source for customer names, when names are not included in the original email.
It turns out we were updating first and last names independently. Only the last name was getting updated when their email address had been used as their first name. A quick two-line fix (and about 20 lines of tests) was all it took to make sure no one ever sees “firstname.lastname@example.org Glasner” again.
Too Many Replies
A few weeks back we started showing nested reply histories in replies to customers, trying to replicate the look of a personal conversation. It has worked great for 99% of emails, but that other 1% has been like a pack of Gremlins on our servers.
Once an email reached a certain size, it would start to bog down outgoing emails:
Once we narrowed the problem down, it was fixed in about an hour. And now our servers are buzzing along happily again:
And a Little More Polish
As part of getting back to basics, we moved lot of little bugs that have been annoying us (and our customers) to the top of the backlog. While not huge fixes, collectively they’ll improve the user experience for many of our customers. We fixed issues like:
- inputs overlapping a couple pixels in the new ticket window at certain browser widths
- misaligned arrows in dropdowns after making a selection
- giant reply form on a 30” screen
We crushed around 20 different edge cases like these, but let us know if we didn’t hit your biggest peeve. It’s spring cleaning time at Groove!