Sınıf Yoklaması İçin Mobil Uygulama Nasıl Oluşturulur

Hedefi ve Kullanıcıları Tanımlayın

Kablolar veya özelliklerden önce ne inşa ettiğinizi ve kimin için olduğunu netleştirin. Bir sınıf yoklama uygulaması, hızlı bir “var/yok” aracından denetimler, raporlama ve veli görünürlüğü olan tam bir yoklama sistemine kadar her şeyi ifade edebilir. Sınırları erken belirlemezseniz, öğretmenler için kafa karıştırıcı ve bakım açısından zor bir öğrenci yoklama uygulamasıyla karşılaşırsınız.

Kimler kullanacak?

Öncelikle birincil kullanıcıları ve onların günlük gerçekliğini düşünün:

• Öğretmenler hızlı, düşük engelli yoklamalar, hataları düzeltme imkanı ve kimin eksik olduğunu basitçe görebilme ister.
• Öğrenciler hızlı ve öngörülebilir bir giriş akışı ister (Wi‑Fi zayıfken çalışmayan bir şey olmasın).
• Yöneticiler raporlama, uyumluluk ve sınıflar arasında tutarlı kurallarla ilgilenir.
• Veliler (isteğe bağlı) okul politikası izin veriyorsa salt‑okuma görünürlüğü veya devamsızlık bildirimleri gerekebilir.

Çözülmesi gereken ana problem

Çekirdek vaadi bir cümleyle tanımlayın, örneğin: “Yoklama süresini azaltın ve doğruluğu artırın, ekstra iş yükü yaratmadan.” Bu, QR kodu, NFC, manuel düzeltmeler veya raporlama seçimine karar verirken odaklanmayı sağlar.

Nerede kullanılacak?

Yoklamalar dağınık, gerçek ortamlarda olur: sınıflar, laboratuvarlar, spor salonları, saha gezileri, toplantılar ve bazen uzaktan oturumlar. Gürültü, zaman baskısı, cihaz erişilebilirliği ve zayıf bağlantı gibi kısıtları not edin—bunlar “yoklama için mobil uygulama”nın pratikte nasıl hissettirmesi gerektiğini belirler.

Başarı nasıl görünür?

Ölçülebilir sonuçlar seçin:

• Sınıf başına kazandırılan zaman (örn. yoklama 3 dakikadan 30 saniyeye düşerse)
• Daha yüksek giriş doğruluğu (daha az çoğaltma ve “ben vardım” anlaşmazlıkları)
• Öğretmen ve yöneticilerin daha az düzeltme yapması
• Raporlamanın kullanım faydası (sınıf, tarih ve öğrenciye göre net eğilimler)

Bu hedefler sonrasında ekleyeceğiniz her özelliğin karar filtresi olur.

Temel Kullanım Senaryolarını Seçin (Önce MVP)

Bir sınıf yoklama uygulaması tam bir sınıf yönetimi paketine dönüşebilir—ama her şeyi bir anda yayınlamaya çalışmak en hızlı şekilde duraklatır. Öğretmen için güvenilir yoklamalar ve net bir kayıt sağlayan en küçük kullanım setini tanımlayarak başlayın.

Olmazsa olmaz akışlar (MVP)

Ürünü uçtan uca kullanılabilir yapan vazgeçilmezler:

• Sınıf oluşturma: Öğretmen sınıf oluşturur (isim, program, konum isteğe bağlı) ve katılma yöntemi (kod/link) alır.
• Liste ekleme: CSV ile içe aktarma, liste yapıştırma veya öğrencilerin kendilerinin katılmasına izin verip öğretmenin onaylaması.
• Oturum başlatma: Öğretmen bugünkü sınıf için “Yoklamayı başlat”a dokunur ve temel kuralları belirler (X dakika açık).
• Öğrenci yoklaması: Öğrenci seçilen yöntemle varlığını doğrular (QR/NFC/konum/manuel—MVP için birini seçin).
• Öğretmen inceleme: Öğretmen kimin var/yok olduğunu görür ve bir nedenle üzerinde değişiklik yapabilir.

İsteğe bağlı akışlar (2. faz)

