Comparisons should support tables, barely usable now

Feature Suggestions
1

The way comparisons are implemented, it’s almost impossible to use them now. Every option has its own reasons, nobody tries to add the same reasons for all options (for example, pro for some, con for others). Even if reasons were similar, they are always sorted by votes. Even sorting and naming were adjusted, and reasons were the same, they just don’t fit on the screen. Only three options can be compared, with no way to choose which (they are always sorted by votes too).

All this makes comparisons unusable for comparing options. While they can be improved, I don’t see how to make them useful. However, it may be unnecessary.

Wikipedia has many comparisons where items are presented in a table: options as rows, reasons as columns and yes/no/?/some-other-short-text as cells, with optional footnotes below the table with citations and more details (both on properties and values). Comparisons can contain multiple tables, grouped by reason groups. For example:

I’d like to see this feature implemented on Slant. In order to do this, neutral reasons (properties?) need to be added on the question level. Each option can have a short value for each property, a long value (if explanation is necessary), and sources. Properties can have a detailed description to be included below the comparison table and/or in some other way (“?” with hints, for example). Properties can be grouped into property groups (can be implemented later).

On the option page, properties can be presented as a two-column table: property — value. Long values can be displayed right after short values because there’s enough space. Users can change values there, add values for properties without values etc.

But properties will truly shine when options need to be compared. With data like this, tables like on Wikipedia can be constructed. Later more prettiness can be implemented, like user being able to choose which properties to compare, searching by property values etc. Having structured data is great.

Related discussions:

1 Like
2

Well you have good timing. We’re working on a basic initial version of this at the moment. V1 is going to look like something like:

We’re not going to expose the editor initially as it’s going to just be a text field with JSON that we parse on the front end. Once we can see it live and experiment with the data we can nail down some requirements and properly build it out. Some additional thoughts:

  • I had not considered having sources for the table. It makes sense in some scenarios, but will greatly complicate the editor. Perhaps in later versions.
  • The JSON approach in V1 will give us the flexibility to experiment with many different table formats (long data, short specs, boolean)
  • We need to be careful to be simple and clear with what should be in the table and what should be a pro or a con. I anticipate a bit of overlap, but if a spec in the table needs further explanation/context perhaps it would be better off as a pro/con.
  • We’re looking into ways to automatically pull in some data (price, size etc) via some third party api’s

Something I didn’t consider, but I can see the use-case for. It won’t make it into V1, but I’ll add it to the roadmap. Coming up with what data we want and how to show it is easy, it’s the generation UX that gets overwhelming/hard if we fuck it up.

I wonder how many comparisons are truly complex enough to warrant this outside of the programming field. I read the wikipedia article you linked, and that level of detail/complexity is something that would be exciting if we could have in our format if there was a big need for it across a lot of our questions.

Thoughts on the mockup @Athari?

1 Like
3

The wikipedia article goes into a level of depth where it’s practically documentation. While it’s great that there is a complete comprehensive resource that compiles every tiny difference, I’m not sure that’s the goal we want to strive for?

I think we want to be a bit higher level than that to direct people to the differences that have the most practical impact on your usage. We definitely want spec tables, but a lot of what is in the wikipedia article, we probably wouldn’t want, although there is definitely a lot of good examples of the kind of information we do want in the article as well.

The article is complete for the sake of documenting every difference in detail, which is great for posterity, but we should be focusing on a more curated list of differences, with each point having a practical reason for being a pro or con, i.e. “Feature X is good in C# because it enables you to do Y”.

When it comes to properties, I think they should also be there if they have a practical impact in helping you make a decision, and not just compile every possible difference just because it exists. I like the idea of having a “?” to potentially explain why that property is important, and what to look out for when making your decision based on it.

4

@StuartK Too much space is wasted in the mockup. It makes comparing actually possible, but it’s far from being useful. It still compares just three options. Most questions have much more options than three.

What does the “Hide” button do? Hides the option and loads the next highest voted one? It will be too hard to use this, I’m afraid. It doesn’t solve the problem of comparing more than three items at all. What should I do if I want to return the hidden one? Too confusing.

You can use a list of checkboxes instead to make switching between displayed options easier. However, displaying just three options still won’t be enough.

And by the way, tables and comparisons shouldn’t be constrained by the usual page content width. Users should be able to use all available screen area.

In some cases, it’s very important. I’m thinking of property values as something similar to reasons: property name (from a dropdown), property value, sources. If compact tables are implemented, the need to provide both short and long value will complicate things though.

Well, professional tools is the area I actually care about. :slight_smile: Properties in other areas (games, books) will be much simpler: OS, price, year, several others.

In areas like gaming comparisons don’t make much sense anyway, I think. If I’m looking for a game to play or book to read, what I actually need is a list of popular stuff with several reviews. I don’t really care whether a game uses DirectX 9 or DirectX 11, what language it’s written in and whether it’s open-source. Even prices for games aren’t too far apart. The list of properties will be short, the list of options can get very big. I’m definitely not going to use comparison view in this case.

Why not? When choosing a professional tool (programming or not), I often have to delve into tiny details, and in these cases detailed comparisons are very helpful. Professional tools have hundreds of features and people tend to use only a small part of them. However, everyone uses their own subset of features, so having a complete list is the only way of providing information for everyone.

Look at this comparison:

It has 33 properties and 19 options. All properties and all options are very important, you can’t remove any of them without sacrificing quality of comparison significantly (well, a couple, maybe). You can’t move to “higher level”, because it’s already high.

But neither Features table nor Available version control systems table can be presented on Slant. All options must be displayed at the same time, my brain will melt trying to remember property values of all websites if I can see only 3 options at the same time. The same with properties.

5

Haha I knew you would hate the 3 options at a time part of the design. What if “Show all” initiated a modal that used all available space and optimised the UI for actual comparing? Giving it it’s own dedicated view would make it easier to build more complex things into it like sorting etc without cluttering up the basic view. It would also be useful in that the gaming etc question could have 3 super basic specs shown while still allowing a UI optimized for crazed technical people to get into the nitty gritty.

6

Er… I don’t get what this picture is supposed to mean.

7

Sorry, was in a rush and didn’t want to spend the time mocking it up. Here is a proposed flow:

  1. Compare page as per my initial mockup (three columns etc)
  2. User pressed “show all” (the gray bar in the current mockup)
  3. A fullscreen modal appears on top of the compare page that shows the Wikipedia like comparison table. In full width + lots of options shown instead of just 3.
8

There’s a tool for comparison tables called Social Compare. Some badass examples:

1 Like