Talk:View it! Tool

While showing images that have the depicts value is neat, I think images that have been chosen to the different Wikidata property for linking to a representative image (Q26940804) should be highlighted since those are manually curated and selected to the best of its kind. I'm thinking properties like sectional view (P2713), panoramic view (P4291) and such that should be surfaced. ♥Ainali ^talk_{contributions} 19:30, 24 August 2022 (UTC)Reply

Thanks Ainali for your experiments and suggestions with the tool. All of us appreciate your excitement and expertise. We've added all the Wikidata items to the list as we experiment with adding further sorting. Take care, please join us Wednesday at 14:00 GMT for live demo/discussion if you're available! JamieF (talk) 23:54, 29 August 2022 (UTC)Reply

Some recent properties like image of entrance (P9721) (currently not linked to Wikidata property for linking to a representative image (Q26940804) could also be interesting. John Samuel 12:02, 5 September 2022 (UTC)Reply

@Jsamwrites: I think with Wikidata property for linking to a representative image type properties, the question I would have is how to use this for discovering media beyond the representative image. Since these are for tagging a Wikidata item with a representative image—so the value of the statement is the media file, not a Qid—I think we need a property that's more of the inverse of this if we were for media results. Or maybe we could have a search filter that will just show all representative images of a topic. This would actually be querying Wikidata rather than searching on SDC statements, but it could be useful? Although I'm not sure how common it is for a single item to have more than one or two of these at a time. Dominic (talk) 22:23, 29 September 2022 (UTC)Reply

Wouldn't it be a better idea find better ways to direct people to the Commons category, where available?

(And investigate why people aren't clicking through more at the moment, and what could be experimented with to improve that -- eg make the link appear more prominently, as presumably you're intending for your View tool ?).

Commons categories already show the Commons materials relevant to a particular item, generally with the advantage of some manual curation and a descriptive infobox. They tend to be more complete, more on-point, and more organised than structured data tagging; and have more of a user-base working on and maintaining them. It would make sense to me to try to build from what we already have. Jheald (talk) 17:06, 29 August 2022 (UTC)Reply

Jheald, thanks for your comments. The current way it is set up uses the ”custommatch” operator which is inclusive of the category (not just depicts statements). The tool will also enable viewing other types of relationships, not just “depicts” or a category - basically anything in a structured data statement. Example: searching on a creator, along with location or subject. There may be fewer results in View it!, but “depicts” is a specific type of data about the media that is different from the scope of many categories about a subject. JamieF (talk) 23:55, 29 August 2022 (UTC)Reply

I came here to say pretty much the same thing as Jheald has already said. I'd love help with getting more Commons links added to Wikidata, and making them more visible. From the work I've been doing on that, I have two guiding principles from the Wikidata Infobox on Commons work that might also help here: 1) don't assume that people can add gadgets (particularly readers!), it has to work natively within MediaWiki, and 2) make it completely multilingual - never assume that the users can read your language, always make it work in their language. Thanks. Mike Peel (talk) 07:53, 30 August 2022 (UTC)Reply

Just want to share similar reactions. I'm in theory excited about View it! because I really believe Commons frequently gives a deeper way for readers a topic to explore a topic than a Wikipedia article does. And I agree that doing things with structured data is better than with Commons category tags. But I'm struggling to find the use case where the new tool gives a clear advantage. For me it's not a question of how good a new tool is, but the marginal gain: how much better is it than what I would use as an alternative? The alternatives in this case are: for readers, a prominent link from the Wikipedia article to the Commons category; and for editors, the FIST (Free Image Search Tool). In some of the examples used in the presentation, the images returned by View It! were the same as you'd get by following the link from the article to the Commons category, and arguably in some ways the Commons category is better. Commons categories include a lot of detritus with scant connection to the topic, but they have subcategories which let me quickly navigate to something more relevant. So I think the tool needs more development before it makes a huge difference to me as a wiki contributor, but more importantly you need better examples to make the case. Thanks to the team for the presentation today. MartinPoulter (talk) 17:17, 31 August 2022 (UTC)Reply

User:Mike Peel We agree about trying to make the tool as user/reader/beginner friendly as possible, in it's final literation we hope it'll work natively we can encourage adoption. We are working on making the tool multilingual already (if you're feeling up for helping us translate, that'd be great!) Thanks for installing and taking the time to give us feedback! JamieF (talk) 21:56, 29 September 2022 (UTC)Reply

User:MartinPoulter What you're saying is completely valid and we are working to add a category search as well. Hoping it'll be live within the week - we will post when it's live. JamieF (talk) 22:02, 29 September 2022 (UTC)Reply

@JamieF: Would it be appropriate for the tool to at least give a link the relevant Commons category in its output, when there is one? Jheald (talk) 12:13, 4 October 2022 (UTC)Reply

 Support I suggest a line like "A structured overview of images about this subject can be found in [link to the relevant Commons category]". At this moment, when visiting a popular page on a Wikipedia, for instance "Paris", and click on the "View" tab, you get lots of photos of the Eiffel Tower, while people might be looking for other subjects. Moreover "Wikimedia Commons" in the left column will be unknown to a lot of visitors of a Wikipedia. So I think it would be a good idea to repeat the link on the View page and give a short description.

