<blockquote>TL;DR: Check this website &gt; <a href="https://www.spektakel.id">spektakel.id</a></blockquote>&nbsp;Beberapa bulan terakhir, tim web <a href="https://spektakel.id">spektakel</a> melakukan persekutuan dan saling berjanji untuk membenahi website yang berkutat di ranah seni budaya Indonesia tersebut. Sejak awal dibangun, web ini menggunakan PHP dan MySql, dengan Laravel sebagai frameworknya.&nbsp;&nbsp;Seiring waktu berjalan, tim web spektakel agaknya tergiur juga untuk mencicipi framework frontend modern. Beberapa dari mereka asik menekuni Svelte, atau Vue. Beberapa yang lain lebih memilih berkutat dengan React. Pilihan framework mereka berbeda-beda, tapi keluhan mereka sama: bahwa sisi depan web spektakel yang dibangun dengan laravel, dengan tambalan jQuery di sana-sini, dengan Bootstrap, membuat website ini terasa sangat jadul. Para developer yang sudah demikian dimanja oleh kenyamanan framework modern ini bersepakat, “ayo pindah ke Next.js, biar developingnya enak!”.&nbsp;&nbsp;Dipilihnya Next.js karena kami semua kebetulan pernah bekerja dengan framework tersebut.&nbsp;Maka keinginan tersebut saya kabulkan. Lalu perkara berikutnya muncul. Kita mulai dari mana proses pindahannya?&nbsp;<h3>Proses Pindahan: Membentuk Tim, Menyepakati Cara Bekerja</h3>&nbsp;Hal yang pertama-tama dan yang utama adalah: menyepakati cara bekerja. Hal ini menjadi penting dalam konteks tim web spektakel. Kami semua sedang dalam posisi bekerja di kantor yang berbeda-beda. Jadwal bekerja kami pun berbeda-beda. Tapi terima kasih kepada metode Scrum, kami boleh mengambil sedikit insight dari situ. Seminim-minimnya, melihat tumpukan task di kanban board yang bergeser dari in progress menjadi done adalah mood booster jua.&nbsp;&nbsp;Saya menunjuk seorang kolega untuk mengawasi kami bekerja. Kolega tersebut yang nantinya bertugas memastikan bahwa cara bekerja ini berjalan dan tidak ada task yang diam berlama-lama dengan status backlog atau open.&nbsp;&nbsp;Setelah dijelaskan secara singkat dan sangat umum mengenai scrum, kami juga saling menyepakati tentang terma-terma yang akan dipakai: apa yang dimaksud dengan sprint, apa itu feature, apa itu bugfix, hotfix, kapan perlu QA, kapan sebuah task bisa dinyatakan done, dan sebagainya. Bagian yang paling kami tekankan adalah memilah-milah, yang manakah dari tumpukan task ini yang menjadi prioritas.&nbsp;Meeting pertama berjalan cukup lancar. Kami berhasil membuat rencana. Sprint 1 akan memuat apa saja, sprint 2, sprint 3, dan seterusnya.&nbsp;Maka diputuskanlah: tiap malam, pukul 20:30 kami perlu melakukan meeting singkat, lima belas menit. Dengan video call. Tidak banyak yang dibahas. Hanya membahas blocker, issue, dan progress.&nbsp;<h3>Proses Pindahan: Coding</h3>&nbsp;Dalam proses pindahan dari Laravel ke Next JS ini, saya dengan sangat terpaksa mesti mengulik-ngulik backend. Mengubah return dari tiap-tiap controller yang biasanya dilemparkan ke view, menjadi JSON. Tidak lupa pula meng-upgrade Laravel ke versi yang terbaru. Juga membuat action di git supaya ada proses CI/CD ke server hosting. Asik juga sih.&nbsp;Selepas endpoint-endpoint siap dikonsumsi, mulailah kami berkutat dengan per-frontend-an. Seperti kata Aan Mansyur: Melihat API Bekerja.&nbsp;Satu demi satu API dikonsumsi. Satu demi satu task bergeser, siap ditest QA, lalu dinyatakan selesai. Proses yang cukup melegakan.&nbsp;&nbsp;Dilihat dari segi waktu, proses ini cukup efisien juga. Karena kami sudah tahu betul bentuk akhirnya akan seperti apa, dan fungsi yang dibuat akan menghasilkan apa, proses coding jadi mudah. Selepas jam kantor, biasanya kami akan mulai coding untuk spektakel. Sejam atau dua jam, lalu meeting rutin lima belas menit pukul 20:30.&nbsp;&nbsp;Dengan cara kerja seperti itu, harapannya semua orang berada di laman yang sama, tidak ada saling curiga satu sama lain. Semua orang bekerja dalam kapasitas masing-masing. Ada issue atau blocker, bukan masalah. Ungkapkan saja waktu meeting. Jika estimasi waktu pengerjaan meleset, kembalikan saja ke backlog. Riset-riset lagi, coba-coba solusi lagi. Push ke development server. Jika lolos test QA, push ke staging. Ketika semua sudah siap, merge staging ke production.&nbsp;Perlu kira-kira tiga bulan bagi kami untuk akhirnya siap rilis produksi tahap pertama. Barangkali terlihat lamban, tapi buat apa ngebut-ngebut kalau developer-nya malah jadi cape?&nbsp;Kira-kira begitulah.&nbsp;Monggo dicek hasil dari proses tersebut: <a href="https://spektakel.id">spektakel.id</a>. Sebuah web tentang Seni Budaya Indoensia. Expect some bugs. Lemme know if you find one. Ciao!

Pindahan Laravel ke Next JS

