Pertimbangan Penyederhanaan Blog

Noted: Wednesday, July 28, 2010 at 02:07:17. Words count: 497.
Last updated: Monday, November 19, 2012 at 10:04:09.

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.

Dani Iswara, [myfirstnamelastname]@gmail.com.

21 comments to "Pertimbangan Penyederhanaan Blog"

  1. Cahya

    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?

  2. dani

    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.

  3. Cahya

    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.

  4. dani

    Cahya,
    Plugin WP Super Cache memang mendukung tema mobile.
    Mungkin tema situ ada versi mobile-nya terintegrasi di sisi server?

  5. Cahya

    Bli Dani,

    Bagaimana dengan dashboard WordPress yang juga memperlihatkan versi mobile?

    Nanti deh kalau ketemuan lagi, kita pastikan sama-sama, karena saya juga ragu.

  6. dani

    Cahya,
    Di WP 3.0 ada fitur: Add mobile webkit styles for twentyten theme.

  7. rismaka

    Ketika saya lihat tampilan ini melalui ponsel, tulisan di bagian konten terlalu ‘mepet’ ke kiri. Paddingnya kurang mas.

  8. dani

    rismaka,
    Memang sedang tidak memakai CSS handheld sama sekali. Terima kasih informasinya.

  9. ardianzzz

    Sepertinya kita sependapat… Hehe
    Meskipun hanya bisa menggunakan simulator sih… :D

  10. aldy

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

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

    penggunaan em dan %, lebih disarankan?

  11. ArdianZzZ

    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.

  12. dani

    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.

  13. aldy

    @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?

  14. dani

    Pak Aldy,
    Ya, 2 atau lebih. Yang saya lakukan memang karena mengakomodasi versi mobile. Seperti saya jelaskan di konten.

  15. aldy

    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 :(

  16. iskandaria

    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’.

  17. dani

    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.

  18. dani

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

  19. ArdianZzZ

    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.

  20. dani

    Konten ini telah saya perbarui dengan merujuk tulisan Bruce Lawson di dev.opera.com.

  21. ArdianZzZ

    Owh, salah satu solusinya menggunakan Media Query ya… :)