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
先把內容和互動做對，再把世界做得精彩。