Commons talk:Mobile app/Feedback

Sorry for deletion

see: User talk:Krd#Bitte um Hilfe/Korretur Molgreen (talk) 08:55, 18 June 2023 (UTC)

Hello Krd thank you very much for your quick support. I do not realize how this happened to me and I hope that something like this will not happen to me again. (DE: Hallo Krd herzlichen Dank für Deine schnelle Unterstützung. Mir ist nicht klar, wie mir das passiert ist und ich hoffe, dass mir so etwas auch nicht wieder passiert.) --Molgreen (talk) 17:03, 18 June 2023 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Molgreen (talk) 17:05, 18 June 2023 (UTC)

Archive resolved sections

In reaction to both a question of Molgreen on my usertalk page and an according ticket on GitHub resource for Android-Commons-app (Archive function for feedback page) let’s discuss it here, by the way also for the talk page itself. Pinging @Molgreen, Syced as former talk participants.

I read only resolved sections should be archived, which seems sensible. For this task we have to use template {{Autoarchive resolved section}}, and SpBot will do the archiving. Molgreen is right that it looks for {{section resolved|1=~~~~}} (important is a valid signature, included with ~~~~).

What I need to know are the wanted parameter settings. There is a sub template {{Autoarchive resolved section/usertalksetup}} which could be added and then fine tuned if the active values do not fit:

• archive parameter: Should there be an archive per year (a longer period is not possible) – done so with the usertalk setup – or is something like /Archive1 and counting preferred? The latter case needs some manual updating in longer terms, if an archive gets too large.
• age: How fast should sections declared as resolved be archived? The usertalk setup sets an age of seven days.
• Should it be hidden? In my opinion not necessary, note also the next item.
• If visible should there be a pointer to the archive or a least the arcive overview? I think this is useful. Also set by the usertalk setup.

@Syced: The template must be on the page itself. It must be somehow secured that it is placed on top of the page. I think it even worked if placed in bottom area, but the displayed parts should be on top of the page.
— Speravir – 22:15, 26 February 2024 (UTC)

I have meanwhile noticed that Kaartic has secretly started with archiving already earlier than I asked, and this in a way that definitively works only manually. For keeping it simple I by now think that annual archiving would be the best, instead. Just for the record: I would have added the mentioned template a while ago if the most recent reactions wouldn’t be on top. Keeping the archiving information on top is the main task I see here. — Speravir – 23:05, 20 March 2024 (UTC)

@Speravir Does this mean that sections could already be archived with {{section resolved|1=~~~~}}? (What do you have to do practically?)

