While researching user experience design techniques, I stumbled upon some nifty whiteboard magnets for prototyping called GuiMags as well as a complementing book called The Unplugged.

GuiMags look like the nicest way to prototype something before going to HTML and CSS. Labor intensive forms of prototyping don’t seem to add much value, and paper and traditional whiteboard prototyping only works until you’ve changed your mind about something and have to throw your work in the trash or erase half the board.

Although I decided to postpone a magnet purchase until I am doing design again, I was able to get my hands on the book. Its premise: we limit ourselves by the technologies we use. Instead of thinking outside the box, we’re often thinking and functioning in it. A large part of this thinking inside the box is how we develop software.

Although, everyone interested in the topic should pick up the book, here are a few of my takeaways:

• Every major form of art that involves technology (music, film, video games, graphic design) starts outside technology. Artists do not limit themselves by their technology but by the limits of their own minds. As a software engineer, you often limit yourself by the technology you use day-to-day.
• Spend as much time as you can iterating on concept and design before going to implementation.
• Design the software front-end not the back-end first.
• Just like there are code freezes, freeze the product when it has passed the design phase.
• It is often wise to outsource the implementation.
  • This serves as a peer review of the design before it goes to implementation. Software developers traditionally think about the back-end first.
  • Different cultures have different strengths: “England and Western Europe are great at design, Ukraine and Macedonia have amazing and prompt developers who can think for themselves, the Netherlands always emails back the same day, India is extremely polite, etc.”
  • Work can be done while you are sleeping. “This can cut the development time in half.”
  • Because you already know what you want and won’t be constantly changing the design, contractors will want to work with you even if you pay less.
  • Only be satisfied with five-star developers.
  • Pay more than you agree to pay.
  • Do one-week sprints. Longer sprints end up getting delayed, with excuses.

With the last (sub)point in mind, I think this methodology is well-suited for an agile development process.

There is a lot to gain from reading the book, so make sure to grab a copy for yourself.

I’ve noticed something interesting over the past decade: commitment to social events has plummeted. When I was young, someone would plan a party or event, send out paper invitations, and get responses from people stating whether or not they were coming. It worked wonderfully. The host knew everyone got the invitation and knew how many people to plan for. It also built a sense of excitement for the get-together as people found out who else was going and speculated on what the day may hold for them.

When Evite became the normal way of sending invitations, people treated them the same as paper ones even though there was a new socially-acceptable response called “Maybe.” People responded with either a “Yes” or “No.” One or two people would say “Maybe” because of some other prior commitment that may not have ended in time. What used to be a “No” was now a viable “Maybe.” However, during the years of Evite’s reign, the “Maybe” population grew. More and more people were responding “Maybe,” not because of prior commitments, but because of subjective reasons. People confessed that they didn’t know whether or not something else might pop-up that day or if they would feel like participating the day-of.

Now that Facebook Events has begun to overthrow Evite, people have become accustomed to using “Maybe” more than “Yes”–especially if the event hasn’t reached its tipping point–the point at which an event gains momentum because of size of the “Yeses.” Often, people don’t even respond but use “Remove from my events” instead. Even the “Yes” and “No” responses aren’t certain–they tend to reflect the invitee’s excitement level about the event rather than his commitment to attend. On several occasions, a “Yes” response meant nothing because the invitee never checked her calendar.

Did Evite and Facebook ruin commitment?

I recently heard David Allen’s commentary on Twitter. He’s an experimental user and has some good thoughts on its utility. One thing he said particularly stood out to me as a nice heuristic when determining the bounds of my commitments to others and myself:

Am I going to too many cocktail parties this week? Or should I be going to more cocktail parties this week given what I’m doing?

The answer to those two questions, especially the second one, helps one discern whether or not to even go to cocktail parties…period. If you can’t answer “yes, I should be going to more cocktail parties…but for reasons X and Y, I can’t,” it’s time to reevaluate why you’re even going.

