Shakesearch is a simple web app that allows a user to search for a text string across the complete works of Shakespeare.
However, the app is in a rough shape. The search is case sensitive, the results are difficult to read, and the search is limited to exact matches.
Improve the app! Think about the problem from the user's perspective and prioritize changes according to what I think is most useful.
I am at liberty to approach the improvements with a back-end, front-end, or full-stack focus.
🚀 Live app : https://tph-shakesearch.onrender.com/
Desktop view | Mobile view |
---|---|
![]() |
![]() |
🔥 🔥 🔥
- Designed and used an API as the contract between clients and the server implementation
- Enhanced the UI/UX. Applied responsive design with best practices for web and mobile
- Support for case-insensitive search
- Support highlighting the occurences of the search term within each displayed result
- Ability to load the app with a search term in the URL and automatically execute the search. E.g
https://tph-shakesearch.onrender.com/?q=Hamlet
will load the app and issue a search forHamlet
. Users can now create bookmarks of searches or send search URLs to friends - Validate search queries both on client and backend. How helpful is it to seach for two letter words?
- Support pagination (no UI yet) and prevent sending hundreds (potentially thousands) of results at once, when the user might likely only see/consume a few
- Prevent unecessary trips to backend by not issuing a search if the query is the same as what was last searched
- Enable CORS on server to enable API integrators (from other domains) search via API. E.g issuing
https://tph-shakesearch.onrender.com/search?q=Hamlet
in the browser or withcURL
will return the JSON response of matches - Lots of code refator and enhancements across frontend and backend. See how quality progressed over time and see code quality status badge at top of this repo
💪 💪 💪
- Support multi-word search
- Support search with mis-spelt words
- Add pagination UI so that users can navigate across all the results. Add
next
andprevious
links in response payload so that integrators/clients don't have to worry about construct them - Benchmark and address performance bottlenecks/current approach e.g around using dynamic RegEx to find matches within a huge body of text
- Support results
ordering
andsorting
by specified enums. E.g order the results by the frequency of the search term - Perform search as fewer times as possible. E.g cache results by the search term, for subsequent requests of same search term
- Allow users "bookmark" or favorite result items they care about
- Search with voice