Kategori
Web Usability

Pertimbangan Penyederhanaan Blog

Diperbarui 19 November 2012 oleh Dani Iswara

Saat memutuskan ingin menghapus fitur blog tidak penting ini, penyederhanaanlah alasan utamanya. Terutama kemudahan pemeliharaan blog versi desktop & mobile. Dengan pendekatan lebih pada kesederhanaan versi mobile atau mobile-aware. Saya tidak ingin repot mengelola versi desktop & mobile atau cross-browser design terpisah. Apalagi blog ini kadang berubah sewaktu-waktu sebagai bahan belajar. Jadi, intinya demi kemudahan pemeliharaan.

Tulisan ini sekaligus menjawab beberapa pertanyaan Pakde Harry (side22.com), Mas Iskandaria (kafegue.com), dan Pak Aldy M. Aripin (personfield.web.id) yang terkait hal ini.

Kemudahan akses mobile

Beberapa hal yang saya lakukan tidak selamanya sesuai dengan norma aksesibilitas Web baku.
Misalnya menu navigasi di atas. Lihat dulu dengan peramban berbasis teks. Saya memakai relationship link (Dani Iswara .com) yang tidak standar sebagai jump link.
Setelah itu, dilihat dengan peramban Web berbasis grafis, navigasi utama tidak lagi memakai elemen blok seperti tag ul & li. Cukup memakai tag <p> biasa.
Laman atau homepage hanya menampilkan menu beberapa tulisan terkini. Daftar tulisan terkini di halaman tunggal dihapus. Diganti dengan daftar tulisan terkait sebagai navigasi tambahan. Mengingatkan untuk taat memakai tag yang benar-benar terkait. Tiap tulisan pun hanya bisa masuk dalam 1-2 kategori.

Menurut saya, semuanya tampak ringkas di peramban Web mobile.

Benarkah ringkas?

Sebenarnya, saya belum melakukan user testing sama sekali. Bukan pula pengamat statistik blog. Hanya berdasarkan pengalaman pribadi & beberapa best practice. Silakan baca kembali tulisan lama di Dani Iswara .Net:

  • Validasi Desain Web Mobile-Friendly.
  • Halaman Aplikasi Web Versi Mobile.

Menurut saya, yang paling sulit dipenuhi dari rekomendasi W3C Mobile OK itu antara lain:

  • kesesuaian doctype. Kecuali memakai dua versi antarmuka. Dengan logika, jika string user agent terdeteksi sebagai peramban mobile, maka tampilkan situs Web versi mobile (browser sniffing). Atau, jika koneksi Internet lambat, tampilkan versi mobile. Semuanya dengan teknik negosiasi konten di sisi server. Sering juga disebut DOCTYPE switching. Baik server sendiri atau pihak ketiga. Sehingga tiap situs punya dua doctype yang berbeda fungsi.
  • ukuran maksimal berkas. Dianjurkan tidak lebih dari 10 kylobytes untuk konten saja dan maksimal 20 kylobytes total beserta CSS dan skrip lain. Upaya kompresi, minimalisasi pemakaian gambar, skrip, bisa saja dilakukan. Tapi banyaknya muatan konten & komentar sulit dibatasi. Kecuali lebih menyenangi sistem paging, memecah menjadi beberapa halaman.
  • kesesuaian CSS. Beberapa elemennya dianjurkan untuk dibatasi pemakaiannya karena dukungan peramban mobile belum maksimal. Antara lain properti position, display, float.

Itulah Indonesia alasan saya. ☯

Diperbarui 3 Agustus 2010: Tulisan Bruce Lawson di situs dev.opera.com berjudul Mobile-friendly: The mobile web optimization guide, sepertinya sesuai dengan beberapa alasan di atas.
Dianjurkan 3 strategi berikut:

  • Code well and do nothing special for mobile users. Setuju. saya berusaha memakai strategi ini & menganggap belum perlu menyediakan versi khusus untuk versi mobile.
  • Make a separate "mobile" site. Ada konsekuensi untuk ini. Jika memakai deteksi per user agent, pemutakhiran string user agent harus rajin. Dengan antarmuka berbeda, user experience akan membutuhkan learning curve atau masa adaptasi yang berbeda dibanding versi desktop. Faktor usability berperan di sini.
  • Build mobile-aware adaptive sites. Banyak teknik yang bisa diimplementasikan via CSS @media & tag <meta name="viewport" content="width=device-width" />.

Tinggal pilih yang sesuai kebutuhan.

21 tanggapan untuk “Pertimbangan Penyederhanaan Blog”

Bli Dani,

Sekarang WP 3.0.1 sudah rasanya sudah mendukung versi mobile yang langsung berdiri sendiri. Dan tema-tema baru seperti the erudite (di catatan.legawa.com) serta hybrid (di cahya.legawa.com) keduanya menyokong tema mobile independen, jadi tanpa plugin (seperti wordpress mobile), tema ini akan memberikan tampilan yang ramah peramban mobile dengan sendirinya saat dibuka di dari ponsel (misal dengan opera mini 5).

Apa mungkin ini standar baru WordPress bahwa setiap theme mesti mendukung peralihan yang ramah untuk peramban mobile?

Bli Dani,

Karena saya menemukan adanya berkas kompresi khusus untuk mobile browser saat mengaktifkan plugin “WP Super Cache”, padahal tidak ada pengaya ata fungsi khusus untuk setelan mobile browser.

Tidak hanya tampilan blog yang tampil dalam versi mobile browser, tapi dashboard wordpress juga tampil dalam versi mobile, padahal di versi sebelumnya tidak tampil demikian walau sama-sama pakai Opera Mini versi yang sama.

Apa ini memang kompresi dan konversi dari sisi server peramban, atau memang ada pembangunan ini di WP, maaf, soalnya memang tidak ada isu spesifik tentang hal ini di WordPress.

Bli Dani,
apa dampaknya dengan mengubah ulli menjadi hanya menggunakan tag p?

menghilangkan position, display, float.? pekerjaan rumah lagi.

penggunaan em dan %, lebih disarankan?

Pak Aldy,
Dengan tag p, menu tampak lebih ringkas di layar sempit/kecil. Tapi, normatifnya, suatu navigasi atau tautan (2 atau lebih) yang memiliki makna sekelompok/sebagai satu kesatuan, semantik menganjurkan memakai tag ul.

Dan antartautan diberi pemisah karakter yang printable. Tentu susah mengenali textanchor1 textanchor2 textanchor3 (dalam satu kalimat) tanpa melihat bar status.

Pemakaian ukuran relatif juga sudah jelas lebih dianjurkan untuk desain Web versi desktop.

@Mas Ardianzzz, saya coba menerapkanya di aldymy.name, tapi gagal (belum sempurna), mungkin skala image yang saya gunakan tidak baik, ada saran?

@Bli Dani,
intinya, jika suatu navigasi lebih dari dua, tetap lebih baik menggunakan tag ul. Penerapan yang Bli lakukan sebagai bentuk akomodatif terhadap layar mobile?

Bli Dani,
yang tebayang sekarang, poin nomor 2, besarnya berkas maksimal 20kylobyte.

Entah bagaimana manajemen yang baik untuk penanganan berkas, solusi dengan penggalan perhalaman, jika diperangkat kecil sepertinya menyulitkan :(

Banyaknya muatan komentar sepertinya menjadi penghambat utama untuk meringankan ‘loading’ blog, terutama untuk blog-blog yang ramai komentar atau yang menggunakan sistem komentar bersarang. Maaf kalau sedikit keluar dari topik. Saya pernah mencoba menyimpan salah satu halaman blog saya yang banyak berisi komentar. Ukurannya relatif besar jadinya.

Tes terakhir saya, setelah menonaktifkan kaskus emoticons, ternyata ukuran berkas halaman menjadi jauh lebih kecil. Dan mungkin akan lebih kecil lagi jika saya menonaktifkan gravatar :) Tapi saya belum sampai hati..

Tentang penyederhanaan blog, ukuran keberhasilannya menurut saya yaitu ketika tidak terlalu lama diakses via ponsel (browser mobile) dan via koneksi nirkabel yang agak ‘lelet’.

Pak Aldy,
Tim W3C Mobile OK sendiri menyebutnya memang sulit. Kecuali disiasati bahwa versi mobile (terutama bagi pengguna Internet volume-based) hanya terdiri dari excerpt. Bahkan ada yang menyajikan tanpa fitur komentar. Atau disediakan tautan tersendiri untuk melihat konten penuhnya. Jadi, pilihan diserahkan ke pengguna.

Yang seukuran lebih kurang 10-20 kylobyte itu setara laman/homepage blog ini. Atau laman blog ini yang dulu dengan 1 excerpt plus CSS handheld & print terpisah dari CSS utama. Semuanya sudah termasuk penulisan markah sehemat mungkin.

Ya, itulah best practice yang akan berubah di masa depan.

iskandaria,
Jika mengukur keberhasilan, tentu kembali ke target masing-masing pengelola. Dan saya tidak menargetkan konversi angka statistik apapun.

Pak Aldy, wow… resizing nirvana… :)
Sepertinya tidak/belum gagal Pak Aldy. Masih ok pada layar 800×500px.
Saya pikir belum semuanya diberi satuan relatif. Misalnya kotak pencarian, navigasi dan lebar gambar — gambar konten — semuanya sebaiknnya menggunakan satuan relatif.

Kalau bungung dengan versi mobile, mungkin dapat menggunakan layanan dari mobify atau mippin.

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *

Situs ini menggunakan Akismet untuk mengurangi spam. Pelajari bagaimana data komentar Anda diproses.