07 Mar 2012, by @pilif

This is it!

The screws are screwed in, the dust is brushed off, the hamsters are fed.

Thehelpr is ready for public consumption.

Over the last two years we worked on thehelpr (on and off), we have

  • completely revamped the backend from node.js/redis to a more traditional Rails/PostgreSQL combination
  • Designed not one, not two, but actually three user interfaces
  • Designed two backend user interfaces for account management
  • Tweaked, tuned, thrown away and tuned again.
  • been running thehelpr prototypes in production for multiple larger websites.

But above all, we had a lot of fun.

Now that the baby is ready for the public, we hope that you will have as much fun using thehelpr as we had making it and using it for ourselves as the documentation tool for our eCommerce solution

As we said a long time ago, we initially developped thehelpr to scratch our own itches. In the end though, we liked the outcome so much that we decided to make it useful for everybody - not just for us.

It took two years to move from a solution that worked perfectly well for us internally to something we want others to use. Two years of learning, of coding, of throwing stuff away. Two years of making thehelpr better and better, but above all, easy to use.

What a ride.

A new front page

14 Jan 2012, by @pilif

front page

We are nearing the public launch. There’s still stuff to do to get the payments working and we still have to do a lot of additional fine-tuning and tweaking.

But as we near completion, we should have a look at making the front page better.

What we had was too text-heavy and didn’t show off what thehelpr was about well enough. Some might argue that it was too green too.

So we went with a much cleaner design, highlighting what thehelpr is about and quickly inviting the user to give it a try.

As before, thehelpr works without signing up or even paying. Everybody can create online help on any website of their chosing.

Only once they want to have the help displayed publically, they have to create an account (and eventually pay).


22 Dec 2011, by @pilif

Up until now, changing the anchor point of a bubble has always been difficult as we had two modes: Via drag & drop you would set the offset and point of attachement to the target element, but to actually change the element the bubble would require to move into a repositioning mode in which we would use selector gadget.

This was very confusing for the users, but felt like a necessity because of two reasons:

  1. selectorgadget runs in the target page - the bubbles are in the iframe which we put over the whole visible area. So dragging the bubble happens in the iframe, but positioning happens on the target page.

  2. selector gadget requires a click to do its positioning work.

The second issue was comparably easy to solve: When the mouse stops, we fire off a timer and if there is no further mouse movement in a specific time period, we just pretend that the user has clicked. This works perfectly and we still don’t have to alter selectorgadget at all.

The first issue was… more interesting to handle. But as we already had heave cross-frame communication going on, at least the positioning we could handle. The problem was just how to even get the mouse position and mouse events to the underlying page - the iframe is on top of the z-index.

The trick is to use pointer-events: none when needed on the iframe in order to have the mouse events go through to the target page.

With this we now have an amazing solution for re-anchoring bubbles: You drag them to your target element and hover it for a few moments. At that point, the element will be highlighted and you can drop the element to reattach it.