Tag: design

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 認證。

如何設計好的 API

一樣是在 Zite 上看到在分享要如何設計 API 的文章與影片：「Parse Developer Day Video Series: How to Design Great APIs」。

算是觀念性的分享，很多觀念很有趣... 而不可避免的，講到 naming 的時候，PHP 又被拿出來婊... (沒辦法，這個程式語言的 naming 實在太經典 XD)

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

在 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」，標題就說明得很清楚了。

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

產生任意大小的貓圖片...

{placekitten} 這個站提供 API 產生圖片，讓你在規劃版面的時候會比較方便：

Like this: http://placekitten.com/200/300
or: http://placekitten.com/g/200/300

像是這樣：


測了幾次，那個 g 應該是指灰階？記得之前有個站是產生純數字的 block image，有誰記得嗎？