Praktik terbaik: Menciptakan pengalaman positif bagi pengguna Looker
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Praktik terbaik ini mencerminkan rekomendasi yang dibagikan oleh tim lintas fungsional yang terdiri dari Looker berpengalaman. Insight ini berasal dari pengalaman bertahun-tahun bekerja dengan pelanggan Looker, mulai dari penerapan hingga kesuksesan jangka panjang. Praktik ini ditulis agar dapat digunakan oleh sebagian besar pengguna dan situasi, tetapi Anda harus menggunakan penilaian terbaik saat menerapkannya.
Developer LookML dapat mempertimbangkan untuk mengikuti tips berikut guna meningkatkan pengalaman pengguna dengan Looker:
Rekomendasi ini dijelaskan secara lebih mendetail di bagian berikut.
Memberikan nama kolom yang bermakna kepada pengguna
Gunakan parameter label untuk menerapkan nama yang mudah digunakan ke dimensi atau ukuran sekaligus mempertahankan nama yang mudah digunakan database dalam file tampilan dan model. Anda dapat mempertimbangkan untuk mengganti nama beberapa istilah umum, seperti Jumlah menjadi Jumlah dan Jumlah menjadi Total. Jika Anda tidak yakin kata mana yang bermakna bagi pengguna, bekerja samalah dengan pengguna bisnis untuk membuat beberapa kueri umum, dan lihat kata-kata yang digunakan hasil kueri untuk mendeskripsikan hal yang dicari pengguna. Misalnya, tampilan Item Inventaris, Item Pesanan, Pesanan, dan Produk masing-masing memiliki ukuran yang disebut Jumlah. Anda dapat menggunakan parameter label untuk memberi setiap ukuran ini nama yang unik dan bermakna, seperti Jumlah Item Inventaris, Jumlah Item Pesanan, Jumlah Pesanan, dan Jumlah Produk.
Hindari mengekspos beberapa kolom dengan nama yang sama. Misalnya, ukuran type: count dibuat secara otomatis dalam Looker dengan nama Count. Hal ini menyebabkan sebagian besar file tampilan berisi ukuran jumlah dengan nama yang sama. Beberapa kolom dengan nama yang sama dapat membingungkan pengguna. Menambahkan label atau mengganti nama pengukuran jumlah untuk menunjukkan objek yang dihitung akan mencegah kebingungan. Kolom lain yang perlu diingat mencakup Tanggal Pembuatan dan Tanggal Pembaruan, seperti di grup dimensi.
Berikan nama yang jelas untuk kolom type: yesno. Misalnya, gunakan Apakah Item Ditampilkan?, bukan Ditampilkan, untuk memberi nama kolom yang menunjukkan apakah item telah ditampilkan.
Beri nama rasio secara deskriptif. Misalnya, Pesanan Per Pelanggan yang Melakukan Pembelian lebih jelas daripada Persentase Pesanan.
Beri nama kolom dan tampilkan nilai secara konsisten di seluruh model. Menggunakan parameter value_format atau value_format_name untuk menerapkan format seperti simbol mata uang, persentase, dan presisi desimal ke kolom numerik akan membantu memperjelas semuanya bagi pengguna.
Mengelompokkan kolom yang serupa untuk mempermudah navigasi
Gunakan parameter group_label untuk menggabungkan dimensi dan ukuran dari satu atau beberapa tampilan gabungan yang terkait. Misalnya, kelompokkan semua informasi geografis ke dalam grup Geografi untuk menggabungkan semua informasi alamat dan lokasi dalam pemilih kolom, bukan mencantumkannya secara alfabetis:
dimension: city {
group_label: "Geography"
type: string
sql: ${TABLE}.city ;;
}
dimension: country {
group_label: "Geography"
type: string
map_layer_name: countries
sql: ${TABLE}.country ;;
}
Pisahkan tabel besar yang didenormalisasi menggunakan parameter view_label. Gunakan parameter view_label dalam kolom untuk mengelompokkan kolom secara logis ke dalam judul terpisah dalam pemilih kolom. Tabel besar yang didenormalisasi dengan banyak kolom dapat sulit dinavigasi, sehingga memberikan ilusi beberapa tampilan di pemilih kolom Jelajahi sebelah kiri.
Hindari mengekspos terlalu banyak hal kepada pengguna pada awalnya
Hindari mengekspos terlalu banyak hal kepada pengguna setelah peluncuran Looker awal. Mulailah dari yang kecil, lalu perluas opsi. Anda tidak perlu mengekspos semua tabel atau dimensi dan ukuran sekaligus. Anda dapat mengekspos kolom yang paling penting pada awalnya, lalu terus membangun lebih banyak fungsi saat pengguna bisnis menjadi lebih percaya diri dengan eksplorasi data.
Menyembunyikan dimensi yang tidak relevan bagi pengguna dari antarmuka pengguna. Gunakan parameter hidden pada dimensi yang tidak akan pernah digunakan melalui antarmuka pengguna (seperti kolom ID atau tanggal pembaruan database).
Gunakan parameter fields dalam Jelajahi dan join untuk membatasi jumlah kolom yang tersedia bagi pengguna. Kolom yang disertakan hanya boleh yang relevan dengan Eksplorasi. Hal ini mengurangi pemborosan dan memberikan pengalaman yang lebih baik bagi pengguna. Tidak seperti parameter hidden, parameter field memungkinkan kolom disertakan atau dikecualikan berdasarkan Eksplorasi-per-Eksplorasi.
Sembunyikan Eksplorasi yang hanya ada untuk mengisi Look, kartu dasbor, atau filter tertentu menggunakan parameter hidden untuk Eksplorasi. Jelajah yang tidak dimaksudkan untuk eksplorasi oleh pengguna harus disembunyikan dari antarmuka pengguna.
Gunakan Eksplorasi sesedikit mungkin, tetapi tetap memungkinkan pengguna mendapatkan akses ke jawaban yang mereka butuhkan dengan mudah. Pertimbangkan untuk membagi Jelajah menjadi berbagai model untuk berbagai audiens guna membatasi opsi yang tersedia untuk setiap grup pengguna. Jumlah optimal Jelajah berbeda untuk setiap bisnis, tetapi terlalu banyak Jelajah cenderung membingungkan pengguna. Pertimbangkan untuk menggunakan parameter group_label untuk Jelajah dalam model, yang akan memungkinkan Anda mengelompokkan Jelajah dengan cara yang masuk akal dalam menu drop-down Jelajah.
Menambahkan deskripsi agar pengguna mengetahui kolom dan Jelajah mana yang akan digunakan
Gunakan parameter description pada dimensi dan ukuran untuk memberikan informasi tambahan kepada pengguna tentang logika atau penghitungan yang digunakan dalam model. Hal ini sangat penting untuk dimensi dan ukuran yang memanfaatkan logika atau penghitungan yang kompleks. Meskipun demikian, sebaiknya pertimbangkan juga deskripsi untuk kolom yang lebih sederhana untuk memastikan pengguna memahami definisi di baliknya.
Tentukan Deskripsi Jelajahi untuk pengguna. Tambahkan deskripsi singkat ke setiap Jelajah untuk menentukan tujuan Jelajah dan audiens yang akan menggunakannya.
Membuat alur kerja umum ke dalam Looker
Tambahkan drill_fields ke semua ukuran yang relevan. Kolom perincian memungkinkan pengguna mengklik nilai gabungan untuk mengakses data mendetail. Gunakan parameter set untuk membuat kumpulan kolom yang dapat digunakan kembali yang kemudian dapat diterapkan ke sejumlah ukuran dalam tampilan.
Tambahkan drill_fields ke semua dimensi hierarkis. Misalnya, menambahkan drill_field untuk Kota ke dimensi Negara Bagian akan memungkinkan pengguna memilih negara bagian, lalu melihat perincian lebih lanjut tentang kota dalam negara bagian tersebut. Perhatikan bahwa pengeboran hierarkis ini akan otomatis diterapkan dalam grup dimensi waktu.
Siapkan link yang memungkinkan pengguna membuka dan meneruskan filter dengan mudah ke dasbor Looker lainnya atau ke sistem atau platform yang bersifat eksternal terhadap Looker. Lihat
dokumentasi kami tentang parameter link untuk mengetahui contoh penerusan filter melalui latihan.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-25 UTC."],[],[],null,["# Best practice: Create a positive experience for Looker users\n\n*These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers, from implementation to long-term success. The practices are written to work for most users and situations, but you should use your best judgment when implementing.*\n\n\nLookML developers can consider following these tips to improve their users' experience with Looker:\n\n- [Provide users with meaningful field names](#1)\n- [Group similar fields together for easier navigation](#2)\n- [Avoid exposing too much to users initially](#3)\n- [Add descriptions so users know which fields and Explores to use](#4)\n- [Build common workflows into Looker](#5)\n\n\nThese recommendations are explained in further detail in the sections that follow.\n\nProvide users with meaningful field names\n-----------------------------------------\n\n- Use the [`label`](/looker/docs/reference/param-field-label) parameter to apply user-friendly names to dimensions or measures while maintaining database-friendly names within the view and model files. You might consider renaming a couple of common terms, like **Count** to **Number of** and **Sum** to **Total** . If you aren't sure which words are meaningful to users, work with a business user to build some common queries, and see what words the query results use to describe what users are looking for. As an example, suppose the **Inventory Items** , **Order Items** , **Orders** , and **Products** views each have a measure called **Count** . You can use the `label` parameter to give each of these measures a unique and meaningful name, such as **Number of Inventory Items** , **Number of Order Items** , **Number of Orders** , and **Number of Products**.\n- Avoid exposing multiple fields with the same name. For example, measures of `type: count` are automatically created within Looker with the name **Count** . This results in most view files containing a count measure with the same name. Multiple fields with the same name can confuse users. Adding labels or renaming count measures to indicate the object that is being counted will prevent confusion. Other fields to keep in mind include **Created Date** and **Updated Date** , such as in [dimension groups](/looker/docs/reference/param-field-dimension-group).\n- Provide clear names for fields of [`type: yesno`](/looker/docs/reference/param-dimension-filter-parameter-types#yesno). For example, use **Was the Item Returned?** instead of **Returned** to name a field that indicates whether an item has been returned.\n- Name ratios descriptively. For example, **Orders Per Purchasing Customers** is clearer than **Orders Percent**.\n- Name fields and represent values consistently across the model. Using the [`value_format`](/looker/docs/reference/param-field-value-format) or [`value_format_name`](/looker/docs/reference/param-field-value-format-name) parameter to apply formatting such as currency symbols, percentages, and decimal precision to numerical fields will help make everything clearer to your users.\n\nGroup similar fields together for easier navigation\n---------------------------------------------------\n\n- Use the [`group_label`](/looker/docs/reference/param-field-group-label) parameter to consolidate dimensions and measures from individual or multiple joined views that are related. For example, group all geographic information into a **Geography** group to pull all address and location information together within the field picker, rather than having it all listed alphabetically: \n\n ```\n dimension: city {\n group_label: \"Geography\"\n type: string\n sql: ${TABLE}.city ;;\n }\n\n dimension: country {\n group_label: \"Geography\"\n type: string\n map_layer_name: countries\n sql: ${TABLE}.country ;;\n }\n \n ```\n\n\n- Break up large, denormalized tables using the [`view_label`](/looker/docs/reference/param-field-view-label) parameter. Utilize the `view_label` parameter within fields to group fields together logically into separate headings within the field picker. Large, denormalized tables with a lot of fields can be difficult to navigate, so this gives the illusion of multiple views in the left-hand Explore field picker.\n\nAvoid exposing too much to users initially\n------------------------------------------\n\n- Avoid exposing too much to users upon an initial Looker roll-out. Start small, and then expand the options. You don't have to expose all the tables or dimensions and measures at once. You can expose the most important fields at first and then continue to build in more functionality as business users become more confident with data exploration.\n- Hide dimensions that are not relevant to users from the user interface. Use the [`hidden`](/looker/docs/reference/param-field-hidden) parameter on dimensions that will never be used through the user interface (such as ID fields or database update dates).\n- Use the [`fields`](/looker/docs/reference/param-explore-join-fields) parameter within Explores and joins to limit the number of fields that are available to users. Included fields should be only those relevant to the Explore. This reduces bloat and provides a better experience for users. Unlike the `hidden` parameter, the `field` parameter enables fields to be included or excluded on an Explore-by-Explore basis.\n- Hide any Explores that exist solely for populating specific Looks, dashboard tiles, or filters using the [`hidden` parameter for Explores](/looker/docs/reference/param-explore-hidden). Explores that are not meant for exploration by users should be hidden from the user interface.\n- Use the fewest number of Explores possible while still allowing users to easily get access to the answers they need. Consider splitting out Explores into different models for different audiences to [limit the options available for each user group](/looker/docs/access-control-and-permission-management#controlling_feature_and_data_access). The optimal number of Explores is different for every business, but having too many Explores tends to confuse users. Consider using the [`group_label`](/looker/docs/reference/param-explore-group-label) parameter for Explores within a model, which will let you group them in a sensible way within the **Explore** drop-down menu.\n\nAdd descriptions so users know which fields and Explores to use\n---------------------------------------------------------------\n\n- Use the [`description`](/looker/docs/reference/param-field-description) parameter on dimensions and measures to provide additional information to users about the logic or calculations that are used within the model. This is particularly important for dimensions and measures that leverage complex logic or calculations. That being said, it's a good idea to also consider descriptions for simpler fields to be sure that users understand the definitions behind them.\n- Define [Explore descriptions](/looker/docs/reference/param-explore-description) for users. Add a short description to each Explore to specify the purpose of the Explore and the audience who will use it.\n\nBuild common workflows into Looker\n----------------------------------\n\n- Add [`drill_fields`](/looker/docs/reference/param-field-drill-fields) to all relevant measures. Drill fields enable users to click into aggregate values in order to access detailed data. Use the [`set`](/looker/docs/reference/param-view-set) parameter to create reusable sets of fields that can then be applied to any number of measures within a view.\n- Add [`drill_fields`](/looker/docs/reference/param-field-drill-fields) to all hierarchical dimensions. For example, adding a `drill_field` for **City** into a **State** dimension will let users select a state and then drill deeper into the cities within that state. Note that this hierarchical drilling will automatically be applied within time dimension groups.\n- Set up links that enable users to easily navigate and pass filters to other Looker dashboards or to systems or platforms that are external to Looker. See our [documentation on the `link` parameter](https://docs.looker.com/reference/field-params/link?lookml=new#passing_a_querys_filter_values_into_a_link) for examples of passing filters through drills."]]
