Bir web sitesi randevu seçimini dışarıdan sağlanan takvim veya başvuru ekranıyla sunabilir. Ziyaretçi sayfayı açtığında boş bir alan görür, bekleme işareti uzun süre kaybolmaz ya da gönderdiği talebin sonucu belirsiz kalırsa ne yapacağını bilemeyebilir. Tasarımın sınavı yalnızca araç çalışırken takvim göstermesi değildir; araç yanıt vermediğinde kullanıcının işi kaybetmeden güvenli ve doğru bir sonraki adıma ulaşmasıdır. Bu rehber, harici randevu bileşeninin yüklenmeme, hata verme veya sonucu doğrulanamama durumlarında görev akışını tasarlar. Merter’de belirli bir işletme, ofis ya da müşteri bulunduğu iddiası içermez.

Buradaki konu, randevu saatlerini veya hizmet kapasitesini yeniden planlamak değildir. Randevu formunda uygunluk ve kesin onay rehberi seçilen zamanın beklemede mi yoksa onaylı mı olduğunu ele alır. Bu yazı, randevu arayüzü ziyaretçinin bulunduğu sayfaya yüklenmediğinde ve ana site ile sağlayıcı arasında sonuç bilgisi net olmadığında kullanıcının önündeki yolu açık tutmaya odaklanır. Proje başlangıcında web tasarım ve yazılım hizmetinin kapsamını konuşurken hangi ekranın hangi sağlayıcıdan geldiğini de netleştirin.

Arıza ile boş randevu sonucunu karıştırmayın

Kullanıcıya görünen her boş takvim aynı anlama gelmez. Randevu aracı hiç yüklenmemiş olabilir; dış hizmet yanıt vermemiş olabilir; seçilen gün için gerçekten boş saat bulunmayabilir; gönderim tamamlanmış ama ana sayfaya sonucu dönmemiş olabilir. Bu durumları tek bir “uygun saat yok” mesajına indirmek, yanlış beklenti yaratır. Arayüzünüz her durumda teknik ayrıntı göstermeyebilir; fakat en azından kullanıcının hangi aşamada olduğunu ve hangi seçeneğin açık kaldığını söylemelidir.

Bir sonuç ekranı çizmeden önce her durumun kanıtını tanımlayın. “Takvim gösteriliyor” yalnızca arayüzün açıldığını; “saat seçildi” kullanıcının bir tercih yaptığını; “talep alındı” sağlayıcının veya işletme akışının talebi kaydettiğini; “randevu kesinleşti” ise onayın gerçekleştiğini anlatmalıdır. Sisteminiz yalnızca ilk iki bilgiyi görebiliyorsa son ikisini olmuş gibi göstermeyin. Sağlayıcıdan dönmeyen bir yanıtı otomatik olarak başarı ya da başarısızlık saymayın.

Durum metninde arızanın kaynağını kesinleştiremediğiniz hâlde sağlayıcıyı suçlamayın. Kullanıcının gördüğü sonucu ve elindeki sonraki seçeneği anlatın; teknik nedeni ancak kayıtlar veya sağlayıcı desteği doğruladığında iç inceleme notuna ekleyin.

Yükleme öncesi ve yükleme beklerken ne gösterileceğini belirleyin

Randevu bölümünün etrafında kullanıcıyı boşlukta bırakmayan bir açıklama bulunsun: araç hangi amaçla açılıyor, yüklenirken yaklaşık olarak hangi alanın görünmesi bekleniyor ve yükleme sürerse hangi seçenek kullanılabilir? Süre sınırını veya geri dönüş zamanını işletme gerçekten belirlemiyorsa sayı yazmayın. Bekleme işareti tek başına bir durum açıklaması değildir. Yavaş bağlantı, kapalı pencere veya desteklenmeyen bir ekran boyutunda kullanıcı araç görünene kadar ne yapacağını anlayabilmelidir.

