訂閱

上次更新

February 01, 2015 12:00 PM

所有時間皆為協調世界時(UTC)。

Powered By

Planet

摩茲星球 | MozTW Planet

這邊是工作人員碎碎念的地方,您可獲得最新出爐的資訊以及最不成形的想法 :P

January 31, 2015

Othree

在盲人之前的親和力

不少人還會直接把網站的親和力(無障礙)問題和盲人朋友直接連在一起,覺得應該來解除迷思一下,盲人朋友確實是最直接會想到的,各種有身心障礙人士的族群當中,盲人朋友使用電腦上網的難度也是最高的,不過在你把眼睛矇起來體驗盲人如何操作電腦之前,有不少事情是可以先做的,隨便把腦袋裡馬上想的到的列了一下:

首先是網頁的文字內容易讀性,易讀性有分兩個面向,第一個面向大家比較清楚,就是文字排版、字形挑選、顏色對比等等視覺上的易讀程度,這部分做的好的話除了對老花眼、近視或是弱視的朋友有幫助外,一般人也會受惠;另一個面向則是文字內容好不好理解的程度,如果網站上的文字說明太難懂,那就應該要用更好理解的文字來重新講一遍,或是加上圖表輔助,或是乾脆減少資訊量,通常自己看的懂,不代表別人看的懂,所以如果是重要的說明(尤其是政府網站一些流程、辦理辦法之類的),建議都要找人看過,最簡單的是找家中長輩,因為網路上理解力較低的族群中,長輩們佔不少。

第二個是操作介面好不好操作,通常是 Web App 才有這需求,一樣有不同的面向,第一個是你的操作介面應該設計的容易理解,讓人看了也不會疑惑應該點哪裡,其中一個很重要的原則是不要破壞使用者的習慣,第二個面向是有些人可能無法好好的控制滑鼠(要模擬這個比模擬盲人的情境還要難),點擊不精確,所以永遠要保留鍵盤操作的選項,如果是使用原生的輸入元件來做操作介面的話,沒有亂做什麼奇怪的事情應該是都可以用鍵盤來控制,但是如果要自己設計一個嶄新的控制元件,那記得要好好利用 WAI-ARIA 來讓鍵盤可以順利的控制,像是 Google 的 Gmail 就有完整的鍵盤操作支援,這個應該是這篇文章當中做起來最辛苦的一項吧。

第三個是表單行為,要把表單作的好填,本身是一門很大的學問,不過在深入的思考設計表單的 usability 之前,有一些很基本的功能是應該具備的,其中特別想說的是錯誤訊息的處理,使用者送出表單後,如果後端的檢查沒過被打回來,應該要伴隨著能幫助使用者更新資料的錯誤訊息,並且正確的顯示在正確的位置,不然使用者不知道發生什麼事情,除了告訴使用者哪裡有錯之外,更進一步是讓使用者能把輸入資料改好,例如帳號名稱有格式限制的話,就要明確的說明有哪些限制,另外表單檢查不通過之後,記得也不要把使用者剛剛填的資料清空(實做這點還需要特別記得安全性問題)。

最後一個是文件結構,正確的使用 HTML 標籤,還可以輔以 WAI-ARIA 的 role 屬性,這已經是講到爛的項目了,當然 single page application 算是特殊情形,不過只要你做的頁面還是接近傳統網頁有文字內容,有主要內容的話,把網頁的文件結構弄好還是有兩大好處的:一、SEO 的部分已經好了一大半了;二、所有輔具都可以根據你的文件結構快速的帶領使用者在文件中穿梭,不用多做什麼奇怪的導盲機制。要把這塊做好算是四點當中最簡單的,只要正確的依照語意使用 HTML 標籤,不夠的再看看 WAI-ARIA 有沒有可用的 role,不要亂用標籤,然後用檢視原始碼的功能看看好不好看,如果你能開始從 HTML 原始碼中感受到美感甚至有完美的感覺出來,相信你就在正確的方向上了。

