Hello Hay,

Thanks for the positive words, and for all the feedback. You're clearly a good person to talk to!

- I agree that it would be great to have autocompletion within the "select class" input. Similarly, I agree that it would be great to have free text inputs to let users specify arbitrary values when choosing filters and filter values, again with autocompletion, in the style of your VizQuery tool. These wouldn't replace the current interface, which just involves clicking, but I think they would be a nice complement to it. We didn't implement any autocompletion, in part because we didn't know how to do it, so it might be nice to steal some of your SDSearch code for that purpose.

- It's true that queries can take a long time, especially for the classes with millions of items (like "human") and especially before a lot of filters have been applied. Using the API could be nice, if that works faster - I didn't know that was an option. Getting the Q code first, then the label, could also help with another big "to-do" item, which is being able to display items that don't have a label in the current language. Right now, the language is always English, and most Wikidata items do seem to have an English-language label, but there are still a lot of gaps. For example, there are 22,000 items whose class is "literary work" and whose genre is "Tang poetry", but only 20 (!) of them at the moment have an English-language label:

https://wikidatawalkabout.org/?c=Q7725634&f.P7937=Q482&f.P136=Q3236984

And, as I'm sure you know, the overall labelling coverage is much worse for all non-English languages. It would be great to get the item code first, then display the item in whatever language label is set for it.

- Yes, there are a few bugs with the handling of the application "state", mostly when hitting the back button - sorry about those.

That's also good to know about your "Tools Directory"! A pretty neat resource. We'll work on getting Wikidata Walkabout registered there.

-Yaron

On Thu, Sep 24, 2020 at 5:40 AM Hay (Husky) <huskyr@gmail.com> wrote:
Hey Yaron and Sahaj,
awesome, i've been thinking about building something like this before,
and it's nice that somebody finally did just that :)

A couple of things I noticed:
* I understand that you're trying to hide Q/P-numbers (which I think
is a good idea), but you still need them for the 'Class' entry at the
top. You'll probably want an autocomplete-like thing there that gives
back items. I see that you're using Vue.js, so you could maybe get
some inspiration from the autosuggest component i've been using in
SDSearch (https://github.com/hay/wiki-tools/tree/master/public_html/sdsearch)
* Most of the example queries from the homepage (e.g. humans,
paintings) take a *really* long time to load. You're dealing with some
limits of the query service,but i could imagine that you could still
speed it up, for example by not getting all the labels, only for the
ones that you actually need on that screen. Alternatively, you might
get results a lot faster by using the search API and using the
'haswbstatement' operator
(https://www.mediawiki.org/wiki/Help:Extension:WikibaseCirrusSearch)
* There seems to be a bug when i'm using the back button on a class
overview page, i can only go back by clicking on the link to the
homepage.
* There's another bug (i guess?) where if i'm clicking on a filter i
get a message saying ('No filters'), but things are still filtered.
* I think it would be really useful if you could change your filters
on the fly, so that you don't need to go back to a previous page to
select a new filter. E.g, how this works on VizQuery
(https://hay.toolforge.org/vizquery/)

Oh, and you can help with making your tool more visible by providing a
toolinfo.json file and submitting it to the Tools directory:
https://hay.toolforge.org/directory/#addtool

Kind regards,
-- Hay

--
WikiWorks · MediaWiki Consulting · http://wikiworks.com