Yükleme mesajını sürekli yenilenen hareketli bir işarete çevirmek yerine, kısa bir metin ve ikinci bir eylemle tamamlayın. “Takvim hazırlanıyor” mesajının yanında, sağlayıcının asıl randevu sayfasına geçiş bağlantısı ya da işletmenin gerçekten izlediği bir alternatif başvuru yolu sunulabilir. Bu seçenekler projede kurulmamışsa varmış gibi anlatmayın. Dış araç kullanılamadığında bile diğer sayfa içeriğinin ve temel iletişim yolunun erişilebilir kalıp kalmadığını ayrıca kontrol edin.

Hata durumunda kullanıcıyı gerçek bir alternatife yönlendirin

Bir bileşen başarısız olduğunda, kullanıcının seçebileceği yedek yol önceden tanımlanmalıdır. Bu yol dış sağlayıcının ayrı randevu sayfası olabilir, bir talep formu olabilir ya da işletmenin doğrulanmış iletişim kanalı olabilir. Her projede aynı alternatif uygun değildir. Örneğin ekip randevu taleplerini e-posta ile izlemiyorsa, ekranda “bize e-posta gönderin” yazmak kullanılabilir bir çözüm sağlamaz. Kanalı, sorumlu kişiyi ve talebin nasıl takip edileceğini gerçek işleyişle doğrulayın.

Alternatif düğmenin yanında ne olacağını açıkça yazın. Dış sayfaya geçiş, kullanıcının mevcut site içindeki seçimlerini taşımayabilir; başvuru formu ise randevuyu anında kesinleştirmeyebilir. Bunlar farklı sonuçlardır. “Başka bir yöntemle talep ilet” seçeneği sunuluyorsa kişinin hangi bilgiyi yeniden girmesi gerekebileceğini ve talebin onay bekleyeceğini dürüstçe belirtin. Olmayan bir telefon numarası, sabit geri dönüş süresi veya kesin rezervasyon vaadi eklemeyin.

Dış araç yeni sekmede açılıyorsa, geri dönen kullanıcı için açıklayıcı bir bağlam bırakın. Aynı sayfaya dönmek randevunun kesinleştiğini göstermez. Kullanıcıya sonucu hangi ekranda göreceğini, dış hizmetin verdiği onay bilgisini saklayıp saklamaması gerektiğini ve emin değilse kiminle iletişim kuracağını anlatın. Geri dönüş yolu gerçekten mevcut değilse bunu geliştirme kapsamına alın; bağlantıdan geri dönünce başarı mesajı göstermeyin.

Sonucu bilinmeyen gönderimi ikinci kez başlatmayın

Bir kullanıcının gönder düğmesine basıp yanıt alamaması, talebin hiç kaydedilmediğini kanıtlamaz. Önce bir belirsiz sonuç durumu belirleyin: “Sonucu doğrulayamadık; tekrar göndermeden önce randevu kaydınızı kontrol edin” gibi bir açıklama, iki ayrı talep oluşturma riskini azaltır. Ancak kontrol yolu da kullanıcının gerçekten erişebileceği bir sayfaya, sağlayıcı onayına veya izlenen iletişim kanalına dayanmalıdır. Kontrol imkânı yoksa bunu çözüm olarak varmış gibi yazmayın.

İşletme tarafında da tek bir olayın iki defa kaydedilip kaydedilmediğini test edin. Hızlı çift tıklama, sayfanın yenilenmesi veya bağlantı kesilip geri gelmesi farklı davranışlar doğurabilir; hangi kayıt sisteminin son sözü söylediği belirlenmelidir. Bu öneri bir sağlayıcının teknik özelliğini varsaymaz. Proje ekibi, seçili araçta tekrar gönderimi nasıl ele aldığını ve sonuç belirsiz olduğunda hangi kayıtla karşılaştırma yapacağını kanıtlayarak açıklamalıdır.