Beberapa bulan terakhir lini masa kita tentu dihujani dengan emoji-emoji berbentuk kotak, dengan warna hijau, kuning, dan putih. Saya termasuk pelakunya. Tentu saya sedang membahas <a href="https://www.nytimes.com/games/wordle/index.html">wordle</a> dan <a href="https://katla.vercel.app/">katla</a>. Dua permainan teka-teki sederhana, yang tiba-tiba membuat banyak sekali manusia menghadapi satu persoalan yang sama: apa gerangan kata hari ini? Ditambah lagi dengan ide untuk membagikan emoji warna-warni itu brilian. Imut, lucu, mudah dimengerti, cemerlang sudah. Pada dasarnya manusia memang mahluk komunal bukan?&nbsp;Saya latah ikut-ikutan bikin, versi Bahasa Jawa. Silakan coba disini: <a href="https://katlo.vercel.app/">Katlo | Wordle Boso Jowo</a> &nbsp;Tapi kemudian saya melihat tweet ini:&nbsp;&nbsp;<div class="raw-html-embed"><blockquote class="twitter-tweet">❓If you are a javascript developer, are you able to build a project in vanilla JS? Without any framework or library (like React)❓— Magdalena (@makneta) <a href="https://twitter.com/makneta/status/1494408393515274246?ref_src=twsrc%5Etfw">February 17, 2022</a></blockquote> <script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></div>&nbsp;&nbsp;Membuat sebuah project dengan Vanilla JS? Tanpa framework? Tentu saja bisa. &nbsp;Proyek game mini seperti wordle misalnya, tentu bisa dibuat dengan vanilla JS. Banyak juga yang coba membuat tutorialnya (yah, namanya juga game viral, konten kreator yang cekatan tentu langsung mengambil hikmahnya). Misalnya <a href="https://www.youtube.com/watch?v=mpby4HiElek">channel ini</a>, <a href="https://www.youtube.com/watch?v=j7OhcuZQ-q8">ini</a>, atau <a href="https://www.youtube.com/watch?v=Wak7iN4JZzU">ini</a>. Mereka semua memakai vanilla JS dan CSS untuk membuat game wordle sederhana.&nbsp;&nbsp;Ada juga yang menyediakan repository open source, siap pakai, tinggal ganti list kata-kata yang ingin dipakai sebagai sumber teka-teki. Berbasis react kalau tidak salah.&nbsp;Niat saya membuat adaptasi <a href="https://katlo.vercel.app/">wordle bahasa jawa</a> itu juga kurang lebih dipicu oleh tweet mbak Magdalena tersebut. Semakin tertarik ketika melihat bagaimana wordle yang dibeli New York Times itu tetap tidak mengubah apapun di coding-nya. Jawaban dan deret kata-kata tetap disimpan di tempat yang sama, tidak ada fetching. Semua yang menyenangkan di dalam game tersebut, dilayani oleh javascript dan browser.&nbsp;Ketika pertama kali mengoprek, saya memang tidak pakai framework apa-apa. Cuma HTML dan CSS. Sekali dua kali masih harus buka-buka dokumentasi lagi soal CSS grid.&nbsp;&nbsp;Bagaimana membuat papan yang memuat tebakan, bagaimana membuat keyboard, semua pakai CSS grid. Bagimana tiap kotak akan memiliki animasinya masing-masing, berputar, bouncing, jumping, juga dengan CSS. Dalam proses ini saya jadi teringat kenapa dulu sempat jatuh hati pada per-Frontend-an, tidak lain tidak bukan ya karena interaksi-interaksi kecil semacam ini. Melihat apa yang kita ketik di editor, muncul di layar sebagai elemen warna-warni.&nbsp;Kemudian masuk ke sisi interaksi, mulailah kita menuliskan baris-baris JavaScript. Tapi kemudian ditengah jalan, saya merasa bosan juga menulis querySelector. Pakai framework tentu lebih enak dan cepat. Pilihan saya jatuh ke svelte. Untuk SPA model wordle begini, Svelte jelas sangat mumpuni.&nbsp;&nbsp;Yang paling menarik buat saya di bagian interaksi ini adalah soal algoritma sederhananya untuk membuat kotak-kotak di papan berubah warna sesuai state-nya, apakah huruf tersebut sudah benar letaknya (hijau), apakah masih meleset (kuning), atau huruf tersebut tidak ada dalam kata (kelabu), untuk kemudian menambahkan delay di kotak-kotak tersebut sehingga animasinya terkesan berjalan dari kiri ke kanan.&nbsp;Saya sempat terkecoh disitu. Misalnya ketika kata yang harus di tebak adalah ‘aroma’, dan jawaban yang saya berikan adalah ‘agama’:&nbsp;A, R, O, M, AA, G, A, M, A&nbsp;Tantangannya adalah membuat kotak untuk huruf ‘A’ di posisi ketiga mempunyai warna kelabu, bukan kuning. Persoalan sederhana, yang seperti wordle itu sendiri, menyenangkan untuk dipecahkan.&nbsp;Setelah masalah tampilan dan algoritma terpecahkan, muncullah perkara berikutnya. Karena saya berniat membuat versi bahasa jawa, tentu saya butuh banyak sekali kata-kata bahasa jawa yang terdiri atas lima huruf. Di sela-sela waktu luang, saya sempat mencoba scrapping satu hingga dua sumber, tapi hasilnya masih terlalu sedikit (cuma 700 kata)….&nbsp;Sampai kemudian saya menemukan repositori ‘<a href="https://batangan.lantip.xyz/">Batangan</a>’. Mantab. Kamus Jawa-nya disitu cukup lengkap, ada ribuan entri. Setelah meminta ijin kepada yang empunya repositori, langsung saya pasang datanya. Sip. Selesai. Beres. I'm happy.&nbsp;&nbsp;Kira-kira begitulah. Ada perasaan nostalgia menyeruak kalau sedang luang lalu mengulik sebuah proyek yang iseng. Nostalgia tentang masa-masa memandang browser dengan penuh rasa takjub. Tapi tentang hal ini, barangkali saya saja yang terlalu sentimentil.&nbsp;N.B&nbsp;Jika kamu membaca ini dan belum mendengar wordle, atau katla, silakan meluncur:&nbsp;<a href="https://www.nytimes.com/games/wordle/index.html">Wordle - The New York Times (nytimes.com)</a><a href="https://katla.vercel.app/">Katla - Permainan Tebak Kata | 1 Hari 1 Kata 6 Kesempatan</a><a href="https://katlo.vercel.app/">Katlo | Wordle Boso Jowo</a><a href="https://batangan.lantip.xyz/">Batangan (lantip.xyz)</a>

Hal-hal menyenangkan ketika ngoprek-ngoprek wordle

