Topic on Talk:Reading/Web/Projects/Related pages/Flow

The feature as currently designed is basically trying to do what editors are supposed to do - it's trying to add relevant links onto the article. I'll skip the rehash, but there's a long list of reasons it doesn't meet editor expectations for what should be added to the article. They aren't really fixable without strong AI.

How about reskinning it as "Find Similar Articles" button, perhaps below the Search button? Instead of returning three results, you can return a long list of results. A long list of random-quality links (including some "unfortunate" machine selected results) isn't going to raise any objections when it's presented in a "Search Results" style. It's very clearly not "in" or "attached" to the article.

+1!

I like this idea! It is an interesting alternative. It sounds, primarily, like further changes to to the feature to make it more obvious it is not part of the content and is (primarily) algorithmically derived would be helpful. I would, however, like to keep it at the bottom of the page, as that is the part of the page where a user who is looking for more/different information would find themselves.

When you said the bottom I was amusingly confused for a minute, chuckle. The bottom of the article is generally considered the lowest value territory, but I can kinda see your point. But somehow having it at the bottom makes me think webchrome gizmo rather than a basic search-result-list. (Maybe I've seen too many carousel gizmos recently.) I was picturing either something like our search page, or maybe simple dropdown list with one article per line. Editors tend to like our webchrome-avoiding aesthetic... sorta like Google. Google mostly avoids webchrome effects, and when they do use them they are so low-key that they don't even look like webchrome.

Good point's @Alsee. I was focusing more on the "It's very clearly not "in" or "attached" to the article." and making it more obviously algorithmic/part of the chrome, and less focused on the specific recommendation of making it more of a "Search results" component.

Sounds like the primary purpose of making it more like a search results component as opposed to keeping it on the bottom would be to reduce the chrome.

"Editors tend to like our webchrome-avoiding aesthetic... sorta like Google. Google mostly avoids webchrome effects, and when they do use them they are so low-key that they don't even look like webchrome."

This is an important and valuable aesthetic, but even google recognizes that there are limits and how you apply them depends on specific user-intent (search is diff from gmail). Since there are more than 30 buttons (links) in the chrome of any wikipedia article page (not including the footer, the lack of visual differentiation means it is very easy to ignore, but also very hard to use. As a result, most navigational elements are ignored. A reader (or new editor) has to read every single link before clicking instead of using visual cues. I would rather see us move towards limiting the menu items to those which we think are helpful to a user (and making them easy to user) or hiding them for that user. I think it is well established that visual cues generate a lower cognitive load on the user, which is one reason even google has been slowly adding more cues in gmail. In search, they have not... and it is unclear whether this is for functional reasons ( essentially hiding the options) or for brand/historical.

this is just a screenshot of gmail's header with annotations to highlight their use of visual buttons

It's kinda funny, but I had mentally skipped past the fundamental graphics style issue. When I said "webchrome gizmo" and "webchrome effects" I actually had in mind browser-effects. Like a carousel: http://shouldiuseacarousel.com (hint, the answer is no, chuckle). For some reason a carousel was the first awful thing to pop into mind at the bottom of an article.

Anyway.... what did you have in mind when I suggested reskinning the product? Because moving the links around the page doesn't help. Adding boxes or graphics or any possible styling doesn't help. That still serves up an article with a random brand name spamvertizement attached. My suggestion, which TMg gave a +1, was something like "Find Similar Articles" button. The button would be the only thing served up with the article. Even my router wouldn't even see random brand names coming down the wire while reading the article. If someone clicks the search box, or clicks a "Find Similar Articles" button, and they actively request a page full of semi-random generated links, no problem.

@Alsee Sorry for the delay and thanks for clarifying. Again, I thought that by "reskin" you meant something to make it more clear that these were algorithmically generated results.

The notion of hiding "read more" unless a user clicks is interesting and there is certainly precedent for it. My concern is that collapsing behind a button is essentially hiding it, and if we don't want to show something, we probably shouldn't show it at all*. I think it would be better to make related pages a feature that people want on by default than make it something that most people wont want and then shrink it. We already do this with our >20 link left-hand menu and our navboxes.

If the issue is that Mercedes or other brands show up algorithmically, then that is a separate issue we should address. I personally think that if an algorithm selects a brand, because the brand is most relevant, it is NPOV (same applies to search results). But, community certainly rules on what violates what.

*Some exceptions and rumination

Top of article/navigation: I think that in some places condensing or hiding useful information is appropriate. At the top of the article, for instance, condensing and hiding information that isn't absolutely necessary is very important because real estate is so precious. Collapsing sections on mobile is something we do for a related reason (to enable navigation on a screen where scrolling large amounts is challenging), but is also controversial. Because so few readers actually click to open sections (40% of users, not pages), I am actually am looking into whether it reduces learning, .

Data: Another exception is purely reference information, like the kind we see in navboxes--data that one could look up, but isn't necessary to learning.

Breaking context: entire other pages with different subjects or purposes (like talk pages)--there is a reason you don't scroll down into the talk page...