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=Q3236…
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(a)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