Talk:Wikistories for Wikipedia

Connect with the Inuka team about Wikistories

What is the procedure to get Wikistories implemented on other projects?

Thank you @Zblace, for your question and interest in this tool.  Wikistories is currently only available as a beta feature on Indonesian Wikipedia. At this stage, we are monitoring and evaluating its usage and viability so that we can make decisions on the future direction of the tool before the end of this year.

Please let us know the Wiki you are considering that should have this tool, and we will consider it and get back to you.

If someone was involved with w:id:Listyo Sigit Prabowo, how would they find out about w:id:story:This? There will need to be some kind of cross-namespace watchlist, history, and notification listing.

If a user has a page-block on a mainspace page, they should also be prevented from linking stories to that page. And what if an article or other mainspace page has semi-protection or ECP? Will that apply to linked stories?

Hello, glad that you found creating a story fun! And thanks for sharing your questions. In trying to understand your first one correctly, do you mean the ability to be informed about stories affecting an article the same way you can be informed about changes to the article itself? That is a good point, we can file a Phabricator ticket for further exploration. Currently, every story has its own page in the Story namespace (for example Wikipedia:Story:Tiram ) but more improvements are expected as Wikistories evolve.

You raise a good point in the second question as well, this type of user permission check is currently missing. I have filed task T316131 put this in the team's radar.

> do you mean the ability to be informed about stories affecting an article the same way you can be informed about changes to the article itself? Exactly! Stories aren't part of the page source, but they appear at the top of the rendered article. Article-to-story is a bit like category-to-article: watchlist an article will show when a category is added to it, but you can't watch a category and see when it gets new articles. Designing a general-purpose tracker for "what links here" could be challenging, though. Or should the link between an article and its stories go in the other direction, like with templates? Thanks for filing the Phab ticket!

Where can I translate the Story and Story talk namespaces?

Namespace localization is done in the Wikistories extension code. If you want to contribute to the translation, you can provide the information here or in a new task in phabricator.

I can't find any starting discussion or consensus in id.wiki regarding community approval for implementation of this feature? Is there any discussion about this in the past? I just found the invitation for research, the proposal for product ambassador, the news for implementation but not community approval. So, don't we need approval from community first before implement this feature?

Hello Angayubagia,

Thank you for your question. The Wikistories team worked closely with the Wikimedia Indonesia affiliate and the community from the Wikistories concept design to development, down to its deployment in the Beta cluster and now to the deployment in Indonesia Wikipedia as a beta feature. So, the community was aware of our plans to deploy Wikistories to Bahasa Indonesian Wikipedia via events (WikiNusantara 2022) and conversations with prolific editors and the affiliate. The conversations were not made via the Indonesian village pump as not all communities use Wikis and the village pump the same way. At the moment, the Wikistories is in its pilot (testing) phase, a phase that the community is also involved in using the tool and providing feedback; after this phase, we will still engage the Indonesian community to bring it out of Beta for everybody.

Once again, thank you for your question; I hope the above answers your question.

Best regards.

Hi @UOzurumba (WMF) Thanks for your replies.

“

The Wikistories team worked closely with the Wikimedia Indonesia affiliate and the community from the Wikistories concept design to development, down to its deployment in the Beta cluster and now to the deployment in Indonesia Wikipedia as a beta feature.

”

Here is my comments. Indonesian wikipedia community is not same as WMID (Wikimedia Indonesia affiliate) because not all member of Indonesian wikipedia community is also member of WMID or otherwise. So even you are closely working with WMID and got support, It is NOT meaning you guys can fully implemented without community approval first. Which is still not yet discussed or approved in village pumps nor "call for discussion" in social media platform which request for discussion timeline. Not even this discussion/opinion poll/pros n cons process included on your timeline/schedule? How come from started idea November 2021 until today not even once all of this member thinking about that? And yet you guys want to fully implemented this feature and already has the date!

“

So, the community was aware of our plans to deploy Wikistories to Bahasa Indonesian Wikipedia via events (WikiNusantara 2022) and conversations with prolific editors and the affiliate.

”

I am aware that beta feature already implemented without all or most member in community consent, just approval from WMID as an affiliate. Yes, it is mentioned in events such as WikiNusantara 2022 (with just 50-60 people) but, as long as I knew, it is just to introduce this feature to the communities (the events not just include Indonesian wikipedia community, also with other local language wikipedias) NOT to fully approved to implement this feature in idwiki.

