Form alanlarını uçuran bug

[ghost]

Doğum tarihi seçilmiş olmasına rağmen kaydet tıklandığında takvimi açıyor (doğum tarihi kaydedilmemiş gördüğü için). Bu adımda tekrar doğum tarihi seçince kaydediyor. Hem öğretmen hem de öğrenci açarken karşılaştım bununla.

[ghost]

Added ~1 label

[ghost]

Added ~9 label

[ghost]

Bu cok acaip bir sey.

benim bu sorunla hic karsilasmamis olma sebebim formlari hizli hizli doldurmam.

yaklasik 1bucuk dakikada bir tarih secim alani kendi kendine siliniyor (yalnizca yeni ekleme formunda)

kaynagini da buldum. ama bu kaynak nasil buna sebep oluyor anlamadim.

ama cok sacma. cok cok sacma.

dun yaklasik 7 saatim gitti buna, acikcasi tum sistemin en merkezindeki accounts modulu uzerinde sorun yarattigi icin bunu cozmeden veya yan etkilerini ve baska nelere dokundugunu tam olarak belirlemeden ilerlemek istemiyorum.

haber verecegim.

not (buna ayirdigim mesaiyi yazmiyorum, takildim ve cok genel bir durum bu benim icin, beni baska projelerde de etkileyebilecek bir sey)

[ghost]

Added ~3 ~2 labels

[ghost]

Sorularda girdiğim şıkların kaybolması sorunu da bununla ilgili olabilir...

[ghost]

bir iki deneme yapabilir misin,

a) formu doldurup kaydete basmadan bekle b) formu doldur ama tepelerden sorunsuz baska bir sahayi eksik birak, kaydete bas

her iki durumda da zaman tut lutfen

tesekkurler

[ghost]

a) Bir soru formu doldurdum. 6 şıklı bir çoktan çok seçmeli soru. Tüm formu doldurdum kaydete basmadan bekledim. Yaklaşık 2 dak 30 sn sonra eklediğim 4 şık kayboldu.

b) Formu doldurup yukarıda bir sahayı eksik bırakınca uyarı veriyor. İlgili sahayı doldurunca sorunsuz kaydediyor. Şıklar kaybolmadı.

[ghost]

Ok meseleyi tam olarak tespit ettim. 140 karaktere sigdiramiyorum ama lutfen okuyunuz, bir karar vermek gerekecek cunku.

Oncelikle iyi haber; sinir bozucu olmak disinda bir yan etki yok.

Mevcut veride kayba sebep olmuyor.

Yeni data girerken ortalama 1.5 dakikada bir kullanicinin guvenligine (terkedilmis sessionlarin temizligi ile ilgili) iliskin calisan bazi otomatik islemlerden baslayan bir olaylar silsilesi aktif formu olusturan kutuphanedeki cok sinsi bir bug ile elele vererek cogunlukla tarih ve satir eklemeli sahalardaki sonradan eklenen bilgileri siliyor, cok cok seyrek de olsa arada (yine sonradan girilmis) baska satirlar silinebiliyor.

Bununla ilgili talep actim. Kutuphane seviyesinde giderilirse ne ala.

bunu biz actik:

• https://github.com/aldeed/meteor-autoform/issues/1281

bunlar da kismen ilgili:

• https://github.com/aldeed/meteor-autoform/issues/1251
• https://github.com/aldeed/meteor-autoform/issues/1278

Ancak, eger biz yok bunu illa biz cozelim ve/ya canli kullanima gecisi beklemeden halledelim dersek

Bu bug, kutuphanenin isimizi en cok kolaylastiran ozelliginde ortaya ciktigi icin, arkasindan dolasmak demek bu ozellikten feragat edip daha cok kod yazmak demek.

Bu ozellik de su.

Ben data modelimizi tanimlarken, direkt olarak modelin uzerine, o sahanin ekranda bir formda gorundug zaman birim ozelliklerinin ne olmasi gerektigini tanimliyorum. Misal bir date picker, veya multiple satir eklenen text fieldlar vb gibi.

Kutuphanenin QUICKFORM denen bir bileseni, bu tanimlamalari alip yukaridan asagiya bu sahalari benim tanimladigim icerige uygun diziyor.

Bu da su demek, uzun uzun mesakkatli html formlari (birkac bin satir) 20 satirda cozuyorum.

Hani formlarla ilgili basindan beri soyledigim bir sey var

Su an gordugunuz formlar benim icin ilk versiyon, hele ki sahalarimizin tum icerikleri kesinlessin, hangi formlar onemli, hangilerinin kullanimi zor, hangileri musteriye donuk, hangilerinin veri olarak iceriginde degisiklikler istenecek vb bakalim, ona gore gereken formlari tek tek ele aliriz

