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

Search history new feature #23

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

enricofer
Copy link

I included a search history model to track queries per user.
Search history is loaded in completion listbox and the selected query is performed on click.
Djangoql app has to be migrated in order to register the new history model.
I hope you will find it useful.
searchhistory
Regards
Enrico

@stebunovd
Copy link
Member

Hi @enricofer,

thank you for your interest in the project and for the pull request! The idea of the Search History sounds interesting, and I wonder how it could play with #1 (Saved search queries). These concepts are a bit different, but at the end of the day, they solve the same problem - enable past queries re-use. Saved search queries feature seem to be slightly more powerful because users could give friendly names to the queries and also share them with others. However, it would require an explicit action from the user - click Save to save a query. Automated search history doesn't require any clicks and the interface implementation is simpler, but it won't allow users to give names to their queries or share queries with others.

Could it be possible to find an interface concept that would combine benefits from both features - History and Saved Queries? That would be great if we could find such concept. If not, then most likely we'll have to choose between History and Saved Queries, i.e. implement only one of these, but not both.

Does it make sense? What do you think?

@enricofer
Copy link
Author

enricofer commented Jul 3, 2018

Hi @stebunovd,
I found that history search and save query features are slightly different, even in implementation, and I fear that combining them together could dirty djangoql clearness and simplicity. The one ease past search retrieval and reuse, the other respond to the need of organizing and share frequent queries.
The history search feature is self explained and auto organized and require a minimum UI, on the contrary the save query feature need at last of some new UI improvements to manage query items (naming, deleting, sharing etc..)
The two features can't be mixed but can easily cohexist. I see that PR proposal to put a star to bookmark the actual query. IMHO the history list access point could be moved from completion drop down to a common "tree dots" icon (or whatever else) next to the bookmark star like a browser url bar.

Regarding my PR, I was thinking that history should be filtered by user (as it is) but furthermore by model otherwise if djangoql is used in a multimodel web app, the history list is likely to mix queries on different models that could bring issues and unclearness. Even the search bookmarks should be filtered by models. And this is why I would not overload the save query next with user sharing, because this can be easily achevied copying and pasting the query in the completion textbox making the user aware of what he is doing. I would prefer making "public" my personal search bookmarks, making them visible in all other user bookmarks list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants