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 duadoctype
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?
Cahya,
Saya tidak menemukan isu itu di Trac WordPress 3.0.1.
Yang dilakukan Opera Mini & Opera Mobile adalah kompresi & konversi di sisi server-nya sendiri. Serupa seperti Google Wireless Transcoder.
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.
Cahya,
Plugin WP Super Cache memang mendukung tema mobile.
Mungkin tema situ ada versi mobile-nya terintegrasi di sisi server?
Bli Dani,
Bagaimana dengan dashboard WordPress yang juga memperlihatkan versi mobile?
Nanti deh kalau ketemuan lagi, kita pastikan sama-sama, karena saya juga ragu.
Cahya,
Di WP 3.0 ada fitur: .
Ketika saya lihat tampilan ini melalui ponsel, tulisan di bagian konten terlalu ‘mepet’ ke kiri. Paddingnya kurang mas.
rismaka,
Memang sedang tidak memakai CSS handheld sama sekali. Terima kasih informasinya.
Sepertinya kita sependapat… Hehe
Meskipun hanya bisa menggunakan simulator sih… :D
Bli Dani,
apa dampaknya dengan mengubah
ul
li
menjadi hanya menggunakan tagp
?menghilangkan
position
,display
,float.
? pekerjaan rumah lagi.penggunaan
em
dan%
, lebih disarankan?Pak Aldy, dengan penggunaan ukuran relatif memungkinkan kita untuk membuat layout yang fleksibel di berbagai ukuran layar. Contoh website yang menerapkan “resizing nirvana” adalah websitenya Jon Hicks.
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 tagul
.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?Pak Aldy,
Ya, 2 atau lebih. Yang saya lakukan memang karena mengakomodasi versi mobile. Seperti saya jelaskan di konten.
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.
Konten ini telah saya perbarui dengan merujuk tulisan Bruce Lawson di dev.opera.com.
Owh, salah satu solusinya menggunakan Media Query ya… :)