I had the opportunity to design an icon for the newly launched Deals feature in Highrise. Jason approached me one morning to think of some icon ideas to depict “Deals”. The development site used a stack of gold coins icon that Ryan had created, so I used that as a jumping off point. I started sketching variations of stacked coins. After a few minutes I decided to think about it in a different way. The word “Deal” kept bringing me back to the concept of card dealing. Card dealing is in no way related to the Deals feature however. I just couldn’t shake card dealing from my head, so I started sketching stacks of cards. I really dug the form that the stacked cards were making. The missing piece was: How is this related to “Deals”? I decided to take some inspiration from Super Mario Bros. and add a star to the top card. I finally had an idea to kick around with Jason and Ryan.

Jason and Ryan were not sold on the star idea. I assured them that it needed more development, so I started producing the idea in Illustrator. I usually start icon work in grayscale. It is way too hard for me to lock down colors right away. The nice thing is that I can concentrate on getting the form just right. Color can always be added later. Once I completed the form I realized that I had the perfect icon. In the Deals tab of Highrise you can set your proposals/bids as Pending, Won, or Lost. The black and white icon would be the Pending state. I would add green for the Won state and red for the Lost state. It was all coming together. There was a problem though. Jamis and Ryan were already deep into development, and this dynamic icon concept would add scope. I shelved that idea and went back to Ryan’s original gold coins icon. Let’s use gold for the Deals icon.

Jason and Ryan were still not digging the star. We went back and forth for about 10 minutes when Ryan had a great idea. Let’s ditch the star for the currency symbol. When you’re dealing with USD proposals then use a dollar sign. When you’re dealing with Yen then use that symbol. I loved that idea and started producing the rest of the icons to map to the currencies that we currently support in Highrise Deals. It is refreshing to work on a little project like this. Jason and Ryan were able to make quick decisions about my icon design direction. As a result the project took less than a day to finish with a majority of my time spent learning about the feature. Side note for those that have kids: WebKinz KinzCash uses the same symbol as the South Korean Won. Feel free to track Deals in Highrise with your WebKinz Krazy kids by using the Won hack. You heard it here first.

I recently acquired an old farm house in rural southwestern Wisconsin. I’ve always wanted a place out in the country. With the real estate market taking a hit I figured this was a good time to buy. Time will tell on the financial return, but the peacefulness return is already paying off.

However, it’s not all about relaxation — I do want to work from there from time to time. Foolishly I assumed that broadband was just about everywhere now, but it’s not. If you’re a mile off the highway, or not in a town of thousands, you may be stuck in the 90s.

DSL: Too far away

First I checked into DSL. Verizon provides it in the nearby town which is a few miles away. But the central office is too far from my house so it’s a no go at this time.

Cable: Not available

Then I checked with the local cable company. There aren’t cable lines in the area so that’s not an option either. No cable TV and no cable internet.

Wireless ISP: No line of sight

I discovered an interesting option from a neighbor over the hill (land, not age). He uses a wireless service. He has a dish-like-thing on his roof and he has a line of sight view to one of about a dozen towers in a 30 mile radius. The speeds are multi-megabit up and down, there are no transfer limits, and it’s about $40/month. It’s a pretty sweet service. Unfortunately (from an internet service perspective) my property is stuck in a valley so I don’t have line of sight to any towers. They even tried climbing this old windmill on a hill, but it can’t see any of the towers either. So that’s a no go.

3G EVDO: Not in range (but I do get EDGE)

I have a Sprint 3G EVDO card which is wonderful when I’m on the road in big cities, but there’s no 3G out where I’ll be. I do get EDGE out there, and the card can handle that, so I can get access but it’s very slow. At least it works. I checked Verizon, AT&T, T-Mobile, and US Cellular, but no one has 3G out there. US Cellular has the best cell coverage, but it’s EDGE-speeds at best. US Cellular does say they are rolling out a 3G network starting early next year.

T1