Çekirdek döngü stabil olduğunda doğruluğu ve raporlamayı geliştiren özellikleri ekleyin:

• Geç/erken bayrakları (hoşgörü süresiyle)
• Mazaretli yoklama (basit neden kodları)
• Telafi oturumları (yoklama sonucunu farklı bir tarih/oturuma ilişkilendirme)

Erken ele alınması gereken kenar durumlar

Gerçek sınıflar karmaşıktır. Öğretmenlerin uygulamayı bırakmaması için hafif yedek akışlar planlayın:

• Öğrenci telefonu unuttu / pil bitti: Öğretmen notla var olarak işaretleyebilir veya tek kullanımlık “manuel giriş” kodu verebilir.
• Paylaşılan cihaz: Giriş öncesi hesap değiştirmeye izin verin veya öğretmen onaylı “başka bir öğrenciyi giriş yap” desteği sağlayın.
• Misafir katılımcılar: Öğretmen geçici bir katılımcı (isim + etiket) ekleyebilsin; resmi listede kirlilik oluşmasın.

Kapsamı gerçekçi tutun

İyi bir MVP şu soruyu cevaplar: “Bir öğretmen 30 saniyeden kısa sürede yoklama alabilir mi ve öğrenciler kafa karışıklığı olmadan giriş yapabiliyor mu?” Bir özellik doğrudan bu hedefi desteklemiyorsa, sonraki sürümlere planlayın.

Roller ve İzinleri Haritalayın

Roller ve izinler uygulamada kimin ne yapabileceğini belirler. Bunu erken doğru yapmak kafa karışıklığını (“Neden öğrenciler yoklamayı düzenleyebiliyor?”) önler ve gizlilik riskini azaltır.

Üç temel rol ile başlayın

Çoğu okul MVP'yi şu üç rol ile başlatabilir:

• Öğretmen: yoklama oturumları oluşturur, canlı girişleri görür, istisnaları düzenler (geç/eksik/mazeret) ve raporları dışa aktarır.
• Öğrenci: hızlı yoklama yapar, kişisel yoklama geçmişini görür ve hatırlatmalar alır.
• Yönetici: okulları/sınıfları, kullanıcıları, rolleri ve akademik dönemleri yönetir.

Daha sonra ihtiyaç olursa (ör. vekiller, yardımcı öğretim görevlileri, bölüm başkanları) yeni roller ekleyin—bunları tek seferlik “özel durum” olarak yapmayın.

İzinleri nesneler üzerinde eylemler olarak yazın

İzinleri uygulama nesnelerine bağlanmış düz cümleler halinde yazın. Örnek:

Bu format boşlukları belirgin kılar ve ekibinizin rol‑temelli erişim kontrolünü (RBAC) uygularken şüpheleri azaltır.

“En az erişim” ve kapsam kurallarını uygulayın

İzinler yalnızca role göre değil, kapsam ile sınırlı olmalı:

• Bir öğretmen sadece kendi sınıflarına erişebilir, okulun tüm sınıflarına değil.
• Bir öğrenci sadece kendi yoklama geçmişini görmelidir.
• Yönetici erişimi kaydedilmeli ve gerçek yönetim görevleri için ayrılmalıdır.

Ayrıca düzenlemelerin nerede izinli olacağını kararlaştırın. Örneğin, öğretmenler yoklamaları sadece 24 saat içinde düzeltebilir; yöneticiler daha sonra gerekçe ile geçersiz kılabilir.

Kenar durumlarını unutmayın

Geçişler, düşen sınıflar ve dönem değişiklikleri için plan yapın. Öğrenci sınıf değiştirse bile geçmiş kayıtların okunabilir kalmasını sağlayın ve geçmiş dönem raporlarını doğru kişilerin üretebildiğinden emin olun.

Bir Yoklama Yöntemi Seçin (QR, NFC, Konum veya Manuel)

Seçtiğiniz yöntem her şeyi belirler: yoklamanın hızı, hangi cihazları desteklemeniz gerektiği ve sahteciliğin ne kadar kolay olabileceği. Birçok uygulama birden fazla yöntemi destekler; böylece okullar basit başlayıp sonra seçenek ekleyebilir.

