search

hochschule-darmstadt / openartbrowser

Exploring the world of arts using open data
http://openartbrowser.org/
MIT License
40 stars 10 forks source link

Display full-text search results in tabs split by type #199

Open EeveesEyes opened 4 years ago

EeveesEyes commented 4 years ago

Is your feature request related to a problem? Please describe. Introduce a tab view in the results page for full-text search which splits the result list by its type.

Why do you want this feature? What goals should be achieved To give users the possibility to find items other than artworks by full text search

Describe the solution you'd like A tab view like the related artworks tabs with tabs like 'Artworks', 'Movements', ... (all types, except 'all' tab) Before implementation, a concept needs to be created and discussed in the team. E.g., this featue does not make sense when a full-text search criterion is combined with an auto-completed criterion, e.g., a concrete movement

Describe acceptance criteria need to be fully specified before implementation started

Describe alternatives you've considered none yet, please discuss.

What effects does your proposed solution have Search component probably has to be changed

Additional context Mockup should be proposed in advance

BernhardHumm commented 4 years ago

Note: this change request applies to full-text search ONLY, i.e., the user does NOT select an auto-suggested element.

Also note: it needs to be discussed what the behavior should be if the user selects several criteria which are AND connected. 

       Bernhard Humm

Von: Adrian Kailus [mailto:notifications@github.com] Gesendet: Donnerstag, 19. Dezember 2019 13:40 An: hochschule-darmstadt/openartbrowser openartbrowser@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Betreff: [hochschule-darmstadt/openartbrowser] Display search results in tabs split by type (#199)

Is your feature request related to a problem? Please describe. Introduce a tab view in the search results page which splits the result list by its type.

Why do you want this feature? What goals should be achieved To give users the possibility to find items other than artworks by full text search

Describe the solution you'd like A tab view like the related artworks tabs with tabs like 'Artworks', 'Movements', ... (all types, except 'all' tab)

Describe acceptance criteria Search result list is split by type

Describe alternatives you've considered none yet, please discuss.

What effects does your proposed solution have Search component probably has to be changed

Additional context Mockup wip

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hochschule-darmstadt/openartbrowser/issues/199?email_source=notifications&email_token=ABYWHS6YPBOMDHYQGF42MELQZNTRLA5CNFSM4J5FFKUKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IBUFIQQ , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYWHS42O4J3V4S6NUHWMNDQZNTRLANCNFSM4J5FFKUA .

EeveesEyes commented 4 years ago

Here is a mockup I made, what do you think? 96a0513a7c4e45058531f2061a6d763a

BernhardHumm commented 4 years ago

My comments:

  1. There are issues with higher priority than #199 which I prefer to be solved first, e.g., the timeline on the start page

  2. This issue ONLY relates to full-text searches (i.e., no auto-suggested topic chosen) and only one search criterion! If an auto-suggested item is selected (e.g., the movement high renaissance), then the movement page for high renaissance is opened (and nothing else). If more than one criterion is selected (eg., movement high renaissance and motif mountain), then the current result page shall be displayed with artworks (!) belonging to the movement high renaissance and showing motif mountain

  3. We should discuss whether in this one special case (which will not be used often) a special treatment is suitable, whether it is worth the effort and whether it might be confusing for the user. I personally have my doubts

  4. The mockup below I find confusing: Why showing years if just a search string is given? (take the example “asdf” instead of “high renaissance”) What are the tags dress, formalwear caul? What do they have to do with the search string?

Viele Grüße

       Bernhard Humm

Von: Adrian Kailus [mailto:notifications@github.com] Gesendet: Samstag, 25. April 2020 13:49 An: hochschule-darmstadt/openartbrowser openartbrowser@noreply.github.com Cc: Humm, Bernhard, Prof. Dr. bernhard.humm@h-da.de; Comment comment@noreply.github.com Betreff: Re: [hochschule-darmstadt/openartbrowser] Display full-text search results in tabs split by type (#199)

Here is a mockup I made, what do you think? https://user-images.githubusercontent.com/28682931/80279058-62c1c200-86fb-11ea-931f-09ed7a1763e7.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hochschule-darmstadt/openartbrowser/issues/199#issuecomment-619367235 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYWHS36IPDWDLGDLNGHPFTROLEZ7ANCNFSM4J5FFKUA . https://github.com/notifications/beacon/ABYWHS5HZRYMY2723N4E7TTROLEZ7A5CNFSM4J5FFKUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOETVMWQY.gif

EeveesEyes commented 4 years ago

Because #69 is done now, here comes a new try (critique#1)

Proposal on how the new Search should work

Instead of selecting one of the proposed search results the user can search for arbitrary key words (critique#2). Then the user gets presented a overview of search results grouped in different tabs (all, artworks, artists, movements, ...). Each of these tabs show a result list containing items which match the search text. These lists are continuesly loading, so by scrolling down new matching search results are fetched and displayed.

New Fetching-List Component

Therefor the new entities-component gets refactored and a new 'fetching-list' shared component can be used by all pages. This should take a callback function to fetch new data from the parent (eg. the entities page or the search result page). The new fetching-list-component has a vertical paginator on the right side, making it easy to scroll up and down to different "pages" / sections of the list.

New Queries

The new search requires new queries. Each word of the search term should be logically disjunct (OR-connective) and should not only be applied to labels of artworks but to labels of all items in our data set (artworks, movements, genres...). Optional (to be discussed): Instead of just searching labels, all other meta data could be used for the search, too. Note that abstracts are excluded here, this would lead to meaningless result sets. This would include:

Advanced Search

Above the result tabs is a collapsed "Advanced Search" menu (which by default is collapsed) that gives the some more options to filter the current search. Timeline: At the top of the "Advanced Search" is a timeline which ranges from the first to the last inception of the result set. Moving the sliders filtes the result set by years. (critique#4.1) Tag Filter: Directly below the timeline is a list of tags of the currently displayed search results. Clicking on one (or more) of these tags will filter the currently shown search results by these tags. Therefor the tags are linked with a logical AND. (critique#4.2)

In the mockup below the all tab would show every "High Rennaisance" search result between 1453 and 1853 which have the tags "portrait" AND "formalwear". If you now click on an artist tab the same search options will be applied on the search results for artists. So this time the search results contains all Artists matching the search keywords, and match the given time period and tags.

@mauamy and me actually think this will get used very often. According to the statistics, we had 66 accesses to /search in all languages, but this is with the current search result page (which is quite useless tbh) (critique#3). We should aim for a search funtion which works like other websites do, eg. web-shops or google.

tmp

BernhardHumm commented 4 years ago

Thank you very much for this excellent, detailed proposal.

Could we talk about it?

Von: Adrian Kailus [mailto:notifications@github.com] Gesendet: Dienstag, 23. Juni 2020 23:08 An: hochschule-darmstadt/openartbrowser openartbrowser@noreply.github.com Cc: Humm, Bernhard, Prof. Dr. bernhard.humm@h-da.de; Comment comment@noreply.github.com Betreff: Re: [hochschule-darmstadt/openartbrowser] Display full-text search results in tabs split by type (#199)

Because #69 https://github.com/hochschule-darmstadt/openartbrowser/issues/69 is done now, here comes a new try (critique#1)

Proposal on how the new Search should work

Instead of selecting one of the proposed search results the user can search for arbitrary key words (critique#2). Then the user gets presented a overview of search results grouped in different tabs (all, artworks, artists, movements, ...). Each of these tabs show a result list containing items which match the search text. These lists are continuesly loading, so by scrolling down new matching search results are fetched and displayed.

New Fetching-List Component

Therefor the new entities-component gets refactored and a new 'fetching-list' shared component can be used by all pages. This should take a callback function to fetch new data from the parent (eg. the entities page or the search result page). The new fetching-list-component has a vertical paginator on the right side, making it easy to scroll up and down to different "pages" / sections of the list.

New Queries

The new search requires new queries. Each word of the search term should be logically disjunct (OR-connective) and should not only be applied to labels of artworks but to labels of all items in our data set (artworks, movements, genres...). Optional (to be discussed): Instead of just searching labels, all other meta data could be used for the search, too. Note that abstracts are excluded here, this would lead to meaningless result sets. This would include:

Advanced Search

Above the result tabs is a collapsed "Advanced Search" menu (which by default is collapsed) that gives the some more options to filter the current search. Timeline: At the top of the "Advanced Search" is a timeline which ranges from the first to the last inception of the result set. Moving the sliders filtes the result set by years. (critique#4.1) Tag Filter: Directly below the timeline is a list of tags of the currently displayed search results. Clicking on one (or more) of these tags will filter the currently shown search results by these tags. Therefor the tags are linked with a logical AND. (critique#4.2)

In the mockup below the all tab would show every "High Rennaisance" search result between 1453 and 1853 which have the tags "portrait" AND "formalwear". If you now click on an artist tab the same search options will be applied on the search results for artists. So this time the search results contains all Artists matching the search keywords, and match the given time period and tags.

@mauamy https://github.com/mauamy and me actually think this will get used very often. According to the statistics, we had 66 accesses to /search in all languages, but this is with the current search result page (which is quite useless tbh) (critique#3). We should aim for a search funtion which works like other websites do, eg. web-shops or google.

https://user-images.githubusercontent.com/28682931/85455719-788a2100-b59e-11ea-9949-5e363fc8f1c0.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hochschule-darmstadt/openartbrowser/issues/199#issuecomment-648425475 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYWHS7VXEYBJTYP2JJPDV3RYEKRFANCNFSM4J5FFKUA . https://github.com/notifications/beacon/ABYWHS7DKLXNSQMAP6UZFETRYEKRFA5CNFSM4J5FFKUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE2TDAAY.gif

EeveesEyes commented 3 years ago

What is the current state of this? What modifications are should be made to the proposal to make this ready and what is the priority at the moment?

BernhardHumm commented 3 years ago

I suggest implementing this in DDK art browser and, if realized before the end of the semester, porting to openArtBrowser.

--

Von: Adrian Kailus notifications@github.com Gesendet: Samstag, 19. Dezember 2020 12:17 An: hochschule-darmstadt/openartbrowser openartbrowser@noreply.github.com Cc: Humm, Bernhard, Prof. Dr. bernhard.humm@h-da.de; Comment comment@noreply.github.com Betreff: Re: [hochschule-darmstadt/openartbrowser] Display full-text search results in tabs split by type (#199)

What is the current state of this? What modifications are should be made to the proposal to make this ready and what is the priority at the moment?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hochschule-darmstadt/openartbrowser/issues/199#issuecomment-748459848 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYWHS3RO6SSILUVR7CLCDLSVSDSHANCNFSM4J5FFKUA . https://github.com/notifications/beacon/ABYWHS6GDUSQ5MDQS7XMUK3SVSDSHA5CNFSM4J5FFKUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFSOJOSA.gif

vinoroidski commented 3 years ago

Concept for full-text search:

Categories:

Backend: Search changes:

Sorting:

Fix for "All" items:

Frontend:

vinoroidski commented 3 years ago