Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Add option for selected card to be displayed from localStorage #99

Open
1 task done
JennySimen opened this issue Oct 15, 2022 · 6 comments
Open
1 task done
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing feature 🟩 priority: low Low priority and doesn't need to be rushed 🚧 status: blocked Blocked & therefore, not ready for work

Comments

@JennySimen
Copy link
Contributor

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

  • I would be interested in implementing this feature.
@JennySimen JennySimen added ✨ goal: improvement Improvement to an existing feature 💻 aspect: code Concerns the software code in the repository 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work 🟩 priority: low Low priority and doesn't need to be rushed labels Oct 15, 2022
@dipanshuraz
Copy link

Hi @JennySimen, I'm an outreachy applicant, I'm interested to pick this up. Maybe we can work on this together let me know 😄

@ImaJin14
Copy link
Contributor

@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
Copy link
Contributor

Either ways let's see what @possumbilities has to say

@JennySimen
Copy link
Contributor Author

@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.

@ImaJin14
Copy link
Contributor

Okay understood ✅

@possumbilities
Copy link
Contributor

possumbilities commented Oct 17, 2022

@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.

@possumbilities possumbilities added 🚧 status: blocked Blocked & therefore, not ready for work and removed 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work labels Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing feature 🟩 priority: low Low priority and doesn't need to be rushed 🚧 status: blocked Blocked & therefore, not ready for work
Projects
Status: Backlog
Development

No branches or pull requests

4 participants