Mobil uygulama mı, mobil site mi?

Mobil uygulama mı mobil site mi sorusu, tek bir ekranın ihtiyaç listesi yazılarak cevaplanır: listede web tarayıcısının karşılayamadığı bir madde varsa uygulama kurulur, yoksa kurulmaz. Karar şirket düzeyinde alınamaz, çünkü aynı işletmenin ziyaretçi ekranı, saha ekranı ve ofis paneli birbirine benzemeyen listeler taşır. KGM SsangYong showroom kioskunda cihazı işletme koyar; ziyaretçinin telefonuna indirilecek bir şey doğmaz.

Soru, yüzeyin neye muhtaç olduğu

“Size bir mobil uygulama yapalım” cümlesi bir ihtiyaç maddesine bağlanmıyorsa gerekçesizdir. Teklifi ölçmenin yolu da basit: uygulamanın yüzeyin ihtiyaç listesindeki hangi maddeyi karşıladığını ve o maddeyi web tarayıcısının neden karşılayamadığını sorun. Cevap bir madde adı değil de bir görünüm isteğiyse, karar henüz verilmemiş demektir. Mobil uygulama geliştiriyoruz ve bu yazının çoğu yüzey için verdiği cevap “gerekmez”.

Yüzeyleri ayırmak listeyi kısaltıyor. Yayın yüzeyi kâğıdın işini devralır: katalog, menü, kartvizit. Orada cihaz okuyucunundur, ekran her seferinde yeni bir kişiye açılır ve kurulum diye bir adım yoktur. İşleyen yüzey başkadır: giriş yapılır, kayıt tutulur, aynı ekranı her iş günü aynı kişi açar. Bu yazının konusu ikincisi.

Portföyümüzün zıt uçları aynı soruya karşıt cevap veriyor. Showroom kioskunda uygulama ziyaretçinin cihazına hiç girmiyor; işletmenin kendi cihazında çalışıyor. Şantiye giriş çıkış kaydı uygulamasında ise uygulama personelin telefonunda çalışıyor ve sahaya donanım kurulmuyor. Her biri kurulu bir uygulama, ama gerekçeleri aynı yerden gelmiyor. Aynı ürün adını taşıyorlar, aynı dağıtım kararını taşımıyorlar.

Karar biriminin neden şirket değil ekran olduğunu da söylemek gerekiyor. “Bizim bir uygulamaya ihtiyacımız var mı” sorusu cevaplanamaz, çünkü bir şirketin birden çok yüzeyi olur ve bunların ihtiyaç listeleri birbirine benzemez. Aynı işletmede ziyaretçinin gördüğü ekran, sahadaki personelin açtığı ekran ve ofisteki panel farklı listeler taşır. Soru ekran düzeyinde sorulduğunda cevap veriye dayanır; şirket düzeyinde sorulduğunda cevap eğilime dayanır.

Buradan çıkan ilk kural şu: işleyen yüzey tek başına uygulama gerekçesi değil. Her gün aynı kişinin açtığı bir ekran bile, ihtiyaç listesi web tarayıcısında karşılanıyorsa uygulama gerektirmez. Gerekçe listede duruyorsa uygulama gerekir; rakibin vitrininde duruyorsa gerekmez. Rakibin uygulaması sizin yüzeyinizin ihtiyaç listesini değiştirmiyor.

Web tarayıcısı ön planda ne veriyor: kamera, konum, izin

Konum tarafında dayanağı doğrudan söyleyebiliyoruz. Web platformunun kendi dokümantasyonu, konum arayüzü için şunu yazıyor: konum bilgisine yalnız güvenli bağlamda erişilir ve konum isteyen çağrı yapıldığında kullanıcının açık izni bir istem üzerinden alınır. Koşullar birlikte aranıyor: güvenli bağlantı ve kullanıcının o an verdiği izin. Aynı dokümantasyon bu arayüzü web tarayıcıları arasında yaygın biçimde kullanılabilir olarak işaretliyor.

Kamera tarafında mekanizma aynı biçimde işliyor. Sayfa görüntüyü kullanıcının izniyle alır ve görüntü sayfanın içinde kalır. QR kodun çözülmesi de sayfa içinde çalışan kodun işi: kamera görüntüsünden bir kod okumak, sayfanın kendi hesabıyla yaptığı bir iştir ve bunun için mağazadan inen bir uygulamaya ihtiyaç yoktur.

