Debounce, küçük önbellekler, basit sıralama kuralları ve yararlı sonuçsuz durumları kullanarak uygulama içi arama anlık hissedebilir; bunun için mutlaka ayrı bir arama motoruna gerek yoktur.
İnsanlar aramanın anlık hissetmesini isterler; ancak genellikle sıfır milisaniye kastetmezler. Kastettikleri, uygulamanın onları duyup duymadığı konusunda şüpheye düşürmeyecek kadar hızlı ve net bir yanıt almaktır. Görünür bir şey yaklaşık bir saniye içinde olursa (sonuçlar güncellenir, bir yükleme ipucu görünür veya sabit bir arama durumu görünürse), çoğu kullanıcı güvende hisseder ve yazmaya devam eder.
Arama, arayüz sizi sessizce beklemeye zorladığında veya gürültülü tepki verdiğinde yavaş hisseder. Hızlı bir sunucu, input gecikiyorsa, liste zıplıyorsa veya biri yazarken sonuçlar sürekli sıfırlanıyorsa yardımcı olmaz.
Birkaç desen hep tekrar eder:
Bu, küçük veri kümelerinde bile önemlidir. Yüzlerce öğe olsa bile insanlar aramayı bir kısayol olarak kullanır; eğer güvenilmez gelirse kaydırmaya, filtrelere geçer veya vazgeçerler. Küçük veri kümeleri genellikle mobil ve düşük güçlü cihazlarda bulunur; bu nedenle her tuş vuruşunda gereksiz işler daha belirgindir.
Adanmış bir arama motoru eklemeden önce birçok şeyi düzeltebilirsiniz. Hız ve kullanılabilirlik çoğunlukla UX ve istek kontrolünden gelir, karmaşık indekslemeden değil.
Önce arayüzü öngörülebilir yapın: inputu duyarlı tutun, sonuçları çok erken temizlemekten kaçının ve yalnızca gerektiğinde sakin bir yükleme durumu gösterin. Ardından debounce ve iptal ile gereksiz işleri azaltın, böylece her karakterde arama çalışmaz. Tekrarlanan sorgular anında geliyormuş hissi vermesi için küçük bir önbellek ekleyin (ör. kullanıcı geri silme yaptığında). Son olarak, basit sıralama kuralları kullanın (kesin eşleşme kısmi eşleşmeden üstündür, başında eşleşme içinde geçene üstün) böylece en üst sonuçlar mantıklı olur.
Arama her şeyi yapmaya çalışıyorsa hız düzeltmeleri işe yaramaz. Sürüm 1 en iyi şekilde kapsam, kalite barı ve sınırlar açık olduğunda çalışır.
Aramanın ne için olduğunu belirleyin. Bilinen bir öğeyi hızlıca bulmak için bir seçim aracı mı, yoksa çok içeriği keşfetmek için mi kullanılıyor?
Çoğu uygulama için birkaç beklenen alanı aramak yeterlidir: başlıklar, isimler ve ana tanımlayıcılar. Bir CRM için bu kişi adı, şirket ve e-posta olabilir. Notlar üzerinde tam metin arama, insanların gerçekten buna ihtiyaç duyduğunu görene kadar bekleyebilir.
Mükemmel sıralamaya ihtiyacınız yok ama adil hisseden sonuçlar gerekir.
Birisi neden bir sonuç çıktığını sorsa açıklayabileceğiniz kurallar kullanın:
Bu temel, sürprizleri azaltır ve rastgelelik hissini azaltır.
Sınırlar performansı korur ve uç durumların deneyimi bozmasını engeller.
En çok gösterilen sonuç sayısı (genellikle 20–50), maksimum sorgu uzunluğu (ör. 50–100 karakter) ve aramadan önce minimum sorgu uzunluğu (genellikle 2) gibi kararları erken alın. Eğer sonuçları 25 ile sınırlıyorsanız bunu belirtin (ör. "En iyi 25 sonuç") yerine her şeyi aradığınız izlenimini vermeyin.
Uygulama trenlerde, asansörde veya zayıf Wi‑Fi'de kullanılacaksa neyin çalışacağını tanımlayın. Pratik bir sürüm 1 seçimi: son öğeler ve küçük bir önbellek çevrimdışı aranabilir, geri kalanı bağlantı gerektirir.
Bağlantı zayıfken ekranı temizlemeyin. Son iyi sonuçları görünür tutun ve sonuçların güncel olmayabileceğini açıkça belirtin. Bu, başarısız gibi görünen boş bir durumdan daha sakin hissettirir.
Uygulama içi aramayı yavaş hissettirmenin en hızlı yolu her tuşta ağ isteği atmaktır. İnsanlar patlamalar halinde yazar ve UI kısmi sonuçlar arasında titremeye başlar. Debounce bunu, son tuş vuruşundan küçük bir süre bekleyip sonra aramayı tetikleyerek çözer.
Başlangıç için iyi bir gecikme 150–300ms'dir. Daha kısa süre yine istekleri spamlayabilir, daha uzun süre uygulamanın sizi görmezden geldiği hissi verir. Veriler çoğunlukla yerelse (hafızada), daha kısa bir gecikme kullanılabilir. Her sorgu sunucuya gidiyorsa 250–300ms civarında kalın.
Debounce en iyi minimum sorgu uzunluğu ile çalışır. Birçok uygulama için 2 karakter, "a" gibi gereksiz aramaları engeller. Kullanıcılar kısa kodlarla arama yapıyorsa (ör. "HR" veya "ID"), 1–2 karaktere izin verin ama yalnızca durakladıktan sonra arayın.
İstek kontrolü, debounce kadar önemlidir. Bunu yapmazsanız yavaş yanıtlar sıra dışı döner ve daha yeni sonuçların üzerine yazılır. Kullanıcı "car" yazdıktan sonra hızlıca "card" yazarsa, "car" yanıtı son gelirse UI geri atlayabilir.
Bu desenlerden birini kullanın:
Beklerken hemen geri bildirim verin ki uygulama sonuç gelmeden önce duyarlı hissetsin. Yazmayı engellemeyin. Sonuç alanında küçük bir inline spinner veya "Aranıyor..." gibi kısa bir ipucu gösterin. Önceki sonuçları ekranda tutuyorsanız onları hafifçe etiketleyin (ör. "Önceki sonuçlar gösteriliyor") ki kullanıcılar şaşırmasın.
Pratik örnek: bir CRM iletişim aramasında listeyi görünür tutun, debounce'ı 200ms yapın, sadece 2 karakterden sonra arayın ve kullanıcı yazmaya devam ettiğinde eski isteği iptal edin. UI sakin kalır, sonuçlar titremez ve kullanıcı kontrol hisseder.
Önbellekleme, aramayı anında hissettirmek için en basit yollardan biridir; çünkü birçok arama tekrarlanır. İnsanlar yazar, geri siler, aynı sorguyu tekrar dener veya birkaç filtre arasında geçiş yapar.
Kullanıcının gerçekten ne istediğine uyan bir anahtar kullanarak önbelleğe alın. Yaygın bir hata sadece metni anahtar yapmaktır; sonra filtreler değişince yanlış sonuçlar gösterilir.
Pratik bir önbellek anahtarı genellikle normalize edilmiş sorgu metnini artı aktif filtreler ve sıralama içerir. Sayfalama varsa sayfa veya imleci de ekleyin. İzinler kullanıcıya veya çalışma alanına göre farklıysa onu da dahil edin.
Önbelleği küçük ve kısa ömürlü tutun. Son 20–50 sorguyu saklayın ve girdileri 30–120 saniye içinde sona erdirin. Bu, geri‑ileri yazmaları kapsamak için yeterlidir ancak düzenlemeler UI'nın uzun süre yanlış hissetmesini engeller.
Önbelleği ısıtarak da hız hissi verebilirsiniz: kullanıcı az önce gördüğünü doldurarak (son öğeler, son açılan proje veya boş sorgu sonucu). Küçük bir CRM'de Müşteriler'in ilk sayfasını önbelleğe almak ilk arama etkileşimini hemen hissettirir.
Hataları başarılarla aynı şekilde önbelleğe almayın. Geçici 500 veya zaman aşımı önbelleği zehirlememeli. Hataları saklıyorsanız ayrı ve çok daha kısa TTL ile saklayın.
Son olarak, veri değiştiğinde önbellek girdilerinin nasıl geçersiz kılınacağını kararlaştırın. En azından ilgili önbellek girdilerini kullanıcı yeni bir öğe oluşturduğunda, düzenlediğinde veya sildiğinde, izinler değiştiğinde veya kullanıcı çalışma alanı/hesap değiştirdiğinde temizleyin.
Sonuçlar rastgele görünürse insanlar aramaya güvenmeyi bırakır. Bir arama motoru olmadan bile birkaç açıklanabilir kural ile sağlam alaka elde edebilirsiniz.
Eşleşme önceliği ile başlayın:
Ardından önemli alanlara küçük yükseltmeler verin. Başlıklar genellikle açıklamalardan daha önemlidir. ID'ler veya etiketler birisi onları yapıştırdığında en çok önem taşıyabilir. Ağırlıkları küçük ve tutarlı tutun ki bunları mantıklı şekilde değerlendirebilesiniz.
Bu aşamada hafif yazım hatası işleme çoğunlukla normalizasyonla ilgilidir, ağır bulanık eşlemeden değil. Hem sorguyu hem de aranan metni normalize edin: küçük harfe çevirin, baş/son boşlukları kırpın, birden fazla boşluğu birleştirin ve kitlenizde aksanlar kullanılıyorsa aksanları kaldırın. Bu tek başına birçok "neden bulmadı" şikayetini çözer.
Sembollere ve sayılara nasıl davranacağınızı erken belirleyin; çünkü beklentileri değiştirirler. Basit bir politika: hashtagleri tokenın parçası olarak tutun, tire ve alt çizgileri boşluk gibi ele alın, sayıları tutun ve çoğu noktalama işaretini çıkarın (ama e‑posta veya kullanıcı adları arıyorsanız @ ve .'ı koruyun).
Sıralamayı açıklanabilir kılın. Her sonuç için kısa bir debug sebebi tutmak kolay bir hiledir: "başlıkta önek" "açıklamada içerme" gibi.
Hızlı bir arama deneyimi genellikle bir seçimdir: cihazda ne filtrelenebilir, ne sunucudan istenmelidir.
Yerel filtreleme, veriler küçük, zaten ekranda veya yakın zamanda kullanılmışsa en iyi sonucu verir: son 50 sohbet, son projeler, kaydedilmiş kişiler veya liste görünümü için zaten çektiğiniz öğeler. Kullanıcı az önce gördüyse aramanın onu anında bulmasını bekler.
Sunucu araması büyük veri kümeleri, sık değişen veri veya indirmek istemediğiniz özel veriler için gereklidir. Ayrıca sonuçların izinlere ve paylaşılan çalışma alanlarına bağlı olduğu durumlarda da gereklidir.
Sabit kalan pratik bir desen:
Örnek: bir CRM, biri "ann" yazarken anında son görüntülenen müşterileri yerelde filtreleyip, arka planda veri tabanında "Ann" için tam sunucu sonuçlarını yükleyebilir.
Yerel ile sunucu sonuçları arasında geçiş yaparken yerleşim değişikliklerini önlemek için sonuçlara yer ayırın ve satırları yerinde güncelleyin. Yerelden sunucuya geçişte hafif bir "Sonuçlar güncellendi" ipucu genellikle yeterlidir. Klavye davranışı da tutarlı kalmalı: ok tuşları listede gezinir, Enter seçer, Escape temizler veya kapatır.
Çoğu arama hayal kırıklığı sıralamadan değil, kullanıcının eylemler arasında ekranın ne yaptığıyla ilgilidir: yazmadan önce, sonuçlar güncellenirken ve hiçbir şey eşleşmediğinde.
Boş bir arama sayfası kullanıcıyı neyin işe yarayacağını tahmin etmeye zorlar. Daha iyi varsayılanlar: tekrar edilebilen görevler için son aramalar ve kısa bir popüler öğeler veya ortak kategoriler listesi (yazmadan gezinmek için). Küçük, taranabilir ve tek dokunuşluk yapın.
İnsanlar titremeyi yavaşlık olarak yorumlar. Her tuş vuruşunda listeyi temizlemek UI'yi kararsız hissettirir, hatta sunucu hızlı olsa bile.
Önceki sonuçları ekranda tutun ve input yakınında küçük bir yükleme ipucu gösterin (veya içinde hafif bir spinner). Daha uzun beklemeler bekleniyorsa mevcut listeyi koruyup altta birkaç iskelet satırı ekleyin.
Bir istek başarısız olursa satır içi bir mesaj gösterin ve eski sonuçları görünür tutun.
Sadece "Sonuç yok" diyen bir boş sayfa çıkışsızdır. Arayüzünüzün desteklediğine göre ne deneneceğini önerin. Filtreler aktifse bir dokunmayla Filtreleri Temizle sunun. Çok kelimeli sorguları destekliyorsanız daha az kelimeyle denemeyi önerin. Bilinen eş anlamlılarınız varsa alternatif bir terim önerin.
Ayrıca kullanıcıyı devam ettirecek bir yedek görünüm verin (son öğeler, en iyi öğeler veya kategoriler) ve ürününüz destekliyorsa Yeni oluştur eylemi ekleyin.
Somut senaryo: biri CRM'de "invoice" arar ve hiçbir şey bulamaz çünkü öğeler "billing" olarak etiketlenmiştir. Yardımcı bir durum "Şunu deneyin: billing" önerebilir ve Billing kategorisini gösterebilir.
Aktif filtrelerle birlikte sonuçsuz sorguları loglayın ki eşanlamlılar ekleyebilesiniz, etiketleri düzeltebilesiniz veya eksik içerik oluşturabilesiniz.
Anlık hissettiren arama küçük, net bir sürüm 1'den gelir. Çoğu ekip her alanı, her filtreyi ve mükemmel sıralamayı ilk günde desteklemeye çalışırken takılır.
Tek bir kullanım durumuyla başlayın. Örnek: küçük bir CRM'de insanlar genelde müşteri ararken isim, e‑posta ve şirket ile arar, sonra duruma göre (Active, Trial, Churned) daraltır. Bu alanları ve filtreleri yazın ki herkes aynı şeyi inşa etsin.
Pratik bir bir haftalık plan:
Geçersiz kılmayı basit tutun. Oturumu kapatma, çalışma alanı değişikliği ve altta yatan listeyi değiştiren herhangi bir eylem (oluştur, sil, durum değişikliği) olduğunda önbelleği temizleyin. Değişiklikleri güvenilir şekilde algılayamıyorsanız kısa bir TTL kullanın ve önbelleği hız ipucu olarak değerlendirin, gerçek kaynak olarak değil.
Son günü ölçüm için kullanın. İlk sonuca ulaşma süresini, sonuçsuz oranını ve hata oranını takip edin. Eğer ilk sonuca ulaşma süresi iyi ama sonuçsuz oranı yüksekse alanlar, filtreler veya etiketleme üzerinde çalışmanız gerekir.
Çoğu yavaş arama şikayeti aslında geri bildirim ve doğrulukla ilgilidir. Kullanıcılar UI canlıysa ve sonuçlar mantıklıysa bir saniye bekleyebilirler. Vazgeçerlerse kutu sıkışmış hissi veriyordur, sonuçlar zıplıyordur veya uygulama yanlış yaptıklarını ima ediyordur.
Yaygın bir tuzak debounce'ı çok yüksek ayarlamaktır. 500–800ms beklemek her şeyi yavaşlatır; özellikle "hr" veya "tax" gibi kısa sorgularda input duyarsız hissedilir. Gecikmeyi küçük tutun ve yazma sırasında uygulamanın asla yok sayılmadığını hissettirecek hemen geri bildirim gösterin.
Bir diğer frustrasyon ise eski isteklerin kazanmasına izin vermektir. Kullanıcı "app" yazıp sonra hızlıca "appl" yazdığında "app" yanıtı son gelirse "appl" sonuçları üzerine yazabilir. Yeni bir istek başlattığınızda önceki isteği iptal edin veya en son sorguyla eşleşmeyen yanıtları yoksayın.
Önbellekleme, anahtar çok belirsiz olduğunda ters tepebilir. Eğer önbellek anahtarınız sadece sorgu metniyse ama filtreler de varsa (durum, tarih aralığı, kategori), yanlış sonuçlar göstereceksiniz ve kullanıcı aramaya güvenmeyi bırakır. Sorgu + filtreler + sıralamayı bir kimlik olarak ele alın.
Sıralama hataları ince ama acı vericidir. İnsanlar önce kesin eşleşme bekler. Basit, tutarlı bir kural seti genellikle akıllıca kurallardan daha iyidir:
Sonuçsuz ekranlar genellikle hiçbir şey yapmaz. Ne arandığını gösterin, filtreleri temizlemeyi teklif edin, daha geniş bir sorgu önerin ve birkaç popüler veya son öğe gösterin.
Örnek: bir kurucu basit bir CRM'de müşterileri arıyor, "Ana" yazıyor, sadece Aktif filtresi açık ve hiçbir şey bulamıyor. Yardımcı bir boş durum "'Ana' için aktif müşteri yok" deyip bir dokunmayla "Tüm statüleri göster" aksiyonunu sunabilir.
Gerçek bir arama motoru eklemeden önce temel şeylerin sakin hissettirdiğinden emin olun: yazma yumuşak kalsın, sonuçlar zıplamasın ve UI her zaman kullanıcılara ne olduğunu söylesin.
Sürüm 1 için hızlı kontrol listesi:
Sonra önbelleğinizin yarardan çok zarar vermediğini doğrulayın. Küçük tutun (sadece son sorgular), nihai sonuç listesini önbelleğe alın ve alttaki veri değiştiğinde geçersiz kılın. Değişiklikleri güvenilir şekilde algılayamıyorsanız önbellek ömrünü kısaltın.
Küçük, ölçülebilir adımlarla ilerleyin:
Eğer bir uygulama Koder.ai (koder.ai) üzerinde inşa ediyorsanız, aramayı prompt ve kabul kriterlerinde birinci sınıf özellik olarak ele almak faydalıdır: kuralları tanımlayın, durumları test edin ve UI'nin ilk günden sakin davranmasını sağlayın.
Gözle görülür bir yanıtı yaklaşık bir saniye içinde sağlayacak şekilde hedefleyin. Bu, sonuçların güncellenmesi, sabit bir “arama yapılıyor” göstergesi veya önceki sonuçları ekranda tutarken görünen hafif bir yükleme ipucu olabilir; önemli olan kullanıcıların yazdıklarının alınıp alınmadığını sorgulamamalarını sağlamaktır.
Genellikle sorun sunucuda değil, arayüzdedir. Yazma gecikmesi, liste titremesi ve sessiz bekleme, sunucu hızlı olsa bile aramayı yavaş hissettirir; bu yüzden inputun duyarlı kalması ve güncellemelerin sakin olmasıyla başlamalısınız.
150–300ms ile başlamayı düşünün. Yerel (hafızadaki) filtreleme için daha kısa, her sorgunun sunucuya gitmesi durumunda ise 250–300ms civarında kalın; çok daha uzun gecikmeler uygulamanın sizi yok saydığını hissettirebilir.
Evet, çoğu uygulamada. 2 karakterlik bir minimum, gereksiz tüm sonuçları döndüren tek harfli sorguları engeller; ancak kullanıcılar kısa kodlarla arama yapıyorsa (ör. “HR” veya “ID”), yazmayı durdurduktan sonra 1–2 karaktere izin verebilirsiniz.
Yeni bir sorgu başladığında devam eden istekleri iptal edin veya yalnızca en son sorguya ait sonuçları işleyin. Bu, eski ve yavaş dönen yanıtların daha yeni sonuçların yerine geçmesini engeller.
Önceki sonuçları ekranda tutun ve sonuçların veya inputun yanında küçük, sabit bir yükleme göstergesi gösterin. Her tuş basışında listeyi temizlemek titremeye yol açar ve yeni içeriğe hazırlanırken kullanıcıya daha yavaş gelme hissi verir.
Normalleştirilmiş sorgu + filtreler + sıralama gibi bir anahtar kullanarak son sorguları önbelleğe alın; sadece metni anahtar yapmayın. Önbelleği küçük ve kısa ömürlü tutun ve alttaki veri değiştiğinde geçersiz kılın, aksi halde yanlış sonuçlar gösterirsiniz.
Kullanıcıların tahmin edebileceği basit kurallar kullanın: önce kesin eşleşmeler, sonra başlama-eşleşmeleri, sonra içerme; önemli alanlara (isim, ID) küçük yükseltmeler verin. Kurallar tutarlı ve açıklanabilir olursa üst sonuçlar rastgele görünmez.
Önce en çok kullanılan alanları arayın, sonra gerçek kullanım verisine göre genişletin. Pratik bir sürüm 1 için 3–5 alan ve 0–2 filtre yeterlidir; uzun notlar üzerinde tam metin araması, gerçekten gerekene kadar bekleyebilir.
Aranan terimi gösterin, kurtarma için filtreleri temizlemeyi teklif edin ve mümkünse daha geniş bir sorgu önerin. Kullanıcının devam etmesi için son öğeler veya popüler öğeler gibi bir yedek görünüm sunun.
