Talk:Reading/Web/Projects/Mobile Page Issues

Jump to navigation Jump to search

About this board

Please give us feedback on your thoughts regarding this project so we can change and improve it. Each language is welcome in this discussion!

Doc James (talkcontribs)

Being created. As 2/3rd of our readers are using mobile and as mobile editing is becoming easier / common this is an important positive step.

Reply to "Great to see this"
Luensu1959 (talkcontribs)

Discûscioîn template:Avviso

Thanks for informing us at WIkipedia Ligure!

~~~~

Reply to "Avíso"
Nami-ja (talkcontribs)

そもそも、モバイルではなぜさまざまな問題を提示しないのですか?

In the beginning, why do not you pose various problems on mobile?

日本語版では多くのモバイルユーザーが対話に応じない荒らしとしてブロックされる事例を見て来ました。

In the Japanese version, I saw a case where many mobile users are blocked as vandalism not responding to dialogue.

しかし、多くのモバイルユーザーがウィキペディアから排除されていくことをウィキペディア自身が望んでいるとは思えません。

However, I do not think Wikipedia itself wants that many mobile users will be excluded from Wikipedia.

Malyacko (talkcontribs)

Hi, thanks for your comment. Could you explain how this is related to technical issues which happen on mobile pages? What does "pose various problems on mobile" mean? Thanks!

Reply to "Mobile users can not talk?"
Trizek (talkcontribs)

It is great to see those improvements coming!

I've seen on the page proposal that there are 4 levels for messages: notice, low, medium, severe. Those 4 levels are commonly used on all wikis I've visited, except for the smaller ones. You already have something unified. You should go with CSS classes: mw-ambox-importance-[importance] to get the level of importance and mw-ambox-message to know where is the message you have to display on mobile. Colors can be override locally if necessary, with an impat on the mobile version.

Have a common CSS library would help a lot for other navigation templates, like disambiguations, Main template, etc. Communities can then implement them quickly.

Reply to "Using a CSS library?"
WhatamIdoing (talkcontribs)

One question that has never been answered: Does it actually matter if readers see these maintenance templates? The hope has always been that readers will see a Template:Copyedit template, and be inspired to click the edit button. I'm not sure that it actually matters for typical readers. There are a few things that might matter under unusual circumstances (e.g., you might want to see the copyvio warning if you're planning to re-use the content), but overall, displaying these notices to logged-out readers might be a complete waste of time. I don't think that asking readers whether they were glad to see the notice will actually get at the real question: Does seeing it actually change their behavior (and not just what they say about what their behavior might be, while someone's asking them leading questions about whether it would change their behavior)?

OVasileva (WMF) (talkcontribs)

@WhatamIdoing - we will be A/B testing these changes to see their effect on the user behavior. We will be looking at clickthrough to the issue modal to see if it increases with the changes and also to see if people tend to view extra details on more severe issues. We will also look to see if the changes have any impact on mobile edits. Additional details can be found in phab:T191532, but I'll also add a note on this on the project page as well.

WhatamIdoing (talkcontribs)

Thanks. I hope that you get actionable results.

Reply to "Research question"

A common solution for all languages: Extension

16
Amire80 (talkcontribs)

On this page there is not a lot of discussion about the fact that these templates are different in each language. Also, there's no discussion at all about the fact that these templates are visual and not semantic: to an experienced edmitor in a given language each of them is meaningful, but to the MediaWiki software each of them is just one of out thousands of other templates.

These are the actual root causes for the difficulties of handling them.

MobileFrontend relies of the design of English Wikipedia's Ambox templates. This obviously doesn't work for other languages.

A better solution would be to give communities guidelines for using some common code in templates of this kind, for example HTML classes. This is far from being robust, because it relies on presence of people who know how to use HTML classes and who read user manuals in each of the 800+ wikis.

The real solution would be to make an extension that stores metadata of this kind about the article—unreferenced, notability, style, perhaps also "stub". Customizations for each language should probably be possible, but a basic set of "page issues" could be made that covers most languages' and sites' common needs. When we have this as an extension, MediaWiki would be able to read this information meaningfully, and present it appropriately on desktop, mobile and elsewhere. Editors would be able to change them in a more convenient and structured way, instead of memorizing template names.