“Uygulama gibi görünsün” isteği de çoğu zaman bu bölümde konuşuluyor ve cevabı düz değil. Web tarafında bir manifest dosyasıyla simge tanımlanır ve sayfanın web tarayıcısı çerçevesi olmadan açılması istenir. Ama bunu belirleyen display alanı için platform dokümantasyonunun kendi değerlendirmesi açık: en çok kullanılan web tarayıcılarının bazılarında çalışmıyor. Kurulum isteminin kendiliğinden çıkması da platforma göre değişiyor. Yani görünüm isteği web tarafında kısmen karşılanıyor ve bu kısmilik demoda görünmüyor, kullanıcıların bir bölümünde görünüyor.

Bu bölümün asıl faydalı cümlesi izinle ilgili. Aynı dokümantasyon iznin ömrünü şöyle tanımlıyor: verilmiş bir iznin ömrü kullanılan web tarayıcısına bağlıdır ve süreyle sınırlı, oturumla sınırlı ya da kalıcı olabilir. Bu, yeteneğin varlığını değiştirmiyor; kullanımın sürtünmesini değiştiriyor. Günde birkaç kez açılan bir ekranda “izin ver” adımının her seferinde yeniden gelmesi, ekranın işlevinden bağımsız bir yük. Ekran ayda bir açılıyorsa aynı yük fark edilmez bile.

Kendi portföyümüzde bunun açık bir örneği var. Şantiye giriş çıkış kaydı uygulamasının dayandığı yetenekler tam bu ön plan sınıfında: kamerayla kod okutmak ve giriş anında konumu kayda yazmak. Kimliğin QR koddan, sahanın konumdan doğrulandığı kayıt mekanizmasını ayrı bir yazıda anlattık. Burada önemli olan sonuç şu: o işte kararı yetenek listesi tek başına vermedi. Uygulama, web tarayıcısının yapamadığı bir şey için kurulmadı. Gerekçe başka bir eksende duruyor; onu aşağıda, cihazın kimde olduğunu konuştuğumuz bölümde açıyoruz.

Web tarayıcısının vermediği yetenekler platforma göre de değişir

Bu sınıftaki maddelerde cevap “hayır” değil, “platforma göre değişir”. Arama sonuçlarının ilk sayfasındaki “çevrimdışı çalışır ve bildirim gönderir” genellemesi tam burada kırılıyor: genelleme yanlış olduğu için değil, tek cevaplı olduğu için.

Bildirimle başlayalım. Web bildiriminin mekanizması dokümante edilmiş durumda: bir uygulamanın bildirim alabilmesi için etkin bir service worker’ı olması gerekiyor ve gelen bildirimi karşılamak üzere bu service worker gerektiğinde başlatılıyor. Yani sayfanın o anda açık durması şart değil. Teslimin kendisi ise platformun bildirim servisinden geçiyor ve desteğin kapsamı platformdan platforma değişiyor. Güvenilirlik bir gereksinimse, bu değişkenlik tek başına bir risk kalemi. Bildirim gitmediğinde kimse bunu size bildirmez; eksik olan şey görünmez.

Tahlil.com’un hasta uygulamasının ihtiyacı tam bu sınıfta duruyor: yorum onaylandığında hastayı sonuca geri çağırmak. Yorumun ne zaman hazır sayıldığını belirleyen kuyruk mekanizmasını ayrı bir yazıda açtık. Buradaki iş yalnız ihtiyacı sınıfına yerleştirmek: geri çağırmanın güvenilir olması bir gereksinimdi ve gereksinim listeye o şekilde yazıldı.

Uygulama açık değilken konum aynı listede duruyor, ama onu daha dar yazmak zorundayız. Doğrulayabildiğimiz şey olumlu koşul: sayfa ön plandayken ve izinle konum veriliyor. Sayfa arka plandayken ne olduğunu bu yazının dayandığı kaynaklar tanımlamıyor; kaynağı olmayan bir cümleyi de kurmuyoruz. Portföyümüzde bu ihtiyaca dayanan bir iş de yok, tabloda o satırın vaka hücresi boş kalıyor.

Kaydın cihazda kaybolmadan beklemesi de bu sınıfta. Bağlantı yokken alınan kaydın sonradan nasıl gönderildiği ayrı bir tasarım işi ve aşağıdaki tabloda tek satır olarak duruyor.

Bu sınıfın hiçbir maddesi tek başına “uygulama şart” demiyor. Madde sizin yüzeyinizin listesinde yoksa, bu bölümün tamamı sizi ilgilendirmiyor. Listede varsa karar tek soruya iniyor: bu değişkenlik sizin işinizde kabul edilebilir mi?