Each time a potential commitment arises, ask ”what am I doing in life right now?” If it has changed since the last time you took on such a commitment, reconsider whether or not you should take it on again. If you shouldn’t, don’t.

Awhile back I wrote about the concept of wisdom of crowds. And I referenced a great explanation of the dangers of its extremes. After a bit of thought, I’ve determined that “wisdom of crowds” needs a new name. Or rather, we need to do a better job communicating its uniqueness from other types of group thought. “Mob rule” is a bad thing, and it sounds bad too. “Group think” is also bad, but it doesn’t sound as bad as “mob rule.” Mob rule isn’t wisdom, group think isn’t wisdom, and, quite frankly, we need to realize there is objective wisdom that “the crowd” misses.

Let’s not kid ourselves. A lot of us make unwise decisions every day. Just because there are more of us doesn’t mean we’re suddenly wise.

I really don’t like system administration.

I ran into an odd issue today with Windows Printer Sharing. My parents have a desktop with a USB-connected printer, as well as a laptop. I could connect the laptop to the shared printer just fine and print to it. However, whenever I would restart the laptop, I would get “The RPC server is unavailable” or “Access is denied” when trying to print again. After a lot of searching and checking the typical firewall and services settings, I discovered that the computers were simply in different workgroups. Once I changed the workgroup on the laptop to match the desktop, things worked perfectly.

Thought I’d post this in case anyone else on the Interweb has the same issue.

I’ve been using Ruby on Rails exclusively for over a year now, but have used other web frameworks for longer periods of time (classic ASP, ASP.NET, and J2EE). Rails is unique in many ways, and if look hard enough online, you’ll find its qualities spelled-out for you.

Deprecation is one quality that isn’t spoken of much, but it’s one of my favorites. The Rails core team is adamant about doing things the best way possible. When it sees a better way of doing things, it immediately starts removing parts of the API that don’t meet that standard of perfection. Developers offload deprecated functionality into plug-ins that give teams time to migrate aging code, but the deprecated code doesn’t stay in the main code base for long.

The other frameworks I’ve used have kept deprecated API calls in for extremely long periods of time. Some I don’t think will ever disappear. These other APIs allow developers to continue using inefficient, poorly-designed, and overall bad code however long they want.

Rails isn’t simply doing things the best way possible, it trains its developers to do the same. I like that.

I used to subscribe to Yahoo Music Unlimited. It let me download as much music as I wanted without paying per track or album. It was much cheaper for me than Apple iTunes. Then they decided to shut the service down and migrate users over to Rhapsody Unlimited. Although Rhapsody is a tad pricier, I was okay with the change. I was still getting a better deal.

The Rhapsody installer worked fine and actually migrated about a third of my Yahoo Music downloads and all of my ripped CDs. Although a little disappointed about having to manually download the rest, I was satisfied.

It took me a little over a month to get around to the “big download” since my first install. A newer version of Rhapsody had since been released, so I routinely applied the update. Then I opened up My Documents/My Music/Yahoo Unlimited to see which old Yahoo tracks I needed to manually download into Rhapsody. To my dismay, the new version of Rhapsody was deleting all my Yahoo tracks (whether previously imported or not). It was systematically deleting WMA files one-by-one off my computer but leaving all the folders and any tracks I had ripped from CD. I could see it happening before my eyes. All along, Rhapsody didn’t say a word; it just acted normal and then dropped all the deleted tracks out of My Library when it was done.

If Rhapsody is manually inspecting each Yahoo Music file to determine whether or not to delete it, shouldn’t it kindly find the same track in its own service and download it for me? Or at least give me a list of the tracks it just removed so I can go find them myself? I’m not quite sure who made it, but this has to be one of the worst usability decisions ever made. It’s almost like switching over to Blu-ray and having someone sneak in and take all your DVDs back to Best Buy.

The good news is that before uninstalling the Yahoo Music Player, I had used Marc Abramowitz’s Export2Excel plug-in to dump a list of all my tracks just in case. I’m glad I did. Thanks, Marc!

I’m now getting carpel tunnel while rebuilding My Library.