其實這個之前有講過，就是一定要有公權力的人，還是需要一個位階，也就是看去發到他們的手機裡面，必須要刷，看這個系統要如何設計。

至於量比較小的那一些部分，說真的就沒有必要建置這一種東西，他的爭議也比較少，這個是可以考慮的方向，謝謝。

其實容易發生糾紛的跟量最大的，其實就是特定的幾個地方，這一種東西比方怎麼給資料集合，其實可以給電子票，在那幾個點設置專門的稽核站，那就是變成每一個隊員過，出去其實也是用一樣的方法。

當然也可以說是自主的人可以用商業隊的手法，但是其實他們不會花那時間來學Excel表怎麼建的，其實都是海量申請的預算，其實是主要是來自於商業隊，不是絕大多數的使用者進來，其實那個入口點不太一樣，因此這個考慮上是有這幾個層面要比較想的。

但是還有一個點是，商業隊的輸入不是那樣子，其實跟國家公園剛剛的要求，其實最後為何Excel要輸入，其實Excel就直接放進去了，所以他們要的介面跟一般真的自主使用介面又不太一樣。

其實像手機的下拉式選單是喜歡的用的方式，你考慮一個使用者想要做的情況是這樣子。

像剛剛路線狀況的問題，那個也可以用顏色來處理，像紅色表示現在是有狀況的，綠色表示ok的，像雪山常常就到了4月的時候還在那邊不知道是雪季或者是雪季的狀況，像顏色是黃色或者是紅色之類的。

我要講的跟剛剛有一點呼應到，你剛剛講下拉式選單就會非常長，你猜測最可能要的是放在最前面，這個可以從兩個地方去做，一個是申請量，一個是哪一個地方被拉高，像兩天對兩天，所以就會被拉高，其實也不是下拉式選單，也就是把那幾個點進去選。

（點頭）

也就是常用的東西現在抽走，剩下麻煩的東西再處理，不管是形成規劃或者是後面要進到介面開始，如果以這個導向去想的話，像太魯閣的錐麓古道跟林務局的北插天山是同一類，會跨過部門間的屏障，而是用另外一種邏輯來統合。

是不是要考慮帶進來的觀念，先把大流量分掉？其實民眾考慮要去哪裡玩，其實是大假期，選擇路線的方法是跟天數有關的，這個假期是兩天或者是三天或者是十天的天數，又或者是一天的，這一種大眾化的部分，其實高達99％以上，那個就有一點像我的最愛。

大家好，我今天來這邊的角色比較像山友，但是我自己其實本身也算是寫程式，只是不是寫這麼高層的程式，而是寫底層的程式，因此對於流程及山友的需求有一些比較綜合性的瞭解，希望來這邊看幫上什麼忙。