Perhaps an extra alternative might be a link to the Galery page, if there is one. If it is a good one, it gives a nice visual overview of the subcategories with links to more images, for instance to the ones someone is looking for. JopkeB (talk) 05:13, 11 October 2022 (UTC)Reply

• @JamieF: A further thought: one place where (perhaps paradoxically) the tool could be especially useful could be on Commons category pages themselves -- to allow one to quickly look at a selection of pics that may drill down several levels from the category. But the tool seems not to be enabled on Commons? Jheald (talk) 16:46, 20 October 2022 (UTC)Reply

• @Jheald:, @JopkeB:, @MartinPoulter:, and @Mike Peel:: I wanted to say thank you again for sharing all of your thoughts on this and I wanted to provide an update. First an FYI, View it! is enabled on Commons, but it will probably only show up in the main namespace - or whichever page is in the Wikidata sitelink. (Ex. Monte Xiabre). Second, we have launched an advanced search option on the Toolforge page. When toggled on, users can search and view the related Commons Category and the results also offer a button that will display any subcategories. This way, users have multiple options for results (and hopefully viewing what they're looking for) including the Commons Category and any related subcategories. Thank you again for sharing your insights and concerns, please feel free to keep sharing! JamieF (talk) 19:44, 2 November 2022 (UTC)Reply

On this page can you give the gist of the algorithm(s) used? Is the end goal simply to show quality and variety? Who wins in ranking -- is it pre-set priority of Wikidata fields, or does it prefer quality? Does it go into Commons subcats, or just use Wikidata without regard to Commons -- furthermore, what would editors do to influence results? Can editors and readers flag images that plainly should not be on the hit list?

Some of the issues I found in a brief test are already on phrabricator, but for the sake of other viewers looking around this month I compared results of Aztecs and Maya civilization, with the former showing quite nice results and the latter showing several inadequate or silly ones and repeats. I chose these to test because of their large and varied (but not overwhelmingly so) Commons cat and subcats, and comparatively sparsely complete Wikidata entries. SamuelRiv (talk) 17:45, 29 August 2022 (UTC)Reply

SamuelRivThanks for your comments. The current way it is set up uses the ”custommatch” operator which includes the category (not just depicts statements) in search results. Some of the silly or repetitive results may be issues more in the data or Commons categorization, rather than the tool itself—though we will use all of this testing feedback to see if we can refine the search logic we use. For example, this is how the query pulls up results for “Aztec”: https://commons.wikimedia.org/w/index.php?search=custommatch%3Adepicts_or_linked_from%3DQ12542&title=Special:MediaSearch&type=image Thank you for your feedback, we really appreciate you taking the time to experiment. These are all issues that we are thinking about as we refine the tool. Please feel free to join us on Wednesday at 16:00 GMT for a virtual meeting/discussion to discuss in more detail if you’re available! JamieF (talk) 23:55, 29 August 2022 (UTC)Reply

I don't have an opinion on how you select images, but the display tool needs thumbnails, slideshow and context. Basically something like https://commons.wikimedia.org/wiki/Category:Dover_Castle, but with an added filter, as I did by modifying the HighslideGallery extension to mediawiki at http://johnbray.org.uk/fortcentral/Dover_Castle in the Images tab. Also allow switching between gallery+text and slideshow modes using a URL switch, something Commons seeps to be missing Vicarage (talk) 07:40, 30 August 2022 (UTC)Reply

Hi Vicarage - thanks for your feedback, we are still working on what the final interface will look like and we are working on adding additional filtering. I'll be adding your comments and example to Phabricator and I'll leave a message when we've addressed what you've mentioned. Thanks again JamieF (talk) 00:42, 1 September 2022 (UTC)Reply

If you develop a clever selection technique, provide an API to return the relevant images/metadata in json format, so other display tools can be used to provide the gallery/slideshow etc. Vicarage (talk) 08:31, 30 August 2022 (UTC)Reply

@Vicarage: Thanks! This is something we were thinking of as well. Not yet well described, but the request is being tracked at task T315373. I'd love to hear more about your use case (or just any ideas you have) for an API endpoint. Dominic (talk) 16:10, 30 August 2022 (UTC)Reply

The webpage I mentioned before grepped out some Commons images from a wikipedia page as a proof of concept, so I could combine them with my own photographs and photographs from other relevant sites. What I'd want from an API is json or csv output with image name, description, date taken and lat/long and copyright information. If the requesting API could filter on those at the same time as wikidata Q number, that would be great. If there is a measure of image quality/how often its used, being about to chose the 10 "best" images would be useful. I could just about cope with a SPARQL query, but many users would want something simpler. Overall purpose, proving skins on wikidata/commons for a particular interest group Vicarage (talk) 17:15, 30 August 2022 (UTC)Reply

@Vicarage We've launched an advanced search on the Toolforge page that allows for control of assessment and resolution of image results. I think this helps address some of the items you mentioned. Thanks for taking the time to respond and share your feedback! JamieF (talk) 19:47, 2 November 2022 (UTC)Reply

IMHO when comparing this ("view-it") vs this ("Q search in Commons"), the second option is way better (content and aspect wise). Strakhov (talk) 17:39, 30 August 2022 (UTC)Reply

• @Strakhov: Thanks! I think you're right. The main difference is that the second search is searching on all instances of that Q-id in Commons, whereas our tool is only searching on depicts statements and the main subject category. This tool is an attempt to provide the user a more specific search experience than just anything with the article subject in its metadata—i.e., we want people to be able to look at images of the subject. Many of the other images with Q5916778 don't actually depict the artist. Of course, maybe depicts isn't the best relationship to search on with artists. I would love for you to play around with some of our new test features, that let you search on different types of relationship sin the data. For example, if you search on images where Q5916778 is the creator, you'll get many more results. Let us know what you think! Dominic (talk) 16:04, 1 September 2022 (UTC)Reply

@Dominic: With regard to structured searches a pretty cool tool was developed two years ago by Hay. With regard to an uncurated-pool-of-images-related-to-a-particular-topic/item selected through structured data statements, in es.wikipedia there is (since a few days ago) a link in the authority control template to a Q-search in Commons, located next to the link to the Commons category (see here). IMHO, showing only instances of depictions/P18 of the item is something comme ci, comme ça. Cheers. Strakhov (talk) 15:03, 10 September 2022 (UTC)Reply

@Strakhov we've expanded the search functionality (toggle on advanced search) of View it! and allow for showing other select depicts statements, as well as viewing Commons Categories (and subcategories). Just wanted to bring this to your attention. Thank you for sharing your insights and feedback. JamieF (talk) 19:50, 2 November 2022 (UTC)Reply

I've just discovered this tool. It is very powerful. Would be nice if the JS script could work on the mobile Minerva interface. Meanwhile, I've added a link to View it in my Chouette.js script (fr:Spécial:MobileDiff/196564296, fr:Utilisateur:PAC2/Chouette). PAC2 (talk) 19:56, 30 August 2022 (UTC)Reply

I also propose to add it to the Item documentation template on Wikidata. See d:Template_talk:Item_documentation#New_tool_needed. PAC2 (talk) 20:26, 30 August 2022 (UTC)Reply

@PAC2: Thanks, I really like the idea of including the idea of using it in that template, and we could see it being used in other infobox-like templates as well. Please let us know if there are any feature requests you come up with specific to that type of use case. I have also logged your report about mobile compatibility, and we will see what we can do about that. Dominic (talk) 20:00, 1 September 2022 (UTC)Reply

Nice idea.

Showing the link to the tool as a (Wikimedia) tab is counter-intuitive, when it opens as a new (browser) tab or window.

This also causes issues on smaller-screen devices, when the other (Wikimedia) tabs are shunted onto a "More" tab, but this tool's tab does not move there.

The tool should be shown in, for example, the left-hand sidebar instead. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:31, 31 August 2022 (UTC)Reply

Pigsonthewing thanks for your feedback - these are good suggestions that we're considering as we work on figuring out the UI. I'll leave a note when we finalize. JamieF (talk) 00:45, 1 September 2022 (UTC)Reply

@Pigsonthewing: Thanks Andy! I wanted to ask a follow-up question. Would you prefer to see this in the left sidebar, or is that only because it opens a new tab as it does currently? One alternative suggestion we have received is for the user to remain on the wiki page, and for the tab to work more like "Talk" opening or expanding an image gallery within the same article interface and not taking users to an external tool at all. I'm curious which type of experience you'd prefer, as we try to decide where to focus efforts. Dominic (talk) 16:10, 1 September 2022 (UTC)Reply

Personally I'd prefer the left-hand menu; but your alternative is better than the current situation. However, I should be concerned if the latter became part of the default chrome, as it would confuse newbies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:01, 4 September 2022 (UTC)Reply

Hey, I just started using View It! (with Vector 2022). I noticed that next to the View tab there is an image count label (e.g. View (0), View (99+), etc.). The first thought/association that came to mind when I saw the count was that it's somehow about notifications/unread messages. I realize this doesn't make much sense, but it's what came to mind. Anyways it made me wonder:

• What's the value in showing the count next to the tab? I can imagine it's nice to know if there are some images vs. no images, but is there value in knowing there are 20 vs. 57 vs. 99+?
• (Since I am always thinking about simplifying the interface, and communicating only the most necessary information) I'm wondering if it would make sense to show the tab as disabled when there are no images, and enabled when there are images? I've added a mockup of this below. Another, even more minimalist, option would be to hide the View tab when there are no images.

AHollender (WMF) (talk) 15:43, 2 September 2022 (UTC)Reply

@AHollender (WMF): Yes, we were wondering about what's best to do about this as well. The first iteration just put "View" on every mainspace page. One of the original design ideas (task T315895) was to suppress the tab with no results, but we implemented the counts and decided some people might actually like the visual indication that there are no results, versus just suppressing. I do quite like your proposal to make it appear disabled in that situation, and I am adding that to our workboard. (And I'm not ultimately against suppressing it altogether, either.)

