Neutral Reasons

Every so often there’s a request for the possibility to add neutral reasons to Slant. An alternative to pros or cons that is a statement without inherent benefit or drawback.

I want to have a discussion about this.


Here are my thoughts:

In most cases it’s brought up when there’s a disagreement about a stated pro or a con. For example, someone adds a pro that framework X uses Sass. That person sees benefit in all that Sass provides, while another sees it as a hassle to set up. They talk it out and over time come to the conclusion that it’s neither a pro, nor a con. It’s just a factual statement that framework X uses Sass.

And they are correct. Sort of. That statement has both pros and cons embedded within it and that’s why it can’t clearly be put in one category or another.

If the first person had added pros explaining how using Sass has benefits A, B & C and the second person added a con stating how it’s a hassle to set up, it wouldn’t be an issue and the answer would be more complete as a result. And I think that’s what we ultimately want.

In my opinion, a good p/c title consists of two things. Cause and effect. What and why. Benefit (or drawback) and reason.

It’s not only about the fact that the TV has HDMI 2.0, it’s also about the fact that HDMI 2.0 can trasmit 4K at 60fps. Inveresly, it’s not only about the fact that this TV can transmit 4K at 60fps, it’s about the fact that this TV can transmit 4K at 60fps because it has HDMI 2.0.

The first example’s more obvious, but the second one is important as well. Adding the reason for the benefit in the inverse example gives context to the claim. (I can elaborate if this needs elaborating)

Of course this could lead to an absurd situation if benefits of each and every single feature would be listed independetly. Not only would it flood the site, but how many times do I need to be explained that these 7 benefits are provided by HDMI 2.0? Especially if I already know what are the benefits of HDMI 2.0 and I can read it in the spec sheet?

If not for the length, I’d say have 1 pro title with all benefits of feature x listed and 1 con title with all drawbacks of feature x listed. With in-depth explanations in descriptions.

1 Like

Stuart has talked about possibly adding “strictly factual” product data. I imagine this would have its own section in the layout, not be part of the pro/con list. Things like HDMI 2.0 would go there, and as a thought: what if those, too, were treated as “options” with pros and cons that you could click on them to view? Then the inherent benefits and drawbacks of industry standards are less likely to see constant repetition. If the choice of a particular standard is particularly good or bad in the context of a specific product, that can still be a local pro or con.

That’s not every case of what you’re describing, of course, and “mixed bag” options were one of the first things I thought about when I started. I got as far as asking Stuart about them when I came to the same conclusion you stated here: the reasoning behind considering something good or bad is really our primary content. An argument of this kind played out on FPS Creator over its beta status and it wound up showing up as both a pro and a con through organic user action, which I think is the perfect outcome.

Are we getting anywhere on accumulating a style or best-practices guide, or just a FAQ, for end-users? This is something that should be included.

Since we’re embracing the option descriptions, it would make sense to write the factual information there. I guess price would make sense to be an exception and have it’s own section, but I don’t think spec sheets or beta status should be separated out in any special way.

As with same options in different questions, pros and cons for HDMI would change given context.

In general some kind of subgrouping / sublevel to pros/cons would create another layer of complexity to a site that already teeters on the edge of simplicity. The more I think about it, the more I’m convinced that it should be a problem solved with semantics. Something along the lines of:

  • “Benefit A, B and C due to HDMI”, explain benefits A, B, C in description then continue explaining D, E, F.
  • “HDMI support provides multiple benefits, including standout benefit X” Explain X, explain the rest.

Same thing for cons.

We just need to agree on one way we take these on and write it in the guidelines / faq / whatever.

Also, I think it should be done not with a typical guideline or similar document that the user has to read through before contributing (although these docs should be available in complete form somewhere on the site), but in a “just in time” manner. Popouts like we have when signing up / logging in, or something similar in functionality.

There have been multiple drafts by multiple people. Our internal guidelines are the best thing we have right now. And I’m re-reading them now - they have held up very well since they were written.

Once the franticness of the redesign settles down, I’ll annoy Stuart about this more.