13 ਜਨ 2026·8 ਮਿੰਟ
ਇਨ-ਐਪ ਖੋਜ UX ਜੋ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋਵੇ: ਡੀਬਾਊਂਸ, ਕੈਸ਼, ਪ੍ਰਸੰਗਿਕਤਾ
ਇਨ-ਐਪ ਖੋਜ UX ਨੂੰ ਡੀਬਾਊਂਸ, ਛੋਟੀ ਕੈਸ਼, ਸਧਾਰਨ ਪ੍ਰਸੰਗਿਕ ਨਿਯਮ ਅਤੇ ਮਦਦਗਾਰ no-results ਸਟੇਟ ਨਾਲ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਖਾਸ ਸਰਚ ਇੰਜਣ ਦੇ।
ਇਨ-ਐਪ ਖੋਜ ਨੂੰ ਆਹਿਸਤਾ ਜਾਂ ਬੇਕਾਰ ਕਿਉਂ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ
ਲੋਕ ਕਹਿੰਦੇ ਹਨ ਕਿ ਖੋਜ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਪਰ ਉਨ੍ਹਾਂ ਦਾ ਮਤਲਬ ਆਮ ਤੌਰ 'ਤੇ ਜੀਰੋ ਮਿਲੀ ਸੈਕਿੰਡ ਨਹੀਂ ਹੁੰਦਾ। ਮਤਲਬ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ ਜਲਦੀ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰਤੀਕਿਰਿਆ ਵੇਖ ਲੈਂ — ਪਰ्यਾਪਤ ਤੇਜ਼ ώστε ਉਹ ਸੋੱਚਣ ਤੋਂ ਬਚ ਜਾਣ ਕਿ ਐਪ ਨੂੰ ਉਹਨਾਂ ਦੀ ਟਾਈਪਿੰਗ ਮਿਲੀ ਕਿ ਨਹੀਂ। ਜੇਕਰ ਕੁਝ ਵੀ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ ਲਗਭਗ ਇੱਕ ਸਕਿੰਟ ਦੇ ਅੰਦਰ (ਨਤੀਜੇ ਅਪਡੇਟ ਹੋਣ, ਇਕ ਲੋਡਿੰਗ ਸੂਚਨ ਜਾਂ ਇੱਕ ਸਥਿਰ "searching" ਸਥਿਤੀ), ਤਾਂ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਆਤਮਾ-ਵਿਸ਼ਵਾਸੀ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਟਾਈਪਿੰਗ ਜਾਰੀ ਰੱਖਦੇ ਹਨ।
ਜਦੋਂ UI ਚੁੱਪ ਰਹਿੰਦੀ ਹੈ ਜਾਂ ਉਲਟ-ਸਿੱਧੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤਿਕਿਰਿਆ ਦਿੰਦੀ ਹੈ ਤਾਂ ਖੋਜ ਹੌਲੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਤੇਜ਼ ਬੈਕਐਂਡ ਵੀ ਮਦਦ ਨਹੀਂ ਕਰਦਾ ਜੇ ਇਨਪੁਟ ਲੈਗ ਕਰੇ, ਸੂਚੀ ਹਿਲੇ ਜਾਂ ਨਤੀਜੇ ਹਰ ਵਾਰ ਰੀਸੈਟ ਹੋ ਰਹੇ ਹੋਵਣ।
ਸਭ ਤੋਂ ਆਮ ਖਰਾਬ ਖੋਜ ਦੇ ਲੱਛਣ
ਕੁਝ ਨਮੂਨੇ ਬਾਰ-ਬਾਰ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
- ਟਾਈਪਿੰਗ ਲੈਗ: ਕੌਰਸਰ ਜ਼ਰਾ ਬਿਰਕ-ਬਿਰਕ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਐਪ ਹਰ ਕੀ-ਸਟ੍ਰੋਕ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੰਮ ਕਰਦਾ ਹੈ।
- ਫਲਿਕਰ: ਸੂਚੀ ਖਾਲੀ ਹੋ ਜਾਂਦੀ ਹੈ ਤੇ ਮੁੜ ਭਰਦੀ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਨਾਲ ਯੂਜ਼ਰ ਆਪਣੀ ਥਾਂ ਖੋ ਬੈਠਦਾ ਹੈ।
- ਪੁਰਾਣੇ ਨਤੀਜੇ: UI ਪੁਰਾਣੇ ਕਵੈਰੀ ਦੇ ਨਤੀਜੇ ਦਿਖਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਰਿਕਵੇਸਟਾਂ ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ ਵਾਪਸ ਆਉਂਦੀਆਂ ਹਨ।
- ਗਲਤ ਮੇਲ: ਸਿਰੇ ਦਾ ਨਤੀਜਾ ਅਣਗਣਤ ਲੱਗਦਾ ਹੈ, ਇਸ ਲਈ ਯੂਜ਼ਰ ਖੋਜ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਛੱਡ ਦਿੰਦੇ ਹਨ।
- ਡੈੱਡ ਏਂਡ: "ਕੋਈ ਨਤੀਜੇ" ਕੋਈ ਮਦਦ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਯੂਜ਼ਰ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਅਗਲਾ ਕੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਹੈ।
ਇਹ ਗੱਲ ਛੋਟੇ ਡੇਟਾਸੈਟਾਂ 'ਤੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸਿਰਫ਼ ਕੁਝ ਸੌ ਨਾਮਾਂ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਲੋਕ ਖੋਜ ਨੂੰ ਇੱਕ ਛੋਟੀ ਸ਼ਾਰਟਕਟ ਵਜੋਂ ਵਰਤਦੇ ਹਨ। ਜੇ ਇਹ ਗਲਤ ਜਾਂ ਅਣਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੋਵੇ ਤਾਂ ਉਹ ਸਕ੍ਰੋਲਿੰਗ, ਫਿਲਟਰਾਂ ਜਾਂ ਹਾਲ ਛੱਡ ਦੇਣਗੇ। ਛੋਟੇ ਡੇਟਾਸੈਟ ਆਮ ਤੌਰ 'ਤੇ ਮੋਬਾਈਲ ਜਾਂ ਘੱਟ-ਪਾਵਰ ਡਿਵਾਈਸਾਂ 'ਤੇ ਵੀ ਰਹਿੰਦੇ ਹਨ, ਜਿੱਥੇ ਹਰ ਕੀ-ਸਟ੍ਰੋਕ 'ਤੇ ਬੇਕਾਰ ਕੰਮ ਹੋਣਾ ਜ਼ਿਆਦਾ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ।
ਤੁਸੀਂ dedicated search engine ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਬਹੁਤ ਕੁਝ ਠੀਕ ਕਰ ਸਕਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਤੇਜ਼ੀ ਅਤੇ ਉਪਯੋਗੀਤਾ UX ਅਤੇ ਰਿਕਵੇਸਟ ਕੰਟਰੋਲ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਮਹਿੰਗੇ ਇੰਡੈਕਸਿੰਗ ਤੋਂ।
ਪਹਿਲਾਂ ਇੰਟਰਫੇਸ ਨੂੰ ਪੇਸ਼ਗੀ ਬਣਾਓ: ਇਨਪੁੱਟ ਦਰੁਸਤ ਰੱਖੋ, ਨਤੀਜੇ ਬਹੁਤ ਜਲਦੀ ਨਾ ਖਾਲੀ ਕਰੋ, ਅਤੇ ਜਦ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸ਼ਾਂਤ ਲੋਡਿੰਗ ਸਥਿਤੀ ਦਿਖਾਓ। ਫਿਰ ਫਾਲਤੂ ਕੰਮ ਘਟਾਓ—ਡੀਬਾਊਂਸ ਅਤੇ ਰੱਦ ਕਰਨਾ ਵਰਗੀਆਂ ਤਕਨੀਕਾਂ ਨਾਲ ਤਾਂ ਜੋ ਹਰ ਅੱਖਰ 'ਤੇ ਖੋਜ ਨਾ ਚੱਲੇ। ਛੋਟੀ ਕੈਸ਼ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਦੁਹਰਾਈਆਂ ਕਵੈਰੀਆਂ ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋਣ (ਜਿਵੇਂ ਬੈਕਸਪੇਸ ਕਰਨ 'ਤੇ)। ਆਖਿਰ ਵਿਚ ਸਧਾਰਨ ਰੈਂਕਿੰਗ ਨਿਯਮ ਰੱਖੋ (exact match ਪਹਿਲਾਂ ਆਵੇ, starts-with ਫਿਰ), ਤਾਂ ਜੋ ਸਿਖਰਲੇ ਨਤੀਜੇ ਮਾਮੂਲੀ ਲਾਜ਼ਮੀ ਬਣ ਜਾਣ।
Version 1 ਲਈ ਸਧਾਰਨ ਲਕੜੀਆਂ ਅਤੇ ਹੱਦਾਂ
ਜੇ ਤੁਹਾਡੀ ਖੋਜ ਹਰ ਚੀਜ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ ਤਾਂ ਗਤੀ ਬਾਰੇ ਸੁਧਾਰ ਮਦਦ ਨਹੀਂ ਕਰਨਗੇ। Version 1 ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਦਾਇਰਾ, ਗੁਣਵੱਤਾ ਦੀ ਪਾਬੰਦੀ ਅਤੇ ਹੱਦਾਂ ਸਪਸ਼ਟ ਹੋਣ।
ਉਹ ਦਾਇਰਾ ਚੁਣੋ ਜੋ ਕੰਮ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ
ਇਹ ਤੈਅ ਕਰੋ ਕਿ ਖੋਜ ਕਿੰਨੀ ਕਿਸਮ ਦੀ ਹੈ। ਕੀ ਇਹ ਇੱਕ ਤੁਰੰਤ ਪਿਕਰ ਹੈ ਇੱਕ ਮਾਲੂਮ ਆਈਟਮ ਲੱਭਣ ਲਈ, ਜਾਂ ਵੱਡੀ ਸਮੱਗਰੀ ਦੀ ਖੋਜ ਲਈ ਹੈ?
ਜ਼ਿਆਦਾਤਰ ਐਪਸ ਲਈ ਕੁਝ ਉਮੀਦਯੋਗ ਫੀਲਡਾਂ ਦੀ ਖੋਜ ਕਾਫ਼ੀ ਹੁੰਦੀ ਹੈ: ਸਿਰਲੇਖ, ਨਾਮ ਅਤੇ ਮੁੱਖ ਪਛਾਣ-ਚਿੰਹ। ਇਕ CRM ਵਿੱਚ ਇਹ ਸੰਪਰਕ ਦਾ ਨਾਮ, ਕੰਪਨੀ ਅਤੇ ਈਮੇਲ ਹੋ ਸਕਦੀ ਹੈ। ਨੋਟਾਂ 'ਤੇ ਪੂਰਾ-ਟੈਕਸਟ ਖੋਜ ਉਸ ਵੇਲੇ ਰੱਖੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿ ਲੋਕਾਂ ਨੂੰ ਇਹ ਵਾਸਤਵ ਵਿੱਚ ਚਾਹੀਦਾ ਹੈ।
ਕਾਫ਼ੀ-ਚੰਗੀ ਪ੍ਰਸੰਗਿਕਤਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ
ਪਰਫੈਕਟ ਰੈਂਕਿੰਗ ਦੀ ਲੋੜ ਨਹੀਂ ਜਿਤੇਕ ਤੁਹਾਨੂੰ ਜਾਰ੍ਹਾ ਲਾਉਣਾ ਹੋਵੇ। ਪਰ ਤੁਹਾਨੂੰ Ergebnisse ਐਸੇ ਰੱਖਣੇ ਚਾਹੀਦੇ ਹਨ ਜੋ ਜਿਆਦਾਤਰ ਲੋਕਾਂ ਨੂੰ ਨਿਆਂਸੰਗਤ ਲੱਗਣ।
ਉਹ ਨਿਯਮ ਵਰਤੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਵਿਆਖਿਆ ਕਰ ਸਕਦੇ ਹੋ:
- ਪਹਿਲਾਂ exact match ("Alex Kim" "Alexandra" ਤੋਂ ਪਹਿਲਾਂ)
- ਫਿਰ starts-with ("pro" "Project" ਨੂੰ ਮਿਲੇ)
- ਫਿਰ contains ("jet" "Budget" ਨੂੰ ਮਿਲੇ)
- ਹਾਲ ਹੀ ਵਰਤੇ ਜਾਂ ਪਿੰਨ ਕੀਤੇ ਆਈਟਮਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਬੂਸਟ
- ਟਾਈਜ਼ ਨੂੰ ਵਰਣਮਾਲਾ ਕ੍ਰਮ ਜਾਂ ਨਵੀਨਤਾ ਨਾਲ ਤੋੜੋ
ਇਹ ਬੇਸਲਾਈਨ ਅਚਾਨਕਤਾ ਦੂਰ ਕਰਦੀ ਹੈ ਅਤੇ ਬੇਰੈਕੇਟ randomness ਘਟਾਉਂਦੀ ਹੈ।
ਪਹਿਲਾਂ ਹੀ ਹੱਦਾਂ ਨਿਰਧਾਰਤ ਕਰੋ (ਅਤੇ UI 'ਚ ਦਿਖਾਓ)
ਹੱਦਾਂ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਸੁਰੱਖਿਆ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਐਜ-ਕੇਸਜ਼ ਨੂੰ ਨੂਕਸਾਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
ਜਿਵੇਂ ਕਿ ਮੈਕਸ ਨਤੀਜੇ ਦੀ ਗਿਣਤੀ (ਅਕਸਰ 20-50), ਮੈਕਸ ਕਵੈਰੀ ਲੰਬਾਈ (50-100 ਅੱਖਰ), ਅਤੇ ਖੋਜ ਤੋਂ ਪਹਿਲਾਂ ਘੱਟੋ-ਘੱਟ ਕਵੈਰੀ ਲੰਬਾਈ (ਅਕਸਰ 2) ਤੈਅ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਨਤੀਜਿਆਂ ਨੂੰ 25 ਤੱਕ ਸੀਮਿਤ ਕਰਦੇ ਹੋ ਤਾਂ UI 'ਤੇ ਦੱਸੋ (ਉਦਾਹਰਣ ਲਈ "Top 25 results") ਬਜਾਏ ਇਹ ਦਰਸਾਉਣ ਦੇ ਕਿ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਖੋਜੀ ਹੈ।
ਆਫਲਾਈਨ ਅਤੇ ਖਰਾਬ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਯੋਜਨਾ ਬਣਾਓ
ਜੇ ਐਪ ਰੇਲਗੱਡੀ, ਲਿਫਟ ਜਾਂ ਕਮਜ਼ੋਰ Wi-Fi 'ਤੇ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ ਤਾਂ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਕਿ ਕੀ ਚੱਲਦਾ ਰਹੇਗਾ। ਇਕ ਪ੍ਰਾਇਗਟਿਕ Version 1 ਚੋਣ ਇਹ ਹੋ ਸਕਦੀ ਹੈ: ਹਾਲੀਆ ਆਈਟਮ ਅਤੇ ਛੋਟੀ ਕੈਸ਼ ਕੀਤੀ ਲਿਸਟ ਆਫਲਾਈਨ ਖੋਜਯੋਗ ਹਨ, ਬਾਕੀ ਸਬ ਕੁਨੈਕਸ਼ਨ ਦੀ ਲੋੜ ਹੈ।
ਜਦੋਂ ਕੁਨੈਕਸ਼ਨ ਖਰਾਬ ਹੋਵੇ, ਸਕ੍ਰੀਨ ਖਾਲੀ ਨਾ ਕਰੋ। ਆਖਰੀ ਚੰਗੇ ਨਤੀਜੇ ਦਿਖਾਓ ਅਤੇ ਸਪਸ਼ਟ ਸੁਚਨਾ ਦਿਓ ਕਿ ਨਤੀਜੇ ਇੱਕ-ਦੋ ਹੋ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕ ਖਾਲੀ ਸਟੇਟ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਸ਼ਾਂਤ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਜੋ ਫੇਲਯਰ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।
ਡੀਬਾਊਂਸ ਅਤੇ ਰਿਕਵੇਸਟ ਕੰਟਰੋਲ ਬਿਨਾਂ ਲੈਗ ਦੇ
ਇਨ-ਐਪ ਖੋਜ UX ਨੂੰ ਹੌਲਾ ਮਹਿਸੂਸ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹਰ ਕੀ-ਸਟ੍ਰੋਕ 'ਤੇ ਨੈੱਟਵਰਕ ਰਿਕਵੇਸਟ ਭੇਜਣਾ ਹੈ। ਲੋਕ ਬਲੱਸਟਾਂ ਵਿੱਚ ਟਾਈਪ ਕਰਦੇ ਹਨ ਅਤੇ UI ਅੰਸ਼-ਨਤੀਜਿਆਂ ਵਿਚਕਾਰ ਫਲਿਕਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ। ਡੀਬਾਊਂਸ ਇਸਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ: ਉਹ ਆਖਰੀ ਕੀ-ਦਬਾਅ ਤੋਂ ਬਾਅਦ ਥੋੜ੍ਹਾ ਸਮਾਂ ਰੁਕਦਾ ਹੈ ਫਿਰ ਖੋਜ ਚਲਾਉਂਦਾ ਹੈ।
ਇਕ ਚੰਗੀ ਸ਼ੁਰੂਆਤੀ ਦੇਰੀ 150-300ms ਹੈ। ਛੋਟੀ ਦੇਰੀ ਵੀ ਬੇਕਾਰ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਜਨਮ ਦੇ ਸਕਦੀ ਹੈ, ਬਹੁਤ ਲੰਬੀ ਹੋਣ ਤੇ ਐਪ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਰਹੀ ਲੱਗਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੋਕਲ ਹੈ (ਮੇਮੋਰੀ ਵਿੱਚ), ਤਾਂ ਤੁਸੀਂ ਨੀਵਾਂ ਰੱਖ ਸਕਦੇ ਹੋ; ਜੇ ਹਰ ਕਵੈਰੀ ਸਰਵਰ ਨੂੰ ਲੱਗਦੀ ਹੈ ਤਾਂ 250-300ms ਨੇੜੇ ਰਹੋ।
ਡੀਬਾਊਂਸ ਘੱਟੋ-ਘੱਟ ਕਵੈਰੀ ਲੰਬਾਈ ਨਾਲ ਬਿਹਤਰ ਕੰਮ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਐਪ ਲਈ 2 ਅੱਖਰ ਕਾਫ਼ੀ ਹੁੰਦੇ ਹਨ ਤਾਂ ਕਿ "a" ਵਰਗੀਆਂ ਬੇਕਾਰ ਕਵੈਰੀਆਂ ਨਾ ਚੱਲਣ। ਜੇ ਯੂਜ਼ਰ ਛੋਟੇ ਕੋਡਾਂ ਨਾਲ ਖੋਜ ਕਰਦੇ ਹਨ, ਤਾਂ 1-2 ਅੱਖਰਾਂ ਦੀ ਆਗਿਆ ਦਿਓ ਪਰ ਸਿਰਫ਼ ਉਹਨਾਂ ਦੀ ਰੁਕਾਵਟ ਤੇ।
ਰਿਕਵੇਸਟ ਕੰਟਰੋਲ ਡੀਬਾਊਂਸ ਜਿੰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਉਤਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਧੀਮੇ ਜਵਾਬ ਕ੍ਰਮ ਤੋਂ ਬਾਹਰ ਆ ਸਕਦੇ ਹਨ ਅਤੇ ਨਵੇਂ ਨਤੀਜਿਆਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਯੂਜ਼ਰ "car" ਟਾਈਪ ਕਰਦਾ ਹੈ ਤੇ ਫਿਰ ਤੇਜ਼ੀ ਨਾਲ "d" ਜੋੜ ਕੇ "card" ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ "car" ਦਾ ਜਵਾਬ ਆਖਿਰ ਵਿੱਚ ਆ ਸਕਦਾ ਹੈ ਅਤੇ UI ਨੂੰ ਪਿੱਛੇ ਧੱਕ ਦੇਵੇ।
ਇਹਨਾਂ ਨਮੂਨਿਆਂ ਵਿਚੋਂ ਕੋਈ ਇੱਕ ਵਰਤੋ:
- ਨਵੇਂ ਕਵੈਰੀ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਰਾਹ-ਚੱਲ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਰੱਦ ਕਰੋ।
- ਇਕ ਰਿਕਵੇਸਟ ID ਟਰੈਕ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਤਾਜ਼ਾ ਰਿਕਵੇਸਟ ਤੋਂ ਨਤੀਜੇ ਰੈਂਡਰ ਕਰੋ।
- ਆਖਰੀ ਕਵੈਰੀ ਸਤਰ ਰੱਖੋ ਅਤੇ ਉਹਨਾਂ ਜਵਾਬਾਂ ਨੂੰ ਅਣਡਿੱਠਾ ਕਰੋ ਜੋ ਇਸ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।
ਇੰਤਜ਼ਾਰ ਦੌਰਾਨ ਤੁਰੰਤ ਫੀਡਬੈਕ ਦਿਓ ਤਾਂ ਕਿ ਐਪ ਨਿਰਪੱਖ ਮਹਿਸੂਸ ਨਾ ਹੋਵੇ। ਟਾਈਪਿੰਗ ਨੂੰ ਰੋਕੋ ਨਾ। ਨਤੀਜਿਆਂ ਖੇਤਰ ਵਿੱਚ ਇੱਕ ਛੋਟਾ inline spinner ਜਾਂ "Searching..." ਵਰਗੀ ਛੋਟੀ ਸੁਚਨਾ ਦਿਖਾਓ। ਜੇ ਤੁਸੀਂ ਪਿਛਲੇ ਨਤੀਜੇ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਥੋੜ੍ਹਾ ਲੇਬਲ (ਜਿਵੇਂ "Showing previous results") ਲਗਾਓ ਤਾਂ ਯੂਜ਼ਰ ਭੁੱਲ ਜਾਣ।
ਇਕ ਵਰਤਾਰਕ ਉਦਾਹਰਣ: ਇੱਕ CRM ਸੰਪਰਕ ਖੋਜ ਵਿੱਚ, ਲਿਸਟ ਦਿਖਾਈ ਰੱਖੋ, 200ms ਡੀਬਾਊਂਸ ਕਰੋ, 2 ਅੱਖਰਾਂ ਤੋਂ ਪਿੱਛੇ ਹੀ ਖੋਜ ਚਲਾਓ, ਅਤੇ ਯੂਜ਼ਰ ਜਦੋਂ ਲਿੱਖਣਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ ਤਾਂ ਪੁਰਾਣੀ ਰਿਕਵੇਸਟ ਕੈਂਸਲ ਕਰੋ। UI ਸ਼ਾਂਤ ਰਹਿੰਦੀ ਹੈ, ਨਤੀਜੇ ਫਲਿਕਰ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਯੂਜ਼ਰ ਕੰਟਰੋਲ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕੈਸ਼ਿੰਗ ਬੁਨਿਆਦੀ ਗੱਲਾਂ
ਕੈਸ਼ਿੰਗ ਖੋਜ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਣ ਦਾ ਸਭ ਤੋਂ ਸਧਾਰਨ ਤਰੀਕਾ ਹੈ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਖੋਜਾਂ ਦੁਹਰਾਈਆਂ ਦੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਲੋਕ ਟਾਈਪ ਕਰਦੇ ਹਨ, ਬੈਕਸਪੇਸ ਕਰਦੇ ਹਨ, ਇੱਕੋ ਕਵੈਰੀ ਦੁਹਰਾਉਂਦੇ ਹਨ, ਜਾਂ ਕੁਝ ਫਿਲਟਰਾਂ ਵਿਚ ਬਦਲਦੇ ਹਨ।
ਕੈਸ਼ ਉਸ ਕੁੰਜੀ ਨਾਲ ਰੱਖੋ ਜੋ ਯੂਜ਼ਰ ਨੇ ਅਸਲ ਵਿੱਚ ਮੰਗੀ ਸੀ। ਇਕ ਆਮ ਬਾਗ ਕਵੈਰੀ ਪਾਠ ਦੁਆਰਾ-ਕੇਵਲ ਕੈਸ਼ ਕਰਨਾ ਹੈ, ਫਿਰ ਫਿਲਟਰਾਂ ਬਦਲਣ 'ਤੇ ਗਲਤ ਨਤੀਜੇ ਦਿਖਾਉਣਾ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਕੈਸ਼ ਕੀ ਆਮ ਤੌਰ 'ਤੇ ਨਾਰਮਲਾਈਜ਼ਡ ਕਵੈਰੀ ਸਤਰ + ਸਰਗਰਮ ਫਿਲਟਰ + ਸੌਰਟ ਆਰਡਰ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ pagination ਕਰਦੇ ਹੋ ਤਾਂ ਪੇਜ਼ ਜਾਂ ਕੁਰਸਰ ਵੀ ਸ਼ਾਮਲ ਕਰੋ। ਜੇ ਪਰਮੀਸ਼ਨਾਂ ਯੂਜ਼ਰ-ਆਧਾਰਤ ਹਨ ਤਾਂ ਉਹ ਵੀ ਸ਼ਾਮਲ ਕਰੋ।
ਕੈਸ਼ ਛੋਟਾ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਲਈ ਰੱਖੋ। ਕੇਵਲ ਆਖਰੀ 20-50 ਖੋਜਾਂ ਸੰਭਾਲੋ ਅਤੇ ਐਂਟਰੀਆਂ 30-120 ਸਕਿੰਡਾਂ ਬਾਅਦ ਮੁੱਕ ਜਾਉਣ। ਇਹ ਬੈਕਸਪੇਸ ਜਾਂ ਦੁਹਰਾਈਆਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਪਰ ਬਹੁਤ ਲੰਬਾ ਨਹੀਂ ਕਿ UI ਬਹੁਤ ਸਮੇਂ ਲਈ ਗਲਤ ਮਹਿਸੂਸ ਕਰੇ।
ਤੁਸੀਂ ਕੈਸ਼ ਨੂੰ ਵਾਰਮ ਕਰ ਸਕਦੇ ਹੋ ਪਹਿਲਾਂ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨਾਲ: ਹਾਲੀਆ ਆਈਟਮ, ਆਖਰੀ ਖੋਲ੍ਹੀ ਪ੍ਰੋਜੈਕਟ, ਜਾਂ ਡਿਫੌਲਟ ਖਾਲੀ-ਕਵੈਰੀ ਨਤੀਜਾ (ਅਕਸਰ "all items" recency ਤੇ)। ਛੋਟੇ CRM ਵਿੱਚ, Customers ਦੀ ਪਹਿਲੀ ਸਕ੍ਰੀਨ ਕੈਸ਼ ਕਰਕੇ ਪਹਿਲੀ ਖੋਜ ਤੁਰੰਤ ਲੱਗਦੀ ਹੈ।
ਫੇਲਿਯਰਾਂ ਨੂੰ ਸਫ਼ਲਤਾਵਾਂ ਵਾਂਗ ਹੀ ਕੈਸ਼ ਨਾ ਕਰੋ। ਅਸਥਾਈ 500 ਜਾਂ timeout ਕੈਸ਼ ਨੂੰ ਜ਼ਹਿਰੀਲਾ ਨਾ ਬਣਾਓ। ਜੇ ਤੁਹਾਨੂੰ errors ਰੱਖਣੇ ਹਨ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਛੋਟੀ TTL ਨਾਲ ਵੱਖਰਾ ਰੱਖੋ।
ਅੰਤ ਵਿੱਚ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਕਦੋਂ ਕੈਸ਼ ਐਂটਰੀਆਂ ਅਮਲ-ਯੋਗ ਡੇਟਾ ਬਦਲਣ ਤੇ ਅਣਵੈਧ ਹੋ ਜਾਣਗੀਆਂ। ਘੱਟੋ-ਘੱਟ, ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਕੋਈ ਨਵੀਂ ਆਈਟਮ ਬਣਾਏ, ਸੋਧੇ ਜਾਂ ਮਿਟਾਏ ਤਾਂ ਸੰਬੰਧਤ ਕੈਸ਼ ਐਂਟਰੀਆਂ ਸਾਫ਼ ਕਰੋ; ਜਦੋਂ ਪਰਮੀਸ਼ਨ ਜਾਂ ਵਰਕਸਪੇਸ-ਸਵਿੱਚ ਹੋਵੇ ਤਾਂ ਵੀ ਸਾਫ਼ ਕਰੋ।
ਸਧਾਰਨ, ਵਿਆਖਿਆਯੋਗ ਨਿਯਮਾਂ ਨਾਲ ਪ੍ਰਸੰਗਿਕਤਾ
Add caching the right way
Add a small, safe cache keyed by query plus filters so backspacing feels immediate.
ਜੇ ਨਤੀਜੇ ਬੇਤਰਤੀਬੀ ਲੱਗਣ, ਤਾਂ ਲੋਕ ਖੋਜ 'ਤੇ ਭਰੋਸਾ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਕੁਝ ਆਸਾਨ ਨਿਯਮਾਂ ਨਾਲ ਇਕ ਮਜ਼ਬੂਤ ਪ੍ਰਸੰਗਿਕਤਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ dedicated search engine ਦੇ।
ਇੱਕ ਸਧਾਰਨ ਸਕੋਰਿੰਗ ਨुसਖਾ
ਮੈਚ ਪ੍ਰਾਇਰਟੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ:
- Exact match (ਪੂਰਾ ਫੀਲਡ ਕਵੈਰੀ ਨਾਲ ਮੇਲ)
- Prefix match (ਫੀਲਡ ਕਵੈਰੀ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ)
- Contains match (ਕਵੈਰੀ ਕਿਤੇ ਵੀ ਆਉਂਦੀ ਹੈ)
- Token match (ਕੋਈ ਸ਼ਬਦ ਕਵੈਰੀ ਵਿੱਚੋਂ ਕਿਸੇ ਸ਼ਬਦ ਨਾਲ ਮੇਲ ਖਾਂਦਾ)
ਫਿਰ ਮਹੱਤਵਪੂਰਨ ਫੀਲਡਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਬਹੁਤ ਬੂਸਟ ਦਿਓ। ਸਿਰਲੇਖ ਆਮ ਤੌਰ 'ਤੇ ਵੇਰਵੇ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਗੁਣਾ ਰੱਖਦੇ ਹਨ। IDs ਜਾਂ ਟੈਗ ਜਦੋਂ ਕੋਈ ਪੇਸਟ ਕਰਦਾ ਹੈ ਤਾਂ ਉਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ। ਵਜ਼ਨਾਂ ਨੂੰ ਛੋਟਾ ਅਤੇ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਬਾਰੇ ਸੋਚ ਸਕੋ।
ਇਸ ਦਰਜੇ 'ਤੇ, ਹਲਕੀ ਟਾਇਪੋ ਸੰਭਾਲਣਾ ਮੁੱਖ ਤੌਰ 'ਤੇ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ ਨਾਲ ਹੁੰਦਾ ਹੈ, ਭਾਰੀ ਫਜ਼ੀ ਮਿਲਾਵਟ ਨਹੀਂ। ਦੋਹਾਂ ਨੂੰ ਨਾਰਮਲ ਕਰੋ: ਕਵੈਰੀ ਅਤੇ ਟੈਕਸਟ ਜੋ ਤੁਸੀਂ ਖੋਜਦੇ ਹੋ—lowercase, trim, ਮੁਲਤਾਨੀ ਖਾਲੀ ਸਥਾਨਾਂ ਨੂੰ ਇੱਕ, ਅਤੇ ਇੱਕਚਾਲੇ ਲਫ਼ਜ਼ਾਂ ਤੋਂ ਆਕਸেন্ট ਹਟਾਉਣ। ਇਹ ਕਈ ਵਾਰ ਦੀਆਂ "ਕਿਉਂ ਨਹੀਂ ਮਿਲਿਆ" ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਦੂਰ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇਕ ਸਧਾਰਨ ਨੀਤੀ ਇਹ ਹੈ: ਹੈਸ਼ਟੈਗਾਂ ਨੂੰ ਟੋਕਨ ਦਾ ਹਿੱਸਾ ਰੱਖੋ, ਹਾਈਫਨ ਅਤੇ ਅੰਡਰਸਕੋਰ ਨੂੰ spaces ਵਾਂਗ ਟ੍ਰੀਟ ਕਰੋ, ਨੰਬਰ ਰੱਖੋ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪੰਕਚੁਏਸਨ ਹਟਾ ਦਿਓ (ਪਰ @ ਅਤੇ . ਨੂੰ ਰੱਖੋ ਜੇ ਤੁਸੀਂ ਈਮੇਲ ਜਾਂ ਯੂਜ਼ਰਨੇਮ ਖੋਜਦੇ ਹੋ)।
ਰੈਂਕਿੰਗ ਵਿਆਖਿਆਯੋਗ ਰੱਖੋ। ਇਕ ਆਸਾਨ ਤਰੀਕਾ ਹੈ ਕਿ ਹਰ ਨਤੀਜੇ ਲਈ ਲੱਘੂ ਡੀਬੱਗ ਕਾਰਨ ਲੌਗ ਕਰੋ: "prefix in title" beats "contains in description"।
ਲੋਕਲ বনਾਮ ਸਰਵਰ ਖੋਜ: ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਵੰਡ
ਤੇਜ਼ ਖੋਜ ਅਨੁਭਵ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਚੋਣ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: ਕੀ ਡੇਵਾਈਸ 'ਤੇ ਫਿਲਟਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਸਰਵਰ ਤੋਂ ਪੁੱਛਣਾ ਲਾਜ਼ਮੀ ਹੈ।
ਲੋਕਲ ਫਿਲਟਰਿੰਗ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਡੇਟਾ ਛੋਟਾ ਹੋਵੇ, ਪਹਿਲਾਂ ਹੀ ਸਕ੍ਰੀਨ 'ਤੇ ਹੋਵੇ, ਜਾਂ ਹਾਲ ਹੀ ਵਿੱਚ ਵਰਤੀ ਗਈ ਹੋਵੇ: ਆਖਰੀ 50 ਚੈਟ, ਹਾਲੀਆ ਪ੍ਰੋਜੈਕਟ, ਸੇਵ ਕੀਤੇ ਸੰਪਰਕ, ਜਾਂ ਉਹ ਆਈਟਮ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਲਿਆ ਸੀ। ਜੇ ਯੂਜ਼ਰ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਵੇਖਿਆ, ਉਹ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਖੋਜ ਤੁਰੰਤ ਉਸ ਨੂੰ ਮਿਲੇਗੀ।
ਸਰਵਰ ਖੋਜ ਵੱਡੇ ਡੇਟਾਸੈਟ, ਬਾਰ-ਬਾਰ ਬਦਲਣ ਵਾਲੇ ਡੇਟਾ, ਜਾਂ ਕੁਝ ਪ੍ਰਾਈਵੇਟ ਤਾਂ ਜੋ ਤੁਸੀਂ ਡਾਊਨਲੋਡ ਨਾ ਕਰਨਾ ਚਾਹੋ, ਲਈ ਹੈ। ਇਹ ਲੋੜੀਂਦਾ ਵੀ ਹੈ ਜਦੋਂ ਨਤੀਜੇ ਪਰਮੀਸ਼ਨਾਂ ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਣ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਪੈਟਰਨ ਜੋ ਸਥਿਰ ਰਹਿੰਦਾ:
- ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਹੈ ਉਸ ਵਿੱਚੋਂ ਲੋਕਲ ਮੇਲ ਦਿਖਾਓ।
- ਪਿੱਛੇ ਵਿਆਪਕ ਕਵਰੇਜ ਲਈ ਸਰਵਰ ਰਿਕਵੇਸਟ ਸ਼ੁਰੂ ਕਰੋ।
- ਜਦੋਂ ਜਵਾਬ ਆਵੇ ਤਾਂ ਨਤੀਜੇ ਮਿਲਾਓ (ID ਦੁਆਰਾ dedupe)।
- ਨਤੀਜੇ ਕੰਟੇਨਰ ਦੀ ਉਚਾਈ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਪੇਜ਼ ਨਾ ਹਲੇ।
- ਖੋਜ ਫੀਲਡ 'ਤੇ ਫੋਕਸ ਰੱਖੋ।
ਉਦਾਹਰਣ: ਇੱਕ CRM ਹੌਲੀ-ਹੌਲੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਹਾਲੀਆ ਵੇਖੇ ਗਏ ਗਾਹਕਾਂ ਨੂੰ ਤੁਰੰਤ ਫਿਲਟਰ ਕਰ ਸਕਦਾ ਹੈ ਜਦ ਯੂਜ਼ਰ "ann" ਟਾਈਪ ਕਰਦਾ ਹੈ, ਫਿਰ ਚੁਪਚਾਪ ਸਰਵਰ ਰਿਕਵੇਸਟ ਨਾਲ ਪੂਰੇ ਡੇਟਾਬੇਸ ਤੋਂ "Ann" ਲਈ ਨਤੀਜੇ ਲੈ ਆਉਂਦਾ ਹੈ।
ਲੇਆਊਟ ਸ਼ਿਫਟ ਤੋਂ ਬਚਣ ਲਈ ਨਤੀਜੇ ਲਈ ਜਗ੍ਹਾ ਰਿਜ਼ਰਵ ਕਰੋ ਅਤੇ ਕਤਾਰਾਂ ਨੂੰ ਥਾਂ 'ਤੇ ਅਪਡੇਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਲੋਕਲ ਤੋਂ ਸਰਵਰ ਨਤੀਜਿਆਂ 'ਤੇ ਬਦਲਦੇ ਹੋ ਤਾਂ ਇੱਕ ਸੁਕੂਨਦਿਹ "Updated results" ਸੁਝਾਅ ਕਾਫੀ ਹੁੰਦਾ ਹੈ। ਕੀਬੋਰਡ ਵਿਹਾਰ ਵੀ ਇਕਸਾਰ ਰਹੇ: ਐਰੋ ਕੀ ਲਿਸਟ 'ਚ ਘੂਮੇ, Enter ਚੁਣੇ, Escape ਸਾਫ਼ ਜਾਂ ਬੰਦ ਕਰੇ।
ਖਾਲੀ, ਲੋਡਿੰਗ, ਅਤੇ no-results ਸਥਿਤੀਆਂ ਜੋ ਯੂਜ਼ਰ ਵਰਤ ਸਕਣ
Design better search states
Generate empty, loading, and no-results states that help users recover without guesswork.
ਜ਼ਿਆਦਾਤਰ ਖੋਜ ਦੀ ਨਿਰਾਸ਼ਾ ਰੈਂਕਿੰਗ ਬਾਰੇ ਨਹੀਂ ਹੁੰਦੀ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਸਕ੍ਰੀਨ ਯੂਜ਼ਰ ਦੇ ਕਾਰਜਾਂ ਦਰਮਿਆਨ ਕੀ ਕਰਦੀ ਹੈ: ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ, ਨਤੀਜੇ ਅਪਡੇਟ ਹੋਣ ਦੌਰਾਨ, ਅਤੇ ਜਦ ਕੁਝ ਮਿਲਦਾ ਹੀ ਨਹੀਂ।
ਜਦੋਂ ਬਾਕਸ ਖਾਲੀ ਹੋਵੇ: ਲੋਕਾਂ ਨੂੰ ਸ਼ੁਰੂਆਤ ਦਿਓ
ਇਕ ਖਾਲੀ ਖੋਜ ਪੇਜ ਯੂਜ਼ਰ ਨੂੰ ਅਨੁਮਾਨ ਲਾਉਣ 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ। ਵਧੀਆ ਡਿਫੋਲਟ ਹਨ ਹਾਲੀਆ ਖੋਜਾਂ (ਤਾਕਿ ਉਹ ਕਾਮ ਦੁਹਰਾਉਣ) ਅਤੇ ਕੁਝ ਲੋਕਪ੍ਰਿਯ ਆਈਟਮ ਜਾਂ ਸ਼੍ਰੇਣੀਆਂ (ਤਾਕਿ ਉਹ ਟਾਈਪ ਕੀਤੇ ਬਿਨਾਂ ਬ੍ਰਾਜ਼ ਕਰ ਸਕਣ)। ਇਸਨੂੰ ਛੋਟਾ, ਸਕੈਨ ਕਰਨ ਯੋਗ ਅਤੇ ਇੱਕ-ਟੈਪ ਰੱਖੋ।
ਭਰਾਈ ਦੌਰਾਨ: ਸੰਦਰਭ ਰੱਖੋ, ਫਲਿਕਰ ਤੋਂ ਬਚੋ
ਲੋਕ ਫਲਿਕਰ ਨੂੰ ਹੌਲਾ ਸਮਾਂ ਸਮਝਦੇ ਹਨ। ਹਰ ਕੀਸਟ੍ਰੋਕ 'ਤੇ ਸੂਚੀ ਹਟਾਉਣਾ UI ਨੂੰ ਅਸਥਿਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ, ਚਾਹੇ ਬੈਕਐਂਡ ਤੇਜ਼ ਹੋਵੇ।
ਪਿਛਲੇ ਨਤੀਜੇ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖੋ ਅਤੇ ਇਨਪੁੱਟ ਦੇ ਨੇੜੇ ਇੱਕ ਛੋਟਾ ਲੋਡਿੰਗ ਇਸ਼ਾਰਾ ਦਿਖਾਓ (ਜਾਂ ਉਸਦੇ ਅੰਦਰ ਇਕ ਨਰਮ ਸਪੀਨਰ)। ਜੇ ਤੁਸੀਂ ਲੰਬੇ ਇੰਤਜ਼ਾਰ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਿਰਟੇ ਬਰਾਬਰ ਕੁਝ skeleton rows ਨੀਵਾਂ ਜੋੜੋ ਪਰ ਮੌਜੂਦਾ ਸੂਚੀ ਬਣਾਈ ਰੱਖੋ।
ਜੇ ਰਿਕਵੇਸਟ ਫੇਲ ਹੁੰਦੀ ਹੈ ਤਾਂ inline ਸੁਨੇਹਾ ਦਿਖਾਓ ਅਤੇ ਪੁਰਾਣੇ ਨਤੀਜੇ ਦਿਖਾਈ ਰੱਖਣ ਦਿਓ।
ਕੋਈ ਨਤੀਜੇ: dead ends ਨੂੰ ਅਗਲੇ ਕਦਮ ਬਣਾਓ
ਇੱਕ ਖਾਲੀ ਪੇਜ ਜੋ "No results" ਕਹਿੰਦਾ ਹੈ ਡੈੱਡ-ਐਂਡ ਹੈ। ਜੋ ਤੁਹਾਡਾ UI ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ ਅਗਲੇ ਕਦਮ ਸੁਝਾਓ। ਜੇ ਫਿਲਟਰ ਸਰਗਰਮ ਹਨ, ਤਾਂ ਇੱਕ-ਟੈਪ Clear filters ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੋ। ਜੇ ਤੁਸੀਂ multi-word queries ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ ਤਾਂ ਘੱਟ ਸ਼ਬਦਾਂ ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਸੁਝਾਅ ਦਿਓ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰਸਿੱਧ synonyms ਹਨ ਤਾਂ ਇਕ ਵਿਕਲਪ ਪੇਸ਼ ਕਰੋ।
ਇੱਕ fallback view ਵੀ ਦਿਓ ਤਾਂ ਯੂਜ਼ਰ ਜਾਰੀ ਰਹਿ ਸਕੇ (recent items, top items, ਜਾਂ ਸ਼੍ਰੇਣੀਆਂ), ਅਤੇ ਜੇ ਉਤਪਾਦ ਇਹ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਤਾਂ Create new ਐਕਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ।
ਠੋਸ ਉਦਾਹਰਣ: ਕੋਈ CRM ਵਿੱਚ "invoice" ਖੋਜ ਕਰਨ ਵਾਲੇ ਨੂੰ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ ਕਿਉਂਕਿ ਆਈਟਮਾਂ "billing" ਨਾਲ ਲੇਬਲ ਕੀਤੇ ਹਨ। ਇੱਕ ਮਦਦਗਾਰ ਸਥਿਤੀ "Try: billing" ਸੁਝਾ ਸਕਦੀ ਹੈ ਅਤੇ Billing ਸ਼੍ਰੇਣੀ ਦਿਖਾ ਸਕਦੀ ਹੈ।
no-results ਕਵੈਰੀਆਂ (ਫਿਲਟਰਾਂ ਸਮੇਤ) ਨੋਟ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ synonyms ਸ਼ਾਮਲ ਕਰ ਸਕੋ, ਲੇਬਲਾਂ ਨੂੰ ਸੁਧਾਰ ਸਕੋ, ਜਾਂ ਘੱਟ ਰਹਿ گئی ਸਮੱਗਰੀ ਬਣਾਉ ਸਕੋ।
ਕਦਮ-ਦर-কਦਮ: ਇਕ ਹਫਤੇ ਵਿੱਚ ਤੁਰੰਤ-ਮਹਿਸੂਸ ਹੋਣ ਵਾਲੀ ਖੋਜ ਬਣਾਓ
ਤੁਰੰਤ ਮਹਿਸੂਸ ਹੋਣ ਵਾਲੀ ਖੋਜ ਇੱਕ ਛੋਟੀ, ਸਪਸ਼ਟ Version 1 ਤੋਂ ਆਉਂਦੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਪਹਿਲੇ ਦਿਨ ਹਰ ਫੀਲਡ, ਹਰ ਫਿਲਟਰ ਅਤੇ ਪਰਫੈਕਟ ਰੈਂਕਿੰਗ ਦੇ ਸਮਰਥਨ ਨੂੰ ਸ਼ੁਰੂ ਕਰਕੇ ਫਸ ਜਾਂਦੀਆਂ ਹਨ।
ਇੱਕ ਕੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉਦਾਹਰਣ: ਇੱਕ ਛੋਟੇ CRM ਵਿੱਚ ਲੋਕ ਮੁੱਖ ਤੌਰ 'ਤੇ ਗਾਹਕਾਂ ਨੂੰ ਨਾਮ, ਈਮੇਲ ਅਤੇ ਕੰਪਨੀ ਨਾਲ ਖੋਜਦੇ ਹਨ, ਫਿਰ status (Active, Trial, Churned) ਨਾਲ ਸੰਕੁਚਿਤ ਕਰਦੇ ਹਨ। ਉਹ ਫੀਲਡ ਅਤੇ ਫਿਲਟਰ ਲਿਖੋ ਤਾਂ ਕਿ ਹਰ ਕੋਈ ਇੱਕੋ ਜਿਹਾ ਬਣਾਏ।
ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ ਇੱਕ-ਹਫਤੇ ਦੀ ਯੋਜਨਾ:
- Day 1: Scope ਲਾਕ ਕਰੋ। 3-5 searchable ਫੀਲਡ, 0-2 ਫਿਲਟਰ, ਅਤੇ ਇੱਕ ਸੌਰਟ ਨਿਯਮ ਚੁਣੋ (ਜਿਵੇਂ exact match ਪਹਿਲਾਂ, ਫਿਰ prefix)।
- Day 2: ਟਾਈਪਿੰਗ ਸੁਰੱਖਿਅਤ ਬਣਾਓ। ਡੀਬਾਊਂਸ (150-250ms) ਜੋੜੋ ਅਤੇ ਪੁਰਾਣੀਆਂ ਰਿਕਵੇਸਟਾਂ ਰੱਦ ਕਰੋ ਤਾਂ ਕਿ ਧੀਮੇ ਜਵਾਬ ਪਿੱਛੇ ਨਤੀਜਿਆਂ ਨੂੰ ਓਵਰਰਾਈਟ ਨਾ ਕਰਨ।
- Day 3: ਸਧਾਰਨ ਰੈਂਕਿੰਗ ਅਤੇ ਹਾਈਲਾਈਟਿੰਗ ਜੋੜੋ। ਵਿਆਖਿਆਯੋਗ ਨਿਯਮ ਵਰਤੋ (exact match > starts with > contains)। ਮਿਲਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਹਾਈਲਾਈਟ ਕਰੋ ਤਾਂ ਯੂਜ਼ਰ ਦੇਖ ਸਕਣ ਕਿ ਨਤੀਜਾ ਕਿਉਂ ਆਇਆ।
- Day 4: ਛੋਟੀ ਕੈਸ਼ ਜੋੜੋ। ਹਾਲੀਆ ਕਵੈਰੀਆਂ ਅਤੇ ਨਤੀਜੇ 30-120 ਸਕਿੰਡ ਲਈ ਰੱਖੋ ਅਤੇ ਜਦ ਯੂਜ਼ਰ backspace ਕਰੇ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤੋ।
- Day 5: UI ਸਥਿਤੀਆਂ ਪੂਰੀਆਂ ਕਰੋ। ਲਾਈਟਵੈੱਟ ਲੋਡਿੰਗ ਸਥਿਤੀ ਅਤੇ no-results ਸਥਿਤੀ ਜੋ ਅਗਲਾ ਕਦਮ ਪੇਸ਼ ਕਰੇ, ਜੋੜੋ।
ਇਨਵੈਲੀਡੇਸ਼ਨ ਸਧਾਰਨ ਰੱਖੋ। ਸਾਇਨ-ਆਊਟ, ਵਰਕਸਪੇਸ-ਸਵਿੱਚ ਅਤੇ underlying ਸੂਚੀ 'ਚ ਕੋਈ ਕਾਰਵਾਈ (create, delete, status change) ਹੋਣ 'ਤੇ ਕੈਸ਼ ਸਾਫ਼ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਬਦਲਾਵ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਤਾਂ ਛੋਟੀ TTL ਵਰਤੋ ਅਤੇ ਕੈਸ਼ ਨੂੰ speed hint ਸਮਝੋ, ਸਹੀ ਸਰੋਤ ਨਹੀਂ।
ਆਖਰੀ ਦਿਨ ਮਾਪੋ। time to first result, no-results rate, ਅਤੇ error rate ਟਰੈਕ ਕਰੋ। ਜੇ time to first result ਚੰਗਾ ਹੈ ਪਰ no-results ਜ਼ਿਆਦਾ ਹੈ ਤਾਂ ਤੁਹਾਡੇ ਫੀਲਡ, ਫਿਲਟਰ ਜਾਂ ਵਾਕ-ਰੂਪ (wording) ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ।
ਆਮ ਗਲਤੀਆਂ ਜੋ ਖੋਜ ਨਿਰਾਸ਼ ਕਰਦੀਆਂ ਹਨ
Plan a calm search UX
Write debounce, caching, and ranking rules as acceptance checks before any code is generated.
ਬਹੁਤ ਸਾਰੀਆਂ ਹੌਲੀ ਖੋਜ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਹਕੀਕਤ ਵਿੱਚ ਫੀਡਬੈਕ ਅਤੇ ਸ਼ੁੱਧਤਾ ਦੇ ਬਾਰੇ ਹੁੰਦੀਆਂ ਹਨ। ਲੋਕ ਇੱਕ ਸਕਿੰਟ ਤੱਕ ਉਡੀਕ ਕਰ ਸਕਦੇ ਹਨ ਜੇ UI ਜੀਵੰਤ ਮਹਿਸੂਸ ਹੋਵੇ ਅਤੇ ਨਤੀਜੇ ਮਾਇਕਸ ਦੇ ਯੋਗ ਹੋਣ। ਉਹ ਛੱਡਦੇ ਹਨ ਜਦੋਂ ਬਾਕਸ ਅਟਕਿਆ ਲੱਗੇ, ਨਤੀਜੇ ਇੱਥੇ-ਉੱਥੇ ਹਿਲਣ, ਜਾਂ ਐਪ ਇੰਨੇਗਲਤਾ ਦਿਖਾਏ ਕਿ ਯੂਜ਼ਰ ਨੇ ਕੁਝ ਗਲਤ ਕੀਤਾ।
ਇੱਕ ਆਮ ਫਸਾਉਣਾ ਡੀਬਾਊਂਸ ਨੂੰ ਬਹੁਤ ਉੱਚਾ ਰੱਖਣਾ ਹੈ। ਜੇ ਤੁਸੀਂ 500-800ms ਤੱਕ ਉਡੀਕ ਕਰਦੇ ਹੋ ਤਾਂ ਇਨਪੁੱਟ ਜਵਾਬਦੇਹ ਨਹੀਂ ਲੱਗੇਗਾ, ਖਾਸ ਕਰਕੇ ਛੋਟੀ ਕਵੈਰੀਆਂ ਲਈ। ਦੇਰੀ ਛੋਟੀ ਰੱਖੋ ਅਤੇ ਤੁਰੰਤ UI ਫੀਡਬੈਕ ਦਿਖਾਓ ਤਾਂ ਕਿ ਟਾਈਪਿੰਗ ਕਦੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਲੱਗੇ।
ਇਕ ਹੋਰ ਫ੍ਰੱਸਟ੍ਰੇਸ਼ਨ ਪੁਰਾਣੀਆਂ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਜਿੱਤ ਜਾਣਾ ਹੈ। ਜੇ ਯੂਜ਼ਰ "app" ਟਾਈਪ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਤੇਜ਼ੀ ਨਾਲ "l" ਜੋੜਦਾ ਹੈ, ਤਾਂ "app" ਦਾ ਜਵਾਬ ਆਖ਼ਰੀ ਆ ਕੇ "appl" ਨਤੀਜਿਆਂ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ। ਪੁਰਾਣੀਆਂ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਰੱਦ ਕਰੋ ਜਾਂ ਜਵਾਬ ਵਰਤੋਂ ਜੋ ਆਖਰੀ ਕਵੈਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋਣ।
ਕੈਸ਼ ਉਸ ਵੇਲੇ ਵਾਪਸੀ ਕਰ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕੁੰਜੀਆਂ ਬਹੁਤ vague ਹੋਣ। ਜੇ ਤੁਹਾਡੀ ਕੈਸ਼ ਕੀ ਸਿਰਫ਼ ਕਵੈਰੀ ਪਾਠ ਹੈ ਪਰ ਤੁਸੀਂ ਵੀ ਫਿਲਟਰਾਂ (status, date range, category) ਵਰਤਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਨਤੀਜੇ ਦਿਖਾਉਂਗੇ ਅਤੇ ਯੂਜ਼ਰ ਖੋਜ 'ਤੇ ਭਰੋਸਾ ਖੋ ਦੇਵੇਗਾ। ਕਵੈਰੀ + ਫਿਲਟਰ + ਸੌਰਟ ਨੂੰ ਇੱਕ ਪਛਾਣ ਸਮਝੋ।
ਰੈਂਕਿੰਗ ਦੀਆਂ ਗਲਤੀਆਂ ਬਹੁਤ ਨਾਜ਼ੁਕ ਪਰ ਦਰਦਨਾਕ ਹੁੰਦੀਆਂ ਹਨ। ਲੋਕ exact matches ਪਹਿਲਾਂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ। ਇਕ ਸਧਾਰਨ, ਸਥਿਰ ਨਿਯਮ-ਸੈੱਟ ਅਕਸਰ ਇੱਕ ਚਤੁਰ ਨੀਤੀ ਤੋਂ ਬੇਹਤਰ ਹੁੰਦੀ ਹੈ:
- ਨਾਮ ਜਾਂ ID 'ਤੇ exact match ਪਹਿਲਾਂ
- ਫਿਰ prefix match
- ਫਿਰ partial match ਕਿਤੇ ਵੀ
- ਫਜ਼ੀ match ਸਿਰਫ਼ ਜਦ ਕੁਝ ਹੋਰ ਨਹੀਂ ਮਿਲਦਾ
- ਹਾਲੀਆ ਜਾਂ ਵਾਰੰਤੇ ਆਈਟਮ ਟਾਈਜ਼ ਤੋੜ ਸਕਦੇ ਹਨ, ਪਰ exact match ਨੂੰ ਓਵਰਰਾਈਡ ਨਾ ਕਰਨ
No-results ਸਕ੍ਰੀਨਾਂ ਅਕਸਰ ਕੁਝ ਨਹੀਂ ਕਰਦੀਆਂ। ਜੋ ਕੁਝ ਖੋਜਿਆ ਗਿਆ ਉਹ ਦਿਖਾਓ, ਫਿਲਟਰ ਸਾਫ਼ ਕਰਨ ਦਾ ਵਿਕਲਪ ਦਿਓ, ਇੱਕ ਵੱਡੀ ਕਵੈਰੀ ਸੁਝਾਓ ਅਤੇ ਕੁਝ ਲੋਕਪ੍ਰਿਯ ਜਾਂ ਹਾਲੀਆ ਆਈਟਮ ਦਿਖਾਓ।
ਉਦਾਹਰਣ: ਇੱਕ ਫਾਉਂਡਰ ਗਾਹਕ ਖੋਜਦਾ ਹੈ "Ana", Active-only ਫਿਲਟਰ ਲੱਗਾ ਹੈ ਤੇ ਕੁਝ ਨਹੀਂ ਮਿਲਦਾ। ਇੱਕ ਮਦਦਗਾਰ ਖਾਲੀ ਸਟੇਟ ਕਹੇ "No active customers for 'Ana'" ਅਤੇ ਇੱਕ-ਟੈਪ Show all statuses ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰੇ।
ਤੇਜ਼ ਚੈੱਕਲਿਸਟ ਅਤੇ ਅਗਲੇ ਕਦਮ
Dedicated search engine ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਸ਼ਾਂਤ ਹਨ: ਟਾਈਪਿੰਗ ਸੌਰ-ਹੇਠ ਨਹੀਂ ਹੁੰਦੀ, ਨਤੀਜੇ ਛਪਦੇ ਸਮੇਂ ਨਹੀਂ ਕੁਦਦੇ ਅਤੇ UI ਹਮੇਸ਼ਾਂ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।
Version 1 ਲਈ ਇਕ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ:
- ਟਾਈਪਿੰਗ ਕਦੇ ਵੀ ਅਟਕੇ nahi। Debounce ਕੰਮ ਇਨਪੁੱਟ ਤੋਂ ਬਾਅਦ ਹੋਵੇ, ਨਾ ਕਿ ਇਨਪੁੱਟ ਨੂੰ ਰੋਕੇ।
- ਨਤੀਜੇ ਕ੍ਰਮ ਵਿੱਚ ਅਪਡੇਟ ਹੋਣ। ਪੁਰਾਣੀਆਂ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਰੱਦ ਜਾਂ ਅਣਡਿੱਠਾ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਕਦੇ ਵੀ stale ਨਤੀਜੇ ਨਾ ਦਿਖਾਓ।
- ਲੋਡਿੰਗ ਸਪਸ਼ਟ ਪਰ ਨਰਮ। ਮੌਜੂਦਾ ਸੂਚੀ ਦਿੱਖਾਈ ਰੱਖੋ ਅਤੇ ਇੱਕ ਛੋਟਾ updating hint ਦਿਖਾਓ।
- no-results ਲੋਕਾਂ ਨੂੰ ਬਹਾਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰੇ। ਇੱਕ ਅਗਲਾ ਕਦਮ ਜਿਵੇਂ ਫਿਲਟਰ ਸਾਫ਼ ਕਰੋ ਜਾਂ ਛੋਟੀ ਕਵੈਰੀ ਦੀ ਪੇਸ਼ਕਸ਼ ਦਿਓ।
- ਰੈਂਕਿੰਗ ਨਿਯਮ ਲਿਖੇ ਹੋਏ ਅਤੇ ਲਾਗੂ ਹੋ ਰਹੇ।
ਫਿਰ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੈਸ਼ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਇਸਨੂੰ ਛੋਟਾ ਰੱਖੋ (ਸਿਰਫ਼ ਹਾਲੀਆ ਕਵੈਰੀਆਂ), ਅੰਤਿਮ ਨਤੀਜਾ ਲਿਸਟ ਕੈਸ਼ ਕਰੋ, ਅਤੇ ਮੂਲ ਡੇਟਾ ਬਦਲਣ 'ਤੇ ਅਣਵੈਧ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਬਦਲਾਅ ਪਕੜ ਸਕਦੇ ਨਹੀਂ, ਤਾਂ ਕੈਸ਼ ਸਮਾਂ-ਸੀਮਾ ਘਟਾ ਦਿਓ।
ਅਗਲੇ ਕਦਮ
ਛੋਟੇ, ਮਾਪਯੋਗ ਕਦਮਾਂ 'ਚ ਅੱਗੇ ਵਧੋ:
- ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਪਲੈਨ ਸ਼ਾਮਲ ਕਰੋ: 5 ਆਮ ਕਵੈਰੀਆਂ, 2 ਐਜ-ਕੇਸ, ਅਤੇ 1 no-results ਕੇਸ।
- ਜੋ ਜ਼ਰੂਰੀ ਹੈ ਉਹੀ ਲੌਗ ਕਰੋ: ਕਵੈਰੀ ਦੀ ਲੰਬਾਈ, time to first results, ਅਤੇ cancel rate (ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਨਿੱਜੀ ਟੈਕਸਟ ਤੋਂ ਬਚੋ)।
- ਹਰ ਹਫਤੇ ਇਕ ਸੁਧਾਰ ਚੁਣੋ: ਬਿਹਤਰ ਰੈਂਕਿੰਗ, ਬਿਹਤਰ ਖਾਲੀ ਸਟੇਟ, ਜਾਂ ਬਿਹਤਰ ਕੈਸ਼ਿੰਗ।
- ਅਸਲ search backend ਸਿਰਫ਼ ਤਦ ਜੋੜੋ ਜਦ ਤੁਸੀਂ ਵਿਆਖਿਆ ਕਰ ਸਕੋ ਕਿ ਅੱਜ ਕਿਹੜੀ ਚੀਜ਼ ਘੱਟ ਹੈ।
ਜੇ ਤੁਸੀਂ Koder.ai (koder.ai) 'ਤੇ ਐਪ ਬਣਾ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ ਹੈ ਕਿ ਖੋਜ ਨੂੰ ਆਪਣੀ(prompt) ਅਤੇ acceptance checks ਵਿੱਚ ਪਹਿਲੀ-ਸ਼੍ਰੇਣੀ ਵਿਸ਼ੇ ਕਰਕੇ ਸੁ Treat ਕਰੋ: ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਸਟੇਟਾਂ ਦੀ ਟੈਸਟਿੰਗ ਕਰੋ, ਅਤੇ UI ਨੂੰ ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਸ਼ਾਂਤ ਰੱਖੋ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
How fast does in-app search need to feel to users?
1 ਸਕਿੰਟ ਦੇ ਅੰਦਰ ਨਜ਼ਰ ਆਉਣ ਵਾਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਲਕੜੀ ਰੱਖੋ। ਇਹ ਨਤੀਜੇ ਦਾ ਅਪਡੇਟ ਹੋਣਾ ਹੋ ਸਕਦਾ ਹੈ, ਇਕ ਸਥਿਰ “searching” ਇੰਡੀਕੇਟਰ, ਜਾਂ ਇੱਕ ਹੌਲੀ ਲੋਡਿੰਗ ਸੂਚਨਾ ਜਦੋਂ ਤੱਕ ਪਿਛਲੇ ਨਤੀਜੇ ਸਕ੍ਰੀਨ 'ਤੇ ਰਹਿੰਦੇ ਹਨ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਸ਼ੱਕ ਨਾ ਹੋਵੇ ਕਿ ਉਹਨਾਂ ਦੀ ਟਾਈਪਿੰਗ ਮਿਲੀ।
Why does search feel slow even when my API is fast?
ਅਕਸਰ ਮੁੱਦਾ ਬੈਕਐਂਡ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ। ਟਾਈਪਿੰਗ ਲੈਗ, ਨਤੀਜਿਆਂ ਦੀ ਫਲਿਕਰਿੰਗ, ਅਤੇ ਚੁੱਪ ਚਾਪ ਰੁਕਿਆ ਹੋਇਆ ਇੰਟਰਫੇਸ ਖੋਜ ਨੂੰ ਹੌਲੀ ਮਹਿਸੂਸ ਕਰਾਉਂਦੇ ਹਨ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਨਪੁੱਟ ਨੂੰ ਜਵਾਬਦੇਹ ਅਤੇ ਅਪਡੇਟਾਂ ਨੂੰ ਸ਼ਾਂਤ ਰੱਖੋ।
What debounce delay should I use for search?
150–300ms ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੋ। ਲੋਕਲ, ਮੈਮੋਰੀ-ਅਧਾਰਿਤ ਫਲਟਰਿੰਗ ਲਈ ਛੋਟਾ ਵੇਲਾ ਚੰਗਾ ਹੈ; ਸਰਵਰ ਕਾਲਾਂ ਲਈ 250–300ms ਨੇੜੇ ਰਹੋ। ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਉੱਚਾ ਰੱਖੋਗੇ ਤਾਂ ਯੂਜ਼ਰ ਨੂੰ ਐਪ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਰਿਹਾ ਲਗੇਗਾ।
Should I require a minimum query length before searching?
ਹਾਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਸ ਲਈ ਇਹ ਲੋੜੀ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ 2 ਅੱਖਰਾਂ ਦੀ ਘੱਟੋ-ਘੱਟ ਲੰਬਾਈ ਬੇਕਾਰ ਕਵੈਰੀਆਂ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ, ਪਰ ਜੇ ਯੂਜ਼ਰ ਛੋਟੇ ਕੋਡ (ਜਿਵੇਂ "HR" ਜਾਂ "ID") ਲੱਭਦੇ ਹਨ ਤਾਂ 1–2 ਅੱਖਰਾਂ ਦੀ ਆਗਿਆ ਦੇ ਸਕਦੇ ਹੋ ਅਤੇ ਥੋੜ੍ਹੀ ਦੈਰੀ ਤੇ ਨਿਰਭਰ ਕਰੋ।
How do I stop stale results when requests return out of order?
ਨਵੇਂ ਕ੍ਵੈਰੀ ਸ਼ੁਰੂ ਹੋਣ 'ਤੇ ਇਨ-ਫਲਾਈਟ ਰਿਕਵੇਸਟਾਂ ਨੂੰ ਕੈਂਸਲ ਕਰੋ, ਜਾਂ ਕੋਈ ਅਜਿਹਾ ਨੰਬਰ ਟਰੈਕ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਤੇਜ ترین ਰਿਕਵੇਸਟ ਦੀ ਨਤੀਜੇ ਦਰਸਾਓ। ਇਸ ਨਾਲ ਪੁਰਾਣੇ, ਧੀਮੇ ਜਵਾਬ ਨਵੇਂ ਨਤੀਜਿਆਂ ਨੂੰ ਓਵਰਰਾਈਟ ਨਹੀਂ ਕਰਦੇ।
What’s the best loading state for search without flicker?
ਪਿਛਲੇ ਨਤੀਜੇ ਸਕ੍ਰੀਨ 'ਤੇ ਰੱਖੋ ਅਤੇ ਨਤੀਜਿਆਂ ਜਾਂ ਇਨਪੁੱਟ ਦੇ ਨੇੜੇ ਇੱਕ ਛੋਟਾ, ਸਥਿਰ ਲੋਡਿੰਗ ਇੰਡੀਕੇਟਰ ਦਿਖਾਓ। ਹਰ ਕੀਸਟ੍ਰੋੱਕ 'ਤੇ ਸੂਚੀ ਹਟਾਉਣਾ ਫਲਿਕਰ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਬੈਤਰ ਹੋਵੇਗਾ ਕਿ ਪੁਰਾਣੀ ਸਮੱਗਰੀ ਨਵੇਂ ਤੱਕ ਰਹੇ।
How do I cache search results without showing outdated or incorrect matches?
ਕੈਸ਼ recent ਕਵੈਰੀਆਂ ਨੂੰ ਇੱਕ ਕੀ ਨਾਲ ਸੰਭਾਲੋ ਜੋ ਨਾਰਮਲਾਈਜ਼ ਕੀਤੇ ਕਿਆਰੀ ਨਾਲ-ਨਾਲ ਫਿਲਟਰ ਅਤੇ ਸੌਰਟ ਆਦੇ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ। ਛੋਟਾ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਲਈ ਰੱਖੋ, ਅਤੇ underlying ਡੇਟਾ ਬਦਲਣ 'ਤੇ ਉਸਨੂੰ ਸਾੱਫ਼ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਗਲਤ ਨਤੀਜੇ ਨਾ ਦੇਖਣ।
How can I improve relevance without adding a full search engine?
ਸਧਾਰਨ ਨਿਯਮ ਵਰਤੋ ਜੋ ਯੂਜ਼ਰ ਅਸਾਨੀ ਨਾਲ ਸਮਝ ਸਕਣ: ਪਹਿਲਾਂ exact matches, ਫਿਰ starts-with, ਫਿਰ contains; ਮਹੱਤਵਪੂਰਨ ਫੀਲਡਾਂ ਨੂੰ ਥੋੜ੍ਹਾ ਬੂਸਟ ਦਿਓ ਜਿਵੇਂ ਨਾਮ ਜਾਂ ID. ਨਿਯਮ ਸਧਾਰਨ ਤੇ ਵਿਆਖਿਆਯੋਗ ਰੱਖੋ ਤਾਂ ਉਪਰਲੇ ਨਤੀਜੇ ਅਣਉਮੀਦ ਨਹੀਂ ਲੱਗਦੇ।
What should I include in version 1 scope for search?
ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਫੀਲਡਾਂ ਜੋ ਅਕਸਰ ਵਰਤੀ ਜਾਂਦੀਆਂ ਹਨ — ਫਿਰ ਖੋਜ ਦਾ ਵਿਸਥਾਰ ਕਰੋ ਜਦੋਂ ਅਸਲ ਉਪਯੋਗ ਮੁਕੱਮਲ ਹੋਵੇ। ਇੱਕ ਪ੍ਰੈਕਟਿਕਲ Version 1 = 3–5 ਫੀਲਡ ਅਤੇ 0–2 ਫਿਲਟਰ; ਲੰਬੇ ਨੋਟਾਂ 'ਤੇ ਪੂਰਾ-ਟੈਕਸਟ ਬਾਅਦ ਵਿੱਚ।
What should a helpful “no results” state say or do?
ਖੋਜ ਕੀਤੀ ਗਈ ਟੈਕਸਟ ਦਿਖਾਓ, ਇੱਕ ਆਸਾਨ ਰਿਕਵਰੀ ਐਕਸ਼ਨ ਦਿਓ ਜਿਵੇਂ ਕਿ ਫਿਲਟਰ ਸਾਫ਼ ਕਰੋ, ਅਤੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਸੋਧੀ ਹੋਈ ਛੋਟੀ ਕਵੈਰੀ ਸੁਝਾਓ। ਇੱਕ fallback ਵਿਊ ਜਿਵੇਂ recent items ਵੀ ਦਿਖਾਓ ਤਾਂ ਕਿ ਯੂਜ਼ਰ dead end 'ਤੇ ਨਾ ਫਸੇ।