Regarding the numbers, I do think there is some value in knowing more than just some images vs. no images. For example, I tend to use the number to decide how interested i am in checking the images out. If I am on an article with a few images in it already, and the View tab shows single digits, it's probably not worth my time to look at mostly all the same images—but if it's a lot more, I know there are images I am missing out on. Maybe that use case isn't worth the tradeoff of a more cluttered UI, though, and I'm definitely taking it under consideration. Dominic (talk) 16:34, 7 September 2022 (UTC)Reply

Thanks for your reply @Dominic. Perhaps the count is something that could optionally be available via a setting? Your comment "Maybe that use case isn't worth the tradeoff of a more cluttered UI, though" is a question/tradeoff I'm often faced with when working on Wikimedia UIs. Some people certainly prefer more information in all cases. At the same time, you could imagine if the Talk and History tabs also featured counts of some sort, along with the View tab, it might be overwhelming for some. AHollender (WMF) (talk) 16:21, 8 September 2022 (UTC)Reply

Hey @AHollender (WMF): Thanks for the suggestion on link disabling! This has been implemented in Vector Legacy, Vector 2022, and Timeless (see Phab task). Let me know if you have any suggestions on styling/implementation changes. Thanks, ~SuperHamster Talk Contribs 16:57, 5 October 2022 (UTC)Reply

On English Wikipedia in the article toolbar some of the tab labels are nouns (Article, History), and others are verbs (Talk, Edit). In general, unless it's a very common/well understood action (like Edit), I think it's much more clear to use nouns instead of verbs, as the nouns tend to be more descriptive. I think this is part of the reason that most other Wikipedias use the label Discussions instead of Talk.

I'm not sure what the considerations were, but it seems like for the View It! tool it was decided to use a verb: View. I think it would be more clear to instead use a noun, and I think either Images or Media would be good choices. The label View doesn't communicate much (if any) information about what will happen if I click on it, whereas Images and Media do. AHollender (WMF) (talk) 15:52, 2 September 2022 (UTC)Reply

@AHollender (WMF): This is valuable feedback! The name and interface messages have not gone through much review yet, and can certainly be changed. We focused initially on having a proof of concept to showcase for the community, but we are definitely still open to alternatives. The initial proposal at the time of funding was simply "Automated Depiction Viewer", so we felt we had to come up with something catchier, and this was our best idea so far. Of course, the name of the tool is a separate question from the actual interface message. My initial reaction is to be a little wary of "Media" in English, as the word has various meanings, and I am not sure it sets up a very clear user expectation either. The tab language is extremely easy to edit, and we're also working very soon on multilingual options. I am tracking this question on Phabricator for now, so we make sure to address it. Dominic (talk) 16:05, 7 September 2022 (UTC)Reply

There is also the option of just going with an icon, such as the one used in VisualEditor's interface: . Is that good or bad practice in terms of UX? Dominic (talk) 16:12, 7 September 2022 (UTC)Reply

Best practice is to use a label + an icon when space allows for it. Of course there are plenty of examples where we don't follow this best practice. Are you familiar with usertesting.com? We (WMF staff) have unlimited credits to run user tests there, and it would be quite easy to show a few different options to people (e.g. "View", "Images", "[icon]", etc.) and ask them what they expect to happen when they click on it. Happy to help you setup that kind of test if you'd like. AHollender (WMF) (talk) 16:24, 8 September 2022 (UTC)Reply

 Support "Images", as AHollender suggests. For the Dutch translation I was struggeling what word to use. I thought indeed "Afbeeldingen" (Images) would fit better than a verb, because "Images" is exactly what we see when we click on the tab. "View" seems too broad and not clear enough to me. Though the word "Media" is often used on Commons, I still don't immediately think of photographs, maps and graphics, but rather of television, newspapers and social media (and I guess a lot of casual visitors of a (not English?) Wikipedia as well). So I would prefer "Images". JopkeB (talk) 08:09, 11 October 2022 (UTC)Reply

@JopkeBThank you for letting us know your preference and for doing the Dutch translation. We are still working on finalizing what the final interface/manifestation will look like and these comments are really helpful. I've added it to our Phabricator notes on design. Thanks again! JamieF (talk) 21:26, 17 October 2022 (UTC)Reply

I embed this tool at ITN Syndication Shizhao (talk) 07:52, 6 September 2022 (UTC)Reply

Shizhao thank you for letting us know! JamieF (talk) 18:20, 26 September 2022 (UTC)Reply

If anyone has come here because they are seeing [object Object] inside either the "View" tab or the Toolforge tool itself, this error is due to a change in the CirrusSearch endpoint we are using to retrieve data. View it! has been updated to correct this. If you are still seeing the error, you just need to clear your cache and/or do a hard refresh, which can be done in most browsers by holding "shift" while clicking the refresh button. Thanks, ~SuperHamster Talk Contribs 23:18, 8 September 2022 (UTC)Reply

Please edit this section with you response to our September 2022 beta testing update! Thank you for participating!! JamieF (talk) 21:23, 11 September 2022 (UTC)Reply

Maybe consider that, where the Wikipedia article (or whatever) you start from has a Commons category linked via a Wikidata item, for each subcat of that Commons category if there is a Wikidata item with an image, include that image as well (with one more step if the subcat is a metacategory)? If that were combined with a "more like this" option that worked from that subcat & its Wikidata item, it could perform very well. Otherwise, good categorization on Commons is always going to make your results bad for anything at all large. Examples:

en:Wallingford, Seattle ends up lacking the most notable buildings in the neighborhood: the Home of the Good Shepherd, Lincoln High School, the former police/fire station, and the supermarket (now a QFC) with the big "Wallingford" sign on the roof. Presumably that is because these each have a subcat of their own. Similarly it shows nothing for the former Lake Union Gas Works, now the award-winning Gas Works Park. (Most of these things are NRHP-listed.)

