Two search functions that function differently, why?


2 Kommentare

  • alcantar sonp
    1. Search functions can differ based on their intended use and target audience.
    2. User interface and design may vary to cater to different preferences and ease of use.
    3. Backend algorithms and technologies employed can influence search speed and accuracy.
    4. Some search functions prioritize real-time updates, while others focus on comprehensive database searches.
    5. Integration capabilities with other systems and platforms may vary, affecting overall functionality.
    6. Accessibility features like voice search or image recognition can differentiate search functions.
    7. Security protocols and data handling practices may differ, influencing user trust and compliance.
    8. Customization options like menusprice such as filters and sorting mechanisms can vary widely.
    9. Geographic relevance and localization settings may impact search results and functionality.
    10. Support for advanced features like natural language processing or predictive search can vary.
    11. User experience metrics and feedback systems may influence continuous improvement efforts.
    12. Just as menusprice provides specific restaurant details, each search function aims to cater to specific user needs and preferences through tailored functionalities.


  • Siniom

    I understand and agree with most of your points. But I would then argue that there are plenty different solutions to most of them. 

    • Suggestions:
      •  If the search would not yield any results you could be directed to search the thread-database instead. 
      • Threads could be a seperate tab of the ordinary search bar. By separating it into a different tab you would hinder unnecessary indexing and searching on that database. 

    Having the UI consolidated into one search box would be more easy to use. Having the backend solve the possible other issues you are describing in your post, is another matter, and shouldn't be impossible to do. 

    1. Search functions can differ based on their intended use and target audience.

    • The intended uses differs for these to search functions, this is true. They are very different. One searches messages overall and the other searches for titles of threads. This will make each search function more efficient by seperating them. 

    2.  Cater to different preferences and ease of use

    •  Ease of use as a goal is reached when it doesn't take me 2 searches in different search boxes to find what I wanted to find. I'm pretty sure that most would agree that this is not easy to use. 


    3. Backend algorithms and technologies employed can influence search speed and accuracy.

    • Agreed. But optimizing and figuring out a way to use one search box, to avoid search both databases (thread-titles, messages) if not needed, doesn't feel like a impossible problem to solve. And to be quite frank, when searching in the “messages” search box…. there is a call to the database with thread titles as well as they are shown in the search result. 
    • In this example below (see image) I use the same search box for messages, but this time I search for ipad instead of the word “begad”. Now it shows, and the thread is shown. This means that the search function for messages also indexes threads. Just not searching them as effectively?
    • I would also argue that having people search more times = more stress on search algorithms / servers?. 

    All in all, I do understand that there might be a lot of reasons that I'm not aware of that might make this a more difficult thing to implement than I would imagine. But in my experience of several search functions throughout a lot of different apps, it is not impossible. 

    I have respect for Discords developers. They do a fantastic job. Discord is my absolute favourite piece of communication software. I'm just saying that it can be better, and this is one point where I think it can be!



Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.