Hidup di Jakarta memang serba susah. Karena begitu luasnya, sesuatu yang unik bisa tersembunyi di sela keramaian. Tidak heran bila kehadiran sebuah online directory macam Urbanesia sangat diharapkan untuk memecahkan masalah keseharian ini.

Setelah melewati proses pengembangan yang cukup sangat lama, Urbanesia tidak pernah resmi meluncur dan membuka dirinya secara formal. Namun dalam perjalanannya, Urbanesia telah banyak mendapatkan traksi, terutama lewat data yang telah terindeks oleh mesin pencari.

Dari kategori dan definisi Urbanesia sebagai sebuah lifestyle city directory, saya pribadi tidak bisa membayangkan sejauh apa sebuah online directory bisa begitu menawan. Namun setelah duduk bersama para founder dan lead developer, saya rasa mereka punya misi dan pastinya ada keunikan tersendiri baik secara layanan atau teknologi.

Urbanesia kini telah resmi meluncur, dan tidak tanggung-tanggung, serangkaian API juga siap sedia untuk para developer. Apa yang bisa disuguhkan dari sebuah online directory, mungkin tidak akan jauh dari informasi bisnis dan lokasi. Berapa banyak API bisa membantu Urbanesia untuk mengukuhkan posisinya? Mengingat location based service tampaknya lebih cocok digunakan secara mobile (read: Koprol). Apakah Urbanesia juga sudah seharusnya lanjut dengan mobile application?

Berikut beberapa poin penting tentang API Urbanesia:

Compressed Result – API ini sangat berguna bagi para developer untuk menyuguhkan hasil pencarian yang dikompres agar irit bandwidth bagi pengguna mobile internet. Data sebesar 27 kb bisa dikompres menjadi 2 kb saja.

Pilihan Format – Format dari output ini tersedia dalam beberapa pilihan seperti JSON, Serialize, atau XML.

– Untuk ulasan lebih lanjut, silahkan simak pendapat Toni berikut ini. –

Location, Location, Location

Urbanesia memberikan fitur auto detection untuk menentukan lokasi pengguna saat ini berada. Fitur ini tentu saja sangat menarik karena output-nya akan selalu dinamis sesuai dengan perpindahan lokasi tempat mengakses API. Tapi masih ada beberapa kelemahan.

Yang jadi masalah utama dalam layanan seperti Urbanesia ini adalah menentukan lokasi default pengguna. Permasalahan bertambah karena tidak semua alat akses punya fitur GPS. Hal kecil ini jadi perkara detil yang mengganjal overall pengalaman dalam memakai API Urbanesia. Karena tanpa memberikan latitude dan longitude, kita akan dianggap berada di titik yang tidak akurat, eg: Jakarta.

Breadcrumb

Salah satu yang cukup membantu dalam hal mencerna informasi lokasi adalah hirarki lokasi. Kadangkala kita mendapatkan dua informasi lokasi yang berlainan, namun sebenarnya berada di tempat yang sama. Misalnya lokasi Pancious dan Aksara bsia mempunyai koordinat berbeda. Tanpa breadcrumb lokasi, kita bisa saja salah sangka jika dua venue tersebut terletak di tempat yang berbeda. Padahal keduanya sama-sama berada di Pacific Place.

Urbanesia memberikan informasi breadcrumb ini sehingga untuk setiap spot yang dimilikinya akan ada informasi spot yang menaungi. Misalnya Pancious akan punya informasi business_place Pacific Place. Pendekatan serupa juga ada di Koprol, paling tidak bisa kita lihat di UI-nya.

Granularity

Dalam konteks location based service, parameter yang di-expose API ini cukup lengkap dan tak kalah detil dari output yang dikembalikan. Kita bisa menyaring berdasarkan lokasi, atau latitude longitude (demi keakuratan), serta radius. Tipe spot yang dihasilkan juga bisa disaring berdasar fungsi bisnisnya, misalkan restoran, dll.

Yang kurang adalah diferensiasi yang menyisihkan Urbanesia dari API yang lain (not that it has any local competitor at the moment). Kekuatan resource-nya dalam menghimpun informasi bisa ditingkat satu notch. Misalnya dengan informasi range harga, atau menu dan detil-detil lain dari spot yang dihimpun.

– Kembali ke Ivan –

API yang disuguhkan Urbanesia terbilang lumayan menawan. Namun bukankah suatu API harus dilatarbelakangi oleh popularitas layanan? Mengingat Urbanesia masih baru, tapi jumlah visit yang diklaim sudah lumayan banyak, apakah API is the way to go? Not sure.