Sometimes the time between coming up with a kickass feature, having a “product planning meeting”, writing, coding, and shipping, is one hour

— c3 (@court3nay) April 21, 2012

While we were trying to scope a new Tender feature, we accidentally stumbled across a very simple and effective UI improvement that we were able to implement, test and deploy in the space of an hour. I figured I could introduce this (very small) feature with the (very short) story of how we built and shipped it.

The issue was thus: We provide per-queue notification settings for support staff. These only affect whether the staff member in question receives email notifications for a queue. However, these notification settings also represent something else. They’re a list of queues that are important or relevant to a particular staff member. Amazingly, we don’t make use of this information anywhere else! I know!

As things wound down in the ENTP office a couple of Fridays ago, Courtenay and I became so energized by this discovery. Courtenay immediately pushed his first pass at a topic branch for this feature. I reviewed and staged it. We went over the QA routine ourselves, since everyone else had mostly gone for the weekend. There was some confusion at first because I couldn’t find the right notification settings. This is why I don’t usually do QA. We pressed on, because we are intrepid and we kept the scope very small. We verified that it worked and shipped it to production to see it in action on our own support page.

Within an hour we had the following simple, new additions:

From now on when you elect to be notified about a queue, that queue will receive priority in the support dashboard UI under “My Queues”. Since we were keen to get a useful change shipped right away, we didn’t do any more than this for the first pass.

I’m not going to lie, we were already barfing rainbows over this, so great was our excitement at this easy win. But! There was one very important bit of functionality missing, in my opinion: What I really wanted was the ability to see discussions from all of my queues in the pending view at once. So we took a little more time and added that too.

We left ourselves greater leeway on the turnaround for this one, and we were able to get our usual QA approval before shipping. We were even able to pay off some technical debt in related code at the same time! This change has been very important to me personally as I find it to be conducive to my own workflow. It gives me an easy way to check whether any queued discussions that I should know about about are waiting for a response, and nothing else.

Like I said it’s the small things, or maybe we here at ENTP are hopeless workflow nerds. Possibly both.

I’ve just added a callback parameter to our autosuggest json endpoint. This means you can now search your knowledge base from anywhere and integrate the results into your page. Furthermore, because it’s using the autosuggest, you can plug in a bunch of unrelated words and it will simply find the best match.

For example, you could parse the contents of your page and automatically suggest the best results for that page from your KB in the sidebar.

Here’s the URL:

 http://your.tenderapp.com/search/autosuggest.json?q=query&callback=function

Here’s some sample code to get you started, using a script tag:

<script type="text/javascript"> 
function kb_search(results){ 
 $('#results').html(results[0].title); 
} 
</script> 
<script src="http://monkeys.tenderapp.com/search/autosuggest.json?callback=kb_search&q=how+do+i+find+api+results" defer="true"></script>

I’ve written a more complex example, that works with a form and a jQuery jsonp call at  this gist: feel free to fork it and improve it. It attempts to minimize the number of requests sent.

Good day to you!

When creating a new profile in Tender, the email preferences default to notifying the user of changes in the issues/discussions they have participated in (either by creating or commenting on), but you can curate your notifications for any given category or queues that you wish by signing in and going here:  https://help.tenderapp.com/profile/edit

Scroll mid-page where you’ll find “Email Preferences” and click as you see fit.  A word to the wise:  choose your notifications wisely, young Jedi. If you get click happy, you may find your email inbox quickly becomes inundated with things you don’t really care about.

Occasionally, users report being spammed by Tender’s support system.  If this happens, have them check their email preferences before submitting a bug report. If they have any public discussion category notifications set, the user will receive all posts, regardless of their direct involvement in the discussion.

Even before the beginning of a pull request for Lighthouse and Tender, TATFT is enforced. Red, green, refactor as the code is written is excellent but it won’t catch everything. Scripts are vital but can sometimes lead to complacency. I believe exploratory testing is a great tool in my web application testers tool belt. Unfortunately, it’s often misunderstood. Here are three common misunderstandings of exploratory testing:

