|
|
|
Displaying posts from September, 2009 (Clear Search) Tuesday, September 1st, 2009
By Tyler King
Have you ever done a quick Google search before buying a product to check out how other people feel? Doesn't it seem odd how overwhelmingly negative the comments generally are?
For example, look at this Palm Pre message board. I have a Palm Pre and I think it's an amazing device. I know 5 other people with the same phone and they all love it. So why are the topics on the front page of that message board mostly about problems with the Pre?
It's because there's nothing to talk about when things are working. Nobody says "I'm so glad my toilet worked today. I'm going to go talk about it on a message board." It isn't until the toilet stops working that anyone takes notice.
I'm not bringing this up because I care about product reviews. I'm bringing it up because the same attitude hinders many peoples' abilities to adopt new technology. When you switch from Outlook to Gmail, the first things you notice are that there are no folders, messages are grouped together in a confusing way, and you can't preview emails from the inbox.*
Why do you automatically focus on those things rather than the speed increase, the convenience of being able to access your email from any computer, or incredibly powerful search? Because, just like with product reviews, you don't notice when things work well because that's the expected behavior. This causes most first-impressions of software to be taken way out of context.
Whenever you try something new (software or otherwise), make sure you don't just focus on the negatives. Conservative decisionmaking leads to boring results. If you focus more on the positives, you may be getting something that isn't as safe and comfortable, but you'll at least have a chance of ending up with something great.
*There's no question that labels are better than folders and the conversations in Gmail are a huge step up from how traditional inboxes work. I only mention them as "problems" because people don't generally see the value until they've used Gmail for a while.
Saturday, September 5th, 2009
By Tyler King
Here's some advice for anyone that ever needs to hire a programmer: Stop focusing so much on years of experience. I think this advice is probably fitting for almost all jobs, but I'm certain that it is for programmer positions.
The other day I was writing up the description and requirements for a job opening and I decided to start by going online to see how other companies do this. I was annoyed to see that almost every job posting for a decent programmer required at least five years of experience using a specific programming language.
Let me make this very clear. For any halfway decent programmer, anything beyond 6 months of experience with a specific language is meaningless. All programming is more or less the same so you should focus on the applicant's understanding of basic computer science principles rather than how long they've been using PHP, ASP, C++, or whatever. The only people that get significantly better with a programming language over five years are people that don't actually understand basic programming. By focusing on that requirement, you're effectively admitting that you won't be hiring a good programmer.
Additionally, I would suggest that focusing on any type of experience is generally a mistake. In most industries, anyone that is really good at what they do will advance quickly so they'll never be applying for the job they had five years ago. If you want someone with five years of project management experience, that means you won't get any employees that are good enough to be promoted beyond that role after five years. If they were a project manager five years ago and they still are now, that means that they aren't extraordinary (or they just really love project management, but that's rare I think).
If you need to make a conservative hire, this is fine. Take the safe pick and accept the lack of upside. But if you're trying to find unique talent, requiring five years of experience almost guarantees that you won't hire any of the best people (because after five years they've already been promoted beyond the job you're offering). If someone has only been doing something for two years, they're more of a risk, but at least there's a chance that they are an elite talent.
I'm not saying that experience should be ignored when hiring. I'm saying that it should be one of many things that you consider when making a personnel decision, and setting strict requirements will just keep the truly great candidates from applying.
Tags: Bad Decisions, Hiring Monday, September 7th, 2009
By Tyler King
I have a lot of experience helping people switch technology. From setting up a new cell phone to changing operating systems, I've seen it all. No matter who is making the switch, there's always a little but of push-back when new problems are encountered. There always seems to be the idea that the old system "just worked" and the new one, while flashy and slick, has more problems.
Is this true? Does new software sacrifice stability and usability for glitz and glamor? Obviously it depends on the software, but I think that new tools are almost always more reliable than their older counter-parts.
But then why does it seem like new software is so buggy? I think that this perception is caused entirely by the familiarity we have with existing bugs. When you're copying files in Windows XP, it doesn't seem like a bug when the time estimation goes from 30 seconds to 17 hours and back. We're all so used to it that we hardly even notice how annoying that is.
However, the first time you try out Vista, you notice that there's an confirmation window that pops up all the time for no apparent reason. Is this problem worse than any of the number of problems with XP? No, it's certainly not (especially because you can turn it off). An yet many, many people have a misguided idea that XP is better than Vista.
I'm not trying to make this specifically about Windows operating systems, but the public image problems Vista had (has?) are frustrating and they perfectly summarize the point I'm trying to make. Vista is better than XP. It's not a lot better, but it is definitely a step up and anyone that tried Vista and decided that XP was better only thinks that because they're already used to all the annoying problems with XP.
I don't want to sound like a broken record by once again saying that people should keep an open mind when trying new things, so instead I'll say that you should keep a open mind when evaluating old things. Don't forget about the problems. Don't ever stop expecting improvement. When you're complaining that your new smart phone is slower than your old cell phone, think instead about how much easier it is to text with a full keyboard or how much better the web browser is.
Wednesday, September 9th, 2009
By Tyler King
The end goal for any smart software developer is to create something that the users enjoy. It matters little what the software does as long as people like using it. Happy users generate a lot more money for you than any amount of measurable utility will. Making your users happy can be a lot more complicated than it sounds. You'd think that you could just ask them what they want, and then iteratively ask how things should be tweaked, but this can lead to disaster. There are two main reasons to avoid letting your users design your software for you. Most people aren't creative enough If you asked someone what they liked or didn't like about a software experience, their feedback could be very useful. However, if you ask someone what could be changed to make it better, you're taking them way outside of their element. Most people think of new experiences by using old experiences as a point of reference. When they give suggestions, they will think of ideas that they've already seen before. Developing great software requires some sort of innovation and you just won't get that from asking random users for feedback. Everyone is different Designing features to make one or two people happy will almost certainly lead to an improved user experience for those people. However, because everyone has different needs, you may end up cluttering up the system for everyone else. You're the only one with enough perspective to make the tough decisions. Some users might be screaming for a feature but you know that your overall customer base would just find it confusing or distracting, so you have to say "no". So what should you do? I always value the feedback of users or co-workers that aren't experienced with the creative design process. The way I keep this feedback under control is to make sure I ask the right questions. These questions are:
Notice that both of these questions focus on the user and not the design of the software. People know their own experiences. If someone hated a certain page, that's great feedback. If they wish the software would help them stay organized, that's also valuable to know. The important thing is that the way I phrase these questions leaves it up to me to translate them into actual solutions. I'm not asking how a current page could be made better, I'm just asking which ones are causing problems. I'm not asking for the user to suggest features, I'm just asking for problems that I can solve by designing my own features. I'm (theoretically) good at designing things, so the user is better off letting me do my own thing.
Tags: Design, User Feedback Monday, September 14th, 2009
By Tyler King
I had to deal with some pretty terrible software earlier today so I thought I'd share. I've been getting emails from my Alma Mater that I really have no interest in, so I clicked the "unsubscribe" link at the bottom of the email.
First, let's go over what I expected. I expected to go to a website with either a confirmation that I was removed from the mailing list, or a button that would allow me to finalize the unsubscription. That should be the end of the interaction
Here's what happened instead:
So let's recap. After clicking the "unsubscribe" link from the original email, I received another two emails, had to fill out a form, and saw a total of three web pages. When my goal is to unsubscribe from emails, sending me more emails seems like a pretty confusing response. I could understand if they were a spammer and simply wouldn't accept my unsubscribe request, but they were clearly trying to accommodate me.
This is an example of annoying software. We're trying to promote less annoying software. If you want to see how this process should work, subscribe to email updates from this blog, then click the link to unsubscribe at the bottom of the first email you receive. I bet it'll be a little easier than what I described above. However, it will hurt my feelings if everyone unsubscribes, so I hope you re-subscribe after testing it out.
Tags: Bad Software
|
New posts will be emailed to you each night
About this blog
This is a blog for small businesses interested in how they can better use technology. Most tech
is targetted at either individual consumers or huge corporations. We'll help you find the tools
that are powerful enough to help run your business, but simple enough that you won't need an I.T.
team to use them.
There are two main writers on the Less Annoying Blog: Tyler has worked on the tech side of several small businesses and knows first hand what the little guys need, and don't need. Bracken is finishing up a PhD at MIT and he's always experimenting with any new software he can get his hands on. We also run an online customer manager tool called Less Annoying Software which was created specifically for small businesses to track all their customer activity.
Search the blog
Tips and Feedback
We obviously want to write about things that you want to read, so help us out! If you are
interested in reading about a particular topic, let us know. We're also always on the lookout for
new software and tools to try out (and review), so feel free to forward information on any new
tech you'd like us to write about.
You can reach us at blog@LessAnnoyingSoftware.com
Archives
|