en:National Register of Historic Places listings in King County, Washington does not even turn up the bulk of the images that are displayed small on the page itself. It mostly comes up with the least important places that qualify, again presumably because of subcatting.

en:Great Seattle Fire shows nothing of the aftermath of the fire, presumably because that has a subcat of its own.

en:Nazi oddly includes Commons:File:Berlin,_Flughafen_Tempelhof,_BMW_i8_--_2019_--_4349.jpg (no idea why) and Commons:File:Suppentasse_Deurag-Nerag-Werke,_NS-Zeit.JPG (presumably because this object dated from the Nazi era someone put it in Commons:Category:National Socialism? Quite a stretch, but that's not your algorithm's fault) but almost nothing that more than incidentally shows Hitler. Again, presumably the same subcatting issue. - Jmabel (talk) 19:48, 12 September 2022 (UTC)Reply

@Jmabel thank you for taking the time to offer feedback. We have expanded the View it! search on Toolforge to include results from Commons Categories (toggle on advanced search, and use the Commons Categories depicts statement). When using this statement, users are also given the option of viewing the subcategories as well. JamieF (talk) 19:53, 2 November 2022 (UTC)Reply

That's certainly a good step (although at least with the current UI it is unlikely most users would ever find it). I don't think this is as effective as my suggestion above: for each subcat of that Commons category if there is a Wikidata item with an image, include that image as well, combined with a "more like this" option. - Jmabel (talk) 20:02, 2 November 2022 (UTC)Reply

See: https://conze.pt/app/commons/?q=Q14448679

I added a modal image-view and zoom option using LC Lightbox and OpenSeaDragon. Feel free to copy the changes under the same license of the tool (if you want).

What is the actual Toolforge URL for this tool? I could not find it. Waldenn (talk) 12:55, 14 September 2022 (UTC)Reply

Waldenn thank you for sharing! The Toolforge link is: https://view-it.toolforge.org/ JamieF (talk) 18:19, 26 September 2022 (UTC)Reply

First of all, thank you for the beta testing option. It's quite useful to find quality/featured/value images depicting a particular topic.

I am wondering if it is possible to have multiple filtres. For example, I would like to retrieve images

• Depicting multiple topics (e.g., depicting sky and building)
• Depicting a topic and created by a Wikidata identifier. (e.g., photographs of buildings by Q...)

Thanks. John Samuel 09:44, 28 September 2022 (UTC)Reply

• @Jsamwrites: Thanks for your comments! I like this idea of combining filters, and it's very possible technically. It is just a matter of how to design that in the interface. I am tracking this request at task T318984, and I've put some more design ideas there. Dominic (talk) 21:54, 29 September 2022 (UTC)Reply

Excellent tool, thank you; really obviously immediately useful & generally gorgeous.

Of course we can see that any number of bells & whistles could be added to make it do, well, stuff that it's not yet able to do. Probably no limit to the scope for feature creep. We might get into that, later. For now, three bits of instant feedback:

1. The landing screen uses a very traditional WMF design trope, of the top 60% of real estate not being image payload. (This is trivial & doesn't really matter much, but I make the observation.)

2. The tool demands that I click for more images once I reach the foot of the page. I'm far to lazy to do that. Google image search provides about five additional screens of images based on the UI noticing the user has scrolled to the bottom of the page, before asking for a click. Internet Archive search dispenses with 'more results' clicks entirely, adding more hits based on the scroll position, fullstop.

3. The search box will reject a search for a non QId string - e.g. "September". It could as easily instead return some WD items as results, based on elasticsearch, allowing the user to click through & see images against the QId. Easy enough to regex the search string to decide in which direction to take it.

thx --Tagishsimon (talk) 09:20, 30 September 2022 (UTC)Reply

Hey Tagishsimon! Thank you for your observations and suggestions! I added them into Phabricator as they're all items I think that could be really useful.

This might be a silly question, but in regards to your third point - did you toggle on advanced search and try free text and see if it got you the results you were wanting? Just curious if that got you closer to what you were hoping for. Thanks again! JamieF (talk) 21:24, 17 October 2022 (UTC)Reply

hello! I have added uk here View it! Tool/localization.json. I was not sure where exactly to let you know about this, so I am leaving the message here :) --アンタナナ 21:31, 7 October 2022 (UTC)Reply

Hi @Antanana: Thanks for adding that! The tool has been updated with the translation and it will appear on Ukrainian-language wikis. ~SuperHamster Talk Contribs 06:23, 8 October 2022 (UTC)Reply

I like the tool, but I do not like that there is an additional tab called View. --NGC 54 (talk｜contribs) 10:57, 8 October 2022 (UTC)Reply

NGC 54 thank you for letting us know - we're still finalizing what View it! will look like in the end product. We will definitely keep this in mind - do you have any recommendations for where you'd like a button/access to be for the tool? Thanks for your feedback! JamieF (talk) 18:36, 17 October 2022 (UTC)Reply

Yesterday I searched Youtube for "Starbucks employees should be able to afford a one bedroom flat", and today my Youtube feed was filled with videos about espresso and coffee pots and coffee history etc. Given that the algorithm did not understand the nature of my request, I'd like to be able to turn the algorithm off some times, or to exercise some control over it. Similar instances have occurred many times. When I realised why I was getting all the coffee video suggestions I tried searching for "algorithm doesn't know what I am talking about" and it returned videos about people being angry, which I wasn't. So if it is possible, at this early stage, please consider some form of user control. You'll set a long overdue precedent if you do. Thanks o/ ^{~^\}\_\.rT'{~ g 16:33, 16 October 2022 (UTC)Reply

