Review: Liferay sebagai Pilihan Aplikasi Portal Web

Tiga tahun yang lalu, saya sempat menyebutkan Liferay sebagai salah satu alternatif untuk menggantikan Microsoft Sharepoint dalam fungsinya sebagai aplikasi portal web. Dan hingga saat ini, saya sudah mengimplementasikan Liferay untuk website resmi pabrik tempat saya bekerja dan satu lagi untuk aplikasi internal. Pada artikel ini, saya ingin sedikit berbagi pengalaman mengenai Liferay ini.

Liferay adalah engine berbasis Java yang ditujukan untuk pembuatan web portal. Memang jika dibandingkan engine-engine berbasis PHP, Liferay jauh kalah populer dibandingkan dengan WordPress, Drupal, dan Joomla. Tapi menurut saya, jika kita mencari engine portal berbasis Java terbaik, Liferay adalah pilihan yang bisa dipertimbangkan dengan serius.

Mengapa Liferay?

Well, di pabrik saya, ada kebutuhan penyeragaman sistem dimana sebagian besar aplikasi berbasis Java. Kami memiliki pengalaman yang tidak menyenangkan dengan PHP, terutama menyangkut skalabilitas dan biaya maintenance yang luar biasa besar. Sehingga otomatis, engine-engine berbasis PHP yang terkenal itu dicoret dari daftar.

Kemampuan untuk melakukan design layout secara on the fly adalah kelebihan yang jarang dimiliki portal lain. Jadi kita bisa menambahkan portlet — isian konten — secara langsung dan bersifat WYSIWYG. Menambahkan ruang untuk blog, forum, galeri foto, file-file bisa tinggal drag-and-drop. Lalu beberapa template layout sudah disediakan pula oleh Liferay, satu kolom, dua kolom, atau free style.

Membuat custom themes juga cukup mudah, meskipun tidak semudah WordPress, tapi masih lebih mudah daripada Joomla apalagi Drupal. Template engine-nya berbasis Velocity, jadi yang biasa melakukan templating di Velocity dan Freemarker akan mudah melakukan custom. Ada empat bagian besar: header, navigation, main content, dan footer. Di main content itulah tempat portlet-portlet dipasang secara dinamis melalui antarmuka web.

Lisensi

Liferay bisa didapatkan secara bebas, baik versi binary maupun source code-nya untuk versi Community Edition. Untuk versi yang mendapatkan dukungan penuh dari vendor, disediakan versi Enterprise Edition. Dengan versi EE ini kita bisa membuat tiket support dari Liferay 24 jam. Dan team support-nya kebanyakan wanita-wanita muda berwajah imut seperti personnel SNSD.

Jangan harap versi CE dan EE sama saja. Curangnya Liferay, versi EE memiliki struktur database dan indeks yang berbeda, jadi harus dilakukan proses migrasi khusus dari versi CE ke EE. Jadi tidak bisa begitu saja gonta-ganti versi dengan menggunakan database yang sama.

Performance, antara CE yang sudah dituning dengan EE default, jauh lebih cepat EE. Pada beberapa fitur, saya menemukan bug di CE yang baru akan diberi patch-nya di rilis major berikutnya. Sementara bug tersebut tidak ditemukan sama sekali di EE. Hal inilah yang membuat kami memutuskan membeli lisensi Enterprise Edition dari yang awalnya hanya Community Edition.

Wrap Up

Jika saya dihadapkan pada project yang mengharuskan software-nya adalah free, maka saya akan lebih memilih WordPress, Joomla, atau Drupal. Saya masih belum menemukan rasa klik dengan Liferay, ada bagian-bagian tertentu yang saya merasa kurang sreg dengan Liferay.

Hal yang lain, Liferay adalah barang langka di Indonesia. Menemukan vendor lokal yang bisa men-support Liferay bukan perkara gampang. Saya pernah menghubungi beberapa vendor yang bisa menangani Liferay (macam Mondrian-nya Frans Thamura), tetapi tidak mendapatkan respon yang positif. Akhirnya kami memutuskan untuk mengembangkan sendiri secara internal dan langsung meminta support dari Liferay Asia Pacific.

