Occasionally it's obvious from the edit summary, or because the page has a conventional structure (a talk page in the case where I noticed it). Or the user has been already tapping in and out of a few diffs to form a picture of who did what.
But perhaps we should ensure that users are thanking the correct edit by only doing it from the diff screen. A thank can't be undone or revoked afterwards if you tap in the wrong place.
So less a case of something that people don't likely want, more of protecting people from themselves?
links to the same article in another language at the top of the article (e.g. from fr:Route to en:Road) point to the desktop version (on en.wikipedia.org). They should point to the mobile version (en.m.wikipedia.org);
sometimes you need to edit several sections of an article at the same time (e.g. add a reference in the Bibliography and use it somewhere else, or fix typography everywhere). If I'm correct that is not possible and you must do several edits. Seudo (talk) 05:41, 28 August 2019 (UTC)
Re. whole-page versus section editing. Personally I prefer it when people make multiple small, focussed edits. But I do agree with Suedo that there are some cases where whole-page editing is needed.
One of my beefs with Visual Editor on desktop is that it dumps you into whole-page mode even when you select the section-edit button. The edit summary keeps the section name, creating misleading history. If you cycle back to source mode then you are still in whole-page with a mass of wikitext to wade through.
I’ve seen cases where editors make a big set of unrelated changes – some good, some quite bad – across multiple sections. Then the next person has to decide whether to revert and throw out the baby with the bathwater, or devote a lot of time to picking through the changes line-by-line.
So, yes, please make whole-page editing available, but don’t make it the default experience for newbies and don’t break section-editing!
The savvy bad-faith editors who use multi-locus editing to hide their insertion of political, nationalist, or racist PoV amongst good changes will still work out how do do so, but let’s not make it easy for the clueless to mess up articles.
Thanks for the links. I guess I'll try to hack something in my minerva.js to solve the first problem, because I navigate quite often from one language to another when the article on my language is not detailed enough.
Are you using a mobile device? Those links should redirect to the mobile site when clicked and if they are not that's a problem in our configuration and likely a different bug.
You can tell if you are on a 'mobile device' based on whether navigating to https://en.wikipedia.org in an incognito/private browser window on your mobile phone redirects to the mobile experience?
Many thanks for asking. I tried what you said and it's probably a problem in my browser (Opera for Android) configuration. Interwiki links from a mobile page (en.m.wikipedia.org) do point to mobile pages in other browsers (Chrome and Samsung Internet for Android) and also in a private Opera window. The problem I mentioned apparently only occurs in a non-private Opera window. So maybe that's a problem with something I did on my phone and not with Wikipedia, I'll look more to find the origin.
No, the "desktop site" option is not selected and the default user agent is "mobile". I have not recently modified these options. If I cannot find the reason I will simply use another browser for Wikipedia... Thanks for your help.
Hey, I was hoping to get some discussion going around the questions we posed in our recent update. Calling upon a few folks who participated constructively in some of the prior AMC [Advanced mobile contributions] discussions — @Donald Trung, Harshrathod50, arajc, jacobtohahn, AdrianWikiEditor:.
Which Talk page experience do you prefer, and why? Is there any low hanging fruit for improving the mobile Talk experience for advanced contributors?
I prefer the Wiki version instead of Default one and that is because it allows me to decide weather I want to sign or not after replying. The automatic signing functionality of Default version is very annoying.
I feel like the current mobile talk page is like the visual editor. Laid out nice and simple showing exactly what to do. However the "Read as wiki page" is like the source editing. You don't know what to do and it's all complicated for newer editors. Keep both but maybe have some sort of dropdown so you can pick between Visual editor and Source editing. Plus people will get angry if there is only one option available. All I am saying to to maybe change how you switch between them.
AdrianWikiEditor (talk) 03:37, 24 January 2019 (UTC)
My concern is that the Talk page is non an "advanced" feature. Anyone who wishes to edit Wikipedia needs to know how to access Talk. First edits are often (almost always?) reverted and visiting the Talk page is the best way to find out why and get help. Implementing Talk access only in a non-default skin does not address the needs of first-time editors. I would suggest an alternative which should work for all skins: add a link to the Talk page at the end of the article's Table of Contents. This should be easy and quick to implement. We could then publicize this way to access talk to new (and old) editors. You could still continue the current project for other features in desktop that are missing in mobile.
To the possible objection that the Talk page is not a proper part of the article, I would reply that Talk is also an important tool for non-editing readers, as it provides useful information as to the state of the article, If there is a controversy raging on the talk page, for example, that alone cautions the reader that the article may be in flux and it also can provide a good overview of the issues involved.
The default mobile talk page (which is accessible at "Pagename#/talk") doesn't allow users to view and edit talk page headers (lead section). I can't post my comment where I want, in a specific section. It automatically signs my comment, even when I don't want to sign it(for some reason). I can't even edit my previous comments using this interface. That's why I don't prefer it. On the other hand, the Wikipage version of the talk page solves the above issues but it has few problems. First some templates don't work properly on the mobile Interface. For example, WikiProject banner. I can only view WikiProject banners if I click "about this page" beneath the talk page title (eg.
w:en:Talk:2017_UK_Championship#/issues/all
). And this link only appears in pages in Talk namespace. I mean this "about this page" button doesn't appear in pages in File talk, User talk, Template talk etc. That's why I always have to switch to desktop version to see this WikiProject banner. Also "edit protection templates", "help me templates" etc are invisible in the mobile interface. I do not like this existing talk page interface at all. But I like this flow talk page. It is more advanced and user-friendly. I'd like to see flow talk pages instead of the current version in mobile interface.
In AMC, the Article/Talk selector is well-placed. But when you tap Talk you are dropped into a completely different layout and the top-page elements disappear.
It feels jarring and breaks the presentation of Article/Talk as a toggle between two related entities.
For those who do like the collapsed/summary talk page overview, is it possible to present that below the nice new AMC toolbars/controls/top-matter? (Not sure of best terms to use. What do the devs and designers call these?)
If not, please make talk "view as wiki page" the default and relegate the "following conversations are now active" to second-fiddle.
Oops, I just read the section that AHollender linked.
Sorry for reiterating something that’s already being planned.
“this current Talk page experience is a little disconnected from the article it belongs to … one of our design goals is to unify the article and Talk experiences, by rendering the Talk page as a tab of the article … help people keep their context, while also allowing seamless navigation back and forth”
So, on to the main question “Which Talk page experience do you prefer, and why?” I think I still like the wiki-page experience over the whatever-that-other-thing-is (not denigrating it, just don’t know what to call it). Partly that’s familiarity and aesthetics, partly because the latter is fairly limited. I do see pros and cons for each. Exploring them will make this a long post.
Summary view
pro: clean minimalist appearance
pro: consistent look with some VE-related screens
con: very different look from AMC
con: minimalist layout means omitted functionality
no talk history
no tools for merging or splitting topics (maybe not that important for mobile users?)
no access to archives!
There's not even any indication of whether archives exist or not. And how would a newbie know that “view as wiki page” is how you find older conversations?
templates in general
discretionary sanctions, page protection, other warnings. Arguably some things don’t really belong on Talk where they apply to the article and not the discussion itself, but they do need to be highly visible. For contentious topics you probably do need some kind of warning on the talk page where arguments may break out. Even if it's direct text and not templated.
any other important templates I haven’t thought of?
pro: loading just the topic titles up front
I'm fortunate enough to have moderately fast network access (if the radio signal is good) and a reasonable data volume allowance, but this isn’t true everywhere in the world
short of going to a desktop pc and fiddling user agent strings to find out for myself, does anybody have info on talk page sizes, with comparisons across the various UIs?
con: not much info about the topics, you need to tap through each to find out
con: tapping back to the summary from the topic causes page reload?
browser, platform, or resource dependent?
HTTP caching headers?
con: no access to content that lies before the first heading
Yes, people sometimes put discussions there, not just meta-info. In a perfect world somebody would refactor and add a heading.
Improvements:
for each topic listed, add post count, size (words), size (kB), number of participants, when created, when last updated
(Topic info could be parsed on save/update/publish and stored in a separate table, rather than parsed on load. Maybe not necessary if the summary page itself is cached, but having topic metadata stored separately and indexed could provide opportunities for some nice searching and filtering.)
search box (for whole board across all topics)
single search across active board and its archives
option to load smaller topics inline
add an "untitled" or "top" topic item for discussion that has been posted above the first heading; or display top-matter on page before the topic list
Topic view
Haven’t used it much yet; looks like you can only bottom-reply and not make a threaded/indented edit. There are arguments in favour of that, but it's not the way that desktop users currently work on en-wp. Other communities may have different norms, of course.
Are there areas where top-posting to Talk is preferred?
Per-topic history would be nice. Maybe not so important of itself, but ties in with better history filtering in general for all pages not just discussions.
No formatting tools for Reply box. Haven’t tested this: does it accept wikitext? If it does, then how about a fixed-width font to give it a more source-edit feel (like this Flow box I’m currently typing into)?
Wiki-page view
some talk pages are huge
data usage and speed already mentioned above
though even a big wiki page is as nothing compared to your typical commercial site that’s loaded up with advertising scripts, images, and auto-playing videos
also big in terms of screen space, scrolling
browser find-in-page searches whole board (but not archives)
you don’t have to tap into each topic separately, valuable where there is a series of short topics
Improvements:
Collapsible headings in talk, like articles have on mobile. (Would love to see this as an option for desktop also.)
Visual editing option for those who like VE.
Maybe not desirable for those mobile devices that don’t have enough grunt to run it?
[Aside: I don’t see any formatting tools or visual option in this Flow editor right now. Is it disabled for small phone screen, or all mobile?]
If it can be done without corrupting the pages.
Because VE only does whole-page editing, it might be too easy for somebody to mess up others' posts and upset them.
The more I think about this, the less it seems like a good idea? Leaving undeleted as there are some pertinent questions.
Desktop view with 2010 wikitext editor
con: a bit hard to use on tablet-sized screens (I should try it on a phone just for the challenge!)
pro: preview, show changes
pro: edit-preview-edit cycle saves state against browser crashes and tab reloads?
comment: some skins responsively adapt to smaller viewport sizes better than others (hooray Timeless!)
iOS app
Natively only views and edits articles, pushes you into built-in browser for other namespaces.
In-built browser doesn’t sign you in, even when you’re already signed into the app and to the website in Safari.
re. Editing with Desktop view on plus-sized phone.
I tried this and it works surprisingly well with Timeless or Minerva Nueue as my desktop skin. Vector scales uncomfortably but might be usable with enough pinching and zooming. I noticed that the AMC tweaks were present in desktop-Minerva. Some toolbars wrap but still appear functional on brief examination.
(The point of directing people to discussion is not just to read but also participate, so choice of editor is as important as the choice of reading view.)
In my long post above, I was assuming that each topic loads separately, and that something server-side parses and selects the relevant section from the underlying page.
Is this true, or does the whole thing get loaded for the non-relevant sections to be hidden client-side?
@Jdlrobson, AHollender (WMF): Would it be possible to make the flow talk page default on mobile interface while keeping "view as wiki page" option? Flow talk page is much more accessible and new user friendly. Masumrezarock100 (talk) 08:38, 11 September 2019 (UTC)
@Masumrezarock100: Those with technical insight could confirm this for us, but from what I've read "Structured Discussions" (Flow without the workflows?) has very different back-end storage that's incompatible with free-form pages.
One possibility would be to enable both discussion spaces side-by-side, and let people choose to engage where they feel comfortable. A kind of natural selection. In can hear the howls of indignation and baying of wolves already, for even uttering this idea …
@Pelagic: I was talking about replacing the default (not Wikipage version) talkpage version, with flow talk page and keep the wiki page version like it was before.
There is a separate engagement at Talk pages consultation 2019 about building some new interface, but I wouldn't be surprised if it ends up more like the current mobile view and less Flow-like.
Great job team! Everything feels just right with the new interface - things are where you expect them to be and there is almost nothing missing from my desktop workflow.
The only bug I could find is the text "pagină" (page) appearing over the history button on ro.wp.
This is an Opera bug. It seems to impact this icon as the tooltip is quite long "Vizualizează istoricul modificărilor pentru această pagină.", so one quick fix would be to change the message translation for mobile-frontend-history to be a little shorter - it's a bit long to be a label.
I can replicate it on Opera 53. Which version are you running Strainu?
The current workflow for reviewing pending changes is quite inconvenient. In order to accept a revision, one has to click on the page title and scroll all the way down to click the "accept revision" button. Without the user script that places an undo button on the diff, reverting the edit requires one to go to the article, click on the history button, find the edit and click undo. It will be helpful to have both buttons avaliable on the diff. I recognize this is not high priority as it is a small part of the workflow, but it's one of the few tasks that are almost as easy to do on mobile as on desktop.
It might be gratuitous to post a thread just for “ILIKEIT”, but WMF gets so much flak (sometimes deservedly so) over UI and usability changes that I’d like to chime in with a thumbs-up for this one.
If Fram was still around, maybe even they might like it.
I haven’t read through the comments yet, so apologies if I’m doubling up on anything.
There is a good separation of the site tools, user tools, and page tools into logical groups.
The animations on these are smooth on an iPhone 6S (not a latest-gen device but still decent processing power) and work fine enough on an iPad 3 (which struggles on some commercial websites). There’s just enough animation time for it to feel like a pop-up or slide-out without being distracting. (Some may disagree as there is an element of personal taste involved when it comes to animations.)
Relocating the talk link to the top is a welcome change for me. On desktop I use Timeless or Vector, not Minerva, so moving between platforms meant making a mental adjustment of where to find it. Also, on iOS Safari, you can scroll to the top by tapping the status bar, but scrolling to the bottom requires swipey-swipey-swipey actions that are cumbersome on a long page.
I’ve been using Timeless as my primary skin on en-pedia for a while now and some aspects of this AMC design feel similar (colours, icons, bar below article/talk selector). Did the Timeless look inform this design, or is it more a case of them both drawing on a common icon library?
It’s informative to compare this interface with, say, the iOS or Android app. Not saying they should be the same; it’s great for users to have choices! I might save those comparisons for a separate post, as this one is already getting quite long.
Similarly, I hope to add some comments about table-of-contents navigation, dark mode / colour themes, and talk pages particularly. But will check the other topics first to see if somebody has already started discussion about those.
Finally, the opt-in process worked well. One interstitial (if that’s the right term?) saying “hey, new feature, would you like to try?”. No mandatory roll-out or forced A/B test. Even if feedback is overwhelmingly positive and AMC becomes the default, I hope users will still have an option to turn back to the old layout. Choice is good. (I know, I said that already, but it bears repeating.) Do non-logged-in users also get an option (e.g. via cookie rather than server-side preference)?