I am still don't have quite good answer from where is the community panel/discussion mention on implementing this feature.

“

The conversations were not made via the Indonesian village pump as not all communities use Wikis and the village pump the same way.

”

Where is the proof for this statement, specially in Indonesian community, seems you know more than us?

From my personal view, this feature more like burden to the communities rather than engage new contributors, because many reasons:

1. Very few wikipedians use stories, and therefore very few wikipedians will maintain it.
2. As very few wikipedians maintain stories, they often or can contain out-of-date and/or irrelevant information.
3. Many stories on certain subjects are less useful as an introduction to their subject than the article(s).
4. The time wikipedians do spend on maintaining stories would (thus) be better spent on maintaining articles.
5. Because they are poorly maintained and have few watchers they attract vandalism and POV pushers, which is not quickly reverted. Nor even will knew it by other wikipedians.
6. There are none interconnected proof that wikipedian who contribute to stories will also contribute to articles.
7. It is more like FOMO (Fear of Missing Out) feature rather than a good feature for wikipedia, as this feature already implemented by social medias such as instagram, facebook, whatsapp, tiktok, snapchat, etc. Are we want to be social media platform or digital encyclopedia?

Thanks for your time. Best regards. Angayubagia (talk) 12:47, 28 August 2022 (UTC)

Thank you, Angayubagia, for your feedback; I understand that not all members of the Indonesian Wikipedia community are members of WMID or otherwise. We reached out early to WMID for guidance and they have helped the Wikistories team connect with the community members using the best approach based on their experience.

Within the Bahasa Indonesian Wikipedia the Wikistories feature is not explicitly visible at the moment and only available as a beta feature for logged-in users only However, feedback such as yours is helpful for us to understand how we can improve the engagement from our side to make it more visible and inclusive. Therefore, we will review our communication practices , and will seek community opinion using the best channels possible - village pump, social media groups, or direct feedback from users such as yourself. Our Product Ambassador and WMID have been close partners in the process so far and we will also continue to seek their  opinion for us to form an overall perspective. We will also appreciate it if there are any other specific forums that you can suggest which we can add to our list of communication channels.

Wikistories target editors (old and new) who would like to create and engage with encyclopedic knowledge visually; it is still in the experimental stage, and your community is the wiki we have been collaborating with for a year now to develop this product. Therefore, we are open to evaluating and learning from the outcomes in every stage and exploring ways to improve it for your community and others who want to engage with content in this format. We appreciate sharing your concerns, and we plan to explore ways and brainstorm with you and other Indonesian community members to tackle some of them as they surface.

Best regards.

Hi @UOzurumba (WMF), thanks for the feedback and your time. Lovely to put my perspective here which already mention above. Still not all my questions above got answer from you & the team. This WMF communication approach is the example and proofing that i need to retired sooner than i thought. How come you just got 15 people in your research (7 people even just edit once or twice a year) and get conclusion that all of them represent the Bahasa Indonesian Wikipedia community itself as a whole, for example, not quite clear? From what research, you guys can already has date for fully implement this feature? This make me wonder, what else you guys pushed without community knew or approved in the past and future? Who responsible for this mistakes?

“

We reached out early to WMID for guidance and they have helped the Wikistories team connect with the community members using the best approach based on their experience.

”

