Brand Ambassador tidak harus early adopter, tapi yang jelas harus punya sifat fanboy .

I’ve been dreaming about it recently. Lucky us, that “save it for later” service has been implemented by LaterLoop. Using laterloop we can save a page for later reading. We can even download the pages as ZIP file (consisting of text only pages) for offline reading as well. However there’s still some feature missing. We can’t choose which one we want to take offline. The only option available for offline reading is 30 recent entried, 30 random entries and 30 oldest entries.

While LaterLoop for sure will update their service to support nitpicking offline entries, why not taking it ourselves to the next level? We can create a simple site to convert our laterloop list to PDF, readily printable on paper. My wish getting stronger after reading copyblogger and Bokardo. Special for Bokardo, I found it hard to understand his writing in one shot. I can see his interesting point but to fully understand it I still need to read it a few more times. So it’d be trully a blesing for me if I can have it in paper so that I don;t have to open my browser to read it. For some occassion, paper is still suitable. Eg: bedtime reading (I don’t want my mac book air — if I have any — to be crush when I fell asleep).

So what do we need to augment laterloop? We’ll actually we don’t need to limit ourselves to laterloop only. The reading source can be obtained from anywhere. So what next would be building the converter of (rendered) HTML to PDFs. I can see konqueror can do this, and I’m sure there are many libs/apps to fill this job. So, technically it’s very feasible.

Monetizing plan? Well, ads is once again no-brainer. Printing service will be premium, and the ads here would be premium as well. Ads can be targetted and the best part it’s there forever printed onto paper. This would be magazine 2.0. Printing service itself can be varied; hardcover; monthly or weekly subs, auto create based on source (eg: RWW, Scobleizer, etc), auto-create content base on popularity (RSSMeme, TechMeme), or even based on alert from google alert. The best part is it’s on demand, no stocks, everyone any taste can be covered.

It’s a bit like Lulu, no? Yes, it’s like Lulu. No, we’re magazine, we are newspaper, we are books, we are the new media! No, we are printing agency 2.0

Photo by FelipeArte

Background
I get constant e-mail from flickr telling me that someone has favorited my wedding invitation card. The photo has 73 favorites and 15 thousands view (since Oct 2006). This is a quite clear signal that people are digging this keyword.

What’s our “user focus”?

• User will be able to design card: change background, and text, spice up card
• User will be able to print the card (printing will be sub-contracted, worldwide)
• User will be given optional URL to share their card online

What designer (other type of user/ecosystem player) will get?

• Vote, credibility
• % of transaction (freemium, print service, packaging service)

Please note that designer (as ecosystem player) won’t be available in early phase. Initial card design will be supplied by subcontracting design job. Print job will likely supported for local area until we can engage with international partners.

UI Guidelines

• Simple javascript
• Keep it web 2.0 clean
• Copy Apple! :p

Navigation

• Under 5 steps
• Lazy registration for editing purposes and sharing card online

Activity flow

1. Start new card or clone card design
2. Choose background
3. Put text
4. Spice up card: add badges, ribbons, bubbles, etc
5. Repeat from #2 (preview will be realtime)
6. Optionally share card design
7. Optionally print card

Epilog
This may not the best idea ever. But looking at the niche, it may just work. This demand will always there except breeding/mating formally is no longer necessary for human race. The ultimate revenue won’t come from ads but instead it will be print and packaging service. There’re many exit options to choose as service progresses. It can turn out to be generic card designer, event organizer, designer community, printing agencies, you name it.

I already have some people names in my head, eg: web designer, card designer. So in case anyone willing to invest in this idea, I’m ready to go

Kenapa harus SOLR, tidak cukupkah google site search/google coop?

Google memang mengindeks dengan handal,akan tetapi Google sepertinya tak akan bisa memberikan banyak interpretasi semantic. Di sinilah implementasi SOLR akan banyak membantu kita. Model searching yang dicontohkan Google adalah evolusi dari search jaman dulu. Walau model ini bekerja dengan baik, kebutuhan search terus berkembang, pada akhirnya pengalaman yang didapat dari aktivitas pencarian lewat Google tidak akan mampu mengakomodasi seluruh permintaan konsumen. Konsumen membutuhkan pengalaman pencarian yang lebih berkesan. Vertical search adalah salah satu jawaban dan harapan. Vertical search hanya bisa dibangun jika semua data dan relasi antar data tersebut tersedia. Dan tentu saja hanya yang pemilik data itu sendiri yang tahu dan mempunyai informasi yang telah disebutkan sebelumnya. Ya, berarti semua orang terkualifikasi untuk mendayagunakan SOLR. Dan sang pemilik data itu sendirilah memang pihak yang paling tepat untuk mengendalikan pengalaman aktivitas pencarian.