1. Testers have to find bugs. Exploratory testing is like a hunting trip and serves no purpose.

   The belief that testers *must* find bugs is false. My happiest day is when I go through a pull request the first time and can say “Ship it!”. The best exploratory testing is not blind exploring, monkey clicking through the application, but rather thoughtful investigation of the application by someone who knows the code specifications.  

2. Exploratory testing is only good right before deploy.  

   Exploratory testing can actually enhance the automated test suite, by finding new uses of the application not already covered by existing tests. I see every bug report as an opportunity to beef up our test scripts.

3. Exploratory testing is done without scripts.

   The best exploratory testing is based on carefully created scripts, but the wise tester  knows when to stray from the scripts and follow the bug trail where it leads; being careful to track the steps to reproduce the bug in question. 

Although it is very easy to dismiss exploratory testing as an inefficient testing method, most web application users are not as predictable as programmers would hope. Exploratory testing bridges the gap between automated testing and those unpredictable users.

Hi everyone,

So what have we been up to?

Well for starters, we fixed the spam count: we had quite some fun with this one, and it should now accurately reflect the number of messages in your spam folder.

We also added a couple of endpoints to the API, and fix a big annoyance. You can now:

• Delete KB articles
• Create and delete sections
• Use pagination for discussion comments (at last)

We’ve added the relevant documentation as well. I know some folks have been waiting on those, so let us know how this works out for you.

That’s it for today, see you next time with more goodies!

Since this is a much shorter period than the last change log, we have less to talk about this time, but here goes!

Most notably, ticket search has improved: While it’s always been possible to specify multiple responsible: specifications in a search, responsible:none only worked in isolation. It was not possible to search for the set of tickets assigned to someone as well as unassigned tickets. Well, this has changed! So for example, if you want to make a bin of your tickets as well as stuff that nobody has picked up yet, you can do that now.

Milestone due dates could exhibit some odd behavior for project members in different time zones, so we now anchor milestone due date comparisons to the account-level time zone. This means milestones will be due/late at the same time for everyone!

In some cases it was possible to silently truncate content for a page if it was too large in size. We’ve added validation to prevent data loss, but the size restriction remains in place for now.

We are also handling (and cleaning up) more instances of failed callbacks, reducing the load on our job runners. We have also continued to improve the stability of our export process for very large data sets.

Hi folks, it’s been too long since the last Lighthouse update! You have me to thank for that, but I have bravely re-learned to blog and am finally here to fill you in. We are tearing through our backlog of issues, and we have plenty of stuff to tell you about!

Here are some highlights from Lighthouse releases in the last month or so:

• Audited for mass-assignment bugs in every controller. I’ll have more on this later.
• There is much-improved display of ticket changes, including inline links.
• We’ve fixed the display for projects with thousands of tickets, so your ticket badges don’t take up 2 lines.
• We improved the fidelity of table styling in preview, to match the final comment.
• Added pagination to user- and account-level activity feeds, and improved pagination behavior in milestone views.
• We’ve updated our OpenID back-end, which should go a long way toward improving interoperability.
• We now avoid modifying ticket creation date when changes are rolled back.
• Watchers were not being added/notified in some cases, this has been fixed.
• We also fixed instances of subscribed watchers being re-added to tickets accidentally.
• Refined auto-linking behavior in the markdown formatter, so that auto-links do not happen inside markdown and textile links.
• We’ve restored reverse-sort functionality in ticket queries.
• There were instances of HTML content appearing in text email notifications, these have been fixed.
• Internal links now work properly while previewing.
• Fixed a JS error being experienced by some Internet Explorer 8 user.
• We’ve made numerous internal improvements to our export functionality, making data exports quicker and more reliable.
• Improved handling/reporting of missing resources during API requests.
• Fixed tag editing on Internet Explorer 9.

