Demo of the feature
Aim is to collect ideas today to then include this search bar in the product:
- How can we improve it and make it more useable?
- Learning algorithm to sort results?
- How should be placed?
- How would you use it?
Problems in navigation are only part of the issue. I want to know what I need to do. Examples: this article needs updating - do you want to edit it?, e.g. Pages app has slowed down by 10 secs - do you want to check the config?
It's not the answer you need, it's the question.
One step in that direction has been done - A/B testing (espen/sasha). Collecting the data is the first thing to do before analyzing it to detect problems.
At least you can get the data out of mgnl, compared to other cms.
Suggestion: Examples of search + action: I want to find pages using xyz component and export it to Excel (or XML)l. OR I want to change abc to 123 in every page.
Search is relatively easy using an external implementation. Some actions are quite generic and easy to do: export, find, ....
Go towards a smart assistant rather than just search? Configure and chain commands.
- Add a little more explanation to the search results, ie. not just "about", but "this is the about app where you can do this or that".
- Would be good to see previous searches.
- Autocomplete feature would also be nice (get that from the index)
- Limit the search to the subtree in JCR could be useful. (cedric: difficulty is language processing)
- Have a wizard to provide advanced search. This would serve users who do not know the syntax. Wizard to clarify ambiguous searches.
- Limit search to content people have the right to access.
- One problem might be resource usage. But, if you have thousands of results it could be beneficial for people only to get the results that are pertinent to them (content I can edit, content i can't edit).
- Query template that can be predefined: ' assets that were added by me recently' You can expand this to quite complex solutions.
- When you search in one context you are usually looking for something within that context: e.g. if i search from pages, I'm probably looking for pages or assets not docs + results ordered by most recently updated.
- System should learn from the user's behaviour.
- Progressive filtering of results. Search for "cedric" everywhere, then limit to pages, then once you find the result you want provide the actions possible: edit, export, etc. If i'm an author this makes sense, if I'm a dev i probably don't want to edit content.
Trade off between pertinence of results and speed of result delivery.
- Problems with connecting to a third party service: firewall, cost, etc.
- Need transparency about what is being used, what data is being sent and where is it sent/harvested?
- Search for a page - system proposes 'what do you want to know about this page' instead of opening it. E.g. what information is available for the page (who edited it last, when it was created/updated)
- Eg. on a db level can only query on a specific field/value. When designing the UI, take this into account (additional fields).
- URL should update for the search.ie with a URL fragment.
- So you send the search to someone else
- Pin a result in favourites (provided you generate a URL fragment, could also be tackled by a learning algorithm which would identify your favourites)
- If you provide unpublish page action in search, people will ask 'why can't i publish from here too? "
- Creating need Expect a lot of demand for further functionality on it - best to analyze business need for it. Careful how it is presented.
- if you have 20 million results, what would you display? Scalability
- Search for actions. E.g. Create a new article > open dialog for this.
- Search for media for this article based on data already filled in.
- Adapt search to context. BE able to choose a result and use it. Eg.g Search & Insert a dog pic in an article image field.
- be able to search for the value of a config property (JCR query)
- not sure speech recognition will be very useful for most real users (good for sales though!). Useful for accessibility.
- search suggestions of similar words or synonyms (e.g. search for dog and it suggests a list of synonyms or canine or jackal).
- Frequently used terms or frequently accessed results (based on user roles/groups)
- big prominent search bar creates expectations of sophisticated features. Put it to one side and smaller, less sophisticated UI to lower expectations, remove voice recognition.
- Expect on the left fine tune search, on the right actions available
- Suggestion is to add as a fourth icon
- if it's a central feature, position centrally
Q: How does search for "circle" work technically?
A: Images were tagged beforehand with a jcr property. Delegated to google via REST API. Looking for another solution not using delegation.
Q: Can we attach more data sources than JCR and doc?
Q: if you have massive amounts of data what happens? Scalability?
A: It might happen that not everything is tagged yet
Q: Limitations to where this bar searches? just content apps?
A: It searches everywhere. Default supplier is "apps". You could customize this to search only your apps
Q: If my app has a separate external data source, can it be searched?
A: Yes. Write your own supplier: synchronous or asynchronous (like for confluence)
Q: What is the order of results?
A: Order of the REST service but you can control this from your supplier.