Kadang-kadang sebuah pertanyaan yang dilontarkan sekelebatan, bisa membuat saya merenung-renung sampai beberapa hari. Begitulah pada suatu hari Jumat yang panas tapi lembab, jam sudah menunjukkan pukul 4 sore, satu jam lagi kita akan menekan tombol clock out untuk mengakhiri hari kerja, lalu menikmati akhir pekan. Kami sedang bercakap-cakap di google meet, agendanya untuk membahas sebuah bug issue, tapi pokok pembicaraan hanya terjadi sepanjang lima menit, selebihnya, kami bercakap-cakap tentang apa saja, sekadar melawan bosan dan sepi akibat WFH.&nbsp;"Udah nyoba remix, mas?"&nbsp;Ketika mendengar pertanyaan ini untuk pertama kali, kepala saya terlempar ke beberapa tahun silam, ke sebuah distro linux yang berniat memindahkan experience OS Android ke PC. Meski sesaat kemudian saya tersadar konteksnya, dilontarkan oleh sesama frontend developer, tentu maksud pertanyaannya adalah tentang framework JavaScript yang lagi naik daun.&nbsp;"Udah," saya menjawab singkat. "Nggak suka, euy. Aku tetep lebih suka Svelte. Gondrong-gondrongnya Rich Harris juga pas banget gayanya."&nbsp;Teman saya tertawa. Tapi saya tidak sedang bercanda. Menjatuhkan pilihan pada sebuah framewok tertentu, diluar tuntutan pekerjaan, menurut saya baiknya juga dipengaruhi oleh cara berpikir para pembuatnya. Gaya, gambaran mental, serta sejarah tentang orang-orang yang mengerjakan proyeknya, termasuk ranah yang asik untuk diikuti. Selain Rich Harris, saya juga suka Evan You, yang membikin Vue dan Vite. Evan You, dia adalah penggemar anime garis keras. Dia tidak segan untuk menampakkan diri dengan citra tersebut. Bahkan sejauh ini, rilisan-rilisan VueJS selalu diluncurkan dengan banderol judul-judul anime. Vue 3.0, sebagai rilisan yang terbesar, diberi nama One Piece. Layak sekali, bukan.&nbsp;<figure class="image"><img src="https://res.cloudinary.com/de2ofvts5/image/upload/v1643420636/blog/2169c4d4afc10612b680aa089a82ad92_viwyv3.png"><figcaption>keren</figcaption></figure>&nbsp;Mencari tahu lebih dalam soal siapa-siapa sosok dibalik teknologi tertentu, apalagi open source, semestinya wajar dan perlu.&nbsp;Mengikuti cuitan-cuitan mereka, serta cuap-cuap mereka yang kadang berseliweran di youtube, kita kadang bisa melihat sedikit karakteristik yang menonjol dan berbeda satu sama lain. Setidaknya, dengan demikian, kita tidak memilih sebuah framework hanya karena FOMO, atau karena dengungannya begitu kencang di lingkar-lingkar sekitar. Atau lebih parah lagi, memakainya tanpa mengerti betul alasannya.&nbsp;Terkait ini, saya teringat pula tentang faker.js. Sebuah package populer di npm untuk membuat data-data dummy. Beberapa pengguna setianya bingung ketika suatu hari, repository faker.js mendadak kosong, dan terdapat sebuah commit dengan judul pesan "endgame", dan di berkas Readme terdapat pesan singkat: "What really happened with Aaron Swartz?"&nbsp;Aaron Swartz, kawan-kawan bisa googling sendiri soal yang satu ini. Sebuah kisah tragis tentang seorang pemuda cemerlang yang berjasa besar bagi kultur dan kegembiraan berinternet.&nbsp;Banyak berita melaporkan bahwa beberapa bulan sebelumnya, Marak Squier, pembuat faker.js, pernah mengutarakan keinginannya untuk memonetasi proyek bikinannya itu.&nbsp;"Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work. There isn't much else to say. Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it," tulis Squier di sebuah <a href="http://web.archive.org/web/20210704022108/https://github.com/Marak/faker.js/issues/1046">github issue</a>.&nbsp;Ironis. Sebuah package yang dipakai oleh banyak sekali manusia. Entah berapa banyak perusahaan besar maupun kecil memakainya untuk melakukan API testing. Tapi tidak ada skema yang mendukung proyek tersebut untuk sustain. Sayangnya di dunia open source, sering kali kita hanya memakainya, tanpa peduli amat kepada pembuatnya. Berapa banyak dari kita sehabis mengetik npm install lalu mengabaikan pesan di terminal bahwa beberapa project yang termaktub didalamnya dengan jujur mengaku jika mereka membutuhkan donasi?&nbsp;Yah, donasi bisa membantu, tapi yang namanya sumbangan, tentu tidak berkelanjutan... runyam nian…

Tak Kenal, Tak Sayang, Pikiran Singkat (dan Kabur) tentang Open Source