Iste bu ele alma dedigim sey, quickform'u (mevcut kodun uzerine insa edilen) custom bir form'a cevirme isi. Bunu yapinca, buradaki bug da temizleniyor. Ama dedigim gibi, bu sekilde custom form duzenlemek hem vakit aliyor hem de kodu buyuttugu icin ileride bir degisiklik istendiginde yapilmasi gereken birim isi artiriyor. Quickform'un bize bugune kadar kazandirdigi neresinden baksaniz 50+ saattir ki ileri donuk bakim/tamir tasarrufunu katmiyorum buna.

Ben derim ki simdilik bekleyelim. Hele ki pilot kullanimlardan gelen geri beslemeler ile basta veri modeliyle ilgili potansiyel degisiklikleri bir gorelim.

[ghost]

mentioned in issue #81

[ghost]

Title changed from Kullanıcı tanımlamada doğum tarihi seçimi to Form alanlarını uçuran bug

[ghost]

1. Çok can sıkıcı. Bunun developer tarafından ele alınıp alınmayacağı ile ilgili bir fikrin var mı? Verdiğin rapor örneklerinden birisi 20 gün önce açılmış.
2. Pilot aşamasında okullara "alın buradan test içeriklerinizi girin" dediğimizde "ama işinizi 1.5 dakikada bitirin yoksa girdiklerinizin bir kısmı silinebilir" mi diyeceğiz? Bunun tek çözümü pilot sırasında içerikleri bize vermeleri ve bizim girmemiz olabilir. Ama bu sefer de öğretmen kullanımını test edemeyiz.
3. Formların saha ekleme tarafının "user friendly" olmadığını zaten başından beri görüyoruz ve ifade ediyoruz. Eklenen satırın aşağıda kalması, içiçe geçen alanların yarattığı görsel karmaşa vs. Aynı feedback öğretmenlerden de gelecektir eminim. Pilotu öğretmenlerin önüne koymadan buna zaten el atmamız gerektiği konusunda mutabık kalmıştık.

Sonuç olarak ben pilot uygulamaya bu bug ve 3. maddede belirttiğim "user unfriendly" yapıyla başlayabileceğimizi öngöremiyorum. Diğer yandan başta öngördüğümüz bütçe sınırına dayanmaya başladığımız da ortada. Bu bug sorununun etrafından dolanacak ve aynı zamanda form yapısını bir parça daha kullanılabilir hale getirebilecek bir çözüm üretebilir miyiz? Örneğin sorularda sabit 5 seçenek alanını baştan tanımlasak bunlar doldurulduğunda aynı durum ortaya çıkacak mı? Çünkü sonradan eklenen alanlar kayboluyor ama başta gelen ilk iki seçenek alanı kaybolmuyor diye görüyorum. Seçenek sayısını sabitlemek formu daha kolay veri girilebilir bir düzene kavuşturmakta da yardımcı olacaktır. Elbette burada önemli bir esneklikten vazgeçiyoruz ama senin de dediğin gibi, diğer usability konuları ortaya çıktıktan sonra bu durumu tekrar ele almak üzere.

Müfredat ve kullanıcı girişi tarafında bu bug ve format sorununu bir şekilde bir süre için tolere edebiliriz diye düşünüyorum çünkü muhtemelen bu veri girişlerini okul değil Mitolojix yapacak (en azından pilot aşamasında). Müfredat girerken dakika başı "kaydet" diyeceğiz artık çaresiz...

@birol ?

[ghost]

Selam,

Kusura bakmayin, 15 saat tek bir bug'in tespiti icin ugrasmanin kafa bulanikligi ve kisa yazamama sorunu birlesince hem eksik bilgi vermis hem de karamsar bir cikarim yapmisim. Soyle duzeltelim:

1) Son derece advanced bir kullanim seklinde son derece sinsi ortaya cikmis bir sey oldugundan bu bug report'un dogrudan bir yanit almasi ve kapanmasi birkac ayi bulabilir. Ama bu bug'in arkasindan dolanmaya iliskin bir yontem kisa surede su yuzune cikacaktir. Bu kutuphane projelerinin developerlarinin private chatroom'lari var (ben de dahilim) ve bu report birkac gun icinde konusulmaya ve oneriler gelmeye baslar.

2) Tabi bir de meselenin bu 1-1.5 dakika boyutu var. O sureyle de eminim oynanabiliyordur.

3) Formlarin bu haliyle idealden uzak olduguna hep katildim. (Adi uzerinde "quick"form) Ama pilot oncesi formlari ellemeye hic katilmadim cunku pilotta zaten "icerik olarak" talepler gelecek ve mesai optimizasyonu acisindan bu formlara a) bu talepleri aldiktan sonra dokunmak ve b) sadece musterinin kullandiklarina dokunmak yontemini halen savunuyorum.

Bu bug sorununun etrafından dolanacak ve aynı zamanda form yapısını bir parça daha kullanılabilir hale getirebilecek bir çözüm üretebilir miyiz?

Tabii ki evet. Sadece, bugun itibariyle eforumu oyun arayuzune yonlendirmek istiyorum.