Contoh kasus. Mislakan berikut ini adalah data yang kita punyai:

SOLR for Dummies
Pennington, Havoc
7888XXXXX
USD $27

Bisakah google menjawab pertanyaan “Buku apa yang ditulis oleh Havoc Pennington?”, “Buku-buku apa saja yang harganya di bawah $30?”. Google tak akan mampu menjawab satu pun dari pertanyaan tersebut kecuali Google tahu semantik/makna data dalam teks tersebut. Sebaliknya, dengan SOLR kita bisa menjawab pertanyaan di atas. Karena kita tahu bahwa “SOLR for Dummies” adalah judul buku, maka kita bisa mengindeks data ini di bawah field book_title dalam SOLR. Kemudian “Pennington, Havoc” bisa diindeks di bawah “author” dan seterusnya. Maka kita pun bisa mencari data yang kita inginkan dengan lebih akurat.

Siapakah klien potensial kita?

Mengulang kembali apa yang sempat kita singgung sebelumnya. Berikut ini adalah beberapa jenis klien potensial.

1. Blogs. Data dalam blog bisa dipastikan jauh dari terstruktur. Ini adalah klien potensial yang tersulit. Potensial karena tumpukan datanya sangat banyak dan sepertinya belum ada yang sanggup mengolahnya menjadi data berharga. Hmmm, sebentar, mari kita berimajinasi. Ada tidak kemungkinan: ”cari ulasan tentang SOLR yang ditulis oleh Akhmad Fathonih”. Dengan struktur umum kontent blog berupa title, excerpt, permalink, full-content, category, dan tags ternyata kita sudah bsia memberikan value lebih. Dengan semakin meningkatnya permintaan dan kepercayaan pengguna internet akan peer review dan citizen jurnalism, query yang baru saja saya sebut pasti akan muncul.
2. e-commerce sites. Segala situs yang bertema amazon, e-bay atau craiglist akan lebih mudah diindeks karena data telah distrukturkan dan mempunyai relasi antar data yang sudah jelas.
3. Semua pemilik data yang menginginkan datanya lebih discoverable bagi penggunanya

Apa yang harus kita bootstrap lebih dulu?

Selain infrastruktur (cores, storage, bandwidth, etc) di mana kita akan mendeploy SOLR, plugins (untuk CMS dan other data management system) adalah salah satu hal kritikal. Faktor ini akan turut menentukan rendahnya barrier of entry pada konsumen. Semakin mudah konsumer bisa memanfaatkan layanan kita maka besar peluang kita untuk mendapatkan konsumen, data (untuk di-mining is possible) dan peluang-peluang lain.

What do you say?

While I will think and write more on this subject, I’m all free for any discussion; whether you are rushing to execute this plan before anybody else, or you want a simply routine-breaking chit-chat.

Photo:

Source

Flickr

Author

Cayusa

License

So, will it work? What do we sell?

• Sell grid power. This is no-brainer. But shouldn;t be the first in the priority list. For most site, search is a non-dominant action. So, they may already have the computing power needed to run their site (includes search activity)
• Tuneable search experience. User will no longer depending on what their CMS provide, instead they can create their own search experience using their defined field and search weigthing.
• Leverage content discoverability. Some site may have a big bulk of data inside their server. Indexing this data (on SOLR) may give them added value. Eg: faceted data can be displayed to attract visitors. It’s like “simple” data mining.
• Targetted ad . We can push ad onto the search page

Then, who are our potential customers?

• e-commerce site. There are many e-commerce site in Indonesia. many of then is simply built from scratch of using off-the-shelf FOSS CMS such as osCommerce which is lacking good search feature. yes, MySQL Fultext search just won’t cut it.
• document intensive site. Eg: library (OMG, there are lots of library out there), .go.id site
• any rich content site

Ok, so how are we going to execute it, technically?

• provide REST API, or
• simply expose the SOLR endpoint for integration and searching purposes

Former option would enable us to push our ad. And the later seems fit premium service, where user can process raw SOLR data.