Dibandingkan dengan Microsoft Sharepoint, di luar integrasinya dengan Microsoft Office, saya akan lebih memilih Liferay karena Liferay jauh lebih fleksibel untuk dicustom. Sharepoint memang memiliki Sharepoint Designer, tetapi sulit sekali membuat theme custom untuk Sharepoint. Padahal salah satu kebutuhan utama dari web portal adalah kemudahannya membuat tampilan custom yang indah.

Membuat Front-End Webserver dengan Apache Reverse Proxy dan Mod_Rewrite

Apa itu front-end webserver? Jadi singkat cerita, kita memiliki sebuah (atau banyak) application server yang menangani banyak aplikasi. Banyak application server yang berjalan di port yang berbeda, misalnya Tomcat jalan di 8080, Weblogic jalan di 7001, lalu ada misalnya IIS untuk menjalankan teknologi .net framework.

Permasalahannya, ini menjadikan struktur URL-nya jadi jelek, misalnya http://server.example:7001, http://server.example:8001. Struktur URL yang cantik itu hanya bisa didapat jika web server berjalan mendengarkan di port 80. Lha, dari sekian banyak application server itu, siapa yang akan mendapatkan port kehormatan? Harus diundi terlebih dahulu?

Front-End dan Back-End Web Server

Solusi agar semua kebagian adalah membuat satu webserver yang mendengarkan port 80, yang berfungsi sebagai forwarder/dispatcher request, untuk meneruskannya ke application yang benar. Karena ada webserver yang ditaruh di depan sebagai forwarder dan webserver di belakang sebagai pemroses request, maka model seperti ini disebut front-end webserver dan back-end webserver. Seperti gambar di bawah ini kira-kira:

Webserver yang saya gunakan sebagai front-end adalah Apache. Dia mendapatkan port kehormatan 80 agar bisa diakses langsung dengan “normal” (http://server.example). Kemudian, berbagai web server dari berbagai platform hidup di belakangnya, misalnya Oracle Weblogic di port 7001 (http://server.example:7001), Apache Tomcat di port 8080 (http://server.example:8080), dan IBM Websphere di port 8888 (http://server.example:8888).

Yang saya inginkan adalah, semua client (Macintosh, Desktop PC, dan Laptop PC) mengakses semua application server melalui port 80 dengan nama-nama cantik berikut ini:

• http://weblogic.example/wls, untuk aplikasi wls yang ada di Weblogic port 7001
• http://tomcat.example/tomcat, untuk aplikasi tomcat yang ada di Tomcat port 8080
• http://websphere.example/ws, untuk aplikasi ws yang ada di Websphere port 8888

Segala akses yang langsung ke application server tidak diperbolehkan (tapi di posting ini, saya tidak menyertakan setting firewall-nya ya!).

Jadi bagaimana setup-nya? Hal yang perlu dilakukan adalah: (1) Setup DNS record untuk mengarah ke webserver, (2) Setup Apache, Virtual Host, (3) Setup Apache, Reverse Proxy, (4) Setup Apache, Mod Rewrite. Mari kita mulai.

Setup DNS Record

Anyway, urusan DNS record adalah urusan DNS server – Apapun tipe DNS Server Anda, konsepnya adalah mengarahkan subdomain tadi ke IP Address web server dimana Apache port 80 berada. Anda juga bisa memasukkan entri ini di file /etc/hosts, atau kalau di Windows, C:\Windows\System32\drivers\etc\hosts. Misalnya, IP Address tempat Apache port 80 adalah 192.168.10.2, maka, entri di file hosts (atau di DNS server) kira-kira sbb:

weblogic.example 192.168.10.2
tomcat.example 192.168.10.2
websphere.example 192.168.10.2


Setup Apache: Virtual Host

Masing-masing dari subdomain perlu diberikan Virtual Host tersendiri agar Apache tahu harus memproses setiap request yang datang ke subdomain yang tepat. Anyway, menurut saya, Apache adalah webserver yang paling fleksibel kalau urusan Virtual Host ini. Jadi, buatlah entri di file setting Apache di httpd.conf seperti di bawah ini:

<VirtualHost *>
ServerAdmin galih.satriaji@server.example
ServerName weblogic.example
ServerAlias www.weblogic.example
ErrorLog "logs/weblogic.example.err.log"
CustomLog "logs/weblogic.example.log" combined
</VirtualHost>


Blok kode ini akan memberitahu Apache untuk menggunakan setting-setting yang ada di bawah VirtualHost weblogic.example setiap kali ada request yang mengarah ke alamat URL weblogic.example. Setting ini tentu saja belum cukup karena si Apache belum diberitahu harus memproses file-file-nya dimana. Nah, karena si Apache ini kita gunakan hanya sebagai Front-End, maka pemrosesan request akan diteruskan oleh Apache ke Application Server di belakangnya (Back-End). Di sini yang perlu dilakukan adalah setup Reverse Proxy dan redirectornya.

Setup Apache: Reverse Proxy

Agar bertindak sebagai front-end, pada setting VirtualHost di atas perlu ditambahkan setting reverse proyx yang memberitahu Apache untuk meneruskan request ke application server di belakangnya.

<VirtualHost *>
ServerAdmin galih.satriaji@server.example
ServerName weblogic.example
ServerAlias www.weblogic.example
ErrorLog "logs/weblogic.example.err.log"
CustomLog "logs/weblogic.example.log" combined
ProxyRequests off
ProxyPass / http://192.168.10.2:7001/
ProxyPassReverse / http://192.168.10.2:7001/
</VirtualHost>

Sudah cukup? Belum, setting ini hanya akan meneruskan request dari http://weblogic.example ke http://192.168.10.2:7001/ saja. Padahal yang dituju adalah http://192.168.10.2:7001/wls. Kita perlu menambahkan sebuah redirector, agar nantinya setiap URL yang diketik http://weblogic.example akan diredirect menjadi http://weblogic.example/wls. Proses redirecting dari port 80 ke 7001 dilakukan secara implisit, tidak mengubah struktur URL yang terlihat oleh user. Jadi tambahannya menjadi seperti ini:

<VirtualHost *>
ServerAdmin galih.satriaji@server.example
ServerName weblogic.example
ServerAlias www.weblogic.example
ErrorLog "logs/weblogic.example.err.log"
CustomLog "logs/weblogic.example.log" combined
ProxyRequests off
ProxyPass / http://192.168.10.2:7001/
ProxyPassReverse / http://192.168.10.2:7001/
<Location />
RedirectMatch ^/$ /wls/
</Location>
</VirtualHost>


Nah, ini kasusnya setiap URL weblogic.example akan menjadi weblogic.example/wls. Seakan-akan web server nya ada di port 80, menggunakan Apache. Padahal, Apache hanya meneruskan saja ke server Weblogic yang ada di port 7001.

Pertanyaan satu milyarnya, bagaimana membuat URL yang benar-benar implisit, weblogic.example tanpa harus diredirect ke /wls? Jadi weblogic.example akan terlihat tetap weblogic.example, meskipun lokasinya di back-end server adalah http://192.168.10.2:7001/wls/? Di sini, kita perlu satu teknologi lagi bernama URL Mod Rewrite dari Apache.

Setup Apache: URL Rewriting

Apache memiliki teknologi penulisan kembali URL yang memungkinkan seorang webmaster mengubah-ubah struktur URL tanpa harus mengubah apa yang terlihat di browser-nya user. Jadi URL yang simpel, indah, dan mudah dihapalkan user bisa tetap dipertahankan meskipun aplikasi memerlukan struktur URL yang ruwet. Contoh gampangnya ya WordPress ini, dia membuat URL dengan simpel misalnya http://blog.galihsatria.com/2012/05/front-end yang aplikasinya sebenarnya memerlukan URL yang ruwet seperti http://blog.galihsatria.com/post.php?permalink=front-end&year=2012&month=05.

Nah, supaya URL weblogic.example tetap diam (tapi sebenarnya di-forward ke weblogic.example:7001/wls), kita memerlukan tambahan setting untuk URL rewrite. Diperlukan kemampuan mengenai regular expression tingkat dewa di sini, tapi sebenarnya tinggal Googling aja bisa. Saya menemukan settingan di bawah ini dari hasil bertanya ke Eyang Google:

<VirtualHost *>
ServerAdmin galih.satriaji@server.example
ServerName weblogic.example
ServerAlias www.weblogic.example
ErrorLog "logs/weblogic.example.err.log"
CustomLog "logs/weblogic.example.log" combined
ProxyRequests off
ProxyPass / http://192.168.10.2:7001/
ProxyPassReverse / http://192.168.10.2:7001/
RewriteEngine on
Options +FollowSymLinks
RewriteRule ^(.*+)$ /wls/$1 [L,QSA]
</VirtualHost>

Penutup

Tentu saja Anda harus mengaktifkan modul-modul Apache untuk mengaktifkan setting-setting di atas, yaitu modul Virtual Host, Mod Proxy, dan Mod Rewrite. Ini adalah settingan yang sudah saya tes jalan di webserver saya untuk mengaplikasikan model front-end dan back-end ini. Apakah ini juga akan jalan di server Anda, belum tentu — besar kemungkinan tidak :p. Selamat mencoba dan jangan lupa di share kalau sudah berhasil!

Don’t Reinvent the Wheel

Kembali ke masa lima atau enam tahun yang lalu waktu saya merilis Content Management System (CMS)* versi terakhir saya untuk www.its.ac.id yang saya beri codename fitri (v3). Saat itu saya tidak menggunakan CMS yang sudah jadi — yang terkenal waktu itu Mamboo — tetapi mengembangkan CMS sendiri berbasis PHP dari awal. Jadi saya membuat satu per satu modul tampilan, dinamisasi konten melalui manipulasi database, hingga manajemen user dan hak aksesnya. Themes atau tampilannya belum bisa dinamis, karena antara kode untuk tampilan dengan kode untuk data tercampur menjadi satu.

Tujuan saya waktu itu hanya satu: belajar. Sebagaimana mahasiswa teknik yang seharusnya. Website-website akademis semacam ITS sebaiknya harus secara aktif berubah secara radikal, karena di sana lah tempat bereksplorasi, belajar, dan bermain. Ngoprek, istilah geek-nya. Tampilan jelek, rusak, dan kacau harus dimaklumi karena untuk belajar. Makanya saya terkejut ketika dikabari bahwa versi obrak-abrik besar yang terakhir dari website ITS itu masih versi kembangan dari fitri itu, setelah sekian tahun.

Zaman sekarang, saya pikir bukan saatnya lagi membuat sebuah CMS dari awal, bahkan untuk kebutuhan belajar sekalipun. CMS-CMS modern sudah sedemikian modular dan dinamisnya sehingga apapun bisa dibuat di atas CMS tersebut. Don’t reinvent the wheel. Sekarang saatnya mempelajari dengan detail salah satu CMS tersebut agar kita bisa dengan maksimal memanfaatkannya. Ketimbang menghabiskan waktu untuk membuat operasi-operasi dasar seperti memasukkan, update, dan hapus data, manajemen user, lebih baik kita memanfaatkan yang sudah disediakan CMS, kemudian memodifikasinya untuk kebutuhan kita.

Gambarannya bisa saya jelaskan dalam diagram di bawah ini:

Secara garis besar, pada umumnya CMS modern memiliki arsitektur seperti diagram di atas. Layer terbawah mengurusi operasi dasar seperti manajemen data, pengguna, session, dan koneksi melalui berbagai protokol (web services, chatting, dll). Di atasnya kemudian ada pengaturan untuk dinamisasi tampilan (themes), dan modul-modul. CMS yang baik selalu dibangun dari modul-modul kecil untuk menjaga agar dia bisa fleksibel untuk kebutuhan yang berbeda-beda. Layer paling atas adalah bagian pengaturan yang spesifik untuk kebutuhan setiap website.

Jika seorang progammer akan membangun CMS sendiri, mau tidak mau ia harus membuat itu semua. Ibaratnya, dia akan membangun sebuah rumah, dia membuat sendiri batu batanya, mengolah pasir untuk menjadi semen, membelah kayu untuk dijadikan pintu dan jendela, dst.Baru dari bahan-bahan itu, dia mulai membangun rumah sesuai dengan desainnya. Sebaliknya, dengan menggunakan CMS yang sudah jadi, ibaratnya dalam membangun rumah sudah disediakan semen, jendela, batu, bahkan hingga pintu, lemari, dan atap. Dia tinggal merakit, merangkai, menyusun, dan menyesuaikan warna, peletakannya sesuai dengan selera. Tentu saja ia harus mengerti cara merakit pintu dan kawan-kawannya itu. Tetapi paling tidak, ia tidak harus mulai membuat pintu dulu untuk membuat rumah.

Bayangkan berapa banyak waktu yang bisa dihemat untuk membuat sebuah website jadi yang lengkap. Kesulitan utama mungkin ada pada mempelajari CMS itu sendiri sebagai framework. Bagaimana cara memodifikasi modul dan mengaplikasikan desain tampilan HTML dan CSS ke dalam theme engine CMS tersebut. Tetapi jika learning curve itu sudah dicapai, saya kira semuanya akan menjadi mudah.

Ada banyak CMS modern yang populer, misalnya WordPress, Joomla, dan Drupal. WordPress adalah yang paling sederhana dan paling mudah dipelajari, tetapi kurang dalam fleksibilitas. Jika Anda akan membangun sebuah website yang tidak hanya melulu tentang publikasi teks, mungkin Anda bisa mempertimbangkan Drupal atau Joomla. Saya sendiri sekarang sedang tertarik untuk memahami Drupal, setelah sekian lama saya tidak mendapatkan feeling dengan Joomla.

*) Content Management System (CMS) dalam ini merujuk pada Web Content Management System.

