UoA-eResearch / research-hub-web

Research Hub Web
https://research-hub.cer.auckland.ac.nz
MIT License
3 stars 2 forks source link

Redesign filter presentation #16

Closed uoa-noel closed 5 years ago

uoa-noel commented 6 years ago

As part of a new design the search filters on the desktop view are moved into a separate view. The new design also includes other minor changes to the text. Not yet ready for merging.

Hganavak commented 6 years ago

Nice progress @uoa-noel! :trollface:

uoa-noel commented 6 years ago

Search results and category list data in the search results page are moved into a separate service, SearchResultsComponentService. This is because components in the filter sidenav need access to the information, and they were unable to because they are not child components of the search results page. By moving the data out to the service, the sidenav components can get the information by requesting injection via the constructor. In the future, the search parameters/filters data could also benefit from being moved into SearchResultsComponentService, as the filter sidenav components need access to that information as well. Currently they are passed in the SearchFiltersService. The service can follow the observable data service pattern, e.g. as described in: https://blog.angular-university.io/how-to-build-angular2-apps-using-rxjs-observable-data-services-pitfalls-to-avoid/ https://stackoverflow.com/questions/39627396/angular-2-observable-with-multiple-subscribers#39758712 Not sure if BehaviorSubject is needed in our case though?

uoa-noel commented 6 years ago

Currently there is no loading state implemented for search results and categories. This means when new search results or the list of categories are being loaded, the category list component will for example display "All: ". This may need to be worked on in the future. Computing the height of the refine search panel mostly works, but it doesn't yet handle content changes. Need clarification on the wireframes - should the site header be sticky as we scroll down the page? Should the filter panel overlap with the footer?

uoa-noel commented 6 years ago

When a user selects a filter that narrows down the search results, the height of the page changes, which sometimes means the footer will become visible above the fold. The height of the Refine Search panel should change as well so it does not overlap the footer. The reverse also happens sometimes - when a user unselects a filter, more search results appear, and the height of the Refine Search panel needs to be increased. I've tried several approaches to recompute the Refine Search panel before settling on the current solution. I've tried recomputing the height when we receive new results from API call, but it did not work because the height of the refine search panel depends on the height of the results, and the new results aren't displayed yet when they are received. I've tried using the component lifecycle hook ngAfterViewChecked in the Search Results page. This worked as it is called when the new results are displayed, but it is also called many times before then, which would be inefficient. I've tried debouncing it, but it is still called many times. After searching online for other options, I've found an approach that used the ngAfterViewChecked hook, but it would only recompute height if the current height of the search results is not the same as a previous recorded height. I have used that approach and verified that there are only two calls to recompute the height of the Refine Search panel when new search results are received.

uoa-noel commented 5 years ago

Feature is now finished. Findings from user study and cross browser tests will be addressed in another feature. Deployed successfully on prod today.