Bugs/Todos

[LadyBytes]

• [x] handle empty results (Wiki and EEXCESS individually)
• [x] Uncaught TypeError: Cannot read property 'hide' of undefined window.onmessage @ VM4977:213
• [x] strange sidebar size due to $(".wikiEditor-ui") not being available in spite of $(document).ready(function () {}
• [x] no right border

Lisa:

• [x] persist the selected filter in chrome.storage instead of the current method of storing it in a variable
• [ ] extension default aktivieren: I thought about this and don't think it's the way to go as I myself would be bugged if it would be enabled by default. How about I persist the state after a reload using the storage?)
• [x] check which result is the bigger one and adapt map function accordingly
• [x] adapt size (it doesn't look good when the result area is bigger than the editors white-colored areas. and I anticipate being asked to make the whole thing resizeable by dragging soon anyways which renders the issue moot.)
• [x] write out filter titles

Stefan:

• [x] last query speichern
• [x] context keywords anzeigen
• [x] handle passive queryTriggeredEvent
• [x] improve: (adjust insert link's background on hover)
• [x] update/check insert links for eexcess results
• [x] could you try to decrease the time it takes for the loading bar to show up when using passive searches (i.e. fire the first queryTriggered-Event directly after the enter-press is detected)? It takes quite some time and users could mistake it for not firing correctly
• [x] direct loading bar displaying also for searchOnSelect
• [x] improve passive search wiki query
• [x] searchbar style: stretch to full width and block wrapping of button in next line

[kunzstef]

@M3hrL1cht I fixed now the passive search triggering, but for a paragraph I have multiple context keywords, but in Wikipedia only the first one is searched. Shouldn't we fire multiple search requests for each context keyword or is there a possibility to insert more keywords when querying wiki commons? And who implements it? Should I work on this?

Also I now inserted the context keywords into the searchbar after a new search was triggered passively like this: "keyword 1" "kw 2"... Here we could think of treating words surrounded by " as single context keywords to enable searching with multiple context keywords out of the searchbar, because now you get different result if you re-submit a query actively with the inserted keywords in the searchbar after a passive search -> could be really confusing as end user. what do you mean? should I work on this feature? @schloett @chseifert

[LadyBytes]

I quickly tried to send multiple keywords to wikipedia and it works if we use "OR" as a logical search operator in-between the terms. You can take a look at it in the new feature branch /multipleKeywordsWiki. I'd prefer firing only one search due to performance concerns, but there's a problem if we have only one request: Currently I search for the first three keywords which means that wikipedia will aggregate all results for the first keyword, then the second, then the third. We also specify a certain amount of images we want to return (20 atm), which means we only get to see the first 20 images for the first term unless the first term yields less than twenty in which case we actually would get to see results our second term provides. If we use "AND" instead of "OR" we don't get any results at all using passive search in most cases.

So, we can either fire one search per term which could increase loading time (although if we would decrease the number of results per term dependent on the number of terms as well as the number of terms itself, that could be manageable). Or we fire only one request and include a fitting one-time notification for the user which states that on passive searches only the first term is used for image search.

Any ideas?

Regarding you second question: Wikipedia actually supports "multiword queries", so that shouldn't be too hard to include. :)

[kunzstef]

OK then I would say we concatenate the single context keywords with OR and when a passive search was triggered we fire only one request to Wikipedia. Then we will get for popular keywords only images for the first one and display a one-time-notification explaining this.

But I would also remove displaying the passive search querys content in the searchbar, because it will be too long for the searchbar and not logical for the user, because when he re-submits the displayed query differnt results will be shown if we don't manually parse "a a" OR "b b" to single context keywords.

And I would not only submit 3 context keywords. I would use all, even though they most times will be ignored, that we always get our given number of pictures.

If you agree I could work on this

[schloett]

If wikicommons supports boolean search, you might use the same semantics as the federated recommender: In contextKeywords is a flag isMainTopic (or named similar), which indicates, that this keyword is the overall topic of the paragraph. Usually, the federated recommender contructs a query that looks like: ("main topic") AND ("keyword 1" OR "keyword 2" OR ...). Another option could also be to use only the main topic as single keyword for a query.

[LadyBytes]

Hey @kunzstef, go ahead! Jörgs's "xz AND xy OR xx" approach is definitely worth a try and should work as I've stated in my comment. Please work on my feature branch as I've already implemented the basics. All you have to do is check for a main topic and assemble the keywords using AND in this case. The particular function is called buildWikiQuery and located in background.js.

[schloett]

some more bugs/todos ordered by priority:

high

• [x] adapt post-install page
• [x] reference/image is inserted twice
• [x] restrict providers to Mendeley and ZBW (and also check for document type - atm more providers are included and when you try to include an image from Europeana as ref, strange things happen

medium

• [x] use thumbnails (did not see this mentioned at first glance, hence I listed it here)
• [x] result list size: not sure what the best option would be, my current guess would be a fixed element, which takes all of the available height in the viewport (-> upper and lower bound of the list always visible). This would might need resizing during scrolling, to account for the top and bottom menus in the current configuration. Alternatively, the div of the list might be appended to mw-content-text, which could simplify this issue.
• [x] remove options (or adapt)

low

• [ ] initially activate extension (there is already a todo, with an argument against, I would vote for it, since after I've installed the extension, I want to try it). Still the state needs to be persisted
• [x] move from browser-action to page-action (the extension only works on wiki edit pages and hence the latter is better suited)
• [ ] add possibility to switch of auto-query?