Zindora

Neden yaptık

Spor salonlarının işletme yükü üyelik takibinde toplanır: kim hangi pakette, ne zaman bitiyor, derse kaç kişi geldi, yenileme konuşması ne zaman yapılmalı.

Bu takip çoğu salonda tabloyla ya da defterle yürür. İki şube olduğunda sistem dağılır.

Zindora'yı üyelik, paket, ders ve eğitmen yönetimini tek yerde toplamak için geliştirdik.

Ölü düğme sessiz bir hatadır

Geliştirme ilerledikçe 113 ekranlık bir yüzey oluştu. Mağaza incelemesine hazırlanırken tüm ekranları tek tek denetledik.

Ortaya çıkan tablo öğreticiydi: 14 düğme hiçbir yere gitmiyordu. Tasarımda vardılar, kodda karşılıkları yoktu ve basıldığında hiçbir şey olmuyordu. Hata mesajı da yoktu.

Bu, mağaza incelemelerinde en sık karşılaşılan ret sebeplerinden biridir. İnceleyen kişi uygulamayı tamamlanmamış sayar ve haklıdır.

Ölü düğmeleri kaldırmak ya da işlevlendirmek, gönderim öncesi kontrol listemizin sabit maddesi oldu.

Görsel port yeterli değil

Bu üründe öğrendiğimiz en genellenebilir ders şuydu: bir tasarımın ekrana birebir taşınmış olması, ekranın çalıştığı anlamına gelmiyor.

Yan yana karşılaştırma "aynı" der. Sayfa açılır, görüntü doğrudur, hiçbir hata çıkmaz. Ama giriş alanı yazı kabul etmiyor, düğme bir yere gitmiyor ya da form boş gönderiliyor olabilir.

Bugün her tasarım portundan sonra ekranları görsel benzerlik için değil etkileşim bütünlüğü için ayrıca denetliyoruz: her düğme bir yere gidiyor mu, her form gerçekten kaydediyor mu, her bağlantı var olan bir sayfaya çıkıyor mu?

Mağaza süreci takvimin parçası

Uygulamanın hazır olması yayına girmesi için yeterli değil. Her iki mağazanın da kendi hazırlık ve test gereksinimleri var ve bunlar takvimde gerçek süre tutar.

Bu süreleri artık projenin başında planlıyoruz; sonradan keşfedilen bir mağaza şartı, hazır bir uygulamayı haftalarca bekletebiliyor.