Dokunma ve fare

İlk kez beraber tekrar

Chris Wilson

Paul Kinlan

Giriş

Yaklaşık otuz yıldır, masaüstü bilgisayar deneyimleri, ana kullanıcı giriş cihazlarımız olarak klavye ve fare ya da izleme yüzeyi etrafında şekilleniyor. Ancak son on yılda akıllı telefonlar ve tabletler, yeni bir etkileşim paradigması olan dokunma kavramını beraberinde getirdi. Dokunmatik özellikli Windows 8 makinelerin kullanıma sunulmasıyla ve şimdi de dokunmatik özellikli harika Chromebook Pixel'in piyasaya sürülmesiyle birlikte dokunmatik, beklenen masaüstü deneyiminin bir parçası haline geliyor. En büyük zorluklardan biri, yalnızca dokunmatik cihazlarda ve fare cihazlarında değil, kullanıcının her iki giriş yöntemini (bazen aynı anda) kullandığı bu cihazlarda da çalışan deneyimler oluşturmaktır.

Bu makale, dokunma özelliklerinin tarayıcıya nasıl dahil edildiğini, bu yeni arayüz mekanizmasını mevcut uygulamalarınıza nasıl entegre edebileceğinizi ve dokunma işlevinin fare girdisiyle nasıl güzel bir şekilde oynatılabileceğini anlamanıza yardımcı olacaktır.

Web Platformunda Dokunma Durumu

iPhone, web tarayıcısında yerleşik olarak bulunan özel dokunma API'lerine sahip olan ilk popüler platformdur. Diğer birkaç tarayıcı tedarikçisi de iOS uygulamasıyla uyumlu olacak şekilde oluşturulmuş benzer API arayüzleri geliştirmiştir. Bu arayüz, artık "Dokunma Etkinlikleri sürüm 1" spesifikasyonunda açıklanmıştır. Dokunma etkinlikleri, masaüstünde Chrome ve Firefox, iOS ve Chrome'da Safari ve Android'de Android tarayıcı ile Blackberry tarayıcısı gibi diğer mobil tarayıcılar tarafından desteklenir.

İş arkadaşım Boris Smus, Touch etkinlikleri hakkında harika bir HTML5Rocks eğiticisi yazdı. Touch etkinliklerine daha önce bakmadıysanız bu yine de iyi bir yol olacaktır. Hatta, daha önce dokunma etkinlikleriyle çalışmadıysanız devam etmeden önce şimdi bu makaleyi okuyun. Devam edin, bekliyorum.

Hepsi bitti mi? Artık dokunma olaylarının temelini atmış olduğunuza göre, dokunmatik etkileşimleri yazmanın zorluğu, dokunma etkileşimlerinin fare (ve fare emülasyonu yapan izleme yüzeyi ve iztopu) etkinliklerinden oldukça farklı olabilmesidir. Dokunmatik arayüzler genellikle fareleri emüle etmeye çalışsa da, bu emülasyon mükemmel ya da eksiksiz değildir. Her iki etkileşim stilini de ayrı ayrı desteklemeniz gerekebilir. Her iki etkileşim stilini de desteklemeniz gerekebilir.

En Önemli: Kullanıcının Dokunması ve Faresi Olması