Ada kalanya website yang sudah kita bikin dengan susah payah, berakhir dengan lemot ketika diakses. Penyebabnya bisa bermacam-macam, bisa diaudit dengan <a href="https://web.dev/measure/">lighthouse</a> dan semacamnya.&nbsp;Salah satu yang paling umum, besarnya ukuran file gambar yang harus dimuat ketika website tersebut diakses.&nbsp;Pertolongan pertama, tentu dengan mereduksi ukuran asset gambar. Gambar yang hanya akan muncul sebagai thumbnail misalnya, pastinya tidak perlu besar-besar amat ukurannya.&nbsp;Pertolongan berikutnya, bisa mencoba optimasi dari segi HTML ataupun CSS.&nbsp;<h3>CSS image-set()</h3>&nbsp;Strategi optimasi dengan CSS ini bisa dilakukan apabila gambar yang dimaksud merupakan gambar background. Sederhananya begini: image-set() memungkinkan kita untuk memberi opsi kepada client untuk memuat gambar yang sudah di-optimasi sedemikian rupa dan disimpan dalam format next-gen image.&nbsp;Apa itu next-gen image?&nbsp;<blockquote>Next-gen images use formats with superior compression and quality characteristics compared to their GIF, JPEG, and PNG ancestors. These image formats support advanced features designed to take up less data while maintaining a high quality level, making them perfect for web use.</blockquote>&nbsp;Jadi format gambar yang kita sediakan untuk client perlu diformat ulang sebagai next-gen image. Bisa sebagai file WEBP, ataupun AVIF.&nbsp;Converter untuk kedua format tersebut bisa diakses disini:<ul><li>- <a href="https://avif-converter.online/">Avif converter</a></li><li>- <a href="https://cloudconvert.com/webp-converter">Webp converter</a></li></ul>&nbsp;Tapi pekerjaan kita belum selesai disitu.&nbsp;Next-gen image adalah teknologi yang masih terhitung baru, sehingga besar sekali kemungkinan peramban yang digunakan untuk mengakses website belum mengenali format gambar generasi baru tersebut.&nbsp;Di titik ini lah kita butuh css image-set().&nbsp;Syntax nya seperti ini:<figure class="image"><img src="https://res.cloudinary.com/de2ofvts5/image/upload/v1626007171/blog/carbon_bho3bq.png"></figure>&nbsp;&nbsp;Contoh pemakaiannya:&nbsp;<figure class="image"><img src="https://res.cloudinary.com/de2ofvts5/image/upload/v1626007236/blog/carbon_1_awi3jr.png"></figure>&nbsp;&nbsp;Bisa dilihat dari contoh diatas, kita tetap memerlukan 'background-image' dengan syntax standar url(), karena sepertinya memang belum ada fallback yang bisa dipakai untuk sintaks image-set() ini.&nbsp;Pemakaian -webkit-image-set() juga tetap kita perlukan untuk mengantisipasi peramban yang belum kompatibel.&nbsp;Sintaks diatas akan dibaca oleh peramban, kira-kira seperti ini: jika peramban bisa memuat generasi terbaru, dia akan memuatnya. Jika tidak, dia akan memuat versi .jpg. Atau jika peramban sama sekali tidak mengenal sintaks image-set(), dia akan membaca sintaks url(), yang sudah pasti dia kenali.&nbsp;<h3>HTML &lt;picture&gt; tag</h3>&nbsp;Bagaimana jika gambar tersebut bukan gambar background, melainkan yang biasanya kita tampilkan dengan tag &lt;img&gt; ?&nbsp;Di HTML, sudah ada tag &lt;picture&gt; yang tampaknya sudah disupport oleh banyak browser.Contoh pemakaiannya seperti ini:&nbsp;<figure class="image"><img src="https://res.cloudinary.com/de2ofvts5/image/upload/v1626007385/blog/carbon_3_qdbcqp.png"></figure>&nbsp;&nbsp;Dengan penulisan tag tersebut, browser pertama-tama akan mencoba membuka file 'balloon.avif'. Jika format tersebut tidak dikenali, browser akan memuat 'balloon.jpg', yang pastinya dia kenali.&nbsp;<h3>Penutup</h3>&nbsp;Saya pribadi jarang sekali memakai gambar sebagai background. Otomatis, saya jarang sekali menggunakan css image-set().&nbsp;Saya jauh lebih sering menggunakan tag &lt;picture&gt; dalam hal ini. Pun, ketika dari segi desain kita membutuhkan gambar sebagai background, saya tetap memakai &lt;picture&gt; tag.&nbsp;Bukan apa-apa, seringnya kasus yang terjadi adalah kita sebagai frontend hanya menerima data entah dari fetch API ataupun render views PHP. Jadi strategi yang paling sering saya gunakan adalah membungkus &lt;picture&gt; dalam sebuah parent element.&nbsp;Parent element tersebut diberi position: relative, dengan dimensi width dan height yang konsisten (misalnya dengan memberi padding-top: 56.75% untuk mendapatkan aspect-ratio 16:9). Kemudian tag &lt;img&gt; tersebut kita beri position: absolute dengan width dan height sebesar 100%, serta tidak lupa memberinya object-fit: cover. Strategi ini akan memaksa gambar yang bersangkutan untuk mengisi seluruh space parent element, efeknya sama saja seperti layaknya gambar background.&nbsp;Kira-kira demikian. Selamat mencoba.

Website Lemot, Mungkin Ini Bisa Membantu: Image-set