So, anyone interested? Or desperately wanting one for your own site? Or, you suddenly want to start your own web crawler? That’s an interesting idea … Going vertical, anyone?

Photo source: swisscan

Liat lintasberita.com, jd tau kecenderungan netter utk menyukai berita pop kontroversial

Ini artinya msh ada segmen netter yg blm diakomodasi oleh pemain lokal about 10 hours ago from web

‘ngapain bsaing dgn digg?’. Gk bsaing, kt justru bmain d ekosistem digg etc, completely not competing but filtering and recommending instead about 10 hours ago from im

‘Tp bagaimana kt bs menarik user?’. Tahu gk klo user itu lbh suka dg rekomendasi org2 yg sudah ia ‘kenal’? about 10 hours ago from im

Jadi ya pastikan early adopter dan ‘selebritis’ nongkrong d situs ‘digg’ anda about 10 hours ago from im

Nah, utk mbuat early adopters dan ‘selebriti’ mau nongkrong dan aktif ini lbh menarik lg untuk diobrolin :d about 10 hours ago from im

Selain itu, hrs ada incremental changes utk menjaga mood user. Exclusiveness jg bs jd unsur menarik. about 10 hours ago from im

Okeh, sila dreply ya klo puna feedback. Saya mo tidur. Ngantuks …zzz..zz about 10 hours ago from im

Di atas adalah twitblogging yang saya lakukan semalam. Kerana tiba-tiba terpikir sesuatu dan tak ingin kehilangan catatannya, maka twitter pun jadi opsi menarik. Berhubung sewaktu di-tweet belum ada yang reply ataupun memberikan feedback, saya berharap something different di blog ini . I really-really love to discuss such thing. I want to grow, I want to know where I am strong at and where are my weakness. I want to grow, and you definitely can grow with me. Bersama kita bisa . Ya kan?

PS:

Segmen yang belum terakomodasi adalah segemen penyuka berita non kontroversial/pop

Photo “Scott Beale / Laughing Squid” by Laughing Squid

• Each user will be given their own room. So, if I’m neofreko then I’ll have #neofreko
• Twitter bot join every user room
• Who following who will be kept in a dedicated database
• Each time user post a message in his (or any) room, twitter bot will relay this message to other user room based on the who-following-who database
• User can leave their room so they may have been replaced by a bot as well. We may want to keep an alias table for user-bot and real user
• This user-bot will “provide” web-based UI so user is not required to join the room but, still, can access their room from external world. Accessing here may mean: views archive, views replies, and sends messages
• Twitter bot can keep all recent messages to build the public timeline

So, now we have

• Other can see my twitter page by visiting my room, or accessing the web-based UI.
• At any given time there’ll be at least two user instance in any given room, ie: user-bot and twitter-bot
• No, the room won’t be available on public. Instead it’s only available in twitter LAN(d). Thus we can prevent evil bot from joining.

And then we must consider

• Netsplit issue. IRC wizard please confirm this: will this problem gone is all user coming from localhost?
• Security. Whether this IRC is vulnerable

Now, who want to fund me?!

Tulisan berikut ini adalah pemenuhan janji yang saya buat kemarin Sabtu. Tentang tren layanan cloud yang saya baca di GigaOm. Jika anda telah membaca url terkait GigaOm (When Is the Right Time to Launch Your Own Cloud?) maka anda akan tahu bahwa belakangan ini banyak pihak yang meluncurkan layanan berbasis cloud.

Cloud computing bisa diasosiasikan dengan kepemilikan grid atau farm. Dari sini saja sudah terlihat bahwa biaya yang dibutuhkan untuk mensetup layanan seperti ini tidaklah murah. Tapi bukan berarti penyediaan layanan seperti ini benar-benar sangat sulit. Setiap pihak yang punya computing resource yang cukup besar bisa menyediakan layanan tersebut. Contoh nyatanya adalah Amazon. Amazon selain menfokuskan diri pada penjualan buku (dan video, dll) ternyata berani mencoba niche market yang sama sekali belum disentuh banyak orang. Jika yang lumrah kita temui biasanya adalah virtual private server dan dedicated server mahal, maka Amazon benar-benar bisa membuat terobosan baru dengan penyediaan virtual server (Elastic Compute Cloud), storage server (Simple Storage Service) dengan harga yang tidak fixed berdasar waktu. Bayangkan saja, siapa yang berani memberikan tarif sewa server berdasarkan jam pemakaian? Dan tarif storage berdasar kapasitas?

