Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Review: FogBugz, part 1

Posted by Tue, 01 Jan 2008 20:43:00 GMT

Today, I thought that I’d give FogBugz a quick trial. A few of our Rails consulting clients use it and I’m hearing that others are as well.

Along the way, I’m bringing one of my favorite tools so that I can share some things thoughts (visually) along the way.

Signing up for a free trial

My first impression of FogBugz was, “nice homepage design… but what is that screenshot of?”

I’m not a designer, but the interface in the screenshot isn’t jumping out to me as something that you’d expect to see in a modern web application. While I appreciate the default browser colors for links (this is really important)... I think they could have found a better way to distinguish which bug links you’ve previously viewed. It’s very likely that you’ll most bugs many times, so having the color be different might not make sense in the same way it would when reading content on a web site. Again, I’m not a designer and I’d be curious to hear from a designer on this. Just something that I initially thought.

Okay, this sign up form seems really easy to start with. I’m used to free trials being really simple to get going. So, I enter in my sub-domain selection and provide my email address on the following page so that they can confirm that I’m legit.

(several minutes later…)

Okay, this process required me to jump from my browser to my email to my browser back to my email and then back again to my browser. It’s really frustrating for an application to force me to go back and forth between my browser and email client. I think the initial email is something I can cope with, but I found it a bit silly to have to wait for another email to receive a link to login to my new account, especially considering I already knew the URL as that was the first thing that I provided. The application could have provided the link (or redirected me) to the following form, which I had a few things to comment on.

At first glance, this might not seem like much… but I’m becoming more and more disappointed by the choice of language that we’re using in applications. First of all, this is the first time that I’ve seen this page. I’m not changing my password… what you’re really asking me to do is, “Create (or set) a password.” There are other verbs that you could use here, but change really isn’t appropriate. Also, choose doesn’t work here either.


  chose; choos·ing.
  –verb (used with object)
  1.    to select from a number of possibilities; pick by preference:  

What am I choosing from? Again, you’re asking me to create a new password.. not change one and definitely not choose one, unless you’re implying that I should choose one from a collection of ones that I already use.

One might argue that we can make an assumption about what they mean, but it’s simple problems like this that can seriously confuse people that use the software we design and develop. As people interact with minor problems like this, their perception of the software as being helpful and friendly… can quickly deteriorate.

Okay, so that was my first several minutes of getting into my new FogBugz account.

Coming soon… Robby will share his thoughts on managing bugs with FogBugz.

Audit Your Rails Development Team

Posted by Sun, 17 Jun 2007 19:05:00 GMT

Several months ago, a few of your colleagues decided to join forces with you as you had come up with a concept for an innovative web application, shared the ideas with your friends and relatives, and began developing a business plan. After a few months of performing some initial market research, working on your pitch, and raising some initial funding, you decided to bootstrap the project and start designing and developing the product.

During your research phase, you came across several articles about this exciting new technology called, Ruby on Rails. You were impressed with many of the sites that were being developed on this new framework as well as the community that surrounded it. Your team decided that it would be a great idea to follow this trend and use Rails as the platform for your new product.

At this point, you began soliciting freelance developers and/or firms to hire for the design and implementation of your project. Eventually, you make a decision and break ground on building the product.

Let’s jump forward to the present day.

You’ve been in heavy development for quite some time. Your product has gone through a series of design changes and you’ve recently begun to allow other people to begin testing the application. You’re receiving a lot of bug reports as people use the system. Your development team quickly fixes them as they appear, but you’re noticing a trend in the development process.

The speed of implementing new features is drastically slowing down as your development team is spending most of their time fixing bugs. Along with that, they are becoming frustrated by the project because they can’t keep up with your new feature requests while trying to keep up with your growing number of bug reports. You’re becoming concerned about the stability of the product and are slightly suspicious that your developer(s) might not be as good as they suggested they were.

Did you hire a bad development team? Chances are, you may not be able to tell. You’re not a developer, so reviewing their code would almost be a waste of time. How would you know if they were doing a good or bad job? Your developers reassure you that things are going to work out in the end, but it’s going to take longer then originally planned. Along with this, your partners and investors are anxiously waiting for you to launch the product, but something feels wrong. You’re worried that launching it too soon could be the quick death of the entire project if it all comes to a screeching halt due to unforeseen bugs and problems with the application. This wasn’t how you pictured the launch of your exciting new product and you feel a lack of confidence in the entire process.