Harici randevu ekranı ayrı bir belge veya hizmet olarak çalışabilir. MDN’nin çerçeve ve aynı kaynak ilkesi belgeleri, gömülü içeriğin ana sayfadan ayrı olabileceğini ve tarayıcının kaynaklar arasındaki erişimi sınırladığını açıklar. Bu nedenle dış ekranda girilen bilgilerin ana siteye otomatik aktarılacağını varsaymayın; hangi verinin hangi adımda kaydedildiğini sağlayıcı belgeleri ve kontrollü testle doğrulayın. Kullanıcının baştan tekrar girmesi gereken bilgi varsa bunu geçişten önce söyleyin; site formuna yazdığı verinin dış sağlayıcı ekranında durduğunu ileri sürmeyin.

Gömülü ekranla ayrı sayfa arasındaki geçişi anlaşılır tutun

Randevu aracı site içinde görünüyorsa başlık ve kısa açıklama, kullanıcının farklı bir hizmetle karşılaştığını anlamasına yardım etmelidir. Yeni sayfaya geçiş yapılıyorsa bağlantı bunun dış sağlayıcıya götürdüğünü açıkça belirtmelidir. Her iki yöntemde de kullanıcı seçtiği randevu konusunu, önceki sayfaya dönüş yolunu ve tamamlanmış sayılma koşulunu anlayabilmelidir. Dış ekranın rengi veya düzeni değiştiğinde sitenin açıklaması hâlâ doğru mu, ayrıca kontrol edin.

Telefon ekranında randevu alanı daralabilir, altına yerleştirilen eylem düğmesi görünmeyebilir veya içerik içinde ikinci bir kaydırma alanı oluşabilir. Klavye ve ekran okuyucu kullanan kişi bileşene odaklanabilmeli, nerede olduğunu anlayabilmeli ve sayfanın geri kalanına dönebilmelidir. Bu bir sağlayıcıya ilişkin evrensel uyumluluk iddiası değildir; hedef cihazlarda yapılacak kabul kontrolüdür. Harita bileşeninin metin alternatifi ve hata durumu için bileşen hata akışı rehberindeki temel yaklaşım yardımcı olabilir; randevu görevinin kendisi ayrıca sınanmalıdır.

Sorumluyu ve test kanıtını teslim edin

Proje ekibi, randevu sağlayıcısının bağlantısı veya hesabı değiştiğinde hangi kişinin sayfayı güncelleyeceğini, hatalı yönlendirmeyi kimin fark edeceğini ve kullanıcıya hangi alternatifin sunulacağını işletmeyle birlikte belirlemelidir. Yönetim erişimi veya sağlayıcı hesabının parolası makale, ekran görüntüsü ya da teslim notuna yazılmamalıdır. Sorumluluk belirsizse, kullanıcıyı çalışmayan bileşene tekrar tekrar yönlendirmek yerine önce bakım sahipliğini belirleyin.

Kabul kaydında kullanılan sayfa sürümü, tarih, cihaz ve tarayıcı, denenen senaryo, ekranda görülen mesaj, dış sağlayıcıya geçişin sonucu ve kontrolü yapan rol bulunabilir. Bir testin başarılı olması ertesi gün dış hizmetin aynı şekilde çalışacağını garanti etmez; bu nedenle hata bildirimi ve yeniden kontrol yolu da teslim edilir. Alan hatası ve geri dönüş davranışı için form hatasında bilgi koruma rehberini, uzun işlemi kaydedip sürdürme örneği için taslakla devam rehberini inceleyin. İkisi de harici sağlayıcı sonucunun onaylandığı anlamına gelmez.

Proje kapsamını site tasarımı, randevu sağlayıcısının kurulumu, içerik ve bakım sorumluluğu olarak ayırın. Web tasarım ve yazılım hizmeti konuşulurken hangi bileşenin kim tarafından sağlanacağı, hesap erişimi, kullanıcı desteği ve hata durumundaki alternatif yazılı olsun. Tasarım ekibinin dış sağlayıcının iç sistemini yönettiği varsayılmamalıdır; sahiplik kararı gerçek erişim ve proje kapsamıyla doğrulanır.