What is the "best approach" meaning? Sorry to say this, it's more like lazy approach. Community have many channels (whatsapp, telegram, discord, social medias, etc), not one talk about "call for discussion" panel or consensus poll? Nor the schedule or timetable for discussion, Is that the "best" effort team can do? WMID chairman, @Rachmat (WMID), which already contact me via twitter also can't (or don't want) answer my questions, how come?

My suggestion, the needed to open the communication/discussion forum and polling via village pump or "warung kopi" is a must. You can see the community polling page here. Still you need as many as you can get or most wikipedian agreed to put the feature permanently on idwiki, usually 2/3 or more than 70% of users. You can see the table of active wikipedian for start the invitation. Let's say 100-200 invitation from top 200 active wikipedian and all stewards/birocrats. Better also using social media campaign "call for discussion" and personal approach/message in each wikipedian talk pages, using all forums available, you can ask for help with WMID. After all of this process valid and most of wikipedian agreed, then you can put it on as per date you want. It takes not more than 1 month if this process already prepared. See this for example.

• 1 week "call for discussion" on all forums available, social medias campaign, personal messages, etc
• 2 weeks "discussion process", pros and cons, benefit or problems, all mentioned here. Report also needed for all process.
• 1-2 weeks "polling"
• 1 week "decision"/final statement.

But thanks for your time btw. I am speechless. Angayubagia (talk) 01:24, 2 September 2022 (UTC)

Bug report #25

Some users reported that they couldn't find the image they uploaded, even after searching using the file name as the keywords:

• https://commons.wikimedia.org/wiki/File:Keraton_Paviliun_at_History_of_Java_Museum.jpg
• https://commons.wikimedia.org/wiki/File:Revitalisasi_Museum_Taman_Tino_Sidin.jpg

I've checked and indeed I couldn't find them through Wikistories search, even though I could find them in Commons. I've mentioned this in my previous bug report that hasn't been answered Searching for a specific file, e.g. c:File:Solo (Surakarta, Java) banner.jpg, cannot be found with search term "Solo (Surakarta, Java) banner", "Solo banner", "Surakarta banner", "File:Solo (Surakarta, Java) banner.jpg".

If possible, please explain what hidden filter/setting that trigger this, and what changes have been made (for example, previously as I stated in my bug report Searching for "Surakarta bennylin" yields 0 result, even though there's plenty of them in Commons but now it's been populated, so obviously some changes have been made, but still some other images couldn't be found.

Screenshots: https://imgur.com/a/U8FQ4lk

Hi @Bennylin, thank you for this bug report! I did a little check and here are my findings:

1. From your screenshots, one of the images is missing in the result when searching for "Keraton Paviliun". We have a filter for our image search function and it returns only images that have both a height and width of 640px or greater. For the missing image, the file size is 504px × 719px so it does not show up.
2. The same applies to this image . The pixel dimensions are 554px × 720px and so we do not return it in the search. However, I can see now that there is this image - Revitalisasi Museum Taman Tino Sidin - 3.jpg that shows up when making the same search because it meets the image criteria.

I hope this clarifies. Please let us know if you need any more information about these two examples.

Regarding your previous bug report `"Surakarta bennylin" yields 0 result, even though there's plenty of them in Commons`, we will take another look at it and see how we can provide some more explanation shortly. Thanks once again!

Thanks!

Bug report #24

First I'd start with my observation of the workflow:

1. Choose images

2. Write captions

3. (repeat 1 or 2)

4. Name the Wikistories (choose a title)

5. Save

I always thought that the flow is not natural. When people creates a Wikipedia article, they always start with the title first, then the content. But this is just a minor observation, and I suppose there's a strong reason for this arrangement.

The problem arise when the title choosing is placed at the last step (as of current iteration):

0. There's so much blank space in this step that beg the question: what can be added in this step?

1. User (a.k.a. me) could forgot the title of the article, or at least the exact wording of the title. It happened to me yesterday, and I have no way to know the (exact) title of the page I'm at (other than to start over, but that would be Very annoying). So, please display the title of the article at this step. Displaying the Wikidata description underneath would be a plus (I'm not sure if that's my gadget or default feature in id.wp). PS: Hitting the back button is Not intuitive in this scenario. At the very least, autofill with the article name, like in step 1 (choosing images), although I realize this would conflict with #3 below (choosing unique title).

2a. There's no way to know which Wikistories title is already taken (when there's ton of Wikistories, like id:Kucing, and it could frustrate users. I suggest to display all Wikistories titles of that article below the textbox. To avoid over-information, the list could be not shown by default, and only shown when the user click "Click here to see all the Wikistories that have been made" button or something.

2b. And since this is a beta feature, you should never assume the user know that Wikistories title have to be unique, since there's no indication anywhere in this step. Therefore please tell the user so when they are at this step, and not after they gave a title that's already taken. (Plus list all the taken names, otherwise, they might fail to input a non-yet-taken names after several tries and get frustrated).

2c. When a name is taken, auto suggest other names. Either use numeral, or other suggestions.

3. A spellchecker would be a bonus, since many times I found users had typos in the title. And there's no easy way to change the title/redirect the page. (Please make this easier! At least put the link to Special:MovePage/Story:... in the three dot menu). I had to make id:Wikipedia:Wikistories/Permintaan bantuan for this.

Or, is it possible to start with the title of the Wikistories first?

Hi @Bennylin, thanks for sharing your reflexion on this topic. I've filed task T318243 directly referencing your feedback for the team to consider. Feel free to watch and join the conversation there.

Bug report #23

I've just deleted a story page, id:Story:Museum Balla Lompoa, but on my mobile phone (where I'm recording a video tutorial, and had to redo the recording), the story still showed up, with all slides and captions. (via PC and mobile). Purging the story didn't help.

Only when I tried to click "Edit", it wasn't editable ("Mohon spesifikasikan subjudul yang valid di URL ..." / "Please specify a valid URL subtitle ...")

This behavior is totally not expected, as when a wiki page is deleted, it should not be cached anywhere. The same goes to pages in Story namespace. Please fix this soon.

Edit: I did some tests with the original story above, so it might not appear anymore. Try this one instead: id:Story:Sekilas Museum Balla Lompoa , or in your test wiki.

Hello Bennylin,

Thank you for reporting this issue; our team will check this out and resolve it. I will share the bug ticket here if it is one so you can track progress.

Best regards,

Hi @Bennylin, we have tested story deletion early in the development cycle and I have tested it again just now on beta on the Dog bones story. I checked that the story page shows the correct deletion notice and that the story no longer appears on the Dog article.

Could you be more specific about the steps you took and what exactly you saw? Is it possible that there was just a delay between the story deletion and its disappearance from the attached article?

Thanks

Hi @SBisson (WMF): , I still find this story up and running https://id.m.wikipedia.org/wiki/Museum_Balla_Lompoa#/story/3701876

Although it has been deleted 3 days ago. https://id.wikipedia.org/wiki/Story:Sekilas_Museum_Balla_Lompoa

As how I did it, I just delete it normally, no extra step or anything.

Hi @Bennylin, I see it now. It turns out cache invalidation happens too often on test environments to really see the issue. I filed task T317999 to track the issue and proposed a fix. It could be deployed next week if all goes well. If it becomes a bigger problem with more stories being deleted, I can try to deploy the fix earlier.

Thanks!

Hi, I stumbled on Wikistories from the post on Movement Strategy Discourse. Though I don't read Bahasa Indonesia, I boldly created a story-board / slide deck for tiram (oyster).

Creating a story for the first time was a much more fun than I expected. I think this has great potential for user engagement. I hope my concerns about the feature will be allayed as I learn more and as the product develops.

Finding images is a limitation. The default search for “Tiram” on Commons returned some reasonable images (I recognise a photo of mine! didn't use it) but they weren't the best match for the text. I wish there was an easy option to select from the images that are already used in the article. Knowing how Commons search works, and using English search terms, gave me more choice. I'd love to know what we can do on Commons and Wikidata to help good images to be findable for new users in diverse languages.

It wasn't obvious how to re-order tiles in create mode, though I managed to do it in edit mode. Perhaps I wasn't tap-holding long enough?

More thoughts to follow.

When does Wikistories will be deployed on other Wikipedias (beside Indonesian Wikipedia)?

Hi NGC,

We are currently running the pilot in Indonesia to get feedback and fix any issues that have come up so far; once we get to a stable state, we will begin to consider other Wikipedias to test.

Which Wikipedia would you want us to consider for testing and feedback?

Personally, Romanian Wikipedia, as I am the most active there.

Hello NGC 54,

Thank you so much, for recommending Romanian Wikipedia. The Wikistories team will keep this in mind as we plan.

Best regards,

These suggestions are for the Story namespace, as I see them in desktop view, not the Wikistories on mobile view.

1. The image cropping mechanism need to be improved, so that the cropped images are optimal:

https://id.wikipedia.org/w/index.php?title=Story:Sekilas_tentang_kapibara&oldid=21315200 Only shows the back of the animals. Should show their faces instead.

https://id.wikipedia.org/w/index.php?title=Story:Anjing_Ras&oldid=21314827 The faces of the dogs are partly obscured by the text.

https://id.wikipedia.org/w/index.php?title=Story:Dunia_Kucing&oldid=21314740 Similar to the first one, the second image didn't quite show the face of the cat.

For non-animals: https://id.wikipedia.org/w/index.php?title=Story:Sekilas_seputar_Jembatan_Pasupati&oldid=21314222 Same, the second image didn't show up the bridge.

Therefore, the solution could be to let the user crop the image themselves.

2. The images should be clickable - to see the original picture.

3. More importantly, the viewer should be able to see the image credits.

4. Links to the history of the page, to credit the writers/contributors of the text

5. Wikilinks in the text wherever available (blue links), from the original text, or using [[ ]] tag.

6. While browsing for images for a story, the image selection is not optimal, only about 50% of the shown images are related to the story I'm building, and I can only use 3 of the remaining images. I want to know which Commons category is it populated from and why it was so unusable. I hope in the future I could choose many more images, and select which Category in Commons I want to choose from. https://id.m.wikipedia.org/wiki/Istimewa:StoryBuilder/Story:Kota_Surakarta

Hi @Bennylin, thank you for testing Wikistories and taking the time to report your findings here!

> 1. The image cropping mechanism need to be improved [...]

We have task T296784 for image positioning and task T310163 for moving the text.

> 2. The images should be clickable - to see the original picture.

See next point.

> 3. More importantly, the viewer should be able to see the image credits.

Yes, we have task T311150 for showing image attribution in the Story namespace, that includes a link to the file on Commons.

> 4. Links to the history of the page, to credit the writers/contributors of the text

Does "page" refer to the article the story is based on or the story itself? If it's the article, we have a link back to it just above the story but I guess we could have a section explaining that the story is based on this article with quick access to different links like the article history.

> 5. Wikilinks in the text wherever available (blue links), from the original text, or using [[ ]] tag.

That's a good point. I filed task T311826 for the team to consider.

> 6. While browsing for images for a story, the image selection is not optimal, [...]

The default image selection is based on the image present in the article and using the article title as a search string in Commons. You can change the search string in the search box at the top of the image selection screen to anything and use the resulting images in your story. Would you like to be able to type "Category:Planets" in the search box to view all the images in this category? All specific feedback about how to make it more usable is welcome.

If you are familiar with phabricator, you are welcome to follow the links to the tasks above and provide any more details about those features. Discussing here on the talk page is also always a good option.

Thanks again for your time

Thanks. Subscribing to the tickets.

> The default image selection is based on the image present in the article and using the article title as a search string in Commons. You can change the search string in the search box at the top of the image selection screen to anything and use the resulting images in your story. Would you like to be able to type "Category:Planets" in the search box to view all the images in this category? All specific feedback about how to make it more usable is welcome.

Correct. Either typing the category name, or, infinite scroll, or paging link (next 50 images, "more" button, etc.)

• Searching for "Kota Surakarta" (as per my first post) is no good
• Searching for "Surakarta", "Solo", or "Kota Solo" are even worse, the result came back from one category only (https://commons.wikimedia.org/wiki/Category:Gaya_Surakarta)
  • Addendum: Not sure if this is doable, but searching for images from (user curated) gallery pages should be considered, i.e. https://commons.wikimedia.org/wiki/Surakarta
• Searching for "Category:Surakarta" is loading forever (https://commons.wikimedia.org/wiki/Category:Surakarta). Ideally this should be provided for power users (with autofill suggestion), as well as searching for a specific file name.
• Searching for a specific file, e.g. c:File:Solo (Surakarta, Java) banner.jpg, cannot be found with search term "Solo (Surakarta, Java) banner", "Solo banner", "Surakarta banner", "File:Solo (Surakarta, Java) banner.jpg".
• Searching for "Surakarta bennylin" yields 0 result, even though there's plenty of them in Commons: https://commons.wikimedia.org/w/index.php?title=Special:MediaSearch&search=surakarta+bennylin&fulltext=Cari&type=image
• Addendum: Searching for "intitle:Surakarta" seem to yield a little better result, although still cluttered from result in https://commons.wikimedia.org/wiki/Category:Gaya_Surakarta
• Meanwhile, searching for "intitle:bennylin" again yields 0 result, although there's plenty of them: https://commons.wikimedia.org/w/index.php?title=Special:MediaSearch&search=intitle%3Abennylin&fulltext=Cari&type=image
• Number of result: seem to be arbitrary. I compared there was 32 for "Kota Surakarta" (39.227 in Commons), while only 22 for "Surakarta Java" (39.487 in Commons).
• Conclusion: there's no easy way to get any good illustration of the said subject as of today, without having to change the search terms many times.

I think this problem is more on the MediaSearch, so I'm submitting a ticket to address that problem. phab:T311834. I gave some ideas for sorting improvements there, because I believe MediaSearch is key factor for Wikistories. Bad result/ bad sorting algorithm would result in cases like what I found above.

Other suggestion

7. Image hovering on the search result (desktop view, with mouse) should show file names, and/or description, and clickable (middle click, right click) to Commons.

Second experiment with "Tionghoa-Indonesia" article: https://id.m.wikipedia.org/wiki/Istimewa:StoryBuilder/Story:Tionghoa-Indonesia

Searching illustrations for "Tionghoa-Indonesia" only yields 11 results (compared to 381 in Commons)

• Wikidata has far more results than that d:Q1945786 contain 35+ images
• Can Wikistories uses data from Wikidata as the search result?
• Searching for "orang Tionghoa Indonesia" only yields 3 results (compared to 13 in Commons). Why not display all 13 results? What kind of additional filters are put in Wikistories search? Obviously there's some discrepancies, like this one, or searching "bennylin" results in nothing.

Third experiment with "Garis Imajiner Yogyakarta" article: https://id.m.wikipedia.org/wiki/Istimewa:StoryBuilder/Garis_Imajiner_Yogyakarta

Default search result from StoryBuilder return no images.

• The concept only found in id.wp d:Q96012243, and there's no category on Commons
• Should offer images found in the article (see suggestion 9 below)
• The user who created the story probably need to do it manually, or via Story page name.

Other suggestions:

8. Simple text editing, like italic, bold, and underline. With keyboard shortcuts (Ctrl-B, etc.), or wiki markup (triple single-quotes, etc.)

9. Should be able to take existing images from the article to be used in the stories.

> The default image selection is based on the image present in the article [...]

This is definitely not the case here, as seen from the 2 experiments I conducted. In my second experiment, only 1 of the 11 results are used in the article, and the other 18 images in the article were not available as selection.

Update on the first experiment. I've cleaned up a bit in Commons, and uses "-tari" to exclude the hundreds of dance pictures, and I've got a better result now.

Some more suggestions: 10. When adding new images, don't display the images that are already selected. For example, I've already had 3 images in the story from yesterday, when I'm adding more images, don't include those 3 images among the result today. If someone really want a duplicate image for their story telling, I suspect their numbers would be low, so make it as an extra step for them, don't display duplicates for the majority of users who didn't want duplicate images in their stories.

11. Users could decide the order of the images. As of now, I'm stuck with getting the images displayed in the order of the search result, let's say 3 images, a-b-c. While what I wanted to build was c-b-a, or b-a-c, etc. Either provide a way in the selection process to sort the images based on the order I'm clicking the images (which has been my experience in messaging app when I'm attaching pictures, for example), or, after the images have been selected, in the list of images in the bottom, provide a way to drag and drop to change the order.

(PS: reminder I'm doing the tests using desktop with mobile web version, with my mouse, so let me know if there's some difference with the real mobile experience)

Even the editing tool in Story namespace didn't have an easy way to change the order.

12. Since there's two ways to edit stories, one through JS (StoryBuilder), and one using no JS (using Story namespace), maybe provide a direct link between the two. For example, I wanted to change the fourth picture of the map of the city, but searching for the image "Peta Solo per kelurahan.svg" and many variations (peta solo, peta surakarta, peta kelurahan etc.) return 0 result, so I had to change it manually, but there's no direct way to do it.

13. I just noticed something strange when I edit the story manually (#12 above), This edit says I'm deleting 4138 bytes of data, when I'm only changing one image. How is that possible? I didn't lose any text either.

14. A small pet peeve, maybe implement a shortcut "Ctrl+Enter" when finished editing text.

4. Regarding #4 in my first post "Links to the history of the page, to credit the writers/contributors of the text", I suppose both, the link to the history of the original article, and who made the story (since the text could've been written all by the story maker(s) too). Images get their credits, why not the text of the stories as well.

> Does "page" refer to the article the story is based on or the story itself? If it's the article, we have a link back to it just above the story but I guess we could have a section explaining that the story is based on this article with quick access to different links like the article history.

In Story namespace, the link goes immediately to the JS version, so there's really no easy way for the viewer to see the contributors of the article. Maybe a different link is needed, with text such as "[article name]" - "by Wikipedian contributors", the first link to the JS version, and the second link to the history page.

In the JS version, maybe put it at the very last slideshow, showing when was the story made and/or last changed, and by whom. No need to be big and center, maybe just like the opening slide with the title of the story, it could be a one liner in the bottom.

15. I noticed that for PNG and SVG file with transparent background, the background in the JS version would be black. Could this be made into white? Otherwise I will need to reupload my PNG image with white background.

16. The link in the Story namespace, if I'm in desktop mode, should still link to the mobile web version, so that the JS version would be displayed. (Currently if I'm on desktop mode, the link would also go to the desktop mode, and wouldn't display the JS version)

1. & 2. Regarding #1 and #2 in my first post, when I searched for some pictures, the cropping mechanism also didn't allow me to have a good look of the pictures, like in this screenshot . Ideally when I hover, I should be able to see the full picture.

17. I haven't tested much in my hand phone, I'm waiting for the public launch on Monday. So far I couldn't get the mobile display correctly in my phone, so the wikistories experience is also not quite pleasant for now (arrow, close, and pause buttons and texts too small, and panoramic images get zoomed too much in portrait view to my liking, cannot swipe, editing is generally unpleasant.)

18. I tried to create a story through Story namespace, filled all 20 fields, except for Frame 10, I had a typo, then when I clicked publish, it said "The file ... was not found", and the rest of the information that I filled disappeared. Ideally, even when there was error when submitting the form, the user didn't have to re-write everything again. Just like the form in other websites.

The same happen when the file name contains "File:" in front of the file name (or the localized term).

19. When mouse-hovering over the stories, should display the story titles, otherwise, the user cannot expect which is which, or if looking for a specific story, couldn't easily distinguish between stories just by looking at the thumbnail (image in circles).

20. Related to #13, I was changing the "Related Article" field in the Story namespace, but the diff didn't show the change . I think there are some bugs in the diff, between this and #13 above. Clicking "Show changes" button, or trying to revert the edit, also didn't show the change in "Related Articles" field.

21. More than 1 "Related Articles" value. Some stories that I made could be displayed in multiple articles, therefore with multiple "Related Articles", I don't have to copy paste the stories to several articles.

22. Linkback and (global) file usage. The images that are used, are not displayed in "What links here" special page, nor the (global) file usage in the File namespace. Linking them is useful for people who go to the file description to go to the story.

Hi @Bennylin, thank you for your feedback while testing Wikistories! I work with the Wikistories project team and I will like to provide some feedback on some of your observations:

Points 7, 14, 16 ad 19 all refer to being able to view Wikistories on the Desktop. We originally focused on optimizing it for a mobile view. We filed a task T313514 to consider this in the near future.

> 8. Simple text editing, like italic, bold, and underline:

This sounds like a good idea. I created a task for it for consideration - T313541.

> 9. Should be able to take existing images from the article to be used in the stories:

In some instances, some of the images on the Wiki page are not free for distribution. That might be what you are experienced. However, kindly let us have some data from the experiment you conducted and we would check this.

> 10. When adding new images, don't display the images that are already selected:

Yes, the implementation to show all images in the search results was intentional, in the event anyone wanted to reuse the same image. If the decision is made to change this, it will be captured here - T313555.

> 11. Users could decide the order of the images:

It is indeed possible to reorder story pages by tapping and holding briefly on a thumbnail, then moving it abound. Perhaps some information about this would have been more helpful. We can consider adding that as part of this task - T314166

> 12. Since there's two ways to edit stories, one through JS (StoryBuilder), and one using no JS (using Story namespace), maybe provide a direct link between the two:

This is a good point for consideration and I have created a task for it T314103.

> 13. This edit says I'm deleting 4138 bytes of data, when I'm only changing one image:

We have identified a bug with this and are fixing it in this task T313511

> 15. I noticed that for PNG and SVG file with transparent background, the background in the JS version would be black:

You are right about SVGs showing up on a white background. We shall correct this experience with this task T314101

> 18. I tried to create a story through Story namespace, filled all 20 fields, except for Frame 10, I had a typo [...] Ideally, even when there was error when submitting the form, the user didn't have to re-write everything again:

The editing experience will be improved in this task T313957.

Thank you once again for letting us know your thoughts and observations, it is highly appreciated.