Board Thread:Technical Updates/@comment-24006128-20200423160701/@comment-9605025-20200429032439

reply to #67 Fair point. However, I am guessing it was easier for Fandom to simply program a redirect from User_talk to Message_Wall rather than go into the core and change everything there. - reply to #68 It is true that the search bar in the global navigation header is a bit confusing. That is something that keeps popping up as a topic now and then. However, in terms of the position on screen, it is the same as Gamepedia; the top-right corner.

I can understand your frustration with having to use drop-down menus instead of having every option openly displayed. I think the over simplification of interfaces is a real issue with web design. That said, the drop-down menus are clearly indicated.

Again, I look at what you are trying to access and I don't think the issue is that they are actually inaccessible on Fandom (except for talk pages). To me, the issue seems to be just that they aren't where you, as a Gamepedia editor, expect them to be. Likewise, I think a Fandom editor would have some trouble adjusting to Gamepedia's layout.

To address the talk pages, I think that ultimately is yet another thing that comes down to habit. Your apparent obsession with links to talk pages is because you see that as critical to having discussions on the wiki. However, if you go to talk pages on most Fandom wikis, you will see nothing there. Why? Because Fandom holds discussions using these other features which you find odd because you have never used them before. However, from the perspective of a Fandom user, what is the point of linking to an empty page? One thing that is nice about Fandom's discussion features is that only the author and admins can edit posts. If you posted a comment on a talk page, there is nothing stopping me from completely rewriting your comment. Yes, users can look through the page history. However, new/casual users aren't going to even know to do that. By having these additional editing restrictions, Fandom's discussion features prevent vandalism and confusion. Users can't claim (as easily) "I didn't write that! Someone is trying to frame me!"

Fandom has long been obsessed with the casual reader/editor. Neglect of the poweruser is an issue that has long plagued Fandom development and one that they fully acknowledge. However, if we grant them that they are focusing on the casual user, then the changes they have made make sense. Whether or not they are neglecting the powerusers too much is a separate issue. To this end, I think Discussions v. Forum is a perfect example. However, based on a glance at the following posts, I think I will save that topic for later. This is just speculation, but I think the focus on readers is due to how Fandom makes money. Fandom is entirely ad-based. There is no "Pro" subscription you can pay for like you do with Gamepedia. Since reduced ads are available to all registered users free of charge, Fandom's dependence on anonymous readers grows stronger. Hence the focus on drawing in readers rather than pleasing editors.

I agree that Fandom and Gamepedia put forth very different images regarding their brands. That is partially why I am skeptical of this "unification" process. If you want a really good example of the difference, just look at how the interwiki map is handled. On Gamepedia, local admins can pretty much do whatever they want. They can add whichever sites they want and even allow transclusion. On Fandom, it is the complete opposite. Nothing gets added without Fandom's approval (and they are pretty stringent on what is "acceptable"). Even then, transclusion is never allowed (except from Community Central). - reply to #70 There is a decent number of users here on Community Central that agree with you. Unfortunately, I don't think we will be getting the old source editor back anytime soon. As MisterWoodhouse already explained, the new JS-based editor is the factory default (plus a few Fandom tweaks) for this new version of MediaWiki. - reply to #72 Part of the issue with the new editor is the distrust generated by the now-legacy VisualEditor. That editor was (arguably still is) constantly plagues with bugs and quirks; all while offering only the basic most functions. While the now-legacy VisualEditor does offer a source mode, you have to revert to visual mode in order to save your changes. Therefore, any issue with visual mode automatically because an issue for source mode as well. Past issues have run the full spectrum from deleting content that wasn't changed to adding tons of interface-related XML upon saving. One of the most frequent issues that new users have is the caching. They will make a change to a template but the VisualEditor won't recognize the changes. Removed parameters will still appear and new parameters won't show.

My biggest issue is with the compatibility for older browsers. However, as Fandom moves more and more towards the future, that is becoming a larger and larger issue for more and more of the entire platform; not just the editor. In most cases, a simple JS polyfill would go a long way. I'll stop here since I have ranted about this before. - reply to #73 BowiQC, since you are not as familiar with the variety of discussion features on Fandom, here are some links to examples. - reply to #76 I am well aware of what the Dashboard is. As a frequent Community Central editor, I noticed it the day it was added. What I am saying is that right now it is a custom JS script imported from the dev wiki on a per wiki basis. It is not yet a standard feature applied farm-wide. Furthermore, as I previously explained, I don't think it adds much value. But that is just my opinion. Clearly you disagree.
 * wiki-style forums (a.k.a. DPLforum)
 * 1) Thread-based discussions (retiring with transition to UCP)
 * 2) Forums (you're in it right now)
 * 3) message walls
 * 4) article comments - scroll to bottom of article
 * 5) legacy blog comments - scroll to bottom of blog
 * 6) Feeds-based discussions
 * 7) Discussions - already on some legacy-platform wikis
 * 8) message walls
 * 9) article comments - in the works
 * 10) blog comments - blogs may not be ported