How about implementing a variant that you think should work well. (That wouldn't be "bad" from my point of view. That's exactly why we're discussing it here). Molgreen (talk) 05:05, 21 March 2024 (UTC)

Molgreen, you could add {{section resolved|1=~~~~}} in sections you think they are out of date, but this will not have any effect until {{Autoarchive resolved section}} has been added. I already could have added this template with the parameter hidden show=no at bottom of the feedback page, but this is far from user friendly: You have to know that archiving is done, discover the embedded template, and have to find out yourself the address(es) of the archive(s). This is by the way also the issue I have with the actual archiving done by Kaartic which is even without any hint on the page itself (together with the address scheme which enforces manual archiving and watching the archive size). — Speravir – 01:18, 22 March 2024 (UTC)

I believe Template:Autoarchive resolved section needs to be at the top of the page, not the bottom. Anything at the bottom will be part of the last section, and will be archived with them - at least that's how ArchiverBot works, and I don't think SpBot is any different about that. We might want to change the section order from newest at the top to oldest at the top, to match the normal talk page structure. whym (talk) 11:38, 23 April 2024 (UTC)

Oh my gosh, I think you are absolutely right, Whym. How could I forget about this. So, the only possible clean solution would be what you wrote and was also my first intention, but according to Syced the app adds intentionally new reactions on top (cf. Syced's answer in archived thread on their talk page). Just another idea: We could try to set the template into a section that itself is prevented from archiving, but I do not know whether this works. In German lang Wikipedia there is a note in the template page that it has to be placed quite on top of a page, but this information is missing in Commons (and e.g. in Meta). — Speravir – 23:44, 23 April 2024 (UTC)

Actually, I think what I said was not accurate. ArchiverBot will definitely look for the template in the header - text written on top of the first section. I don't know if SpBot will do the same, or look for the template in the entire page. If the latter, it might work, as long as the template is in a section that's never archived. I think we can just try. whym (talk) 00:07, 25 April 2024 (UTC)

@Speravir,@Syced, @Whym: I have just seen that there is now an archive which apparently includes entries older than one year. That seems like a good solution to me.

Two questions:

1. is the archiving automatic?

2. is this the end of this discussion?

best regards Molgreen (talk) 09:22, 20 May 2024 (UTC)

For both questions: No. This was a one time action by a user. But manual archiving needs active users who know what to do (and what not to do). I do this very infrequently on my own talk pages, but there are less many messages. The bot would also archive in talk page/Archive/Archive… with talk page/Archive being an overview page or at least providing this as opportunity. — Speravir – 21:25, 20 May 2024 (UTC)

Good morning @Speravir, thank you for your feedback. Do you have any ideas as to whether and how we could make further progress on this topic? Molgreen (talk) 04:12, 21 May 2024 (UTC)

Let's do what Whym and I thought: We try it out. Please, set some sections to resolved (at best also the oldest ones), and we will see if the bot reacts like intended. If not it seems it has to be done manually like Kaartic did it. Who by the way seems to be a developer, too, like Syceed. It’s actually a pity that no one of them reacted to the question, whether another solution would be possible. A big caveat right now is that in edit mode an info box is partly hidden now due to the way I put the archival box on top of the page, but I do not know another way. — Speravir – 22:15, 21 May 2024 (UTC)

@Speravir, thanks, I have marked two sections accordingly Molgreen (talk) 05:09, 22 May 2024 (UTC)

I feared this: It did not work. Let’s wait another day, but I at best little faith it will work, then. Next idea would be asking Euku as bot owner. — Speravir – 22:07, 23 May 2024 (UTC)

No, the bot did again not archive the sections. So, we have to notice: The test failed. — Speravir – 03:02, 24 May 2024 (UTC)

good morning @Speravir, thanks for keeping an eye on. Could you contact @Euku? Best regards Molgreen (talk) 04:38, 24 May 2024 (UTC)

Sorry about the rather delay in response. Thank you for proceeding with setting up the archival bot! It's unfortunate that it doesn't work due to how the app writes new sections. Feel free to let us know if there's anything specific to be done at the app end to improve this situation. We could gladly handle it :-) Kaartic ^{[talk] kindly ping me} 18:42, 24 May 2024 (UTC)

I’ve added an answer below with less indentation.— Speravir – 22:50, 24 May 2024 (UTC)

I have meanwhile noticed that Kaartic has secretly started with archiving already earlier than I asked, and this in a way that definitively works only manually.

Yeah. I wasn't intending to keep that archiving strategy up. I just wanted to do make the feedback page a bit accessible as it had several years' feedback gathered. Hope I didn't break anything by doing so. :-)

For keeping it simple I by now think that annual archiving would be the best, instead.

Given that we're discussing about only archiving resolved sections. I think it might be fine even if we have a shorter term such as once in 6 months or once in 3 months. But if there's a strong preference for having it once a year, that's fine too :-) Kaartic ^[talk] 18:29, 24 May 2024 (UTC)

For me, the most important thing is that archiving works automatically. How often is not so important. (My preference: the shorter the time intervals, the better). Molgreen (talk) 19:05, 24 May 2024 (UTC)

Kaartic, you didn’t destroy anything. If there should be another archiving method the existing archive content could be merged. For the other frequence I thought once a month should be enough. If there are no messages no action will be taken with the approach to only archive resolved sections. — Speravir – 22:50, 24 May 2024 (UTC)

@Kaartic and Syced: Is it really not possible to edit the app in a way that it recognizes some marker on the feedback page and adds new sections below this special marker? I know in Javascript there is the possibility to get an element by its ID, so I’d suggest to put the archiving template, but also your information, that is now the last message on bottom, or a potential introduction, into an html div block with an app specific ID. This would in my eyes be the best solution for all of this. Since Molgreen have opened a GitHub ticket I could write this a second time there (ticket 5542, already linked in first message of this thread). But the app is not written in Javascript, I suppose? — Speravir – 22:50, 24 May 2024 (UTC)

Is it really not possible to edit the app in a way that it recognizes some marker on the feedback page and adds new sections below this special marker?

I don't suppose it should be totally infeasible. It basically boils down to what the Mediawiki API provides support for (note: it isn't super flexible). In this case, we rely on the edit API for creating the section in the Feedback page. The most straight-forward way seems to be prepend the text to the page so that new feedback appears on top.

But the app is not written in Javascript, I suppose?

Yes. The app is written in Java/Kotlin for the Android platform. So, the ID solution / JS native solution that you suggest doesn't work so well there. We would need to load the whole page to do the kind of handling that you suggest. This is not optimal for a critical function such as feedback.

That said, we could just consider going the usual discussion page style. The API supports this very well. This would make new feedback appear at the end rather than the top. I'm not sure if that's really too bad 🤔

Since Molgreen have opened a GitHub ticket I could write this a second time there (ticket 5542, already linked in first message of this thread).

Sure that would be great :-) Kaartic ^[talk] 18:31, 25 May 2024 (UTC)

“That said, we could just consider going the usual discussion page style. The API supports this very well. This would make new feedback appear at the end rather than the top. I'm not sure if that's really too bad.“

On the contrary: the way it is now is not the Wikipedia standard for me: I would always expect new things at the bottom. I don't think I know of any other site in the wikiverse that puts new stuff at the top!

PS1: I really appreciate the Commons app for allowing me to leave feedback without having to log in anywhere.