What can you do?

Before I get into that, let’s discuss some of the possible causes for this situation.

  • Your development team may have grossly underestimated this project.
  • You might have pushed too many features into the initial release of the product and your development team might not have done a good job of helping you determine what you need, not just what you want.
  • Your development team might not emphasize testing enough in their process.
  • Your development team may have begun to take a lot of short cuts in an effort to hit your launch date(s)
  • Perhaps you asked for quick turnarounds on new features before an investor meeting… maybe this happened on several occasions.
  • Your development team might not be very good with Ruby on Rails, maybe this was their first Rails project.
  • ...and so on.

At this point, the big question is… what’s the problem?

Can you answer this question yourself? Can your development team answer it? If not, what do you do? How can you get an accurate understanding of how stable the code base of your application is?

Answer: An independent code audit and review

Why is this a good idea? Well, when you have an independent team review your code, you get the benefit of having a fresh perspective.. and often times, an independent team can be much more critical and provide an honest assessment in a very short period of time. This is especially true if they have a lot of experience with the technology. For example, PLANET ARGON has been conducting code audits on existing projects for over two years. We’ve designed a process for checking existing code bases for mistakes that we’ve either made ourselves in the past or found in other projects that we’ve reviewed.

In fact, our process currently walks us through the following areas of your Rails application.

  • Security of the application
  • Privacy of users’ personal data
  • Adherence to the conventions of the Ruby on Rails framework
  • Scalability of the application
  • Performance of the application and data model
  • Testing framework and process
  • User interaction (when applicable)
  • Information Architecture
  • Model-View-Controller (MVC) implementation and organization

Not only does this process provide you with our analysis, but we also provide you with our advice as to where your development team should focus their attention next. If your team is lacking experience in the areas that we recommend they focus on, we’re also here to help them through this with our consulting services. We’re currently assisting several Rails development teams with their testing process, refactoring, user interaction design, optimizing their site, improving their deployment strategy, and plan the implementation of new features.

In general, most freelancers and firms could/should provide you this service, but it should not be performed by your existing development team. They have a bias towards their process and this is your chance to get a second (or third) opinion on the work that you’ve been paying them for. If you’re spending several tens/hundreds of thousands of dollars into this product, an independent review of your investment should be something to seriously consider.

There are several different scenarios that could lead you to deciding to have an independent firm perform a code audit. In fact, I’d encourage you to always get an outside perspective of your team’s work.

You can learn more about our Ruby on Rails Code Audit service on our website or by giving us a call at +1 877 55 ARGON.

Review: Highrise, part 2

Posted by Tue, 20 Mar 2007 17:53:00 GMT

It’s been five days since I posted my initial review of Highrise, that shiny new application by our friends at 37signals. I’ve been getting adjusted to my new process of managing contacts and have had to remind myself a few times that there is a brand new tool that aims to make my life a little easier.

Contact Form Integration

I haven’t heard about a Highrise API available yet, but I will definitely be looking into tighter integration once that is available.

Direct Submissions (not yet)

It seems that Highrise isn’t going to allow direct emails to be sent to it, they need to come from an existing contact in your account. For example, our contact form sends an email to our customer service mailing list. At one point, we had it connected to the Basecamp API to submit each new contact request as a new message in a designated project, but it didn’t really give me what I was looking for. Since each user in Highrise has a custom dropbox email address, I thought that I would try to link up the contact form to submit directly to Highrise.

I got the following response back from Highrise. ;-)

Hi Robby- An email was sent to your Highrise dropbox from john@cusackforpresident.com. This address does not correspond to any address that you have recorded for yourself in your Highrise account, and so the email was discarded.

So, in the meantime, I’m following this process with new contact requests as well as the other people at PA who are responsible for responding to Contact Requests.

Contact Request Submission

So… let’s say that John Cusack (one of my favorite actors while growing up) is having a weird dream and wants to get a website built for the record store that he ran in High Fidelity.

PA Contact Request Form

He fills out the form and submits it, which our application than stores and also sends over his contact information to our customer service email address.

A few minutes later…

Manually Review in Mail.app (and apply 2-minute rule)

Here I am in Mail.app and doing a double-take… “is that the real John Cusack?” (no, it’s just test data).

Email in Mail.app

I then ask myself the following questions…

  • Can I answer this in less than 2 minutes?
    • If yes, respond immediately (forward to Highrise, if contact info will be needed again)
    • If no, forward to Highrise