Uygulama mağazasına girmek bir dağıtım kararıdır

Uygulama mağazası bir yetenek değil, bir dağıtım kanalı. Kanalın bedeli de yayın tarafında ödeniyor. Bu ayrımı karar masasında kimse yapmıyor, çünkü bedel ilk sürümde görünmüyor.

Web’de yayın tek noktalı. Yeni sürüm sunucuya çıkar; kullanıcı sayfayı sonraki açışında onu görür. Cihazda kalan bir kopya olmadığı için “kim hangi sürümde” diye bir soru da doğmaz. Karşılaştırmanın sıfır noktası burası.

Mağaza uygulamasında sürüm cihaza iner ve cihazda kalır. Bu tek cümlenin sonuçları şöyle. Birincisi, yayınladığınız sürüm ile kullanıcının çalıştırdığı sürüm ayrı şeylerdir; aradaki mesafeyi tek başınıza belirlemiyorsunuz. İkincisi, kullanımda kalan her sürüm sunucunuza istek atmaya devam eder. Sunucu tarafındaki sözleşme, kullanımdaki eski sürümleri taşımak zorunda kalır; yani bakım yükü dağıtım kanalında değil, sizin tarafınızda birikir. Üçüncüsü, kullanımdaki sürümü tek noktaya çekmek istiyorsanız bunu uygulamanın kendi içinde bir kontrol olarak kurarsınız. Bu ayrı bir geliştirme kalemi ve her sürümde yaşamaya devam eder.

Aynı fark hata anında büyüyor. Web’de kırık bir sürüm sunucuda geri alınır ve bir sonraki açılışta kimse onu görmez; hatanın ömrü sizin tepki sürenizle sınırlı. Cihaza inmiş bir sürümde geri alma kararı, cihazdaki kopyayı geri getirmiyor. Kırık sürüm kullanıcıların telefonunda kalmaya devam ediyor ve sunucu tarafı onu da beslemek zorunda. Bu yüzden mağaza uygulamasında test yükü web’e göre daha erken ve daha ağır oturuyor.

Portföyden somut karşılığı Tahlil.com’da duruyor: hasta uygulaması tek kod tabanından iki mağazaya çıkıyor. Tek kod tabanı geliştirme tarafını teke indiriyor, dağıtım tarafını teke indirmiyor. Aynı düzeltme her yayında kanalların hepsinden ayrı ayrı geçiyor ve bu yük ürünün ömrü boyunca ödeniyor.

Bu bölüm mağaza aleyhine bir liste değil. Dağıtım kanalının bedeli, karşılığında alınan bir yetenek varsa ödenmeye değer; Tahlil.com’da ödendi. Ödenmeye değmeyen tek durum, bedelin karşılıksız kalması.

Cihazı işletme mi koyuyor, çalışan mı taşıyor

Yetenek listesi kararı vermediğinde soruyu değiştirmek gerekiyor: cihaz kimin?

Showroom kiosku bu sorunun en net cevabı. Cihazı işletme koyuyor. Ziyaretçi kendi telefonuna bir şey indirmiyor, bir adres yazmıyor, bir izin ekranıyla karşılaşmıyor; ekran zaten önünde duruyor ve açık. Ziyaretçinin web tarayıcısı da uygulama mağazası da denklemde yok. Basılı kataloğu yazılıma taşırken indirme adımının neden bir eşik olduğunu ayrı bir yazıda tarttık; kioskta o eşik hiç doğmuyor. Dağıtım burada bir cihaz yönetimi işine dönüşüyor. Uygulamanın işletmenin kendi cihazına hangi kanaldan indiği proje kaydımızda yazılı değil, biz de bu konuda bir şey iddia etmiyoruz.

Zıt uç şantiye. Cihazı çalışan taşıyor, sahaya donanım kurulmuyor.

Asıl soru burada: yetenekler ön plan sınıfındaysa neden bir web tarayıcısı sayfası değil de kurulu uygulama? Cevap yetenek değil, kalıcılık. İznin ömrü web tarafında web tarayıcısına bağlı ve oturumla sınırlı kalabiliyor; her iş günü aynı ekranı açan bir çalışan için bu, her açılışta yeniden karşılaşılabilecek bir adım. Oturum ve kimlik web tarafında web tarayıcısının veri alanında duruyor; o alan temizlendiğinde oturum da gidiyor. Açılış yolu da farklı: kurulu uygulamada simge, web tarafında adres. Sahadaki bir kişi için adres yazmak günün ilk sürtünmesi olur.

