Yönetici arayüzlerindeki büyük açılır menüler: neden sizi yavaşlatır

Büyük açılır menülerle ilgili asıl sorun

Bir alana tıklıyorsunuz, açılır menü açılıyor ve her şey tereddüt ediyor. Sayfa bir an takılıyor, kaydırma yapışkan hissediyor ve yerinizi kaybediyorsunuz. Sadece bir saniye sürse bile form doldurma ritmini bozuyor.

Bu sorun en çok yönetici panolarında ve dahili araçlarda görülür çünkü gerçek, dağınık veri kümeleriyle ilgilenirler: müşteriler, siparişler, SKU'lar, destek talepleri, konumlar, çalışanlar. Genel uygulamalar bazen seçenekleri kısıtlayabilir. Yönetici araçları genellikle hepsine erişim gerektirir ve bu basit bir form kontrolünü mini bir veri tarayıcısına çevirir.

“Büyük” ne demek bağlama bağlıdır, ama sıkıntı insanların beklediğinden daha erken başlar. Yüzlerce seçenek hâlâ kullanılabilir; ama tarama yavaşlar ve yanlış tıklamalar yaygınlaşır. Binlere ulaştığınızda kullanıcılar gecikme hissetmeye ve daha fazla yanlış seçim yapmaya başlar. On binlerde kontrol artık açılır menü gibi davranmaz, performans hatası gibi davranır. Milyonlarda ise artık açılır menü olamaz.

Asıl sorun sadece hız değil. Doğruluk.

İnsanlar uzun listelerde kaydırırken yanlış “John Smith”i, yanlış “Springfield”ı veya yanlış ürün varyantını seçer ve sonra yanlış veriyi kaydederler. Maliyet daha sonra destek işi, yeniden düzenlemeler ve kimsenin güvenmediği raporlar olarak ortaya çıkar.

Hedef basit: formları hızlı ve öngörülebilir tutmak, hassasiyetten ödün vermeden. Bu genellikle “her şeyi yükleyip kaydır” yaklaşımını, insanların doğru kaydı hızla bulmasını sağlayan ve sistemin yalnızca gerekeni getirdiği desenlerle değiştirmek anlamına gelir.

Gecikmeler nereden geliyor (basitçe)

Büyük bir açılır menü görünüşte basittir, ama tarayıcı bunu gerçek iş olarak değerlendirir. Binlerce öğe yüklediğinizde, sayfadan binlerce option elemanı oluşturmasını, ölçmesini ve ekranda boyamasını istersiniz. Bu DOM ve render maliyeti hızla birikir, özellikle formda birden fazla böyle alan varsa.

Gecikme her şey görünmeden önce başlayabilir. Birçok yönetici UI’si, açılır menünün daha sonra anında açılabilmesi için referans listelerini (müşteriler, ürünler, konumlar) önceden yükler. Bu daha büyük API yanıtları, ağda daha fazla bekleme ve JSON ayrıştırmada daha fazla zaman demektir. İyi bir bağlantıda bile büyük yükler formun etkileşimli hale gelmesini geciktirir.

Sonra hafıza var. Tarayıcıda büyük listeleri tutmak RAM gerektirir. Düşük-özellikli dizüstü bilgisayarlarda, eski tarayıcılarda veya yoğun sekmelerde bu takılmalara, yazının yavaşlamasına veya açılır menü açıldığında geçici donmaya yol açabilir.

Kullanıcılar teknik nedenlerle ilgilenmez; duraklamaları fark ederler. Sık görülen “mikro-gecikmeler” akışı bozanlardır:

• Sayfa yüklenir, ama ilk tıklama bir süre hiçbir şey yapmaz.
• Açılır menü açılmakta gecikir veya kaydırma takılmalı hisseder.
• Diğer alanlara yazı girişi hafifçe gecikir.
• Kaydetme daha yavaş hissedilir çünkü UI zaten yük altında.