Örneğin sorularda sabit 5 seçenek alanını baştan tanımlasak bunlar doldurulduğunda aynı durum ortaya çıkacak mı?

Bence akillica bir oneri. Yalniz soyle bir kisitlama var. Basta kac secenek geliyorsa, onun altina inemiyoruz. Su an 2 ile baslama sebebi de bu. Min 2 oldugu icin iki tane hazir geliyor. Ama 2-3-4 gibi seceneklere musaadee edebilmek icin min 5 degil min 2 yapmistim.

Seçenek sayısını sabitlemek formu daha kolay veri girilebilir bir düzene kavuşturmakta da yardımcı olacaktır. Elbette burada önemli bir esneklikten vazgeçiyoruz ama senin de dediğin gibi, diğer usability konuları ortaya çıktıktan sonra bu durumu tekrar ele almak üzere.

Bu da olabilir. "Simdilik 5 secenek sabit ama bunu esnek hale getirecegiz" denebilir musteriye. Ama bence yukarida (1) altinda acikladigim uzere birkac gun bekleyelim. Muhtemelen daha teknik, dogrudan bug uzerinde bir workaround ortaya cikar.

Müfredat ve kullanıcı girişi tarafında bu bug ve format sorununu bir şekilde bir süre için tolere edebiliriz diye düşünüyorum çünkü muhtemelen bu veri girişlerini okul değil Mitolojix yapacak (en azından pilot aşamasında).

Buna zaten genel olarak tam katiliyorum. Sadece musteriye donuk olan ekranlarda usability hedeflerimizi belirleyelim.

Sunu da tekrar eklemek isterim, bu spefisifik form konusu bir kenarda dursun, usability benim icin son derece onemli bir konu. Hatta kendi fikirlerimi degil, celisse bile standartlar olarak ortaya koyulmus ne varsa onlari savundugum bir konu. Ama bu form meselesi zaten degismesini bekledigim ve mesai anlaminda geriye donuk revizyon kaybini minimum tutmak istedigim cok temel bir mesele oldugundan burada onceligi mesaiyi dusuk tutmaya vermeye gayret ediyorum hep. quickform denen zimbirti bize toplamda %10-15 tasarruf saglayan ciddi bir silah.

[ghost]

@mitolojix, Kavacık'taki toplantımızda bize gösterdiğin veritabanındaki değişiklikleri kullanıcıya push eden bir mekanizma vardı ya... Bu hata onun eseri sanıyorum. Bu kütüphanede o özelliği devre dışı bırakabiliyor musun? Şimdilik bizim sorunumuza çare olabilir.

[ghost]

Quickform'lar yerine özel formlar tasarlamaktan ziyade, Quickform'ları daha kullanışlı hale getirmek lazım. Diğer Meteor geliştiricileri Quickform'dan çok mu memnunlar? Bu konuda bir iyileştirme talep etmiyorlar mı?

[ghost]

Bu hata onun eseri sanıyorum.

Yok tamamen alakasiz. Formun hangi sahalarinin ekrana getirilmeyecegine karar veren bir mekanizmanin calisma sistemindeki bir eksiklikle alakasi var.

Diğer Meteor geliştiricileri Quickform'dan çok mu memnunlar?

Memnun olmamalari icin bir sebep yok. Ben de cok memnunum. Burada yakalandigimiz bug disinda kullanislilikla ilgili meselede sorun quickform degil, sorun formlardaki sahalarin ekrana nasil dizilecegine karar verecek bir mekanizma olmamasi. Bu mekanizmanin adi HTML. Yani tum internetin uzerine oturdugu sey. Hicbir kutuphane de bunu tek satirda cozemez, teorik olarak bile mumkun degil. O yuzden quickform'un "tasarimsal/yerlesim" olarak yetmedigi yerlerde formlarin icerigini (yari) manuel kurguluyorsun, yine bu kutuphanenin pek cok baska ozelliginden destek alarak. Ha HTML ile ilgili ciddi bir memnuniyetsizlik var. Bunun icin ayri kutuphaneler gelistiriliyor, en one cikanlardan biri REACT (javascript'in yeni versiyonu ES2015 ile birlestiginde cok kuvvetli bir arac), digeri POLYMER. Ilki biz bu uygulamaya basladigimizda henuz kullanilabilir bir release cikartmamisti, ikincisi ise cok yayginlasamadi. Ilki ile ilgili olarak da bir gecis yapabilecegimiz ilk noktada (sanirim haziran ayiydi) duralim bana ek 2 hafta mesai izni verin mevcut kodu yeni yapiya tasiyayim oradan ilerleyelim demistim ama nasilsa bu sadece bir prototip diyerek kabul etmemistiniz :)

[ghost]

birol bu sen misin :)

Bu mesele simdilik cozuldu. Teknik olarak istedigim kalitede degil, ama bunu herhalde benden baska da kimse gormez.

Siz yine de tekrar bir bakin.

Yalniz temiz veriyle test etmek gerekiyor, uzgunum veritabanini resetlemek zorunda kaldim :(