Hacker News Reader

Comment by RyanZAG | Hacker News Reader

Good article, makes an important point about complexity.

Just want to add one extra thought though:

  he or she will run reports against the usage data to find
  out whether a given feature is often used. That data can
  then be run past the product managers who can help decide
  whether it's sensible to just drop the feature.

It's important to be careful here, and it's one of the traps that is very easy to fall into (see Gnome). Just because a feature is only used by 1% of your users doesn't mean it's not important. You might have 100 features only used by 1% of your users each, but if you take out all 100 features, chances are you've taken out at least one feature that every single one of your users depends on, and now your product is a lot worse instead of better.

View on HN

You could also drop a feature used by 1% who just happen to be the 1% who make the buying decisions or are vocal.

I call these User Landmines (they are quiet right up until you step on one).

We hit this at MSN: we removed the "print" button from all articles. Result? Engagement in Japan fell. Why? Apparently, printing out a sheaf of articles to peruse on the train is (or was) a thing. Solution? Re-enabled the "print" button in Japan; everyone else was saved from downloaded the unused-in-market "print" button, lowering PLT.

Please keep in mind I'm talking about stuff from about five years ago when you run to MSN.jp looking for print buttons.

Seriously doubt this has changed, even now Japan sells millions of fax machines a year domestically, Japan loves paper.

Problem is then that you have two cases that need to be tested and taken into consideration when designing etc.

On a similar note, this bit caught my eye:

It's often subtle or intentionally hidden features that cost the most in the long term. Yammer has long had a feature that allows you to begin a message with "to:" and a username to send a private message to someone, or followed by a group name to post to a group. This probably took me an hour to implement, test and deploy back in early 2008. I have easily spent 40 hours of my time -- and, necessarily, 40 hours of others' time -- over the intervening 5 years explaining this feature and its justification.

One likely reason why an engineer - as opposed to a sales or customer support rep(1) - might end up spending as much as 40 hours explaining and justifying a trivial, implemented and documented feature would be a culture obsessed by removing perceived cruft.

(1) If competent sales or customer support reps spend 40 hours talking about a feature then some conceivable variant of it has some perceived value to someone...

I have to say that two man-weeks in 5 years for a feature with pretty high utility doesn't seem that much of a burden. However, I'm quibbling over words- I agree with the general thrust of his argument.

That's how I feel about Apple deeming unimportant my Home, End, PgUp, PgDn, and front-delete keys.

RIGHT ON, BROTHER!

Just in case you’re not aware: the Fn key, in conjunction with the arrow keys or the delete key, let you type those keys. Though that’s certainly not as convenient as having dedicated keys.

Also, you can remap different keys to those keys with the free software KeyRemap4MacBook (https://pqrs.org/macosx/keyremap4macbook/index.html.en). For instance, you can remap \ to be forward-delete and Fn+\ to be typing ‘\’.

That's fine and good, until you want to use key combinations that include the missing keys, particularly selection type stuff. For me, it comes up a lot in programming, writing, and file/photo management.

I find that Shift-Fn is particularly easy to chord since they share a boundary. I usually use pinky on Fn and ring finger on Shift.

No one is using this password reset feature, lets drop it.

Reply on news.ycombinator.com