Hi RTG since this tool isn't based on an algorithm, the user has all the control. We do have the source code available if you wish to take a look. Thanks for being interested and please let us know if you have other concerns. JamieF (talk) 23:14, 25 October 2022 (UTC)Reply

Hi JamieF, I don't want to take anyones time about this but having looked briefly at the code on your suggestion, it seems the results are to be based on Wikidata P codes assigned to the specific image or article being viewed at that time, rather than "related" or suggestions? ^{~^\}\_\.rT'{~ g 10:12, 29 October 2022 (UTC)Reply

@RTG No worries - we are here to chat about it (sorry for delays in responses). Yes, it's based on P codes or depicts statements, not "related" or suggestions. We did recently expand the search on Toolforge, so if folks need more expanded results, they can also search by Commons categories (and view subcategories as well). Hope this helps. Please don't hesitate to ask questions, thanks for your interest and for reaching out. JamieF (talk) 19:56, 2 November 2022 (UTC)Reply

Heads up to any vector-2022 users: There's a bug in the skin that causes the "View" button to appear higher than it should. There is an open Phabricator ticket for this, and it looks like it should be fixed soon. ~SuperHamster Talk Contribs 17:26, 27 October 2022 (UTC)Reply

First of all, thank you for this new update. Glad to see this new interface with the photographs on top of Wikidata and Wikipedia pages. I currently activated the full version across the Wikimedia projects. This new integration will give value to the works of numerous photographers on Wikimedia Commons who have contributed to the topics that are not very common (or popular).

Question/feedback: I do not understand the meaning of the file symbol (or folder symbol) on the bottom left of every photograph. I thought it as an option to hover over to get additional information. I think it's meant for some future use: quality/valued image? John Samuel 11:55, 9 January 2023 (UTC)Reply

Hi @Jsamwrites: Thanks for the feedback! That's a "copy-to-clipboard" function; clicking the icon should copy the syntax to insert the image as a thumbnail in the article (e.g. [[File:Name.png|thumb|left|caption]]). That being said, I've gone ahead and removed it for now until it is further refined (more accessible, tells you what it is on-hover, and only visible when editing). Thanks, ~SuperHamster Talk Contribs 14:01, 9 January 2023 (UTC)Reply

Thanks for the modification. The feature "copy-to-billboard" will be definitely useful. I suggest a clipboard icon in the future releases. John Samuel 19:41, 9 January 2023 (UTC)Reply

Copy-to-clipboard function is available again, and now only appears when editing a page. We'll consider a clipboard icon, thanks for the suggestion! ~SuperHamster Talk Contribs 19:14, 12 January 2023 (UTC)Reply

Hi. First of all - nice tool. I like the idea.

I think the scrollbar above article is too big. You could use `scrollbar-width: thin` there to save some space.

Added a patch to my V'22 style [1].

BTW. Not a huge fun of the left alignment of the button. On pl.wiki, and I think most other wikis (de, en), this kind of additions and buttons are usually right aligned. For example in POI articles with have a map button that opens an enhanced OSM map. See for example Polska article. Nux (talk) 21:50, 12 January 2023 (UTC)Reply

Hi @Nux: great suggestion, thank you! I've added the thin scrollbar CSS.

Regarding the left alignment of the button, could you clarify? Are you referring to the "Close View it!" button? That should be floated to the right already, but I may be misunderstanding the issue. ~SuperHamster Talk Contribs 22:00, 12 January 2023 (UTC)Reply

@SuperHamster Hi. Thanks for adding the scrollbar fix. As for alignment... Our indicators like padlock and the OSM map are in `.mw-indicators` (inside of `#bodyContent`) - they are right aligned (in LTR mode). The `#view-it-close-button` is inside `mw-body-header` just before `#firstHeading`. And so your blue button is left aligned and kind of in a wrong place (should probably be inside of indicators and open below the first header). Nux (talk) 00:53, 16 January 2023 (UTC)Reply

@Nux: Ah, gotcha! It was appearing on the right in legacy Vector and Timeless, but on the left in Vector 2022. That button was added rather last minute and I didn't properly integrate it with mw-indicators. Should be fixed now -- thanks for the detail. We'll likely rework where things are positioned altogether, especially with the feedback AHollender left down below. ~SuperHamster Talk Contribs 08:31, 18 January 2023 (UTC)Reply

Hello, I am struggling to understand the feature/tool "View it!". I try to understand what it does and what it is useful for, and who might benefit from it.

On the project description page, I found this explanation:

"The View it! tool enriches Wikipedia content by offering an illustration of a given subject. It increases the discovery of Wikimedia Commons uploads and encourages contributors to utilize Commons and structured data. While the number of images displayed in a Wikipedia article is finite and highly curated by editors, "View it!" allows readers to access the full catalog of images available on Wikimedia Commons, and help editors easily add relevant media to an article."

This means that I expect that the tool helps me finding images that I wouldn't find otherwise. The tool finds all related images. The tool helps adding an image to an article. If this is the promise, the tool does not deliver (in my view).

I have installed the full version on my meta user page (the subpage). When I now go to Wikipedia, I find a new space above a random Wikipedia article. There I see a quite limited number of file-images. I understood that these images are related to the topic of the article via Structured Data.

So this is a limited selection of the Wikimedia Commons (WMC) images to this topic, because only some if the WMC images in total have structured data, isn't it? Therefore, I miss a lot of images that may be relevant and useful.

What else can I do with the tool? The images on the new space above the article are small thumbnails. When I click on such a thumbnail, I am sent to the concerning file page of WMC. This means that I do not see any functionality that would help me to add the image to the article. I would have to copy and paste the file name, then go to the article page, click on "edit" or "edit source text" and embedd the image in the traditional way(s).

Finally I found the website of "View it!" proper. It seems to offer a new search functionality. I see "Search options" that are very limited, even in the "advanced search" version. I can search for a topic based on the Q-number of Wikidata. There is also a field "additional free text". Writing something into that field usually has the result that I get zero results.

Also, there are search options related to "assessment" and "resolution", which are not my primary concerns: first I try to find images at all. But this "View it!" tool does not show me more images than the search function on WMC itself. (Also, I do not know Q numbers by heart - I first would have to go to Wikipedia or Wikidata to learn the correct Q number.)

I tried the option to search the "main subject" of the image. As Berlin=Q64 is one of the few Q numbers that I know by heart, I tried it. But the result was only 1 (one) image. I am quite surprised that this is currently the only image with structured data where Berlin is the main subject. (But of course, I understand that at the moment not all images have structured data at all, that is not the fault of this tool.) Maybe, because I can only search for images WITH (any) assessment?

And, is it correct that I can only for something related to one Q-number, not several Q-numbers?

In conclusion, I do not understand how the tool would help me or anybody to find images (= better than via the existing functions of WMC). I also do not understand how this tool is supposed to help "users" (including new users) to add an image to an article. He would have to learn all the technical (and other) steps he has to learn already.

For me the biggest problem (in Wikipedia courses, for example) is now the limited functionality of the Visual Editor (VE) when it comes to images.

When I try to add an image to the article, the VE shows me the images that I have recently uploaded to WMC. These images, of course, are totally unrelated to the article that I try to edit. (Among others, I tried "Doktrin" on German Wikipedia.)

When I type a search word into the prompt, I get a number of images that is also quite limited (but more than I found via "View it!"). Again, it is the WMC search function that gives me much more results (even some relevant ones).

It would be great progess if the WMF improves the embedding function of the Visual Editor. It is exactly there where I would like to have an excellent search function, where I can search for images of a given topic, using free text, or using structural data, searching for images with a certain resolution, or within a certain category, etc.

As always: this is my superficial impression of the tool. I am very sure that I have missed something relevant or did not totally get the point of everything. Please correct my assessment where necessary. :-) Ziko (talk) 21:46, 13 January 2023 (UTC)Reply