300–600 ms'lik bir takılma çok gibi gelmeyebilir, ama gün boyunca tekrarlandığında gerçek bir rahatsızlığa dönüşür.

UX problemleri: sadece performans değil

Büyük açılır menüler sadece yavaş hissettirmez. Basit bir seçimi küçük bir bulmacaya çevirir ve kullanıcılar bunu her form dolduruşunda öder.

İnsanlar 2.000 öğeyi etkili biçimde tarayamaz. Liste anında yüklense bile göz “tarama moduna” girer: kaydır, aşırı geç, geri kaydır, ikinci tahmin etme. Liste büyüdükçe kullanıcılar doğru seçimi onaylamak için daha fazla zaman harcar; işin tamamlanması yerine doğrulamaya vakit gider.

Yanlış seçimler kolaydır. Bir trackpad'deki küçük bir kaydırma vurgulanmış seçeneği hareket ettirebilir ve tıklama yanlış satıra iner. Hata genelde sonra ortaya çıkar (yanlış faturalanan müşteri, yanlış depo, yanlış kategori) ve ekstra iş ve karışık denetim izleri oluşturur.

Native select’in “arama” davranışı başka bir tuzaktır. Bazı platformlarda yazmak belirli harfle başlayan bir sonraki öğeye atlar; bazılarında farklı davranır veya keşfedilmez. Kullanıcılar uygulamanızı suçlar, oysa kontrol düz bir açılır menü gibi davranmaktadır.

Uzun listeler ayrıca veri kalitesi sorunlarını gizler. Yinelenen kayıtlar, belirsiz adlandırma, arşivlenmesi gereken eski kayıtlar ve yalnızca bir sonek ile ayrılan seçenekler gürültü içinde kaybolur.

Her “tek seçim” alanı için hızlı bir gerçek kontrol:

• Yeni bir ekip üyesi ilk denemede doğru seçer mi?
• Hatalı seçimlere yol açan yakın-aynı adlar var mı?
• Kontrol Mac, Windows ve mobilde aynı mı davranıyor?
• Seçim yanlışsa, bunu hemen fark edecek biri olur mu?

Açılır menünün doğru tercih olduğu durumlar

Her seçme alanının aramaya ihtiyacı yoktur. Büyük açılır menüler liste uzun olduğunda, sık değiştiğinde veya bağlama bağlı olduğunda sorun çıkar. Ancak küçük, sabit bir seçenek seti açılır menülerin tam da güçlü olduğu alandır.

Bir açılır menü hızlıca taranıp doğru değerin düşünsüzce tanınabildiği durumlarda güçlü bir tercihtir. Sipariş durumu, öncelik, kullanıcı rolü veya ülke gibi alanları düşünün. Liste zaman içinde yaklaşık aynı kaldığı ve genellikle bir ekrana sığdığı sürece basit kontrol kazanır.

Genellikle 50–100 öğenin altındaki listeler için açılır menü hem hız hem netlik sağlar. Kullanıcıların aynı ilk harfleri tekrar tekrar yazmaya başladığı noktaya dikkat edin—bu, listenin akılda kalmaz olduğunu ve taramanın aramadan daha yavaş hale geldiğini gösterir.

Sık değişen veya giriş yapan kişiye göre değişen herhangi bir liste kesin olarak durdurma sebebidir. Örneğin “Atanan kişiye” alanı genellikle ekip, bölge ve izinlere bağlıdır. Tüm kullanıcıları yükleyen bir açılır menü güncel olmayan, ağır ve kafa karıştırıcı olur.

AppMaster gibi bir araçta bunu inşa ediyorsanız iyi bir kural: küçük referans verileri (durumlar gibi) için açılır menüleri koruyun; müşteri, ürün, personel gibi işiniz büyüdükçe büyüyen her şey için arama tabanlı seçime geçin.

Typeahead arama: en basit ikame

