如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
加粗樣式
***@TOC
歡迎使用Markdown編輯器
你好！ 這是你第一次使用 Markdown編輯器 所展示的歡迎頁。如果你想學習如何使用Markdown編輯器, 可以仔細閱讀這篇文章，了解一下Markdown的基本語法知識。
新的改變
我們對Markdown編輯器進行了一些功能拓展與語法支持，除了標準的Markdown編輯器功能，我們增加了如下幾點新功能，幫助你用它寫博客：
全新的界面設計 ，將會帶來全新的寫作體驗；
在創(chuàng)作中心設置你喜愛的代碼高亮樣式，Markdown 將代碼片顯示選擇的高亮樣式 進行展示；
增加了 圖片拖拽 功能，你可以將本地的圖片直接拖拽到編輯區(qū)域直接展示；
全新的 KaTeX數(shù)學公式 語法；
增加了支持甘特圖的mermaid語法1 功能；
增加了 多屏幕編輯 Markdown文章功能；
增加了 焦點寫作模式、預覽模式、簡潔寫作模式、左右區(qū)域同步滾輪設置 等功能，功能按鈕位于編輯區(qū)域與預覽區(qū)域中間；
增加了 檢查列表 功能。
功能快捷鍵
撤銷：Ctrl/Command + Z
重做：Ctrl/Command + Y
加粗：Ctrl/Command + B
斜體：Ctrl/Command + I
標題：Ctrl/Command + Shift + H
無序列表：Ctrl/Command + Shift + U
有序列表：Ctrl/Command + Shift + O
檢查列表：Ctrl/Command + Shift + C
插入代碼：Ctrl/Command + Shift + K
插入鏈接：Ctrl/Command + Shift + L
插入圖片：Ctrl/Command + Shift + G
合理的創(chuàng)建標題，有助于目錄的生成
直接輸入1次#，并按下space后，將生成1級標題。
輸入2次#，并按下space后，將生成2級標題。
以此類推，我們支持6級標題。有助于使用TOC語法后生成一個完美的目錄。
如何改變文本的樣式
強調文本 強調文本
加粗文本 加粗文本
標記文本
刪除文本
引用文本
H2O is是液體。
210 運算結果是 1024.
插入鏈接與圖片
鏈接: link.
圖片:
帶尺寸的圖片:
居中的圖片:
居中并且?guī)С叽绲膱D片:
當然，我們?yōu)榱俗層脩舾颖憬?，我們增加了圖片拖拽功能。
如何插入一段漂亮的代碼片
去博客設置頁面，選擇一款你喜歡的代碼片高亮樣式，下面展示同樣高亮的 代碼片.
// An highlighted block
var foo = 'bar';
1
2
生成一個適合你的列表
項目
項目
項目
項目1
項目2
項目3
計劃任務
完成任務
創(chuàng)建一個表格
一個簡單的表格是這么創(chuàng)建的：
項目 Value
電腦 $1600
手機 $12
導管 $1
設定內容居中、居左、居右
使用:---------:居中
使用:----------居左
使用----------:居右
第一列 第二列 第三列
第一列文本居中 第二列文本居右 第三列文本居左
SmartyPants
SmartyPants將ASCII標點字符轉換為“智能”印刷標點HTML實體。例如：
TYPE ASCII HTML
Single backticks 'Isn't this fun?' ‘Isn’t this fun?’
Quotes "Isn't this fun?" “Isn’t this fun?”
Dashes -- is en-dash, --- is em-dash – is en-dash, — is em-dash
創(chuàng)建一個自定義列表
Markdown
Text-to-HTML conversion tool
Authors
John
Luke
如何創(chuàng)建一個注腳
一個具有注腳的文本。2
注釋也是必不可少的
Markdown將文本轉換為 HTML。
KaTeX數(shù)學公式
您可以使用渲染LaTeX數(shù)學表達式 KaTeX:
Gamma公式展示 Γ(n)=(n?1)!?n∈N \Gamma(n) = (n-1)!\quad\foralln\in\mathbb NΓ(n)=(n?1)!?n∈N 是通過歐拉積分
Unexpected text node: ' 'Unexpected text node: ' '
Γ(z)=∫
0
∞
t
z?1
e
?t
dt.
你可以找到更多關于的信息 LaTeX 數(shù)學表達式here.
新的甘特圖功能，豐富你的文章
Mon 06
Mon 13
Mon 20
已完成
進行中
計劃一
計劃二
現(xiàn)有任務
Adding GANTT diagram functionality to mermaid
關于 甘特圖 語法，參考 這兒,
UML 圖表
可以使用UML圖表進行渲染。 Mermaid. 例如下面產(chǎn)生的一個序列圖：:
張三
李四
王五
你好！李四, 最近怎么樣?
你最近怎么樣，王五？
我很好，謝謝!
我很好，謝謝!
李四想了很長時間,文字太長了不適合放在一行.
打量著王五...
很好... 王五, 你怎么樣?
張三
李四
王五
這將產(chǎn)生一個流程圖。:
鏈接
長方形
圓
圓角長方形
菱形
關于 Mermaid 語法，參考 這兒,
FLowchart流程圖
我們依舊會支持flowchart的流程圖：
開始
我的操作
確認？
結束
yes
no
關于 Flowchart流程圖 語法，參考 這兒.
導出與導入
導出
如果你想嘗試使用此編輯器, 你可以在此篇文章任意編輯。當你完成了一篇文章的寫作, 在上方工具欄找到 文章導出 ，生成一個.md文件或者.html文件進行本地保存。
導入
如果你想加載一篇你寫過的.md文件或者.html文件，在上方工具欄可以選擇導入功能進行對應擴展名的文件導入，
繼續(xù)你的創(chuàng)作。
mermaid語法說明 ??
注腳的解釋 ??
藍藍設計( m.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
1. 如何實現(xiàn)一個響應式對象
最近在看 Vue 的源碼，其中最核心基礎的一塊就是 Observer/Watcher/Dep, 簡而言之就是，Vue 是如何攔截數(shù)據(jù)的讀寫， 如果實現(xiàn)對應的監(jiān)聽，并且特定的監(jiān)聽執(zhí)行特定的回調或者渲染邏輯的?？偟目梢圆鸪扇髩K來說。這一塊，主要說的是 Vue 是如何將一個 plain object 給處理成 reactive object 的，也就是，Vue 是如何攔截攔截對象的 get/set 的
我們知道，用 Object.defineProperty 攔截數(shù)據(jù)的 get/set 是 vue 的核心邏輯之一。這里我們先考慮一個最簡單的情況 一個 plain obj 的數(shù)據(jù)，經(jīng)過你的程序之后，使得這個 obj 變成 Reactive Obj (不考慮數(shù)組等因素，只考慮最簡單的基礎數(shù)據(jù)類型，和對象):
如果這個 obj 的某個 key 被 get, 則打印出 get ${key} - ${val} 的信息
如果這個 obj 的某個 key 被 set, 如果監(jiān)測到這個 key 對應的 value 發(fā)生了變化，則打印出 set ${key} - ${val} - ${newVal} 的信息。
對應的簡要代碼如下:
Observer.js
export class Observer {
constructor(obj) {
this.obj = obj;
this.transform(obj);
}
// 將 obj 里的所有層級的 key 都用 defineProperty 重新定義一遍, 使之 reactive
transform(obj) {
const _this = this;
for (let key in obj) {
const value = obj[key];
makeItReactive(obj, key, value);
}
}
}
function makeItReactive(obj, key, val) {
// 如果某個 key 對應的 val 是 object, 則重新迭代該 val, 使之 reactive
if (isObject(val)) {
const childObj = val;
new Observer(childObj);
}
// 如果某個 key 對應的 val 不是 Object, 而是基礎類型，我們則對這個 key 進行 defineProperty 定義
Object.defineProperty(obj, key, {
enumerable: true,
configurable: true,
get: () => {
console.info(`get ${key}-${val}`)
return val;
},
set: (newVal) => {
// 如果 newVal 和 val 相等，則不做任何操作(不執(zhí)行渲染邏輯)
if (newVal === val) {
return;
}
// 如果 newVal 和 val 不相等，且因為 newVal 為 Object, 所以先用 Observer迭代 newVal, 使之 reactive, 再用 newVal 替換掉 val, 再執(zhí)行對應操作(渲染邏輯)
else if (isObject(newVal)) {
console.info(`set ${key} - ${val} - ${newVal} - newVal is Object`);
new Observer(newVal);
val = newVal;
}
// 如果 newVal 和 val 不相等，且因為 newVal 為基礎類型, 所以用 newVal 替換掉 val, 再執(zhí)行對應操作(渲染邏輯)
else if (!isObject(newVal)) {
console.info(`set ${key} - ${val} - ${newVal} - newVal is Basic Value`);
val = newVal;
}
}
})
}
function isObject(data) {
if (typeof data === 'object' && data != 'null') {
return true;
}
return false;
}
index.js
import { Observer } from './source/Observer.js';
// 聲明一個 obj,為 plain Object
const obj = {
a: {
aa: 1
},
b: 2,
}
// 將 obj 整體 reactive 化
new Observer(obj);
// 無輸出
obj.b = 2;
// set b - 2 - 3 - newVal is Basic Value
obj.b = 3;
// set b - 3 - [object Object] - newVal is Object
obj.b = {
bb: 4
}
// get b-[object Object]
obj.b;
// get a-[object Object]
obj.a;
// get aa-1
obj.a.aa
// set aa - 1 - 3 - newVal is Basic Value
obj.a.aa = 3
這樣，我們就完成了 Vue 的第一個核心邏輯， 成功把一個任意層級的 plain object 轉化成 reactive object
2. 如何實現(xiàn)一個 watcher
前面講的是如何將 plain object 轉換成 reactive object. 接下來講一下，如何實現(xiàn)一個watcher.
實現(xiàn)的偽代碼應如下:
偽代碼
// 傳入 data 參數(shù)新建新建一個 vue 對象
const v = new Vue({
data: {
a:1,
b:2,
}
});
// watch data 里面某個 a 節(jié)點的變動了，如果變動，則執(zhí)行 cb
v.$watch('a',function(){
console.info('the value of a has been changed !');
});
// watch data 里面某個 b 節(jié)點的變動了，如果變動，則執(zhí)行 cb
v.$watch('b',function(){
console.info('the value of b has been changed !');
})
Vue.js
// 引入將上面中實現(xiàn)的 Observer
import { Observer } from './Observer.js';
import { Watcher } from './Watcher.js';
export default class Vue {
constructor(options) {
// 在 this 上掛載一個公有變量 $options ,用來暫存所有參數(shù)
this.$options = options
// 聲明一個私有變量 _data ,用來暫存 data
let data = this._data = this.$options.data
// 在 this 上掛載所有 data 里的 key 值， 這些 key 值對應的 get/set 都被代理到 this._data 上對應的同名 key 值
Object.keys(data).forEach(key => this._proxy(key));
// 將 this._data 進行 reactive 化
new Observer(data, this)
}
// 對外暴露 $watch 的公有方法，可以對某個 this._data 里的 key 值創(chuàng)建一個 watcher 實例
$watch(expOrFn, cb) {
// 注意，每一個 watcher 的實例化都依賴于 Vue 的實例化對象, 即 this
new Watcher(this, expOrFn, cb)
}
// 將 this.keyName 的某個 key 值的 get/set 代理到 this._data.keyName 的具體實現(xiàn)
_proxy(key) {
var self = this
Object.defineProperty(self, key, {
configurable: true,
enumerable: true,
get: function proxyGetter() {
return self._data[key]
},
set: function proxySetter(val) {
self._data[key] = val
}
})
}
}
Watch.js
// 引入Dep.js, 是什么我們待會再說
import { Dep } from './Dep.js';
export class Watcher {
constructor(vm, expOrFn, cb) {
this.cb = cb;
this.vm = vm;
this.expOrFn = expOrFn;
// 初始化 watcher 時, vm._data[this.expOrFn] 對應的 val
this.value = this.get();
}
// 用于獲取當前 vm._data 對應的 key = expOrFn 對應的 val 值
get() {
Dep.target = this;
const value = this.vm._data[this.expOrFn];
Dep.target = null;
return value;
}
// 每次 vm._data 里對應的 expOrFn, 即 key 的 setter 被觸發(fā)，都會調用 watcher 里對應的 update方法
update() {
this.run();
}
run() {
// 這個 value 是 key 被 setter 調用之后的 newVal, 然后比較 this.value 和 newVal, 如果不相等，則替換 this.value 為 newVal, 并執(zhí)行傳入的cb.
const value = this.get();
if (value !== this.value) {
this.value = value;
this.cb.call(this.vm);
}
}
}
對于什么是 Dep, 和 Watcher 里的 update() 方法到底是在哪個時候被誰調用的，后面會說
3. 如何收集 watcher 的依賴
前面我們講了 watcher 的大致實現(xiàn)，以及 Vue 代理 data 到 this 上的原理?，F(xiàn)在我們就來梳理一下，Observer/Watcher 之間的關系，來說明它們是如何調用的.
首先, 我們要來理解一下 watcher 實例的概念。實際上 Vue 的 v-model, v-bind , {{ mustache }}, computed, watcher 等等本質上是分別對 data 里的某個 key 節(jié)點聲明了一個 watcher 實例.
<input v-model="abc">
<span>{{ abc }}</span>
<p :data-key="abc"></p>
...
const v = new Vue({
data:{
abc: 111,
}
computed:{
cbd:function(){
return `${this.abc} after computed`;
}
watch:{
abc:function(val){
console.info(`${val} after watch`)
}
}
}
})
這里，Vue 一共聲明了 4 個 watcher 實例來監(jiān)聽abc, 1個 watcher 實例來監(jiān)聽 cbd. 如果 abc 的值被更改，那么 4 個 abc - watcher 的實例會執(zhí)行自身對應的特定回調(比如重新渲染dom,或者是打印信息等等)
不過，Vue 是如何知道，某個 key 對應了多少個 watcher, 而 key 對應的 value 發(fā)生變化后，又是如何通知到這些 watcher 來執(zhí)行對應的不同的回調的呢？
實際上更深層次的邏輯是:
在 Observer階段，會為每個 key 都創(chuàng)建一個 dep 實例。并且，如果該 key 被某個 watcher 實例 get, 把該 watcher 實例加入 dep 實例的隊列里。如果該 key 被 set, 則通知該 key 對應的 dep 實例， 然后 dep 實例會將依次通知隊列里的 watcher 實例, 讓它們去執(zhí)行自身的回調方法
dep 實例是收集該 key 所有 watcher 實例的地方.
watcher 實例用來監(jiān)聽某個 key ，如果該 key 產(chǎn)生變化，便會執(zhí)行 watcher 實例自身的回調
相關代碼如下:
Dep.js
export class Dep {
constructor() {
this.subs = [];
}
// 將 watcher 實例置入隊列
addSub(sub) {
this.subs.push(sub);
}
// 通知隊列里的所有 watcher 實例，告知該 key 的 對應的 val 被改變
notify() {
this.subs.forEach((sub, index, arr) => sub.update());
}
}
// Dep 類的的某個靜態(tài)屬性，用于指向某個特定的 watcher 實例.
Dep.target = null
observer.js
import {Dep} from './dep'
function makeItReactive(obj, key, val) {
var dep = new Dep()
Object.defineProperty(obj, key, {
enumerable: true,
configurable: true,
get: () => {
// 收集依賴！ 如果該 key 被某個 watcher 實例依賴，則將該 watcher 實例置入該 key 對應的 dep 實例里
if(Dep.target){
dep.addSub(Dep.target)
}
return val
},
set: (newVal) => {
if (newVal === val) {
return;
}
else if (isObject(newVal)) {
new Observer(newVal);
val = newVal;
// 通知 dep 實例, 該 key 被 set，讓 dep 實例向所有收集到的該 key 的 watcher 實例發(fā)送通知
dep.notify()
}
else if (!isObject(newVal)) {
val = newVal;
// 通知 dep 實例, 該 key 被 set，讓 dep 實例向所有收集到的該 key 的 watcher 發(fā)送通知
dep.notify()
}
}
})
}
watcher.js
import { Dep } from './Dep.js';
export class Watcher {
constructor(vm, expOrFn, cb) {
this.cb = cb;
this.vm = vm;
this.expOrFn = expOrFn;
this.value = this.get();
}
get() {
// 在實例化某個 watcher 的時候，會將Dep類的靜態(tài)屬性 Dep.target 指向這個 watcher 實例
Dep.target = this;
// 在這一步 this.vm._data[this.expOrFn] 調用了 data 里某個 key 的 getter, 然后 getter 判斷類的靜態(tài)屬性 Dep.target 不為null, 而為 watcher 的實例， 從而把這個 watcher 實例添加到 這個 key 對應的 dep 實例里。 巧妙！
const value = this.vm._data[this.expOrFn];
// 重置類屬性 Dep.target
Dep.target = null;
return value;
}
// 如果 data 里的某個 key 的 setter 被調用，則 key 會通知到 該 key 對應的 dep 實例, 該Dep實例， 該 dep 實例會調用所有 依賴于該 key 的 watcher 實例的 update 方法。
update() {
this.run();
}
run() {
const value = this.get();
if (value !== this.value) {
this.value = value;
// 執(zhí)行 cb 回調
this.cb.call(this.vm);
}
}
}
總結：
至此， Watcher, Observer , Dep 的關系全都梳理完成。而這些也是 Vue 實現(xiàn)的核心邏輯之一。再來簡單總結一下三者的關系，其實是一個簡單的 觀察-訂閱 的設計模式, 簡單來說就是， 觀察者觀察數(shù)據(jù)狀態(tài)變化, 一旦數(shù)據(jù)發(fā)生變化，則會通知對應的訂閱者，讓訂閱者執(zhí)行對應的業(yè)務邏輯 。我們熟知的事件機制，就是一種典型的觀察-訂閱的模式
Observer, 觀察者，用來觀察數(shù)據(jù)源變化.
Dep, 觀察者和訂閱者是典型的 一對多 的關系,所以這里設計了一個依賴中心,來管理某個觀察者和所有這個觀察者對應的訂閱者的關系, 消息調度和依賴管理都靠它。
Watcher, 訂閱者，當某個觀察者觀察到數(shù)據(jù)發(fā)生變化的時候，這個變化經(jīng)過消息調度中心，最終會傳遞到所有該觀察者對應的訂閱者身上，然后這些訂閱者分別執(zhí)行自身的業(yè)務回調即可
參考
Vue源碼解讀-滴滴FED
代碼參考
藍藍設計( m.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
視覺設計師作為展示產(chǎn)品最終形態(tài)的執(zhí)行層，產(chǎn)品上線前走查視覺與交互還原是必經(jīng)環(huán)節(jié)，而留給設計師走查修改的時間其實非常少，有時候為了配合產(chǎn)品上線時間，通常只能犧牲一些細節(jié)，在下一次迭代進行優(yōu)化。為了每一次上線的產(chǎn)品都能夠得到更好地還原，這就需要設計師去了解開發(fā)到底是根據(jù)哪些規(guī)則還原我們的設計稿，以及在每一次制作和交付設計稿的時候，我們應如何設定好每一個細節(jié)的規(guī)則。開發(fā)：這里已經(jīng)完全對齊了。
視覺：看起來還沒完全對齊，我的圖也沒有切錯吧？
開發(fā)：字體大小和間距都是按照視覺稿來的。
視覺：這里間距偏差這么大，為什么不按照視覺稿？
開發(fā)：視覺樣式好多，每個設計師的間距好像都不一樣。
視覺：……
我們經(jīng)常會聽到身邊的設計師與開發(fā)小哥的一些對話，關于對齊、大小、間距等設計還原問題經(jīng)常會討論很久，有時甚至會覺得，幾個像素的間距是不是沒有必要這么糾結。以我較常接觸的云產(chǎn)品官網(wǎng)為例，云產(chǎn)品官網(wǎng)體量龐大，單個頁面或信息模塊的樣式復用可高達上百個子產(chǎn)品頁面，此時第一個模塊設計的規(guī)范性、擴展性、復用性則變得尤為重要，所以為了讓設計方案更加合理，為了讓合作更加，這里總結一些設計經(jīng)驗，與大家一起探討。
本文將從以下三個方面，思考作為視覺設計師，應當如何讓設計更加合理有效：
1. 字體結構
網(wǎng)頁設計中，我們總避免不了與字體打交道，字體也是我們在設計中經(jīng)常容易忽視的部分，而經(jīng)常出錯的原因往往是因為我們對文字的理解不夠清晰。相比西文字體，中文字體結構復雜，字庫龐大，網(wǎng)頁的渲染效果會比西文字體艱難很多。
但無論是中文還是西文，我們經(jīng)常需要用到的無非是字體大小、字重、字色，還有就是經(jīng)常被我們忽視的行高和行寬，我們從西文字體提取三個最主要的因素，即字高、行高、行寬?；谖魑淖煮w的結構轉換為中文，我們可以理解為，字高指的就是我們肉眼所能看到的字體的實際高度，而行高指的是字高+上邊距＋下邊距，反過來說，行高減去字高除以 2 就能得到我們的上下邊距，行寬指的就是整個文本的寬度。
舉一個圖文模塊的例子，圖（1）中我們肉眼所看到間距，在我們做標注時，看到的其實是圖（2）中的三個色塊，我們實際給到開發(fā)的標注，是色塊的尺寸和色塊之間的間距，以及詳細的文本屬性。
2. 文字行寬
關于行寬，以設計 banner 的標題及描述文字為例，定義行寬是為了讓文本在極限寬度的時候進行換行，再固定好配圖的尺寸，從而得到文本與配圖之間的間距，定義行寬、行數(shù)、字數(shù)，能夠更好地為運營人員規(guī)范輸出的文案，避免因字數(shù)過多或過少所造成的視覺不平衡。
當我們處理無序列表時，四個短句文本，長短不一，同樣我們需要限制一行文本寬度，定義一行能承載的最多字數(shù)，以及跟產(chǎn)品確認可能出現(xiàn)的最多字數(shù)的情況，確認模塊設計的可行性，保證后續(xù)運營人員在替換文案的時候不會出錯。
以上兩個例子都是我們設計文字經(jīng)常出錯的地方，正確的定義規(guī)范，無論是交付開發(fā)或者其他下游，都能保證模塊設計的可擴展性及規(guī)范化，保證最終上線質量。
3. 圖標視錯覺
關于圖標，這里提到一個幾何學錯覺的概念，視覺上的大小、長度、面積、方向、角度等幾何構成，和實際上測得的數(shù)字有明顯差別的錯覺，稱為幾何學錯覺。人眼所接受的視覺平衡，往往不是設計軟件上精準的對齊，我們總是會通過調整間距、大小或角度來補齊一些負空間，讓畫面保持視覺平衡。
以客戶案例的卡片樣式為例，客戶案例在 to B 產(chǎn)品中是必不可少的模塊，我們的客戶 logo 有的圓形，有的長方形，有的純文字，尺寸差距比較懸殊，這種情況下我們需要給他限制一個高度，在這個高度以內，再根據(jù) logo 本身的體量來調整圖形的大小，處理好 logo 的視覺平衡，最后紅色區(qū)域是 logo 的實際尺寸，藍色區(qū)域則是我們實際給到開發(fā)的尺寸，從開發(fā)的角度來看其實就是占位符，而規(guī)范的作圖則是把占位符的透明度調整為 0，以占位符為實際有效作圖區(qū)。
UI 設計中通常以「向右箭頭」來表示當前鏈接可跳轉，使用箭頭作圖時，當我們把箭頭和文字右對齊，箭頭其實會更加的往外突出，這時候我們會人為的往里邊推 1 至 2 像素，最后實際給到開發(fā)的也應該是紅框的尺寸，也就是 16×16 的占位圖尺寸。
「按鈕」也是 UI 設計中常用的組件，當我們在按鈕里使用圖標加文字時，由于文字的體量更大，整體重心會往右偏，所以我們通常會認為讓圖標和文字整體往左偏移，使整體的視覺更加平衡，實際給到開發(fā)的，也是兩個不同等的邊距。
1. 理性的設計
在 iOS 和 Android 的設計規(guī)范中，都有提到過使用「8點柵格」的概念，即建議使用 8×8 的網(wǎng)格系統(tǒng)進行設計，我們都知道 0.5px 的渲染在屏幕上會變模糊，之所以使用 8 的倍數(shù)是因為市場上主流的屏幕都能被 8 整除，使用 8 點柵格能夠的讓我們所設計的內容樣式在屏幕上保持高清顯示，而在日常的網(wǎng)頁設計中，我其實更加傾向使用 4 點柵格系統(tǒng)。
我們以下圖 4 組數(shù)列為例，大家可能都曾使用過上面三組藍色數(shù)列中的數(shù)值應用到設計中，或以 5 為倍數(shù)，或以 10 為倍數(shù)、或以偶數(shù)為設計邏輯，而實際上以 5 為倍數(shù)則會包含奇數(shù)，奇數(shù)會導致控件文字對不齊，當 5 的倍數(shù)和偶數(shù)同時使用時，則會出現(xiàn)類似 14、15、16 這種相差為 1 的相鄰數(shù)，這樣會導致我們的尺寸規(guī)范不好定義規(guī)則，難以形成邏輯，而使用 4 的倍數(shù)，他們的公差為 4，不會出現(xiàn)奇數(shù)，也不會出現(xiàn)相鄰數(shù)。
我們再看看一些通用的尺寸定義，例如常見的 icon 設計尺寸都是以 4 為倍數(shù)。
常見的網(wǎng)頁柵格及其所均分的卡片和間距，也都是 4 的倍數(shù)，如果我們的控件尺寸，圖標尺寸和間距都使用 4 的倍數(shù)來定義，那所有的信息模塊自然都能更好的相互適應，層層遞進的邏輯關系也會更加明顯。
我們把 4 點柵格的設計邏輯套用到卡片設計上，第一眼我們可能比較難去評判兩者的好壞，但仔細看，我們就會發(fā)現(xiàn)第一個卡片的按鈕沒有水平對齊，相互之間的間距尺寸也是沒什么邏輯性。假如今天調整一個 8px 的間距，明天調一個 10px 的間距，設計師走查起來也很難發(fā)現(xiàn)有問題，對接的開發(fā)也難以有一個可以參考的規(guī)范標準。而相對的，以 4 為倍數(shù)，我們會發(fā)現(xiàn)所有的信息都會完美對齊，而且倍數(shù)為 4 的每個數(shù)值之間公差為 4，即使設計稿微調了 1px 我們都能很快發(fā)現(xiàn)，開發(fā)在還原設計稿時也會有一個衡量標準。
網(wǎng)格設計在報紙、雜志、海報等平面設計領域中也是十分常見的設計手法，通過建立網(wǎng)格，考究每一個信息模塊在頁面中的擺放位置，大小占比，顏色占比，從而使得頁面信息保持秩序、均衡。
使用 4 點柵格系統(tǒng)，通過理性、秩序、邏輯的設計方式賦予畫面秩序感以及閱讀體驗，而以 4 為倍數(shù)，每個數(shù)字之間都相差為 4，不會太大，也不會太小，同時保持著秩序，讓設計更加理性。對于團隊合作，設計師與開發(fā)也將更有默契，不必再為不清不楚的間距浪費時間。
1. 有效切圖
關于切圖，切圖之前應跟開發(fā)確定好輸出的格式和尺寸，確定應該用 SVG，一倍圖或是兩倍圖。SVG 體量小渲染質量好，單色使用時還能替換顏色，PNG 則通常用在實景圖，一倍圖和二倍圖則根據(jù)實際需要進行輸出。
如果要做分層動畫，那我們就需要分層切圖，如果桌面端和手機端樣式差別較大，那我們需要和開發(fā)溝通好如何實現(xiàn)，是否需要特殊切圖，所有的特殊切圖和特殊樣式，我們都應該提前跟開發(fā)溝通好。
2. 交互細節(jié)
如果某個控件或信息模塊交互樣式較多，那我們可以有一個空白畫板來清晰地標注這些狀態(tài)和樣式，很多開發(fā)在還原過程中都是一手視覺稿一手交互稿，但視覺設計師作為展示產(chǎn)品最終形態(tài)的執(zhí)行層，很多情況下，視覺階段依然會有很多需要跟交互和產(chǎn)品溝通修改的地方，所以為了避免遺漏修改點，視覺稿應該呈現(xiàn)最完整的設計細節(jié)，這樣也會很大程度上節(jié)省開發(fā)的時間，減少出錯的幾率。
當頁面內容有一定的更新頻率，我們則需要標明視覺樣式規(guī)范，以及后續(xù)的運營規(guī)則，完整的收尾，可以避免產(chǎn)品經(jīng)常過來尋求上線素材和規(guī)范。有些需要隔三個月或半年才上線的需求，清晰的標注也能幫助我們快速回憶起需求背景，讓我們在日常工作中保持頭腦清晰，有條不紊，這其實也是在給我們自己節(jié)省時間。
3. 重構稿走查
走查還原的時候，在 Chrome 瀏覽器的空白處右鍵點擊檢查，找到里面的 Computed 窗口，我們可以找到具體的文字、間距、投影等屬性，有時候一些比較細微的調整，我們可以雙擊具體的數(shù)值進行調整，調整到自己滿意之后再把具體的數(shù)值給到開發(fā)，這樣就不用在我們搖擺不定的情況下，造成雙方的困擾。
最后，在預發(fā)布的時候，我們可以利用 SwitchHosts 的客戶端來配置開發(fā)環(huán)境進行體驗，保證最終上線的效果。
藍藍設計( m.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
如何爬去爬去今日頭條動態(tài)數(shù)據(jù)，
網(wǎng)上有很多教程，我就不在啰嗦了
第一步如何分析得到存儲數(shù)據(jù)的真實url
首先打開https://www.toutiao.com/，搜索街拍，會跳轉https://www.toutiao.com/search/?keyword=%E8%A1%97%E6%8B%8D
你如果用傳統(tǒng)的方式你將的得不到任何有價值的信息
這個時候你怎么辦呢？
你這個時候注意查看requests url，
Request URL: https://www.toutiao.com/api/search/content/?aid=24&app_name=web_search&offset=0&format=json&keyword=街拍&autoload=true&count=20&en_qc=1&cur_tab=1&from=search_tab&pd=synthesis×tamp=1559831008973
到這里我們就找到了數(shù)據(jù)春芳的真正url了
你好！ 這是你第一次使用 Markdown編輯器 所展示的歡迎頁。如果你想學習如何使用Markdown編輯器, 可以仔細閱讀這篇文章，了解一下Markdown的基本語法知識。
后面就簡單了，直接上代碼
import os
import re
import json
import requests
from requests import RequestException
from requests import exceptions
from urllib.parse import urlencode
from demo01.util import buid_proxy
‘’’
抓取今日頭條圖片圖片集
因為今天頭條數(shù)據(jù)是動態(tài)，因此第一步是找到存儲圖片的真正url
第二步就是構造瀏覽器（偽瀏覽器），因為現(xiàn)在防爬網(wǎng)站做的很好，他會更具某項標準你是否是機器人，因此這步很重要
‘’’
proxies=buid_proxy()
def get_one_page(offset, keyword):
‘’’
獲取網(wǎng)頁html內容并返回
‘’’
params = {
‘a(chǎn)id’: ‘24’,
‘a(chǎn)pp_name’: ‘web_search’,
‘offset’: offset,
‘format’: ‘json’,
‘keyword’:keyword,
‘a(chǎn)utoload’: ‘true’,
‘count’: ‘20’,
‘cur_tab’: ‘1’,
‘from’: ‘search_tab’,
‘pd’: ‘synthesis’,
‘timestamp’: ‘1559660659001’}
header = {
"User-Agen":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36",
"referer":"https://www.toutiao.com/search/?keyword=%E8%A1%97%E6%8B%8D",
"cookie":"tt_webid=6692573135994799624; UM_distinctid=16ace1c56988c-06f62adc4fd369-7a1437-144000-16ace1c5699a3; csrftoken=368635b7c1d736ff1889c2b70705afa9; tt_webid=6692573135994799624; WEATHER_CITY=%E5%8C%97%E4%BA%AC; s_v_web_id=152a5d87eb7690f9953388e50371f37b; CNZZDATA1259612802=1893030441-1558619693-https%253A%252F%252Flanding.toutiao.com%252F%7C1559662594; _ga=GA1.2.569135354.1559664708; _gid=GA1.2.419995265.1559664708; __tasessionId=wb39ej38m1559741348358",
}
url = 'https://www.toutiao.com/api/search/content/?' + urlencode(params)
#print(url)
try:
# 獲取網(wǎng)頁內容，返回json格式數(shù)據(jù)
response = requests.get(url, headers=header,proxies=proxies)
# 通過狀態(tài)碼判斷是否獲取成功
if response.status_code == 200:
#此處必須這樣寫不然會出現(xiàn)中文亂碼
response=response.content.decode('utf-8')
html=response
return html
return None
except RequestException:
return None
def parse_one_page(html):
‘’’
解析出組圖網(wǎng)址,并將網(wǎng)頁中所有圖集的標題及圖片地址返回
‘’’
urls = []
data = json.loads(html,encoding=‘utf-8’)
if data and ‘data’ in data.keys():
for item in data.get(‘data’):
#print(item)
page_urls = []
title = item.get(‘title’)
#print(title)
image_list = item.get(‘image_list’)
if image_list !=None:
for i in range(len(image_list)):
# 獲取large圖片地址
url = image_list[i][‘url’]
# 替換URL獲取高清原圖
url = url.replace(‘large’, ‘origin’)
page_urls.append(url)
urls.append({‘title’: title,‘url_list’: page_urls})
return urls
def save_image_file(url, path):
‘’’
保存圖像文件
‘’’
ir = requests.get(url)
if ir.status_code == 200:
with open(path, ‘wb’) as f:
f.write(ir.content)
f.close()
def main(offset, word):
html = get_one_page(offset, word)
#print(html)
urls = parse_one_page(html)
print(urls)
#圖像文件夾不存在則創(chuàng)建
root_path = 'E:/test001/photo/TOUTIAO'
if not os.path.exists(root_path):
os.mkdir(root_path)
for i in range(len(urls)):
print('---正在下載 %s'%urls[i]['title'])
folder = root_path + '/' + urls[i]['title']
if not os.path.exists(folder):
try:
os.mkdir(folder)
except NotADirectoryError:
continue
except OSError:
continue
url_list = urls[i]['url_list']
try:
for j in range(len(url_list)):
path = folder + '/index_' + str("%02d"%j) + '.jpg'
if not os.path.exists(path):
save_image_file(urls[i]['url_list'][j], path)
except exceptions.ProxyError:
return None
if name == ‘main’:
main(0,‘街拍’)
新的改變
我們對Markdown編輯器進行了一些功能拓展與語法支持，除了標準的Markdown編輯器功能，我們增加了如下幾點新功能，幫助你用它寫博客：
全新的界面設計 ，將會帶來全新的寫作體驗；
在創(chuàng)作中心設置你喜愛的代碼高亮樣式，Markdown 將代碼片顯示選擇的高亮樣式 進行展示；
增加了 圖片拖拽 功能，你可以將本地的圖片直接拖拽到編輯區(qū)域直接展示；
全新的 KaTeX數(shù)學公式 語法；
增加了支持甘特圖的mermaid語法1 功能；
增加了 多屏幕編輯 Markdown文章功能；
增加了 焦點寫作模式、預覽模式、簡潔寫作模式、左右區(qū)域同步滾輪設置 等功能，功能按鈕位于編輯區(qū)域與預覽區(qū)域中間；
增加了 檢查列表 功能。
功能快捷鍵
撤銷：Ctrl/Command + Z
重做：Ctrl/Command + Y
加粗：Ctrl/Command + B
斜體：Ctrl/Command + I
標題：Ctrl/Command + Shift + H
無序列表：Ctrl/Command + Shift + U
有序列表：Ctrl/Command + Shift + O
檢查列表：Ctrl/Command + Shift + C
插入代碼：Ctrl/Command + Shift + K
插入鏈接：Ctrl/Command + Shift + L
插入圖片：Ctrl/Command + Shift + G
合理的創(chuàng)建標題，有助于目錄的生成
直接輸入1次#，并按下space后，將生成1級標題。
輸入2次#，并按下space后，將生成2級標題。
以此類推，我們支持6級標題。有助于使用TOC語法后生成一個完美的目錄。
如何改變文本的樣式
強調文本 強調文本
加粗文本 加粗文本
標記文本
刪除文本
引用文本
H2O is是液體。
210 運算結果是 1024.
插入鏈接與圖片
鏈接: link.
圖片:
帶尺寸的圖片:
居中的圖片:
居中并且?guī)С叽绲膱D片:
當然，我們?yōu)榱俗層脩舾颖憬荩覀冊黾恿藞D片拖拽功能。
如何插入一段漂亮的代碼片
去博客設置頁面，選擇一款你喜歡的代碼片高亮樣式，下面展示同樣高亮的 代碼片.
// An highlighted block
var foo = 'bar';
1
2
生成一個適合你的列表
項目
項目
項目
項目1
項目2
項目3
計劃任務
完成任務
創(chuàng)建一個表格
一個簡單的表格是這么創(chuàng)建的：
項目 Value
電腦 $1600
手機 $12
導管 $1
設定內容居中、居左、居右
使用:---------:居中
使用:----------居左
使用----------:居右
第一列 第二列 第三列
第一列文本居中 第二列文本居右 第三列文本居左
SmartyPants
SmartyPants將ASCII標點字符轉換為“智能”印刷標點HTML實體。例如：
TYPE ASCII HTML
Single backticks 'Isn't this fun?' ‘Isn’t this fun?’
Quotes "Isn't this fun?" “Isn’t this fun?”
Dashes -- is en-dash, --- is em-dash – is en-dash, — is em-dash
創(chuàng)建一個自定義列表
Markdown
Text-to-HTML conversion tool
Authors
John
Luke
如何創(chuàng)建一個注腳
一個具有注腳的文本。2
注釋也是必不可少的
Markdown將文本轉換為 HTML。
KaTeX數(shù)學公式
您可以使用渲染LaTeX數(shù)學表達式 KaTeX:
Gamma公式展示 Γ(n)=(n?1)!?n∈N \Gamma(n) = (n-1)!\quad\foralln\in\mathbb NΓ(n)=(n?1)!?n∈N 是通過歐拉積分
Unexpected text node: ' 'Unexpected text node: ' '
Γ(z)=∫
0
∞
t
z?1
e
?t
dt.
你可以找到更多關于的信息 LaTeX 數(shù)學表達式here.
新的甘特圖功能，豐富你的文章
Mon 06
Mon 13
Mon 20
已完成
進行中
計劃一
計劃二
現(xiàn)有任務
Adding GANTT diagram functionality to mermaid
關于 甘特圖 語法，參考 這兒,
UML 圖表
可以使用UML圖表進行渲染。 Mermaid. 例如下面產(chǎn)生的一個序列圖：:
張三
李四
王五
你好！李四, 最近怎么樣?
你最近怎么樣，王五？
我很好，謝謝!
我很好，謝謝!
李四想了很長時間,文字太長了不適合放在一行.
打量著王五...
很好... 王五, 你怎么樣?
張三
李四
王五
這將產(chǎn)生一個流程圖。:
鏈接
長方形
圓
圓角長方形
菱形
關于 Mermaid 語法，參考 這兒,
FLowchart流程圖
我們依舊會支持flowchart的流程圖：
開始
我的操作
確認？
結束
yes
no
關于 Flowchart流程圖 語法，參考 這兒.
導出與導入
導出
如果你想嘗試使用此編輯器, 你可以在此篇文章任意編輯。當你完成了一篇文章的寫作, 在上方工具欄找到 文章導出 ，生成一個.md文件或者.html文件進行本地保存。
導入
如果你想加載一篇你寫過的.md文件或者.html文件，在上方工具欄可以選擇導入功能進行對應擴展名的文件導入，
繼續(xù)你的創(chuàng)作。
mermaid語法說明 ??
注腳的解釋 ??
藍藍設計( m.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
WWDC19 可能是最近幾年最令人激動的蘋果開發(fā)者大會了。重回高端專業(yè)領域的 Mac Pro 不僅僅是性能怪獸，在專業(yè)度、設計感甚至細節(jié)的模塊化的設計上，體現(xiàn)出了蘋果這一頂尖大廠應有的底蘊，說實話，考驗民間硬件評測玩家們的資金實力和評測能力的時候到了。在發(fā)布Mac Pro 這一系列產(chǎn)品的環(huán)節(jié)，空耳幾乎完全聽不懂說的是啥，不過可以全程感知到每一個單詞都是牛X的，蘋果官方頁面的介紹現(xiàn)在肯定是最有說服力的，因為最近的評測起碼是要等到今年年底。
屬于 iOS 13 的 Dark Mode 正正好好滿足了所有人的想象，但是和簡單直接的 Android Dark Mode 相比，又多出一絲優(yōu)雅，非常蘋果。擁有 App Store 和一連串新功能的 watchOS 終于成為了一個更加獨立、功能強大的硬件設備了，而 tvOS …… 不是重點。
重點是，在 iOS 和 macOS 之間，硬生生多出了一個 iPadOS，這才是整個發(fā)布會上，最亮眼的星。
屏幕尺寸介于 iPhone 和 Mac 之間的 iPad ，一直沿用著交互機制相對比較簡約的 iOS 。也正是因此，絕大多數(shù)的用戶的重度需求，被電腦尤其是Mac 所分走了，而高頻輕量的需求則被 iPhone 給分走了，iPad 系列產(chǎn)品在很多時候都是作為家庭娛樂設備而存在，你聽到更多關于它的功能應用場景，是看視頻追劇。
Apple Pencil 是這個系列的轉折點。書寫，創(chuàng)作，搭配鍵盤輸入，屏幕尺寸從9.7 一路上探到 12.9，iPad 開始在觸摸為王的時代，開始切入更多的使用場景。在學校里面越來越多的學生開始使用一臺iPad 來作為 All in one 學習/娛樂設備，藝術家和音樂者開始使用 iPad 替代手繪板和合成器，AR和娛樂的結合也越來越緊密，從創(chuàng)作到專業(yè)領域，iPad 成為了越來越多輕應用場景的核心。
吃灰的 iPad 擁有了更多的可能性，而 iOS 的功能限制反倒成為了 iPad 短板，這大概也是 iPadOS 在整個生態(tài)中獨立出來的最重要原因之一吧。
使用單一屏幕作為輸入核心，圍繞觸摸來交互，以原有 iOS 作為開發(fā)核心，深入到更多的細分應用場景，連通 macOS 和 iOS ，iPadOS 的定位看似曖昧，實則在這個多元和高度垂直的時代，幫蘋果趟出了第三條路。
iPadOS 的新布局看起來終于不那么 iPhone了，原有最左一屏的小組件匯集到主屏幕之后，看起來越來越有桌面的意思的。
……專為多點觸摸的顯示屏而設計，通過直觀的手勢實現(xiàn)多任務……它現(xiàn)在被稱為iPadOS。
這是蘋果給 iPadOS 所寫的出道宣言。
比起 iOS 12 時代更強的分屏模式，發(fā)布會現(xiàn)場演示的時候，展示了使用托拽在多個應用之間快托拽內容和元素的操作，多屏互通效率極高。
而多任務不僅僅體現(xiàn)在多個應用之間的互動，同一個應用同樣可以多屏存在——也就是我們常說的多任務。比如打開兩個「提醒事項」應用，在兩個筆記之間，來回編輯內容。點擊Dock 中的特定應用圖標，你就能看到它到底開了多少個頁面。
仔細想想，這是不是和桌面端的系統(tǒng)的邏輯越來越接近了？
想成為了一個獨立的設備，iPad 在用戶輸入端的短板需要補足，而為了解決這一問題，蘋果為 iPadOS 精心定制化了一套組合拳：編輯手勢，輸入提速，外設支持。
快速輸入是 iPad 的短板之一。不借助鍵盤而能快速輸入的方法之一，就是單手快速輸入。蘋果在iPadOS 上使用了一個全局的小鍵盤，使用雙指捏合快速呼出，全局浮動，使用QuichPath 滑動手勢輸入法，減少輸入的難度。這就是使用輸入法和鍵盤輸入提速的方法之一。
長段落或者是其他內容，又要怎么編輯呢？蘋果巧妙地將 Macbook 系列觸控板的三指手勢微調了一下，給遷移過來了：三指捏合是復制，三指散開是粘貼，而三指滑動是撤銷。
而輔助快速編輯手勢的， 是智能選取功能，光標定位比以往更加智能和精準，把編輯輸入的最后一個短板也給補上了。
iPad 的多點觸摸屏幕本就支持大量不同的手勢，功能支持不是難點，難點在于用盡可能少、且認知度足夠高的常見手勢，以的認知負荷，讓用戶更快上手，更舒適地做到各種各樣的事情。
以觸摸為核心的交互，以及的指針的交互，在iPadOS 上交匯了。這種交互模式無疑是實驗性的，但是這也是未來所有的移動端和數(shù)字產(chǎn)品的設計者都要考慮的問題，而iPadOS 就是最重要的試驗田。
當然，外置鍵盤輸入也并不是難事。iPad 本身的配套鍵盤套和第三方藍牙鍵盤，多數(shù)有輸入需求的用戶都已經(jīng)購置了，為此，蘋果給iPadOS 搭配了豐富的快捷鍵，來輔助輸入：
當然，輸入這件事情上，Apple Pencil 也是非常重要的組成部分。蘋果將系統(tǒng)自帶的備忘錄應用進行了重設計，其中很大一部分原因，就是為 Apple Pencil 提供更為強大的繪圖功能：
這樣一來，即使你沒有購買第三方的繪圖工具，同樣可以用它畫出足夠漂亮的插畫作品。除了特定APP中的手寫輸入和繪圖這樣的使用場景之外，Apple Pencil 還作為日常截圖批注的主力，方便日常作筆記：
更好的輸入，最終的目的，始終是為了更好地輸出內容。
iPadOS 的野心很大。作為一塊10英寸上下的屏幕之內的操作系統(tǒng)，它作為內容承載的硬件，是一個很合理的想象，不然也不會有那么多開發(fā)者一直在開發(fā)將iPad 作為外接屏幕的應用，而現(xiàn)在，用戶只需要連上Wifi ，它就能作為 Mac的外接屏幕。
打通了這一個環(huán)節(jié)之后，后面的事情就自然而然了：Apple Pencil 可以在屏幕上畫畫，這樣一來，它很自然而然就成了手繪板。發(fā)布會上，蘋果官方所放出的圖片當中，涵蓋了多數(shù)設計師都在使用的設計軟件，其中不乏 AI、AE、Pr、Sketch、C4D、Zbrush 這些大熱設計工具。
更重要的一點在于，Apple Pencil 原本 20ms 的反應延遲，在這次的更新之后，將會達到9ms，反應速度提升了一倍以上！它已經(jīng)是一個稱職的手繪板了。
有意思的地方在于，并沒有 PS。為什么？答案很簡單啊，iPadOS平臺上的原生 PS 馬上就要來了??！連上Adobe 的創(chuàng)意云，兩個平臺又呼應上了……
畢竟，想要打通細分的應用場景，iPadOS 是需要自身具備強大生產(chǎn)力的，這意味著大量的獨立功能、服務和應用支撐。
想要 iPadOS 能夠獨立完成視覺創(chuàng)造的工作，對于多種字體的支持是肯定需要的。在iPad 上獨立運行 Photoshop 也同樣是需要這樣的功能支撐的，所以，干脆官方提供支持了：
而值得注意的是，作為一個設計公司，蘋果的想象力并不止于此。這次更新的功能當中，有一個非常引人矚目的功能是 SF Symbols。
蘋果將1000多個常見的 iOS 和 macOS 的圖標和蘋果官方的舊金山字體融為一體，這些圖標和符號支持 iOS 13、iPadOS以及的 watchOS 6 和 tvOS 13，而且你還可以在官方的文檔支持之下，自己創(chuàng)造！
具體可以戳這里了解：SF-symbols 使用文檔
完全獨立的 iPadOS 將會需要好好管理本地和云端的文件系統(tǒng)，官方將文件管理器進行了升級，確保它無需借助另外一臺電腦來完成操作。
核心應用沒有問題，和外接內容進入口也要一并升級。功能強大的 TypeC接口能夠直接讀取U盤和存儲卡：
而作為主要的瀏覽器，Safari 瀏覽器也向著桌面端瀏覽器的方向進了優(yōu)化和調整，比如支持下載：
此外，圖片、照片和視頻的本地管理和剪輯功能，也一并進行了升級，這也是為了讓iPad 能夠成為一個更加獨立的產(chǎn)品而存在。
而真正改變游戲玩法的東西，在開發(fā)和設計上。
多年以前，蘋果為了統(tǒng)一全平臺的應用開發(fā)，開發(fā)語言從原本的 Obj-C 遷移到自家的 Swift 語言。隨著移動端應用量的快速增長，移動端的應用數(shù)量其實早已超過 macOS 平臺的開發(fā)數(shù)量和頻度，這種變化也催生了 Project Catalyst。
圖片來自 engatget
這個名為「催化劑」的項目的目標是希望開發(fā)者可以更加便捷地將 iOS 應用遷移到 macOS 上，比如說 Twitter 的開發(fā)者只花了幾天時間，就將現(xiàn)有的 iOS APP 遷移到 macOS 上。緊隨其后，成千上萬的移動端應用將都可以逐步地反哺到 macOS 上。
但是 Project Catalyst 只是權宜之計，真正治根又治本的東西，則是這次的新的UI框架，SwiftUI。SwiftUI 是一個典型的原生應用框架，是蘋果在磨合了上十年的經(jīng)驗之后，所創(chuàng)造出一個的UI開發(fā)框架，開發(fā)者僅僅只需要極少量的代碼和交互式的設計，就能夠調用這一框架。這一改變對于 iOS 平臺的設計和開發(fā)都會有直接的影響。
在現(xiàn)場演示的時候，原本復雜無比的開發(fā)代碼，在換用 SwiftUI 之后僅需幾行代碼聲明就可以搞定：
新的 Xcode 11 當中，開發(fā)者可以使用托拽的方式來增刪組件，而右側的實時預覽則能夠呈現(xiàn)每一點改變。而基于 SwiftUI 的代碼開發(fā)模式，可以快速復用遷移到整個蘋果的產(chǎn)品平臺上，比以往任何時候都要快：
關于SwiftUI 的相關文檔：https://developer.apple.com/documentation/swiftui/
官方教程：https://developer.apple.com/tutorials/swiftui/
在新的 iPadOS 和 iOS13 中，系統(tǒng)的整體速度和性能得到了進一步的提升，解鎖速度提升了30%，啟動速度是以往的2倍，而應用的容量也比以往要小。
對，深色模式也是蘋果這次 iOS 產(chǎn)品更新的最核心特點，甚至整個WWDC19 主題演講環(huán)節(jié)的整體視覺設計也是完全沿用這種沉浸感極強的深色模式視覺來進行構建的。目前蘋果的 HIG 當中 iOS 的章節(jié)中新增了 Dark mode 的章節(jié)，而 iPadOS 相關的系統(tǒng)的設計設計指南還未更新。
「在 iOS 13 及以上的版本當中，用戶可以選擇深色模式為默認的外觀風格。在深色模式下，系統(tǒng)界面、視圖、菜單和控件都會使用較暗的配色方案，并且讓前景元素更加鮮艷，確保突出。用戶可以選擇選擇深色模式作為默認的視覺風格，也可以通過設置，讓它在光線較暗的時候，自動切換過去。需要注意的是，深色模式可以讓人更加專注。在設計的時候，需要在淺色模式和深色模式中都進行測試，因為有些元素和配色在一種模式下可用，在另一種模式下并不一定適用?！?
蘋果目前在設計規(guī)范中所提供的設計要求相對比較簡略，感興趣的同學可以借助翻譯工具看一下：Dark Mode
如果你對于深色模式感興趣，我們還有文章提供給你：
由于目前蘋果官方暫時沒有更多的內容，我們可以把深色模式更多的內容留到今后來聊。
覺得社交網(wǎng)絡帳號登錄不夠安全？Google 和 Facebook 兩大巨頭在發(fā)布會上成了反面案例，蘋果適時地推出了自家的帳號登錄服務。
蘋果將產(chǎn)品和用戶之間的邊界劃分得非常清晰，包括借助 Homekit 為用戶提供基于本地存儲的安全服務，在網(wǎng)上登錄的時候使用經(jīng)過加密的郵箱帳號，等等。
而被蘋果點名的兩家著名科技企業(yè)，Google 和 Facebook 也是在之前的 Google I/O 大會以及F8 大會上，相繼針對隱私策略、安全服務進行了提升。
如果你對于這些大會感興趣可以看看之前的文章：
和每年9月的新品發(fā)布相比，WWDC 的信息量一點都不小。尤其今年還有超贊的 Mac Pro，單開2篇文章都不一定聊得完。但是在我看來，和設計關系最緊密的產(chǎn)品，應該就是 iPadOS了。這個獨特操作系統(tǒng)，巧妙地卡在一個獨特的需求點上，它本身的設計和定位、用戶體驗的考量、服務用戶的思路、牽涉到的功能和服務乃至于它對于設計的影響，都是巨大的。
藍藍設計( m.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
Echarts數(shù)據(jù)化可視圖表
開發(fā)工具與關鍵技術：Visual Studio 2015 使用Echarts圖表
作者：郭海明
撰寫時間：2019年 6月 4日
1
2
3
在創(chuàng)建一個網(wǎng)頁的時候，有一些頁面會有許多數(shù)據(jù)，瀏覽起來枯燥而乏味，而且數(shù)據(jù)之間的對比也不夠明顯。那么有什么方法可以讓這些數(shù)據(jù)的對比明顯起來，使數(shù)據(jù)看起來也沒有那么枯燥呢！答案當然是有的，我們只需要引用Echarts數(shù)據(jù)可視化圖表就可以了。使用Echarts數(shù)據(jù)化圖表不僅可以讓數(shù)據(jù)之間對比明顯，還可以使數(shù)據(jù)更加生動起來，增強用戶瀏覽頁面數(shù)據(jù)的體驗感。
Echarts提供了常規(guī)的折線圖，柱狀圖，餅狀圖，散點圖。還有用于統(tǒng)計的盒型圖，用于地理數(shù)據(jù)可視化的地圖，熱力圖，線圖，用于關系數(shù)據(jù)可視化的關系圖，多維數(shù)據(jù)可視化的平行坐標。還有用戶BI的漏斗圖，儀表盤，并且支持圖與圖之間的混搭。
Echarts圖表使用起來的方法頁很簡單，首先將Echarts插件引用到視圖里面，視圖里面添加顯示Echarts圖表的類。給這個類顯示圖表的空間，并給類ID，用于后面寫好圖表之后將圖表放到這個類里面。
然后在
將學生信息數(shù)據(jù)表格需要用到的數(shù)據(jù)表，進行多表的連接查詢，連接完成之后，
獲取到需要用到的數(shù)據(jù)，封裝到自定義的AchievementInfor的實體類里面。
寫出接收不同階段成績的方法。用于接收每個不同階段的成績.
寫完之后，返回到視圖里面去寫調用Echarts的圖表，這里我們顯示的是折線圖，所以首先在
藍藍設計( m.yvirxh.cn )是一家專注而深入的界面設計公司，為期望卓越的國內外企業(yè)提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網(wǎng)站建設 、平面設計服務。
如果您想訂閱本博客內容，每天自動發(fā)到您的郵箱中， 請點這里
今天我們就來討論一下什么是顧客體驗地圖。
顧客體驗地圖（ Customer Journey Map） 是一張超越時間和空間，從個體的視角得到用戶與企業(yè)、服務、產(chǎn)品之間的關系地圖。它能夠視覺化地描繪用戶在使用服務的整個過程中的流程、需求、痛點。它可以很好地幫助我們梳理和分析常見的場景可能存在的問題。在營銷、服務、產(chǎn)品的場景分析中CJM都能發(fā)揮很大作用。
我們來欣賞一些著名公司做的顧客體驗地圖：
在整個體驗中找到樂高沒？
受害人報案到打官司的體驗流程
這張圖包含了很多便于瀏覽的視覺化信息：
了解完什么是顧客體驗地圖后，我們開始學習如何創(chuàng)建它。顧客體驗地圖的創(chuàng)建需要五步：明確目標、探究、頭腦風暴、繪制地圖、優(yōu)化迭代:
考慮好產(chǎn)品或服務的整體目標，以及期望顧客旅程圖反應出具體目標。在做之前，最好把原有的體驗流程感受一遍。并且與利益相關者溝通，探尋背后真正的動因。可以使用5W1H:
（1）檢視所有相關的用戶研究資料，其中包括定性和定量的調查結果，以便于提供洞察客戶體驗。也可以通過書籍資料做更多的研究。常用的研究方法包括客戶訪談、人種學和情境調查、客戶調查、客戶支持/投訴日志、網(wǎng)絡分析、社交媒體收聽和競爭情報。
（2）移情映射，從各個方面描述一個角色在特定場景中的經(jīng)歷。這個練習幫助我們的團隊加深對顧客體驗的理解，并對顧客所需要的東西做出驚人的洞察力。移情圖也為顧客體驗地圖的繪制提供了物質基礎。我們的目標是獲得一個全面的感覺，在這段經(jīng)歷中扮演那個角色的感覺，特別是關注他們的想法、感覺、視覺、聽覺、說話和行動。
（3）先生成一個客戶觸點清單以及這些觸點出現(xiàn)的場景。然后通過頭腦風暴尋找被遺漏的接觸點或場景。例如，觸點可以是“付賬單”，與觸點相關的場景可以是“在線付費”、“通過郵件付費”或“親自付費”。
為了收集更多的Idea，我們需要組建一個團隊進行頭腦風暴。頭腦風暴的目的是在短時間內產(chǎn)生盡可能多的想法。我們可以選擇品牌屬性或心態(tài)的詞匯。頭腦風暴的時候，圍繞這些詞進行。我建議團隊選擇3-5個詞（例如：可訪問的，社交的，安慰的），然后每個單詞使用2分鐘的時間。每個人都會寫下他們當時所能想到的許多想法。2分鐘后切換到下一個詞，直到所有的詞被用作靈感。
使用親和圖進行整理。親和圖是通過視覺方式組織團隊的思想，凝聚和發(fā)現(xiàn)概念中的的方法。親和圖解有助于我們從一個廣泛的網(wǎng)絡轉移到探索許多可能性，以獲得對這個觀眾的正確解決方案的重點。所有的團隊成員都應該把他們的想法放在墻上的頭腦風暴活動中。有人把這些想法分類并貼上標簽。作為一個群體，開始考慮你可以在哪里組合，提煉，并刪除想法，形成一個凝聚力的未來客戶體驗的愿景。
把所有的東西放在一起：時間線、觸點、頻道、情緒波動，以及為如何改進未來客戶旅程所產(chǎn)生的所有美妙的新想法。顧客體驗地圖有5個關鍵要素：
購買場景下的顧客體驗地圖
另外，這張圖還可以提供一些額外信息：
PM熊叔，微信公眾號：PM熊叔，人人都是產(chǎn)品經(jīng)理專欄作家。教育類產(chǎn)品產(chǎn)品經(jīng)理出身，學過設計，做過開發(fā)，做過運營的產(chǎn)品經(jīng)理。
編輯：藍藍
設計思維是一種解決問題的方法，運用同理心,橫向思考,做原型,講故事,令人信服地澄清洞見。
2004年，斯坦福大學機械工程系的教授戴維·凱利（DavidKelley)創(chuàng)辦了D.School（斯坦福大學哈索普萊特納設計學院），并在D.School教授關于設計方法論的課程，他也是世界最著名的創(chuàng)業(yè)設計與咨詢公司IDEO的創(chuàng)始人。
什么是設計思維？
設計思維需要將人放回故事的中心。要學會將人放在首位，這就是設計思維的核心精神：以人為本的設計，也叫做以用戶為中心的設計（User-Centered Design）。設計思維，就是一套以人為本的解決問題的方法論。解決問題，要從人的需求出發(fā)，多角度地尋求創(chuàng)新解決方案，并創(chuàng)造更多的可能性。
在“設計思維”在被不同的學者提出之后，IDEO是第一家將設計思維應用于商業(yè)問題的解決之中。
D.School將設計思維分成五大步驟：“Empathy同理心思考”、“Define需求定義”、“Ideate創(chuàng)意構思”、“Prototype原型實現(xiàn)”、“Test實際測試”，
接下來，就讓我們了解一下如何實施設計思維的五步驟！
1同理心思考（Empathy）
同理心思考，就是要獲得對你試圖解決的問題的共鳴。簡單來說，就是換位思考。比如你希望改善學校的教室環(huán)境，那么，你就可以像學生一樣，坐在課桌后面上一整天的課?；蛘撸阆Ｍ麑W生們來解決班級紀律的問題，你可以讓一位學生來做一天的老師。這個步驟的目標是深入解讀用戶，收集大量信息。
2需求定義 （Define）
在收集到的調查信息基礎上，我們需要更的定義需求。像“讓學生的成績更好”，這就不是一個的需求定義。而“提升學生在自習時間的專注力”，則是更精準的，入手點明確的需求定義。只有精準定義需求，我們才能開始入手解決問題！
3創(chuàng)意構思（Ideate）
這個步驟可以看做是頭腦風暴的階段。圍繞上一步定義的需求，我們可以跳出局限，打破慣性思維，天馬行空的提出各種各樣的點子。不要一定要想到好點子，而是要在一百個點子里選出最好的。
4原型實現(xiàn)（Prototype）
這個步驟是要做出可以是粗糙、簡單的產(chǎn)品或產(chǎn)品中的特定功能的原始模型，用于測試上一階段提出的解決方案。原型可以是一個具體的產(chǎn)品的模型，也可以是一個小規(guī)模的環(huán)境或過程的簡單模擬。
5實際測試 （Test）
這個階段，我們會使用實現(xiàn)的產(chǎn)品原型，或模擬環(huán)境來嚴格測試問題是否得到解決，需求是否得到滿足。這個階段非常重要，一些想法可能會在這個過程中被重新定義，甚至，發(fā)現(xiàn)新的問題。
以上，就是實施設計思維的五大步驟。
第6步：重復以上步驟進行迭代
反饋——原型——測試——反饋——原型.......
編輯：藍藍
戰(zhàn)略設計中的一部分,是需要對自己和他人開誠布公,讓大家清楚你真正想要從一項創(chuàng)新活動中尋求什么。很多時候,團隊都是在缺乏對于真實的目的和需求認知清楚的基礎上被迫使做一些徹底改造或是重新想象的事情。
需要探素的問題可能包括:
我們想要的解決方案的本質是什么?
破壞性創(chuàng)新還是漸進式創(chuàng)新?我需要很明確這點嗎?
我們是昨天需要還是明天需要？
我是否為我正投入做的挑戰(zhàn)耗費了合適的資源?
破壞性創(chuàng)新是一些新的、之前沒有過的體驗,而漸進式創(chuàng)新是在現(xiàn)有的給人們來的利益點的基礎上做的一些新的、改進式創(chuàng)新。當然，我們每大都在連續(xù)不斷地努力、改善我們提供的產(chǎn)品和服務。無論是哪一種創(chuàng)新変革,在不同的時間范時都有對它的需求。你希望哪種創(chuàng)新變革,以及你能花在上面的時間,都會影響到你如何實現(xiàn)創(chuàng)新。
變化的類型 ：短期、中期、長期
破壞性創(chuàng)新、漸進式創(chuàng)新、持續(xù)改進
舉個例子,假設一個領導者確實想要“盡快”做出破壞性創(chuàng)新,那么關鍵是就把它盡快培育起來并推向市場，與所需要的資源、人力和資金的需求展開一番對話。這個簡單的對話對于構建你的戰(zhàn)略邊界是很重要的。沒有它,你可能會在一些不必要的努力上浪費時間。時機很重要，不要等到太完美。
或許它不是人們想要放在首位的對話,但是從領導力的角度,確實最為重要的,也是會贏得參與挑戰(zhàn)的團隊成員的高度贊賞的。
藍藍設計的小編 http://m.yvirxh.cn
