Dokumen ini memberikan konsep dan rancangan awal untuk Gugus, sebuah prototipe mini program yang bertujuan untuk mendatakan kegiatan pelaku UMKM secara digital. Dokumen ini menjelaskan entitas, layanan, arsitektur, dan modul-modul yang dibutuhkan untuk membangun Gugus. Rancangan ini dirancang agar ringan dan mudah digunakan serta mampu bekerja secara online-offline dengan menggunakan teknologi seperti QR code, email, dan microsite.

1. GUGUS
a mini-program prototype
Ditulis oleh Dony Riyanto
Maret 2020

2. Arti Nama

3. Disclaimer
• Ini adalah catatan pribadi. Jika saya share, semata-mata untuk
sekedar berbagi catatan, dan disiapa tahu bisa kita diskusikan lebih
lanjut dan bahkan dibahas secara lebih formal dan serius, kearah
pengembangan inovasi yang lebih baik.
• Ini bukan dan bukan peruntukan sebagai karya ilmiah. Jadi format
penulisan dan bahasa yang dipakai bukanlah format dan bahasa yang
baku/standar.
• Tujuan dari tulisan ini adalah mencari satu model/studi kasus yang
dapat diselesaikan dengan cara adopsi model “WeChat Mini Program”
dan memaksimalkan pemanfaatan teknologi QR Code. Diharapkan
dengan demikian dapat menjadi dasar, untuk dapat dikembangkan
dan dimanfaatkan bagi studi kasus yang lebih luas dan kompleks.

4. Bagaimana cara mudah untuk dapat melakukan pendataan kegiatan
publik secara digital?
• Memanfaatkan teknologi umum/awam misalnya: smartphone, web
site, QR Code, aplikasi-aplikasi yg umum dipakai masyarakat luas.
• Gunakan teknologi generik sebisa mungkin. Hindari start-from-sratch,
atau malah membuat framework baru (kecuali memang ditujukan
untuk menjadi framework publik/opensource)
• Mudahkan cara pemakaian.
• Fokus pada fungsi intinya. Jangan di “gado-gado” dengan fungsi-fungsi
tambahan/pendamping lainnya.
• Dalam slide ini kita akan membahas studi kasus mendata kegiatan
pelaku UMKM pada berbagai acara/kegiatan seperti seminar,
workshop, sarasehan, dsb.

5. Entitas-entitas Penting
• Acara (pameran, talkshow, seminar, workshop) beserta checkin-nya
• Penyelenggara acara
• Lokasi acara
• Waktu pengelenggaraan acara
• Narsum
• Materi (dan downloadnya)
• Quiz/Survey (dan pengisian/submit-nya)
• Peserta
• Progress
• Stamp
Acara yang dimaksud bisa berbentuk:
- Present
- Presentless (atau keduanya sekaligus)

6. Problem Domain
• Kehadiran: present, presentless, no present
• Aktor: peserta, penerima tamu, pembicara/narsum, petugas jaga,
penyelenggara acara (EO), dsb
• Jenis Aset: digital, fisik
• Aset yang digunakan: brosur/iklan fisik, poster/iklan elektronik,
backdrop/information display acara, tiket acara, materi
pelatihan/seminar, standing banner di lokasi acara, online quiz,
microsite, web portal, dsb.
• Progress: no progress, in progressing, resurrent progress, late
progress (response but late), stop progress (no more response).

7. Progress
• Main objective dari dalam prototype ini adalah progess tracking dari
peserta.
• Progress adalah history kejadian apapun yang terkait peserta dan
kombinasinya dengan entitas-entitas lainnya (peserta dengan acara,
peserta dengan download materi, peserta dengan submit survey, dsb)
• Akan ada reward yang diberikan secara virtual atas progress yang
dicapai. Reward ini juga memiliki jenjang. Progress yang mana yang
mendapat reward, atau rule tambahan apa saja untuk mendapatkan
reward, akan ditentukan kemudian dengan rule-set tertentu.
• Nantinya akan ada proses kurasi/klasifikasi dari semua Progress yang
terjadi.

8. Diagram Ilustrasi
No Progress
In
Progressing
No More Response
(stop progressing)
Late Response
New
Progress
(new ID)Stimulant
(event, flyer,
meetup info,
words of
mouth, quiz,
download)
Re-current
progress
Progress
Rules*

9. Aktifitas peserta
• Melihat flyer atau mengetahui dari referensensi/reshare, lalu mendaftar acara.
• Menerima email registrasi/konfirmasi.
• Check in acara dengan Scan QR atau membuka short-url (present).
• Terima email follow up (present maupun presentless):
• lalu mengisi survey dan submit
• atau men-download materi dari link email
• Download materi dari link yang ditayangkan, atau scan QR, atau URL yang disampaikan secara verbal (present)
• Terima email akan adanya acara lain (web-poster atau link ke microweb/registrasi acara)
• Melihat (atau mendapatkan email) Passport
*Identitas yang digunakan adalah USER ID
** Satu User ID digunakan untuk mengidentifikasikan satu peserta. Bisa berdasarkan satu atau lebih alamat email,
dan/atau satu atau lebih nomor telpon. Tiap User ID bisa memiliki satu atau lebih alamat tinggal/fisik (alamat usaha,
rumah, dsb)

10. Aktor utama pemakai aplikasi
• Peserta
• Panitia
• Pihak yang membutuhkan data
Format Aplikasi:
• Web (desktop web, mobile web, dan web yang dijadikan dalam
bentuk email dan microsite)
• Mobile Apps

