As Lumoshi said, recent changes serves the exact same purpose for MediaWiki-based edits—comments and forum posts are now on a separate log. Wiki Activity combined these, into a place to check what the community was editing and talking about.
I always knew of recent changes. It comes with MediaWiki; it was near the top of the Wikipedia sidebar. Wiki Activity was simply way more comprehensive (see above), informative (images and categories added, number of messages in a thread, achievements earned, the sidebar…), user-friendly (item and link icons, relative timestamps, profile pictures, information spaced across multiple lines…), and inviting. You could see what was going on.
Recent changes is just unglanceable text and links. That suits other wikis just fine, but Wiki Activity catered to Fandom's unique suite of features. It felt like the lifeblood of the whole wiki farm. Its removal tanked my impulse to check Fandom wikis, something I used to do every few minutes.
I can attest to communities drifting apart after UCP, and to newcomers who are only active on Discussions. My editing experience across, like… at least seven Fandom wikis, over the past few years?… has felt isolating and antisocial. This is regardless of how active i was (from occasional contributor to main editor and admin) or my efforts to spark conversation. I don't want to pin that on the users if i have reason to believe in systemic factors like these.
Is it possible to request a wiki to have the Page Previews and Reference Tooltips features, which sites like Wikipedia use, installed?
If not, could we request this to be added sitewide, or would it just not be compatible with, or available to, Fandom? And are there any Dev Wiki scripts you'd recommend to emulate this feature?
It's really nice to have LinkSuggest back!
I'm having a minor issue where empty LinkSuggest boxes appear. This is especially noticeable when the text insertion caret is after a pipe in the link or template syntax. For example, [[File:Example.jpg|thumb‸]] does this.
If it's checking for page titles starting with File:Example.jpg|thumb, then the box of 0 results should be hidden, right? But I'm not totally sure that that's the intended behavior, either.
I'm not sure I get what you mean. I'd wager that most FANDOM users create content with Oasis in mind, because Oasis is the default skin, and therefore how viewers will use and read their content by default. Anonymous users with knowledge of ?useskin are a fringe case.
I hope this means more work can go into improving the end-user and administrator experiences on wikis, now that there won't be a secondary skin competing for maintenance.
Yes, but eventually the staff will replace all forums with Discussions.
Ah, never mind then. Sorry for the misunderstanding.
Being forced to use a specific style on a new feature makes adaptation harder for everyone, and no fallacy of relative privation will change that.
Here's a petition thread that may interest you, for the lack of CSS/JS customizability in the new header.
It's not that the update itself is necessarily bad; it's that locking communities out of customizing the presentation of their own headers, even on the level of font, is something we are dissatisfied with.
Even if the staff don't listen, I think it's still important to make our opinions heard.
Edited the original post with a short explanation. See here.
The FANDOM staff have started rolling out features and updates that are made impossible to customize using CSS or JavaScript (JS). Many users and communities use these programming languages to create unique styles and add custom features to their wikis.
Removal of CSS/JS customizability is removal of basic low-level functionality for wiki users. It also breaks existing styles. Finally, it is an example of the staff needlessly controlling and branding wikis in places where admin decisions have sufficed. Regardless of what you think of the new features themselves, I hope we can agree that barring us from customizing them is a negative trend.
Sign (~~~) below if you support CSS/JS customizability on FANDOM. More importantly, whether you support or oppose, please reply to this thread to add to the discussion.
A FANDOM staff member has provided the following statement as to why CSS/JS customizability is being disallowed.
| “ | As part of the redesign we also announced that we will no longer be allowing most forms of CSS and JS customization to the headers. This includes adding fourth and fifth level sub-menus to Wiki Navigation. Some wikis out there have these customizations, and a point of feedback we heard when we showed these changes to the Community Council was that some admins felt that these fourth and fifth levels were essential to their navigational structure. We've opted to disallow this type of customization not only to ensure design consistency across Fandom but also because of the simple fact that it's a bad design practice and hinders the user experience. | „ |
| ~ Brandon Rhea on Thread:1247796 |
However, the CSS/JS customization blocking does not only block out fourth and fifth levels from the navigation bar. It prevents any possible change to the wiki and article headers, which includes article names and edit buttons.
While I'm also sure FANDOM has put a lot of UX research into the new placements and styling of these elements, it should ultimately be up to the community of a particular wiki to decide how to present them in line with their individualized style. Indiscriminately blocking CSS/JS is a problem, and I worry this line of thinking won't be limited to this one navigational instance.
We can't customize new features, and this is a problem.
If this starts happening again, be sure to copy every post to your clipboard before you submit it. It will save you a lot of grief after the first time the message shows up again.
Not to argue semantics, but I think that's a tad mean to the 80 million people who speak Korean.
Spam is a very broad term, and may refer to things that cannot be flagged as such programmatically. Perhaps a tool already exists that can help you, but you'll need to be more specific in explaining what you mean.
Though given the new Javascript review process, you might have to wait a while before the code is approved.
