本文從零開始,逐步講解如何用react全家桶搭建一個完整的react項目。文中針對react、webpack、babel、react-route、redux、redux-saga的核心配置會加以講解,通過這個項目,可以系統的了解react技術棧的主要知識,避免搭建一次后面就忘記的情況。
代碼庫:https://github.com/teapot-py/react-demo
首先關于主要的npm包版本列一下:
思考一下webpack到底做了什么事情?其實簡單來說,就是從入口文件開始,不斷尋找依賴,同時為了解析各種不同的文件加載相應的loader,最后生成我們希望的類型的目標文件。
這個過程就像是在一個迷宮里尋寶,我們從入口進入,同時我們也會不斷的接收到下一處寶藏的提示信息,我們對信息進行解碼,而解碼的時候可能需要一些工具,比如說鑰匙,而loader就像是這樣的鑰匙,然后得到我們可以識別的內容。
回到我們的項目,首先進行項目的初始化,分別執行如下命令
mkdir react-demo // 新建項目文件夾
cd react-demo // cd到項目目錄下
npm init // npm初始化
引入webpack
npm i webpack --save
touch webpack.config.js
對webpack進行簡單配置,更新webpack.config.js
const path = require('path');
module.exports = {
entry: './app.js', // 入口文件
output: {
path: path.resolve(__dirname, 'dist'), // 定義輸出目錄
filename: 'my-first-webpack.bundle.js' // 定義輸出文件名稱
}
};
更新package.json文件,在scripts中添加webpack執行命令
"scripts": {
"dev": "./node_modules/.bin/webpack --config webpack.config.js"
}
如果有報錯請按提示安裝webpack-cli
npm i webpack-cli
執行webpack
npm run dev
如果在項目文件夾下生成了dist文件,說明我們的配置是沒有問題的。
安裝react相關包
npm install react react-dom --save
更新app.js入口文件
import React from 'react
import ReactDom from 'react-dom';
import App from './src/views/App';
ReactDom.render(<App />, document.getElementById('root'));
創建目錄 src/views/App,在App目錄下,新建index.js文件作為App組件,index.js文件內容如下:
import React from 'react';
class App extends React.Component {
constructor(props) {
super(props);
}
render() {
return (<div>App Container</div>);
}
}
export default App;
在根目錄下創建模板文件index.html
<!DOCTYPE html>
<html>
<head>
<title>index</title>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no">
</head>
<body>
<div id="root"></div>
</body>
</html>
到了這一步其實關于react的引入就OK了,不過目前還有很多問題沒有解決
Babel是一個工具鏈,主要用于在舊的瀏覽器或環境中將ECMAScript2015+的代碼轉換為向后兼容版本的JavaScript代碼。
安裝babel-loader,@babel/core,@babel/preset-env,@babel/preset-react
npm i babel-loader@8 @babel/core @babel/preset-env @babel/preset-react -D
更新webpack.config.js
module: {
rules: [
{
test: /\.js$/, // 匹配.js文件
exclude: /node_modules/,
use: {
loader: 'babel-loader'
}
}
]
}
根目錄下創建并配置.babelrc文件
{
"presets": ["@babel/preset-env", "@babel/preset-react"]
}
配置HtmlWebPackPlugin
這個插件最主要的作用是將js代碼通過
npm i html-webpack-plugin -D
webpack新增HtmlWebPackPlugin配置
至此,我們看一下webpack.config.js文件的完整結構
const path = require('path');
const HtmlWebPackPlugin = require('html-webpack-plugin');
module.exports = {
entry: './app.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: 'my-first-webpack.bundle.js'
},
mode: 'development',
module: {
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
use: {
loader: 'babel-loader'
}
}
]
},
plugins: [
new HtmlWebPackPlugin({
template: './index.html',
filename: path.resolve(__dirname, 'dist/index.html')
})
]
};
執行 npm run start,生成 dist文件夾
當前目錄結構如下
可以看到在dist文件加下生成了index.html文件,我們在瀏覽器中打開文件即可看到App組件內容。
webpack-dev-server可以極大的提高我們的開發效率,通過監聽文件變化,自動更新頁面
安裝 webpack-dev-server 作為 dev 依賴項
npm i webpack-dev-server -D
更新package.json的啟動腳本
“dev": "webpack-dev-server --config webpack.config.js --open"
webpack.config.js新增devServer配置
devServer: {
hot: true, // 熱替換
contentBase: path.join(__dirname, 'dist'), // server文件的根目錄
compress: true, // 開啟gzip
port: 8080, // 端口
},
plugins: [
new webpack.HotModuleReplacementPlugin(), // HMR允許在運行時更新各種模塊,而無需進行完全刷新
new HtmlWebPackPlugin({
template: './index.html',
filename: path.resolve(__dirname, 'dist/index.html')
})
]
redux是用于前端數據管理的包,避免因項目過大前端數據無法管理的問題,同時通過單項數據流管理前端的數據狀態。
創建多個目錄
下面我們來通過redux實現一個計數器的功能
安裝依賴
npm i redux react-redux -D
在actions文件夾下創建index.js文件
export const increment = () => {
return {
type: 'INCREMENT',
};
};
在reducers文件夾下創建index.js文件
const initialState = {
number: 0
};
const incrementReducer = (state = initialState, action) => {
switch(action.type) {
case 'INCREMENT': {
state.number += 1
return { ...state }
break
};
default: return state;
}
};
export default incrementReducer;
更新store.js
import { createStore } from 'redux';
import incrementReducer from './reducers/index';
const store = createStore(incrementReducer);
export default store;
更新入口文件app.js
import App from './src/views/App';
import ReactDom from 'react-dom';
import React from 'react';
import store from './src/store';
import { Provider } from 'react-redux';
ReactDom.render(
<Provider store={store}>
<App />
</Provider>
, document.getElementById('root'));
更新App組件
import React from 'react';
import { connect } from 'react-redux';
import { increment } from '../../actions/index';
class App extends React.Component {
constructor(props) {
super(props);
}
onClick() {
this.props.dispatch(increment())
}
render() {
return (
<div>
<div>current number: {this.props.number} <button onClick={()=>this.onClick()}>點擊+1</button></div>
</div>
);
}
}
export default connect(
state => ({
number: state.number
})
)(App);
點擊旁邊的數字會不斷地+1
redux-saga通過監聽action來執行有副作用的task,以保持action的簡潔性。引入了sagas的機制和generator的特性,讓redux-saga非常方便地處理復雜異步問題。
redux-saga的原理其實說起來也很簡單,通過劫持異步action,在redux-saga中進行異步操作,異步結束后將結果傳給另外的action。
下面就接著我們計數器的例子,來實現一個異步的+1操作。
安裝依賴包
npm i redux-saga -D
新建src/sagas/index.js文件
import { delay } from 'redux-saga'
import { put, takeEvery } from 'redux-saga/effects'
export function* incrementAsync() {
yield delay(2000)
yield put({ type: 'INCREMENT' })
}
export function* watchIncrementAsync() {
yield takeEvery('INCREMENT_ASYNC', incrementAsync)
}
解釋下所做的事情,將watchIncrementAsync理解為一個saga,在這個saga中監聽了名為INCREMENT_ASYNC的action,當INCREMENT_ASYNC被dispatch時,會調用incrementAsync方法,在該方法中做了異步操作,然后將結果傳給名為INCREMENT的action進而更新store。
更新store.js
在store中加入redux-saga中間件
import { createStore, applyMiddleware } from 'redux';
import incrementReducer from './reducers/index';
import createSagaMiddleware from 'redux-saga'
import { watchIncrementAsync } from './sagas/index'
const sagaMiddleware = createSagaMiddleware()
const store = createStore(incrementReducer, applyMiddleware(sagaMiddleware));
sagaMiddleware.run(watchIncrementAsync)
export default store;
更新App組件
在頁面中新增異步提交按鈕,觀察異步結果
import React from 'react';
import { connect } from 'react-redux';
import { increment } from '../../actions/index';
class App extends React.Component {
constructor(props) {
super(props);
}
onClick() {
this.props.dispatch(increment())
}
onClick2() {
this.props.dispatch({ type: 'INCREMENT_ASYNC' })
}
render() {
return (
<div>
<div>current number: {this.props.number} <button onClick={()=>this.onClick()}>點擊+1</button></div>
<div>current number: {this.props.number} <button onClick={()=>this.onClick2()}>點擊2秒后+1</button></div>
</div>
);
}
}
export default connect(
state => ({
number: state.number
})
)(App);
觀察結果我們會發現如下報錯:
這是因為在redux-saga中用到了Generator函數,以我們目前的babel配置來說并不支持解析generator,需要安裝@babel/plugin-transform-runtime
npm install --save-dev @babel/plugin-transform-runtime
這里關于babel-polyfill、和transfor-runtime做進一步解釋
Babel默認只轉換新的JavaScript語法,而不轉換新的API。例如,Iterator、Generator、Set、Maps、Proxy、Reflect、Symbol、Promise等全局對象,以及一些定義在全局對象上的方法(比如Object.assign)都不會轉譯。如果想使用這些新的對象和方法,必須使用 babel-polyfill,為當前環境提供一個墊片。
Babel轉譯后的代碼要實現源代碼同樣的功能需要借助一些幫助函數,而這些幫助函數可能會重復出現在一些模塊里,導致編譯后的代碼體積變大。
Babel 為了解決這個問題,提供了單獨的包babel-runtime供編譯模塊復用工具函數。
在沒有使用babel-runtime之前,庫和工具包一般不會直接引入 polyfill。否則像Promise這樣的全局對象會污染全局命名空間,這就要求庫的使用者自己提供 polyfill。這些 polyfill一般在庫和工具的使用說明中會提到,比如很多庫都會有要求提供 es5的polyfill。
在使用babel-runtime后,庫和工具只要在 package.json中增加依賴babel-runtime,交給babel-runtime去引入 polyfill 就行了;
詳細解釋可以參考
Babel插件一般盡可能拆成小的力度,開發者可以按需引進。比如對ES6轉ES5的功能,Babel官方拆成了20+個插件。
這樣的好處顯而易見,既提高了性能,也提高了擴展性。比如開發者想要體驗ES6的箭頭函數特性,那他只需要引入transform-es2015-arrow-functions插件就可以,而不是加載ES6全家桶。
但很多時候,逐個插件引入的效率比較低下。比如在項目開發中,開發者想要將所有ES6的代碼轉成ES5,插件逐個引入的方式令人抓狂,不單費力,而且容易出錯。
這個時候,可以采用Babel Preset。
可以簡單的把Babel Preset視為Babel Plugin的集合。比如babel-preset-es2015就包含了所有跟ES6轉換有關的插件。
{
"presets": ["@babel/preset-env", "@babel/preset-react"],
"plugins": [
[
"@babel/plugin-transform-runtime",
{
"corejs": false,
"helpers": true,
"regenerator": true,
"useESModules": false
}
]
]
}
點擊按鈕會在2秒后執行+1操作。
在web應用開發中,路由系統是不可或缺的一部分。在瀏覽器當前的URL發生變化時,路由系統會做出一些響應,用來保證用戶界面與URL的同步。隨著單頁應用時代的到來,為之服務的前端路由系統也相繼出現了。而react-route則是與react相匹配的前端路由。
引入react-router-dom
npm install --save react-router-dom -D
更新app.js入口文件增加路由匹配規則
import App from './src/views/App';
import ReactDom from 'react-dom';
import React from 'react';
import store from './src/store';
import { Provider } from 'react-redux';
import { BrowserRouter as Router, Route, Switch } from "react-router-dom";
const About = () => <h2>頁面一</h2>;
const Users = () => <h2>頁面二</h2>;
ReactDom.render(
<Provider store={store}>
<Router>
<Switch>
<Route path="/" exact component={App} />
<Route path="/about/" component={About} />
<Route path="/users/" component={Users} />
</Switch>
</Router>
</Provider>
, document.getElementById('root'));
更新App組件,展示路由效果
import React from 'react';
import { connect } from 'react-redux';
import { increment } from '../../actions/index';
import { Link } from "react-router-dom";
class App extends React.Component {
constructor(props) {
super(props);
}
onClick() {
this.props.dispatch(increment())
}
onClick2() {
this.props.dispatch({ type: 'INCREMENT_ASYNC' })
}
render() {
return (
<div>
<div>react-router 測試</div>
<nav>
<ul>
<li>
<Link to="/about/">頁面一</Link>
</li>
<li>
<Link to="/users/">頁面二</Link>
</li>
</ul>
</nav>
<br/>
<div>redux & redux-saga測試</div>
<div>current number: {this.props.number} <button onClick={()=>this.onClick()}>點擊+1</button></div>
<div>current number: {this.props.number} <button onClick={()=>this.onClick2()}>點擊2秒后+1</button></div>
</div>
);
}
}
export default connect(
state => ({
number: state.number
})
)(App);
點擊列表可以跳轉相關路由
至此,我們已經一步步的,完成了一個簡單但是功能齊全的react項目的搭建,下面回顧一下我們做的工作
麻雀雖小,五臟俱全,希望通過最簡單的代碼快速的理解react工具鏈。其實這個小項目中還是很多不完善的地方,比如說樣式的解析、Eslint檢查、生產環境配置,雖然這幾項是一個完整項目不可缺少的部分,但是就demo項目來說,對我們理解react工具鏈可能會有些干擾,所以就不在項目中加了。
后面會新建一個分支,把這些完整的功能都加上,同時也會對當前的目錄結構進行優化。
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
部分借鑒自:csdn 作者:鄭清
原文鏈接:
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
在與客戶的溝通中,聆聽了許多建議,學習到了很多知識,也收到過贊美與批評,在經過千錘百煉過后 總結了一點點經驗
首先:
框架選擇
網站css框架選擇(簡潔,節約成本,快速開發)
對于一些簡單靜態網站,展示類網站項目,達到快速開發建站,而又節約成本人力的情況下 選擇一些用于css庫的框架最為合適,
1.Bootstrap
Bootstrap 是最受歡迎的 HTML、CSS 和 JS 框架,用于開發響應式布局、移動設備優先的 WEB 項目。
預處理工具 雖然可以直接使用 Bootstrap 提供的 CSS 樣式表,但是不要忘記,Bootstrap 的源碼是采用最流行的 CSS 預處理工具
一個框架、多種設備。 你的網站和應用能在 Bootstrap 的幫助下通過同一份源碼快速、有效地適配手機、平板和 PC 設備,這一切都是 CSS 媒體 查詢(Media Query)的功勞。
功能完備 Bootstrap 提供了全面、美觀的文檔,你能在這里找到關于普通 HTML 元素、HTML 和 CSS 組件以及 jQuery 插件方面的所有詳細文檔。
Bootstrap 是最受歡迎的 CSS 框架,被認為是擁有最好的響應性的CSS框架。專為前端開發而設計,有助于構建web設計理念、移動優先項目、網格系統、排版和按鈕等。
2.layui
開源模塊化前端 UI 框架
開源模塊化前端 UI 框架
由職業前端傾情打造,面向全層次的前后端開發者,易上手開箱即用的 Web UI 組件庫
Layui 是一款采用自身模塊規范編寫的情懷型前端UI框架,遵循原生HTML/CSS/JS的書寫與組織形式,門檻極低,拿來即用。其外在極簡,卻又不失飽滿的內在,體積輕盈,組件豐盈,從核心代碼到API的每一處細節都經過精心雕琢,非常適合界面的快速開發。
3.Semantic-UI
Semantic 是一個開發框架,可以使用人性化的 HTML 幫助創建漂亮的響應式布局。Semantic UI 旨在使網站構建過程更加語義化。核心特征是利用自然語言原理使代碼更易于閱讀,更容易理解。
4.Pure
Pure 非常輕量級,經過壓縮后不過 3.8KB。這是一個特別為移動端考慮的框架,為了壓縮大小,每一行代碼都經過仔細考量。當然如果你不使用框架給出的全部模塊,體量還可以更小。
5.Skeleton
Skeleton 如其名字,非常小巧,設計簡約,麻雀雖小五臟俱全。網格系統,文本,表單,按鈕,列表,表格,媒體查詢等功能面面俱到。非常適合快速創建簡約網站的需求。
快速搭建
為客戶節省時間成本, 并滿足客戶快速建站的需求,開發過程中 使用到css模塊化,html也應簡潔實用。
在我們最初學習寫頁面的時候,大家都學過怎么去寫 css,也就以下幾種情況:
我們在不斷摸索中,逐漸形成了以編寫內嵌樣式和外部樣式為主要的編寫習慣。
讀到這里大家肯定有所疑問,為什么不建議使用行內樣式?
使用行內樣式的缺點
然后我們繼續剖析一下,為什么不建議使用導入樣式?
經測試,在 css 中使用 @import 會有以下兩種情況:
1、在 IE6-8 下,@import 聲明指向的樣式表并不會與頁面其他資源并發加載,而是等頁面所有資源加載完成后才開始下載。
2、如果在 link 標簽中去 @import 其他 css,頁面會等到所有資源加載完成后,才開始解析 link 標簽中 @import 的 css。
使用導入樣式的缺點 - 導入樣式,只能放在 style 標簽的第一行,放其他行則會無效。 - @import 聲明的樣式表不能充分利用瀏覽器并發請求資源的行為,其加載行為往往會延后觸發或被其他資源加載掛起。 - 由于 @import 樣式表的延后加載,可能會導致頁面樣式閃爍。
隨著時間的不斷發展,我們逐漸發現,編寫源生的 css 其實并不友好,例如:源生的 css 不支持變量,不支持嵌套,不支持父選擇器等等,這些種種問題,催生出了像 sass/less 這樣的預處理器。
預處理器主要是強化了 css 的語法,彌補了上文說了這些問題,但本質上,打包出來的結果和源生的 css 都是一樣的,只是對開發者友好,寫起來更順滑。
隨著前端工程化的不斷發展,越來越多的工具被前端大佬們開發出來,愿景是把所有的重復性的工作都交給機器去做,在 css 領域就產生了 postcss。
postcss 可以稱作為 css 界的 babel,它的實現原理是通過 ast 去分析我們的 css 代碼,然后將分析的結果進行處理,從而衍生出了許多種處理 css 的使用場景。
常用的 postcss 使用場景有:
隨著 react、vue 等基于模塊化的框架的普及使用,我們編寫源生 css 的機會也越來越少。我們常常將頁面拆分成許多個小組件,然后像搭積木一樣將多個小組件組成最終呈現的頁面。
但是我們知道,css 是根據類名去匹配元素的,如果有兩個組件使用了一個相同的類名,后者就會把前者的樣式給覆蓋掉,看來解決樣式命名的沖突是個大問題。
為了解決這個問題,產生出了 CSS 模塊化的概念。
你如果遇到如上問題,那么就很有必要使用 css 模塊化。
BEM 的意思就是塊(block)、元素(element)、修飾符(modifier)。是由 Yandex 團隊提出的一種前端命名方法論。這種巧妙的命名方法讓你的 css 類對其他開發者來說更加透明而且更有意義。
BEM 的命名規范如下:
/* 塊即是通常所說的 Web 應用開發中的組件或模塊。每個塊在邏輯上和功能上都是相互獨立的。 */ .block { } /* 元素是塊中的組成部分。元素不能離開塊來使用。BEM 不推薦在元素中嵌套其他元素。 */ .block__element { } /* 修飾符用來定義塊或元素的外觀和行為。同樣的塊在應用不同的修飾符之后,會有不同的外觀 */ .block--modifier { }
通過 bem 的命名方式,可以讓我們的 css 代碼層次結構清晰,通過嚴格的命名也可以解決命名沖突的問題,但也不能完全避免,畢竟只是一個命名約束,不按規范寫照樣能運行。
CSS Modules 指的是我們像 import js 一樣去引入我們的 css 代碼,代碼中的每一個類名都是引入對象的一個屬性,通過這種方式,即可在使用時明確指定所引用的 css 樣式。
并且 CSS Modules 在打包的時候會自動將類名轉換成 hash 值,完全杜絕 css 類名沖突的問題。
使用方式如下:
1、定義 css 文件。
.className { color: green; } /* 編寫全局樣式 */ :global(.className) { color: red; } /* 樣式復用 */ .otherClassName { composes: className; color: yellow; } .otherClassName { composes: className from "./style.css"; }
2、在 js 模塊中導入 css 文件。
import styles from "./style.css"; element.innerHTML = '<div class="' + styles.className + '">';
3、配置 css-loader 打包。
CSS Modules 不能直接使用,而是需要進行打包,一般通過配置 css-loader 中的 modules 屬性即可完成 css modules 的配置。
// webpack.config.js module.exports = { module: { rules: [ { test: /\.css$/, use:{ loader: 'css-loader', options: { modules: { // 自定義 hash 名稱 localIdentName: '[path][name]__[local]--[hash:base64:5]', } } } ] } };
4、最終打包出來的 css 類名就是由一長串 hash 值生成。
._2DHwuiHWMnKTOYG45T0x34 { color: red; } ._10B-buq6_BEOTOl9urIjf8 { background-color: blue; }
CSS in JS,意思就是使用 js 語言寫 css,完全不需要些單獨的 css 文件,所有的 css 代碼全部放在組件內部,以實現 css 的模塊化。
CSS in JS 其實是一種編寫思想,目前已經有超過 40 多種方案的實現,最出名的是 styled-components。
使用方式如下:
import React from "react"; import styled from "styled-components"; // 創建一個帶樣式的 h1 標簽 const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `; // 創建一個帶樣式的 section 標簽 const Wrapper = styled.section` padding: 4em; background: papayawhip; `; // 通過屬性動態定義樣式 const Button = styled.button` background: ${props => (props.primary ? "palevioletred" : "white")}; color: ${props => (props.primary ? "white" : "palevioletred")}; font-size: 1em; margin: 1em; padding: 0.25em 1em; border: 2px solid palevioletred; border-radius: 3px; `; // 樣式復用 const TomatoButton = styled(Button)` color: tomato; border-color: tomato; `; <Wrapper> <Title>Hello World, this is my first styled component!</Title> <Button primary>Primary</Button> </Wrapper>;
可以看到,我們直接在 js 中編寫 css,案例中在定義源生 html 時就創建好了樣式,在使用的時候就可以渲染出帶樣式的組件了。
除此之外,還有其他比較出名的庫:
最后放一張總結好的圖。
下一篇我們講一下主流js框架 與js開發
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
部分借鑒自:知乎 作者:孟思行
原文鏈接:
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
Bootstrap 是最受歡迎的 HTML、CSS 和 JS 框架,用于開發響應式布局、移動設備優先的 WEB 項目。
Bootstrap 是最受歡迎的 HTML、CSS 和 JS 框架,用于開發響應式布局、移動設備優先的 WEB 項目。
Bootstrap 是最受歡迎的 HTML、CSS 和 JS 框架,用于開發響應式布局、移動設備優先的 WEB 項目。
這篇文章很好,提供了一種“以用戶為中心”把自己和項目組成員隨時假定為一個用戶的身份,去思考,提出一系列問題,把這些問題編號,去一一解決,注重用戶體驗,以此為基本框架,嚴格遵守,一旦設立不增加臨時的多余的功能,不把沒有用戶故事的界面元素放在界面上,保證了精簡的內容圍繞確立的框架中,井井有條。這篇文章值得看十遍。
隨著大數據的興起,數據價值的不斷挖掘,圖表作為數據呈現與分析的有效手段,正扮演著越來越重要的角色。我們在進行B端平臺設計時也在思考:如何讓圖表清晰的傳達信息,同時帶來美觀的視覺感受。
為了達到清晰傳達和視覺美觀的目標,我們結合實際項目,進行大量探索及思考,梳理總結了一套適用于B端后臺類產品的圖表設計思路及方法,涵蓋了曲線圖、柱狀圖、餅圖、雷達圖、漏斗圖等各類常用圖表類型。
圖表視覺層級
圖表能夠承載大量數據信息,同時視覺元素較多,如果只是憑借設計師的審美喜好進行視覺設計,沒有整體信息讀取考量,可能會導致重要信息未能凸顯,降低用戶讀取效率。
為清晰傳達信息,進一步提升讀取效率,我們采用元素重要程度與視覺強度相綁定的方法。依據元素重要程度,將圖表元素分為三類,分別為“底層元素”、“中層元素”和“頂層元素”,并依據不同視覺強度分別設計三類元素。底層元素最弱,頂層元素最強。通過這種方法,梳理圖表元素的前后關系,能夠清晰把握元素視覺層次,保證信息傳遞效率。
| 底層元素設計
在各類圖表中,我們把輔助說明數據的軸線、刻度等定義為底層元素。為了減少視覺干擾,最大程度突出主圖形,底層元素全部使用淺灰色進行設計。我們發現,當元素與背景顏色的明度對比在1.2:1時,人眼較難看到元素;當對比度在2.0:1時,視覺強度過強,易吸引用戶注意力。通過元素視覺強度的調研及視覺嘗試,最終確定元素與背景對比度在1.6:1左右,視覺強度偏弱但人眼能夠看清的程度。以保證元素視覺不突兀,只在需要查看時可以被發現。
| 中層元素設計
中層元素的內容包括數據圖形、數據線段等承載主要數據信息的元素,是圖表中表達數據的關鍵元素。與底層元素相比,中層元素采用更低明度與更高飽和度的數據色來表現,使元素從頁面中凸顯出來,保證可讀性。同時在樣式上適當加入漸變、描邊等樣式,豐富視覺層次,帶來美觀的視覺感受。
| 頂層元素設計
我們把頂層元素定義為圖表高亮信息,內容包括懸停樣式、懸停后的詳細數據說明等。在設計上為保證視覺樣式突出,使用深灰色、強調色等強對比度樣式,并輔以動畫、投影等手法保證明顯的視覺強調效果,保證頂層信息最有效的傳達給用戶。
| 最終效果
通過層級梳理,并綁定元素重要程度和視覺強度的方法,設計后圖表主次信息均按重要程度進行對應視覺強度的展示,讓用戶能夠在第一時間接收到最重要的信息,提升信息讀取效率。
圖表排版設計
圖表排版是指各元素在圖表中的尺寸及布局等,對于B端后臺類產品來說,不同排版對用戶使用體驗造成較大影響。如何建立一套合理的規范保證用戶的使用體驗?我們經過大量討論推敲,梳理出一套針對B端后臺類產品的排版規則,力求保證用戶圖表的使用體驗。
| 圖表尺寸
圖表尺寸指圖表整體長寬高。在項目中我們發現不同尺寸的圖表對數據展現效果影響巨大,例如巨量數據的圖表擠在名片大小的區域例顯示,這使得信息讀取的效率大打折扣。為此我們收集并提取出“全貌概覽”、“多角度環視”、“詳情分析”三類典型場景,并制定了“迷你圖”、“中號圖表”、“大號圖表”三類尺寸,針對不同尺寸優化圖表的信息展示密度,以達到高效讀取信息的目的。
“迷你圖”尺寸最小,舍棄了Y軸等不必要信息,利用小面積展示最關鍵的圖表信息,并控制數據密度,保證信息高效讀取。
“中號圖表”尺寸受限,限制坐標軸刻度數量和數據的密度,例如曲線圖數據點不高于每4像素1個數據點,Y軸坐標刻度不超過5個,以確保信息密度不過載,這類圖表尺寸通常用在針對某大類內容進行多方面檢視時。
“大號圖表”尺寸最大,不限制數據信息密度,給予最全最詳細的展示,這類尺寸通常用在數據詳情頁等詳細分析場景中。
最后考慮到多圖表混合排列時,餅圖、地圖等大面積填色圖表,相較折線圖等描邊型圖表,視覺感受更加膨脹。我們縮小了填色類圖表的實際高度,保證多種圖表混合排列時,視覺感受的均衡。
| 坐標軸
坐標軸在圖表中出現的頻率較高,那么坐標軸常見的設計問題有哪些呢?
第一是橫縱坐標軸的刻度出現過密情況。
如果坐標軸所承載的是連續數據(連續數據指可量化的,連續不斷的,在區間內可任意取值的數據,如時間、金額、人數等),設計師可自行增減刻度數量以保證視覺舒適度。如果承載是離散數據(離散數據指不可量化的,無關聯的,不可在區間內任意取值的數據,如分類、軟件版本、省份等),可采取增加坐標軸縮放功能以解決.
第二個常見問題是刻度的說明文字過長。
如果是X軸(橫軸)文字過長,除了在可控范圍內減少刻度,還可采取文字傾斜45°~90°的辦法(如文字全部為中文,可用豎排代替傾斜90°),緩解信息過密看不清的情況。
如果是Y軸(縱軸)文字過長,需聯合研發一起調整數據的單位,比如把“元”調整為“百萬元”。
如果不能調整,那就要根據所使用的圖表庫有針對性調整。例如常用的Echarts圖表、D3圖表等開源圖表庫,需要提前預估刻度文字長度并預留出來,否則刻度文字可能會被頁面裁掉而不能完全顯示。如你是用的是AntV等可自適應的圖表庫,則不必提前處理,圖表庫會自動按刻度長度進行整體調整。
| 圖例
圖例作為圖表中不可或缺的部分,在各類圖表庫中位置不盡相同,由于不同圖表樣式差異很大,圖例的位置需整體考慮并適當布局擺放,但在同一產品或頁面內,過于隨意的擺放圖例,會導致頁面統一性較差,同時增加用戶的瀏覽成本。我們團隊所負責的B端商業產品矩陣,作為面向用戶的產品集合,產品間聯系非常緊密。過于靈活隨意的圖例擺放不利于用戶對于圖表的瀏覽。為解決此問題,我們基于業務特點,針對B端商業產品矩陣制定了圖例布局指導原則。
我們以提升屏幕信息密度為目標,分析不同場景的頁面排布,制定了頂部和右側兩種較為寬松的指導原則,供設計師在沒有明確的更優方案時選用。
當圖表是左右兩端對齊的類型,例如折線圖、柱狀圖時,建議將圖例放置在圖表頂部。這樣能結合標題等其他元素進行統一排布,減少占用空間。當圖表本身左右都有空余空間時,例如餅圖,建議將圖例放置于圖表的右側。也能夠節省頁面的空間。
數據色板設計
色板作為常見的數據表達手段,能夠利用不同顏色明確體現分類信息、數值高度、狀態信息等。但目前市面上鮮有專業用途圖表的配色工具。我們經過大量探索嘗試,梳理總結出圖表色彩的兩個關鍵維度:辨識度與統一性。既需要顏色間突出強烈可清晰辨別,又需要顏色整體能形成統一風格,以達到清晰傳遞和美觀的目標。如何平衡辨識度與統一性,是我們遇到的難題。
| 辨識度
辨識度在圖表中有兩方面:顏色與頁面底色的辨識度,各顏色之間的辨識度。對于第一種,我們采用控制顏色的明亮程度來確保色彩辨識度,尤其對于黃色、青色等本身較亮的顏色,降低顏色的明度,確保在淺色背景下顏色可辨識。
對于第二種也就是各顏色之間的辨識度,通過實驗發現單純的顏色色相變化,例如紅色與橙色的區分,人眼不容易分辨。所以采用了色相變化+明度變化的方法,既深紅色與亮橙色,深藍色與亮紫色等,這樣用戶能在第一眼就明確分辨,保證顏色間的辨識度。最終把顏色映射到色彩空間的三維坐標中,運用歐幾里得距離公式測算顏色間的距離長短,來衡量各顏色間色差數值。顏色間距離越遠代表色差越大,利用數據輔助衡量辨識效果。
| 統一性
色彩統一性的作用在于確保圖表整體風格一致,色彩搭配舒適,從而帶來美觀、統一的視覺感受。為達目的,我們首先提煉商業產品設計風格為明亮、強對比,其次把設計風格轉化為色彩數值。經過實驗,把顏色明度限制在50%-70%,把飽和度限制在75%-85%,并在區間內不斷波動。這樣既保證了色彩視覺感受的統一,各顏色間又能夠有清晰的辨識度。
| 顏色量化與工具
量化顏色,將色彩轉化為數值,利用數值來驗證設計師的「感覺」,能夠保證方案合理性,保證設計質量。但通過嘗試,我們常用的色彩模式均不能科學合理的量化顏色。通過查閱大量資料,我們最終決定以小眾的HCL色彩模式來衡量色彩。其中H表示色相、C表示飽和度、L表示明度。HCL區別于傳統的RGB或HSB模式,它能夠將人眼對顏色的感知精確的量化為數值,例如黃色相比藍色明度更高,都能如實的反饋到數值上。也由于此特性,HCL模式在誕生距今不到20年間,已被一些先鋒設計師用于數據可視化的呈現中。
但是HCL作為小眾色彩模式,目前設計軟件鮮有支持,造成了HCL色彩不直觀、不方便調色等的問題。為解決此問題,我們已初步完成智能配色程序,只需輸入品牌色,就能自動生成圖表色版,并在風格上與品牌色匹配,達到整體色彩的統一。我們也將一套調配好的色板及HCL實用小工具附在文末,幫助大家直觀的查看和使用HCL模式顏色。
結語
數據價值就像不為人知的寶藏,隱藏在一條條枯燥晦澀的數據背后。而圖表則是開啟寶藏的鑰匙,是發掘數據價值的強有力武器。通過對圖表的不斷探索優化,我們希望能夠最大化數據的價值。通過圖表,讓數據最直觀的展現;通過圖表,讓其背后的規律浮出水面被人探知;通過圖表,讓B端不再有難懂的數據。
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
文章來源:站酷 作者:百度MEUX
分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
我們常說,現在是體驗至上的時代,用戶對產品的使用不再是單純的需求滿足,更要獲得滿意的體驗。服務設計的發展為我們改善用戶的體驗提供了新的思路,從本質出發,任何產品都是在提供某種服務,服務的質量從根本上決定了用戶的體驗。
什么是服務設計
服務設計一直在我們的生活中,我們無時無刻不在體驗著各式各樣的服務。荷蘭一家專業的服務設計機構31 Volts是這樣描述服務設計的:“如果有兩家緊挨著的咖啡店,出售同樣價格的咖啡時,服務設計是讓你走進其中一家而不是另一家的原因?!边@個描述很生動,同時也說明了服務設計的作用。
其實服務設計的定義還有很多,行業內不同的專家和學者都有自己的理解和解讀,不管定義如何,重要的是服務設計的思維方式,可以幫助我們從全局改善服務體驗。
服務設計的原則及案例說明
2010年在《This is Service Design Thinking》一書中,作者首次提出了5個服務設計基本原則,這些原則之后也被廣泛使用,但隨著服務設計的不斷發展,其中的一些原則也需要重新去審視和思考,因此在2017年作者將其更新修訂為6項。
a.以人為中心(Human-centered)
以人為中心的設計理念在產品設計、交互設計等領域已經得到了廣泛的應用,服務設計當然也沒有例外,以人為中心就是要站在用戶的角度上看待和思考問題,考慮所有被服務影響的人。
在日本,農產品市場存在這樣一個問題,農產品批發商無法及時從種植者處了解農產品的相關狀況、收獲量等信息,因此他們也就無法與要購買農產品的人進行談判,這樣造成的結果可能是糧食的浪費。日本的一家軟件公司NJC(Nippon Jimuki Co. Ltd.)發現了這一問題,他們希望利用自身能力(軟件方面的優勢)去解決這一問題,因此將目標設定為:創建一個可以提供有用數據而又不給農民或農產品批發商帶來負擔的系統。
最終的產出的結果是Fudoloop這個應用程序,通過Fudoloop,批發商可以提前一天從農民那里收到信息,進而協調買家的各種要求。Fudoloop的使用者分為兩種,一種是需要更新農產品信息的農民,一種是從Fudoloop上獲取農產品信息的批發商,Fudoloop分別為兩種用戶進行了設計。
圖片來源:Fudoloop
在設計Fudoloop時存在這樣一個問題,農產品市場中的相關從業人員普遍年齡較大、受教育程度低、軟件使用經驗很少,面對這樣的用戶,顯然通常的軟件設計并不符合他們的需求,因此Fudoloop的界面設計非常簡單且信息突出,從事農產品相關工作的人員可以輕松的使用Fudoloop完成農產品信息的更新,而不會因為學習產生很大的壓力。Fudoloop還在大型農業貿易展覽會邀請了一些行業內的人員和用戶參與到了產品的體驗中,并收集了他們反饋的建議,以改善產品。
圖片來源:IDEO
NJC在設計Fudoloop時充分堅持了以人為中心的原則,考慮到服務涉及的不同用戶,并根據用戶本身的特點和需求進行設計。NJC的CMO佐藤賢一是這樣評價Fudoloop的:“當簡單、以人為本的思想匯聚在一起時,創新就會發生”。
b.協作(Collaborative)
這條原則說的是,不同背景和職能的利益相關者應該參與到服務設計流程中,收集多方訴求,發現不同看待問題的角度,才會更好的解決問題。
在美國舊金山,有一所學校和Revolution Foods這家餐飲公司合作,為學校內的人員提供豐富的、營養的午餐,但是實際來餐廳就餐的人數與預期相差很大,數據顯示,有72%可以承擔起午餐費用的人并沒有來到食堂吃午餐。經過調查發現其中的原因,很多學生等校內人員并不愿意排長隊或者匆忙的吃完午餐,因此他們選擇了去校外享受午餐的時間。
為了改善這種情況,這所學校請來了全球頂尖的設計咨詢公司IDEO,他們與1300多名學生、父母、營養人員、董事會專員、校長、老師和社區團體等利益相關者一起工作,重新去設計了學校的午餐,并且制定了針對三種年齡的就餐體驗的建議,完成了飲食、就餐空間、新技術使用等多方面的優化和設計。
圖片來源:IDEO
最終,學校完美的改善了午餐服務的體驗,這其中包含了所有利益相關者的想法和工作,因此設計成果也被人們所接受,越來越多的校內人員會選擇學校的午餐,之后,這種設計模式也被舊金山的許多學校采納和推出。
所以,服務中涉及到的利益相關者有很多,多收集他們的想法與建議,甚至讓他們參與到服務設計中去,問題會得到更好的解決。
c.迭代(Iterative)
迭代是一個不斷接受反饋不斷優化的過程,如此重復執行,讓產品變得越來越好。服務設計也需要迭代,不要避免犯錯誤,而是從錯誤中學習和改變,同時也要不斷的收集各方的反饋信息,這些信息是服務進行迭代的核心所在。隨著互聯網的發展,迭代的思維早已滲透到每一個互聯網產品,此處就不再過多解釋。
d.有序(Sequential)
服務設計應該是一系列相互關聯的活動,并且是按照順序進行的,精準的把控服務每一個環節的節奏,用戶才能獲得更愉悅的體驗。
以外賣為例,用戶的使用過程包含訂外賣時的商家選擇到下單過程,下單后配送外賣,用戶收到外賣和用餐后這幾個過程,而服務的提供者主要包括商家、平臺和外賣小哥,為了保證用戶能夠獲得流暢的服務體驗,需要各個服務提供者在服務展開的不同環節推出優質的服務,如下圖。
在訂外賣時,平臺會為用戶推出“超值優惠”“限時秒殺”等優惠活動,商家推薦、訂單歷史等商家選擇渠道,以及不同的篩選條件,以上的目的都在于幫助用戶快速找到自己期望的、合適的商家。在用戶選定商家后,進入到選擇商品并下單的過程,一方面,商家會推出優惠的活動、推薦菜品等,另一方面,平臺也會給出自己的優惠。
下單后,用戶面臨的是一個配送過程中的等待時間,為了緩解用戶在等待過程中的焦慮情緒,平臺會及時更新和推送外賣小哥的狀態,如到達商家、取餐中、與用戶的距離等,同時會給出用戶預期的送達時間,若超過預期時間用戶還可進行催單,商家可以聯系用戶表達歉意,整個過程用戶對配送狀態是可視的。
用戶收到外賣時首先會與外賣小哥接觸,包括與外賣小哥提前確定取餐的時間地點,取外賣時的短暫對話等,這些都會影響用戶對服務的印象,因此外賣小哥需要保證服務態度的禮貌和友好。收到外賣后,食品包裝首先給到了用戶對商家的第一印象,然后是餐品是否符合用戶預期,讓用戶滿意。
在用戶就餐后,首先平臺要提供給用戶評價的功能,用戶可以分享自己就餐的感受,商家也可以通過平臺為用戶提供更多的優惠,引導用戶能夠再次回到商家訂餐。
從外賣的案例中我們可以看到,服務是一個過程,是需要有序展開的,每一個環節的體驗都會影響到用戶對服務的印象,在恰當的環節提供恰當的優質服務,才能確保用戶的整體體驗。
e.真實(Real)
服務本質上是無形的,應該用“物理元素”來可視化,這樣可以用戶的服務記憶,增強用戶對他們所接受服務的感知。
同樣以上述外賣為例,商家為用戶提供餐食,這部分是借助美團這個平臺和外賣小哥來完成的,用戶和商家的接觸僅僅是送達的餐食,因此無法通過像到店體驗一樣,讓用戶感知到商家提供的更多服務。
為了讓服務變得更加“有形化”,商家就需要花費更多的心思,如圖,商家為了增強用戶對服務的感知,一般會在在包裝上花費很多功夫,精致的包裝讓商家的形象更好且更加值得信任,一些有趣的包裝還可能讓用戶的心情變得愉悅。另外,商家也可以通過一張便利貼的溫馨問候或者贈送小禮品等方式讓用戶更真實的感受到服務,通過這樣的手段,即使用戶并沒有真的接觸到商家,體驗也會變得很好,商家的形象也會提升很多。
圖片來源:古田路9號
f.整體(Holistic)
整體就是要著眼于整個用戶旅程,考慮用戶與服務的每個觸點(觸點的概念后文會進行介紹),并兼顧多方利益相關者的需求。也就是所謂的全方位服務體驗,考慮服務環境的方方面面,沒有任何遺漏。這個原則實施起來并不是那么簡單,從整體角度思考問題會使問題變得復雜。不過在服務設計中,是有一些方法和工具是可以幫助我們完成整體思考的,比如服務藍圖。
服務設計的常用方法-服務藍圖
a.服務藍圖簡介
服務藍圖是一張圖表,通過列出在每個階段發生的、不同角色執行的所有活動,顯示了服務的整個過程。如圖所示是一個服務藍圖的簡單示例,垂直方向上展示服務中的利益相關者,水平方向上為用戶的歷程,也就是用戶經歷的不同階段。在服務藍圖中有兩條線,一條是可見線(line of visibility),可見線上方為用戶可與之交互的服務,也可以稱之為“前臺”,可見線下方代表的是后臺進程,用戶無法看到但需要給用戶提供支持,后臺進程還可以存在內部交互線,用來表示內部人員的聯系。用戶與前臺服務之間存在另外一條交互線(line of interaction),用來表示用戶與服務之間的接觸。
圖片來源:Service Design Tools
明確了服務藍圖的大致框架之后,還需要注意服務藍圖中一個非常重要的概念——觸點。觸點就是在服務的各階段,用戶和產品、服務、后臺產生的接觸,每個觸點也是服務可以進行展開和優化的方向。
b.Uber服務藍圖繪制
為了明確服務藍圖的繪制和分析過程,下面將結合下圖所示的Uber服務藍圖進行說明。
圖片來源:Medium
(1) 明確用戶歷程
用戶使用Uber打車服務主要可以簡單分為以下三個階段:注冊(下載APP - 新用戶注冊),乘車階段(下單 - 等待車輛到達 - 乘車 - 到達目的地)、乘車后(付款 - 評價)。
(2) 明確利益相關者
用戶與之產生互動的前臺服務人員為司機,而設計師、開發人員、項目經理等負責后臺的服務支持,以保證Uber按照預期的目標運作。
(3) 明確前后臺活動
一方面,需要明確和用戶接觸的前臺活動有哪些,Uber打車服務中和用戶產生接觸的主要為司機及車輛,因此需要確保司機是合格的、車輛內部的環境是干凈舒適的,同時司機在與用戶接觸的過程中需要提供禮貌的問候和交流,滿足用戶在乘車過程中的要求,完成乘車費用的收取,提醒用戶離開前帶好隨身物品,以及評價乘客等。
另一方面,用戶對后臺的流程可能并不了解,但需要明確哪些后臺活動和支持會對用戶產生影響。比如在用戶下單時能夠自動獲取用戶定位,告知用戶預期的時間和價格,以及發送給用戶司機的狀態等。
在明確前后臺活動時,我們可以以用戶歷程為線,分步驟進行分析,確保每個環節中涉及到的前后臺活動沒有被遺漏。
(4)明確關鍵觸點
在服務藍圖中我們可以標注用戶與服務的主要接觸點,針對觸點進行設計是提升服務體驗的一個重要和有效的手段。
在Uber打車服務中還有一些需要注意的觸點,一是等待時間,這包括用戶發起乘車請求后、付款時以及評價司機時,等待時間是造成用戶體驗較差的一個原因,因此需要注意標注出這些觸點,并想辦法優化,在服務設計中需要注意相關環節的應盡量簡單,減少用戶的等待。另外需要注意的是會對體驗影響較大的觸點,如司機態度不友好、乘客下車時忘記帶隨身物品等,可能造成失敗的服務體驗的觸點應該精心地去設計,避免這樣的情況發生。
通過以上過程我們完成了Uber服務藍圖的繪制,從中可以獲取到Uber打車服務的整體概貌及其相互關系。
///
結語
服務設計的思維能夠幫助我們從全局的角度去審視和思考,發現更多改善服務的可能性,從而為用戶提供更好的體驗。因此對于產品和設計等相關人員來說,不能僅僅把目光放在產品本身,而是要從服務的角度去正確看待產品和用戶的關系,以用戶為中心,找到用戶與產品的每一個接觸點來進行服務設計,這樣才能保證用戶在整個流程中都能得到好的體驗。
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
文章來源:站酷 作者:百度MEUX
分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
即時通訊界面設計 表達其物流行業的專業性和商務性,標識整體精致細膩,令人印象深刻,在界面設計時以厚重,大氣的配色方案和視覺風格提升整個品牌的含義。
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
現在是互聯網逐漸發展,已經出現了很多可以供自己寫博客的網站,大家可以在上面 發表自己的文章,供自己記錄或者是供他人閱讀。但是,可不可以自己搭建一個只屬于自己的個人博客網站呢?這篇文章就帶你從0開始搭建一個自己的個人博客網站,并部署到屬于自己服務器。這里有一點要說的是,沒有服務器的同學使用自己機器的linux系統也是一樣的操作。我們選用一個很好用的博客框架Hexo進行搭建我們的個人博客。
Hexo是一個快速,簡介而且高效的博客框架,Hexo 使用Markdown(或其他渲染引擎)解析文章,在幾秒內,即可生成一個靜態網頁展示我們發布的文章,同時也提供了大量精美的博客主題供我們使用。
我們使用Centos7系統作為演示,使用其他linux系統也是可以的,只需要更換為對應Linux版本的軟件安裝命令即可。
1.安裝Git
直接使用yum安裝即可,在命令行輸入 yum -y install git
完成之后輸入git version 查看是否安裝成功,如果顯示git版本信息即為成功,如下:
2.安裝Node.js
Node.js是一種運行在服務端的JavaScript,是一個基于Chrome JavaScript運行時建立的一個平臺。
Hexo基于Node.js,所以安裝Node.js是必須的一個操作,安裝步驟如下:
2.1:下載安裝包:
wget https://nodejs.org/dist/v12.13.1/node-v12.13.1-linux-x64.tar.xz
2.2:解壓縮軟件包并配置環境變量:
#解壓 tar -xvJf node-v6.10.1-linux-x64.tar.xz #移動到/usl/lcoal目錄下 mv node-v6.10.1-linux-x64 /usr/local/node-v6 #創建軟鏈接 ln -s /usr/local/node-v6/bin/node /bin/node ln -s /usr/local/node-v6/bin/npm /bin/npm #添加環境變量 echo 'export PATH=/usr/local/node-v6/bin:$PATH' >> /etc/profile source /etc/profile #讓環境變量生效
2.3:測試是否安裝成功:
在命令行輸入node -v 和 npm -v,若是顯示出了版本號,即為安裝成功:
3.安裝并使用Hexo
Hexo的安裝較為簡單,使用如下命令安裝
npm install -g hexo-cli #這里有一點要注意的就是,npm的源是在國外的,訪問可能會很慢,這里可以換成我們國內的源進行安裝加快速度。操作如下: npm config set registry https://registry.npm.taobao.org
3.1:初始化Hexo
上面的安裝完成之后執行下面的命令進行對Hexo進行一個初始化
#這個文件名字可以自己指定,之后會在當前目錄下生成對應文件夾 hexo init <文件名字> cd 文件名字 npm install
可以看到安裝好之后的一個目錄結構:
目錄文件說明:
_config.yml:網站的配置信息,您可以在此配置大部分的參數。
package.json:應用程序的信息。EJS, Stylus 和 Markdown renderer 已默認安裝,您可以自由移除。
scaffolds:模版文件夾。當您新建文章時Hexo 會根據 scaffold 來建立文件Hexo的模板是指在新建的文章文件中默認填充的內容。例如,如果您修改scaffold/post.md中的Front-matter內容,那么每次新建一篇文章時都會包含這個修改。
source:資源文件夾是存放用戶資源的地方。除 _posts
文件夾之外,開頭命名為 _
(下劃線)的文件 / 文件夾和隱藏的文件將會被忽略。Markdown 和 HTML 文件會被解析并放到 public
文件夾,而其他文件會被拷貝過去。
themes:主題 文件夾。Hexo 會根據主題來生成靜態頁面。
查看hexo的版本以及對應的數據:
3.2生成靜態文件,并開啟Hexo服務:
進入到了hexo的安裝目錄之后,使用hexo generate來生成靜態文件,也可以使用hexo g,之后使用hexo server(可以寫成hexo s)命令啟動服務,操作如下:
可以看到4000端口的服務已經開啟,之后在你的瀏覽器輸入http://<你的linux機器的ip地址或者服務器公網地址>:4000,如下可以看到最開始的一個界面:
4.初步使用Hexo:
使用前,我們對我們的站點進行一個配置,也就是我們創建的hexo目錄的_config.yml文件,可以修改的部分介紹如下:
# Site
title: QIMING.INFO #博客網站的標題
subtitle: #博客網站的副標題
description: #你的網站描述
keywords: #網站的關鍵詞
author: #作者的名字
language: #博客網站使用的語言
timezone: #網站時區
我自己的修改如下供大家參考,這里的修改沒有太大的限制:
4.1:開始使用Hexo發布自己的第一篇博客!
執行下面的目錄創建一篇新文章:
hexo new post <文章標題>
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-9Tz5aBlT-1622032930755)(pictures/image-20210526145922392.png)]
這里我創建了一篇標題為First_Blog的博客,創建之后hexo目錄下面的source/_post文件夾下會產生一個First_Blog.md的文件
4.2:編輯文章
進入到上面說的那個目錄下可以看到我們創建的博客文件:
直接使用vim或者vi就可以對我們的博客文章進行編輯了,打開此First_Blog.md后可以看到—分隔的區域,這部分主要對文章進行標注變量,如下:
title:標題
tage:標簽
categories:分類
date:時間
這些標注大家在-----區域可以進行使用
4.3:發布文章
輸入如下命令,生成靜態網頁,靜態網頁會存放在public文件下
hexo g
hexo s
之后就可以去瀏覽器訪問了!可以看到我們發布的文章已經成功在瀏覽器顯示,到這里個人博客網站就已經成功搭建了。
5.主題的選擇:
主題網站:https://hexo.io/themes/ hexo提供了大量精美的主題供我們選擇,選擇喜歡的主題,在hexo目錄下的themes文件夾下使用git clone下載主題,之后再配置文件_config.yml把theme后面修改成下載的主題的名字,之后運行hexo clean ,hexo g即可看到生效的主題。
如果是有服務器的小伙伴,也可以將Hexo部署到服務器供全網訪問,服務器的購買這里就不多說,阿里云跟騰訊云上面對于學生也有較為優惠的價格。部署到服務器的話,就需要將上面的全部操作,在你的服務器系統上面執行,之后我們使用Nginx(反向代理服務器)進行部署。
Nginx安裝:
Nginx是一款高性能的 HTTP 和反向代理服務器,這里我們采用編譯安裝的方式,按照下面的指引依次執行命令
#安裝gcc編譯環境: yum install -y gcc-c++ #安裝zlib-devel庫: yum install -y zlib-devel #安裝OpenSSL密碼庫: yum install -y openssl openssl-devel #安裝pcre正則表達式庫:編譯nginx,需要需要指定pcre的路徑,這里我們選擇安裝穩定版本的。 下載地址:https://ftp.pcre.org/pub/pcre/ #選擇對應的版本下載下來之后上傳到我們的服務器,也可以使用wget直接下載 tar -xf pcre-8.43.tar.gz cd pcre-8.43 mkdir -p /usr/local/pcre
./configure --prefix=/usr/local/pcre make && make install
下載編譯安裝nginx:
nginx下載官網:http://nginx.org/en/download.html wget http://nginx.org/download/nginx-1.16.0.tar.gz mkdir -p /usr/local/nginx tar -xf nginx-1.16.0.tar.gz #編譯指定安裝路徑需要進入nginx cd nginx-1.16.0
./configure --prefix=/usr/local/nginx --with-http_ssl_module --with-http_stub_status_module --with-pcre #http_ssl_module 這是支持https的一個模塊,就是可以使用https://這樣去訪問。 make && make install #編譯安裝
啟動nginx服務:
#啟動: /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf #用指定配置文件的方式啟動 -c #測試: /usr/local/nginx/sbin/nginx -t #這個用于測試nginx的語法是否有問題 顯示is successful即為成功。 #關閉: /usr/local/nginx/sbin/nginx -s stop #繼續輸入以下命令使Nginx開機自動啟動: systemctl enable nginx #配置文件的位置:/usr/local/nginx/conf
之后我們需要配置服務器公網ip,編輯配置文件。
之后再重啟nginx服務,開啟hexo服務,這個時候使用公網的ip就可以訪問到我們的hexo服務了!
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
文章來源:csdn 作者:YO哥教你大數據
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
很久以前我寫過一篇講「用戶體驗」的文章,文中提到電影的觀影體驗是可以通過燈光、鏡頭、腳本、臺詞、道具、特效等等手段去塑造出來的。比如,《教父》中對燈光塑造角色形象的首次運用,營造出陰暗、冷酷、深不可測的角色形象,幫助觀眾去建立更立體的角色印象。
所以許多學習電影的同學會去分析電影里的某個鏡頭或某個片段的細節,聊這個鏡頭的拍攝用了什么樣的手法,演員的表演傳遞出了一種什么樣的信息,以值得我們去學習。于是許多學電影的新人就會以為,學好這些東西,就能拍出一部好電影。
但是作為一名導演,如果只關注這些細節去學習所謂的理論知識,而不知道這部電影背后的宗旨,支撐起整個故事脈絡的重要信息,眾多人物角色的復雜情感關系,以及劇本背景所表達的時代現象等等,那么就不可能在自己的電影里代入那些細節理論。甚至連如何推進到這樣的場景都做不到,試問又怎么可能去聊某個鏡頭下的細節呢?
這叫缺乏上下文聯系,也是任何行業的從業人員在學習該行業所需要具備的理論知識時,都會忽略掉的重要條件。
說一個真實故事。設計師 Teisanu Tudor 前陣子在 Instagram 上做了個實驗。他扮演成一位資深 UX,每天通過網上找來的幾張圖片組成各種設計案例、教程、原則等帖子,分享在上面。受歡迎程度遠超他的預期,而其中熱度最高的帖子,是案例改版對比圖,以及兩個方案比較圖,再加幾句簡單的總結。比如:
通過這樣的說法,難道就能認為現在所有 App 或網頁上的 banner 設計都是錯誤的?當然不能這么隨意下定論。
許多人都以為通過這種簡單的幾個步驟就可以學會設計,且認為這個學習過程是有趣且輕松,可以速成的。
Teisanu Tudor 說:這種速成貼如此火爆,不免讓人有些擔憂。這些帖子里的案例幾乎都是脫離改版目標的上下文背景去探討體驗的,可許多人都忘了目標才能決定設計改版后的效果,而不是單獨看起來如何。
或者這類:
A 與 B,真的是 B 更好么?在不同設備與不同用戶的條件下,僅僅通過視覺理論得出這樣的結論,未免也過于倉促。
我們都知道,一個設計方案不可能適用于所有場景,設計師的主要能力之一就是在具體限制條件下,平衡好不同利益相關者,以及多個變量,產出合理方案。而類似這種帖子的火爆似乎在傳遞出一種信息,就是設計是不需要具體問題具體分析的,甚至通過這種細節的通用解法就能解決絕大多數設計問題。這就屬于誤人子弟了。
我經常會在一些地方看到有人在整理某個頁面當中的設計細節,然后有模有樣總結一遍,試圖將其當做產品設計的某種理論或準則。比如截一張某款產品中的界面,說它的按鈕擺放有問題,會導致用戶如何如何,而依據就是之前得出的設計準則。其中最有趣的一次是,有個人拿著一款產品的設計方案去吐槽另一個產品的方案,說沒對上…
在前面兩篇理論文章里,我反復說過理論知識的重要性,它可以幫助我們產出設計方案。但是有一個點是沒有被提及的,就是「理論知識的連接性」。
許多人會把自己看到或學到的東西看作是一個獨立的知識模塊,且希望在工作時能運用上,然而卻事與愿違。于是漸漸排斥理論,覺得理論無用,形成一種認知,就是理論無用論。再也不去讀書,不去學習理論知識,以至于在知識體系層面停滯不前,無法說明白自己產出的方案,只能說感覺:我感覺可以。
這些人再也不會去思考自己為什么做這個需求,以及這個需求的利益相關者是誰,用戶的目標,企業的目標,甚至是這次需求的指標,而只是看界面從某個原則上來說是否合理……而這所謂的原則,只是一些無關緊要的東西,卻被人當做設計圣經。
這就是理論知識逐漸被人輕視的原因,許多人本末倒置,再也回不到正確的那條路上。
比如,前陣子有位讀者問我:呆總,你看 QQ 這里把一些未開通的特權放出來,吸引用戶去開通,但是絕大多數直播產品的勛章體系也挺豐富的,卻很少看見會這么做的,是為什么呢?
類似這樣的問題,在缺乏業務背景,商業目的,需求指標等前提下,是不可能得出一個絕對結論去證明其他產品為什么不這么做的。這是現在大多數人面臨的問題,但卻不自知。
就像我這個系列文章里說的一樣,理論知識當然重要,但是破碎的理論,是有反作用的,所以需要串聯,從全局角度出發,再深挖到細節。而不是只聊大方向,或只聊細節。
舉個例子。當我們拿到一個需求,說要從 0-1 做一個長視頻產品的彈幕體系。可能很多人就會無從下手,第一直覺想的是去找所謂的競品抄一下??赡苓€會像上面那種對比圖一樣,把幾個產品的彈幕界面截圖下來比較下,試圖從界面元素角度判斷哪個設計得更合理。但是會發現,即使是抄,也會抄不到位,甚至會被老板質疑這個方案的合理性。而你能反駁的只是:別人也是這么做的。
而關于不同用戶發布彈幕的權限,比如次數、時間限制、字符差異等重要信息,就被忽視掉了。包括各種違規彈幕,以及如何判斷違規的彈幕,甚至是彈幕在屏幕上出現的密度、形式、速度等信息可能都無法考慮到。這就是現在許多設計師存在的問題 —— 過分專注界面元素,忽視其背后的信息。
雖然我在之前一篇文章里提到,注重細節的重要性,但是理論知識,從來都不是相互獨立的,尤其是與項目相關的,更不可能從某個單點出發得出全面的設計方案理論。
如果你是剛入行的設計師,這么做無可厚非,就像學習電影的學生一樣,它確實是學習理論的一種途徑,只不過缺乏連接。但如果你已經入行一些日子,覺得自己進步緩慢,甚至感到迷茫,且讀完我寫的文章也意識到了這個問題,那你就要開始反思,自己對于理論知識的學習是否有主動去將它們串聯起來。
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
文章來源:優設 作者:呆呆U理
分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
人的時間精力都是有限的,建立良好的信息架構和層級,能讓用戶在有限的時間里快速獲取和理解有用的信息,并進行下一步操作。
一張圖上有四句話,讀者根據 字號 判斷先讀哪一句。在從測試和調研中收集來的用戶需求和期望的基礎上,首先明確內容和交互的優先級,確認信息的先后順序和關聯性后,才能夠設計出有重點的交互界面。這些行為是為了引導用戶在閱讀過程中 一眼獲取重要信息。
用視覺語言來說,上面的例子只是通過調整 文案的尺寸 去探索如何設計頁面層級。同時,通過調整其他平面設計元素例如 字重、顏色、透明度 等等也可以達成同樣的效果。當然,這種行為同時適用于 按鈕、菜單欄、表單 等其他控件。
通過距離劃分視覺元素展示它們之間聯系的基礎前提是 格式塔心理學 組織原則,這是在構建數字界面時所考慮的設計系統的基礎指導理論。因為用戶一般通過 視覺元素的位置 來判斷閱讀順序,設計視覺元素和控件的位置是為了促使用戶完成任務,同時在某些情況下,也會引導用戶去做他們所期望的事。在很多情況下,用戶會自己選擇想看的信息。
“在網絡上,人們會一目十行而不是逐字逐句的閱讀內容。他們一般傾向于付出更少的精力,以高效的方式達成目標。”
這意味著在一個擁有很多功能的頁面上,用戶會一目十行的迅速尋找他們的目標,因此 大部分的視覺信息會被屏蔽。
用戶在網絡上的閱讀方式高度取決于:
用戶的任務目標
用戶習慣
頁面層級
頁面內容形式
這就非常明顯了:最后兩個因素是設計師可以控制的,并且考慮到網絡設計越來越先進,運用知識和技術推動用戶行為,而不是使電子產品成為用戶的阻礙?;谶@個原因,我提出一個設計原則。
有一些人說如果需要在圖標旁邊放一個文字說明,圖標就沒有存在意義了,因為它的認知優先級被降低了,成為了識別序列里的一個負擔。因為圖標視覺系統是建立在 邏輯原則 上的(和文字表達的意思相同),所以無論是對于有沒有相關交互經驗的用戶而言,圖標被認為是可以幫助用戶迅速理解功能的。
一個只有文字說明的軟件菜單和同時擁有圖標和文字的菜單相比,圖標可以幫助用戶更快的理解。在上圖中,根據用戶所期望的功能,可以看到菜單中的圖標帶有要訪問頁面的標題名。接下來,當用戶習慣圖標后,圖標將會更加簡單的引導用戶快速的在界面中尋找到所需要的內容。
當設計一個新界面時設計師需要知道,頁面必定會被有不同閱讀習慣的人使用。為了促進理解,我會把用戶分成三種人并且定義為:新手用戶、中間用戶、專家用戶。
新手用戶 — 就像你所想象的那樣,這是一個 第一次接觸 這個界面的用戶。如果這個界面是某個系統中的一部分,那意味著始終有某些功能點是他第一次接觸到的。這個趨勢是說,這個等級的用戶 理解頁面的速度會低于用戶理解頁面的平均值,并且花費更多的時間去理解語句直到找到所需的內容為止。
中間用戶 — 比新手用戶多一些數字產品的使用經驗,但并不是一個界面使用專家,理解界面的時間大概是處于平均值左右。
專家用戶 — 他們已經使用這個平臺很多次了,所以可以較快的閱讀,而且并不需要通過閱讀所有的內容去理解界面,可以 快速識別元素、布局和交互的視覺呈現。也許正因為這些原因,很多用戶 對產品界面的突然改變抱有抵觸心理。
現在,想想看如果一個投資 APP 每周通過 Email 將以下這個界面發送給用戶。用戶會不會閱讀上面所有的內容呢?每次打開都會閱讀嗎?或者只是閱讀對他比較重要的內容?
這個來自金融 APP 的卡片信息展示了用戶的收入??纯催@個例子,你的閱讀順序是怎么樣的?我可以通過元素的擺放位置、比重、尺寸大小…所形成的視覺層級邏輯來理解它。由于缺乏明確的層級關系,有一些內容無法被精準獲知,必須在事后實際運營的過程中調試,通過用戶使用數據反饋來決定內容的優先級和必要性,并進行修改(使用 Hotjar,Crazy Egg 之類的熱點地圖可以收集數據)。
請注意在這些內容中:唯一的 動態信息 就是整個【 3 】模塊中的重要信息【 4 】中的內容。所有的郵件頁面中位于【 1 】的內容都是一樣的。【 2 】中的信息是不變的,并且重復出現在每一封這類型的郵件中,它們都是其認知標識的一部分。
第一次看到的用戶需要理解這是關于什么內容的信息,所以信息全面是非常重要的,但是 并不需要把所有信息都放在突出的位置上??紤]到這點,通過 減少色彩飽和度、改變字號大小 等降低視覺重量的方式,是不打斷用戶閱讀過程的選擇。
一張展示了用戶收入的來自金融 APP 的 Email 卡片,它應用合理排版促進用戶更好的理解信息。
在上面這張卡片里,簡單的改變了內容排布,突出了最重要的內容。他們展示了 層級關系 對用戶體驗的影響。一味格式化的信息傳遞被更具個性化、同理心的方法所取代。頭部和底部信息與主體信息相合并,通過這種隔離降低了被突出的可能性。最后,將主按鈕更改為次級按鈕(具體情況要根據點擊率來決定,主按鈕可能是最好的方式,有背景色的主按鈕更能激起用戶點擊欲望)
在商業軟件環境中,確切的說是在大量的表格中,更多見的是列表標題比每一行的內容更加突出。因為標題是固定信息,而且用戶可能每天都會看到,而不是將重要等級修改為 主要和可變內容(列表內的內容信息)。
認識到設計界面時成本和實現功能之間的復雜性,遵循這一思路可以幫助設計師確定元素優先級,并且創建層級關系以提升用戶的使用體驗。同時,因為引導對新用戶來說是必須的,所以在設計產品的時候,重要功能需要結合良好的入門教程、功能提示和及時反饋。這樣便建立了可以提升用戶日活及留存的高效、友好的用戶體驗。
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
文章來源:站酷 作者:ZZiUP
分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
“文中示例相關數據都為假的模擬數據,而非真正的商業數據,以此聲明”
【度量Measure】是一種測量評定對象的方式,它幫助我們結構化的獲取對象的狀態與變化,我們運用這些數據進行洞察,轉化為有用的信息,幫助決策和優化,這個過程也是分析診斷的過程。
那日常會有怎樣的一些信息獲取呢?(這里面包含了數據也包含了一些正負性的反饋)
我們對一個功能上線進行一組完整的項目結果質量數據模擬:
凈交易收入額比去年同期上升2.0%,達到2千萬
訂單量為222,比上周上升了2.0%(對交易產生直接正向作用)
方案產出數共222件,比上周上升了22.2% (對內容產出有直接的提升)
用戶的滿意度為2.2 ,上升了2% (之前是2.0)
用戶使用表現出沉靜,輕松的情緒(比之前挫折,晦澀要好很多)
功能點擊,周活躍2200,點擊率22%,周留存22.2%(0-1)
功能渲染和可交互時長為0.2秒加載完成。用戶在使用時交互順暢無卡頓(符合業界前端質量交付標準)
這段描述符合整個產品使用的過程,它似乎是一個多面體,幫助我們了解整個產品黑盒。這個描述越精細越多維,我們得到的信息就越清晰越客觀。(包含多元數據內容,并對數據已進行比對和使用,得到一定的有效信息)反之,假如哪個環節出現問題。我們能清晰看到問題出現的環節,并且通過其表征的信息進行問題的深挖(再細化相關數據或者關聯的層次)。
我們可以拆解到這幾個層次的數據
業務結果、用戶反饋(態度與情緒)、行為點擊、系統性能
可理解為:良好的產品運行-》用戶流暢使用-》良好的用戶反饋-》預期的產品轉化結果
從獲取方式來說,大致可以從兩個大角度(這里從廣義的范疇去分)
【qualitative research定性研究】:快速從樣本中判斷問題的性質和方向
【quantitative research定量研究】:數據的驗證性,全面性、追蹤性
系統承載業務內容的運作,可以記錄各種各樣的明細數據表,在海量數據中,進行科學的關聯與細分。以大數據驅動為最終目標,其特點是:數據的全面性和自動追蹤獲取。
追蹤問題:產品是否符合市場需求?產品是否良性發展?
業務型數據是圍繞著整個商業建設和運作階段而產生的數據。是最能體現產品、商業價值的部分。可以歸納為三類:內容建設->流量訪問->商業交易。是商業鏈路中產生的具有直接商業結果的數據。
內容建設 是指經過人為輸入,系統流轉產生的比如商品、文章、方案等等具有實質內容價值的數據。是具有生產過程的(一般是經過一系列的操作完成的)。
流量訪問/分發 則是針對商業內容的使用/運作,比如某個商品的瀏覽,某個內容的傳播等等。這些和營銷相關具備人群效應的數據也屬于業務數據。最常見的就是曝光量點擊量,而在中后臺系統中則是以訪問瀏覽為主。
商業交易 則是最直接的商業結果型數據,最常見的就是網站的GMV(成交金額:包括:付款金額和未付款。)
訂單交易額、注冊會員數等等。
以某平臺中相關的業務數據為示例
業務結果的分析,是根據不同業務發展,確定核心業務指標,以及建立對核心指標的拆解邏輯。
它或許是個計算公式。或者是個一級指標到二級關聯指標。例如以下,這里暫時不展開來講。
對于業務數據的獲取,我們大部分是直接通過后端的數據庫沉淀下來的。但如果涉及到商業數據的細分(按照商業目標進行階段性或者類別型的追蹤監測)。比如想知道會員的vip的分層情況。或者知道某行業商品的生產細分情況等等。這些雖然可以通過后端拉數據,讓數據分析師或者運營整理出來,但是每次都有加工成本,也沒有辦法看到實時數據,這時候就會要考慮去做細分埋點,下文會提及到埋點方式。
追蹤問題:產品使用情況如何?用戶瀏覽習慣如何?
用戶行為數據,是圍繞用戶訪問某產品過程的用戶行為軌跡數據。其中大體包含了用戶量、曝光量、點擊量、瀏覽量、訪問時長、停留時長等等觀測用戶使用情況的表征數據。
這里是一組典型的平臺用戶使用行為的描述,而這些行為的最終,是產出了上面的業務數據(訂單與成交金額)
訪問首頁->點擊并瀏覽商品詳情->點擊客戶咨詢進行咨詢->點擊購買提交訂單->點擊支付,支付完成
由此我們可以解釋,行為數據與業務結果之間的關系,并且兩者的關注點也是有差異的,在行為鏈路中,我們更注重每一層的轉化關系以及用戶為什么沒有向下轉化的障礙點。
再以B端管理系統為例
B端的管理系統具有典型性,可以用點線面來歸納,點指的是諸如事件曝光點擊等。線指的是用戶使用路徑,面則是廣義的綜合性觀察,比如流量分布,比如區域熱圖等。通過觀察這些,可以觀察到用戶的使用率和使用路徑。并且得知用戶使用產品是否真的貼合需求,設計的是否合理高效。
行為數據要結合具體的場景或者維度去觀察,才能產生更有用的信息。
運用行為數據,我們可以去做很多分析:漏斗分析、留存分析、流量分布分析、路徑分析 、單頁熱力分析、點擊分析、 人群分析等等,這些都是分析方式,在后續關聯篇章中會去探討。
行為數據的獲取是依賴于埋點的,在業界有兩大類埋點方式:全埋點、手動埋點。
行為數據的三大事件類型基本可以歸類為:曝光事件、點擊事件、停留事件
對于C端側重于曝光、點擊。對于B端側重點擊、停留 (從流量轉化與訪問效能兩個角度來說)
以上介紹了業務結果和行為點擊兩種數據,而這兩種內容,都會涉及到埋點采集這件事,這里我們介紹下關于埋點采集數據這件事情。
追蹤問題:如何根據人物、場景、動作制定精準的采集方案?
埋點,是對特定數據的采集,由前端埋點和上報、進行數據處理和數據分析。一般數據埋點分以下三種:
全埋點雖然是所有數據可按需可查,但是因為它的數據量極大,且需要2次定義和清洗,所以只能對通用性質的數據進行采集。而針對性的內容,由數據采集定義后,由前端上報后,可能做到定點,定期精細具體的統計。
兩者大致能產出什么數據分析呢?主要以平臺/系統這個角度看:
整體分析-通用全埋點
用戶活躍、用戶留存、用戶跳出率、用戶停留時長、用戶流量分布...
局部與特定分析-手動埋點
關鍵事件點擊率、關鍵入口渠道流量總計與分布、關鍵鏈路漏斗、關鍵具體區域曝光與停留時長...
為了獲取更精準的業務/行為數據,我們一般會采用手動埋點的方式,所以前期 第一階段會在場景中確定分析目標,然后梳理相應需要的指標,書寫明確的埋點需求是很重要的一個環節,書寫的足夠明確,才能和業務、前端、數據分析師進行準確的溝通,分析目標一致,然后上線后建立相應的數據看板。
注意點:采集方式|統計口徑|數據精準度校驗
那怎么定義數據分析時的埋點需求呢?可以用以下方式去描述:
什么用戶=用戶定義
什么時間=時間戳
什么環境=地理位置+網絡環境+硬件環境+軟件環境+哪個頁面(來源頁面)+什么位置
什么行為=事件ID+命名
什么條件=可以以某個行為或者業務交易為條件
結果如何=用戶操作的結果
示例:
一個后臺系統懸浮幫助功能使用的情況需求
一個搜索使用的情況需求
這2個是比較細致的數據采集的描述。規則了統計的對象,范疇,以及條件,結果觀測等等的需求,大家可以在業務和行為數據相關采集中,試著撰寫下這樣明確的需求。這樣的數據采集才具有精準的分析價值。
追蹤問題:用戶都是哪些人,誰使用了這些功能 ?
人群標簽可以理解為數據型用戶畫像。為什么在這里提及,因為大量數據(特別是具體的采集數據)都會涉及到人群這個角度。人群也是定量數據中最具有獨立觀察價值的數據。
人群標簽就是根據人群特點,進行描述分類,對人群打標簽。我們根據不同的獲取路徑,可以大致分兩類。
一類是利用基本數據進行定義,比較簡單直接
從不同的端,可以獲取用戶的基本來源,如訪問端的類型,或地理位置等,可以定義為“客戶端用戶”、“江浙滬用戶”等。
通過唯一用戶ID所匹配的一系列用戶注冊時的基本信息內容,如性別、職業、行業、興趣等。可以定義為“女性用戶”、“定制類用戶”等。
還有一類就是復合型自定義,一般是根據用戶的業務、行為數據或者類別屬性來定義的,它非常的靈活聚焦。
使用某類條件公式來定義某一波用戶
如我們將購買能力從高低來分層用戶:月購買小于5000的為中購買力用戶,大于5000的為高購買力用戶,周活躍大于2但無購買記錄為潛力用戶。
另外一種構建用戶范疇的方式:通過“時間、地點、事件”等一系列復雜描述來勾勒圈選用戶
如我們定義“第一次訪問站點時,在首頁有關注過每日推薦“的用戶。
這里的復合定義很多時候都會用到多指標多維度。是一種深度結合業務場景來圈選人群,定義用戶的方式。
人群標簽,不僅幫助我們細分數據,知道“到底是什么人做了什么事”,聚焦使用人群的各項指標健康情況。最終,還可以定位產品,定位人群,精細化運營產品:現在的用戶大致都集中在哪些人群中?哪些功能是頭部用戶需要的?哪些功能最受基礎版用戶的歡迎等等。在探索商業需求的時候,更容易找到抓鉤,去深挖商業價值。
常用畫像的場景
2.定量用戶畫像:用定量的數據做某些值的規則,來圈定用戶人群
某產品生命周期使用示例:
性能數據一般指由產品進行頁面渲染及前后端交互時,監測到的時長數據。觀測系統性能,是因為系統數據量很大時,在產品渲染交互環節中,容易產生卡頓,造成用戶體驗的下降,導致流失率。而系統性能,一般是由性能監控等產品產出質量報告。在一些瀏覽器中,也有嵌入的插件統計報告。
這里大致介紹下業界google最新的關于7大性能指標的定義
這其中,最重要的3大核心指標是:
可以通過官方出品,安裝 web-vitals-extension 插件來獲取三大核心指標,也可以通過通過安裝 Lighthouse 插件來獲取如下指標,現在已經內置在瀏覽器中
即選擇典型用戶角色,針對問題或者內容進行集中測試或者訪談:用戶訪談、焦點問題調研、可用性測試等。
比較常用的是:系統可用性量表(SUS)、有效性、滿意度和易用性的問卷(USE)
不管哪種方式,我們都是圍繞“可用性”這個角度去進行評估和研究的。業內可用性這個詞稱為:“Usability”「ISO9241/11」中有明確的相關定義:一個產品可以被特定的用戶在特定的境況中,有效、高效并且滿意得達成特定目標的程度。可用性關注的是用戶與對象在互動過程中的有效性(effectiveness)、效率(efficiency)和滿意度(satisfaction)。
用戶反饋中我們獲取到什么樣的信息,我們第一:明確用戶對此內容的態度,觀察用戶行徑中的順暢度,感受用戶認知反饋。第二:詢問其嚴重程度和影響程度,正面負面情緒。這兩層是由表及里的,互相關聯。但側重有所不一樣。
通常用到以下幾種度量
而這些內容中一般包含數據是
而從場景分我們如何使用這幾種度量呢?
不難發現,我們最常用到的是「自我報告式的度量」
它比較寬泛的反應了產品綜合情況。這里舉一個自我報告度量涵蓋的范疇
追蹤問題:用戶使用后,在情感上反應如何?
初步知曉用戶反饋情況后,可以深入用戶情緒感受,進行點狀問題的挖掘。進而對問題進行定性分析追蹤和程度評級。用戶在一定嚴重情緒影響下,是對產品會產生排斥的,所以有時候對情緒的收集,能讓我們對內容具備敏感度。且在設計過程中,充分建立共情和同理心。
連續型描述模型往往認為人類的情感狀態是分布在若干個維度組成的某一個空間中,不同情感狀態之間不是獨立的,而是連續的,可以轉化的。
當度量情緒變化階梯時,可以試著使用連續情緒。比如:挫折——》生氣、沮喪——》厭煩等。而有些程度詞是和時間長度有直接關系的,比如說疲憊。我們需要關注場景特點,用戶可能會長時間沉浸式體驗時,它是否能接受打擾,是否會因為一些內容受挫。這些都會導致他最終直觀感受的好與壞。
舉例子來陳述:
情緒評分卡:
在各種用戶態度反饋中,我們也可以直接去獲取針對性的情緒化度量表進行5分表計量評分。
具體方式:
以下為目標設定的取詞示例:
常用評估:
高中低評估
低
-會讓參加者心煩或沮喪,但不會導致任務失敗的問題。
中
-這類問題會顯著提高任務的難度,但不會直接導致任務的失敗。
高
-所有直接導致任務失敗的問題。遇到這類問題后基本沒有可能再完成任務。
綜合因素評估
多維度的評估
前兩個較常用,后兩個看產品及技術配合
對用戶體驗的影響
預期的發生頻率
對商業目標的影響
技術/實現成本評分(0=低,1=中,2=高)
藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。
文章來源:站酷 作者:酷家樂UED
分享此文一切功德,皆悉回向給文章原作者及眾讀者.
免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。
藍藍設計( www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務
藍藍設計的小編 http://www.syprn.cn