WEBVTT

1
00:00:00.700 --> 00:00:04.755
看到一個可以旋轉、點擊、探索的島嶼網站，

2
00:00:04.975 --> 00:00:08.614
我們很容易先問：這是用什麼三維技術做的？

3
00:00:08.834 --> 00:00:13.227
但要真正做出同一類作品，需要理解三個層次。

4
00:00:14.447 --> 00:00:20.173
底層是內容與證據，中層是互動規則，最上層才是三維畫面
。

5
00:00:20.393 --> 00:00:23.843
這堂課會用一個完全虛構的城市學習島，

6
00:00:24.063 --> 00:00:27.041
帶設計師與前端工程師共同規劃。

7
00:00:28.261 --> 00:00:30.425
最後你們應該能說清楚：

8
00:00:30.645 --> 00:00:35.511
誰來使用網站、資料怎麼整理、點擊如何找到內容，

9
00:00:35.731 --> 00:00:38.402
以及怎麼做出第一個可測試的版本。

10
00:00:39.622 --> 00:00:43.974
我們研究的參考網站，從公開程式碼可以確認，

11
00:00:44.194 --> 00:00:47.903
它使用原生 JavaScript 模組、Three.

12
00:00:48.123 --> 00:00:52.567
js、透視相機、軌道控制器與點選偵測。

13
00:00:52.787 --> 00:00:55.459
建物可以由程式組合幾何形狀，

14
00:00:56.679 --> 00:00:58.804
政策資料則由 JSON 驅動。

15
00:00:59.024 --> 00:01:03.843
我們沒有確認它使用 React、Vue、後台內容管理
系統，

16
00:01:04.063 --> 00:01:06.480
或任何特定的人工智慧工具。

17
00:01:07.700 --> 00:01:10.869
這次也沒有完成原站實際渲染驗證，

18
00:01:11.089 --> 00:01:14.415
所以接下來看到的圖形都是教學示意，

19
00:01:14.635 --> 00:01:16.808
不是假裝錄到原站的操作。

20
00:01:17.028 --> 00:01:21.078
確認過的事實與我們提出的做法，要始終分開。

21
00:01:22.298 --> 00:01:26.440
第一份產出不是三維模型，而是一頁網站計畫。

22
00:01:26.660 --> 00:01:28.503
先列出使用者與任務。

23
00:01:28.723 --> 00:01:31.784
例如探索者想知道有哪些公共議題，

24
00:01:32.004 --> 00:01:35.660
研究者則想快速找到某一筆資訊與出處。

25
00:01:36.880 --> 00:01:40.890
前者適合島嶼探索，後者需要搜尋與清單；

26
00:01:41.110 --> 00:01:44.500
不要逼每個人都旋轉城市才能讀內容。

27
00:01:44.720 --> 00:01:46.284
接著決定資訊架構：

28
00:01:46.504 --> 00:01:52.648
首頁介紹、主題入口、項目摘要、完整說明、來源與更新日
期。

29
00:01:52.868 --> 00:01:57.447
每個畫面都要回答一個問題：使用者下一步能做什麼？

30
00:01:58.667 --> 00:02:02.286
驗收也不要只寫漂亮，要寫可測試的任務，

31
00:02:02.506 --> 00:02:07.952
例如第一次使用的人能否找到公共空間主題，開啟一項計畫
，

32
00:02:08.172 --> 00:02:09.479
並追溯到來源。

33
00:02:09.699 --> 00:02:12.661
成功率與花費時間，由實測決定。

34
00:02:13.881 --> 00:02:17.539
把政策內容做成互動，關鍵是資料結構。

35
00:02:17.759 --> 00:02:24.060
本課的 starter 有三個主題、六個提案、三條關
係與三份虛構來源。

36
00:02:24.280 --> 00:02:27.875
content 點 JSON 保存主題、項目、關係、

37
00:02:28.095 --> 00:02:30.927
來源、有效日期與編輯溯源；

38
00:02:32.147 --> 00:02:35.079
layout 點 JSON 另外保存座標與顏色。

39
00:02:35.299 --> 00:02:38.332
標題可以修改，識別碼不能任意改。

40
00:02:38.552 --> 00:02:42.611
畫面建築只是一種視覺表示，不等於真實建築。

41
00:02:42.831 --> 00:02:46.875
來源用 ID 引用，不要四處複製同一段文字。

42
00:02:48.095 --> 00:02:53.673
像步行導覽線這筆資料，可以同時產生清單、卡片和建物。

43
00:02:53.893 --> 00:02:59.445
座標不寫進政策事實，未來更換場景時，內容就不用重做。

44
00:02:59.665 --> 00:03:01.669
注意畫面只是欄位節錄，

45
00:03:01.889 --> 00:03:04.596
完整可執行資料請看 starter。

46
00:03:05.816 --> 00:03:10.332
當你畫出一條線，甚至讓人流或光點沿著線移動，

47
00:03:10.552 --> 00:03:14.173
使用者可能以為這是經過證實的影響關係。

48
00:03:14.393 --> 00:03:18.729
因此，關係也必須是資料，不能只是美術效果。

49
00:03:18.949 --> 00:03:24.325
資料要說明起點、終點、關係類型、證據等級與出處。

50
00:03:24.545 --> 00:03:27.336
參考網站的資料包含證據等級，

51
00:03:28.556 --> 00:03:33.232
並把標示為未確認、不動畫的關係排除在動畫之外。

52
00:03:33.452 --> 00:03:37.066
我們的示範用 evidenceStatus 欄位實作
這個原則：

53
00:03:37.286 --> 00:03:39.836
兩條 supported 關係可以畫線，

54
00:03:40.056 --> 00:03:43.980
一條 pending 關係不畫線，但保留文字說明。

55
00:03:44.200 --> 00:03:46.350
所有來源都是虛構教材。

56
00:03:47.570 --> 00:03:48.826
沒有資料支持，

57
00:03:49.046 --> 00:03:53.438
就不要把流動速度、流量或成功率演成真實統計。

58
00:03:53.658 --> 00:03:57.424
示意動畫要標示為示意，模擬要交代假設。

59
00:03:57.644 --> 00:04:02.570
即使兩個項目同時發生，也不代表其中一個造成另一個。

60
00:04:02.790 --> 00:04:08.051
來源卡必須能指出文件、日期，以及支持的是哪一句主張。

61
00:04:09.271 --> 00:04:12.994
開始做三維時，先不要追求完整城市。

62
00:04:13.214 --> 00:04:16.453
先做一個島、一種建物、一張卡片。

63
00:04:16.673 --> 00:04:20.372
Three.js 負責場景、相機與渲染器；

64
00:04:20.592 --> 00:04:22.913
控制器處理旋轉和縮放；

65
00:04:24.133 --> 00:04:28.873
幾何工廠把方塊、圓柱與屋頂組成可重用的模型。

66
00:04:29.093 --> 00:04:33.562
資料只要指定模型類型與位置，就能建立場景物件。

67
00:04:33.782 --> 00:04:37.784
像樹木、窗戶或路燈這種大量重複物件，

68
00:04:38.004 --> 00:04:39.882
可以考慮實例化繪製，

69
00:04:40.102 --> 00:04:43.405
但不能以為用了實例化就不用測試效能。

70
00:04:44.625 --> 00:04:47.970
裝飾、內容物件與互動標記要分層，

71
00:04:48.190 --> 00:04:50.593
避免使用者點到不重要的葉子。

72
00:04:50.813 --> 00:04:54.204
水面和天空的著色器可以最後再加。

73
00:04:54.424 --> 00:04:58.734
先確保內容可讀、操作正確，再追求氛圍。

74
00:04:59.954 --> 00:05:02.602
點擊不是直接把模型變成文章。