Banyak diantara teman-teman tahu (lebih banyak lagi yang tidak), bahwa sejak 2016, saya mendedikasikan sebagian besar waktu untuk mengembangkan sebuah platform web untuk seni budaya Indonesia. Web tersebut bisa diakses di sini: <a href="https://spektakel.id">https://spektakel.id</a>&nbsp;Di tahap awal pengembangan web spektakel, tadinya web tersebut dibangun dengan Native PHP - mySql, tanpa framework, dengan tambalan jQuery di banyak tempat. Secara fungsi, awalnya web spektakel bertujuan untuk mendata acara-acara seni budaya dari seluruh Indonesia, mulai dari kegiatan festival budaya, tradisi, ritual, sampai gigs Punk Rock underground yang terdapat di balai desa nun jauh di pelosok.&nbsp;Seiring berjalannya waktu, spektakel juga mulai mengeluarkan produk yang terkait dengan wisata seni budaya, kami namai sebagai Plesir!. Di luar itu, kami juga rutin menulis isu-isu ringan terkait budaya Indonesia, utamanya tentang budaya di ranah keseharian masyarakat. Outlet artikel-artikel ini di tempatkan di platform blog.&nbsp;Mengelola tiga subdomain yang berbeda adalah hal yang cukup merepotkan. Memantau performa, analytics, optimasi search console, dan sebagainya. Tercetuslah ide untuk melakukan perombakan besar-besaran untuk platform ini. Saya ingin menyatukan semua produk spektakel dalam satu atap, sekaligus membangunnya dengan framework demi kemudahan pengembangan skala besar ke depan.Ya, kami tidak melakukan revamp, melainkan redesign.&nbsp;<blockquote>Redesigning VS Revamping<blockquote>Firstly, when talking about a website redesign we are referring to a complete overhaul of the site. Assessing it’s navigation, it’s design, it’s call to actions – really everything that could be re-assessed with a view to giving a more effective user experience.</blockquote> &nbsp;<blockquote>With a revamp, your website structure could remain the same or maybe some new pages, corporate colours etc could be incorporated. It’s about giving your site a more up-to-date look and tweaking bits here and there to make it perform better or serve a purpose. For example, in winter we revamp several of our e-commerce website with a Christmas theme to put customers in a Festive mood, this is a temporary revamp and will see the site returned to normal in Spring.</blockquote></blockquote>&nbsp;<h3>&nbsp;</h3><h3>Before Redesign</h3>&nbsp;Ini penting! Sebelum proses mendesain dimulai, kami melakukan doa bersama terlebih dahulu. Biar berkah.&nbsp;Berikutnya adalah mulai menentukan struktur baru website. Akan seperti apa fungsi web dengan bentuk baru ini? Dalam konteks platform web spektakel yang sudah berjalan sebagai direktori kegiatan budaya, bagaimana data yang ada diperlakukan? Bagaimana dengan bentuk konten baru seperti artikel, foto, serta video? Bagaimana dengan kemungkinan membuka akses bagi member untuk mengirimkan tulisan, foto, dan sebagainya?&nbsp;Pertanyaan-pertanyaan di atas cukup panjang juga proses pengambilan keputusannya. Setelah beberapa kali rapat, akhirnya baru bisa mulai terlihat berbagai kemungkinan struktur website nya. Dari hasil rapat-rapat itu, tampak jelas bahwa struktur database konten akan sangat berubah. Relasi-relasi antar tabel banyak juga yang berubah. Salah satu relasi tabel yang sangat merepotkan saat itu ialah relasi tabel user dan konten. Karena awalnya, web spektakel hanya melakukan input dari sisi admin, sedangkan di bentuk baru ini, entry bisa dilakukan oleh siapa saja yang mendaftar. Tugas admin dan editor adalah mengkurasi semua entry tulisan atau foto yang diunggah oleh pengguna.&nbsp;<h3>Mulai Mendesain</h3>&nbsp;Setelah struktur berhasil dikunci, tahap mendesain baru bisa dilakukan. Kami mulai menentukan prioritas-prioritas sesuai dengan hierarki informasi yang telah disepakati. Mana bagian yang harus tampil di bagian above the fold? Blok informasi apa yang harus muncul setelahnya? Apa panggilan aksi nya? Bagaimana konten video ditampilkan di halaman muka? Bagaimana dengan menu?&nbsp;Karena struktur sudah dikunci terlebih dahulu, semua pertanyaan terkait keputusan desain tersebut bisa lebih mudah dijawab. Dalam proses mendesain kami jadi lebih leluasa untuk bermain di style dan identitas produk. Kami masih menerapkan pola lama dalam mendesain web ini, belum memakai design system, atau memutuskan desain dengan paradigma atomic design, misalnya.&nbsp;<blockquote>A Design System is the single source of truth which groups all the elements that will allow the teams to design, realize and develop a product.</blockquote> &nbsp;<figure class="image"><img src="https://media-exp3.licdn.com/dms/image/C5112AQEG92DG_daN2g/article-inline_image-shrink_1500_2232/0/1585035853460?e=1631145600&amp;v=beta&amp;t=aQTakPZuo5ldDsqZ_DRVv2WyGNWaYL-KRsBLCPNWo2E"></figure><figure class="image"><img src="https://media-exp3.licdn.com/dms/image/C5112AQEzClSCMohP4g/article-inline_image-shrink_1500_2232/0/1585036944614?e=1631145600&amp;v=beta&amp;t=j8xyXC7Z7f98FiINjGcCovWIMAq_XjWNpyVfByp55Cw"></figure><h3>&nbsp;</h3><h3>Dari Desain ke Coding</h3>&nbsp;Proses desain dan coding sebetulnya berjalan secara simultan. Walaupun memang untuk bagian front-end harus menunggu desainnya dikunci dulu.&nbsp;Untuk framework, kami memilih menggunakan Laravel. Fitur-fiturnya modern, salah satu framework MVC yang paling mudah dipelajari. Lagipula untuk kemudahan kerja kolaborasi, Laravel masih jadi pilihan yang sangat baik. Belum lagi kemudahannya untuk dikembangkan bersama Vue, dan fitur mixing nya yang memudahkan mengkompilasi file-file css serta js.&nbsp;Yang menjadi salah satu tantangan terberat kami dalam proses awal redesign adalah pemindahan database, serta penyesuaiannya dengan struktur baru. Seperti yang telah disebut sebelumnya, akan ada banyak relasi antar tabel yang mesti dibuat. Untungnya Laravel menawarkan banyak kemudahan dalam membuat relasi antar model, baik one to one, one to many, maupun many to many.&nbsp;Salah satu hal yang saya syaratkan dalam pengerjaan pemindahan database baru ini adalah menyepakati semua nama tabel, model, serta controller sesuai dengan konsensus yang umum dipakai oleh komunitas Laravel. Ini untuk memudahkan kerja-kerja kolaboratif di kelak kemudian hari.Keseluruhan proses dari mulai rapat konsep, mulai mendesain, hingga koding, kurang lebih memakan waktu satu tahun lamanya. Itu pun karena terbentur oleh pekerjaan-pekerjaan lain. Proses yang panjang, melelahkan, namun menyenangkan.&nbsp;<h3>Penutup</h3>&nbsp;Pelajaran penting yang bisa saya ambil dari semua proses ini: (1) Menentukan arah produk itu mesti disepakati dan ditaati sejak awal. (2) Tidak ada ide yang brilian. Sesederhana apapun sebuah ide, kalau eksekusinya baik, itu sudah sangat bagus. (3) Bekerja dengan framework yang telah teruji, dengan komunitas yang berkembang dan aktif. Sebagai developer, kita tidak perlu pusing sendirian. Komunitas yang aktif sangat membantu dalam memecahkan masalah. (4) Taati konsensus, penamaan nama model, class, controller, nama tabel, dan sebagainya. Ini akan memudahkan pengerjaan. Juga membantu saat memerlukan bantuan dari komunitas.&nbsp;N.BSaya berasumsi bahwa tiap design yang dibuat oleh tim kami pasti sudah memakai paradigma mobile first. Responsive web itu mutlak!

Proses Redesign Web, Sebuah Studi Kasus