Typeahead (çoğunlukla otomatik tamamlama olarak adlandırılır), yazdıkça arama yapan ve eşleşen kısa bir liste gösteren bir metin alanıdır. İnsanların devasa listeyi kaydırmasına izin vermek yerine klavyeyi kullanmalarını sağlayıp gerçek zamanlı güncellenen sonuçlardan seçim yapmalarını sağlarsınız.

Bu genellikle ilk düzeltme için en iyi seçenektir çünkü çizilen öğe sayısını, indirilen veriyi ve doğru öğeyi bulmak için gereken çabayı azaltır.

İyi bir typeahead birkaç temel kurala uyar. Aramaya başlamadan önce minimum karakter bekler (genelde 2–3) ki UI yalnızca “a” veya “e” gibi tek harflerde çırpınmasın. Hızlı sonuç döndürür ve listeyi kısa tutar (genelde en iyi 10–20 eşleşme). Her sonucun eşleşen kısmını vurgular ki tarama hızlı olsun. Boş durumlar konusunda da açık olmalı: doğrudan bir “Eşleşme yok” mesajı ve sonraki adım için yönlendirme göstermeli.

Klavye davranışı insanlar için sandıklarından daha önemlidir: Yukarı/Aşağı seçenekler arasında gezinmeli, Enter seçmeli, Esc kapamalıdır. Bu temel eksikse, typeahead açılır menüden daha kötü hissedebilir.

Küçük detaylar istikrarı sağlar. İnce bir yükleniyor durumu çift yazmayı ve kafa karışıklığını önler. Örneğin birisi “jo” yazıp duraklarsa sonuçlar hızlı görünmeli; “john sm” yazarken liste daralmalı, vurgulanan seçim kaybolup yeniden sıçramamalıdır.

Örnek: bir yönetici panelinde müşteri seçimi yaparken “mi” yazıldığında “Miller Hardware”, “Mina Patel” ve “Midtown Bikes” gösterilebilir; “mi” kısmı vurgulanır. AppMaster'da bu desen doğal uyum sağlar çünkü UI müşteri arayan bir endpoint çağırabilir ve tüm tabloyu değil sadece gereken birkaç eşleşmeyi döndürebilir.

Gerçekten eşleşme yoksa doğrudan ve yardımcı olun: “'johns' için müşteri bulunamadı. Daha kısa bir isim deneyin veya e-posta ile arayın.”

Typeahead'i adım adım nasıl uygulamalısınız

Typeahead, küçük bir arama aracı gibi ele alındığında en iyi şekilde çalışır; küçük bir açılır gibi değil. Hedef açık: birkaç iyi eşleşmeyi hızlıca getir, kullanıcı birini seçsin ve seçimi güvenli biçimde kaydet.

Pratik, hızlı bir kurulum

İnsanların gerçekten hatırladığı bir veya iki alanı seçerek başlayın. Müşteriler için genelde isim veya e-posta, ürünler için SKU veya dahili kod işe yarar. Bu seçim stil kadar önemli çünkü kullanıcıların ilk birkaç vuruşta sonuç alıp almayacaklarını belirler.

Ardından akışı uçtan uca uygulayın:

• Arama anahtarını seçin (örneğin müşteri adı artı e-posta) ve minimum karakter sayısını belirleyin (genelde 2–3).
• q ve limit (artı offset veya bir cursor) kabul eden bir API endpoint'i oluşturun.
• Sadece küçük bir set döndürün (genelde en çok 20), en iyi eşleşmeye göre sıralayın ve göstermek istediğiniz ID ile etiket alanlarını dahil edin.
• UI'da yükleniyor durumunu gösterin, boş sonuçları ele alın ve klavye gezinimini destekleyin.
• Seçilen kaydı gösterim metni olarak değil ID olarak kaydedin; etiketler yalnızca görüntüleme amaçlı olsun.