Okay, so I’ve decided to forward this contact to Highrise as I decided to go ahead and speak with John over the phone, since he was kind enough to leave his phone number.

As I mentioned in my last post, I’m using Act-On for forwarding emails to Highrise.

(back-tic h)

Mail.app with Act-On

...and off the email goes.

View/Edit message/contact in Highrise

I’m now logged into Highrise and looking at my dashboard. As you can see, John Cusack is now at the top of my dashboad and waiting for me to decide if I want to do something with it.

Highrise Dashboard

Schedule Follow Up tasks

As I mentioned, I spoke with John over the phone and promised him that I’d send him a follow up email with a proposed date/time for a meeting next week.

Adding task in Highrise

...and that’s one way that I’m now using Highrise to getting all my contacts organized.

Five Day Review

Well, after five days of using Highrise, I’m still impressed with it. Our Administrative Assistant began using it last Friday and is using it to schedule follow up tasks for me. This definitely beats the old process of leaving post-it notes on my desk with names and phone numbers. :-)

We also upgraded to a paying account and paid for invoice #4.... and I plan to hit contact #200 later today within our account.

A few bugs:

  • Forwarding email from Thunderbird doesn’t currently work (as of last Friday)
  • A few forwarded emails from Mail.app didn’t work right (garbled… html emails perhaps?)

Also… it appears that 37signals has opened the doors to the public earlier today.

Have fun!

Review: Highrise, part 1

Posted by Thu, 15 Mar 2007 22:45:00 GMT

So, today I got what I’ll call a platinum ticket from one of our pals at 37signals for their upcoming new application, Highrise, which is what they’d call a “shared contact manager.” The rest of you can keep hoping that you’ll win a golden ticket this weekend. ;-)

For the past year and a half, I’ve been wanting to build some sort of contact and task management tool for organizing all of the contact requests that PLANET ARGON receives about our Design and Development and Rails Hosting services. If I go away for a week, I come back to a huge backlog of people who may be waiting a response from me. Having a tool to allow others at PA to see what is in my queue and in some cases, respond on my behalf… has been needed. When I first heard about Highrise long ago, I got excited and have tried several different tools and each of those tools has left me feeling uneasy. Perhaps I’ll post some reviews of the other tools one day.

First Impressions

The signup process looks familiar… :-)

highrise signup

Look and Feel

Well, it definitely looks and feels like a 37signals application. There might have been a time when I thought that would be silly… but really, when you look at other product suites, consistency is extremely important to the user experience. While they are definitely going to attract people to Highrise who have never used any of their other products, I’d also expect a huge majority of their initial customers will be users of their other products. It’s obvious that Highrise was in response to a void in the market that people (likely customers) were asking for in other products like Basecamp.

Highrise has all the Ajaxy goodness that you’d expect in a brand new modern web application. Most of it seems very intuitive, but I found myself getting caught up on the extra tabs across the top of the screen. When new tabs appear, my natural response was to try to close them when I was finished looking at the page. Perhaps this is just a design decision that I’ll learn to really like. At the moment, I’m still not quite sure because I expect the tabs to change quite frequently.

Highrise tabs

(few minutes later)

Actually… I wonder if the interface designers at 37signals did this to help their users avoid having several tabs open in their web browser. I use Safari for Basecamp and generally have 5-8 tabs open throughout the day for different projects that our team is working on because the Dashboard view doesn’t really give me a good feel for what is happening throughout the day on our various internal and client projects. I’ll try to pay attention to my usage habits to see if I’m opening less browser tabs in Highrise.

So far, this is the one thing that I’m not quite sure about (yet).

Highrise meets Act-On

Once I saw that you could forward emails to Highrise and it’d auto-magically create a contact and store it, I jumped for joy (not literally… but I got an evil grin). I have been using (more like heavily relying on) Mail Act-On for what seems a really long time. I’m constantly forwarding emails off to my colleagues to keep things from sitting stagnant for too long. So, guess what I did?

Mail Act-On + Highrise

This is working beautifully and allowed me to move about 20 contact requests to Highrise in just a few minutes.

With this new ability, I can remove that one project in Basecamp that I was using to collect contact request information. That information now has a proper home!

Manage your Peeps

PLANET ARGON peeps

I’m taking more screenshots and going to continue putting more of our contacts into Highrise… so… consider this part one of a short series of posts.

To be continued…