This is the discussion that we really should be having, instead of hacking MobileFrontend around the current local templates in each wiki.

Saint Johann (talkcontribs)

Your better solution was quite enough. Having another extension that can be supported only by a handful of developers and will be enforcing a strict model for such templates among the languages without the consent of their communities is not the best way to go. Template extensions are incredibly bad for a handful of reasons: they are non-customisable and supported only by WMF or especially zealous volunteers because the code is shut away in an environment that one must first learn themselves.

The experience of extensions like Babel shows that we should make less extensions of such kind, not more. If you want a best solution, have WMF developers do customisable, non-invasive, configurable modules. It would be a lot better than building an extension, because then the tasks about simplest things that are wrong with those extensions won’t have to be waited for long, long time to be acted upon.

Amire80 (talkcontribs)

An extension has advantages that a template doesn't have: proper internationalization, ease of installation on any wiki site, uniform functionality. And no, "uniform" doesn't necessarily mean "strict", as you say.

The clear advantage of a template is that it's easy for community members on a local wiki to update. Other than that, they are highly problematic. (Making templates easily reusable across projects would make them much better, however.)

If extensions were as easy for all community members to update as templates are now, without having to go through the current long and difficult cycle of review and deployment, this wouldn't be a problem at all. That's exactly what I'm talking about towards the end (1:04:14) of my interview on WikiJabber.

(I am intentionally saying "review and deployment", and not "development". Evidently, development is not a problem—the more active communities are clearly capable at developing templates in wiki syntax and modules in Lua. The fact that extensions are in PHP and JavaScript and templates are in wiki syntax and Lua is not a problem at all. In fact, extensions' initialization code has to be in PHP, but that's easy boilerplate code, and the functional parts of extensions can already be written also in Lua. I don't know why isn't it practiced more than it is now. So the programming language is really not an issue.)

As for Babel, it's a funny example. Clearly it's better to manage one extension than a set of literally thousands of the same templates in hundreds of projects. But what's particularly funny about Babel is that if you look at its history and documentation you see how strongly it tried to emulate what templates on projects are doing. This resulted in the need to write hundreds of lines in the server configuration files. Look at InitialiseSettings.php, search for wmgBabelCategoryNames. You'll find hundreds of repetitive lines that could be made default. So Babel emulated the functionality of "User xx" categories and Babelbox templates appearance on user pages too closely instead of doing what it really should have done: create a way to store metadata about a user with a list of languages that they know, and let other parts of the software do whatever is needed, for example show a box on a userpage, add a page to a category, etc.

And that's why I propose an extension that stores metadata about a page, which would be available for any use.

TheDJ (talkcontribs)

> these templates are visual and not semantic

Well yes and no.. each mbox has a page/contenttype (tmbox,fmbox,ambox etc) and a notice type. There is already some semantics in that combination, and these dictate the styling (so not the other way around). At least that is what it is supposed to be and thats how we designed it back in 2008. "hide when compact", which was added to that later on indeed is a bit of a hack. mbox-inside denotes a grouping of mboxes

I think this can definitely be improved, but I'm not in favor of an extension, mostly because of what Saint Johann says. Annotations perhaps. But making a MediaWiki:PageIssues.json that describes the semantics for each language (a bit like citations templates are described for Citoid) seems most viable and effective to me. Especially since these all are generated by templates, it should be easy to have some basic in place, and then create extra options to 'enhance' the mobile results.

Amire80 (talkcontribs)

@TheDJ, they are "semantic" only on one wiki, and they are not semantic to the software that processes them. If I understand correctly, the English Wikipedia templates were made "semantic" to MobileFrontend, but this doesn't scale to all Wikimedia projects, let alone non-Wikimedia wikis.

