Uygulama içi arama UX'i anlık hissettirmek: debounce, önbellek, alaka

Uygulama içi aramanın yavaş veya işe yaramaz hissetmesine ne sebep olur

İ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.

En sık görülen kötü arama semptomları

Birkaç desen hep tekrar eder:

• Yazma gecikmesi: uygulama her tuş vuruşunda çok fazla iş yapar, imleç takılır.
• Titreme: liste temizlenip tekrar doldurulur, kullanıcı yerini kaybeder.
• Eski sonuçlar: yanıtlar sıra dışı dönünce UI daha eski bir sorgunun sonuçlarını gösterir.
• Yanlış eşleşmeler: en üst sonuç rastgele görünür, kullanıcı aramaya güvenmeyi bırakır.
• Çıkışsız durumlar: Sonuç yok durumunda yönlendirme yoktur, kullanıcı ne deneyeceğini bilmez.

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.

Sürüm 1 için basit hedefler ve sınırlar belirleyin

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.

Göreve uygun bir kapsam seçin

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.

Yeterince iyi alaka tanımlayın

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:

• Önce kesin eşleşme ("Alex Kim" "Alexandra"dan önce gelir)
• Sonra başlama-eşleşmesi ("pro" "Project" ile eşleşir)
• Ardından içerme ("jet" "Budget" ile eşleşir)
• Son kullanılan veya sabitlenmiş öğelere küçük bir artı puan verin
• Beraberlikleri alfabetik sırayla veya güncellemeye göre kırın

Bu temel, sürprizleri azaltır ve rastgelelik hissini azaltır.

Sınırları baştan belirleyin (ve UI'da yansıtın)

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.

Çevrimdışı ve kötü bağlantılar için plan yapın

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.

Gecikme (debounce) ve istek kontrolü, gecikme olmadan

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:

• Yeni sorgu başladığında devam eden istekleri iptal edin.
• İstek kimliği takip edin ve yalnızca en son isteğin sonuçlarını renderlayın.
• Son sorgu metnini saklayın ve eşleşmeyen yanıtları yoksayı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.

Güvenli hızlandıran önbellek temelleri

Ö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.

Basit, açıklanabilir kurallarla alaka temelleri

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.

Basit bir puanlama tarifi

Eşleşme önceliği ile başlayın:

• Kesin eşleşme (alan tümüyle sorguya eşleşir)
• Önek eşleşme (alan sorgu ile başlar)
• İçerme eşleşme (sorgu herhangi bir yerde görünür)
• Token eşleşme (sorgudaki herhangi bir kelime alandaki herhangi bir kelimeyle eşleşir)

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.

Yerel vs sunucu araması: pratik bir ayrım

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:

• Zaten sahip olduklarınızdan önce yerel eşleşmeleri gösterin.
• Daha geniş kapsam için arka planda bir sunucu isteği başlatın.
• Yanıt geldiğinde sonuçları birleştirin (ID ile dedupe edin).
• Sonuç kapsayıcı yüksekliğini sabit tutun ki sayfa zıplamasın.
• Odak arama alanında kalsın.

Ö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.

Boş, yükleme ve sonuçsuz durumlar kullanıcıya yardımcı olmalı

Ç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.

Kutucuk boşken: bir başlangıç noktası verin

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.

Yüklenirken: bağlamı koruyun, titremeden kaçını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.

Sonuç yok: çıkışsız durumları bir sonraki adıma çevirin

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.

Adım adım: bir haftada anlık hissettiren arama inşa edin

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:

• Gün 1: Kapsamı kilitleyin. 3–5 aranabilir alan, 0–2 filtre ve bir sıralama kuralı seçin (ör. önce kesin eşleşme sonra önek).
• Gün 2: Yazmayı güvenli hale getirin. Debounce ekleyin (genellikle 150–250ms) ve eski istekleri iptal edin ki geç gelen yanıtlar daha yeni sonuçların üzerine yazmasın.
• Gün 3: Basit sıralama ve vurgulama ekleyin. Açıklanabilir kurallar kullanın (kesin eşleşme > başlama > içerme). Eşleşmeleri vurgulayın ki kullanıcı neden bir sonucun çıktığını görsün.
• Gün 4: Küçük bir önbellek ekleyin. Son sorguları ve sonuçları kısa süreli (ör. 30–120 saniye) saklayın ve kullanıcı geri silme yaptığında tekrar kullanın.
• Gün 5: UI durumlarını bitirin. Hafif bir yükleme durumu ve kurtarıcı eylem içeren bir sonuçsuz durum ekleyin.

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.

Aramayı sinir bozucu yapan yaygın hatalar

Ç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:

• İsim veya ID üzerinde kesin eşleşme önce
• Sonra önek eşleşme
• Ardından herhangi yerde kısmi eşleşme
• Hiçbiri yoksa bulanık eşleşme
• Beraberlikleri kırmada son kullanılan veya sık kullanılan öğeler devreye girebilir, ama kesin eşleşmeleri geçmemeli

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.

Hızlı kontrol listesi ve sonraki adımlar

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:

• Yazma asla takılmasın. Debounce işi inputun ardından yapın, inputu geciktirmeyin.
• Sonuçlar sırayla güncellensin. Eski isteklere izin vermeyin veya onları iptal edin ki eski sonuçlar görünmesin.
• Yüklenme açık ama nazik olsun. Mevcut listeyi görünür tutun ve küçük bir güncelleme ipucu gösterin.
• Sonuçsuz durum kullanıcıyı kurtarmaya yardımcı olsun. Filtreleri temizleme veya daha kısa sorgu denemesi gibi bir sonraki adımı teklif edin.
• Sıralama kuralları yazılı olsun ve tutarlı uygulansın.

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.

Sonraki adımlar

Küçük, ölçülebilir adımlarla ilerleyin:

• Küçük bir test planı ekleyin: 5 yaygın sorgu, 2 uç durum ve 1 sonuçsuz vaka.
• Sadece gerekli olanı loglayın: sorgu uzunluğu, ilk sonuca ulaşma süresi ve iptal oranı (mümkünse kişisel metinlerden kaçının).
• Haftada bir iyileştirme seçin: daha iyi sıralama, daha iyi boş durum veya daha iyi önbellekleme.
• Bugün eksik olanı açıklayabildiğinizde gerçek bir arama altyapısı ekleyin.

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.