75
00:05:02.822 --> 00:05:06.438
通常是先把指標位置轉成場景中的射線，

76
00:05:06.658 --> 00:05:09.339
由 Raycaster 找到交會的物件。

77
00:05:09.559 --> 00:05:13.628
物件保存項目 ID，再利用 ID 查詢資料，

78
00:05:14.848 --> 00:05:19.976
更新選取狀態，最後讓卡片和場景同時反映這個狀態。

79
00:05:20.196 --> 00:05:25.448
這個流程的重點，是資料、狀態與畫面各自負責一件事。

80
00:05:25.668 --> 00:05:27.701
如果模型有多層子物件，

81
00:05:27.921 --> 00:05:31.260
要確保命中的子物件能找到所屬項目，

82
00:05:31.480 --> 00:05:34.427
不能假設每個三角形都有 ID。

83
00:05:35.647 --> 00:05:38.716
搜尋清單也呼叫同一個選取函式。

84
00:05:38.936 --> 00:05:42.729
這樣即使使用者不用滑鼠、不看三維畫面，

85
00:05:42.949 --> 00:05:45.116
仍然可以開啟相同內容。

86
00:05:45.336 --> 00:05:50.497
關閉卡片、清除選取與返回上一個結果，也要明確設計。

87
00:05:51.717 --> 00:05:54.719
實作時先安裝 Node 二十二版以上，

88
00:05:54.939 --> 00:05:56.566
進入 starter 目錄，

89
00:05:56.786 --> 00:06:00.578
依序執行 npm ci 加上 ignore scri

90
00:06:00.798 --> 00:06:05.619
pts 選項、npm test、npm run ch
eck，

91
00:06:05.839 --> 00:06:07.608
最後 npm start。

92
00:06:07.828 --> 00:06:12.025
開啟伺服器啟動時設定的本機 HTTP 網址，

93
00:06:12.245 --> 00:06:16.065
預設是四一七三連接埠，不能直接雙擊檔案。

94
00:06:17.285 --> 00:06:20.889
教材鎖定 Three.js 零點一八六點一，

95
00:06:21.109 --> 00:06:23.523
與原站觀察的一六零版不同。

96
00:06:23.743 --> 00:06:26.830
這不是 React 專案，也沒有 build 步驟。

97
00:06:27.050 --> 00:06:28.941
第一步修改 content 與 layout，

98
00:06:29.161 --> 00:06:30.255
跑資料驗證。

99
00:06:30.475 --> 00:06:35.668
第二步在 app 與 model 做清單、搜尋、日期
和共同狀態。

100
00:06:36.888 --> 00:06:41.085
第三步在 scene 建三島六棟，接上點擊與高亮。

101
00:06:41.305 --> 00:06:44.124
第四步加入兩條有來源的關係線，

102
00:06:44.344 --> 00:06:46.894
以及一條不畫線的待確認說明。

103
00:06:47.114 --> 00:06:50.103
先跑通內容閉環，再增加美術。

104
00:06:50.323 --> 00:06:54.253
工作副本已通過十項測試、四份語法檢查；

105
00:06:54.473 --> 00:07:01.160
本次也用實際瀏覽器核對三維點選、拖曳、搜尋、日期與鍵
盤操作。

106
00:07:01.380 --> 00:07:04.122
真實觸控與完整效能仍待驗收。

107
00:07:05.342 --> 00:07:09.042
三維網站最常見的問題，不是模型不夠細，

108
00:07:09.262 --> 00:07:13.439
而是手機操作困難、文字太小、載入太久。

109
00:07:13.659 --> 00:07:17.239
設計時就要保留二維清單與文字詳情，

110
00:07:17.459 --> 00:07:20.564
支援鍵盤焦點、可理解的按鈕名稱，

111
00:07:20.784 --> 00:07:23.056
以及減少動態效果的偏好。

112
00:07:23.276 --> 00:07:25.741
重要狀態不能只用顏色表示。