其實以上四點都有一個特色,就是把這些地方做好,不只是身心障礙人士會受惠,文字易讀性就不用說了,操控介面如果支援鍵盤,有些正常人操作起來會更得心應手,表單的訊息也是不論是怎樣的使用者都很需要,而文件結構也是,弄得好的話,大家都好找到資料,站長應該也開心。所以其實在你想要為了提升親和力而去實際模擬身心障礙人士使用電腦的情境之前,是有很多東西是可以先做的,

相信還是有人會有興趣盲人朋友怎麼操控電腦的,曾經 HappyDesigner 有邀請有聲書協會的朋友來介紹,不過已經有點久了,我去年初剛好有機會在 Moztw Lab 遇到 Fancy 示範,當時有簡單的錄下來,有興趣的朋友可以看一下:

至於要怎麼體驗盲人怎麼操作呢?如果你是用 OSX 的話,系統有內建 Voice Over,品質很好,可以直接使用,Windows 有好幾套商業軟體,至於免費的比較有名的是 NVDA,這套也是開源軟體,一開始可能需要先當明眼人練習操作,另外它講的話一開始可能會聽不太懂,聲音合成引擎和商業軟體比起來有差,多聽幾次慢慢就聽的出來再講什麼了。

January 31, 2015 10:58 AM

January 30, 2015

MozLinks-zh

Firefox for Android 的兩個新功能

我們很高興的在此公佈兩個超棒的 Android 版 Firefox 新功能:

  1. 家,甜美又能任意裝潢的家
    以您喜歡的方式安排您的首頁。新增最愛的面板到您的首頁,選擇您預設的面板、或隱藏不需要的。

  2. 快速分享按鈕
    現在您只需要輕輕的按一下分享按鈕,就可以透過您最愛的社交應用程式,快速又容易的分享網頁。(編按:而且 Firefox 還會記住你最愛使用的服務,並放到選單的最上方!)

請確保您已擁有最新版的 Firefox Android 版,或現在就立即下載。這樣,您就能享受一切最新的功能!

原文 / Two new features for Firefox for Android
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ 歐西里斯 翻譯 - Irvin 編輯

by Irvin Chen (noreply@blogger.com) at January 30, 2015 05:46 PM

January 26, 2015

orinx

準備啟程至峇里島參加 CUAsia

先簡單的介紹一下 CUAsia 是什麼吧,他的全名叫做 Coworking Unconference Asia。顧名思義就是亞洲區共用工作空間的 Unconference 。大概會有 100~200 個來自各地的空間維護者,來討論關於共用工作空間的一些經營方向、理念及案例。

這次去主要是希望能夠取經,學習看看其他亞洲國家是怎麼做共用空間管理、規劃、行銷等。也許有些東西能夠來幫助我們的 摩茲工寮 成長;同時也希望能夠在第二天搶到 Unconference topic 的名額,來分享我們 摩茲工寮 是怎麼做分散式的 Keyholder 管理制度、以及我們怎麼透過空間推廣我們所熱愛的 Mozilla 精神 及開源文化。

先把這次主要想要取經的內容先列表寫下來,歡迎大家多給點意見。我在回台灣後,會找間在 摩茲工寮 辦一場簡單的心得分享。如果你有特別期待某個方向的內容,歡迎在我的部落格直接回應討論。我會在 CUAsia 的時候會特別關注這些議題的,不過我去聽/討論的東西主要還是會以能幫助 摩茲工寮 為主

  • 吸取別人的失敗經驗,哪些場地、設備、活動以及行銷方式是不合宜的?成長到最後大家各走出怎樣的路?
  • 當空間成長的速度過快(人數、甚至是場地),該有怎樣的應變措施去確保品質?
  • 怎麼樣讓共用工作空間可以「自己養活自己」,別人是怎麼做的?大家是運用了怎樣的 Business Model 在盈利、非營利的共用空間中
  • 以一個共用空間來說,跟其他公司、政府等單位合作的生態是什麼?
  • 更多… 我有思考到我會再更新上來 :P

by Orin Chen at January 26, 2015 04:04 PM

January 23, 2015

MozLinks-zh

Firefox 附加元件下載突破四十億次啦!