The need to prepare separate Citoid configurations for each wiki is a symptom of the same problem: things that should have been global and default are made local per wiki for no good reason. You can say, of course, that the reason is that for many people it's too hard to push an extension through the exhausting review and deployment cycle, and it's even true, but it's not a good reason.

TheDJ (talkcontribs)

Past experiences show that dealing with reality tends to end better, than grand schemes that are consequently rejected by all the majors wikis as being inflexible and disruptive to their processes. The flexibility of wikitext (structure, and the HTML it can generate) is a feature after all. It's a terrible feature from a design and software perspective, but a feature none the less and it's heavily ingrained in the userbase.

Once you have a good json design, you can even add default implementation and UI for those who have NOT provided their own templates, effectively moving the other group to an 'opt-out' state from the default software and creating huge benefit to smaller wiki's (although this follow through seems particularly lacking often). And i'm totally in favour of putting actual semantic definitions in an extension (how else would you read that json file) as well as adding parser functions that allow this extension to consume some of the information.

But we shouldn't forget the incredible amount of domain knowledge you would have to capture in an extension in order for it to effectively displace even 50% of the constructs that wikis have in place right now. And the further you get, the harder it will be (we see the same issue with TemplateData for instance). This creates a huge transition problem where often you can't switch to something new unless everything can move to the new methodology. And that is very unlikely to be the case within a year or so, you might even find out half way you built the wrong thing. In my opinion it is therefore important to design any solution to be so flexible that it can coexist with the current implementation.

PerfektesChaos (talkcontribs)

Strict and predefined matters in a global implementation are fine for basic and technical things, and unanimous abstraction of generic features.

However, things like unreferenced, notability, stub and more are far off from a common view of all wiki projects. There are very different needs of a wikisource, a wiktionary or a wikipedia on such topics, and a very different policy of each community. Some need even more and are left unsatisfied, some might not require any.

Areas like discussed here are highly dependant of the community view, and they are a bad subject for reusability across projects. The level is very close to individual decisions about content rather than a basic level of agreed technical support. Extensions and other global implementations should limit themselves to support generic tasks, not ask for preoccupation of high level editorial issues.

Amire80 (talkcontribs)

Is the "Unreferenced" template deeply and conceptually different in English, Russian, and French?

I understand that the template implementation may be a little different, and that the text may be a little different, too. I also understand that different communities may have somewhat different policies about what to consider "unreferenced".

But non of this is a reason not to have a generic global way to store metadata about an article that would have an "unreferenced" field. It's up to the communities how will they use it. But for machines there would a cross-wiki way to know that there's something to show.

Think also about a new wiki that is starting. Maybe they want completely different policies. If they want different policies, it's fine. But what actually happens is that a lot wikis import a bunch of templates from a language they know best, usually English, Spanish, French, or Russian. This makes things work superficially, but it is very time-consuming for new communities, which could invest their time in writing articles instead of importing templates, and it creates a lot of forks of code that is basically the same.

PerfektesChaos (talkcontribs)

The concept how to deal with Unreferenced is very different between projects.

  • On English Wikipedia there is a citation needed template at micro level, and an expectation what shall happen and how important that is.
  • On German Wikipedia there is nothing like that on statement level, but on page or section level. Furthermore I presume that classification of importance differs.
  • For a Wikisource this is quite meaningless in general, perhaps in a discussion.
  • Same for Commons or our current host MediaWikiWiki.

The global idea that something is felt to require a citation source does not map globally on presentation level. But handling presentation is the outcome of this “common solution for all languages” and the question how to present important things on a mobile (what the embedding task is about). BTW it is not per language, but per project community.

A global assignment of “unreferenced” would result in patronizing the wiki projects since it defines the presentation level how attracting such things shall be displayed. That means your Extension will make the decision for the wiki communities how they are to handle and focus on unreferenced issues, or any other thematic question.

A global software product is only permitted to offer a scale of very important, important, less important, normal, not interesting things and present all down to a certain level. It is not upon a global software support to force how to deal with encyclopedic statements perhaps not based on sufficient sources.

Amire80 (talkcontribs)