Framework dan Tumpukan Masalah yang Menyertainya

Saya sudah agak lama tidak terlibat dalam sebuah project yang sangat intens dengan coding dan saya merasa rindu karenanya. Saya sudah cukup banyak tahu dan mencoba bermacam framework seperti Spring, Hibernate, Webwork, Struts, Seam, IceFaces (Java sudah jenuh dengan framework ya?). Saya bukan programmer yang tahu terlalu dalam dengan tumpukan framework tersebut dan tidak terlalu tahu bagaimana memanfaatkan mereka dengan benar. Izinkan saya meletakkan ego saya dengan berkata bahwa saya tidak terlalu paham dengan konsep MVC (Model View Controller).

Saya pernah gagal dalam merancang sebuah software dengan tumpukan framework MVC, dimana di sisi model menggunakan Hibernate sebagai ORM (Object Relational Model), di sisi view menggunakan Struts/Webwork, sedangkan Spring menangani sisi controller-nya. Singkatnya, dengan begitu tumpukan framework yang besar, permasalahan datang karena batasan-batasan framework, bukan karena proses bisnisnya. Akhirnya, banyak energi yang harus dihabiskan untuk memenuhi syarat-syarat cukup yang diwajibkan framework.

Seharusnya dengan perancangan, desain, dan perencanaan yang baik hal itu tidak terjadi. Janji-janji framework dimana proses skalabilitas dan perawatan akan lebih mudah menjadi janji palsu belaka. Nyatanya proses tambal sulam menjadi sedemikian besar. Apakah dengan framework tersebut proses pengerjaan akan menjadi lebih cepat? Mungkin jika project-nya begitu besar iya, tapi dengan skala kecil, akan ada waktu yang dihabiskan untuk membuat sistem dasar dimana semua framework berjalan dan saling bekerja sama dengan baik sebelum menyentuh ke proses bisnis intinya.

