web-gelistirme-sc.com

2020'de Kaydırma Çubukları Öldü mü?

Son zamanlarda bir tasarımcının modern web tasarımlarının görsel kaydırma çubukları kullanmadığına dair bir şey söylediğini duydum - ya da en azından sadece kaydırma sırasında görülebilir. Ben bir ön uç geliştiriciyim ve bunu gerçekten duymamıştım. Bunun bir gerçeği var mı? Özellikle benim sorum:

Bir web uygulaması için içerik kaydırılabilir olduğunda:

  1. Hiç görünür kaydırma çubukları olmalı mı (ve neden)?
  2. Hiç görünür kaydırma çubukları olmamalı mı (neden olmasın)?
92
jbyrd

Evet olmalı.

Görünür kaydırma çubukları "bu sayfa kaydırılabilir" özelliktedir

Bunun gibi görsel ipuçları olmadan işlevsellik atlanabilir.

107
colmcq

Bazı modern tasarım yönergeleri, kesinlikle görünür olan kaydırma çubuklarını kesinlikle değiştirmez, ancak hepsini değil. Örneğin, Malzeme Tasarımı kılavuz , menüler için, bir menü kaydırılabilir durumdaysa, bir kaydırma çubuğu göstermelidir. Her durumda, içeriğiniz kaydırılabilir durumdaysa, içeriğin kaydırma sağladığı göz önüne alınmalıdır.

Bu yatırımın ne kadar aşağı kaydırabileceğinizi (geleneksel), bir "daha fazlasını oku" bağlantısını veya aşağıyı gösteren oku (birçok modern uygulama ana sayfasında veya blogunda olduğu gibi) açıkça gösteren bir kaydırma çubuğuyla işaretlenmesi bireysel bir tasarımcıya veya kılavuza bağlıdır. ) veya içerik alanının Kenarına yaklaştıkça yavaş yavaş kaybolur. Kaydırılabilen ancak kullanıcıya kaydırılabilirliği göstermeyen içeriği sunmak zayıf bir tasarım olacaktır. Kullanıcıyı hayal kırıklığına uğratabilir veya önemli bilgileri veya harekete geçirici mesajları kaçırmasına neden olabilir.

102
sintax

Bir fare kullanıcısı olarak, kaydırma çubuklarına bir görünüm ve erişim vermeyen kaydırılabilir içerikten nefret ediyorum.

  1. Kaydırma çubuğu bir kontroldür. Hızlı bir şekilde büyük sayfalarda gezinmeme izin veriyor, parmak kaydırma, kaydırma tekerleği vb. Ayrıca çoğu sayfa için kaydırma tekerleğimden daha fazla hassasiyet sağlıyor.

  2. Kaydırma çubuğu bana bilgi veriyor. Sayfadaki içeriği okumanın ne kadar süreceğini hızlı bir şekilde belirlememe izin veriyor (tanıtıcısı: Cilt payı oranı ekrana eşit: sayfa oranı) iyi bir kaydırma çubuğunu varsayarak ve sayfada ne kadar ilerlediğimi söyler . Ayrıca, hızlı bir şekilde yukarı ve geri aşağı kaydırmak istiyorsam, sayfada nerede olduğumu belirlemem için bir dizin verir.

  3. Kaydırma çubuğu önemsiz miktarda alan kaplıyor. Şu anda ekranım 1920 x 1080 = 2,1 Mpx hızında. İçinde bu sayfa bulunan Firefox penceresi 1125 x 905 = 1.0 Mpx değerinde. Kaydırma çubuğu, toplam 13 Kpx veya ekranımın% 1.3'ünü kaplayan 16 x 816'dır. Monitörüm bana oldukça yakın çünkü oyun için kullanıyorum, bu yüzden penceremi yine de monitörden daha dar tutma eğilimindeyim, bu yüzden kaydırma çubuğu etkili bir şekilde yer kaplamaz.

  4. İçeriğin kaydırılabilir olduğunu bilmediğim durumlar olsa da, çubuğu bile kontrol etmeden tekerleği kaydırmayı deniyorum, bu yüzden bunun web sayfaları için büyük bir sorun olduğundan şüphe duyuyorum. Normalde kaydırma yapmayan masaüstü uygulamaları için bu daha büyük bir sorun olacaktır.

  5. Gizlenebilir bir kaydırma çubuğu istiyorsanız, el ile her kaydırma yaptığımda (fare tekerleği, klavye tuşları, izleme paneli vb. Aracılığıyla) ve faremi ekranın sağ kenarına doğru her hareket ettirdiğimde görünmelidir.