I'm not suggesting anything that will "force how to deal with encyclopedic statements". I only suggest a global way to store and read pieces of article metadata. An "unreferenced" flag may be one of these pieces. What do communities actually do with this is up to them.

The fact is that more than 100 Wikipedias have an "unreferenced" template. This means that it was manually copied more than 100 times.

To compare, the policy about blocking users is also different in every wiki, but the blocking functionality is available everywhere as part of the software.

PerfektesChaos (talkcontribs)

Blocking is part of Mediawiki software. It causes actions on server when IP or registered are attempting something.

Unreferenced is not a part of Mediawiki software. It has no consequences at all. It is not business of the software to deal with this situation. It is an editorial affair of content, and does not tell much whether really citation needed or even appropriate.

Amire80 (talkcontribs)

Templates are not a part of the MediaWiki software, but they are software. They are just implemented in a way that cannot be conveniently ported from one wiki to another. Sometimes it's not useful to reuse templates on many wikis. Sometimes it is. In case of Unreferenced, it's useful.

The fact that the unreferenced templates are not a part of the MediaWiki software now doesn't mean that they shouldn't be.

PerfektesChaos (talkcontribs)

They shouldn’t be. They are neither an issue for MediaWiki core nor for a MediaWiki extension, but a decision and implementation of the local wiki and depend on a policy and processes which the local community has to agree upon first before establishing any mechanism.

Amire80 (talkcontribs)

And yet, the question is asked here by the developers how to deal with them on the mobile platform. Why should it have a completely different answer in every language?

And perhaps more importantly, why should each Wikipedia in a small languages have to reinvent it? Isn't their time better spent in writing actual articles than in maintaining a fork of a template that could be maintained centrally? It's a privilege to say "they shouldn't be easy to port to new languages" when you are editing in a wiki that already has them. Not everybody has this privilege.

PerfektesChaos (talkcontribs)

Again, it is not a matter of any “language”, it is a matter of a community decision, and a French Wikisource might deal entirely different with an “unreferenced” situation as the French Wikinews, since for a Wikisource mainspace “unreferenced” is absolutely nonsense, but a Wikipedia has again an entirely different view on this, and on Commons or MedaWikiWiki your personal view is again stupid, and for some namespaces out of main space some views might be a bit interesting but not much.

And again, German Wikipedia community is dealing with “unreferenced” absolutely different than English Wikipedia does, and will refuse that you or your Extension or any MediaWiki developer attempts to patronize them and to set up global rules how any project has to deal with any matter of content. You are trying to force projects to follow your personal ideas how they are obliged and focus on certain things. This is not how wikis are working.

Developers asked how to present very urgent or very important or important or normal or less interesting things. This is fine, and they might support by framework. The judgement, what is how important is not up to you nor up to your “Extension” nor does any term of content, but the mapping is up to every single community who are to decide first which issues really matter for them and how they organize maintenance and community processes and which points they want to focus on and where to attract attention of readers.

EOD.

Amire80 (talkcontribs)

It appears, sadly, that we are talking about different things. At no point have I suggested anything that will judge what to do, but only a way to store relevant metadata about wiki pages, which will be readable in a uniform way.

Reply to "A common solution for all languages: Extension"

Any benefits for the English Wikivoyage?

3
WhatamIdoing (talkcontribs)

There are about 700 uses of ambox in the mainspace at the English Wikivoyage, including:

IMO approximately none of these matter to non-editing readers, unless perhaps you can read whatever language is listed in the "translate" template, and you didn't know that a Wikivoyage existed in that language.

A few, such as https://en.wikivoyage.org/wiki/Template:Copyvio are about serious editing problems, but there are typically few or none in the mainspace at any given point in time. Additionally, templates such as https://en.wikivoyage.org/wiki/Template:Side_box use the mbox classes and might be affected.

I'm not sure that this project will provide any tangible benefit to readers of the English Wikivoyage.

Quiddity (talkcontribs)

re: "matter to non-editing readers" - part of the idea of these amboxes, has always been that they entice readers to become editors. (We were all just readers, once upon a time!).