正因有這些令人讚嘆的附加元件,「客製化」成為許多人選擇 Firefox 作為獨立瀏覽器的理由。數字會說話:

  • 有 18,000 個附加元件可供使用
  • 有 369,000 個佈景主題在藝廊中等著你
  • 自 2009 年統計起,捐獻給開發者們的金額已達兩千萬台幣(USD $634,000)
  • 附加元件下載突破 4,000,000,000,四.十.億.次!(大聲歡呼)

多麼「個人化」!在此我們不只為貢獻心力開發超讚 Firefox 附加元件的人歡呼,也要為使用這些附加元件的你們歡呼。今天就來看看最新的附加元件,然後替你的 Firefox 加上一些厲害的功能吧!

原文 / Firefox Add-ons Hit 4 Billion Downloads | The Den
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ Wildsky 翻譯 - Irvin 編輯

by Irvin Chen (noreply@blogger.com) at January 23, 2015 06:24 AM

January 16, 2015

Othree

fetch 二三事

之前介紹過 fetch 之後過了一段時間,有發現幾個目前 spec 上的一些細節要來分享一下。首先是上一篇文章說到的重複 header 的問題,詳細看下去後,發現 fetch 收的 header 參數有兩種,一個是 key value pair 的原生物件,另外一種是 Headers 物件,這個物件是 fetch spec 裡面新定義的:

var h = new Headers();
h.append('X-Custom-Header', '1');
h.append('X-Custom-Header', '2');
h.append('X-Custom-Header', '3');

就可以像這樣用 append 重複加上同樣名稱的 Header,其實丟原生的物件進去,也會在內部被轉成這個 Header 物件。

第二個要說的是關於回應 status code 在 400 到 600 之間時,Promise 物件是 resolve 不是 reject,理由是 Error 和 Exception 不一樣,不過有人開 Issue 在討論,會不會有改變還不知道,倒是如果現在用 github polyfill 想要處理這個問題的話,除了可以自己處理之外,也有人寫了 fetcher 這個,wrapper 可以把 fetch 的一些行為弄得更接近大部分開發者的直覺,目前提供的功能除了這個之外,還有一個是如果回傳的 type 是 JSON,但是內容的 JSON 語法有錯,那也會被丟到 reject 那邊去。

January 16, 2015 04:31 AM

January 07, 2015

MozLinks-zh

重修 Mozilla 資料隱私原則

對於資料運用透明化的承諾,是 Mozilla 的核心特質。我們設立的「資料隱私原則(Data Privacy Principles)」中,清楚的傳達了這份信念。這份在 2011 年首度釋出的原則,是 Mozilla 宣言 的補充資訊,作為我們處理資料時的指引。

今年稍早,我們重新檢視了這份原則,也邀請 Mozilla 跨部門的成員與公眾提供意見。我們將在此公開新版的 Mozilla 資料隱私原則。

這項更新反應了 Mozilla 內外的改變。自 2010 年以來的四年間,Mozilla 成長、發展出過去未有的新產品和服務。在 2014 年的 Snowden 事件後,公眾對於使用者掌控與透明化表達的強烈要求,也成為我們重新檢視產品和與隱私政策的契機。

Mozilla 資料隱私原則,將持續在創造產品、發展服務、管理用戶資料、挑選合作夥伴並與其互動時,作為我們的指引,形塑我們的公開政策與倡議行動。

Mozilla 的五個資料隱私原則為:

沒有意外
以透明與益於用戶的方式使用與共享資訊。

使用者掌控
提倡及運用最佳的典範實務作法開發產品,讓使用者得以掌控他們的資料與線上體驗。

有限資料
只收集需要的資料,盡可能的去身分識別化,並在不再需要時刪除。

合理的設定
在安全性和用戶體驗間取得合理平衡。

深度防禦
維持多層次的安全防護機制,其部分需可被公開驗證。

結合 Mozilla 宣言,當我們為使用者和網路奮鬥時,這份原則將持續指引我們的作為。為維持網路的自由和開放,我們透過透明化及給予掌控權,將使用者置於中心;透過限制資料的收集、合理設定以及強力的防護,將使用者可能遭遇的風險降至最低。

原文 / Mozilla’s Data Privacy Principles Revisited | Mozilla Privacy Blog
作者 / Denelle Dixon-Thayer
授權 / 創用 CC 姓名標示-相同方式分享-3.0

φ 張瑞明、Irvin 翻譯

