Robby on Rails

RubyURL was a project that I built about 2 1/2 years ago as a late night attempt to see what I could build and deploy with Ruby on Rails in a night. It’s nearing 50,000 unique website links, has a Ruby gem that you can use with it, and rbot plugins.

I’ve rewritten it about three times in the past six months, to try out some new approaches, but haven’t deployed with a new version as I’ve been waiting for someone to help me with a new design. Chris has offered to help out and once we integrate his new design with it, we’ll be launching it.

Everything is not great in RubyURL land though. It appears that it’s become an easy target for comment spammers to abuse the site to generate rubyurls and paste those links in their spam comments. Several pissed off bloggers, forum administrators, and system administrators have emailed me to complain that I’m spamming their site. Sadly, even with a basic disclaimer on the site, they still like to blame me for their spam. It’s gotten common enough, that I’ve written a template email that I respond with that explains how the site works and that I’m not accountable for people posting links to my URL redirect tool.

You can see that it’s popping up around the net via a google search.

So, I’ve been trying to think of ways to make it easier for people to flag URLs as being abusive of the site. I’ve not come up with any elegant solution that doesn’t force the good users of the site to have more steps in their process to create a basic RubyURL.

The ideal (and current) workflow:

• User navigates to http://rubyurl.com
• User pastes in long url into text box/area
• User submits form
• User is provided with new (shortened) rubyurl
• User copies the rubyurl and does what they want with it (generally… pastes into IM, IRC, Email, etc.)

Some people have suggested using a user system to do this, but I really don’t like that as a solution.

Another idea, which I built… and later removed from my new version, involved having the original url load in a frame, and then provide a way for users to flag it as ‘spam’, ‘nsfw’, or ‘dead’. Then, we could provide the user with a warning that the following URL was flagged before, are you sure you want to continue? I didn’t like this as a solution in this way as it felt very obtrusive to have a rubyurl frame at the top of the browser window.

One person suggested a captcha to try and verify that the user is human, but there are problems with this.

• I really dislike captchas. ;-)
• This doesn’t prevent spammers from using the ShortURL gem, which does everything via an API.

In regards to the API, this could be enhanced by requiring that everyone register an email address to get an API key, but only solves the API abusers.

I’m starting to brainstorm some solutions that specifically help the requests made through the web. I haven’t checked the logs enough yet to verify it, but I have a strong suspicion that much of the abuse is happening through a web-based bot, not through ShortURL… because Ruby developers are nicer than that. (I hope…)

So, I am curious… dear readers of my blog. How might you solve this problem without disrupting the user experience? Or, should I just stick with what I’ve got going and find a better way to respond to pissed off bloggers who think I’m spamming them?

Discuss…

So, I was trying to send AT&T wireless a support email through their online system and got stuck at the following screen.

Come on guys… you can design a better form than this… and I’m now going to have to try and sneak in a question under a sub-topic that doesn’t apply to my question… just so I can send you an email?

Getting help shouldn’t be so hard¹.

¹ At least I can Print this page and show all my friends…

In an effort to increase awareness of the importance of good Interaction and Interface Design in Web Development… I suggested that today be... Hug Your Designer Day.

Designers Versus Developers

Are you seeing a lot of this in your Design and Development teams?

Allison Beckwith, Experience Director and Graeme Nelson, Lead Architect

Happy Designers and Happy Developers

Well, maybe it’s time that your developers gave your designers a hug…

Alain Bloch, Web Developer and Chris Griffin, User Interface Designer

Also… to celebrate Hug Your Designer Day, Amy Hoy was kind enough to post her slides and some audio that I recorded of her talk at RailsConf 07.

Let’s all take a moment to thank the designers who put the experience of the users first. The success of our projects rely on everyone working together. Hug Your Designer! (they might hug back…)

Amy Hoy, of slash7 fame, gave a talk titled, Rubber, Meet Road: Getting Designers Running with Rails, which provided a good overview of some of the problems that designers and developers face when working together. This was one of my favorite talks, because she essentially explained several of the problems that our team has faced in the past and in many ways, still encounter from time to time. A few things that I was surprised to hear, was that several companies leave their developers to implement HTML/CSS in the Rails applications, rather than let their designers into the area. Some teams, provide a directory in public/ for their designers to write their HTML/CSS. Amy said that she preferred to work in the standard view directories (as a designer), which is exactly how our team works.

In fact, I agreed with Amy on several points.

• Developers say, “We can’t do that” too often, when really… we mean, “We won’t/don’t want to) do that”
• Template languages create extra barriers to training designers. Stick with RHTML… designers won’t be afraid of ERb syntax if you sit down with them and explain some of it. Move the ugly stuff to helpers… like you should be anyways!
• Teach your designers how to use subversion… let them break it first and then help them… they’ll love you for it
• When meeting clients with a designer and a developer… don’t let the developer speak too much about implementation when it hasn’t been designed yet. Interaction Design should dictate architecture not vice-versa.

“Stop, Collaborate, and Listen”—Vanilla Ice

I’d like to personally thank Amy for being a diplomatic designer and telling the hundreds of developers that showed up for her talk to remember that designers and developers… think differently… and that’s a good thing for the application and ultimately… the user experience.

Having said that, I’d like to request that tomorrow, May 23rd, be… Hug Your Designer Day.

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

• In what ways is your team embracing the failures of your development projects?
• How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

This morning was delightful. I woke up to find that 37signals had referenced our website on Signal vs Noise this morning. In particular, they referenced the Rails hosting order form on the PLANET ARGON site. What’s interesting is that Allison created this design over a year and a half ago.. and we’re actually in the process of a complete site redesign, which Chris and Allison are planning to blog about in depth. :-)

There are some discussions within the comments on the blog post about the design decisions that were made, some of which we’ve already begun to address in our redesign process brainstorming (based on google analytic conversion data).

On top of that, today is our Experience Director, Allison Beckwith’s, birthday.

Thanks for the linkage, 37signals!

...and… Happy Birthday Allison!