DISCLAIMER: Saya bukan ahli sprint atau metode manajemen proyek lainnya. Tulisan yang akan kamu baca ini hanya menyentuh permukaan saja tentang metode Google Design Sprint.&nbsp;&nbsp;Design Sprint, metode kiwari untuk menjawab berbagai permasalahan melalui proses mendesain, prototyping, dan langsung melakukan test kepada user, hanya dalam waktu 5 hari kerja: mulai Senin, dan berakhir di Jumat. Ya, seperti orang yang berlari sprint, ngebut!&nbsp;Metode ini dikembangkan oleh Jake Knapp dari Google Venture (GV). Design Sprint memungkinkan sebuah lembaga untuk memvalidasi ide kepada target audiens nya dengan efisien dan efektif.&nbsp;&nbsp;<figure class="image"><img src="https://cdn.substack.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F2de49c26-de4c-4eb7-8f9b-92f534106554_800x600.png"><figcaption>Illustrasi &nbsp;Design Sprint</figcaption></figure>Diagram kerja Design Sprint terlihat seperti gambar di atas. Dari model tersebut, kita bisa melihat bahwa proses ini memangkas bagian Build dan Launch, menggantinya dengan proses Idea dan Learn secara simultan dan intens.&nbsp;&nbsp;<h3>Kapan kita bisa memakai metode Design Sprint?</h3>&nbsp;Kalau menurut Jake Knapp, kapanpun! Maka dengan sangat pede dia menuliskannya dalam buku berjudul: “Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.”&nbsp;Barangkali terdengar ambisius, tapi sebetulnya masuk akal.&nbsp;Kata kunci di design sprint adalah: Teamwork, Organisasi, Brainstorm, Ide, Sketch, prototype, dan test ke user. Dalam terma mereka: Understand, Define, Sketch, Decide, Prototype, dan Validate. Btw, kalau kamu ingin mencoba metode ini, pastikan dulu kamu punya tim yang enak diajak bekerja bareng. Itu salah satu kunci terpentingnya.&nbsp;&nbsp;&nbsp;<h3>Merencanakan sebuah Design Sprint</h3>&nbsp;Adakah problem dari tempat kerjamu yang bisa diselesaikan dengan sprint? Problem bisa bermacam-macam: apakah ingin meningkatkan penjualan, memperbanyak subscribers, membuat panggilan donasi untuk campaign, dan sebagainya.&nbsp;Selama ada problem yang kiranya bisa dijawab dengan produk, design sprint bisa dilakukan.&nbsp;&nbsp;Pertama-tama, tulislah brief dari problem dan buat pertanyaan yang ingin dijawab melalui sprint. Misalnya: redesign website campaign supaya lebih banyak orang mau berdonasi.&nbsp;&nbsp;<h3>Membentuk Tim Sprint</h3>&nbsp;Tim untuk sprint sebaiknya tidak terlalu besar, cukup 5 - 7 orang saja. Pastikan mereka adalah pihak yang mau berkomitmen penuh selama 5 hari kerja untuk melakukan Sprint. Sebab saat melakukan Sprint, tim ini akan dikondisikan untuk fokus kepada proses sprint, dan mengabaikan pekerjaan-pekerjaan lain. Fokus! Senin - Jumat, dari jam 10 pagi sampai Jam 5 sore.&nbsp;<blockquote>Di tulisan ini kita tidak bicara soal hari pertama, hari kedua, apa dan bagaimana, kawan-kawan bisa membaca buku Jake Knapp untuk detailnya.</blockquote>&nbsp;Idealnya, Tim Sprint ini terdiri atas UX designer, user researcher, product manager, developer, marketer, dan seorang pengambil keputusan. Tapi tidak masalah juga kalau ada orang keuangan, akuntansi, atau siapapun dalam organisasi untuk dilibatkan ke dalam sprint. Sudut pandang yang bervariasi malah akan membuat ide-ide makin kaya.&nbsp;Jelaskan kepada tim tentang agenda Sprint, bahwa selama 5 hari ke depan kita akan fokus pada satu problem nan spesifik. Pastikan juga sebelum memulai sprint, ada dua tokoh sentral yang berperan: Fasilitator, dan Decider. Fasilitator adalah orang yang mengerti organisasi secara menyeluruh, dia yang akan menggerakkan sprint, dia yang men-trigger pertanyaan-pertanyaan. Sedangkan decider, tentu saja adalah seorang yang bisa mengambil keputusan organisasi.&nbsp;&nbsp;&nbsp;<h3>6 Fase Design Sprint</h3>&nbsp;Sesuai dengan fase Understand, Define, Sketch, Decide, Prototype, dan Validate, mari coba lihat apa-apa yang perlu disiapkan dan perlu dilakukan di tiap fase nya.&nbsp;<h4>Fase 1: Understand</h4>Di fase ini, semua partisipan sprint bersama-sama mencoba memetakan masalah. Berangkat dari problem, menuju tujuan, memikirkan kemungkinan-kemungkinan proses menuju tujuan tersebut. Ada banyak metode asik yang bisa dipakai di tahap ini. Baca selengkapnya tentang Fase Understand ini dari Kit yang sudah disediakan oleh mbah Google: <a href="https://designsprintkit.withgoogle.com/methodology/phase1-understand">Phase 1 - Understand</a>&nbsp;<h4>Fase 2 : Define</h4>Di fase kedua ini, partisipan mengevaluasi temuan-temuan yang ada di fase sebelumnya, lalu memfokuskan sprint pada satu pokok masalah.&nbsp; Umumnya, di fase ini tim sudah mulai bisa membuat user story. Bagaimana skenarionya seorang user bisa memakai produk ini dan menuju ke Goal yang telah ditetapkan.&nbsp;Baca selengkapnya dari kit mbah Google: <a href="https://www.ipsoa.it/documents/impresa/contratti-dimpresa/quotidiano/2020/05/01/def-fase-2-previsioni-governo-uscire-emergenza-covid-19">Fase 2 - Define</a>.&nbsp;<h4>Fase 3 : Sketch</h4>Barangkali ini bagian paling menyenangkan dari design sprint. Kita sudah punya peta masalah, kita sudah punya user story, mari kita mulai sketching tiap-tiap bagian prosesnya. Ga usah pakai software apapun. Cukup kertas dan pensil. Ga perlu bagus-bagus amat sketchnya. Proses ini adalah untuk menuangkan ide ke dalam bentuk visual, supaya tidak melulu abstrak. Mencontoh solusi dari berbagai produk lain pun tak masalah, malah disarankan. Tapi, jangan berhenti, terus keluarkan ide sketchingnya.&nbsp;Lihat apa dan bagaimana Fase 3 ini: <a href="https://designsprintkit.withgoogle.com/methodology/phase3-sketch">Sketch</a>.&nbsp;<h4>Fase 4 : Decide</h4>Fase keempat ini tim sudah mulai fokus ke arah prototype. Dari sketch yang telah dibuat sebelumnya, masing-masing akan mempresentasikannya dalam waktu tiga menit saja per orang. Semua sketch dihamparkan, lalu semua partisipan melakukan voting di sketch-sketch tersebut. Sketsa-sketsa yang mendapat vote terbanyak, terpilih menjadi fokus sprint, lalu menjadi basis bagi prototype.&nbsp;Ada beberapa metode dari mbah Google, silakan dibaca-baca: <a href="https://designsprintkit.withgoogle.com/methodology/phase4-decide">Fase 4 - Decide</a>.&nbsp;<h4>Fase 5 : Prototype</h4>Membangun prototype biasanya memakan waktu lama, bisa berminggu-minggu, bahkan berbulan-bulan. Tapi dalam Design Sprint, kita cuma melakukannya dalam satu hari. Figma, Adobe XD, bahkan tools seperti Invision atau Marvelapp bisa dipakai untuk membuat prototype sederhana.&nbsp;&nbsp;Prototype disini bukan produk yang sudah siap pakai dengan fungsi penuh. Cukup fungsi-fungsi sederhana saja. Jangan terlalu khawatir pada estetika di tahap ini. Prototype ini mengacu pada sketsa-sketsa yang telah dibuat pada fase-fase sebelumnya. Artinya, kita fokus pada user flow, klik ini akan lari kesitu, dan sebagainya. Tidak perlu coding, semua aplikasi yang disebut di atas bisa melakukan itu semua.&nbsp;<h4>Fase 6 : Validate</h4>Barangkali ini fase paling penting dalam Design Sprint. Fase final, mempertemukan prototype dengan target pengguna. Lagi-lagi, target user untuk testing juga tidak perlu banyak-banyak. Lima orang saja cukup. Tapi kita harus betul-betul memperhatikan tiap gestur mereka ketika bersentuhan dengan prototype produk.&nbsp;&nbsp;Apapun respon mereka, baik atau buruk, percayalah proses sprint ini tidak sia-sia.&nbsp;&nbsp;Jika target user menilai ide produk kamu ini konyol dan tidak masuk akal, itu kabar baik. Artinya kamu tidak perlu repot-repot menginvestasikan waktu, tenaga, dan uang untuk membangun produk yang ternyata tidak disukai user.&nbsp;Jika target user menilai ide produk kamu ini baik dan bisa berguna, itu jelas kabar baik. Artinya kamu bisa sesegera mungkin memoles prototype itu menjadi produk betulan.&nbsp;&nbsp;<h3>Penutup</h3>&nbsp;Demikianlah menyoal Design Sprint. Sebuah metode kilat, melelahkan, tapi bisa membantu untuk memvalidasi ide produk. Intinya begini, kalau ide produkmu tidak valid di mata target penggunanya, sebaiknya tidak perlu buang waktu dan tenaga untuk mengembangkannya lebih jauh. Kalau nekat, ya tidak mengapa juga sih, cuma, jangan mengeluh kalau terasa berat dalam perjalanannya :)&nbsp;RESOURCES<ul><li><a href="https://www.gv.com/sprint/">GV’s Design Sprint</a></li><li><a href="https://www.ideo.com/blog/5-tips-for-running-a-successful-design-sprint">IDEO’s 5 tips for running a design sprint</a></li></ul>

