July 12th, 2003


Information before killing features?

Recently, there have been several major code changes which removed functions of LJ which are used often by users, with no replacement available and no discussion until after of why they were removed or when they plan on being replaced.

I understand the need to speed things up, and temporary removals of features are fine - with planned implementations to replace them. The need for speed is a true one at LJ, and I understand that.

However, if popular features are going to be removed, there are a couple ways to alleviate the pain that comes in with that:

- Make some kind of indication to the development community that the feature is being removed, with reasons and how to fix it. This lets people get started (or at least realize that work needs to be done) on a replacement, so the site isn't left without sometimes important features.

- Make the community at large aware that a feature is being removed, and why. lj_maintenance is good for that: "Community searching is down while we rework it. For more information on the reason, and the planned fix, please see $lj_dev_entrylink."

Currently, both findsim searching and community searching by interest are broken, with no timeline set for repair. (findsim, community search.) Brad has stated opinions on them - but in both cases, by proxy. I had to make a post to get an answer on community search, and whitaker passed on information for the findsim bug. Although brad and brad may speak as one voice, they just aren't the same.

Basically, this is just asking for a little heads up before features die, both to the development community and the community at large. I know that the users will thank you, and I'm sure the support team wouldn't be all too upset about it either.

As a side note: Ideally, all features which are not being permanantly killed should be replaced before being removed. However, I realize this is not always the most effective way of doing things, and sometimes things just need to happen fast. This method allows at least some form of compromise.

Happy coding.
  • Current Mood
    hopeful hopeful