Amazon tidak memilih jalan memberdayakan ad seperti halnya perusahaan-perusahaan lain. Ini adalah langka yang cerdas. Amazon benar-benar tahu apa kekuatannya. Amazon mempunyai hardware berlebih yang memang disetup untuk mendukung layanan utamanya yakni berjualan buku, dll. Kebutuhan hardware ini, semakin ke depan tida akan bertambah sedikit akan tetapi justru akan bertambah banyak. Pilihan menyewakan resource computing adalah komplemen usaha yang tidak memerlukan banyak modal karena sebenarnya sebagian besar permodalan dan maintenance telah dicakup secara otomatis di dalam fokus usaha utamanya.

Dari situ saya berpikir, kenapa di Indonesia tidak ada yang melirik pasar basah ini. Cloud computing adalah masa depan pasti! The big boys are doing it. Ini adalah opsi paling masuk akal dibandingkan dengan bersikukuh meneruskan model bisnis jadul dengan skema pricing yang tak masuk akal.

Oke, lalu siapa saja yang kira-kira berpotensi untuk bisa bermain dalam pasar ini? Tentu saja pihak-pihak yang mempunyai computing resource besar. Paling mudah, kita lihat saja siapa yang mempunyai page hit tinggi dan tetap bisa menyediakan response time yang bagus. Jika di luar negeri ada Slashdot effect, di Indonesia kita punya detik effect. Setiap orang pasti tak susah untuk menebak bahwa detik.com punya potensi besar untuk bermain di cloud computing services. Blogdetik adalah saya satu bukti kekuatannya. Blogdetik tentunya tidak bisa langsung di-serve dengan kekuatan dari detik.com saja. Saya cukup yakin pasti ada investasi tambahan untuk blogdetik. Upaya melakukan scaling secara horizontal tentu ada batasnya. Mau tak mau, walau mas Andry sudah mengeksploitasi nginx habis-habisan, hardware tetap akan jadi limit pasti di masa depan.Pada suatu saat pasti akan ditemui titik batas dimana horizontal scaling tidak lagi efektif tanpa disertai occasional vertical scaling.

Lalu, jika hanya pemain besar saja yang bisa turut serta, apa menariknya bagi kita-kita pemain kelas teri seperti saya (dan mungkin Anda)? Hehehe, walau cloud service sudah bisa dianggap niche market, sebenarnya masih ada banyak niche di dalam niche cloud service ini. Tidak ada seorang pun yang akan bisa memenuhi segala jenis kebutuhan cloud computing. Ini adalah peluang untuk merambah pasar spesialisasi cloud service. Contohnya ya SCC yang saya tulis kemarin. Contoh yang lebih mudah lagi adalah webhosting. Saya belum menemukan webhosting yang pelayanannya mencakup scaling. Yang ada adalah opsi upgrade yang kadang tidak masuk akal dalam hitungan budget para pemain baru. Layanan webhosting yang ready-to-scale pasti akan jadi pembeda tersendiri. Dengan meniru skema pricing progressif yang dipakai Amazon, webhosting pun bisa merendahkan barrier of entry. Rendahnya barrier of entry akan mengundang banyak konsumen baru yang mungkin bisa menjadi konsumen tetap. Siapa tahu salah satu konsumen ini bsia jadi pemain besar yang sekaligus menjadi your permanent cash-cow?

So, kapan cloud computing jadi tren di Indonesia? Be the first!

Photo by Stuck in Customs

Hari ini sewaktu mandi, saya kembali terpikir mengenai ide saya beberapa waktu lalu. Yakni tentang Social Compile Cloud (selanjutnya akan saya singkat dengan SCC) dengan memberdayakan icecream dan hamachi. Ide yang minim umpan balik ini kembali datang setelah membaca GigaOm. Saya hampir putus asa dengan GigaOM karena beritanya terasa turun mutu. Padahal GigaOm ini adalah salah satu feed pertama yang mengawali penjelajahan saya atas Web 2.0. Hari ini GigaOm is back in my heart. Post-nya tentang tren layanan cloud menggelitik otak saya dan akhirnya ide SCC mendapat bahan baru!