Akhirnya saya begitu merindukan PHP. PHP from scratch. PHP tanpa framework. PHP yang dengan begitu buruknya menangani variabel dan nilai null karena pemesanan blok memory tanpa deklarasi. Dan itulah yang saya lakukan. Semua saya gabung jadi satu. Query ke database, validasi, HTML, Javascript, semua dalam satu file PHP yang besar. Saya hanya memakai library kecil-kecil saja tanpa framework besar yang bertumpuk-tumpuk. Cukup merepotkan, tapi saya fokus dan hanya dihadapkan pada permasalahan inti, bukan masalah-masalah yang ditimbulkan karena penggunaan framework yang tidak benar.

Pelajaran moral yang saya dapatkan: tidak semua permasalahan harus menggunakan solusi framework yang besar. Kadang-kadang, sebuah permasalahan lebih efektif jika dikerjakan dengan cara “gila” tanpa aturan seperti ini. Permasalahan selesai, dan ada banyak orang yang lebih mengerti dengan cara dasar (karena mudah) dan sulit mengerti cara framework karena learning curve-nya jauh-jauh lebih panjang. Lebih mudah mendelegasikan pekerjaan.

Anda boleh menyebut saya programmer yang buruk karena tidak patuh terhadap kaidah suci MVC. Toh, saya mungkin tidak akan kembali lagi ke dunia ini, ha ha ha ha…