Sekilas tentang Design Sprint, Metode Ngebut bikin Prototype

Dalam beberapa tahun terakhir ini terdapat perkembangan pesat yang sangat membantu dalam kerja-kerja UI/UX design serta implementasinya ke dalam koding untuk membuat prototype produk digital.&nbsp;Kita tidak hanya bicara tentang framework, melainkan juga tentang tools yang bisa digunakan dalam kerja-kerja kreatif ini. Kabar baiknya: kebanyakan tools ini gratis!&nbsp;Mari kita unduh dan install satu per satu.&nbsp;<h3>Design&nbsp;Tools</h3>&nbsp;Dalam pandangan kustomer, produk dan desain adalah satu kesatuan. User experience sebaiknya sudah kita rencanakan sejak awal mula pengembangan desain. Tools berikut ini membantu kita untuk memudahkan membuat konsep protoype dengan cepat.&nbsp;<h4>Adobe XD</h4>&nbsp;Jika kamu sudah punya sedikit gambaran tentang bagaimana rupa atau bentuk produk digital yang kamu ingin buat, langkah berikutnya adalah bagaimana visualisasinya. Adobe XD adalah tools yang sangat mudah digunakan untuk tahap ini. Apakah kita berniat membuat sekadar wireframe atau bahkan MVP (minimum viable product), Adobe XD dibuat dengan maksud untuk memudahkan kerja-kerja tersebut.&nbsp;Sejauh ini pengalaman saya menggunakan Adobe XD dalam rangka membuat konsep produk digital (UI/UX design), aplikasi ini jauh lebih intuitif dan ringan digunakan dibanding Adobe Illustrator, atau Photoshop.&nbsp;Adobe XD ini gratis. Tersedia untuk MacOS serta Windows. Buat pengguna Linux, sabar ya… :)&nbsp;Silakan unduh disini: <a href="https://www.adobe.com/sea/products/xd.html">Adobe XD</a>&nbsp;<h4>Figma</h4>&nbsp;Figma mirip seperti Adobe XD, bedanya, aplikasi ini tersedia di cloud. Kamu bisa mengaksesnya via browser (saran saya sih pakai chrome). Jadi, kamu tidak perlu install apapun di laptop atau PC. Selama ada akses internet, Figma bisa menjadi tools andalan dalam membuat prototype atau wireframe.Sama seperti Adobe XD, Figma juga dilengkapi dengan dukungan banyak plugins yang memudahkan pembuatan prototype. Banyak pula komunitas design &amp; development yang mulai beralih ke Figma.Kabar terakhir, tim desain dari <a href="https://spotify.design/articles/2020-04-20/how-spotify-works-in-figma/">Spotify juga mulai beralih haluan ke Figma</a> untuk memudahkan kerja-kerja kolaboratif mereka.&nbsp;Kunjungi website-nya di sini: <a href="https://www.figma.com/">Figma</a>&nbsp;&nbsp;<h3>Development</h3>&nbsp;Selain membuat prototype desain, jika berbicara soal design &amp; development tentunya kita juga bicara soal peranti yang sudah menjadi standar umum bagi para developer profesional. Berikut ini adalah beberapa diantaranya.&nbsp;<h4>Visual Studio Code</h4>&nbsp;Visual Studio Code (sering disebut dengan VS Code), adalah program text editor besutan Microsoft yang gratis untuk diunduh. Text editor ini ringan dan didukung oleh banyak addons yang membantu koder untuk membangun aplikasi dengan kode yang lebih rapi, readable, dan taat konsensus.&nbsp;Unduh di sini: <a href="https://code.visualstudio.com/">VS Code</a>&nbsp;<h4>Github – Code&nbsp;Management</h4>&nbsp;Github adalah surganya para developer. Di sini, para developer saling berbagi repository kode aplikasi yang mereka bangun. Banyak aplikasi open source dikembangkan dengan bantuan kerja kolaboratif melalui Github.&nbsp;Mendaftar di Github adalah hal yang sudah menjadi norma standar bagi mereka yang terjun ke dunia development.&nbsp;Daftar di sini: <a href="https://github.com/">Github</a>&nbsp;Untuk lebih memahami bagaimana bekerja dengan Github, sebaiknya kita juga mempelajari juga tentang apa itu Git.&nbsp;<blockquote>Singkatnya, Git adalah tool yang memungkinkan kita untuk melakukan kerja development secara kolaboratif, dengan version control yang rapi dan mudah dilacak.</blockquote>&nbsp;Kenapa Git diperlukan? Bayangkan sebuah skenario seperti ini:&nbsp;Seorang developer menulis kode-kode pemrograman yang kemudian direvisi oleh koleganya, tanpa sepengetahuannya. Kode yang sudah ia tulis itu tertimpa, dan sulit dilacak revisinya. Dengan Git, resiko peristiwa revisi tersebut bisa diminimalkan. Sebab Git mencatat semua perubahan pada repository project, dan Git menandai dimana saja perubahan tersebut dilakukan.&nbsp;Resource tentang Git dan bagaimana cara menginstallnya bisa dibaca di sini:&nbsp;<a href="https://www.petanikode.com/git-untuk-pemula/">Apa itu Git?</a><a href="https://phoenixnap.com/kb/how-to-install-git-windows">How to Install Git on Windows</a><a href="https://www.atlassian.com/git/tutorials/install-git">Install Git on MacOS</a><a href="https://www.atlassian.com/git/tutorials/install-git#linux">Install Git on Linux</a>&nbsp;<h4>npm (Node Package Manager)</h4>&nbsp;Beberapa tahun terakhir, Node digunakan secara luas oleh developer JavaScript untuk membagikan tools, install berbagai modul dan mengelola dependensi antar library. Mengenal dan bekerja dengan npm menjadi penting untuk developer, terlebih banyak aplikasi modern yang dikembangkan dengan Node.js.&nbsp;Sebagai penganut rapid development, npm sangat membantu saya sebab tidak perlu lagi repot merunut berbagai library untuk diunduh demi membangun sebuah aplikasi, cukup dengan mengetik satu line di terminal / command prompt, dan voila, npm yang mengatur semuanya. Dalam hitungan menit, kita sudah memiliki aplikasi boilerplate yang siap di otak-atik.&nbsp;Bagaimana cara menginstall dan bekerja dengan npm akan kita jelajahi lebih lanjut dalam publikasi tersendiri. Agaknya akan terlalu panjang jika harus disematkan di sini :)&nbsp;<h4>Xampp</h4>&nbsp;XAMPP adalah tool open source yang kita gunakan sebagai solusi server untuk environment local. Artinya, dengan meng-install Xampp, kita menjadikan komputer kita sebagai server yang dapat melayani script kompleks seperti PHP, serta koneksinya dengan database MySql.&nbsp;Installasi Xampp di windows dan MacOs cukup mudah dan straightforward. Sila unduh di sini: <a href="https://www.apachefriends.org/index.html">XAMPP</a>.Sementara untuk linux, saya sendiri memakai ubuntu 18 dan ZorinOS, resource ini layak dicoba: <a href="https://vitux.com/how-to-install-xampp-on-your-ubuntu-18-04-lts-system/">install Xampp di linux</a>.&nbsp;Kira-kira segini dulu teman-teman yang baik, silakan coba install dulu tools di atas. Kita akan banyak bekerja dengan Adobe XD, Figma, dan VS Code. Mengenai Git dan npm, kita akan bahas lebih dalam di lain waktu. Tapi tidak ada salahnya untuk mulai mendaftar github sekarang juga :)&nbsp;Jika ada pertanyaan atau ada topik khusus yang ingin dibahas seputar design &amp; development, bisa kita diskusikan via twitter. Colek saja <a href="https://twitter.com/ginseladipura">@ginseladipura</a>&nbsp;Jika berkenan, kamu juga bisa follow twitter tersebut. Saya inginnya sih, kita bisa berbagi banyak ilmu dan pengalaman terkait design &amp; development ini.