Birçok geliştirici, bir ortamın dokunma etkinliklerini destekleyip desteklemediğini statik olarak algılayan siteler oluşturmuştur ve sonra sadece dokunma etkinliklerini (fare ile değil) desteklemeleri gerektiğini varsayarlar. Bu, artık hatalı bir varsayımdır. Dokunma etkinliklerinin olması kullanıcının öncelikle söz konusu dokunmatik giriş cihazını kullandığı anlamına gelmez. Chromebook Pixel ve bazı Windows 8 dizüstü bilgisayarlar gibi cihazlar artık hem Fare hem de Dokunma giriş yöntemlerini desteklemektedir ve yakın gelecekte daha birçok yöntem de desteklenecektir. Bu cihazlarda, kullanıcıların uygulamalarla etkileşimde bulunmak için hem fareyi hem de dokunmatik ekranı kullanmaları son derece doğaldır. Yani, "dokunmayı destekler" ifadesi, "fare desteğine ihtiyaç duymaz"dan farklıdır. Sorunu "İki farklı etkileşim stili yazmam ve bunlar arasında geçiş yapmam gerekiyor" şeklinde düşünemezsiniz. Her iki etkileşimin birbirinden bağımsız olarak birlikte nasıl çalışacağını da düşünmeniz gerekir. Chromebook Pixel'imde dokunmatik yüzeyi sık sık kullanıyorum ancak ellerimden uzanıp ekrana dokunuyorum. Aynı uygulamada veya sayfada o anda en doğal gelen şeyi yapıyorum. Diğer yandan, dokunmatik ekranlı bazı dizüstü bilgisayar kullanıcıları, dokunmatik ekranı hiç kullanmadıkları takdirde nadiren kullanılırlar; bu nedenle, dokunmatik girişin varlığı fare kontrolünü devre dışı bırakmamalı veya engellememelidir.

Ne yazık ki, kullanıcının tarayıcı ortamının dokunmatik girişi destekleyip desteklemediğini bilmek zor olabilir.İdeal olarak, bir masaüstü bilgisayardaki tarayıcı dokunmatik etkinlikleri desteklediğini gösterir ve böylece her an bir dokunmatik ekran takılabilir (ör. bir KVM üzerinden takılan dokunmatik ekran kullanılabilir hale gelirse). Tüm bu nedenlerle, uygulamalarınız dokunma ve fare arasında geçiş yapmaya çalışmamalıdır; yalnızca her ikisini de destekleyin!

Fare ve Dokunma özelliğini destekleme

1. Tıkla ve Hafifçe Vurma - Nesnelerin "Doğal" Sırası

İlk sorun, dokunma arayüzlerinin tipik olarak fare tıklamalarının benzetimini yapmaya çalışmasıdır. Dokunma arayüzlerinin daha önce yalnızca fare etkinlikleriyle etkileşimde bulunmuş uygulamalarda çalışması gerektiğinden, dokunuş arayüzlerinin genellikle fare tıklamaları benzetimi yapmaya çalışmasıdır! Kullanıcı ister fareyle tıklasın ister parmağını ekrana dokunsun, "tıklama" etkinlikleri tetiklenmeye devam edeceğinden bunu kısayol olarak kullanabilirsiniz. Ancak, bu kısayolla ilgili birkaç sorun var.

Öncelikle, daha gelişmiş dokunma etkileşimleri tasarlarken dikkatli olmanız gerekir: Kullanıcı fare kullandığında bir tıklama etkinliği üzerinden yanıt verir, ancak kullanıcı ekrana dokunduğunda hem dokunma hem de tıklama etkinlikleri gerçekleşir. Tek bir tıklama için etkinliklerin sırası şu şekildedir:

1. dokunma başlangıcı
2. Touchmove
3. dokunmatik uç
4. fareyle üzerine gelme
5. mousemove
6. fareyi aşağı çekme
7. fareyi yukarı çekme
8. click

Bu, elbette, dokunarak başlatma gibi dokunma etkinliklerini işliyorsanız, ilgili fareyle üzerine gelme ve/veya tıklama etkinliğini de işlemediğinizden emin olmanız gerektiği anlamına gelir. Dokunma etkinliklerini iptal edebilirseniz (etkinlik işleyicinin içinde preventDefault() çağırın) dokunma için herhangi bir fare etkinliği oluşturulmaz. Dokunma işleyicilerin en önemli kurallarından biri şudur:

Bununla birlikte, bu durumda diğer varsayılan tarayıcı davranışları da (kaydırma gibi) engellenir. Ancak genelde dokunma etkinliğini tamamen işleyicinizde gerçekleştirdiğiniz için varsayılan işlemleri devre dışı bırakmak İSTEDİĞİNİZ olur. Genel olarak, tüm dokunma etkinliklerini ele alıp iptal etmek istersiniz veya söz konusu etkinlik için bir işleyici kullanmaktan kaçının.