PS: Saya jadi ingat tulisan-tulisan beberapa tahun yang lalu waktu masih memuja MVC hehe.

Komentar untuk Website ITS v4

Website ITS v4.

Wah, sebenarnya saya menyimpan komentar kalau sudah benar-benar selesai nanti, tapi ternyata pas saya lihat di sana ada untouched link yang bernama “Komentar Anda”. Karena sudah dimintai komentar dan ternyata di sana tidak ada media untuk mencurahkan komentar, ya saya tulis di sini. Yang jelas first of all, congratz untuk tim webmaster ITS.

Secara umum, saya suka konsep layout yang dibawa. Fresh! Segar! Mantaps! Beberapa catatan subjektif sayah:

1. Header terlalu kosong. Hanya tulisan webmail yang sedikit menemani.
   Yaya… saya tahu, webmaster tak punya pilihan banyak menempatkan logo. Dilema yang pernah saya alami berkali-kali dulu. Mungkin bisa dibuat semacam ornamen pemanis warna-warni di sana. Nggak usah ngeblok. Jika dibuat overflow keluar dari batas kotak 800 pixel mungkin lebih manis. Adik saya, Fitri, berkomentar kalau layout itu mirip buku TA. Hmm… masuk akal juga, mungkin memang inspirasinya dari situ?
2. Bagaimana kalau link webmail dibuat login form-nya sekalian? Untuk accessbility rasanya lebih praktis. Juga untuk mengurangi ruang yang terlalu kosong di sana. Terakhir, saya tahu SquirellMail yang dipakai sudah mendukung untuk tujuan ini kok.
3. Penonjolan informasi.
   Ini penting. Saya melihat portal ini terlalu flat. Tak ada informasi yang ditonjolkan. Saya ambil contoh: Di bagian Agenda. Mata saya tak bisa langsung di-drive untuk melihat suatu agenda. Kapan? Dimana? Tentang apa? Saya harus cari-cari di tulisan bertypo Trebuchet yang kecil itu.