Tools wajib install untuk Design & Development

Dulu ada masanya tiap kali ngantor, kala makan siang, saya selalu mampir ke toko buku. Kutu buku? Snob? Otaku? Sok intelek? Tidak juga…&nbsp;Kebetulan saja kantor saya waktu itu terletak dalam gedung yang sama dengan beberapa toko buku besar. Tepat di jantung Jakarta di gedung yang tinggi menjulang.&nbsp;&nbsp;Untuk pergi ke kantin, saya mesti turun dengan lift puluhan lantai hingga telinga saya berdenging. Lalu keluar dari lift, saya masih harus melewati toko buku tersebut.&nbsp;&nbsp;Sekilas melihat buku-buku yang terpampang di etalase, saya mendapati nama-nama pengarang atau judul-judul bukunya nan terasa familiar. Familiar sebab sering diperbincangkan, baik dari mulut ke mulut maupun lewat media-media seperti majalah, koran, ataupun social media seperti blog, facebook atau twitter. Diterjang dengan terpaan semacam itu, sering saya tidak berdaya, lalu memutuskan untuk membeli buku yang terpampang di etalase. Suka membaca? Tidak juga.&nbsp;&nbsp;Suka membeli, lebih tepatnya. Suka mengoleksi, lebih tepatnya lagi.&nbsp;&nbsp;Ada semacam perasaan senang ketika membeli buku, sekalipun perasaan itu berangsur hilang ketika sudah sampai rumah. Saya percaya, membeli buku dan tidak membacanya adalah tindakan yang wajar. Hasrat untuk beli buku dan baca buku adalah dua hal yang berbeda.&nbsp;&nbsp;Manusia pada dasarnya memang suka mengoleksi. Ada yang suka mengoleksi mobil, lukisan, patung, mainan, baju, sepatu, tas, poster, burung, dan lain sebagainya. Disesuaikan dengan kemampuan finansial masing-masing pelaku.&nbsp;&nbsp;Hobi mengoleksi ini kadang tidak ada hubungannya dengan perilaku konsumtif. Misalnya, dulu saya pernah punya teman mahasiswa yang hobinya mengoleksi name tag panitia acara. Dia aktif sekali di acara-acara kampus, dan di kamarnya kita bisa menemukan setumpuk name tag dari berbagai acara, dari acara musik sampai acara bakti sosial.&nbsp;&nbsp;Teman saya yang lainnya, suka mengoleksi bungkus rokok. Bertumpuk-tumpuk di jendela kamarnya. Entah apa motivasinya. Lain lagi dengan teman yang lain yang suka mengunduh film dan musik di Internet. Hasil unduhannya banyak sekali, tapi cuma sedikit yang didengarkan atau ditonton.&nbsp;&nbsp;Mencari tahu alasan kenapa orang mengoleksi sesuatu, bisa jadi terdapat banyak sekali jawabannya.&nbsp;&nbsp;Mengenai hobi mengoleksi buku, kadang penerbit juga memanfaatkan celah ini. Mereka menerbitkan beberapa seri buku (seringnya komik), yang bila dirangkai secara baik dan benar, punggung bukunya menampilkan sosok tertentu. Terakhir yang saya paling ingat, Djenar Maesa Ayu juga melakukannya. Bukan punggung buku, melainkan cover buku. Jika dirangkai, buku-buku Djenar tersebut menampilkan sosok wanita sedang berbaring menyamping. Cakep juga.&nbsp;&nbsp;Seperti perkataan orang bijak yang saya lupa namanya, bahwa buku yang baik itu cemerlang dilihat dari segala sudut. Hal-hal semacam permainan gambar punggung buku atau desain cover yang ciamik itu kian mempertebal keyakinan saya bahwa membeli buku dan tidak membacanya, merupakan tindakan yang wajar. Selama yang melakukannya bahagia dan tidak merugikan orang lain, sebaiknya memang tidak perlu digugat.

Gin

I'm your average frontend developer

All Articles