Manuel yoklama (öğretmen liderliğinde temel)

Manuel yoklama her yerde çalışan en güvenli seçenektir. Öğretmen sınıf listesini açar, var/geç/eksik olarak işaretler ve hızlı not ekleyebilir (örn. “10 dakika gecikti”).

Tarama veya konum eklerseniz bile bunu bir yedek olarak kullanın—Wi‑Fi kesintileri, kameralar bozulur ve vekiller güvenilir bir akışa ihtiyaç duyar.

QR kod tarama (hızlı, düşük maliyet)

QR popülerdir çünkü hızlıdır ve özel donanım gerektirmez. Öğretmen ekranda bir QR gösterir (veya bastırır), öğrenciler uygulamayla tarar ve yoklama kaydedilir.

“Ekran görüntüsü paylaşımını” azaltmak için QR kodu:

• Zaman sınırlı olsun (örn. her 15–30 saniyede döner)
• Sınıf/oturum‑spesifik olsun (yeniden kullanılmaz)
• Kısa bir yoklama penceresinde geçerli olsun

NFC dokunuşu (çok hızlı, ancak donanım bağımlı)

NFC yüz yüze deneyimini en pürüzsüz yapan yöntem olabilir: öğrenciler sınıf kapısındaki etikete veya öğretmenin cihazına dokundurur.

Dezavantajlar: tüm telefonlar NFC desteklemez ve etiketleri satın alıp yönetmeniz gerekebilir. NFC, okul fiziksel alanı kontrol ettiğinde ve “dokun ve git” hızını istediğinde en iyi çalışır.

Konuma dayalı yoklama (GPS/geofence)

Geofencing bir öğrencinin belirli bir mekânda olduğunu doğrulayabilir (spor salonu, laboratuvar, kampüs binası). Büyük ders salonlarında tarama kuyrukları oluştuğunda işe yarar.

Dikkat: GPS iç mekânlarda hatalı olabilir ve konum verileri hassastır. Onay açık olsun, gereken asgari veriyi toplayın (çoğu zaman “içeride/dışarıda” yeterlidir) ve konum dışı bir yedek sunun.

Çevrimiçi dersler için uzaktan yoklama

Sanal oturumlar için pratik bir yaklaşım tek seferlik bir kod + zaman penceresidir (örn. 3 dakika). Kod paylaşımını caydırmak için öğrencinin oturum açmasını zorunlu kılma, deneme sayısını sınırlama ve aynı cihaz/IP’den çok sayıda giriş gibi olağandışı desenleri işaretleme gibi hafif kontroller ekleyin.

Emin değilseniz, MVP olarak manuel + QR ile başlayın; sonra okulun fayda sağlayacağı yerde NFC veya geofence ekleyin.

Kullanıcı Deneyimini ve Ekranları Tasarlayın

İyi yoklama uygulamaları “anında” hissi verir. Öğrenciler birkaç dokunuşla giriş yapabilmeli; öğretmenler ise sınıf durumunu bir bakışta anlamalı.

Öğrenci uygulaması: tek bir birincil akış tutun

Günlük kullanım için minimal ekran setiyle başlayın:

• Sınıfa katıl: kod/link gir, sınıf adı ve öğretmeni onayla, kaydet.
• Bugünün oturumu: mevcut sınıfı, zaman penceresini ve tek bir birincil eylemi göster (Tarama / Dokun / Yokla).
• Tarama/Dokun: kamera veya NFC istemi, açık talimat ve büyük bir iptal düğmesi.
• Onay: zaman damgası, oturum adı ve bir sorun olursa ne yapılacağı ile başarı durumu.
• Geçmiş: geçmiş oturumların basit listesi (Var / Geç / Mazeretli / Eksik), filtreler isteğe bağlı olsun.

Tasarım ipucu: acele kullanım varsayımıyla büyük düğmeler, kısa etiketler ve tarama hataları için “Tekrar dene” yolu ekleyin.

Öğretmen uygulaması: hızlı kurulum, canlı izleme, hızlı düzeltme

Öğretmenlerin üç anı desteklemesi gerekir:

• Oturum kurulumu: sınıfı seç, oturumu başlat, isteğe bağlı geç kalma sınırını ayarla ve QR/NFC oluştur.
• Liste + canlı durum: Not checked in / Present / Late gibi net rozetlerle gerçek zamanlı liste. Arama çubuğu ekleyin.
• Neden düzenleme + sonlandırma: hızlı geçersiz kılmalar (örn. “Otobüs gecikmesi”, “Tıbbi”), notlar ve oturumu kilitleyen finalize düğmesi.

Kritik eylemleri menülere gömmeyin—oturumu başlatma/bitirme her zaman görünür olmalı.

Yönetici paneli: genellikle web'de en iyisi

Birçok okul sınıf, kullanıcı ve rapor yönetimi için mobil yerine web tabanlı yönetici paneli tercih eder. Toplu düzenlemeler, yoklamaların dışa aktarımı ve personel değişiklikleri için web daha uygundur.

Önemli erişilebilirlik temel kuralları

Yüksek kontrastlı metin, büyük yazı boyutu desteği, açık hata mesajları (“QR tanınmadı—daha yakınlaştırın ve parlaklığı artırın”) ve düşük ışık tarama UI'si (parlak viewfinder, el feneri anahtarı) ekleyin.

Veri Modelini ve Kayıtları Planlayın

Temiz bir veri modeli uygulamanın güvenilir kalmasını sağlar. Önce gerçekten ihtiyaç duyduğunuz minimum veriyi yazın, ardından bir kullanım durumu gerektirdikçe genişletin.

MVP için saklanması gereken minimum veri

Asgari olarak ihtiyacınız olacak:

• Öğrenci kimliği: isim ve kalıcı öğrenci ID (e-posta yerine buna güvenin)
• Sınıf üyeliği: hangi öğrencilerin hangi sınıfta olduğu
• Yoklama kayıtları: kim girdi, hangi oturuma, hangi durumla (var/geç/mazeretli)
• Cihaz tokenleri (isteğe bağlı): push bildirimleri için

Temel varlıklar (pratik başlangıç şeması)

Çoğu uygulama küçük bir varlık setiyle modellenebilir:

• School → temel organizasyon konteyneri
• Term → tarih sınırlı gruplayıcı (yarıyıl/çeyrek)
• Class → dönemdeki bir ders kısmı (örn. “Matematik 2B – 3. Ders”)
• Session → sınıfın belirli bir toplantısı (tarih/saat; önceden oluşturulabilir veya talep üzerine)
• Student → profil + tanımlayıcılar
• AttendanceEvent → yoklama olayı (öğrenci + oturum + durum + zaman damgası + yöntem)

İpucu: Session ile AttendanceEvent'i ayrı tutun ki “gelmeyenler” sahte olay yaratmadan takip edilebilsin.

Denetim izi (okullar için vazgeçilmez)

Her düzenleme izlenebilir olmalı. Her değişiklik için şunları saklayın: kim (öğretmen/ yönetici ID), ne zaman, hangi alanlar ve kısa bir gerekçe (örn. “tıbbi not sağlandı”). Bu anlaşmazlıkları azaltır ve uyumluluğu destekler.

Saklama ve silme politikası

Kaçınılmaz olarak karar verin:

• Ham loglar ve denetim kayıtları (genellikle UI'da görünenden daha uzun saklanır)
• Personel tarafından oluşturulan dışa aktarımlar (CSV/PDF)

Veri talepleri için silme iş akışlarını belgeleyin: neler kaldırılıyor, ne anonimleştiriliyor ve hangi kayıtlar yasal/politika nedeniyle saklanmalı. Açık bir politika sonradan panik yaşanmasını engeller.

Teknoloji Yığını Seçimi (Basit ve Sürdürülebilir)

Teknoloji yığını MVP kapsamınıza, ekibinizin becerilerine ve okulların önem verdiği raporlama ihtiyaçlarına uygun olmalı. En basit yığın genellikle en az hareketli parça olandır.

Backend: önce yönetilen, gerekiyorsa özelleştirin

Çoğu ilk versiyon için yönetilen bir backend aylar kazandırır.

• Firebase hızlı kimlik doğrulama, gerçek zamanlı güncellemeler, push bildirimleri ve düşük sunucu bakımı istediğinizde iyidir.
• Supabase SQL tabanlı (Postgres) ve sorgulamalar için tercih edilebilecek güçlü bir alternatiftir.
• Özel API (Node/Java/.NET vb.) entegrasyon veya özel barındırma gereksinimleriniz varsa mantıklıdır.

Kural: yönetilen ile başlayın; net bir sınıra gelene kadar özel API'ye geçmeyin.

Eğer geleneksel inşa döngüsüne bağlı kalmadan daha hızlı ilerlemek isterseniz, Koder.ai gibi vibe-coding platformlarında prototip oluşturabilirsiniz. Sohbet ile öğretmen/öğrenci akışlarını yineleyebilir, React yönetici paneli oluşturabilir ve Go + PostgreSQL backend kurabilirsiniz—ve hazır olduğunuzda kaynak kodu dışa aktarabilirsiniz.

Mobil uygulama: çapraz platform mu, yerel mi?

• Flutter ve React Native genellikle MVP için iyi seçimdir: iOS/Android için tek kod tabanı, daha hızlı yineleme.
• Yerel iOS/Android derin cihaz özelliklerine ihtiyaç varsa veya güçlü bir yerel ekip varsa tercih edilebilir.

Veri tabanı: raporlama gereksinimine göre seçin

Yoklama raporlamaya dayalıdır. “Eylül ayında 9. sınıfın tüm devamsızlıkları” veya “öğrenci bazında gecikmeler” gibi sorgular bekliyorsanız SQL (Postgres) genellikle en güvenli tercihtir.

NoSQL hızlı prototipler için çalışabilir ama gereksinimler büyüdükçe raporlama zorlaşabilir.

Kimlik doğrulama: okullar için kolaylaştırın

Yaygın seçenekler:

• Google/Microsoft SSO: District zaten Workspace veya Microsoft 365 kullanıyorsa
• Magic link: öğretmenlerin parola sorunlarını azaltmak için
• Okul‑provisioned hesaplar (liste senkronizasyonu) daha sıkı kontrol gerektiğinde

Hangi yöntemi seçerseniz seçin, hesap yaşam döngüsünü (yeni dönem, transfer, mezuniyet) erkenden planlayın—aksi halde destek maliyetleri fırlayabilir.

Gerçek Sınıflar İçin İnşa Edin: Çevrimdışı ve Sahteciliğe Karşı Temeller

Sınıf gürültülü, zaman sınırlı bir ortamdır. Öğrenciler farklı zamanlarda gelir, Wi‑Fi zayıftır ve “kodunu tara” hızla kenar durumlara dönüşür. Yoklama akışınız bu koşullarda başarısız olursa öğretmenler uygulamayı terk eder.

Çevrimdışı‑öncelikli yoklamalar (zayıf Wi‑Fi kırmasın)

Yoklamaların ağ yokken bile çalışması için plan yapın:

• Yoklamaları cihazda yerel saklayın (zaman damgası, oturum ID, öğrenci ID, yöntem ve “beklemede” gibi geçici durum)
• Bağlantı geri geldiğinde arka planda senkronize edin
• UI durumlarını net gösterin: Beklemede senkron vs Onaylandı, böylece tartışmalar azalır

Senkronizasyon sırasında olayları üzerine yazmak yerine ekleme odaklı (append-only) gönderin; hata ayıklama kolaylaşır.

Başından karar verilecek çakışma kuralları

Çevrimdışı ve çoklu cihazlar çakışma yaratır. Sunucunun otomatik çözebilmesi için deterministik kurallar belirleyin:

• Çoğaltılmış taramalar: en erken geçerli girişi tutun, diğerlerini yoksayın (ama kaydedin).
• Bir öğrenci için birden fazla cihaz: bir oturum için sadece bir aktif girişe izin verin; ek girişleri öğretmen incelemesine işaretleyin.
• Oturum bittiğinde geç senkron: giriş izin verilen pencere içinde oluşturulduysa kabul edin; aksi halde geç/geçersiz işaretleyin.

Öğretmenleri rahatsız etmeyecek sahteciliğe karşı önlemler

Ağır gözetim gerekmez—birkaç pratik kontrol yeterlidir:

• Dönen QR kodları (15–30 saniyede değişen)
• Kısa zaman pencereleri (örn. dersin ilk 5–10 dakikası) ve isteğe bağlı “geç” nedeni
• Şüpheli desenler için öğretmen onayı (aynı saniyede çok sayıda giriş, tekrarlı çoğaltmalar, cihaz değişimleri)

Cihaz zamanı sorunları (sessiz hataların kaynağı)

Telefon saatleri yanlış olabilir. Mümkün olduğunda sunucu zamanına güvenin: uygulama oturum zaman penceresini sunucudan isteyip yüklemeyi bu kurallara göre doğrulasın. Çevrimdışıyken cihaz zaman damgası kaydedin ama senkron esnasında sunucu ile karşılaştırıp belirlenen kuralları tutarlı şekilde uygulayın.

Gizlilik ve Güvenlik Gereksinimleri

Yoklama verisi basit gözükse de sıklıkla kişisel tanımlayıcı bilgileri (PII) ve zaman/konum sinyallerini içerir. Gizliliği ve güvenliği sadece mühendislik işi değil, ürün gereksinimi olarak ele alın.

Veriyi aktarımda ve sunucuda şifreleyin

Tüm ağ trafiği HTTPS (TLS) ile şifrelenmeli. Bu, okul Wi‑Fi'sinde yoklamaların, roster güncellemelerinin ve yönetici işlemlerinin ele geçirilmesini engeller.

Sunucuda veri saklanırken sağlayıcı destekliyorsa at‑rest şifrelemesi etkinleştirin ve anahtarları yönetilen bir anahtar hizmetiyle koruyun. Cihazda hassas veri saklamaktan kaçının; çevrimdışı önbellek gerekiyorsa OS tarafından sağlanan güvenli depolamayı tercih edin.

Sadece gerektiği kadar toplayın (ve nedenini açıklayın)

Doğrulama ve anlaşmazlık desteklemek için gerekeni toplayın. Birçok okul için öğrenci ID, oturum ID, zaman damgası ve “yöntem” bayrağı yeterlidir.

Eğer ek sinyaller (GPS koordinatları, QR tarama meta verisi veya cihaz tanımlayıcılar) kaydediyorsanız, amacı açık bir dilde belgeleyin. “Konumu yalnızca sınıfta olduğunu doğrulamak için kullanıyoruz” gibi sade açıklamalar belirsiz ifadelerden daha iyi okunur.

Onay, şeffaflık ve açık kurallar

Kullanıcılar hangi işlemin geçerli yoklama sayılacağını ve nelerin kaydedileceğini anlamalı. Yoklama ekranı ve ayarlarında açıkça gösterin:

• Hangi veriler kaydediliyor (zaman, sınıf, yöntem, eğer etkinse konum)
• Kimler görebilir (öğretmen, yöneticiler)
• Ne kadar süre saklanır
• Öğrenci gecikmeli veya izin verilen alan dışında giriş yaparsa ne olur

Bu, özellikle QR, NFC veya geofence gibi yöntemler getirdiğinizde güven oluşturur.

Temel uyumluluk düşünceleri (hukuki garanti olmadan)

Gereksinimler bölgeye ve kuruma göre değişir. ABD'de öğrenci kayıtları FERPA kapsamına girebilir; AB/İngiltere'de GDPR geçerli olabilir. Pazarlama metninde uyumluluk sözü vermeden önce hukuki doğrulama yapın. Bunun yerine aşağıdaki ortak beklentilerle tasarlayın: rol bazlı erişim kontrolleri, düzenleme denetim kayıtları, veri saklama kontrolleri ve kayıt dışa aktarma/silme yolları.

Eğer uygulamanız başka sistemlerle entegre oluyorsa, paylaşılan verileri gözden geçirin ve bu entegrasyonların da güvenli, kimlik doğrulamalı bağlantılar kullandığından emin olun.

Bildirimler ve Entegrasyonlar

Bildirimler bir sınıf yoklama uygulamasını "canlı" hissettirir. Doğru yapıldığında kaçırılan yoklamaları azaltır ve öğretmenlerin takip işini hafifletir. Kötü yapıldığında ise gürültü olur—bu yüzden ilgili, zamanında ve kontrol edilebilir olmalarını sağlayın.

Gerçekten yardımcı olan push bildirimleri

Basit bir push seti çoğu okul için yeterlidir:

• Ders hatırlatmaları: öğrencilere ders başlamadan birkaç dakika önce gönderilir (sessizlik saatleri ve zaman dilimi dikkate alınmalı).
• Oturum başladı: öğretmen yoklamayı açtığında tetiklenir.
• Giriş yapmayanlara hatırlatma: öğrenci kısa bir hoşgörü süresi sonra hala giriş yapmadıysa gönderilir.

Kullanıcılara kontrol verin. Öğrenciler bir ders için hatırlatmaları susturabilmeli; öğretmenler sınav veya saha gezisi gibi özel durumlar için öğrenci hatırlatmalarını devre dışı bırakabilmelidir. Ayrıca erişilebilirlik için net ifadeler kullanın.

Öğretmenler ve yöneticiler için e‑posta özetleri (isteğe bağlı)

E‑posta hâlâ kayıt tutma ve yönetim iş akışları için faydalıdır. İsteğe bağlı ve yapılandırılabilir tutun:

• Günlük/haftalık özetler: hangi öğrencilerin geldiği, kimlerin kaçırdığı, geç gelenler
• Yönetici özetleri: sınıf veya sınıf düzeyi eğilimler

Hassas bilgileri yanlış posta kutusuna göndermekten kaçının—alıcıları role göre belirleyin ve yalnızca gerekli bilgiyi gönderin.

Entegrasyonlar: önce CSV, sonra SIS/LMS

Entegrasyonlar zaman kazandırır ama MVP'yi yavaşlatabilir. Pratik yol:

1. CSV içe/dışa aktarım (öğrenciler, roster, yoklama kayıtları) önce olsun. Test etmesi ve çalışması kolaydır.
2. Veri formatı stabil olduğunda SIS/LMS entegrasyonları veya tek yönlü senkron ekleyin.

Entegrasyonları isteğe bağlı yapın

Okullar çok farklıdır. Entegrasyonları ayarlar altında tutun; her okul neyi bağlayacağını, kimlerin açabileceğini ve hangi verinin hareket edeceğini seçsin. Varsayılanı “kapalı” yapın ve davranışı açıkça belgeleyin (örn. /privacy veya /settings gibi yerlerde) ki yöneticiler neyi açtıklarını bilsin.

Test Et, Pilot Yap, Ölç

Gerçek testler olmadan uygulamayı yayınlamak; kızgın öğretmenler, kafası karışık öğrenciler ve güvenilmez kayıtlar demektir. Hedef “mükemmel” değil—yoklama akışının hızlı, net ve savunulabilir veri ürettiğini kanıtlamaktır.

Arayüzden önce kuralları test edin

Yoklama çoğunlukla mantıktır: kim giriş yapabilir, ne zaman yapabilir ve iki kez denediğinde ne olur. Şunlar için birim testleri yazın:

• Zaman pencereleri (erken/geç kesmeleri, hoşgörü, zaman dilimi)
• Çoğaltma ve yeniden denemeler (idempotent istekler)
• İzinler (yanlış sınıf, yanlış rol, iptal edilmiş erişim)

Bu testler, manuel QA'da fark edilmeyen sessiz hataları engeller.

Gerçek koşullarda cihaz testi

Uygulama simulatörde geçse de sınıfta başarısız olabilir. Cihaz/OS matriksinde test edin, özellikle riskli donanım özelliklerine odaklanın:

• Kamera tarama hızı ve odak (çatlak ekranlar, düşük ışık, parlama)
• NFC güvenilirliği (farklı modeller, kılıflar anteni engelleyebilir)
• Düşük pil ve “güç tasarruf” modları arka plan işlerini kısıtlayabilir

Ayrıca zayıf bağlantı senaryolarını test edin: uçak modu, Wi‑Fi'den hücresel veriye geçiş ve captive portal'lar.

Bir sınıfla pilot yapın (izleyin, sadece sormayın)

Bir öğretmen ve bir sınıfla en az bir hafta pilot yürütün. Mümkünse ilk oturumları canlı gözlemleyin.

Geri bildirim toplayın:

• Hız: uygulamayı açmaktan onaya kadar geçen süre
• Açıklık: öğrencilerin bir sonraki adım için ne yapmaları gerektiğini ne kadar anladıkları
• Hata durumları: tarama çalışmadığında ne yaptıkları

Anında sorun raporu kolay olsun (ör. cihaz bilgisi ve zaman damgası içeren uygulama içi “Sorunu bildir”).

Suçlamadan ölçün

Güvenilir analitik kurun; teknik hataları gerçek devamsızlıklardan ayırın. Teknik olayları ayrı loglayın: “tarama başarısız”, “NFC okunamadı”, “GPS kullanılamıyor”, “çevrimdışı sıraya alındı”. Bu sayede “12 öğrenci devamsız mıydı yoksa projeksiyonda QR görünmedi mi?” sorularına yanıt bulursunuz.

Öğretmen odaklı metrikler yayınlarsanız, bunları eyleme dönüştürülebilir tutun: akışı yavaşlatan noktaları vurgulayın ve MVP'de ne düzeltileceğini gösterin.

Yayınlayın ve Zaman İçinde İyileştirin

Yoklama uygulamasını yayınlamak bir bitiş çizgisi değil—gerçek kullanımın size neyi düzeltmeniz, sadeleştirmeniz ve genişletmeniz gerektiğini öğrettiği başlangıçtır.

App Store ve Play Store temel hazırlıkları

Gönderimden önce temiz bir yayın paketi planlayın:

• Uygulama mağazası açıklaması: uygulamanın kime yönelik olduğunu (öğretmenler, öğrenciler, yöneticiler) net açıklayın
• Yüksek kaliteli ekran görüntüleri: yoklama akışını ve öğretmen görünümünü gösterin
• Gerçekte topladığınız verilerle eşleşen gizlilik açıklamaları (konum, cihaz tanımlayıcıları, öğrenci ID'leri vb.)

Kısa bir “Ne topluyoruz ve neden” sayfasını uygulama içinde bulundurmak yardımcı olur (ör. /privacy) ve mağaza açıklamalarında da aynı dili yansıtın.

Yönetici onboarding'ı hızlı (ve esnek) yapın

Benimseme sorunlarının çoğu kurulum sürtünmesiyle başlar. Yönetici onboarding'i şu adımları kapsamalı:

• Bir dönem ve sınıflar oluşturma
• Roster içe aktarma veya yapıştırma (CSV yükü genellikle yeterli)
• Öğretmen ve öğrencileri davet etme (e‑posta linki, kod veya varsa SSO)

Koruyucu önlemler ekleyin: yinelenen öğrencileri tespit edin, roster düzenlemelerini kolaylaştırın ve yeni yöneticilerin güvenle tıklayıp denemesi için bir “örnek sınıf” sunun.

Ekibi yormayan destek

Hafif bir destek planıyla başlayın:

• /help altında 10–15 yaygın soruyu kapsayan küçük bir yardım merkezi
• Uygulama içi iletişim formu, cihaz/uygulama sürümü ve sınıf ID'si ekli olsun
• Basit sorun giderme adımları (re-sync roster, sınıfa yeniden katıl, izinleri kontrol et)

Yayın sonrası yol haritası oluşturun

Geri bildirim + metrikleri önceliklendirmek için kullanın:

• Daha iyi raporlama (geç gelenler, eğilimler, dışa aktarımlar)
• Entegrasyonlar (SIS/LMS, Google Classroom, Microsoft 365)
• Ek yoklama yöntemleri (QR, NFC, coğrafi sınırlama veya öğretmen geçersiz kılma)

Küçük iyileştirmeleri düzenli yayınlayın ve değişiklikleri uygulama içinde sade bir dille bildirin.