Bunu o projede alınmış kararın gerekçesi diye sunmuyoruz; proje kaydında böyle bir karşılaştırma yazılı değil. Aynı soruyu bugün soran biri için bir muhakeme olarak duruyor.

Kural şu uçlardan çıkıyor. Cihaz işletmenin ise dağıtım bir cihaz yönetimi işi ve ziyaretçinin uygulama mağazası denklemde yok. Cihaz çalışanın ise dağıtım kanalı ne olursa olsun bakım her sürümde ödeniyor; kalıcılık kazancı bu ödemeyi karşılıyorsa uygulama yerinde. Cihaz ziyaretçinin ise yayın yüzeyi web tarayıcısında kalıyor, çünkü kurulum orada en pahalı adım.

Karşı durum da var. Cihaz çalışanın ama yüzey seyrek açılıyorsa kalıcılığın kazancı küçülüyor. Ayda birkaç kez açılan bir ekran için adresle açılan bir sayfa yeter ve dağıtım döngüsü satın alınmaz.

Yüzeyin ihtiyacı satır satır

Aşağıdaki tabloyu kendi yüzeyinize tutun ve satırları işaretleyin. Tablonun asıl bilgisi boş bıraktığı hücrelerde duruyor.

Boş bıraktığımız satırlarda portföyümüzde bu ihtiyaca dayanan bir iş yok; satırı doldurmak için de vaka uydurmuyoruz. Her satıra bir proje koyan bir tablo, satırı projeye göre eğdiğini gösterir.

Tablonun okunma yönü de önemli. İkinci sütunda “karşılanır” yazan bir satır uygulama tartışmasını kapatıyor. “Platforma göre değişir” yazan bir satır tartışmayı açıyor ama tek başına kapatmıyor: karar, o değişkenliğin sizin yüzeyinizde kabul edilebilir olup olmamasına bakıyor. “Kısmen” yazan satır ise en yanıltıcı olanı, çünkü demoda çalışıyor gibi görünüp kullanıcıların bir kısmında sessizce farklı davranıyor.

Web tarayıcısının gördüğü işi uygulamaya taşımak bedelini her sürümde öder

İhtiyaç listesi web tarayıcısında karşılanan bir yüzeyi mağaza uygulamasına taşımak, karşılığında hiçbir yetenek almadan şu kalemleri satın almaktır: dağıtım döngüsü, yayınlanan sürümle kullanılan sürüm arasındaki mesafe, sunucunun kullanımdaki eski sürümleri taşıma yükü ve kullanıcının kurulum adımı.

Tahlil.com bunu yapmadı. Değerlerin girildiği yer web sitesi olarak kaldı; hesaplayıcı, platforma randevusuz bir giriş kapısı açıyor ve o kapı adresle ve aramayla ulaşılan, kurulum istemeyen bir yüzey. Bu türden bir yüzeyin web tarafında nasıl kurulduğunu hizmet sayfasında anlatıyoruz. Hasta uygulaması yalnız web tarayıcısının garanti edemediği tek ihtiyaç için kuruldu ve sitenin gördüğü işi devralmadı.

Devralmamasının teknik karşılığı da var. Web sitesi, hekim paneli ve hasta uygulaması aynı çekirdeğe bağlı. Kaç yüzeyin aynı çekirdeği dinleyeceğinin koddan önce verilen bir karar olduğunu ayrı bir yazıda anlattık. Buradaki sonuç şu: yeni bir yüzey eklemek, var olan yüzeyi emekliye ayırmak anlamına gelmiyor. Yüzeyler aynı çekirdeği dinlediği sürece her biri kendi işini görmeye devam ediyor.

Ters yönde de bir bedel var. Yüzeyinizin ihtiyacı platforma göre değişen sınıftaysa, web tarafında ısrar etmek ihtiyacı karşılamaz. Bildirimin güvenilir olması gerekiyorsa “platforma göre değişir” bir cevap değil, bir risk. O durumda uygulama kurulur ve dağıtım döngüsü bilerek satın alınır.

Kapanış sorusu size ait: yüzeyinizin ihtiyaç listesinde web tarayıcısının karşılamadığı bir madde var mı, varsa hangisi? Cevabınız bir madde adıysa, bağlantı kesildiğinde de kayıt almaya devam eden saha uygulamalarını anlattığımız sayfa tam o sınıfı tarif ediyor. Cevabınız “yok” ise elinizdeki site zaten yüzeyin işini görüyor ve teklif masasında konuşulacak şey uygulama değil, o sitenin eksik kalan tarafı.