PS2: A link from the app to the feedback page would be nice. The user giving feedback (at least that's how I felt at first) has no idea where the feedback ends up and whether someone else has already reported the same bug. Molgreen (talk) 19:01, 25 May 2024 (UTC)

@Molgreen I could totally get your point. Let's see if we could change the section ordering back to the normal one. :-)

PS1: I really appreciate the Commons app for allowing me to leave feedback without having to log in anywhere.

Are you referring to the ability to share feedback via e-mail when the user is not logged in?

PS2: A link from the app to the feedback page would be nice. The user giving feedback (at least that's how I felt at first) has no idea where the feedback ends up and whether someone else has already reported the same bug.

This is a good suggestion. I've opened an issue regarding and will look into tackling it soon-ish. -- Kaartic ^{[talk][kindly ping me]} 04:33, 30 May 2024 (UTC)

@Kaartic (PS1): No, I think that (via E-Mail) would make things even more confusing. (You would have to check an email account, the Commons feedback page and GitHub).

What I mean is that you don't need a GitHub account. I think that's very good. (Other apps only allow feedback via GitHub. I don't like that).

And it would be good if feedback could also be submitted (via IP address) if there was a login problem with the Commons app, for example. Molgreen (talk) 04:47, 30 May 2024 (UTC)

What I mean is that you don't need a GitHub account. I think that's very good. (Other apps only allow feedback via GitHub. I don't like that).

Ah. I get it now. Glad to know that you find on-wiki feedback support helpful!

And it would be good if feedback could also be submitted (via IP address) if there was a login problem with the Commons app, for example. Molgreen (talk) 04:47, 30 May 2024 (UTC)

It's kind of circualar, isn't it? If there's some problem with the app's code where user is not able to login, trying to again submit feedback using same code could possibly hinder the feedback, isn't it? I think that's why the app supports sending feedback vai e-mail when you're not logged in. I could understand it is yet another channel but if there are enough eyes watching it, I think it is not a problem? :-) -- Kaartic ^{[talk][kindly ping me]} 17:33, 2 June 2024 (UTC)

@Kaartic, That's right! The more channels available to users, the better. Are you sure that the e-mail channel still exists? I thought "Commons talk:Mobile app?" was introduced as a replacement for the e-mail channel!? I can no longer find an e-mail address. Molgreen (talk) 18:14, 2 June 2024 (UTC)

The e-mail route still does exist. The same is shown only when you're logged out. They get posted to the commons-app-android mailing list (upon approval). Do you suggest to have a way to also send e-mail in case users face difficulty with posting on-wiki feedback? Kaartic ^{[talk][kindly ping me]} 18:30, 2 June 2024 (UTC)

@Kaartic, thank you, I didn't know that. Then it's fine the way it is. (If the password has become invalid or sending the feedback causes the app to crash, an error report is automatically sent by e-mail. Everything is perfect). Molgreen (talk) 04:28, 3 June 2024 (UTC)

Kaartic When I wrote above about the best solution being adding a marker I did this under the impression that the inversed section order is a fixed fact not to be discussed about. But if this was wrong, putting all sections in the usual chronological order and adding new ones below the older messages would be, of course, the easiest way solving the issue why this discussion thread was started. Probably then the feedback area should be kept shorter, something I cannot estimate at all. — Speravir – 22:45, 26 May 2024 (UTC)

I could understand @Speravir. I don't think there's a great reason to post feedback topics at the top rather than at the end. The only reason we're posting at top seems to be that the initial suggestion mentioned posting at the top. That was likely done so that people easily notice new feedback. Alternatively, we could post at the bottom and just explore ways to possibly have an inverted ToC to achieve the same point of quickly noticing new feedback. I'll post about this in the corresponding issue in the Commons repository too. Kaartic ^[talk] 03:33, 30 May 2024 (UTC)

Kaartic, regarding your we could post at the bottom and just explore ways to possibly have an inverted ToC If the MediaWiki devs would have coded it this way that every section was actually embedded in an html5 <section> displaying the section in an inversed order would be even possible for the whole page (whether there would be the FOUC issue then, we cannot check), but it is kind of easy possible for the TOC (if one has some CSS knowledge):

.page-Commons_Mobile_app_Feedback :is(#toc, #vector-toc) ul {
	display: flex;
	flex-direction: column-reverse;
}

The selector :is(#toc, #vector-toc) is necessary for Vector-2002 skin. This needs #vector-toc, all other supported skins including Minerva (mobile skin) apparently have #toc. — Speravir – 22:49, 30 May 2024 (UTC)

Thanks for the comment @Speravir. Let's continue the discussion in the GitHub issue [ref] -- Kaartic ^{[talk][kindly ping me]} 17:28, 2 June 2024 (UTC)

Kaartic, I noticed Special:Diff/882305209. Does it mean that the new app version which adds new feedback on bottom is shipped for users or are you still using a test build? Because if your ship out this feature the page has, of course, once to be adjusted. — Speravir – 23:45, 9 June 2024 (UTC)

Ah, I just now noticed your GitHub ticket pull request Make new feedback to be added as a new section to the end of the page on GitHub. — Speravir – 23:50, 9 June 2024 (UTC)

Yes, @Speravir. The change has been approved. It'll be shipped in the upcoming release that is to be done in a couple of weeks. Will update here once it has been rolled out. :-) Kaartic ^{[talk][kindly ping me]} 03:33, 11 June 2024 (UTC)