A second part of the idea, is that they help remind (or teach) readers that they're looking at a massively collaborative project which is a constant work-in-progress (i.e. that they should always seek external confirmation before relying on information within).

A third part is that they show how open we are about our flaws, which implicitly encourages readers to both tag any flaws that they find themselves, and also leads to greater overall respect in the work because of the helpful transparency.

WhatamIdoing (talkcontribs)

I don't recall ever seeing any evidence that this effort at "enticement" is effective.

Most of the arguments I've seen at enwiki about this are all about "we have to warn the readers about this article!" even though maintenance templates (with the reasonable exception of Template:Hoax) are officially not supposed to warn the readers about anything.

(That is basically my question at Topic:Ughiujdu59it47bc.)

Reply to "Any benefits for the English Wikivoyage?"
WhatamIdoing (talkcontribs)

I have looked this over, and I think this proposal will have no effect at all at ht.wikipedia.org It appears to be designed for the big Wikipedias.

Reply to "No effect at htwiki"

Project independent approach required.

1
PerfektesChaos (talkcontribs)

Several comments already mention that the proposal is guided by English Wikipedia and cloned modules and template systems.

There are other wikis who have similar templates, more than a decade for establishing their own classification and issues and maintenance procedures, but other appearance and not a matching distinction.

The proposal needs to be an abstraction from enWP which might be a test case, but not the role model all other wikis have to follow now.

On the level of CSS selectors (classes) a neutral formulation is reasonable, which can be assigned by local template implementations and enWP might map into their system:

  • mw-page-issue-urgent
  • mw-page-issue-severe
  • mw-page-issue-important
  • mw-page-issue-error
  • mw-page-issue-warning
  • mw-page-issue-normal
  • mw-page-issue-neglectable

or whatever.

A simple three-value distinction called high-medium-low seems to be too simple and blocks later extension by additional levels which might become necessary. E.g. some registered authors who claim to maintain articles in preferences should see error and even warning messages, which are hidden from normal and anonymous users.

MediaWiki software is supposed to identify such <div> or other block element and show the appropriate level in current presentation.

Reply to "Project independent approach required."
197.218.89.29 (talkcontribs)

As the old saying goes, " those who don't learn from history are doomed to repeat it".

The issue here is that attempting to build a hack on top of a hack like this is likely to fail, for various reasons:

  • Different design in different wikis
  • Templates such as these are themselves hacks
  • Page issues are metadata - no different than interwiki links

Wikia seemed to have tried a similar thing, with an extension called Flags. It was more sensible than this approach, and provided a graphical interface to set certain page issues, some for readers, and other to editors. The primary reason it probably failed is exactly due to an over reliance on templates (it too depended on templates). Templates in these cases aren't used because they are great. They are simply a desperate tool borne out of the fact that Mediawiki / Wikimedia has no annotation mechanism for either editors or readers. So their solution seemed to have been the greater evil of bombarding everyone with these monstrosities, e.g. many page issues are 100% irrelevant to readers, but they may be to editors.

A more sensible approach would be to first develop a way to way to identify these in a structured manner, e.g. TemplateData, thereby identifying templates by what their primary output (similar to https://phabricator.wikimedia.org/T165053). Then to develop a sensible interface that doesn't rely on templates to create structured issues like these, and let editors adopt them, perhaps with a heuristic tool that migrates the data from templates to the structured system. Finally, once implemented, simply hide all templates that look like page issues from mobile devices.

One obvious benefit will be the ability to do targeted updates whenever a specific element of the structure of the page issue changes, rather than the messy and horrible update to all pages that include it.

Of course, the sensible approach will likely be met with editor resistance. Resistance to chance is human nature...

197.218.89.29 (talkcontribs)

*to change

OVasileva (WMF) (talkcontribs)

Hi - thanks for your comments. We realize that a centralized and structured approach is a the best way forward. We're hoping that in the future we might get closer to something like this using TemplateStyles. The benefit of this project is that we'll be able to display issues between now and then as well as refine the styles we would want to use in the future.

Reply to "Sensible idea wrong approach"