by Irvin Chen (noreply@blogger.com) at January 07, 2015 01:44 PM

January 05, 2015

Othree

Android L WebView Fullscreen API

今天遇到一個問題是,本來好好的全螢幕影片播放功能,到了 Android L 的 Facebook App 裡的 webview 瀏覽器就壞掉了,而且透過開發工具看沒有錯誤訊息出來,查了一陣子終於發現,最新的 webview 改成使用 Chrome 核心後,有些 API 雖然 Chrome 有支援,但是在 WebView 裡面是沒開啟的。

其實我本來已經有用 feature detection 的寫法了,不過這個情形實際上,requestFullscreen 是找的到,可以執行,也不會有錯誤的,只是就是什麼事情都不會發生,後來才 發現 是要用 document.fullscreenEnabled 來做判斷,這個東西我之前一直覺得在手機上都用不到的東西(桌面瀏覽器通常會先問使用者是否願意讓網頁進入全螢幕),沒想到會在這邊派上用場啊。

January 05, 2015 01:20 PM

December 29, 2014

orinx

2014 剩沒幾天了,把握機會拿今年 SUMO L10n 勳章

Screen Shot 2014-12-29 at 11.59.16 PM

SUMO 是什麼

SUMO 是相撲… 啊,其實是 Support Mozilla 的縮寫 SUMOsupport.mozilla.org。這裡面放的是 Mozilla 各種產品的技術支援,大部份的疑難雜症都能在這裡解決。不過如果你是開發者,想解決或了解更核心、底層的東西。那我會建議你去看看 MDN (Mozilla Developer Network)

L10n 是什麼?

L10n 其實就是 Localization (在地化) 的縮寫,同時他也是一種標準;用於統整一套軟體不同的語系。

為什麼這個時機

因為 SUMO 每年都會有一個勳章可以領,如果你當年度有提交十篇被審核過的文章。如果你跟我一樣,喜歡蒐集這些小東西的話。可以趕快翻譯一下 SUMO 來蒐集小勳章喔。像是我 2012 年的就沒拿到,感覺超可惜的…

SUMO Link : https://support.mozilla.org/zh-TW/

by Orin Chen at December 29, 2014 04:03 PM

December 04, 2014

Othree

關於 TypeScript

type-error

這幾年各種 compile to JavaScript language 盛行,大部分都是朝向讓程式碼更好寫的方向來前進,微軟在 2012 年也推出了 TypeScript 這個 compile to JavaScript language,不過他的方向卻不一樣,TypeScript 是一個 JavaScript 的 superset,意思就是所有的 JavaScript 都是合法的 TypeScript,而 TypeScript 多了一些語法,加入了一些新功能,不過這些新的語法完全都不用也是可以正常的寫程式,給 TypeScript compiler 編譯。

TypeScript 顧名思義,它著重的在資料型別這個部分,JavaScript 是 weak type (弱型別)的語言,寫起來算是很方便,不過這個特性卻也是一些問題的來源,首先最常見到的是因為資料型態不嚴謹而造成的 bug,第二個常被提出來的就是為了實做 weak type 而造成的 performance 下降,因此一直有一些聲音在對抗弱型別這個特性,第一個是 Douglas Crockford 先出聲的,不過一開始是從程式碼的嚴謹和可靠性來說的,因為他當時主力在 JSLint 上,所以對於可靠的程式碼的要求比較高,JSLint 一度還把這項檢查放入,後來接著 Google V8 引擎也對沒有改變型別的變數作了最佳化,然後有 TypeScript,接著未來的 ES7 也可能會加入型別宣告的語法進來,這部分似乎是 Douglas 參與推動的,然後 Google 也打算推出 AtScript 的樣子,AtScript 是 TypeScript 的 superset,更進一步增加了型別相關的特性進來。

TypeScript 是一個介於中間的語言,當然為了支援 JavaScript 不能直接把整個環境都改成強型別的,所以 TypeScript 的作法是讓形別的宣告變為可省略的,如果沒有宣告型別,則一切和以前一樣,如果你的變數有宣告型別,那個變數才會是強型別,在編譯的時候,如果把不同型別的值給它,就會跑出警告訊息,像是 JSLint 一樣。TypeScript 的型別宣告語法中,一些比較簡單的可以和程式碼一起寫:

var str:string;

可是稍微複雜一點,和物件有關係的話,就要獨立寫一段宣告的程式碼了:

interface HotkeysProvider {
    template: string;
    includeCheatSheet: boolean;
    get(combo: string): ng.hotkeys.Hotkey;
    toggleCheatSheet(): void;
}

這段宣告其實是完全獨立於程式碼的邏輯本身,全部砍掉程式也可以運作,本身不牽涉到任何邏輯,所以可以完全獨立出去,在 TypeScript 中稱為 type definition(型別定義) ,常用的副檔名是 .d.ts,感覺上很像是 C 語言的 header file,其實我對於 TypeScript 本身的發展是不太樂觀的,覺得他的佔有率永遠不會起來,但是它的型別定義這塊我到覺得是大有可為,主因是目前沒有比較在業界有使用的到型別定義的語言,寫標準所用的 WebIDL 普極度實在很低,相關的工具開發和支援實在很少,反而 .d.ts 檔知道的人比較多,編譯器也都有了,而且多虧 TypeScript 有開放原碼,事實上也有其它專案有借助 TypeScript 定義檔,像是我在用的 TernJS 這個 JavaScript 自動補完工具,就有提供一個 from_ts 工具 可以把 .d.ts 檔轉成它可以讀的定義檔案,加上有 DefinitelyType 專案,各種不同 JavaScript Library 的定義檔都已經有了,所以 TernJS 就可以利用這些資源,提供各種 Library 的自動補完支援了,不過前提是使用者要知道有這些東西,官方文件其實沒有把這塊講得這麼連貫。

除了 TernJS 的應用外,我相信這些定義檔還可以讓編輯器或是 IDE 可以提供更多的輔助功能,像是或許可以拿來產生編輯器用的 syntax 定義檔,在編寫程式時直接提出警告等等,其實現在想的到的這些功能微軟的 Visuall Studio 應該都有了,不過有個公定格式做中介還是比較方便第三方應用,雖然目前好像只有看到 TernJS 的第三方應用,有些可惜,而且微軟的 Compiler 常常偷改,TernJS 提供的 from_ts 是需要使用到一些 compiler 內部的 function 才能用的,而從我接觸 TernJS 以來,微軟至少已經改過兩次改很大造成 from_ts完全不能用的情形。

總之微軟的 TypeScript 我覺得使用人數也不會有什麼大變化,但是定義檔 .d.ts 的部分倒是比較可以期待,變成半個 JS 用的標準介面定義文件格式,競爭對手的話應該是 WebIDL 吧,不過 WebIDL 比較不親切,也不太有人去實做和推廣他的應用,ES7 的型別暗示其實是只是針對那五個基本型別為主,沒有像 WebIDL 和 TypeScript 那樣完整。

December 04, 2014 03:06 PM

November 25, 2014

Othree

前端工程師都應該知道的 fetch

之前介紹 ES6 Promise 的時候就有提到一些過去的標準應該也可以更新到來支援 Promise,沒想到就看到 WHATWG 的 fetch 了,fetch 就是個 XMLHttpRequest(XHR)的 替代品,幾乎是集了這幾年前端領域 Pattern 之大成。

首先是命名很簡單,和 XHR 完全不一樣,那個時期的網路標準的命名都很繁雜,尤其像是 XML Schema 的那個時期,聽說是找了些語言學家來一起制訂的,那個時期的東西很多都名稱弄的很冗長,當然不可否認這樣有個好處是比較容易理解東西的源由,像 XHR 看名字就可以知道其實主要目的是為了抓 XML,而那個時期會想要抓 XML 大概就是為了 SOAP 協定的 Web Service 吧,只是真的用來抓 XML 的已經很少了,一直用這個名稱早就已經覺得很奇怪了,至於新的 fetch 顧名思義就是為了抓東西用的,反而和現在 XHR 使用的情境很符合,而且命名很簡單,好記,就像是 jQuery 的 on 取代了 addEventListener 一樣。(PS: 另外有一個叫 sendBeacon 的是只管送出,不管回來的東西的。)