I already enthusiastically said in a Telegram group a few days ago that the View it! tool helped me to discover an image for a Wikidata item. Would you consider adding a very easy-to-use drag and drop feature to immediately drag and add the image to the item with a P18 statement, a bit similar to the mechanics of, for instance, dragging images through the DragNDrop.js userscript? Thanks! Spinster (talk) 07:59, 14 January 2023 (UTC)Reply

@Spinster: We do really like this idea, and we had a similar feature identified already. It might look right now like a button with a confirmation dialog, rather than drag and drop. Hoping to launch in the next week or so! Dominic (talk) 19:02, 19 January 2023 (UTC)Reply

@Dominic That sounds great! Thank you for being so responsive to requests :-) Spinster (talk) 10:59, 20 January 2023 (UTC)Reply

After reading the Signpost article, I installed the tool. Using Vector-22, it seems a bit obtrusive, not just giving the new View tab but also pushing the article title rightwards to provide an Open View It! blue button. (On old Vector it is more discreet, showing on the right-side of the Title line, but that space is crowded by the Other-Languages selector in Vector-22.) AllyD (talk) 08:27, 16 January 2023 (UTC)Reply

• @AllyD: Thanks for pointing that out! Should be better in Vector-22 now. ~SuperHamster Talk Contribs 08:38, 18 January 2023 (UTC)Reply

  Thanks, the blue button looks much better, tucked in on the right now. AllyD (talk) 09:45, 18 January 2023 (UTC)Reply

• A different comment, but trying the tool across gd and zh as well as en.wiki, the word View in the tab bar looked conspicuous: presumably translations will be added? AllyD (talk) 08:32, 16 January 2023 (UTC)Reply
  • Translations for the "View" tab button can be done at View it! Tool/localization.json. We don't yet support localization for the "Close View it!" button, but plan to soon. If you're interested in adding translations and need help with that localization.json page, just let us know. Thanks, ~SuperHamster Talk Contribs 08:39, 18 January 2023 (UTC)Reply

Hey, awesome progress with the tool. My latest feedback: I don't love either of the two current options for where the images appear.

In the first version:

- they take up too much space at the top of the page

- the mechanism to close (and then re-open) them is distracting

- it feels weird, from an information architecture standpoint, to have the images above the page title (which is something we thought a lot about with Vector 2022, and why the tabs are now below the page title)

In the second (lite) version: they open in a new tab which causes a switch in context, and then extra work to get back to the article.

