Home » Posts tagged "design"

在手機上看 Trac 的套件

這邊講的是 Safari 這些瀏覽器看 Trac,而不是講 app...

這次從高雄回來,在高鐵上想說用手機看看 Trac,發現桌機版的界面是會動,但在手機上不太好用,所以找看看有什麼套件可以改善...

回到家後找到 BlueFlatTheme 這套 (需要透過 ThemeEnginePlugin 啟用),標語是「A responsive, flat, blue theme using Bootstrap」,拿官方的 screenshot 可以看出來有特地為了寬度比較窄的情況調整:

裝好後用手機測了一下,還是有不滿意的地方,不過改善不少了,先這樣撐著...

HTTP/2 時代的 API 設計

在「Let’s Stop Building APIs Around a Network Hack」這邊提到了以前為了解決 HTTP/1.1 的問題而發展出來的 workaround,在 2015 年發展出來的 HTTP/2 從底層直接解了不少問題,加上很快被許多瀏覽器支援 (就算不支援 HTTP/2 也只是降到 HTTP/1.1 跑,比較慢而已):

Guess what else was released in May 2015? RFC 7540, otherwise known as HTTP/2. In retrospect this seems highly poetic, as HTTP/2 kinda makes the compound document aspect of JSON-API a little bit pointless, and compound documents to me go hand in hand with what JSON-API is as a standard.

2012 年在 MOPCON 第一屆講的「API Design Optimized for Mobile Platform」剛好就是這個主題:

有種懷念感... XD

iOS 11 的無線網路與藍芽關假的讓 EFF 不爽...

這次 iOS 11 的無線網路與藍芽需要到 Settings (設定) 裡面才能有效關掉的設計,讓 EFF 不爽寫了一篇文章:「iOS 11’s Misleading “Off-ish” Setting for Bluetooth and Wi-Fi is Bad for User Security」。

On an iPhone, users might instinctively swipe up to open Control Center and toggle Wi-Fi and Bluetooth off from the quick settings. Each icon switches from blue to gray, leading a user to reasonably believe they have been turned off—in other words, fully disabled. In iOS 10, that was true. However, in iOS 11, the same setting change no longer actually turns Wi-Fi or Bluetooth “off.”

不過藍芽的洞真的不少,儘量避免吧... +_+

Flat UI 反而造成使用者困擾

在「Flat UI Elements Attract Less Attention and Cause Uncertainty」這邊透過追蹤眼球的技術,發表了研究結果:

Summary: Flat interfaces often use weak signifiers. In an eyetracking experiment comparing different kinds of clickability clues, UIs with weak signifiers required more user effort than strong ones.

其中最明顯的一個例子就是大家被訓練「有底線的文字應該可以按」,這也是最能馬上被想到的問題... 不過這算是 Flat UI 的問題嗎?

The popularity of flat design in digital interfaces has coincided with a scarcity of signifiers. Many modern UIs have ripped out the perceptible cues that users rely on to understand what is clickable.

將 Sketch 輸出成 iOS/Android 的程式碼

Supernova 是前陣子看到的工具,目前是 public beta,將 Sketch 的設計直接轉成 iOS/Android 的程式碼,減少每次手動調整的痛:「Introducing Supernova」。

目前只支援 iOS/Android,但之後有打算要支援 React Native。(參考「Import & Export」這邊的說明)

五月時寫到的「透過 NN (類神經網路) 訓練好的系統,直接把圖片轉成程式碼」這篇是直接從圖片轉成程式碼,也是想做類似的事情。但 Supernova 因為有 Sketch 內的資訊,轉換的準確度會高不少...

InnoDB 的各種枚枚角角

Baron Schwartz 的 blog 上看到「An Outline for a Book on InnoDB」這篇文章,作者因為被 InnoDB 所驚嘆而想要寫一本書探討 InnoDB 的設計:(因為雖然複雜,但試著將這些複雜的東西隱藏起來,不讓使用的人暈頭轉向)

Years ago I pursued my interest in InnoDB’s architecture and design, and became impressed with its sophistication. Another way to say it is that InnoDB is complicated, as are all MVCC databases. However, InnoDB manages to hide the bulk of its complexity entirely from most users.

I decided to at least outline a book on InnoDB. After researching it for a while, it became clear that it would need to be a series of books in multiple volumes, with somewhere between 1000 and 2000 pages total.

作者還沒開始寫,不過 outline 已經先列出來了:

I did not begin writing. Although it is incomplete, outdated, and in some cases wrong, I share the outline here in case anyone is interested. It might be of particular interest to someone who thinks it’s an easy task to write a new database.

這篇文章的重點在這些 outline,即使沒有寫成書,這些 outline 也讓你知道要可以朝什麼方向研究...

因颱風延期的「COSCUP 2015 Hands-on【妙生活】MySQL 入門」剛好可以 review 這邊的 outline 來修正一些主題。

Google 移除「安全問題」...

總算有大頭把這個不安全的「安全問題」移除掉了:「Google Drops Support for Security Questions」。

引用自原文說明:

Security questions weren't a great way to protect an account since many answers could be guessed or found using a Google search.

目前提供的機制是手機號碼,以及透過其他的 e-mail address 認證。

英國政府所建議的「數位服務設計原則」

在 Hacker News 的摘要上看到的,對於政府提供數位服務,英國政府嘗試訂出設計原則 (雖然目前這份文件還是 alpha 版本):「Government Digital Service Design Principles」。

這份原則是延伸自原來的七大守則:

其中有幾點相當棒:

  • 第二條的「Do less」,如果有人已經做了類似的事情,就直接連出去,不要做重複的事情 (If someone else is doing it — link to it),政府只需要提供其他人無法提供的資訊 (We should concentrate on the irreducible core)。如果能夠提供 API 之類的介面幫助其他服務做的更好,就提供出去讓其他人再利用 (If we can provide resources (like APIs) that will help other people build things — do that.)。
  • 第四條的「Do the hard work to make it simple」直接提到,使用者會用政府的服務是因為沒有替代方案:如果不努力讓服務簡單易用,就是在浪費使用者的時間。(With great power comes great responsibility — very often people have no choice but to use our services. If we don’t work hard to make them simple and usable we’re abusing that power, and wasting people’s time.)
  • 第五條的「Iterate. Then iterate again.」,考慮風險,如果一次到位的風險太高,邊打邊跑推出服務:從 alpha 階段進入 beta 階段,再從 beta 階段趨近於成熟,每個階段去看實際的反應,而不是一開始就畫一張大餅猜測使用者需要什麼。
  • 第八條的「Build digital services, not websites」與第十條的「Make things open: it makes things better」,標題就說明得很清楚了。

即使是一般商業產品的設計也是通用的原則...

Archives