Bigger improvements and new functionality are on the horizon. I expect you’re as excited about the new hotness as we are, so stay tuned for more!

Howdy! We have been shipping a bunch of updates to Lighthouse, dealing out bugfixes and tidying up in general; basically fixing a bunch of the nigglingest issues and making up words while we’re in there. Here’s what we shipped recently:

• Lighthouse has been modernized and now runs on Ruby 1.9, along with a bunch of upgraded and moderner libraries for our whole stack: memcached, mysql, and more.
• Callbacks - you may know them as web hooks - now have their own UI (previously only accessible via the API.) You can make callbacks from the account-level settings page. All ticket updates get a JSON post to any URL you choose. If a callback fails continuously, we will eventually stop posting to it.
• Bulk edit failure modes got improved: if you create a bulk edit that has no actual tickets (i.e. if you create it twice, or the ticket got moved), it won’t sit around hassling you that it hasn’t run. Also, you can’t select archived projects as a bulk edit target.
• CSV reports are now fully Excel compliant and are UTF-16, so your non-ASCII characters will work just fine, right-to-left, und so weiter.. There’s also a dedicated Excel button (it’s actually a TSV) as well as the same old CSV.
• We upgraded our markdown processing library to the latest, which may fix some annoying formatting bugs.
• We also upgraded our date parsing library and fixed some minor bugs there.
• Attachments on tickets with more than 100 comments now show correctly.
• Pagination on milestones is fixed and now actually works.
• “Late” milestones is now an accurate thing that refers to the end of day rather than beginning (you’re not late til the day is done, man).
• Saving default ticket bins no longer clears the default state.

Once we get these fixes out of the way we have lots of exciting lighthousey things to share with you!

Both Tender and Lighthouse will be down for up to 30 minutes tonight from 8pm Pacific while we reboot some critical servers. While we can reboot most of the instances without causing downtime (in fact, we already have), there are some services that don’t handle failover particularly gracefully and so it will be cleaner for us to take the apps down completely rather than try to do it ‘live’.  For example, we could easily fail over our redis cluster to the slave instances (they’re already used for reads) but there’s a risk that a few minutes of writes would be lost.

We apologize for any inconvenience due to the late notice - we’re not entirely happy about it either.

We’ve just deployed the User Class feature.  This is our way of providing the minimum amount of access control and segregation possible.

You see, many of you have two main versions of their software or application: the normal version, and a beta version with features not generally available. You want to have articles and categories available to those users without revealing that information to the public.

You also tend to have regular users, and a separate class of important users — whether they’re paying more, need special handling, or you just love ‘em because they always open nice detailed and friendly support requests.

So, we’ve enabled a few toggles on your users, KB sections, and categories. You’ll need to enable it like so:

1. Go to your site settings. Select “Enable beta users” and hit save.
2. Go to your users page (settings/users), and check some users’ checkboxes. Set the Beta Access, or Important User, flag. (also can be set in the API and SSO hash)
3. Go to your categories admin page, and edit or create a forum category with the same toggle. 
4. Go to your KB sections admin page, and edit or create a KB section with the same toggle.

Any sections, KB articles, categories, or discussions flagged as beta or important won’t be visible to other users. Users who have access to see those sections and categories will have the results show up in searches, autosuggest and regular browsing.

Finally, while we haven’t enabled this on discussion filters (yet!) we HAVE shipped something else that’s even more useful. You can now design your filters around the ‘extras’ hash that is attached to each user and discussion. So, for example, lets say you set a user with the extras hash of { plan: ‘Premium’ }

You can now create a filter that will check for key/value pairs on new discussions, like “plan=Max” or “name=Joe”. You can even use regular expressions (name=~Joe) and have multiple statements (name=~Joe;plan=Premium).

This feature should be (somewhat ironically) considered beta quality for the next week or so, but I’d love to hear how you’re using it or how it doesn’t quite meet your needs. As always, open a discussion on our own forum at help.tenderapp.com or email us at help@tenderapp.com.