Küçük bir örnek: bir admin "maria@" yazarsa UI q=maria@ ile endpoint'i çağırır ve 20 eşleşme alır. Kullanıcı doğru olanı seçer ve form customer_id=12345 olarak kaydeder. Bu müşteri daha sonra adını veya e-postasını değiştirse bile kayıt doğru kalır.

AppMaster'da bunu inşa ediyorsanız aynı fikir geçerlidir: arama için backend endpoint kullanın (sayfalamalı), onu UI alanına bağlayın ve seçilen değeri model ID'sine bağlayın.

İki detay performansı korur: istekleri debounce edin (her tuşa sunucu çağrısı göndermemek için) ve mevcut oturum içinde yakın sorguları önbelleğe alın.

Sunucu tarafı filtreleme: hızlı kalmanın desenleri

Listeniz birkaç yüz öğeden büyük olduğunda tarayıcıda filtreleme dost canlısı olmaktan çıkar. Sayfa kullanmayacağınız verileri indirir, sonra küçük bir dilimi göstermek için ekstra iş yapar.

Sunucu tarafı filtreleme akışı tersine çevirir: küçük bir sorgu gönderin (örneğin "isim ali ile başlıyor"), sadece ilk sayfayı geri alın ve form tablo ne kadar büyük olursa olsun duyarlı kalsın.

Yanıt sürelerini sabit tutan desenler

Birkaç basit kural büyük fark yaratır:

• Sınırlı bir sayfa boyutu döndürün (örneğin 20–50 öğe) ve bir “next” token veya sayfa numarası ekleyin.
• Değişen veriler için cursor tabanlı sayalamayı tercih edin böylece kayıtlar eklenince boşluklar oluşmaz.
• UI'nin ihtiyaç duyduğu alanlarla yetinin (id + etiket), tam kayıtları göndermeyin.
• Kararlı sıralama kullanın (örneğin önce isim, sonra id) ki sonuçlar yer değiştirmesin.
• Geçerli kullanıcının izinlerini sorgunun içinde uygulayın, sonradan filtrelemeyin.

Önbellekleme: yardımcı ama kolayca yanlış yapılır

Önbellek popüler aramaları hızlandırabilir, ama sadece tekrar kullanım güvenliyse. “En iyi ülkeler” veya “yaygın ürün kategorileri” iyi adaylardır. Müşteri listeleri genellikle iyi aday değildir çünkü sonuçlar izinlere, hesap durumuna veya son değişikliklere bağlı olabilir.

Önbellek yapıyorsanız kısa ömürlü tutun ve kullanıcı rolü veya tenant'ı cache anahtarına dahil edin. Aksi halde bir kişi başka birinin verisini görebilir.

AppMaster'da bu genelde bir endpoint oluşturup, arama stringi ve cursor kabul etmesini ve döndürmeden önce backend mantığında erişim kurallarını zorlamasını gerektirir.

Referans veri desenleri: formları hızlı tutmak

Birçok “yavaş açılır menü” sorunu aslında “dağınık referans veri” sorunudur. Form alanınız başka bir tabloya (müşteriler, ürünler, konumlar) işaret ediyorsa, bunu bir referans gibi ele alın: ID'yi saklayın ve etiketi sadece görüntüleme amaçlı tutun. Bu kayıtları küçük tutar, geçmişi yeniden yazmayı engeller ve aramayı/filtrelemeyi kolaylaştırır.

Referans tabloları sıkıcı ve tutarlı tutun. Her satıra net, benzersiz bir anahtar verin (genelde sayısal ID) ve kullanıcıların tanıyacağı bir ad alanı ekleyin. Silmek yerine aktif/pasif bayrağı ekleyin ki eski kayıtlar hala çözsün ama yeni seçimlerde görünmesin. Bu typeahead ve sunucu tarafı filtreleme için de iyidir çünkü varsayılan olarak active=true ile güvenle filtreleyebilirsiniz.