Two options I propose:

Option 1 — similar to what Google does, put a film-strip of images above the article content, and then give people the opportunity to expand it if they'd like

Option 2 — once someone clicks the "View" tab (which I still think should be called images/media/etc ; ), replace the article content with the images (which is how the other tabs like Talk, History, etc. work)

Also, in case it's at all helpful, here is a similar prototype I created for mobile a few years ago: https://mobile-media-tab.web.app/Tulip

Cheers, AHollender (WMF) (talk) 13:49, 16 January 2023 (UTC)Reply

@AHollender (WMF): Thanks for the great feedback, it's always appreciated (and congrats on the Vector 2022 launch on en.wiki). We've updated the carousel so that it now appears below the header, after the #contentSub element. I don't think it's perfect yet, and we'll likely keep iterating on it as we find odd interactions with other elements (e.g. I had to add some top-padding in Vector 2022 to avoid overlapping with the coordinates that appear on some articles). I also experimented with inserting the carousel after notices (hatnotes, maintenance templates, etc.), but the main challenge there is that it will disappear when entering Visual Editor; we could pursue that further, but it'd require a bit more work i.e. "moving" the carousel to a different area when entering or exiting Visual Editor.

I do like the "View x more images" in-line box in your first screenshot, we might experiment with that as well (the amount of vertical space the expansion arrows take up isn't great). If you have any other suggestions, please let us know. Thank you! ~SuperHamster Talk Contribs 01:32, 19 January 2023 (UTC)Reply

Is it possible to move the filmstrip outside the article body? Almost 2/3 of the screen are wasted for white margins, surely there is a way to place the filmstrip vertically left or right. With current vector-22 layout, wasting any part of the already shrunk-down article space seems undesirable. Retired electrician (talk) 22:04, 25 February 2023 (UTC)Reply

Example edit:

• https://meta.wikimedia.org/w/index.php?title=k;fsdlkd;s&action=edit
• https://pl.wikisource.org/w/index.php?title=Strona:PL_Leo_Belmont-Rymy_i_rytmy_t.1.pdf/5&action=edit

Uncaught TypeError: document.querySelector(...) is null
    viewItEmbedded https://meta.wikimedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:SuperHamster/view-it-full.js:287
    <anonymous> https://meta.wikimedia.org/w/index.php?action=raw&ctype=text/javascript&title=User:SuperHamster/view-it-full.js:470

Seems like you don't check if elements exist. E.g.:

• document.querySelector('#t-wikibase>a').href
• document.getElementById('mw-content-text').innerHTML

Nux (talk) 20:21, 22 January 2023 (UTC)Reply

@Nux: Thank you! Added a check for '#t-wikibase>a', you shouldn't see any errors on those pages anymore. I'm starting to go back through the code and cleaning it up, and hope to add better error checking and handling soon. ~SuperHamster Talk Contribs 08:34, 23 January 2023 (UTC)Reply

The full, embedded version of View it! has some new functionality on Wikidata. The copy icon now appears on Wikidata items, and clicking it will copy just the filename instead of the boilerplate thumbnail syntax you see on other wikis (since, well, you only need the filename when updating Wikidata statements). In addition, if you are viewing an item that lacks a P18 (image) statement, you will also see a new plus icon . Clicking this will ask you to confirm, and then instantly add the image as a P18 statement and refresh the page. Let us know if you run into any issues or have any suggestions. Thanks, ~SuperHamster Talk Contribs 08:41, 23 January 2023 (UTC)Reply

An alternative location for the "View" link could be the Vector 2022 page tools menu. I have disabled View it!, because for me it is too prominent (including the Lite version). The option 1 (#Two ideas for where to display the images) is too much prominent, and pushes downwards the content of the article. Wikipedia is firstly an encyclopedia, and the content of the article is much more important than the media provided by View it!. The option 2 would be, however, much better for readers. And "View" should be replaced by "Media". --NGC 54 (talk｜contribs) 13:51, 28 January 2023 (UTC)Reply

Right not, the instrument merely dumps everything in the connected category (or the whole category tree?) - and, conversely, does not show anything if such category does not exist (correct me if I'm wrong). Sometimes, the category is an unsortable mess of many hundreds of low-grade images. Is there a way to somehow narrow down the selection, either automatically or through manual curation? Retired electrician (talk) 22:10, 25 February 2023 (UTC)Reply

Breaks on the following line e.g. on mobile:

var VI_API = new mw.Api();

The message:

Uncaught TypeError: mw.Api is not a constructor
   viewItEmbedded https://meta.wikimedia.org/w/index.php?action=raw&ctype=text/javascript&smaxage=21600&maxage=86400&title=User:SuperHamster/view-it-full.js:2

Cheers, Nux (talk) 22:58, 12 March 2023 (UTC)Reply

If anyone has added the View it! script to their global.js, note that there is a bug that prevents the script from loading on Wikipedia projects. It looks like the issue should be resolved soon. Until then, if you want the script to run on Wikipedia, you'll need to import the script on each individual Wikipedia project. Thanks, ~SuperHamster Talk Contribs 14:43, 17 August 2023 (UTC)Reply

Update, global scripts are now working on Wikipedia again. ~SuperHamster Talk Contribs 03:39, 18 August 2023 (UTC)Reply