Mobil cihazlar daha zordur, çünkü kaydırma çubuğu özellikle kullanmak için yeterince büyükse çok fazla yer kaplar.

  • C. Genellikle masaüstü görünümüne geçerek sorunu çözerim (henüz mobil sürümü masaüstü sürümünden daha iyi olsa da iyi olan bir web sitesini görmedim, bu yüzden varsayılan olarak masaüstü görünümüne geçiyorum). Sonra uzaklaştırma, aşağı kaydırma, sonra yakınlaştırma. Yakınlaştırırken kaydırma, kaydırma, kaydırma yapmaya çalışmaktan daha hızlı ve daha hassastır ve kavranabilir bir kaydırma çubuğu gerektirmez. (Ayrıca, çoğu mobil sitenin açıklanamaz bir şekilde izin vermeyi reddettiği görüntülerin, diyagramların vb. Daha iyi görüntülenmesi için yakınlaştırmamı sağlıyor.)

  • B. Firefox on Android, sayfanın hangi kısmında olduğumu söylemek için erişilemeyen bir kaydırma çubuğuna sahip (varsayılan olarak "İnternet ve hem de sitenin mobil sürümleri için) "Bunları, tıpkı endeksleme ve sayfa uzunluğunu belirleme için fare ile bir masaüstü tarayıcısında yaptığım gibi kullanıyorum.

  • C. Ayrıca, büyük web sayfalarını yalnızca uygun bir monitörde görüntüleme eğilimindeyim, bu nedenle 900 sayfalık bir .pdf veya başka bir şeyde gezinmeye çalışan bir mobil cihazda olma ihtimalim daha düşüktür. Web uygulamanız hiçbir zaman iki veya üç ekrandan daha uzun sürmezse, kaydırma çok daha az sorun olur.

  • D. Dokunmatik ekran parmak kaydırmanın genellikle fare tekerleğini kullanmaktan daha hızlı ve daha hassas olduğunu da belirtmek gerekir, bu nedenle hızlı gezinmek zor olan bir sayfanın çok daha büyük olması gerekir.

Sonuç

Fare (veya izleme dörtgeni veya hareket topu) kurulumları için kaydırma çubuğunun her zaman görünür ve kavranabilir olması gerektiğini düşünüyorum. Minimum olarak, kaydırma yaparken veya fareyi kaydırma çubuğunun yakınına getirirken görünmelidir.

Mobil dokunmatik ekran kurulumları için, kaydırma çubuğunun kaydırma sırasında her zaman görünür olması gerektiğini, ancak kavranabilir olması gerekmediğini ve boşa harcanan alanı azaltmak için kaydırılmadığında muhtemelen gizleneceğini düşünüyorum.

Tablet/iPad veya daha büyük dokunmatik ekranlarla uğraşmadım, bu yüzden bunlar hakkında nasıl hissettiğimden emin değilim.

Tabii ki, görsel stilleri değiştirme seçeneğine sahip olmak (geçici çerezler veya kayıtlı kullanıcı ayarları aracılığıyla, kullanıcınızın misafir mi yoksa hesap mı olduğuna bağlı olarak) en iyi seçenektir, ancak varsayılan olarak işlevsel bir şeye ihtiyacınız vardır.

61
MichaelS

Bu bakış açısı öncelikle Mac ortamından gelir; burada kaydırma çubukları genellikle içerik ilk görüntülendiğinde kısa bir süre görüntülenir, ardından kaybolur. Kaydırma meydana geldiğinde (kullanıcı tarafından tetiklenir veya başka bir şekilde), kaydırma çubuğu yeniden görünür. Sadece tutamak görülebilir (yarı saydam yuvarlak siyah çubuk olarak); ok veya Oluk yok. İmleç göründüğünde kaydırma çubuğunun üzerindeyse, genişler ve imleçle sürüklemeye izin verir. İçerik hiçbir zaman boyutu değişmez; kaydırma çubuğu yokmuş gibi davranır ve kaydırma çubuğu üstte görüntülenir.

Bu, izleme dörtgeni veya izleme dörtgeni benzeri giriş mekanizmaları (yani bir dizüstü bilgisayar) kullanırken geçerlidir. Fare kullanılırken normal kaydırma çubukları varsayılan olarak görüntülenmeye devam eder.

Tabii ki, bu aynı zamanda mobil cihazlara da uzanıyor; iOS neredeyse aynı davranışı kullanır (eksi imleç etkileşimi). Aslında iOS'ta başladığını (kaydırma çubuklarının güvenilir bir şekilde dokunmak için çok küçük olacağı yerlerde) ve macOS'a taşındığını düşünüyorum.

Genel olarak, bunun avantajları ve dezavantajları vardır:

  • Kaydırma çubukları için yer açmaya gerek olmaması, sayfa tasarımını basitleştirir (daha az dikkat dağıtıcı öğe) ve özellikle birden fazla yer kaydırılabildiğinde içerik için daha fazla alan sağlar.
  • Mac'teki kullanıcılar bu davranışa alışır ve bunu bekler.
  • Bir alan aniden kaydırılabilir hale geldiğinde içerik boyutunda bir sıçrama olmaz; bu da, kaydırma çubuğunun görünür olduğu sürece ihtiyaç duyulduğu ve gizlenmişse (örneğin metin kaydırma nedeniyle) gerekli olmadığı ortak bir belirsizliği giderir.

  • Negatif tarafta, daha önce de belirtildiği gibi, içeriğin kaydırılabilir olduğunu belirtmek için başka bir yol bulmanız gerekir. Bir web sayfasının ana kısmı için böyle bir sorun değil çünkü bu zaten bekleniyor, ancak kullanıcı beklentilerine bağlı olarak dahili içerik için bir sorun olabilir. İlk flaş yardımcı olur, ancak her zaman yeterli değildir.

  • Belgedeki başka bir yere atlamak için kullanıcı etkileşimi karmaşıktır; kullanıcı imlecini kaydırma çubuğunun görüneceği yere taşımalı, fare tekerleği veya "2 parmakla kaydırma" ile hafifçe kaydırmalı, göründüğünde kaydırma çubuğunu tutmalı ve istenen konuma sürüklemelidir. Momentum kaydırma bazı durumlarda bunu önlemeye yardımcı olur.
  • Kaydırma çubuğu şeffaf bir arka plan üzerinde göründüğünden, arka plan karanlıksa görmek zor olabilir. macOS, bu durumda kullanılabilecek beyaz bir alternatif kaydırma çubuğu sağlar (arka plan yeterince karanlıksa tarayıcıların otomatik olarak buna geçtiğine inanıyorum, ancak% 100 kusursuz değildir). Ayrıca, bara yeterince iyi bir arıza güvenliği olarak ince bir parlaklık (veya gölge) verir.

Mümkünse, elbette, bu tür şeyler için tarayıcı-yerel bileşenlere bağlı kalın. Her kullanıcının kendi platformu için doğal bir deneyim elde etmesini sağlayacaktır (Kesinlikle çok sayıda web sitesinin momentum kaydırmayı ve elastik kaydırmayı iğrenç sonuçlarla çoğaltmaya çalıştığını gördüm). Mac kullanıcıları, görünür kaydırma çubuklarını beklemedikleri yere zorladığınız için teşekkür etmeyecek ve Windows kullanıcıları kaydırma çubuklarını bekledikleri yere gizlediğiniz için size teşekkür etmeyecektir.

26
Dave

Benim görüşüme göre kaydırma çubuklarının kaldırılması, stilin işlevsellik üzerine koyulmasının aptal ve sığ ideolojisinin bir başka örneğidir. Bu nasıl olması gerektiği konusunda öndedir ve toplumun bana düştüğünü gösterir. Kaydırma çubukları, diğer alternatif yöntemlerin her zaman tekrarlayamayacağı önemli bir işlevsel amaca hizmet eder. Değişikliğin kısmen insanların dokunmatik ekran kullandıkları fikrine dayandığını düşünüyorum, bu yüzden gerekli değildir, ancak birçok kişi hala kullanmamaktadır. Birçok alternatif yöntem, kötü bir kullanıcı arayüzü ile savaşmak yerine, iş yapmak için harcamayı tercih ettiğim bir enerji drenajı olan manipülasyon için ekstra konsantrasyon ve incelik gerektirir. Geleneksel kaydırma yöntemleri genellikle, daha fazla konsantrasyon gerektiren diğer yöntemlerden çok daha kolay bulduğum ok aşağı tuşuna basarak klavye kaydırma ile birlikte gider, ancak kaydırma çubukları kaldırıldığında, klavye ok kaydırma bazen onunla birlikte kaybolur; -Hayır! Bir örnek, büyük F sosyal ağı, msg geçmişinde yukarı kaydırırken "dinamik" kaydırma stiliyle sürekli olarak tahrişe neden oldu ve yukarı kaydırırken konuşmada nerede olduğunuzu bilmediğiniz, ancak daha sonra belirli bir nokta ve aniden ekstra bir konuşma geçmişi yükü yüklenir ve sonunda olmak istediğiniz yerin çok ötesine atlarsınız.

Ben de kısmen cehalet ve kısmen kullanıcı deneyimi pahasına şirketlerin para tasarrufu için sunucularda kaynakları ve bant genişliği tasarrufu arzusu düşünüyorum. Ayrıca, aptalların şeyleri çok basit komutlar için "daha kolay" hale getirmeleri için, aptal olmayan ve sıradan bir şey yapmak isteyenler için daha zahmetli hale getirme pahasına şeyleri aşağı çekmekle ilgilidir. Umarım blockchain, paradan tasarruf etmek için kullanıcı deneyiminden ödün veren bu çağın sonunu müjdeliyor ve hızlı çalışan ve hem temel hem de ileri düzey kullanıcılar için sorunsuz sistemlere sahip olabiliriz.

Örneğin, skype ve F messenger gibi yazılımlar, bölümün yüklenmesinden sonra sonsuza kadar beklemek yerine msg geçmişinizin en başlangıcına anında gitmenize izin verirse harika olmaz mıydı ?! Ben her zaman bir sürü bütün yükleme kaynaklarını kurtarmak için şüpheliyim. Bununla birlikte, biraz zeka ve nüanslı düşünceye sahip biri bunu tasarlasaydı, (blockchain çevrelerinde umduğum şirketlerden daha yaygın), hepimiz kekimizi alabilir ve yiyebiliriz. Kaynakları kaydedebiliriz (bu hala blockchain'de bile önemsiz bir şey değildir) ve sayfa yükleme sistemine göre bu iğrenç sayfaya katlanmak zorunda kalmadan istediğimiz bilgileri anında alabiliriz.

Tüm zaman çizelgesi geçmişinin çerçevesini, kaydırma çubuğunda açılan tarihlerle birlikte bir kaydırma çubuğunda düzenleyin. Fare düğmesine bastığınız veya kaydırma kaydolduğunuzda, o bölüm yüklenebilir. Doğrudan başa dönmek istiyorsanız, sağa en üste gidin ve yalnızca ilk sayfanın yüklenmesi gerekir. Hemen yüklemek için her şeye ihtiyacınız varsa, örneğin bir anahtar kelimeyi aramak için, sadece tüm msg geçmişini veya kaydırdığınız her şeyin geçmişini elde etmek için basılabilecek basit bir düğme sağlayın.

Birisi özellikle tüm bunların yüklenmesi için gerekli olduğunu işaret ederse, blok zincirinin kaynakları barındırması gerekir. Bu ve eski modeldeki şirketler arasındaki fark, özellikle her şeye ihtiyaç duyanların bile yüklenmesine izin vermekten çekinmez, pis kar amacı için kaynaklarını korumak ve kullanıcıyı vidalamak. Bu yüzden blockchain'e ve tercihen açık versiyona ihtiyacımız var.

11
Lex

Karışık bir bakış açısı olarak ...

Yatay kaydırma çubukları genellikle kötü bir şeydir. Bir PC monitörünün ekran genişliği için optimize ettiğiniz anlamına gelebilir, bu da mobil cihazlara iyi tercüme edilmez. Aşağı kaydırırken, tüm sayfayı okumak için her içerik ekranında çok fazla sol-sağ kaydırma gerekir. Tersine, bu siteler daha büyük ekranlarda yer harcamış olacaktır. (Daha yaşlı okuyucular, "En iyi 1024x768'de görüntülenen" web sitelerini hatırlıyor musunuz? Evet, bunlar.) 2019'da buna katlanmamız gerekmiyor -bu 1990'lar değil ve hala Netscape Navigator kullanmıyoruz. Sadece oraya gitme.

Diğer yandan dikey kaydırma çubukları iyi. Sezgisel olarak bir şeyi aşağı kaydırmaya alışkınız - örneğin, bir gazete gazetesini nasıl okuyacağınızı düşünün. Sadece yukarı/aşağı kaydırmayla tüm sayfa kolayca görülebilir.

2 veya 3'ten fazla ekran dolusu içeriğin çok fazla olduğu düşüncesi var. Bundan sonra bir şeyler bulmak zorlaşıyor. Bu nedenle kaydırma çubukları çalışırken, sizi sınırsız uzunluktaki sayfalara yönlendirmesine izin vermeyin!

8
Graham

Evet, erişilebilirlik uğruna başka bir sebep yoksa kaydırma çubukları görünür olmalıdır.

Kaydırma çubuğunu gizlemenin sitenizi/programınızı sinir bozucu ve sınırda herhangi bir yerde kullanılamaz hale getirdiği birçok durum vardır:

  • Sayfanıza erişmek için yardımcı donanım/yazılım kullanma
  • Kaydırma tekerleği olmayan bir fare kullanma
  • Kaydırma olaylarından geçmeyen bir uzak masaüstü sistemi kullanma
  • Çoklu parmak hareketlerini kullanarak kaydırılan bir dokunmatik yüzey kullanma (çoğu ortalama kullanıcı bunların var olduğunu bilmez)
  • Dokunmatik ekran kullanarak, sayfa birkaç ekrandan daha uzun ve sayfanın diğer ucunda bir yere kaydırmam gerekiyor
  • Dokunmatik ekran kullanarak, bağlantılar/düğmelerle dolu bir sayfayı kaydırmak (dokun ve kaydır hareketinin bir şeyi yanlışlıkla etkinleştirmesi muhtemeldir)

Görünür kaydırma çubukları, tüm bu sorunlardan kaçınmanın kolay bir yoludur. Meslektaşınızın birincil argümanı diğer sitelerin bunu yapıyor olması durumunda, onu dinlemeyin bile. Akran baskısı, anlamlı ve anlamlı bir neden olmadığı sürece geçerli bir argüman değildir neden bunu yapmak iyi bir fikirdir. Bu tür bir düşünce <blink> etiketi popüler oldu.

Ayrıca erişilebilirlik uğruna kendi kaydırma çubuklarınızı uygulamayın. Sistem tarafından sağlananları kullanın. Yardımcı teknoloji her zaman ev yapımı kaydırma çubuklarını tanımlayamaz ve bu şekilde çalıştırmaz.

7
bta

Kaydırma çubuğu son derece kullanışlıdır

  1. kullanıcıya sayfanın kaydırılabilir olduğunu gösterir
  2. kullanıcıya şu anda kaydırılabilir sayfada nerede olduklarını gösterir

Kaç kez sinirlendiğimi ve kaybolduğumu bilmiyorsunuz çünkü bazı boktan tasarımcı kaydırma çubuğunu silmenin iyi bir fikir olduğunu düşündü.

3
Solid_Metal

MichaelS’ın cevabına eklemek için,

Tabletlerde ve iPad'lerde, kaydırılmadığında gizlenen yakalanamayan bir kaydırma çubuğu tercih edilir. Dediği gibi, dokunmatik cihazlarda kaydırma çok daha hassas ve görünür, kavranabilir, kaydırma çubukları tıknaz ve sinir bozucu. Ancak, sayfa uzunluğuna bağlı olarak, bir başa dön düğmesi kabul edilir.

Ayrıca, bunu 12.9 inç iPad pro kullanarak StackExchange'e yazarken, yanlışlıkla farklı bir tonda iyi (~ 1cm) bir dolgu eklemenin, yanlışlıkla bağlantı açmadan kaydırma yapılmasına izin verdiği için yararlı olduğunu fark ettim.

2
Bob Kerman

İlginç bir soru, benim 2c bir geliştiriciden geliyor ama UX kurşun ve aynı zamanda birkaç dahili kaydırılabilir alan ile arayüzler tasarlanmış.

Birkaç nokta:

  1. İçerik, kaydırma gerektirecek kadar büyükse görünür kaydırma çubukları bulunmalıdır; çünkü kaydırma çubuğunun varlığı, içeriğin kaydırılabileceğini gösterir ve sağlar.
    • Sonsuz kaydırma kişisel cehennem fikrimdir, özellikle de izleme çubuğunu tıklayıp sürüklerseniz (teğet)
  2. İçerik kaydırılamıyorsa, kaydırma çubukları gerçekleşmeyen şeyleri öneren bir anti-parazittir.
    • Bir Edge durumu kaydırılamayan şeylerdir now ancak içerik boyutu artarsa, bu editörlerde veya dinamik çıktısı olan herhangi bir sistemde yaygın olabilir. Özellikle kaydırma işlevini ekler/kaldırırsanız, düzenlerle karışabilir, içerik genişledikçe yatay jank alırsınız ve sonra kaydırma çubuğu görünür. (Eğer kullanırsan overflow: auto Örneğin). Bu durumda, kaydırılabilir bir alan olduğunu belirtmek için devre dışı bırakılmış bir kaydırma çubuğu koymak easy olabilir, ancak içerik henüz bu davranışı etkinleştirecek kadar büyük değildir.
  3. Yatay kaydırma çubukları, dikey kaydırma çubukları ile birlikte tanıtıldığında ve örtük mod seçimi ile birlikte normalde kötü bir fikirdir. Olduğu gibi, bir fare kaydırma varsayılan olarak dikey kaydırma, ancak örtülü bir ek tuş basımı (veya izleme dörtgeni etkileşimi) yatay kaydırma elde edilebilir. Bunun karmaşıklığı çok nadiren elde edilir.
  4. Bazı uygulama arabirimlerinde (örn. Slippy haritaları) tüm kaydırma çubuklarını kaldırmak, içerik bu paradigmada tarayıcı penceresinin altında hareket ettiği için iyi bir fikir olabilir, aksi halde değil. Kontroller çoğu kullanıcı tarafından iyi anlaşılmıştır.
  5. Birçok özel özel sürüm istemiyorsanız, kaydırma çubuklarını stil etmeye çalışmak zamanın% 99'udur, tüm ortamlarda mükemmel görünmeyeceklerini ve tarayıcı varsayılanlarını kullanmadıklarını kabul edin.
1
dougajmcdonald

Tasarımcı kaydırma çubuklarını kayan kaydırma aşağı/yukarı düğmesiyle değiştirmekten mi bahsediyor? Bence bu mobil ilk önce bir yaklaşım ve bazı bağlamlarda başarıyla kullanıldığını gördüm, ancak bu düğmeler bir ızgaradaki kaydırma çubuklarının yerini alamaz.

0
Ling