Etiketin kaydını anlık mı tutacağınıza erken karar verin. Bir fatura satırı customer_id saklarken ayrıca customer_name_at_purchase saklayabilir, anlaşmazlık ve denetim için geçmiş okunabilir kalsın. Günlük yönetim kayıtları için genelde her zaman join yapıp güncel adı göstermek daha iyidir ki yazım hataları düzeltildiğinde her yerde görünür olsun. Basit bir kural işe yarar: geçmişin değişmediği durumda snapshot alın.

Hızı korumak için küçük kısayollar aramayı azaltıp tüm veri setini yüklemeyi engelleyebilir. Kullanıcı başına “son kullanılan” öğeleri başa koymak genelde herhangi bir UI değişikliğinden daha iyi sonuç verir. Favoriler, insanların aynı birkaç şeyi günlük olarak seçtiklerinde faydalıdır. Güvenli varsayılanlar (son kullanılan değer gibi) tüm etkileşimi ortadan kaldırabilir. Pasif öğeleri kullanıcı istemedikçe gizlemek listeyi temiz tutar.

Örnek: bir siparişte depo seçimi. Siparişe warehouse_id kaydedin. Depo adını gösterin ama denetim izi gerektiğinde gömülü tutmayın. AppMaster'da bu temiz şekilde eşleşir: Data Designer'da referansı modelleyin ve binlerce seçeneği UI'ye yüklemeden “son seçimler” kaydetmek için iş mantığını kullanın.

Yaygın form senaryoları ve daha iyi UI kontrolleri

Büyük açılır menüler, form alanının “basit” görünmesinden kaynaklanır: listeden bir değer seç. Gerçekte yönetici alanları farklı kontroller gerektirebilir ki hızlı ve kolay kalsın.

Bağımlı alanlar klasik bir örnek. Eğer Şehir, Ülkeye bağlıysa yalnızca ilk alanı sayfa yüklemesinde alın. Kullanıcı ülkeyi seçtiğinde o ülke için şehirleri getir. Eğer şehir listesi hâlâ büyükse, şehir alanını seçilen ülkeye göre filtreleyen bir typeahead yapın.

Çoklu seçim alanları (etiketler, roller, kategoriler) büyük listelerle hızla kırılır. Kullanıcının yazdıkça sonuç yükleyen ve seçilenleri chip'ler olarak gösteren arama-öncelikli çoklu-seçim, binlerce seçeneği yüklemeden üç tane seçmeyi sağlar.

Eksik bir seçenek varsa alandan “yeni oluştur” ihtiyacı sıkça doğar. Alanın yanına veya seçicide içine “Yeni ekle…” eylemi koyun. Yeni kaydı oluşturun ve otomatik seçin. Sunucuda doğrulayın (gerekli alanlar, benzersizlik) ve çakışmaları net ele alın.

Uzun referans listeleri (müşteriler, ürünler, tedarikçiler) için bir arama penceresi veya sunucu tarafı filtrelemeli typeahead kullanın. Sonuçlarda bağlam gösterin (örneğin müşteri adı + e-posta) ki doğru seçim kolay olsun.

Zayıf ağ ve çevrimdışı anlar büyük listeleri daha da kötüleştirir. Birkaç seçim dahası dahili uygulamaları kullanılabilir tutar: kullanıcı başına son 10 seçimi önbelleğe alın, net bir yükleniyor durumu gösterin, yeniden denemeyi kullanıcı girdisini temizlemeden destekleyin ve bakarken kullanıcıların diğer alanları doldurmaya devam etmesine izin verin.

AppMaster içinde formlar oluşturuyorsanız bu desenler temiz bir veri modeli (referans tablolar) ve filtrelenmiş arama için sunucu endpointleri ile iyi eşleşir; böylece veri büyüdükçe UI duyarlı kalır.

Daha da kötü hale getiren yaygın hatalar

Çoğu yavaş form tek bir devasa tablodan yavaş değildir. UI pahalı tercihi tekrar tekrar yaptırdığı için yavaşlar.