Yayın sonrasında sağlayıcı bağlantısı, sayfa metni veya sorumlu ekip değişebilir. Değişiklikten sonra gömülü alanı, dış sayfa geçişini ve başarısız yükleme yolunu yeniden deneyin. İçerik değişikliği sağlayıcı ekranının çalıştığını kanıtlamaz; sağlayıcı onayı da ana sitedeki açıklamanın güncel kaldığını tek başına göstermez. Bu iki tarafı ayrı kontrol kaydında düzenli olarak tutmak, hata bildiriminin doğru ekibe ulaşmasına yardımcı olur.

Sık Sorulan Sorular

Harici randevu aracı açılmıyorsa kullanıcı ne görmeli?

Boş takvimi uygun saat yokmuş gibi göstermeyin. Aracın yüklenemediğini sade biçimde söyleyin ve yalnızca gerçekten kurulu olan alternatif yolu sunun. Alternatif yoksa “randevunuz alındı” demek yerine destek ekibinin takip edeceği adımı tamamlayın.

Gömülü randevu alanı yerine dış sayfa bağlantısı kullanmak daha mı iyidir?

Her projede tek doğru yöntem yoktur. Gömülü görünüm sayfa içinde kalmayı kolaylaştırabilir; ayrı sayfa ise sağlayıcının kendi yönlendirmesini açık tutabilir. Kullanıcının görevini hedef cihazlarda deneyin; tasarım kararı, marka görünümünden önce anlaşılırlık ve güvenilir devam yoluna dayanmalıdır.

Bekleme işareti ne kadar süre gösterilmelidir?

İşletme ve sağlayıcı gerçekçi bir süre belirlememişse saniye sayısı vaat etmeyin. Kullanıcıya yüklemenin sürdüğünü, ne zaman yeniden deneyebileceğini veya hangi alternatifin bulunduğunu anlatın. Süre aşıldığında arayüz aynı işareti sonsuza kadar göstermemelidir.

Gönder düğmesine bastım, sonuç görünmüyor; tekrar denemeli miyim?

Önce talebin kaydedilip kaydedilmediğini doğrulayan gerçek bir kontrol yolu sunun. Bu mümkün değilse, tekrar göndermenin yeni talep oluşturabileceği konusunda açık bilgi verin ve onaylanmış destek kanalını gösterin. Sonuç belirsizken iki kez tıklamayı başarı gibi göstermeyin.

Dış ekranda yazılan bilgiler ana sitede saklanır mı?

Bu, kullanılan entegrasyonun gerçek davranışına bağlıdır. Gömülü bir ekran görmek, verinin ana siteye kopyalandığını kanıtlamaz. Hangi adımda hangi sistemin kayıt tuttuğunu sağlayıcı belgesi ve kontrollü testle doğrulayın; test edilmemiş bilgi koruması sözü vermeyin.

Sağlayıcıya geçince kullanıcı randevusunun onaylandığını varsayabilir mi?

Hayır. Bir sayfayı açmak veya takvimde saat seçmek kesin onay anlamına gelmeyebilir. Onay, yalnız sistemin veya işletmenin doğruladığı durumda gösterilmelidir. Kullanıcı dış sağlayıcıdan dönüş aldığında bunu nerede göreceğini ve sonuçtan emin değilse kime ulaşacağını bilmelidir.

Aracı hangi cihazlarda ve durumlarda test etmeliyim?

En azından telefon ve masaüstünde normal yükleme, yavaş bağlantı, sağlayıcı yanıtı gelmemesi, boş uygunluk sonucu, dış sayfaya geçiş ve belirsiz gönderim durumlarını deneyin. Klavye ile kullanım, geri dönüş bağlantısı ve alternatif başvurunun gerçekten çalışması da test kapsamına girmelidir.

Web tasarım tesliminde bu araç için hangi bilgiler kalmalı?

Sağlayıcı bağlantısının sahibi, sayfa içindeki açıklamanın kimin tarafından güncelleneceği, hata durumunda kullanıcıya sunulan gerçek alternatif ve test kanıtının nerede tutulduğu yazılmalıdır. Parola veya gizli erişim anahtarı eklemeyin. Sağlayıcı veya işletme sorumluluğu değiştiğinde kaydın güncellenmesi gerekir.