Search managers have no easy way to preview the impact of single rules they are currently working on. SMUI only enables the deployment of whole rules.txt files that belong to a rules collection. This is disadvantageous, e.g.:
- Rule deployments might take too long, resulting in unacceptable wait times for the managers.
- Rule deployments in the middle of their evolution is risky, because they might impact the end user search experience in an unexpected way (when done on LIVE). Also, rule deployments by one search manager always deploy all rules maintained in the system incl. rules from other managers at the time of deployment.
Note: Rules and spellings will be treated the same in the context of this improvement proposal. Also rules.txt incl. spellings will be used for simplicity.
Deployments to optionally configured PRELIVE instances, might be as time consuming as LIVE deployments. Also, PRELIVE instances do often not come with synchronous data compared to their LIVE equivalent (product data especially).
Goal: Enable publishing single rules in a draft status - robust & fast!
The (querqy) search tech stack:
Assume the following setup:
A (1) search frontend processing the user (URL) query,
and a (2) search engine (like Solr or Elasticsearch, to respond to the query) with a querqy Rewriter-Chain that is connected to the SMUI rules.txt deployment process.
A typical search query might enter the system like this:
https://example.com/search?query=laptop
The corresponding querqy Rewriter-Chain might enhance the user query like this:
common --> hyphen --> replace --> wordbreak
common and replace, in this example, receive rules.txt input from SMUI via the described deployment process.hyphen and wordbreak work without SMUI input.- Also, the SMUI deployment process might add additional business logic like semantic checks of resulting rules.txt files, regression tests including searches being simulated, or other kinds of plausibility verification.
Single preview or draft rules should not be part of above’s productive Rewriter-Chain for the search end user. On the other hand, their impact shall be previewable in the LIVE context by the search managers who work on these rules.
Acceptance Criteria:
- Search managers instantly see the impact of rules, they are editing, in the LIVE context.
- The status of rules (draft vs. LIVE) is transparent to the search managers.
- Individual search managers might work on different rule drafts at the same time.
- Entitled search managers might trigger a deployment of rules.txt files at any time, making all finalized draft rules of all search managers accessible to the search end users.
- To prevent a search manager, A, from accidently publishing an unfinished rule draft of B, the draft status of rules need to be explicitly closed so that they will only then be considered by the deployment process of SMUI.
Side criteria: The final rules.txt deployment, having the final impact on the search end user experience, should still be testable like suggested above (plausibility/regression tests).
Note: There is also the possibility of two search managers concurrently working on the same rule draft.
Introducing drafts to the (querqy) search tech stack:
Challenge / search manager UX hypothesis: While using the preview, search managers want to experience the impact of all rules end users experience, but with the additional flavor of draft rules. This means more specifically:
- In general: All Rewriters applying to end users, also apply to preview searches for managers.
- Exception: All search manager specific draft rules apply additionally while the (maybe outdated rule from the perspective of the manager) end user rule is suppressed.
To ensure a clean separation of (single) draft rules vs. the whole set of productive rules.txt files, draft Rewriters are suggested, e.g.:
common_drafts --> common --> hyphen --> replace_drafts --> replace --> wordbreak
This way, integrity of rules.txt file deployments for the search end users can be ensured with every (also time consuming) process necessary, while it technically only needs to be ensured draft Rewriters never apply to requests from end users (vs. requests from search managers). This can also be test automation ensured in the (querqy) search tech stack.
Request flow for the search end user:
--> search frontend: https://example.com/search?query=laptop
--> The common Rewriter applies the following rule:
laptop =>
SYNONYM: notebook
Request flow for the search manager:
--> search frontend: https://example.com/search?query=laptop&smui.user=paul_bartusch
--> The common_draft Rewriter applies the following rule:
laptop =>
SYNONYM: notebook
@{
"smui.user" : "paul_bartusch"
}@
The Rewriter containing the draft rules can also be created dynamically.
The smui.user URL parameter can be part of the preview_link as introduced with v3.15.
Security note: Making draft rules accessible via the search frontend by adding a URL parameter incl. the clear text username of the search manager might be easily replicated by an outside party (and also easy to spoof). This is either be accepted or prevented by a more advanced security architecture (e.g. VPN access or other encryption/decryption techniques).
(?) Discussion:
- Do you see an alternative frontend / (querqy) search engine and Rewriter setup that also fulfills the requirements expressed in this improvement proposal? Some thoughts: The
smui.user querqy annotations can also be part of the main common and replace rules.txt input as second versions of the inputs (making dedicated draft Rewriters obsolete). But this way, still the whole rules.txt deployment process incl. time consuming processes eventually are part of draft deployments.
- Do you see a way to suppress the laptop rules in the
common Rewriter when a “laptop” search frontend query is triggered by the manager (instead of the end user)? The way it is suggested here, seems to impose the risk of overlapping rule application (draft vs. LIVE).
(!) Next: Concept evaluation of the search manager experience for (single) draft preview rules in SMUI.
)
)
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent