Re: [討論] 建議公車站牌加設停車按鈕

[PsMonkey (痞子軍團團長)]

※ 引述《YiShenHsieh (汲汲營營)》之銘言：
: 我想許多人等公車都很怕公車會過頭不停
: 我這邊有一個想法提供給各位參考
: 在公車上如果要下車要先按按鈕
: 司機那邊燈號就會亮起來
: 我想相同的道理
: 可以在每個站牌下設立一個按鈕
: 只要按下去之後
: 下一班公車車上那邊該站燈號會亮起
: 表示需要停車
: 待公車停車後 該站燈號就會消失
: 我覺得這種方式就可以讓等待的人安心等待了
: 也可以不用再考驗司機的眼力
: 尤其是下雨與夜間時候

: 推 cookie20125:其實這樣真的不錯，應該是有經費壓力+怕惡作劇才不行   12/15 20:10
: 推 s88239:如果有兩路以上能到 先來的是沒按的，那已經按了的不就囧了  12/15 20:39
: 推 tntchn:手機APP公車停車系統                                      12/15 21:06

: → moriyaorange:這個比較適合用在班次少的路線上，但以目前最好的方   12/15 21:15
: → moriyaorange:式是以手機通訊的方式，類似於電話叫車               12/15 21:15

: → YiShenHsieh:對於s88239的問題 如果該按鈕是可以設置取消的功能     12/15 23:07
: → YiShenHsieh:那應該就可以看到有更快到的路線時 可把原本設定取消   12/15 23:08

: 推 mackywei:用SmartPhone的Location Base系統，旅客到乘車站附近後，  12/15 23:09
: → mackywei:選取路線/目的站/目的地，再傳給指定的公車。             12/15 23:10
: → mackywei:問題會在系統反應的時間跟乘客可能會挑車....             12/15 23:11

  先說，我不是大眾運輸相關科系 or 業者
  只是就一個程式設計師 or（軟體）系統分析的角度來看這個... 需求

  首先，就是這個需求到底好不好呢？
  以我的觀點，相當好，我每次等公車搭公車都會有這個念頭
  而且對司機 or 對乘客都是雙贏
  乘客不用苦苦當望夫石（雖然這年頭已經好很多了）
  司機在特定條件下也可以很理所當然的過站不停，加快行車速度
  （當然，這有點遙遠，後敘）

  你說軟體系統 or 軟體技術有沒有辦法作到呢？
  太複雜的細節我們就跳過（反正也不是你寫 or 我寫，怕什麼 XD）
  簡單地說，如果 5284 這種公車動態資訊都已經 online 了
  那麼剩下來的流程就是

        1. 乘客 A 新增一個 request 給 server
        2. server 根據公車動態資訊，將訊息傳送給某公車
            2.1 更好的作法是也送給某車站的顯示系統
        3. 某公車的某裝置接收到訊息，alert 司機

  理論上也沒有問題，剩下來就是軟硬體經費... blahblah


  那我這篇就是徹底的廢文了 [喂喂]


  實際上，我可以這麼說：

        拜託，有錢也不要浪費來搞這個好嗎？

  原因在上頭各位大大們的推文已經寫了開頭了
  只是我缺 P 幣，所以就來畫蛇添足一下 [毆飛]


  這個 idea 首要的天敵就是：同個路段有太多路線重疊。
  以中永和為例，中正橋頭→中興二村
  就有 214 / 262 / 249 / 670 / 304 可以選擇
  （很久沒看到 242 / 248 / 227 就姑且跳過）

  這樣會造成什麼問題？ 很多...
  第一個問題就是：我到底要通知哪一班公車？

      a.軟體設計成「通知哪一班公車」
        那麼大多數人一定會統統都勾
      b.按照 mackywei 的「起點跟終點」設計想法

  a 的作法實在很愚蠢，而且會炸出更多問題
  例如推文中的「取消」機制就會變得很複雜
  因為：
        a.1 使用者忘記按取消
            即使設計成只要一個按鍵「我已上車」就好
            也還是會有一卡車的人忘記要按
            就像現在語音報站做的很徹底
            還是有人會顧著當低頭族然後車們都要關了才大喊下車 ＝＝"
        a.2 214 / 262 / 304 幾乎同時進站
            要取消也來不及，結果可能不用進站卻還是要來這麼一下
        a.3 server / communication loading problem
            （我只是使用者，管你去死 [踢]）

  b 的想法看起來很 user friendly 的，但是

        b.1 介面很難設計的很簡單好用（誰知道你要去哪裡？）
            可能你都還沒來得及設定完目的地
            結果公車已經到了
        b.2 系統認定的車子 311 來了，你嫌太繞
            想要 262 / 249 這種兩點一直線的車子
            回歸問題 a 或是 b.1
        b.3 其實我真正的目的地是 http://goo.gl/maps/svcN6
            5 路我也可以... 於是又回到 b.1 跟 a.1
            或著中興二村只是我的轉乘點，還有其他目的地可選擇...
            我還不如盯著車子還比較快
        b.4 server / communication loading problem、
            server 程式很難寫
            （我只是使用者，管你去死 [踢]）


  好，UI 設計的問題解決、
  使用者的良好習慣也都養成（我個人對這點極度悲觀），
  那麼，還會有什麼後續問題呢？

        c. 熱門路段（像公車專用道），這系統基本上沒啥意義
           原因類似 b.1
        d. 熱門時段冷門路線，車來了也未必上得去
           還得重新再設定一次

  結果只有冷門時段的冷門路線
  那種半個小時、一個小時才發一班車，才能顯現出價值
  於是就會炸出一個更根本的問題：

        這個系統建置、維護的成本
        說不定都可以讓冷門路線用 307 的方式營運 [誤]

  那些 UI 設計、a.3、b.4 的解法，
  背後都是用 $$（或著新鮮的肝臟）堆出來的
  賠錢生意沒人作阿老闆...... Orz

  更不用說，對於乘客來說
  建置這些系統，還不如一個倒數計時器來的實在？

  這些還只是我臨時、嘴砲階段的 defence
  實際分析起來應該還有更多反對理由  Orz


  當然，可能有很多盲點是我沒有想到的
  也歡迎大家詰譙...... (艸)


--
錢鍾書：    說出來的話
                                                  http://www.psmonkey.org
    比不上不說出來的話
                                                  Java 版  cookcomic 版
  只影射著說不出來的話
                                                  and more......

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 220.129.132.206
推 kutkin:就是預估到站時間讓乘客去挑選要等哪一台就好
→ hgame:很中肯啊
推 cassine:覺得班次少或是偏遠路線比較有用，307這種的沒太大意義
推 shun01:227班次有這麼少?
推 sayin:會衍伸另一個議題 誰有權管控那顆按鈕不被亂按 有沒有補救
推 treasuredady:是不是可以直接輸入想搭的路線編號？！
→ hicker:如果說起訖點只有一條路線就還好 但有多條路線的話
→ hicker:本文所述的問題就會很真實且殘忍的發生了
推 visa9527:按鈕問題就跟後門刷卡下車一樣大家先預設會逃票
→ hicker:這就是相信人性本善還是本惡的問題了....
→ Schelfaniel:感覺上這系統就是要做的工多，但成效不大....
推 Kazamatsuri:有些公司目前有實施行駛外側依序進站的措施
推 lina7inverse:同為科技人中肯用心推！
→ edctw:倒數計時器+按鈕 自己看情況按 結案