113
00:07:25.961 --> 00:07:30.376
行動裝置可以降低像素比、減少陰影與裝飾密度，

114
00:07:31.596 --> 00:07:33.234
並依實際測試調整。

115
00:07:33.454 --> 00:07:37.421
不要為了漂亮開場讓使用者長時間無法閱讀。

116
00:07:37.641 --> 00:07:42.993
效能測量至少包含首次可操作的時間、互動時的幀時間，

117
00:07:43.213 --> 00:07:46.186
以及重複開關內容後的記憶體變化。

118
00:07:46.406 --> 00:07:49.169
測試案例包括搜尋典藏剩一筆，

119
00:07:49.389 --> 00:07:52.913
日期二零二四年十二月三十一日剩兩筆，

120
00:07:53.133 --> 00:07:54.913
二零二三年底剩零筆。

121
00:07:56.133 --> 00:08:00.016
日期只是有效區間篩選，不是歷史狀態回放。

122
00:08:00.236 --> 00:08:03.770
三維載入失敗時，內容清單仍應可用。

123
00:08:03.990 --> 00:08:09.933
請再用真實瀏覽器驗收三百七十五像素寬度、兩倍縮放、鍵

124
00:08:10.153 --> 00:08:12.736
盤、觸控與停用 WebGL。

125
00:08:12.956 --> 00:08:16.659
CSS2D 標籤有百分之百縮放限制，

126
00:08:16.879 --> 00:08:18.975
文字清單仍是可靠替代。

127
00:08:19.195 --> 00:08:23.375
不能把射線數學測試，當成真實點擊已經驗證。

128
00:08:24.595 --> 00:08:27.622
最後，網站不是發布一次就結束。

129
00:08:27.842 --> 00:08:29.405
建立內容欄位規範，

130
00:08:29.625 --> 00:08:35.165
讓編輯知道摘要長度、狀態定義、來源要求與誰負責審核。

131
00:08:35.385 --> 00:08:36.532
正式發布前，

132
00:08:37.752 --> 00:08:43.374
自動檢查重複 ID、找不到的引用、非法狀態與缺少的日
期。

133
00:08:43.594 --> 00:08:48.818
人工審核則確認文字是否準確、來源是否真的支持主張，

134
00:08:49.038 --> 00:08:51.262
以及圖像有沒有造成誤導。

135
00:08:51.482 --> 00:08:54.257
初期可以使用版本控制中的 JSON，

136
00:08:54.477 --> 00:08:56.440
不一定需要先做後台；

137
00:08:57.660 --> 00:09:02.157
資料量和編輯人數增加後，再評估內容管理系統。

138
00:09:02.377 --> 00:09:07.009
每次發布都保留可追溯版本，讓修正與回復有依據。

139
00:09:07.229 --> 00:09:11.385
政策文字、資料連結和場景表現要一起驗收，

140
00:09:11.605 --> 00:09:14.300
不能只看畫面有沒有正常打開。

141
00:09:15.520 --> 00:09:20.166
接下來請設計師與前端一起完成五份小型交付物：

142
00:09:20.386 --> 00:09:27.351
一頁網站計畫、一份資料字典、一張點擊到內容的流程圖、
一個三島原型，

143
00:09:27.571 --> 00:09:29.638
以及可測試的驗收清單。

144
00:09:30.858 --> 00:09:36.052
練習時，故意加入一個缺少來源的項目與一條未確認關係，

145
00:09:36.272 --> 00:09:41.207
看看系統能否正確提醒，而不是照樣演出可信的效果。

146
00:09:42.427 --> 00:09:46.648
真正值得學習的，不只是把政策變成漂亮的城市，

147
00:09:46.868 --> 00:09:51.151
而是讓每個視覺元素都能回到清楚的資料與證據。

148
00:09:51.371 --> 00:09:55.297
先把內容和互動做對，再把世界做得精彩。