provence wrote:
只問一個問題，標準是...(恕刪)
大就是有他說話的本錢
其他系統只能期待自己慣用的系統有一天能變大
這就好像為什麼全世界共通的語言是英文而不是中文
如果大家能夠把這些迴響全部讓銀行們知道
我想聲音夠大聲他們就會去開發
前面文章太多了還沒時間讀完
但是就剛剛讀的幾篇我發表我的想法:
1. XP 在新增及移除元件中確實可以把 IE 拿掉
當然也不是真的就完全把他從電腦中移除
只是就不讓他在你使用上出現
2. 前面有很多人講到蘋果是小眾市場
沒辦法支援是理所當然, 依銀行他們的角度來說不去開發個支援蘋果的平台絕對是最省的
以上這點我完全認同
我也沒那麼傻到不知道這世界就是看錢在講話
但是我覺得現在蘋果使用者越來越多了
所以應該一起去努力講出這個聲音
沒想到絕大多數的台灣消費者選擇的聲音是
"沒辦法我們是小眾, 算了" 或是
"很正常啊, 我也習慣了"
至於前面有人舉出牛肉麵的例子
你說我不應該要求酸菜,
但是我覺得今天我不能夠使用網路銀行的話並不是我沒吃到酸菜, 是我整晚牛肉麵被拿走了
我認為, 基於公平交易的準則上
賣方必須在交易前完整告知買方產品實情
如: 這東西含有反式脂肪吃下去對健康不好,
這個玩具五歲以上兒童才適合, 肯能會給五歲以下的兒童帶來某種危險等等...
當然, 我舉的例子是會直接危害到使用者的
但是要是我開了銀行戶頭卻又不讓我查詢我的帳戶資料, 這樣跟沒開不是一樣?
希望台灣的消費者不要默許這樣不公平的待遇, 你該有怎麼樣的消費自己要去爭取
有一位提到說面紙盒工廠的例子。
****那個例子要表達的主題是﹍『不要脫褲子放屁』、『不要將事情複雜化』
但，事實是﹍複雜化的是ms的ie。
最早的網路語言、各種協定，基本跟ms公司無關的。而今天台灣的網路銀行們，大多卻是『遵守』ms出台的『新』的規格。
最佳例子是 ActiveX
而，這東東跟ssl之類的安全性可沒有多大的關聯。
有一位提到說『不需要』為了小眾市場開發。
哼哼，但怎不反過來說呢？
有能力另外去買蘋果的，相對是比較有經濟基礎的，比較有購買力的。（當然，這是大多的刻板印象）
這樣得客戶，是否比較值得去掌握？
還有，別忽略口語傳播的力量。
一個人說某銀行的系統相容性不好，就會傳達給三個人知道。然後，三個人傳播九個人，九個人傳播二十七。依此類推。
銀行﹍是服務業﹍服務業講求的是服務品質，如果還去計算經濟效益﹍那不如去開工廠算了。
當然，不諱言的，經濟效益仍舊是最後追求的目標。但是，此經濟效益跟你所謂的經濟效益，是不可以畫上等號的。
追本溯源，為啥現在的網路銀行介面大多是如此的不兼容ie以外的軟體呢？
不要說網路轉帳不支援，即使是網路刷信用卡、網路查帳戶餘額、基金買賣等，都不支援！
這事情幾年前也曾經討論過，網路多衝浪幾次，就可以發現以下原因
一、許多寫網頁的『工程師』，本來就是學ie的基礎。也不特別學習另外，根本就是拿ms包裝好的元件，直接套用。
當然無法相容其他的瀏覽器。
二、有的『工程師』，則是為了使網頁顯示好看，特別用了一些『很新』的java，或是ms特別的插件，才可以正常顯示。
如果網路銀行的介面，是必須另外開發，則可以達到兼容。那的確不需要捨本逐末。
如果，按照『標準規格』就可以寫好，同時兼顧安全與兼容，那是否『本來』就要往這方面努力呢？
如果，上面這想法只是緣木求魚，那玉山是笨蛋？hsbc是瘋子？中華電信是潘仔？
（中華電信並非每個網頁都不支援mac，至少，電話費網路繳費是百分百可以支援的。）
小弟並非抱怨web atm，因為即使是『ic卡讀卡機』，可以兼容mac的本來就不多。
但是，就連基礎的網路銀行，許多銀行的網頁可是連『登入』，都無法登入。這不是奇哉怪哉？
========
我可以這樣大膽的說，如果連服務小眾的客戶都不用心
那實在不用期待這銀行會在別的小地方認真了。
========
provence wrote:
只問一個問題，標準是...(恕刪)
這位大哥，跟您報告一下，IE 8 由於增加了對「標準」語法的支援，而且是預設值，因此針對 IE 7 以前的語法寫的網站，用 IE 8 是有可能會出問題的。（http://en.wikipedia.org/wiki/Internet_Explorer_8#Rendering_engine）因此舊的語法需要下參數告知 IE 8 進入所謂的「Compatibility mode」，強制使用 IE 7-like 的 rendering engine 來呈現內容。
微軟是間大公司，他們也有意識到網路「標準」的重要性，因此在新產品上才會做出這樣的改良。
再來微軟支援的類 JavaScript（JavaScript 跟 Java 是不一樣的），正確來說要稱之為 JScript，由於添加了很多專屬語法跟函式庫，故有經驗的網頁設計師會盡量避免使用專屬語法，以避免網頁在不同平台或瀏覽器上顯示不正常。使用 Mozilla Gecko 或者是 Apple WebKit 引擎的瀏覽器等用的 JavaScript 直譯引擎支援的才是一般所謂的 JavaScript。由於現在幾個著名的 AJAX frameworks 都有針對瀏覽器相容性處理過，因此使用這些 frameworks 來開發前端平台是可以省掉很多麻煩的。
由於台灣的教育環境使然，使得許多學校教學上偏以特定平台的方式教育學生，個人以為是降低國際競爭力的一種作法，相當可惜。
上面已經有很多位先進提出來，其實前端系統（使用者接觸到的使用者介面）一般都只是將後端系統的資料呈現出來，並提供項目供使用者與系統互動，因此支援什麼瀏覽器、語法，前端就可以做變更，不必動到後端的架構。
說到底，真的只是做與不做的差別。
加菲爾大說到重點了，重點就是這個心態問題。要是大邊小邊「只能」選一邊，那選大邊我完全可以接受，畢竟在商言商。要是同時顧兩邊很花成本所以只顧一邊，那我也很能接受，開銀行畢竟不是開善堂。但要顧兩邊明明就很可行而且成本不用提高，甚至更低，實際用過 HSBCDirect 的人大概就能體會到我在說什麼。是不是還有其他簡單便宜又安全的方法，我猜只要有心應該想的出；想不出來就抄人家的作法吧。
前面也點到一個還蠻常見到的現象，就是有些開發人員其實就已經是便宜行事不用功，所以要求他做他熟知的範圍以外的東西就百般不願意，把事情講得很複雜很高成本（搞不好他們的主管也就以為非IE專屬真這麼複雜困難）。像有些美術人員號稱 Photoshop 高手，但卻不了解圖檔壓縮的特性，所以把都是色塊的報表圖用 jpg 來輸出放到網路上而不用 gif 或 png。有些做網頁的人只會開發工具而不了解 HTML，所以何時該用 div 何時該用 td 來做內容的容器搞不清楚。有些寫程式的人其實會的不是那個程式語言而是某個強大的 IDE，不用它內建的功能和元件（常常也就專屬）就不知道怎麼寫出個像樣的東西。對那些半桶水而言，講跨平台、共通標準什麼的實在有些沈重。
反正我廢話一堆都不重要，重要的就是有各位如果需要用 IE 以外瀏覽器來使用網路銀行，請換到玉山或匯豐去，目前已知這兩家有 solution。
內文搜尋
從 APP 打開
X