Klasik hata, tam listeyi “sadece bir kez” sayfa yüklemesinde yüklemektir. 2.000 öğeyle iyi hisseder. Bir yıl sonra 200.000 olur ve her form uzun bir bekleyişle, ekstra bellek kullanımıyla ve ağır bir payload ile açılır.

Arama hızlı olsa bile başarısız olabilir. Alan sadece görüntü adı ile arıyorsa kullanıcılar takılır. Gerçek insanlar ellerindekiyle arar: müşteri e-postası, dahili kod, telefon numarası veya hesap numarasının son 4 hanesi.

Bir avuç sorun kabul edilebilir bir kontrolü acıya çevirebilir:

• Debounce yok, UI her tuş vuruşunda istek gönderiyor.
• Devasa payload'lar (tam kayıtlar) yerine küçük eşleşme listeleri döndürülmüyor.
• Pasif veya silinmiş öğeler ele alınmıyor; kaydedilmiş formlar sonra boş gösteriyor.
• Form etiket metnini saklıyor, ID yerine; bu çoğaltmalara ve karışık raporlara yol açıyor.
• Sonuçlar yeterli bağlam göstermiyor (örneğin iki “John Smith” arasında ayırıcı yok).

Gerçek bir senaryo: bir ajan müşteri seçiyor. “Acme” iki kere var; biri pasif ve form etiket metnini sakladı. Şimdi fatura yanlış kayda işaret ediyor ve kimse bunu güvenilir şekilde düzeltemiyor.

AppMaster'da daha güvenli bir varsayılan, veri modelinizde referansları ID olarak tutmak ve arama endpoint'inizin küçük, filtrelenmiş eşleşme listeleri döndürmesi olacaktır.

Yayınlamadan önce hızlı kontrol listesi

Her “listeden seç” alanını hem performans hem UX riski olarak ele alın. Bu alanlar test verileriyle iyi hissedip gerçek kayıtlar geldiğinde çökme eğilimindedir.

• Liste yaklaşık 100 öğeyi geçebilecekse typeahead arama veya başka bir aranabilir seçime geçin.
• Arama yanıtlarını küçük tutun. Sorgu başına yaklaşık 20–50 sonuç döndürmeyi hedefleyin ve kullanıcıya daha fazla yazması gerektiğini net söyleyin.
• Etiketi değil kararlı değeri kaydedin. Kayıt ID'sini saklayın ve formu kabul etmeden önce sunucuda, izin kontrolleri dahil doğrulayın.
• Durumları kasıtlı yönetin: arama sırasında yükleniyor göstergesi, eşleşme yoksa yardımcı bir boş durum ve istek başarısız olursa net hatalar gösterin.
• Fare olmadan da hızlı olsun. Klavye gezinimini destekleyin ve kullanıcıların arama kutusuna isim, e-posta veya kod yapıştırmasına izin verin.

No-code bir araç olan AppMaster'da bu genelde küçük bir değişikliktir: bir giriş UI'si, bir arama endpoint'i ve backend iş mantığında sunucu tarafı doğrulama. Günlük yönetici işlerinde fark büyük olur, özellikle yoğun kullanılan formlarda.

Gerçekçi bir örnek: yönetici panelinde müşteri seçimi

Bir destek ekibi, gelen her ticket'ı doğru müşteriye atarken yönetici UI'si kullanır. Basitmiş gibi görünür; ta ki müşteri listesi 8.000 kayıt olana kadar.

“Önce” versiyon devasa bir açılır menü kullanır. Açılması biraz zaman alır, kaydırma takılır ve tarayıcı binlerce seçeneği hafızada tutmak zorundadır. Daha da kötüsü, insanlar yanlış “Acme”yi seçer çünkü yinelenenler, eski adlar ve “ACME Inc” vs “Acme, Inc.” gibi küçük farklar vardır. Sonuç: sürekli küçük zaman kayıpları ve sonradan karışık raporlama.