I don’t even know if this is an option, but I fear if it is it’s going to be hundreds or thousands to install and hundreds a month. Not an option for a sometimes house.

Satellite: Please no

It appears the only way to go is satellite. That means the horribly reviewed HughesNet. Terrible customer service, satellite latency (who knew the speed of light wouldn’t be fast enough), 2-year contracts, hardware and fees, and draconian download limits (200 MB/day or they throttle you way down).

Is anyone out there using HughesNet? I know message boards and forums are usually filled with the worst of the worst complaints, so any personal experiences with this service would be useful, thanks.

Any other ideas?

Please tell me someone has a really creative solution here. Is there something I haven’t thought of? Any geniuses out there with an answer? I’m afraid I may have exhausted my options beyond satellite. So satellite it may have to be, but I’m hoping there’s another way.

A few weeks ago at our Maine meet-up, David was telling a story about preparing for his latest RailsConf keynote. His plan was to talk about bad code from our own apps, and we were cracking up when he explained his hunt for all that “crusty gold” buried in our repos. I ran into my own nugget of crusty gold today while taking a peek at Basecamp’s footers.

The footer of each page in Basecamp may show a badge that says “Managed with Basecamp.” I wanted to figure out when and why that badge is displayed. So I found my way to the relevant template and saw this:

<div class="Footer">
  <% if @account.free? || @account.show_footer_badge?%>
    <a href="<%= @account.free? ? "http://www.basecamphq.com/?ref=free" : affiliate_link %>" target=_blank>
      <img align="right" width="112" height="30" src="/images/poweredbybasecamp.gif" alt="Powered by Basecamp" border="0" align="absmiddle" style="margin-right: 8px;" />
    </a>
  <% end %>
</div>

The first order of business was the question: Under what conditions do we show the badge? The first condition, @account.free? is clear enough (it means the account is on a Free plan). But what’s up with the second condition: @account.show_footer_badge?

Since the method is on @account, the first place I checked was our Account model. But it turned out that show_footer_badge? isn’t a method. It’s a column on the database. That meant I had to find where that value was being set by the user and saved into the DB to figure out what it really ‘means’.

Some grepping revealed that show_footer_badge? is actually a relic from our first BC affiliate program. People on this old program had the choice to check a box to hide or show the footer badge to all their employees and clients using their Basecamp account. What’s crusty about this? The problem is that @account.show_footer_badge? gave me no indication that this is really about affiliate settings. A simple change to the name of the method would have really clarified that:

  <% if @account.free? || @account.affiliate_wants_to_show_badge? %>

This comes back to a favorite design pattern: Intention Revealing Interfaces. @account.show_footer_badge? says what to do, but it doesn’t reveal the original author’s reason or intention.

To round out this nugget, let’s improve that nasty anchor and image tag from the first excerpt above. We’ll use a Rails helper and some CSS to clean things up:

<div class="Footer">
  <% if @account.free? || @account.affiliate_wants_to_show_badge? %>
    <%= link_to basecamp_url_with_affiliate_code, image_tag('poweredbybasecamp.gif'), :class => 'affiliate_badge' %>
  <% end %>
</div>

The next time we go digging into Basecamp’s footers, this code will be a lot easier to understand.

Related: Behind the scenes: Redesigning and coding the Highrise sidebar modules, What belongs in a helper method?

For a while we’ve been exploring switching to WYSIWYG text editing in our products. Up until this point we’ve been using either plain text, manual HTML, or Textile formatting. Depending on who you are it’s either fine or annoying. We want to do a lot better.

We’ve looked at a lot of existing options (Yahoo’s WYSIWYG plug-in, TinyMCE, etc), but we weren’t happy with any of them. Currently available WYSIWYG editors don’t offer much flexibility when it comes to modifying their look and behavior. You are stuck with their HTML, buttons, and design. Modification was possible, but it was really ugly behind the scenes. We really needed a framework for building our own editor with beautiful code and a low cost of change.

WysiHat

So we decided to make our own. It’s called WysiHat and we’ve open sourced it. Get it? WysiHat. Hat instead of Wig? Funny, we know! Today we’re releasing a very stripped down early developer release.

WysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it.

We are giving developers early access to the project while we continue to work out the remaining issues. Note: It’s extremely early. Contributors are welcome so please check out the project on GitHub and send us your feedback.

From the Business of Software conference in Boston, September 2008.

Today we officially announced a big new Highrise feature called Deals. Deals lets you keep track of proposals, bids, and estimates you’re submitted, won, or lost.

This new feature is especially handy for designers, developers, contractors who bid on projects for clients. Now you’ll know which proposals are still out for bid, when you sent them, who you’re expecting to hear back from, which ones you won, which ones you’ve lost, and how much money you’ve made from each customer.

I wish I had Highrise Deals when we were doing website design. I had a hard time remembering all the RFPs we’d responded to and how many projects we’d won or lost and why we’d won or lost them. Saying I was disorganized would be kind.

The best way to get a feel for the new feature is to watch a video demo:

(See a bigger, clearer version on the Product Blog)

If you don’t have a Highrise account, sign up today. If you do, we hope you find Deals useful! Thanks again for your continued support.

A couple months ago I posted “Sour Apple: How an Apple ad sets the wrong expectations” here on SvN.

I felt that the interface response time and network transfer rate was unrealistically fast. It looked like they had to cut out a bunch of frames to make things as fast as they were advertising. I felt that was deceitful without claiming that the sequence was simulated or shortened in some way.

Yesterday I noticed they are now adding some fine print to the bottom of some of their ads that says “Sequence shortened” (the red box above is mine for emphasis).

It’s good to see them adding the disclaimer to these ads. The fine print doesn’t distract from the ads in any way. I think it’s a win-win.

Having great taste is one of the most important characteristics of designers, programmers, and managers alike. Being able to discern what’s good from that which is bad. Which of the thousands of possible little details are key to make whatever you’re working on just right.

The problem with the concept of taste is that it’s so ephemeral. One view of the world is that some people just have it and others don’t. Either you’re lucky enough to be born with it and you’ll be forever awesome or you’re a tasteless sod doomed to create crappy work. I don’t subscribe.

I think taste is mostly about developing an eye for the details that matter and that it’s absolutely something that can be learned. The best way to learn what details that matter is to examine the details of great and not-so-great work and contrast and compare.

It requires determination and dedication to develop an eye, to develop your taste, but it’s absolutely possible. Some may be predisposed, but anyone willing to be a student can get there. So what are you waiting for?

So, you’ve got your scope creep, and you’ve got your feature creep. Lately, though, I’ve been thinking a lot about a little gremlin I’ve been calling “future creep”.

Future creep is not about adding features to your products. At least, it is not directly about that. Rather, it is about adding infrastructure to your products in preparation for features that may or may not be added later. In the future.

This is really subtle, because it can happen even (or perhaps especially) when the feature list for a product has been frozen. So, sure, you can’t add any more new features for this release, but there has been talk about some new feature X being added eventually, and if you just tweak the code a bit here and here, and maybe there, the way can be paved for X that much more easily!

That feature X can be anything: a programmer interface (API), a drag-and-drop UI, element categorization, data export/import, batch processing, anything at all, anything that you don’t intend to implement immediately, but which has been bandied about as a possible addition someday.

Paving the way doesn’t sound bad at all, though, does it? In fact, it sounds proactive and laudable. And if that feature X goes through in a timely fashion, exactly as you envisioned, I’m sure you’ll be praised for your foresight.

BUT.

Even the simplest of potential features can be implemented in a number of ways. Or not implemented at all. At best, your “foresight” can result in wasted time, where you spun your wheels for a few hours (or days!) playing “what if” and “let’s pretend”, trying with too little information to think of how best to architect your code to accommodate that future feature.