11. Microsite vs Mini Program vs Web Widget
• Format web utuh, tapi di
simplifikasi (aset hanya
hanya 1 file html dan
load-nya ringan)
• Tujuan khusus (fokus)
• Di-deploy di subdomain
yang melekat ke
induknya, atau di embed
di email
• Biasanya tidak
menggunakan API. Atau
juka menggunnakan API,
biasanya mengacu pada
induk domainnya saja.
• Format aplikasi tetapi
menggunakan
framework/lib khusus
kombinasi XML dan JS
• Tujuan khusus (fokus)
namun feature extended
dari induk aplikasinya.
• Di deploy masing-masing
oleh author, dan di
registerkan ke induk
aplikasinya.
• Bisa mengakses API
aplikasi induk maupun
API milik author sendiri.
• Format web namun dengan
ukuran display yang kecil dan
biasanya dimasukkan kedalam
tag iframe
• Tujuan khusus (fokus) dan lebih
spesifik daripada microsite
• Di-deploy di hosting yang sama
dengan induknya/author-nya.
Dan biasanya bukan bagian
yang terpisah dari induknya.
• Umumnya mengakses API dari
induknya.

12. Web-Widget-Mini-Program dan Micro-site-mini-program
• Dari slide sebelumnya, kita bisa sekilas melihat perbedaan antara microsite, web widget dan mini
program.
• Ada banyak kemiripan tetapi setidaknya ada 1 perbedaan utama antara web widget & micro site
dengan mini program, yaitu “backbone” API tunggal yang memungkinkan antar mini program bisa
berkomunikasi/berkolaborasi satu dengan lainnya.
• Ini dimungkinkan karena mini program melekat pada sebuah superapp. Walau dalam
perkembangannya, mini program yang sama juga bisa menempel pada beberapa superapp. Ini
perbedaan mendasar dari cara kerja dibelakang layar antara microsite & web widget dengan mini
program.
• Untuk itu dalam studi kasus ini, kita perlu mendefisinikan API yang akan dijadikan “backbone”
supaya bisa dipakai bersama.
• Backbone API = shared functions, single main identity, memungkinkan session sharing dan omni-
channel

13. Gugus Backbone API (1)
• Dari uraian diatas, ada beberapa fungsi yang bisa kita jadikan shared function untuk aplikasi
Gugus ini, yaitu:
• Event Service (add new event, get/update event status, get event list)
• Activity Service (add/update activity type, record/get list activity with event id, timestamp & trigger source:
mini URL link/QR Code/email/microsite/etc)
• QR Code Service (Generate QR Code by activity/event, update QR Code, activate/deactivate, add/update
schedule)
• Location Tracking Service (add/update location. Data structure: timestamp, object type, object id, location
name, location lat+lon+acc, location source)
• User Service (register, retrieve status, update profile/status, login)
• Progress Services (new progress, update progress, get progress list, alert late progress, get/update/list
progress score by rule, add/update rule set)
• Asset Service (Aset terdiri dari microsite, download material, quiz, mini url, poster fisik, poster digital, voucher,
name tag/card, reward card)
• Mailer Service
• Microsite Service

14. Gugus Backbone API (2)
• Terlihat bahwa dari aplikasi (fungsi) Gugus yang cukup sederhana saya
ternyata setelah di analisa menghasilkan banyak layanan dasar
(service) dan turunannya.
• Ini menunjukkan indikasi awal bahwa untuk menerapkan Gugus (dan
pengembangan aplikasi sejenis) untuk studi kasus yang lebih
luas/besar akan membutuhkan rancangan layanan dasar yang
kompleks dan bisa jadi sangat besar.
• Setelah aplikasi Gugus ini selesai, kita akan kaji kembali hasilnya dari
berbagai aspek: efektivitas, kendala, keuntungan, kompleksitas dan
berbagai aspek-aspek lainnya.

15. Arsitektur Aplikasi (1)
Requirement umum:
• Fungsi utama aplikasi ini (baik email maupun microsite) harus small-
footprint (ukurannya bytenya kecil dan compact/tidak butuh banyak
library) sehingga ringan untuk digunakan/akses,
• mudah (UX) digunakan peserta dan informatif,
• mampu bekerja secara online-offline,
• omni channel (kombinasi interaksi beberapa kanal: email, microsite,
tampilan visual fisik/poster, verbal, dsb)

16. Arsitektur Aplikasi (2)
Dengan pertimbangan-pertimbangan diatas, maka:
• Front End Web Portal: bisa dikembangkan menggunakan framework
SPA (lebih baik yang lebih simple/light payload)
• Front End Mobile App: dikembangkan dengan pola hybrid agar
kontennya bisa dinamis namun ukuran downloadnya tetap kecil
• Front End Microsite: HTML untuk email/microsite dikembangkan
dengan lib/framework responsive-email (seperti MJML atau HEML)
• Back End API Server: dikembangkan dengan NodeJS (pertimbangan
kemudahan Javascript dan fleksibilitas JSON), dengan database NoSQL
(bisa MongoDB atau lainnya)

17. Daftar modul:
• Event Service (function: get list, add, update, de/activation, check-in, broadcast event info/thanks page,
create/update schedule)
• Microsite generator Service
• QRCode generator Service
• Media Service (function: uploader, generate link, link de/activation, download web page, report)
• Quiz Service (function: list, add, update, de/activation, submit)
• Email Service (function: send mail, scheduling, trigger)
• User management service
• Microapp main page act as microapp platform (home, registration, login, user profile)
• Microsite loader page
• Passport page
• Mobile App act as microapp platform as a microapp-main-page companion
• Admin Web

18. To be continued
• Dokumen ini masih sedang dalam pengerjaan dan belum selesai.
Setelah selesai akan di update kembali
• Untuk follow perkembangannya bisa dilihat di Google Drive
https://drive.google.com/open?id=11hNC0Y2-
E3T0y_yq2PYSGSDn0A9dy8In