İkinci olarak, kullanıcı bir mobil cihaz üzerinde web sayfasındaki bir öğeye dokunduğunda, mobil etkileşim için tasarlanmamış sayfalarda, dokunmatik başlatma etkinliği ile fare etkinliklerinin işlenmesi (fareyi indirme) arasında en az 300 milisaniye gecikme olur. Bu işlem Chrome kullanılarak yapılabilir. Dokunmatik olmayan bir sistemde dokunma arayüzlerini test etmenize yardımcı olması için Chrome Geliştirici Araçları'nda "Dokunma etkinliklerini emüle et"i açabilirsiniz.

Bu gecikme, tarayıcının, kullanıcının başka bir hareket, özellikle de iki kez hafifçe vurarak yakınlaştırma yapıp yapmadığını belirlemesi için zaman tanımasıdır. Elbette bu, bir parmak dokunuşuna anında yanıt almak istediğiniz durumlarda sorun yaratabilir. Bu gecikmenin otomatik olarak gerçekleştiği senaryoları sınırlamaya çalışmak için sürekli çalışmamız vardır.

Bu gecikmeyi önlemenin ilk ve en kolay yolu mobil tarayıcıya sayfanızın yakınlaştırmaya ihtiyaç duymayacağını "söylemektir". Bu işlemi, sabit bir görünüm kullanarak (ör. sayfanıza ekleyerek yapabilirsiniz:)

<meta name="viewport" content="width=device-width,user-scalable=no">

Bu elbette her zaman uygun değildir. Bu durum, erişilebilirlik nedeniyle gerekli olabilecek olan sıkıştırma yakınlaştırma özelliğini devre dışı bırakır. Bu nedenle, hiç kullanmayacaksanız dikkatli kullanın (kullanıcı ölçeklendirmesini devre dışı bırakırsanız uygulamanızda metin okunabilirliğini artırmak için başka bir yol sağlamak isteyebilirsiniz). Ayrıca, dokunmayı destekleyen masaüstü sınıfı cihazlardaki Chrome'da ve mobil platformlardaki diğer tarayıcılarda sayfanın ölçeklendirilemeyen görüntü alanları olduğunda bu gecikme geçerli değildir.

2: Mousemove Etkinlikleri Dokunarak Tetiklenmez

Bu noktada, bir dokunma arayüzündeki fare etkinlikleri emülasyonunun, genel olarak fare hareketi etkinliklerinin benzetimini kapsamadığı unutulmamalıdır. Bu yüzden, fare hareketlerini kullanan, fareye dayalı güzel bir denetim oluşturursanız, özel olarak dokunarak taşıma işleyicileri de eklemediğiniz sürece, büyük olasılıkla bir dokunmatik cihazla çalışmayacaktır.

Tarayıcılar genellikle HTML denetimlerindeki dokunma etkileşimleri için uygun etkileşimi otomatik olarak uygular; böylece, örneğin HTML5 Aralığı kontrolleri yalnızca dokunma etkileşimlerini kullandığınızda çalışır. Bununla birlikte, kendi denetimlerinizi uyguladıysanız, büyük olasılıkla tıkla ve sürükle türü etkileşimlerinde çalışmayacaktır. Aslında, yaygın olarak kullanılan bazı kitaplıklar (jQueryUI gibi) henüz bu şekilde dokunma etkileşimlerini yerel olarak desteklememektedir (jQueryUI için bu sorunun birkaç maymunu düzeltmesi mevcuttur). Bu, Web Audio Playground uygulamamı dokunmayla çalışacak şekilde yeni sürüme geçirirken karşılaştığım ilk sorunlardan biriydi. Kaydırma çubukları jQueryUI tabanlı olduğu için tıkla ve sürükle etkileşimleriyle çalışmıyordu. HTML5 Aralığı kontrollerine geçtim ve bunlar çalıştı. Alternatif olarak, elbette, kaydırma çubuklarını güncellemek için dokunma taşıma işleyicileri ekleyebilirdim, ancak bununla ilgili bir sorun var.