Dalam ide saya yang lalu, yang terpikir oleh saya hanya hamachi (VPN) saja yang bisa dipakai untuk menjadi penghubung antara anggota SCC dalam jaringan internet. Sekarang, tiba-tiba saya terpikir XMPP. Ya, kenapa tidak. Waktu lalu, isu yang cukup mendasar yang belum saya temukan solusinya adalah masalah trust dan keamanan. Dengan VPN, memang setup SCC bisa jadi sangat mudah. Namun, karena semua anggota SCC terhubung langsung via VPN maka resource yang ada pada setiap anggota akan terekspose seluruhnya. Webserver, FTP, ssh, dan lain-lain akan terlihat gamblang oleh anggota yang lain. Hal ini tentunya akan menjadi penghambat dalam hal pengembangan jaringan sosial para anggota. Bagaimana saya bisa menambahkan friend jika saya beresiko mengalami penetrasi ilegal dalam jaringan?

Dengan XMPP, berarti yang terekspose adalah XMPP resource saja. Tidak yang lain. Dan kini setiap anggota tidak harus lagi membuat VPN meskipun VPN bisa tetap dipakai sebagai pilihan. VPN bisa menjadi pilihan advanced user sedang XMPP bisa menjadi pilihan user pemula atau user yang ingin mengembangkan network dengan jalan membuka diri secara aman.

Tapi tentu saja pilihan menggunakan protokol XMPP tidak berarti membuat segalanya menjadi lebih meudah. Dari sisi user memang akan tampak simpel, akan tetapi implementasi dari sisi developer menjadi lebih susah. Wajar saja, ini memang sudah formula paten. You can take one but you can’t have both .

Implementasi SCC dengan XMPP memerlukan tambahan server yang akan berfungsi sebagai tracker layaknya trakcer dalam model bittorrent. Alih-alih mengekspose keberadaan icecream secara langsung, kini user akan mengekspose icecreamnya secara lebih secure lewat tracker. Instans icecream tidak akan terlihat langsung namun statusnya bisa dimonitor di tracker. Lebih jauh tracker ini juga bisa dijadikan media penyimpan informasi tambahan mengenai resource apa saja yang akan tersedia dalam icecream isntan milik suatu user. Misalnya, icecream saya akan ready untuk mengkompile KDE saja, sedang icecream milik stwn siap untuk mengkompile segala hal dalam konteks Kuliax.

Selain tracker, sudah pasti source code icecream juga perlu dipatch supaya berjalan dengan protokol XMPP atau mendayagunakan protokol XMPP. Iya, tidak harus menggunakan XMPP seutuhnya namun XMPP bsia dipakai sekedar untuk menjembatani aktivitas sosial antar anggota. Sementara itu proses compile-nya sendiri bisa memakai VPN secara implisit (seamless). Yang terbayang dalam benak saya, kita tinggal meng-install plugin tambahan untuk klien IM kita untuk menambahkan support SCC.

Bagaimana? Mudah-mudahan bisa lebih jelas konsepnya daripada yang kemarin. Mengenai business model memang belumada banyak tambahan. Tapi saya sudah lebih punya fokus. Seperti yang tertulis di atas, anggota SCC bisa menyediakan berbagai macam compile enviroment. Jadi user bisa juga memasang tarif untuk resource tertentu yang bisa dipakai orang lain. Misalnya memasang tarif untuk enviroment Sun Solaris atau Mac.

Menarik?

PS:

Sebenarnya saya masih punya draft mengenai tren layanan cloud. Akan tetapi, sepertinya akan saya tulis di lain kesempatan saja. Ini sudah pukul sembilan, tiga puluh menit lagi cakewalk mungkin sudah mau kukut-kukut

Photo by Thomas Hawk

For those waiting for a free ride, this is your moment. Take Joyent offer, implements OpenSocial and determine within your free 6 months: Would a VPS or dedicated really worth an investment? I heard Shindig is a great tool to start impelementing OpenSocial. Shindig is an Apache Incubator project. But not only Java, it’s also supporting PHP. Great isn’t it?

Further, I heard EC2 is quite cheap ($0.100/hour-instance). If you can really take off with your free 6 months at Joyent, instead of continuing on Joyent you can always consider EC2. There’s also scaling tool compatible to EC2 architecture called Scalr.

So, there are two ideas you can found here:

• Host your app over Joyent or EC2. go international!
• VPS is a wet market. Refine your business model, grab potential early adopters!

Yahooooo! Let’s do it!

PS:
Joyent offers free service as well for Facebook App developer!

Photo by carf