creativecommons
[Feature] Add option for selected card to be displayed from localStorage
Problem
From the current system, the search engine cards can be selected either randomly, or when a card is clicked.
In the usecase of returning users who always prefer a particular search engine for example, this means they always have to click on that card everytime they open the platform (unless it is hopefully randomly selected).
Description
A third option could be set, where the last selected card should still be loaded when the user returns to the platform. That way, they can only enter the text and search unless they decide to choose another search engine. That means:
- First time users, should have a randomly selected engine
- Users can choose an engine
- Returning users will have the last selected engine by default and then they can choose another engine
Alternatives
An option would be to use localStorage to store the engine when clicked on the client side.
So that on page load we would check if any engine is available in localStorage: if yes, we move on to use it. If no, we randomly choose an engine.
Implementation
- [x] I would be interested in implementing this feature.
Hi @JennySimen, I'm an outreachy applicant, I'm interested to pick this up. Maybe we can work on this together let me know 😄
@JennySimen I really don't think that will be necessary as cc search is just a portal to alp these search engines... Meaning each time you enter a search query and chose a search engine it automatically redirects you to that search engine in a new tab
This way you just have to search using the cc search portal and a desired search engine of your choice all the time
@ImaJin14 using localStorage (or any other client side storage) does not prevent you from using the portal as you have mentioned above. Let me give you more context as it seems you didn’t understand the usecase.
I am a new user and the first time I searched on the platform google photos was selected. While I was on the platform, I refreshed the page and then searched again but Instead ccMixter was selected. I had not left the platform, I just refreshed the page (as I thought my network was disturbibg) but the search engine was changed.
So while I am on the platform and I refresh the page, I would like to continue using the same search engine withouth having to click. (taking to consideration that I enter the search text and press the enter key).
Just to mention that there are 2 ways to search:
- Enter search text and click the search engine
- Enter search text and press enter button (as most search platforms do)
NB: You do not always have to click the search engines to search
I just think for a better experience, the plaform should not always randomly select on page refresh.
@JennySimen I really don't think that will be necessary as cc search is just a portal to alp these search engines... Meaning each time you enter a search query and chose a search engine it automatically redirects you to that search engine in a new tab
This way you just have to search using the cc search portal and a desired search engine of your choice all the time
I'm inclined to agree that this is not necessarily a UX use-case we'd want to support. Users landing on the site would likely perform further searches on the landing engine once they arrived there. The Portal is just a jumping off point.
I think what might be the underlying issue here that's more likely is that there isn't clear UX on the steps taken for a user to utilize the portal itself. It can be be confusing what engine is selected when you search and you might wrongfully assume you are going where you have went before or that you are going to a combined search for all engines. Issue #93 starts to outline some of this a bit.
I think the better route would be finding a stable route to resolve #93, and then depending on the outcome there further considering whether a "saved engine favorite" in local storage is a valid UX improvement or whether it is side-stepping a confusing UX with adjacent solutions.
I am going to leave this open though, for us to circle back to as Blocked, because it might prove out as a valid Issue to address eventually.