4. Kenapa ITS Tour ada di bawah? Kenapa membuat pengunjung baru dan awam men-scroll halaman untuk melihat bagian yang bisa mereka lihat pertama kali. Taruh saja di atas, sebab informasi ini memang ditujukan untuk orang-orang yang belum tahu sama sekali tentang ITS, apalagi struktur website-nya. Key-nya tetap: penonjolan informasi.
5. Ada bagian cukup besar untuk foto. Komentar saya untuk foto saat ini: Jelek. Olah digital yang kurang rapi untuk seorang desainer DKV ITS. Tapi saya yakin, ini sementara. Saya usul, kalau memang ada content, lebih baik adalah movie flash yang melakukan slide show mengenai informasi yang diperlukan oleh pengunjung baru. Kalau tidak ada, ya foto-foto tentang suasana lingkungan ITS. Tapi jangan diedit habis seperti itu. Kalau ingin foto IR ya yang dari filter IR lah, jangan Photoshop.

Sedangkan kritik saya tentang konsep:

1. Konsep Web 2.0-nya mana? Zaman sudah akan beranjak ke Web 3.0, kok masih tetap bertahan dengan konsep ala tahun 2003?
2. Back to table layout? Is tableless layout too difficult for you?

Selebihnya Oke. Saya tak bisa berkomentar tentang sitemapping dan kemudahan navigasi karena belum jadi. Sebenarnya saya lebih setuju kalau tidak usah ada preview dan meminta sedekah komentar (meminjam istilah Bu Velisa) seperti ini. Langsung saja hajar jadi website utama. Karena kalau meminta kritik terlebih dahulu, web baru ini kehilangan kesempatan untuk membuat surprise. Padahal surprise itu penting. Orang cuma bisa mengkritik, dan orang tak bisa memuaskan semua pihak. Jadi, apa gunanya menerima kritik yang kebanyakan sifatnya subjektif dan selera saja?

Congratz Ridho’ and the team. Keep on hard work guys.

Sang Juara yang Memprihatinkan

Saya masih di sana ketika lomba website di seantero lingkungan ITS diadakan. Meskipun menjadi penjaga gawang portal utama, saya tidak dilibatkan baik sebagai peserta maupun penilai. Saya tak tahu siapa jurinya, tetapi waktu itu yang menjadi juara salah satunya adalah website ini: FTIF. Website fakultas dimana saya belajar.

Reaksi pertama saya waktu mendengar itu adalah berteriak,

“HAH!! APA?!? GAK SALAH TUH??!”

Memang, website ini membawa konsep baru dalam dunia website pendidikan, yaitu sebagai agregator blog-blog anggota fakultas — saya termasuk yang didaftarkan. Meskipun hal ini kontroversial, tapi saya anggap ini adalah sebuah konsep baru yang patut dihargai lebih.

Menurut saya, website yang baik adalah website yang dirawat dengan baik. Membuat website itu mudah, lima menit juga jadi. Yang jauh lebih sulit adalah merawatnya. Perlu cinta kasih dalam merawat sebuah website. Bagi saya, hal inilah yang seharusnya menjadi faktor penilaian dengan bobot terbesar. Setelah itu adalah isi, baru kemudian tampilan layout dan sitemapping.

Karena menjadi penjaga portal, saya jadi tahu kinerja semua website di lingkungan ITS. Dan saya tahu website yang menjadi juara itu (FTIF) dari dulu kurang dirawat. Kok tiba-tiba waktu lomba menjadi sebegitu bagusnya, saya curiga itu hanyalah tren sesaat^TM saja.

Dugaan saya terbukti. Iseng saya membuka website FTIF. Aktivitas ngeblog anggotanya juga tren sesaat. Entri agregator itu seperti saya dominasi sendirian (scharra saya ngeblog tiap hari sekarang) ) Ayo dong! Saya tahu betul, FTIF ITS adalah gudangnya mahasiswa dan dosen jenius luar biasa. Hanya diperlukan sedikit kasih sayang untuk merawat website itu. Ini penting karena citra pertama yang dilihat orang luar adalah kesan website-nya.

Artikel terkait: Web ITS, Ganti Layout dong!

Screenshot dokumentasi:

Read More