第二個特點是使用了 Options Object,不過 XHR 倒也不是收很多參數,他的設計是先產生物件後才對它操作:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'test.html');
xhr.setRequestHeader('Tester-Name', 'mike');
xhr.setRequestHeader('Tester-Name ', 'peter');
xhr.send();

雖然沒有搞不清楚參數順序的問題,卻也是多了很多步驟才能達成目標,不過其實產生了 XHR 物件但是卻不送出 request 的使用情境我實在想不太到,大概是因此,新的 fetch 才改成像是 jQuery 的 $.ajax 那樣,產生物件時直接就發出 request 了吧。

第三個特點當然就是回傳的是 ES6 Promise 物件,另外也支援 FormData 等等新東西,不過要說能不能完全取代 XHR 呢?目前看起來是不行的,最主要是因為 ES6 Promise 並沒有支援 progress 的機制,而且已經不是 event-based 的物件了,所以沒辦法抓上傳進度之類的資訊。

因為這個 spec 還很新,目前是沒瀏覽器支援,不過 Github 有提供一個 polyfill 了,把基本的功能都做好了(還有缺一些比較少用到的細節),有興趣想開始用的人可以從這邊開始,大概要注意的有兩個,第一個是因為它是用 ES6 Promise,所以還要引入 ES6 Promise polyfill,第二個是回傳資料的處理,雖然 fetch 在發 request 的時候和 jQuery 的設計很像,不過回傳的資料處理方式就差距比較大了。

jQuery 的 ajax 收到 Response Body 時,會自動根據 Header 的 Content-Type 來處理,像是 JSON 會自動用 JSON.parse 把文字轉成 JS 物件,不過 fetch 不會,根據 spec 所說, fetch 算是一個底層的 library,所以這種事情就要自己來了:

fetch("https://pk.example/berlin-calling.json", {mode:"cors"})
  .then(res => {
  if(res.headers.get("content-type") == "application/json") {
    return res.json()
  } else {
    throw new TypeError()
  }
}).then(processJSON)

fetch 需要你自己在程式碼裡面判斷回傳資料的格式是什麼,然後可以用它提供的 method 擷取到相對應格式的資料,像是這個例子中抓的是 JSON 格式的資料,就直接執行 Response 物件的 json 這個 method,當然你也可以不判斷就直接執行 json(),只是無法 parse 時會直接 throw error 出來,又因為在 Promise 串接過程中,後面就會跑到 reject 的 callback function 那邊去,除了 json 外,其他支援的還有 arrayBufferblobformDatatext。這些從 response 物件中讀取 body 資料出來的動作(spec 中稱為 consume)只能操作一次,如果真的很想讀很多次,建議是直接把回傳資料的那個 Promise 儲存起來,還有一個方法是用 clone 複製 Response 物件,不確定那個方法好就是了,這部分這樣設計的原因似乎是為了處理少一點事情,讓效能比較好。

而除了 Response Body 外,其它的回傳資訊像是 Response Header 等,都有新定義的物件來儲存,不過沒有很複雜,設計的很直覺,和送出去的 Options Object 很接近。不過講到 Header 就有一點還是要說一下,其實 HTTP Header 是可以重複送出一樣的 key 的,先不管合不合規範,現實是 HTTP Protocol 的實作都還可以處理這種狀況,以前的 XHR 也可以做出這樣的行為,印象中也有 framework 會這樣用,不過不太確定,總之 fetch 因為 Header 是給 Options Object 中的一個物件,而物件的 key 不能重複,所以不會允許這種行為出現,我個人是覺得這樣其實也比較好啦。

目前這個標準還未廣為人知,但是我是覺得前景非常看好,Spec 寫的也異常詳細,雖然不能把 XHR 的所有功能都取代,不過大部分的 XHR 應用都可以用的上了,也有 Github 提供的 polyfill,應該很容易吸引人進去使用,加上也沒其它的類似候選標準,除了沒有 progress 和回來的資料格式要自己判斷外,應該是沒什麼缺點了,而且判斷資料格式的部分也是可以自己寫點程式碼把他處理掉,所以嚴格一點說的話,問題就剩下沒有 progress 可以看這點了。

November 25, 2014 12:48 PM