3: Dokunma Hareketi ve Fare Hareketi Aynı Şey Değil

Birkaç geliştiricinin karşılaştığım bir yanlışlık da touchmove veMousemove işleyicilerinin aynı kod yollarına çağrı yapmasıdır. Bu etkinliklerin davranışı çok yakındır, ancak biraz farklıdır. Özellikle, dokunma etkinlikleri her zaman BAŞLADI'ya dokunulan öğeyi hedeflerken, fare etkinlikleri o anda fare imlecinin altındaki öğeyi hedefler. Bu nedenle fareyle üzerine gelme etkinliklerimiz var, ancak buna karşılık gelen dokunma ve dokunma etkinlikleri yok, yalnızca dokunma sonu.

Bu durumun sizi olumsuz etkilemesinin en yaygın yolu, kullanıcının dokunmaya başladığı öğeyi kaldırmanız (veya yerini değiştirmenizdir)dir. Örneğin, özel kaydırma davranışını desteklemek için bandın tamamında dokunma işleyicisi olan bir resim rulosu düşünün. Kullanılabilir resimler değiştikçe bazı <img> öğelerini kaldırıp diğerlerini eklersiniz. Kullanıcı bu resimlerden birine dokunmaya başlar ve ardından onu kaldırırsanız, işleyiciniz (img öğesinin üst öğesindedir) dokunma etkinliklerini almayı durdurur (çünkü artık ağaçta olmayan bir hedefe gönderilirler; çünkü kullanıcı hareket etmiş ve sonunda kaldırmış olsa bile parmağını bir yerde tutuyormuş gibi görünür).

Dokunma etkinken dokunma işleyicileri olan (veya üst öğeleri olan) öğeleri kaldırmaktan kaçınarak elbette bu sorunun önüne geçebilirsiniz. Alternatif olarak, en iyi yol statik touchend/touchmove işleyicilerini kaydetmektir, bir touchstart etkinliği alana kadar bekleyin ve ardından touchmove/touchend/touchcancel işleyicilerini touchstart etkinliğinin hedefine ekleyin (ve bitiş/iptal sırasında kaldırın). Böylece, hedef öğe taşınmış/kaldırılmış olsa bile dokunmayla ilgili etkinlikleri almaya devam edersiniz. Bu öğeyle biraz burada oynayabilirsiniz. Kırmızı kutuya dokunun ve DOM'den kaldırmak için escape tuşuna basın.

4: Dokunma ve :Fareyle üzerine gelme

