Jump to content

Topic on Talk:Wikistories for Wikipedia

Bad crop of images, and other suggestions

6
Bennylin (talkcontribs)

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

SBisson (WMF) (talkcontribs)

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

Bennylin (talkcontribs)

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.)

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.

Bennylin (talkcontribs)

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.

Bennylin (talkcontribs)

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.

EUdoh-WMF (talkcontribs)

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.

Reply to "Bad crop of images, and other suggestions"