“Sonra” versiyon açılır menüyü typeahead alanıyla değiştirir. Ajan üç harf yazar, form en iyi eşleşmeleri hızlı gösterir, seçer ve devam eder. Alanda ekstra bağlam gösterebilirsiniz (e-posta alanı, hesap ID'si, şehir) ki doğru müşteri açıkça belli olsun.

Hızlı kalması için arama tarayıcıda değil sunucuda olur. UI yalnızca 10–20 eşleşme ister; bunları alaka sırasına göre (genelde tam önek eşleşme ve yakın zamanda kullanılan karışımı) ve durum (ör. yalnızca aktif müşteriler) ile filtrelenmiş olarak döndürür. Bu desen uzun listelerin günlük bir sıkıntıya dönüşmesini engeller.

Yeni akışı çok daha güvenli yapan küçük veri hijyeni adımları:

• İsimlendirme kuralı koyun (örneğin yasal ad + şehir veya domain).
• Ana alanlarda (e-posta domaini, vergi kimliği, dış ID) çoğaltmayı önleyin.
• Ürün genelinde tek bir “görüntü adı” alanı tutarlı olsun.
• Birleştirilen kayıtları pasif olarak işaretleyin ama geçmişi saklayın.

AppMaster gibi bir araçta bu tipik olarak kullanıcı yazdıkça eşleşme döndüren arama destekli bir referans alanı ve önceden tüm müşteri listesini form içine yüklememektir.

Sonraki adımlar: bir alanı yükseltin ve deseni standartlaştırın

Herkesin şikayet ettiği bir açılır menüyü seçin. İyi bir aday, birçok ekranda görünen (Müşteri, Ürün, Atanan) ve birkaç yüzün üzerine çıkan alandır. Sadece o alanı değiştirerek hızlı kanıt elde edersiniz, her formu yeniden yazmaya gerek kalmaz.

İlk olarak alanın aslında neye işaret ettiğine karar verin: kararlı bir ID'ye sahip bir referans tablo (müşteriler, kullanıcılar, SKU'lar) ve küçük bir görüntü alanları seti (isim, e-posta, kod). Sonra UI'nin hızlı alabileceği, sadece gerekeni döndüren bir arama endpoint'i tanımlayın.

Gerçekçi bir uygulama planı:

• O alan için açılır menüyü typeahead aramaya değiştirin.
• Kısmi metin ve sayalamayı destekleyen sunucu tarafı arama ekleyin.
• ID + etiket (ve bir yardımcı ipucu olarak e-posta gibi bir ikincil alan) döndürün.
• Seçilen değeri kopya metin değil ID olarak saklayın.
• Aynı varlık her kullanılacağı yerde bu deseni yeniden kullanın.

Değişikliği birkaç temel ölçümle takip edin. Alanın açılma süresini ölçün (anlık hissetmeli), seçme süresini (düşmeli) ve hata oranını (yanlış seçimler, yeniden düzenlemeler veya kullanıcı vazgeçmeleri) takip edin. 5–10 gerçek kullanıcı ile yapılan hafif bir ön/son test bile sorunu düzeltip düzeltmediğinizi gösterebilir.

AppMaster ile yönetici araçları inşa ediyorsanız referans veriyi Data Designer'da modelleyip Business Process Editor'da sunucu tarafı arama mantığını ekleyerek UI'nin her zaman küçük bir sonuç dilimi istemesini sağlayabilirsiniz. Takımlar genelde appmaster.io üzerinde inşa edilen dahili uygulamalarda bunu standart bir desen haline getirir çünkü tablolar büyüdükçe temizce ölçeklenir.

Son olarak, takımınızın tekrar kullanabileceği bir standart yazın: aramadan önce minimum karakter sayısı, varsayılan sayfa boyutu, etiketlerin nasıl formatlanacağı ve sonuç yoksa ne olacağı. Tutarlılık her yeni formun hızlı kalmasını sağlar.