Fare işaretçisi metaforu, imleç konumunu aktif seçme işlevinden ayrıyordu. Bu da, geliştiricilerin, kullanıcılarla ilgili olabilecek bilgileri gizlemek ve göstermek için fareyle üzerine gelme durumlarını kullanmasına olanak tanıdı. Ancak, şu anda dokunmatik arayüzlerin çoğu, bir hedefin üzerinde "fareyle üzerine gelinen" parmağınızı algılamaz.Bu nedenle, bu bilgilere erişmek için dokunma dostu bir yöntem sunmadığınız sürece, fareyle üzerine gelmeye dayalı semantik olarak önemli bilgilerin (ör. "bu kontrol nedir?" pop-up'ı görüntülenir) sunulmasına izin verilmez. Kullanıcılara bilgi aktarmak için fareyle üzerine gelmeyi nasıl kullandığınıza dikkat etmeniz gerekiyor.

Yine de ilginç bir şekilde, CSS :hover sözde sınıfı bazı durumlarda dokunma arayüzleri tarafından tetiklenebilir - bir öğeye dokunulduğunda, parmak aşağıdayken öğe etkin hale gelir ve aynı zamanda :hover durumu da edinilir. (Internet Explorer'da, :fareyle üzerine gelme işlemi yalnızca kullanıcının parmağı aşağıdayken etkin olur. Diğer tarayıcılar bir sonraki dokunuşa veya fare hareketine kadar :hareketini korur.) Bu, açılır menülerin dokunmatik arayüzlerde çalışması için iyi bir yaklaşımdır. Bir öğeyi etkin yapmanın bir yan etkisi, :fareyle üzerine gelme durumunun da uygulanmasıdır. Örneğin:

<style>
img ~ .content {
  display:none;
}

img:hover ~ .content {
  display:block;
}
</style>

<img src="/awesome.png">
<div class="content">This is an awesome picture of me</div>

Başka bir öğeye dokunulduğunda, kullanıcı artık fare işaretçisini kullanıp öğeden uzaklaştırmış gibi, öğe artık etkin olmaz ve fareyle üzerine gelme durumu kaybolur. İçeriği sekme durağı yapmak için bir <a> öğesinin içine sarmak isteyebilirsiniz. Bu şekilde kullanıcı, fareyle üzerine gelindiğinde veya tıkladığında, dokunarak ya da tuşa basıldığında ekstra bilgileri JavaScript gerekli olmadan değiştirebilir. Web Audio Playground'umu, bu tür bir yapı kullandığım için açılır menülerimin dokunma üzerinde zaten iyi çalıştığı dokunma arayüzleriyle uyumlu bir şekilde çalışmak üzere çalışmaya başladığımda çok şaşırmıştım.

Yukarıdaki yöntem, fare işaretçisine dayalı arayüzlerin yanı sıra dokunmatik arayüzlerde de iyi sonuç verir. Bu, fareyle üzerine gelindiğinde görünen "başlık" özelliklerinin aksine, öğe etkinleştirildiğinde GÖSTERİLMEZ:

<img src="/awesome.png" title="this doesn't show up in touch">

5: Dokunma ve Fare Hassasiyeti

Farelerin gerçeklikle kavramsal ilişkisi olsa da, altta yatan işletim sistemi genellikle imleç için tam piksel hassasiyetini izlediğinden, farelerin son derece doğru olduğu ortaya çıkar. Diğer yandan mobil geliştiriciler, dokunmatik bir ekrana yapılan parmak dokunmalarının pek doğru sonuç vermediğini öğrenmişlerdir. Bunun nedeni, çoğunlukla ekranla temas eden parmağın yüzey alanının büyüklüğü (kısmen parmaklarınızın ekranı engellemesi) sonucunda ortaya çıkmıştır.

Birçok kişi ve şirket, parmakla etkileşimi destekleyen uygulamaların ve sitelerin nasıl tasarlanacağı konusunda kapsamlı kullanıcı araştırmaları yapmıştır ve bu konuda pek çok kitap yazılmıştır. Temel öneri, dolguyu artırarak dokunma hedeflerinin boyutunu artırmak ve öğeler arasındaki boşluğu artırarak yanlış dokunma olasılığını azaltmaktır. (Dolgu, dokunma ve tıklama etkinliklerinin isabet algılamasını işleme alırken kenar boşlukları dahil değildir.) Web Audio Playground'da yapmam gereken başlıca düzeltmelerden biri, doğru bir şekilde daha kolay dokunulabilmesi için bağlantı noktalarının boyutlarını artırmaktı.

Dokunma tabanlı arayüzlerle çalışan pek çok tarayıcı satıcısı, kullanıcı ekrana dokunduğunda doğru öğeyi hedeflemeye ve yanlış tıklama olasılığını azaltmaya yardımcı olacak bir mantık sunmuştur. Ancak, bu genellikle yalnızca tıklama etkinliklerini düzeltir, hareketleri düzeltmez (Internet Explorer'ın da fareyle üzerine gelme/fareyle taşıma/fareyle getirme etkinliklerini değiştirdiği görülüyor).

6: Dokunma İşleyicileri Bulun. Aksi takdirde parşömeninizi temizleyecekler

Ayrıca, dokunma işleyicilerini yalnızca ihtiyaç duyduğunuz öğelerle sınırlı tutmak da önemlidir. Dokunma öğeleri çok yüksek bant genişliğine sahip olabilir. Bu nedenle kaydırma elemanlarında dokunma işleyicilerden kaçınmanız önemlidir (işleminiz hızlı, olumsuz dokunmayan dokunmatik kaydırma için tarayıcı optimizasyonlarını engelleyebilir. Modern tarayıcılar bir GPU iş parçacığında kaydırmayı dener ancak öncelikle uygulamanın her bir JavaScript etkinliğinin işlenip işlenmediğini kontrol etmeleri gerekiyorsa bu işlem yapılamaz). Bu davranışın bir örneğini inceleyebilirsiniz.

Bu sorunu önlemek için dikkat edilmesi gereken bir nokta da, kullanıcı arayüzünüzün yalnızca küçük bir bölümündeki dokunma etkinliklerini işlemeniz durumunda dokunma işleyicilerini yalnızca buraya eklemektir (ör.sayfanın <body> bölümüne değil). Kısacası, dokunma işleyicilerinizin kapsamını mümkün olduğunca sınırlamanız gerekir.

7: Çoklu Dokunmatik

Son olarak ilginç olan sorun ise, "Dokunmatik" kullanıcı arayüzü olarak nitelememize rağmen, neredeyse dünya genelinde desteğin aslında Çoklu Dokunma'ya yönelik olmasıdır. Yani API'ler, aynı anda birden fazla dokunma girişi sağlar. Uygulamalarınızda dokunmayı desteklemeye başlarken, birden fazla dokunmanın uygulamanızı nasıl etkileyebileceğini göz önünde bulundurmalısınız.

Esas olarak fare ile çalışan uygulamalar oluşturuyorsanız, bu durumda en fazla bir imleç noktasıyla derlemeye alışıksınız demektir. Sistemler genellikle birden fazla fare imlecini desteklemez. Birçok uygulamada dokunma etkinliklerini yalnızca tek bir imleç arayüzüne eşlersiniz ancak masaüstü dokunmatik girişi için gördüğümüz donanımların çoğu en az 2 eşzamanlı girişi işleyebilir ve çoğu yeni donanım en az 5 eşzamanlı girişi destekler. Elbette, ekranda piyano klavyesi geliştirmek için birden çok eşzamanlı dokunma girişini destekleyebilmek istersiniz.

Şu anda uygulanan W3C Touch API'leri, donanımın kaç temas noktasını desteklediğini belirleyen bir API'ye sahip değildir. Bu nedenle, kullanıcılarınızın kaç temas noktası isteyeceğine ilişkin en iyi tahmininizi kullanmanız veya elbette uygulamada kaç temas noktası gördüğünüze dikkat edin ve bunları uyarlayın. Örneğin, bir piyano uygulamasında hiçbir zaman ikiden fazla temas noktası görmüyorsanız "akorlar" kullanıcı arayüzü ekleyebilirsiniz. PointerEvents API, cihazın özelliklerini belirleyen bir API'ye sahiptir.

Rötuş

Bu makalenin, fare etkileşimlerinin yanı sıra dokunmayı uygularken sık karşılaşılan zorluklarla ilgili yol gösterici bilgiler sağladığını umarız. Elbette uygulamanızı mobil cihaz, tablet ve birleştirilmiş fare ve dokunmatik masaüstü ortamlarında test etmenizin diğer tavsiyelerden daha önemli olması gerekir. Dokunma+fare donanımınız yoksa farklı senaryoları test etmenize yardımcı olması için Chrome'un "Dokunma etkinliklerini emüle et" özelliğini kullanın.

Dokunmatik giriş, fare girişi ve hatta aynı anda her iki etkileşim stiliyle iyi çalışan ilgi çekici etkileşimli deneyimler oluşturmak, bu yönergeleri uygulamak mümkün olduğu gibi nispeten kolaydır.