<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          行業研究:分析框架與思考維度

          資深UI設計者

          做好行業研究,有助于企業或個體從業人員更好地洞察市場,進一步發現機會,或者找準產品定位,推動企業戰略決策和后續實施。本篇文章里,作者就行業研究的分析框架與思考維度做了總結和梳理,一起來看一下。


          一、行業研究的目的

          以始為終,構建行業研究的方法論和分析框架,需要從目的出發,下面列舉幾類典型的行業研究報告目的。

          券商的報告(二級市場),分析某個行業是否有投資價值,從行業賽道的選擇過渡到這個行業賽道中的值得被投資的公司,說明這個行業中哪些公司更有投資價值。報告結果是要用于股票投資服務的。二級市場由于公司財務報告的披露性質,公司的財報分析在行業報告中也是重要的構成部分。

          互聯網戰略投資部門/VC的報告(一級市場),互聯網戰略投資部門通常以公司的戰略發展目標為出發點,布局上/下游產業鏈,或通過收購競品公司,鞏固和發展公司在行業的競爭力,提升市場占有率,開拓新的市場;VC通過布局細分的賽道,選擇合適的投資標的,參與風險投資。

          值得注意的是在互聯網初創企業的財報分析通常不作為重要參考因素,多數互聯網公司在初創期將投入大量資金,長期處于虧損狀態,此時,市場份額和估值與傳統二級市場的分析方式有較大差異。

          咨詢公司的報告,目的是為行業內的公司服務的,說明該行業的行業規律、行業風險、行業機會、行業發展趨勢等。在行業研究的內容方面,咨詢公司常見的模式還包括訪談調研行業內公司高管。

          二、行業研究的常規分析框架

          基于行業研究的目的,常規的行業研究框架,包括一下幾個核心部分:宏觀分析、行業分析、公司分析、消費者分析、競爭者分析,其中宏觀分析和行業分析的視角都是從賽道鏈路的角度,進行整體分析,而公司、消費者和競爭者則是從市場參與者的角度進行分析。

          1. 宏觀分析

          1)宏觀分析思考的維度

          1. 宏觀分析的因素大多非直接影響行業和公司,而是通過影響宏觀基本面,進而對行業產生間接影響。
          2. 在宏觀分析中,多數分析不是僅僅是單因子影響,而是混合因子影響的結合。
          3. 除了行業分析的分析范圍,宏觀分析應該考慮更廣闊的范圍要素,例如如果限定為某一國家的具體的某一行業研究,需要將宏觀分析的內容范圍擴展至全球范圍內的影響要素分析,將中外的宏觀影響影響都考慮到。
          4. 最后,宏觀分析需要考慮時間維度,不能局限于靜態分析,既要考慮存量數據,也要考慮趨勢變化,同時考慮增量數據。

          2)宏觀分析考慮的內容:

          宏觀分析中考慮的因素點對行業環境的影響,因素點可采用PEST模型分類,但不必拘泥于PEST模型,因素點間可能是組成多因素,從而對行業環境產生間接或直接影響?;赑EST模型,因素點可以分為:

          ① 經濟類

          包括經濟發展水平、社會經濟結構和宏觀經濟政策,其中經濟發展水平可以通過較為典型的量化指標進行衡量,例如GDP\CPI\進出口規模等;宏觀經濟政策主要包括貨幣政策和財政政策;社會經濟結構主要體現在經濟體制和產業結構構成。

          ② 政治類

          包括政治體制、政局穩定性、和相關的政治政策。

          其中政治體制包括資本主義、社會主義和中國特色社會主義等,政治體制對行業的影響為間接影響;政策包括投資政策、環保政策、進出口政策、貨幣政策和財政政策等,也有針對具體行業的政策,例如近期發布的教育“雙減”政策就對在線教育行業產生了不小沖擊,網絡安全隱私數據保護政策對互聯網公司獲取用戶使用偏好數據,產生了非常大的影響。

          其次,除了政治政策,政局的穩定性對行業發展穩定產生重要影響。

          ③ 文化環境類

          包括人口因素、社會流動性和消費心理,此類因素可與消費者分析關聯,對消費者細分市場和市場定位產生了重要的影響,主要從聚類的角度,對消費群進行分析。

          人口因素主要考慮人口總數、年齡構成、性別比例、教育水平、人口地理分布等,社會流動性主要考慮社會階級流動性和貧富差距;消費心理主要包括生活方式、文化傳統和價值觀等,對消費者偏好心理產生影響,從而影響消費者的行為決策。

          ④ 科技類

          主要包括專利技術數量和質量、相關產業技術等,科技對一個產業的生產效率與產品更新,甚至一個產業的萌芽和滅亡都將產生巨大的影響,例如智能芯片對手機行業產生了巨大的沖擊,原有的非智能手機迅速被智能手機取代,生產非智能手機的廠商迅速破產。

          綜上,宏觀類因素多數為混合因子對產業產生直接或者間接的影響。

          2. 產業分析

          1)產業分析思考的維度

          ① 整體市場分析

          整體市場分析除了關注靜態的存量市場,也需要關注動態的增量市場。市場的現有市場規模和增速決定了市場的規模,體現為市場的“寬”度和市場的“長”度,行業壁壘和驅動因素影響參與市場的玩家數量,體現為市場的“陡”度。

          ② 市場參與者

          市場參與者從各個角度,在產業分析上有不同的分析時間,例如從產業鏈角度,分析上下游供應商和購買者、從行業參與者的角度,分析競爭者和行業集中程度。

          ③ 影響因素

          產業影響因素和宏觀影響因素的區別在于,產業影響因素從供給需求、驅動和壁壘的角度分析更為直接的影響因素對產業產生的影響。

          2)宏觀分析考慮的內容

          ① 產業規模

          產業規模可以從空間維度進行解析,產業的寬度代表現有市場規模,產業的長度以時間為維度,代表增長率和增長率增速,而產業規模=現有市場規模*增速。

          由此可見產業規模的衡量有兩個重要的衡量標準和指標,即市場規模與復合年均增長率(CAGR),市場有多寬指行業規模有多大、增長的天花板有多高,是衡量一個行業現有市場容量和將來市場發展空間的最重要的標準,現有市場容量決定了該市場有多少蛋糕可以分,而市場增速決定了行業發展潛力,行業增速可與行業的成熟度曲線緊密聯系。

          ② 產業生命周期

          產業的生命周期以時間為維度,一般分為導入期、成長期、成熟期和衰退期。產業生命周期在導入期、成長期、成熟期和衰退期的不同階段,可以從經營風險、財務風險、產品差異、單位利潤、產品特征等不同維度進行分析,詳見下圖。

          ③ 產業鏈

          產業鏈分為上游供應商、下游購買者、潛在進入者和現在競爭者,將企業放在產業鏈進行分析,需要對供應商和購買者有較高的議價權,能有效面對競爭者。

          其中,影響供應商議價能力的影響因素包括市場占有率、轉換成本和供應商戰略,影響購買者議價能力的影響因素包括價格敏感度,相對議價能力等,影響潛在進入者的障礙有結構性障礙和行為障礙,影響替代品威脅的主要因素包括產品同質化程度和勞動生產效率等。

          ④ 產業驅動因素與行業壁壘

          產業的驅動因素主要分為兩個部分,第一是生產要素驅動,第二是相關支持性產業驅動,其中,生產要素包括高級生產要素和初級生產要素,而相關支持性產業,則表現為產業鏈上下游的聚集驅動。

          行業壁壘:行業壁壘分為限制性要素和市場壁壘,可以通俗理解為一只“看得見”的手和“看不見”的手,即政策限制和市場限制。

          政策限制如進出口限制、許可證、配額等,實現限制如規模效益使得成本降低,對新進入的小規模玩家形成行業壁壘,又比如缺乏品牌技術,而只能成為代加工企業,獲取最低的生產制造利潤等。

          如果行業的門檻很高,競爭者難以進入市場,行業的壟斷程度也相應比較高,通常用行業集中度來分析衡量,即CR5(行業中前5名的企業占據的市場份額)。

          但是,壟斷程度越高,企業越有機會獲得超額利潤,但行業的壟斷程度并非僅僅由行業壁壘所決定,消費者的需求差異也會對壟斷程度產生重要影響,例如手機行業的壟斷程度較高,而餐飲行業卻很難出現寡頭壟斷,因為餐飲的消費者偏好差異非常大。

          ⑤ 供求分析

          供給側主要包括產能分析,同時也受行業集中程度的影響,即上文所述的行業壟斷程度,產能分析包括產能利用率水平、庫存周期、產品使用壽命、訂單周期,這里比較典型的行業是電子產品生產制造業。

          需求側主要從消費者市場出發進行分析,同時考慮替代品,需求預測包括消費者整體購買力和細分需求市場,這里的消費者整體購買力受到宏觀因素的影響,例如人均可支配收入、貧富差距等;替代品的細分影響因素包括國家進出口和國內市場替代品。

          ⑥ 產業結構

          產品結構:產品結構可以從加工階段和主導構成不同的視角進行分析,加工階段主要以產業鏈維度為分析視角,從初級產品、中間產品和最終產品進行分析,主導構成主要從驅動因素進行分析,分為勞動密集型產品、資金密集型產品和技術密集型產品等。

          市場結構:市場結構從分類上可以分為市場主體結構、市場客體結構、市場空間結構和市場 時間結構,從行業集中程度,可以分為完全競爭市場、完全壟斷市場、壟斷競爭市場和寡頭壟斷市場等,影響行業集中程度的因素在前文已經提及。

          3. 市場參與者——公司與競爭者

          1)公司思考的維度

          ① 戰略

          戰略需要將企業放置在宏觀和產業的角度,通過對賽道、競爭者和消費者的分析,制定戰略,從整體分配資源,規劃產品和服務。

          ② 經營分析

          經營分析從數據量化的指標,動態指導經營過程中的業務發展。運用定量分析、業務分析和行為分析相結合的方法,對企業進行綜合分析的一種現代經營分析體系。包括:經營基礎分析、財務分析、市場分析、勞務分析、生產分析、物資分析等。從業務單元的視角優化運營。

          2)公司分析考慮的內容

          ① 戰略分析

          戰略分析包括企業能力與資源分析、價值鏈分析、產品組合分析、外部分析、內部分析、財務指標分析和商業模式分析等。

          • 外部分析:外部分析從企業所面臨的產業環境出發,分析企業在產業環境中所面臨的機會和威脅
          • 內部分析:內部分析從企業內部經營的角度出發,分析企業所擁有的資源與能力的優勢和劣勢,即下文所展開的企業能力與資源。企業的外部分析和內部分析構成了SWOT模型。
          • 企業能力與資源:從企業能力的視角可以分為研發能力、生產管理能力、營銷能力、組織管理能力、財務能力等,這些能力構成了企業的核心能力,成為企業在市場中競爭的制勝因素,構成了企業的護城河,其次,從企業資源的視角,可以分為有形資源和無形資源。
          • 價值鏈:可以分為基礎設施和基本活動兩大類,其中基礎設施包括財務、戰略、法務、人力資源、技術開發和采購管理,基本活動包括內部后勤、生產經營、外部后勤、市場營銷和運營。
          • 商業模式:從企業提供產品和盈利模式出發,主要關注一類企業在市場中與用戶、供應商、其他合作伙伴(即營銷的任務環境的各主體)的關系,尤其是彼此間的物流、信息流和資金流。
          • 產品組合:從提供的服務和產品出發,例如零售行業中的品類策略,包括產品線的和SKU的設置,即品類的長度和深度,也可以從經典的波士頓矩陣出發,分析銷售增長率和市場占有率的矩陣,針對明星業務、問題業務、瘦狗業務和金牛業務制定不同的策略。
          • 財務指標:從財務指標,以始為終,進行測算和分析,包括毛利率、現金流、ROE等。

          ② 戰略選擇

          戰略選擇可以從總體戰略和智能單元戰略出發,如果業務涉及海外業務,需要分析選擇國際化經營戰略。

          • 總體戰略:總體策略是公司的總策略,可分為發展戰略、穩定戰略和收縮戰略,其中發展戰略可以分為一體化、密集型和多元化戰略。
          • 職能戰略:從業務單元視角,制定單元戰略,一般包括營銷、生產研發、運營、人力和采購戰略。例如營銷戰略中需要制定細分市場STP,進行營銷戰略的選擇,包括產品、渠道、促銷和分銷(4P)等,其余業務單元策略,在此不做過多的贅述。
          • 國際經營戰略:根據全球化協作程度和本土獨立性和適應能力的差別,本土企業的國際化經營戰略可以分為四種類型,即國際化戰略、多國本土化戰略、全球戰略與跨國戰略。

          3)競爭者思考的維度

          • 優勢:競爭者分析的思路可以簡單分為,發現優勢是什么,以及采取何種策略發大優勢,形成企業的護城河。
          • 劣勢:其次,競爭者分析需要思考與競爭者相比,企業的劣勢是什么,如何縮小這種劣勢。

          4)競爭者分析考慮的內容

          • 競爭分析:競爭分析主要從前文所述的企業資源和能力角度進行分析,包括產品優勢,技術壁壘、分銷渠道優勢、用戶增量和存量、財務狀況、組織架構、核心管理層(人才資源)等視角分析,同一賽道的不同玩家在市場中的競爭力。
          • 戰略選擇:基于競爭分析,針對賽道中的競爭者,可以采取不同的競爭者戰略,主要包括三類,即藍海戰略、中小企業戰略和基本競爭戰略,其中,基本競爭戰略可以分為成本領先戰略,差異化戰略和集中化戰略。

          4. 消費者

          1)消費者思考的維度

          細分市場與精準營銷:在互聯網數字化的革新下,原有的消費者聚類分析越來越精細化,不僅有群體的聚類標簽,個體消費者的標簽也能層層穿透,為精準營銷運營提供了條件。

          2)消費者分析考慮的內容

          基本屬性:基本屬性包括年齡、收入、性別、受教育程度和地域分布等。

          購買動機和購買行為:根據MBA智庫的定義,營銷學家把消費者的購買動機和購買行為概括為6W和6O,從而形成消費者購買行為研究的基本框架。

          ① 市場需要什么(What)——有關產品(Objects)是什么。通過分析消費者希望購買什么,為什么需要這種商品而不是需要那種商品,研究企業應如何提供適銷對路的產品去滿足消費者的需求。

          ② 為何購買(Why)——購買目的(Objectives)是什么。通過分析購買動機的形成(生理的、自然的、經濟的、社會的、心理因素的共同作用),了解消費者的購買目的,采取相應的市場策略。

          ③ 購買者是誰(Who)——購買組織(Organizations)是什么。分析購買者是個人、家庭還是集團,購買的產品供誰使用,誰是購買的決策者、執行者、影響者。根據分析,組合相應的產品、渠道、定價和促銷。

          ④ 如何購買(How)——購買組織的作業行為(Operations)是什么。分析購買者對購買方式的不同要求,有針對性地提供不同的營銷服務。在消費者市場,分析不同的類型消費者的特點,如經濟型購買者對性能和廉價的追求,沖動性者對情趣和外觀的喜好,手頭拮據的購買者要求分期付款,工作繁忙的購買者重視購買方便和送貨上門等。

          ⑤ 何時購買(When)——購買時機(Occasions)是什么。分析購買者對特定產品的購買時間的要求,把握時機,適時推出產品,如分析自然季節和傳統節假日對市場購買的影響程度等。

          ⑥ 何處購買(Where)——購買場合(Outlets)是什么。分析購買者對不同產品的購買地點的要求,如快速消費品,顧客一般要求就近購買,而選購品則要求在商業區購買,一邊挑選對比,特殊品往往會要求直接到企業或專賣店購買等。

          三、總結

          綜上所述,行業研究的框架可從宏觀、賽道、市場參與者進行分析。


          文章來源:人人都是產品經理  作者:Elaine.H

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          如何提升用戶登錄成功率

          資深UI設計者

          什么是登錄?

          登錄是進入一個應用程序 、網站或服務的入口。幫助用戶建立他們的賬戶。

          • 一個登錄流程通常包括一個主要的登錄頁和一個相當復雜的重置流程,其中包括 “忘記密碼”、重置密碼和其他登錄方法。
          • 登錄的首要目標是確保用戶成功登錄到他們的賬戶。

          什么是登錄目標?

          讓我們花點時間來定義一下“登錄目標”這個術語,這是在做設計決策時的關鍵。

          登錄目標是指用戶進入登錄流程的意愿。以有聲思維來表達,它可以是 “我想登錄”、“我想檢查我的電子郵件”、“帶我去那里”,等等。

          當用戶進入到登錄頁時,他們可能沒有登錄意愿??赡軙a生“嗯,我不在乎,以后再做”或“這太麻煩了”或“呀,我現在該怎么辦?”的想法。忘記密碼、半路遇到困難或切換到另一個頁面/設備,都可能是缺乏登陸意愿的跡象。

          掌握這 7 條準則,提升用戶登錄成功率!

          我們得到了登陸目標

          保留或增強登錄流程中的登陸意愿是很好的目標,下面的準則都是為這個目標量身定做的。

          設計熟悉的體驗

          設計熟悉的體驗,雖說不是設計師最喜歡的設計準則,但是與整個生態系統中最好的體驗保持一致是非常重要的。例如使用簡單、公認的布局,使用眾所周知的術語和文案,都有助于用戶自信而輕松地進行熟悉的操作。

          保持通用的設計也有助于將頁面輕松擴展到不同的形式和設備。

          掌握這 7 條準則,提升用戶登錄成功率!

          Pinterest 有一個傳統的、居中的覆蓋式登錄頁。它有一個亮紅色的主要登錄按鈕,并提供 Google 和 Facebook 作為額外的社交登錄選項。

          滑到最后,有我對網絡上流行的成功登錄經驗的總結。這就把我們帶到了下一個問題 —— 創新的界限在哪里?

          登錄是一個品牌展示的絕佳機會點。在視覺上,它可能使用品牌色、品牌照片、品牌插圖,甚至是營銷信息。和大多數設計問題一樣,登錄頁品牌展示的關鍵在于平衡。登錄操作應該一直占據中心位置。頁面上的其他元素必須謹慎規劃好,不應該奪走登陸操作的注意力。

          一條優秀的經驗之談:用戶在登錄頁面上花費的時間越少越好。幫助他們繼續前進,盡快發現產品中的優點和價值。

          聚焦設計

          快速回顧一下:用戶在登錄頁面上花費的時間越少越好。根據這一點,登錄(或恢復)操作應當占據用戶的全部注意力。

          • 最好是把登錄框放在頁面的中心。如果你打算把它放在一側,最好是賦予它核心視覺效果。
          • 對于文案寫作來說,指明用戶在某一步驟中到底需要做什么才是很重要的!比起冗長的解釋,一句簡單的 “輸入密碼”就能起效。幽默、復雜的行話、技術術語和花哨的文筆在登錄體驗中是沒有用武之地的。

          在恢復體驗中,將一套復雜的操作分解成多個步驟是很有效的。安排用戶一次只做一件重要的事情!例如:輸入你的手機號碼和輸入發送到你手機上的驗證碼是兩個獨立的步驟。

          掌握這 7 條準則,提升用戶登錄成功率!

          Facebook 在頁面中保持用戶信息在右側,并將恢復流程分解為多個步驟。

          掌握這 7 條準則,提升用戶登錄成功率!

          亞馬遜把它的恢復流程分解成多個步驟。它將次要的恢復選項設置為 “我需要更多幫助 ”的可擴展部分,這有助于保持注意力集中在主要操作。

          保持注意力集中在主要操作的技巧:

          • 登錄框可以布局在一個主頁、疊加頁,或一個獨立頁面。
          • 使用卡片式布局
          • 將操作分為主要和次要操作
          • 使用一個大而醒目的登錄按鈕
          • 盡量減少次要操作的數量 —— 避免出現任何與核心登錄操作無關的內容。

          給予明確的反饋并在用戶失敗時提供幫助

          在登錄過程的每個階段,用戶都可能失敗。電子郵件地址輸入錯誤、密碼輸入錯誤或忘記密碼、網絡問題,所有這些都可能導致登錄意愿的急劇下降。因此,登錄界面以最恰當的方式回應用戶是非常重要的。清晰、及時、精心編輯的錯誤提示信息能起到很大幫助。

          掌握這 7 條準則,提升用戶登錄成功率!

          錯誤信息包含有用的提示/暗示,指明你在失敗時可以做什么

          掌握這 7 條準則,提升用戶登錄成功率!

          當你密碼登陸失敗,但你有一個 Gmail ID 時,Facebook 會增加一個 “用 Google 賬號登錄 ”的功能

          指導用戶恢復的技巧:

          • 鼓勵用戶嘗試合適的替代方案
          • 在用戶失敗后,安排替代的登錄方案,同時將用戶導航至一個獨立的頁面
          • 在文本中展示出最有用的登錄方案,并在出現錯誤時對用戶做出積極響應!

          盡量保留登錄痕跡

          重點是讓用戶知道平臺識別出了他們,并提供一個歡迎回歸的體驗。這有助于提升用戶的登錄意愿。

          保留登錄痕跡的方法:

          • 像 “記住我”這樣的功能
          • 預先填寫上一步收集到的字段,例如:在跳轉到恢復流程時,預先填寫登錄步驟中收集到的電子郵件 ID
          • 如果使用的是兩步式登錄,為用戶提供個性化的登錄方式是個不錯的主意 —— 用戶對電話OTP(一次性驗證碼)登錄更滿意?還是電子郵件+密碼?記住用戶上次選擇的登陸方式可以提升用戶的登錄意愿,并讓他們感覺到登錄體驗的自然和舒適。
          • 在企業 SSO(單點登錄) 中,用戶可能會用多個賬戶登錄。在檢測到多個賬戶的情況下,最好是將這些賬戶選項呈現給用戶,讓他們選擇他們想使用的賬戶。

          靈活提供多種登錄方式

          對于你的平臺應該提供哪些登錄方法,沒有一個放之四海而皆準的方案。最好是提供一到兩種額外的方法(除了用戶名+密碼),這樣用戶就有了選擇,以防他們忘記密碼。這些方法可以是基于電話號碼的登錄、人臉識別,或最常見的社交登錄,如 Google、Twitter、LinkedIn 或 Facebook。如果你正在考慮社交登錄,思考為平臺添加最流行和最安全的方案。

          需要注意的是 —— 增加很多的登陸方法會使頁面變得混亂,可能會導致登錄意愿降低!將額外的選項限制在 2 或 3 種。

          針對最常用的登陸方式進行優化,并明確區分主要和次要方式。這些選項通常被證明是需要重置密碼(以防用戶忘記密碼)的很好的替代方法,但同時也被認為是一個乏味的步驟。情況允許時,應智能地浮現其他登陸選項并進行個性化處理。例如:如果用戶是通過電子郵件登錄,提供一個帶有一次性鏈接的登錄選項可能會有效。

          掌握這 7 條準則,提升用戶登錄成功率!

          在此提供 Medium 登錄頁的案例。雖然清晰且設計良好,但它確實有太多的登錄方法。不得不回訪 Medium 的設計者,如果這個設計對他們來說是好的!

          無密碼登錄正火速流行起來。特別對于只有移動端的應用程序來說,基于電話號碼的認證已常態化。指紋和 FaceID 在許多地方出現,使認證流程變得快速、安全。為平臺找到最適合(且可開發)的方法,并將其作為主要登錄選項。

          登錄是信任敏感的時刻

          登錄涉及到用戶輸入敏感的個人數據,如電子郵件、密碼和電話號碼 —— 這是決定了他們與平臺關系的敏感時刻。

          登錄框代表了品牌,任何視覺上的改變都必須緩慢進行——因為整體的視覺變化可能會失去用戶信任。

          登錄也是(有用的)保障 —— 足以讓壞人無法進入系統!

          雖然減少普通用戶的操作是很重要的,但如果我們懷疑用戶可能是黑客,那么出現額外的認證也變得很重要。這可能是一個很好的機會去提醒用戶能夠采取哪些措施來加強他們賬戶的安全性 —— 例如:強密碼、雙重認證等。

          通過調研確定用戶類型

          之前有提到過,投入足夠的時間去調研用戶,有助于提高登錄意愿!這一點是很重要的。

          登錄是一種體驗,你的用戶角色可以是各種各樣的 —— 每個人都可能擁有一個你平臺的服務賬戶!如果可能的話,縮小你的角色范圍。

          情況允許時,像我這樣(為社交媒體平臺設計),可以嘗試以下方案:

          1. 登錄漏斗 —— 與項目管理人員合作,找出用戶在登錄流程中互動和放棄的關鍵點。
          2. 登錄入口 —— 用戶是通過電子郵件進入登錄頁面?還是通過搜索引擎的結果?還是當他們在使用產品時?或是在應用程序中?你可以利用這些入口點作為線索,為用戶展現出最相關的選項。
          3. 已知的設備 —— 手機、瀏覽器和已知的設備可以有助于為用戶提供受歡迎的、個性化的登陸體驗。
          4. 用戶群組 —— 根據用戶特性進行劃分,如網絡/移動、年齡組和地域,也能有幫助。
          5. 在用戶沒有登錄時,使用這些線索可以增加用戶的登錄意愿。采取微小的步驟進行用戶識別,并且使用戶易于接受。這有助于你提高登錄成功率!反之這也會為你的平臺帶來更多的活躍用戶,每個人都能成為贏家。

          案例介紹

          以下是我對網絡上我最喜歡的登錄頁進行的總結,包含一些我經常訪問的平臺。歡迎推薦更多登錄頁!

          掌握這 7 條準則,提升用戶登錄成功率!

          Google(谷歌)打破了標識優先的格式 —— 改成了分步式登錄模式,在不同的步驟中輸入電子郵件和密碼。這種模式對于 Google 有安全優勢,也可以使他們在接下來的步驟中為用戶提供個性化的選擇。頁面也是最小的、全白的、聚焦的。

          掌握這 7 條準則,提升用戶登錄成功率!

          Uber 的登錄頁是簡單且聚焦的,允許用戶輸入他們的電話號碼并進入下一步。

          掌握這 7 條準則,提升用戶登錄成功率!

          Facebook 有幾個登錄方案,他們用這些方案進行實驗和 A/B 測試 —— 這是一個右對齊的登錄框案例,它很好地突出了重點。左側的空間被用來打造積極的品牌形象 —— 總體來說是成功的登錄體驗。

          掌握這 7 條準則,提升用戶登錄成功率!

          Pinterest 做了 一個簡單居中的疊加表單,有碩大的輸入框 —— 不斷吸引用戶!還有一個亮紅色的登錄主按鈕,以及一些額外的社交登錄選項。

          掌握這 7 條準則,提升用戶登錄成功率!

          盡管 Airbnb(愛彼迎)在很多方面都做得很好,但它的登錄頁讓人感到操作繁多,這也許是因為基于手機號碼登錄,也許是因為大量的次要登錄選項,導致相當多的認知負荷!

          掌握這 7 條準則,提升用戶登錄成功率!

          LinkedIn(領英)很好地保持登錄框的簡介、聚焦和居中,有一個醒目的主登錄按鈕。

          掌握這 7 條準則,提升用戶登錄成功率!

          我對 Dropbox 的登錄頁面持猶豫態度——插圖很好看,但它的顏色與界面按鈕的顏色相似。這是附加元素分散注意力的案例。就我個人而言,我喜歡在界面中大膽使用插圖,但評估插圖的使用環境也很重要。

          掌握這 7 條準則,提升用戶登錄成功率!

          Amazon(亞馬遜)的登陸頁視覺設計上有些老舊,但對于管理用戶注意力是一個很好的案例,巨大的黃色“繼續”按鈕以及頁面上沒有任何干擾,使登錄任務看起來簡單快速。

          掌握這 7 條準則,提升用戶登錄成功率!

          在登錄頁面上放置廣告可能不是一個好主意,但同時 Yahoo(雅虎)有一個與眾不同的標識在登錄框中,其中設計了一些巧妙的功能,幫助用戶減少輸入。(參考下圖)

          掌握這 7 條準則,提升用戶登錄成功率!

          掌握這 7 條準則,提升用戶登錄成功率!

          我想把 Figma 納入優秀的登錄案例中,該頁居中于浮層,Google 登錄被突出展示(也許是 Figma 的首選和推廣的登錄形式?),它非常簡潔,幾乎是線框式的。用戶體驗非常好。

          感謝我的產品合作伙伴 Apurva 和我一起學習。采取微小的步驟進行用戶識別,并且使用戶易于接受。這會使你的用戶登錄成功率越來越高!同時這也會為平臺帶來更多的活躍用戶。:)希望你能從這篇文章中得到啟發,并應用于你自己的產品和設計工作中。

          文章來源:優設  作者:TCC翻譯情報局

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          部署智能合約到conflux公鏈

          前端達人

          一、準備合約

          本節課程教大家如何講智能合約部署到conflux公鏈上,首先大家可以看到下面的這個智能合約是不是很簡單。我們將會以這個合約演示部署到conflux公鏈的過程。

          pragma solidity ^0.5.0;
          
          contract Counter {
              uint public count=0;
              event SelfEvent(address indexed sender, uint current);
          
              constructor() public {
              } function inc(uint num) public returns (uint){ return count += num;
              } function self() public {
                  emit SelfEvent(msg.sender, count);
              }
          } 復制代碼

          二、conflux的sdk安裝

          我們使用js-conflux-sdk作為本教程的web教程,交互首先我們需要進行安裝nodejs作為我們的運行環境。飛機票一張收下吧,我們安裝好nodejs后,就可以來玩我們的sdk了。廢話不多說,直接開始擼。

          我們使用WIN + R鍵打開命令行,然后創建一個文件夾(溫馨提示切換到非系統盤玩切換方式“D:”就切換到D盤了)使用“mkdir my-project && cd my-project” 創建好項目后自動進入文件夾,然后我們運行“npm init” 進行初始化node項目,這一步會讓你確認一些東西,如果你是小白一路回車(Enter鍵)就好。如果你是前端大神,我也沒啥好教的我也不太懂。為了穩定我們使用固定版本號方式安裝依賴,我們運行 “npm install js-conflux-sdk@0.9.2” 命令進行安裝js-conflux-sdk的0.9.2版本依賴(可以使用“npm uninstall package-name” 命令刪除對應依賴)。前置準備到這里基本已經完成。

          三、編寫調用合約js代碼

          下面請看我的目錄結構跟隨我一起來學習,下面的目錄結構請不要直接看到了就創建,因為你不知道都是什么意思,看玩我的解釋在回頭創建。

           

          image

           

          小伙伴應該已經發現了 node_modules、package-lock.json、package.json 這些文件是我們在進行安裝 sdk依賴時自動生成的。其他文件目前都沒有,我們來按順序生成他們。

          先創建sol這個文件夾,然后創建這三個文件。test.sol就是上面我們的合約代碼直接拷入文件中。abi.json和code.json兩個文件是通過這個工具 remix 在線生成的。我來說下生成過程。 首先我們將里面的文件全部刪除,然后點擊這里找到我們的項目目錄下的test.sol 文件

           

           

           

           

          我們應該看到下方我框出來的兩個按鈕了吧,那兩個按鈕就是abi.json和code.json文件的來源。abi.json我們可以直接復制過去,code.json文件我們要改點東西。

          首先我們看到的code文件應該是這樣的

          { "linkReferences": {}, "object": "608060405260...c63430005110032", "opcodes": "PUSH1 0x80 PUSH1 ... 1100 ORIGIN ", "sourceMap": "27:337:0 ... 37;;;;;;" } 復制代碼

          代碼有省略,太長不好看,我們看到object這個key值了吧,我們把它的值考出來然后在頭部加0x 就好了放在code.json文件中。code.js文件中只存放object的內容前面加0x,也就是下面的代碼,其他信息都不要,千萬記住了。這點很重要!?。?!

          "0x608060405260...c63430005110032" 復制代碼

          就是這樣的。然后我們在寫另外兩個call和deploy兩個文件

          先寫deploy文件

           // 私鑰地址
          const PRIVATE_KEY = '0x20f9169d40801955faada641cdb029f8e42c581c0c991a62753c736a0a168e5e';
          // 合約地址
          const CONTRACT = '';
          const { Conflux } = require('js-conflux-sdk');
          
          async function main() {
            const cfx = new Conflux({
              url: 'http://mainnet-jsonrpc.conflux-chain.org:12537',
              defaultGasPrice: 100,
              defaultGas: 1000000,
            });
            const account = cfx.Account(PRIVATE_KEY); // create account instance
            console.log(account.address); 
          
            // create contract instance
            const contract = cfx.Contract({
              abi: require('./sol/RC20.abi.json'),
              bytecode: require('./sol/RC20.code.json'),
            });
          
            const receipt = await contract.constructor()
              .sendTransaction({ from: account })
              .confirmed();
            console.log(receipt.contractCreated); 
          }
          main().catch(e => console.error(e)); 復制代碼

          打開項目cmd窗口在上面的目錄下 運行命令 “node deploy.js”就將合約部署上去了

          receipt.contractCreated 這個會打印出合約地址。






          作者:悠悠_15832013094

          鏈接:https://juejin.im/post/5ef563f75188252e99702335

          來源:掘金

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          轉自:csdn
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務

          Conflux 開發教程 | 使用 IDE 在 Conflux 開發 DApp 的實戰操作指南

          前端達人

          Conflux DApp 開發教程

          對本教程有任何疑問或建議可以在 GitHub 給我們留言。

          簡介

          Conflux DApp 開發教程將使用 Conflux Studio 在 Oceanus 網絡下開發一個簡單的代幣應用 Coin。
          在這里插入圖片描述

          通過這個開發教程,你將會學習到如何進行 Conflux 智能合約的編寫、調用,配置智能合約的代付以及如何使用 Web 前端項目與智能合約進行交互,從而實現一個包含前端和智能合約的完整的 DApp。

          在閱讀教程中遇到任何問題,歡迎在 Issues 中向我們反饋。

          準備工作

          安裝 IDE

          請在 GitHub 下載頁面下載 Conflux Studio。目前 Conflux Studio 支持 macOS 和 Linux 系統,請根據系統下載對應的版本。

          正確安裝 Conflux Studio 并初次啟動后,Conflux Studio 將顯示歡迎頁面,根據提示完成 Docker, Conflux Node 以及 Conflux Truffle 的下載、安裝及啟動。
          在這里插入圖片描述

          創建錢包

          完成所有的安裝步驟后,首先需要創建鑰匙對來完成后續的合約部署以及調用。

          在 Conflux Studio 的任意界面,點擊應用左下?的鑰匙圖標,打開密鑰管理器。點擊 Create 按鈕打開新鑰匙對彈窗,輸入鑰匙對的名字并點擊 Save 按鈕。完成后將在密鑰管理器中看到剛剛生成的鑰匙對的地址。鑰匙對由私鑰和公鑰組成,公鑰在智能合約中也常被稱作地址。

          導出私鑰可以通過點擊每個地址后面的眼睛按鈕打開查看私鑰彈窗,彈窗顯示地址以及私鑰。后續教程中會需要通過管理器導出私鑰。
          在這里插入圖片描述

          為了順利完成教程,首先需要創建三個鑰匙對:

          • minter_key 用于 Coin 合約部署時的簽名,是這個教程中最常使用的鑰匙對
          • receiver_key 用于 Coin 合約接收轉賬,將在后文中介紹轉賬時用到
          • sponsor_key 用于 Coin 合約代付功能,將在后文中介紹代付功能時用到

          連接 Conflux 網絡

          教程將在 Oceanus 網絡進行合約的部署以及合約的調用。點擊頂部 Network 標簽的倒三角打開下拉菜單,點擊選擇 Oceanus 網絡進行切換。

          切換完成后,可以在主頁面中看到當前網絡為 oceanus。頁面左邊包括了當前網絡的節點 URL,Chain ID,TPS 信息,頁面右邊包含了當前網絡區塊的信息。
          在這里插入圖片描述

          申請測試 CFX

          點擊頂部 Explorer 標簽打開區塊瀏覽器,并在地址欄粘貼鑰匙對地址,可以在左邊看到當前地址的 CFX 余額信息。
          在這里插入圖片描述

          在區塊鏈的世界中,大家通常將申請測試 Token 的方式稱為 faucet,目前在 Oceanus 網絡下每次 faucet 申請到的 Token 為 100 CFX。

          獲取 CFX 的方式有兩種方式:

          • 輸入地址后點擊地址欄右邊的水龍頭按鈕,Conflux Studio 將為地址自動申請 CFX
          • 你也可以直接在瀏覽器中輸入 https://wallet.confluxscan.io/faucet/dev/ask?address={address} 來申請 CFX
            在這里插入圖片描述

          使用上述方法在 Conflux Studio 中為 minter_key 和 sponsor_key 申請 CFX Token。完成申請后,這兩個賬戶上的余額將會從 0 CFX 更新為 100 CFX。

          目前余額信息為:

          • minter_key 余額 100 CFX
          • receiver_key 余額 0 CFX
          • sponsor_key 余額 100 CFX

          智能合約

          創建項目

          點擊頂部左邊的 Project 標簽切換至項目列表頁面,點擊頁面中的 New 按鈕打開項目創建窗口,輸入項目的名稱并選擇 coin 模版,點擊 Create Project 完成項目的創建。
          在這里插入圖片描述

          合約代碼

          Coin 合約是一個簡單的代幣合約,其中:

          • 通過 mint 方法可以增發代幣數量
          • 通過 send 方法可以將一定數量的代幣轉賬給別的用戶,同時會在事件中記錄下這筆轉賬的信息
          • 通過 balanceOf 方法可以查詢到指定賬戶地址的代幣余額
          • 通過 add_privilege 方法可以為合約添加代付白名單
          • 通過 remove_privilege 方法可以為合約移除代付白名單
            在這里插入圖片描述

          Conflux 智能合約使用 Solidity 語言進行開發,打開目錄下的 contracts/Coin.sol 文件,這個是本項目的核心代碼:

          // 指定了 Solidity 的版本,通過 Pragmas(https://solidity.readthedocs.io/en/latest/layout-of-source-files.html#pragmas) 告訴編譯器本代碼可以兼容的版本為 0.5.0 到 0.7.0
          pragma solidity >=0.5.0 <0.7.0;
          
          // 導入 SponsorWhitelistControl 合約
          import "./SponsorWhitelistControl.sol";
          
          // 定義 Coin 的合約
          contract Coin {
              // 定義了兩個 State Variables(https://solidity.readthedocs.io/en/latest/structure-of-a-contract.html#state-variables)
              address public minter;
              mapping (address => uint) private balances;
          
              // 使用 SponsorWhitelistControl 合約連接系統合約
              SponsorWhitelistControl constant private SPONSOR = SponsorWhitelistControl(address(0x0888000000000000000000000000000000000001));
          
              // 定義了 `Sent` 的事件,定義了 from / to / amount 列
              event Sent(address from, address to, uint amount);
          
              // Coin 合約的 constructor ,在 constructor 中指定了 minter 的地址
              constructor() public {
                  // msg.sender 為部署合約時簽名的賬戶地址,將這個地址賦值給 minter
                  minter = msg.sender;
              }
          
              // 定義 mint 方法,通過此方法來增發代幣
              function mint(address receiver, uint amount) public {
                  require(msg.sender == minter);
                  require(amount < 1e60);
                  balances[receiver] += amount;
              }
          
              // 定義 send 方法,通過此方法可以給別的賬戶轉賬代幣
              function send(address receiver, uint amount) public {
                  require(amount <= balances[msg.sender], "Insufficient balance.");
                  balances[msg.sender] -= amount;
                  balances[receiver] += amount;
                  // 通過 emit 觸發 Sent 事件,記錄這筆轉賬的信息
                  emit Sent(msg.sender, receiver, amount);
              }
          
              // 定義 balanceOf 方法,這是個 view 類型的方法,用于查詢賬戶余額
              function balanceOf(address tokenOwner) public view returns(uint balance){
                return balances[tokenOwner];
              }
          
              // 定義了 add_privilege 方法,調用系統合約 add_privilege 方法添加地址到代付白名單
              function add_privilege(address account) public payable {
                  address[] memory a = new address[](1);
                  a[0] = account;
                  SPONSOR.add_privilege(a);
              }
          
              // 定義了 remove_privilege 方法,調用系統合約 remove_privilege 從合約代付白名單中移除地址
              function remove_privilege(address account) public payable {
                  address[] memory a = new address[](1);
                  a[0] = account;
                  SPONSOR.remove_privilege(a);
              }
          } 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39
          • 40
          • 41
          • 42
          • 43
          • 44
          • 45
          • 46
          • 47
          • 48
          • 49
          • 50
          • 51
          • 52
          • 53
          • 54
          • 55
          • 56
          • 57
          • 58
          • 59

          編譯及部署合約

          點擊工具欄的 Build 按鈕進行合約的編譯,編譯的結果將會保存在 build/Coin.json 文件中。
          在這里插入圖片描述
          在部署合約前,首先需要確認在 Explorer 中選擇合約部署所使用的地址,Conflux Studio 會使用這個地址將部署合約這筆交易進行簽名(選擇的方法為在 Explorer 的地址欄中輸入地址)。在合約代碼的 constructor 中,minter 被賦值為 msg.sender,這個 msg.sender 就是 Explorer 所選擇的地址。

          在此我們選擇 minter_key 作為部署合約的簽名者。
          在這里插入圖片描述
          點擊工具欄的部署按鈕進行部署,部署完成后,部署結果會在 deploys 的 JSON 文件中,在這個文件中可以在 contractCreated 中找到當前合約部署的地址,后文中使用 contract_addr 來代表這個合約地址。
          在這里插入圖片描述

          調用合約

          點擊頂部的 Contract 標簽切換至合約頁面,在地址欄輸入 contract_addr 地址并加載合約。
          在這里插入圖片描述

          合約頁面由三個部分組成:

          • 左邊為合約調用區域
          • 中間為合約數據查詢區域
          • 右邊為事件查詢區域

          合約調用及查詢

          增發代幣

          點擊合約調用的下拉菜單中選擇 mint 方法,在下方的參數區域分別填入以下信息:

          • receiver 接收代幣的地址。填入 minter_key 地址
          • amount 發行的代幣總數。填入整數 1000
          • Value 選填項,具體可查看 Value 詳解。填 0 或者不填
          • Signer 這筆交易的簽名地址,如果沒有開通代付功能,交易手續費將在這個賬戶地址中扣除,在合約代碼中通過 msg.sender 獲取到這個地址。填入 minter_key 地址

          填寫完成后點擊執行按鈕,Conflux Studio 將自動構造交易并推送到網絡中。成功執行后可以在下方 Result 中看到這筆成功的交易。
          在這里插入圖片描述

          查詢代幣余額

          點擊查詢區域的下拉菜單并且選擇 balanceOf 方法,這是在代碼中定義的查詢方法。在下方的 tokenOwner 填入 minter_key 地址并點擊執行,就可以在下方的 Result 中看到 minter_key 賬戶的 Coin 代幣的余額信息為 1000。使用同樣方法可以查詢到 receiver_key 賬戶的代幣余額為 0。
          在這里插入圖片描述

          轉賬代幣

          在合約調用區域選擇 send 方法,在 Parameters 中分別填入:

          • receiver 收款人地址。填入 receiver_key 地址
          • amount 轉賬的代幣數量。填入整數 200
          • Signer 這筆交易的簽名地址,代幣轉出的數量將會在這個賬戶中扣除。填入 minter_key 地址,

          點擊執行完成轉賬,再次查詢代幣余額可以看到 minter_key 賬戶只剩下 800 代幣,而 receiver_key 賬戶則從 0 變成了 200 代幣。在這里插入圖片描述

          Value 參數

          Conflux 智能合約的每個調用的方法都可以帶上 Value 參數,這是一個可選的參數。如果帶上了這個值,智能合約出了在執行這個方法的邏輯外,還會額外轉 Value 中指定數量的 CFX token 到 receiver 賬戶,轉賬金額為 Value 中所填的值。有些智能合約的方法需要這個參數才可以完成調用,但是在 Coin 合約不需要這個參數。

          后文中的代付功能將會使用到 Value 參數。

          查詢事件

          在事件區域選擇 Sent 并點擊執行,下方的 Event Logs 可以看到轉賬的記錄。Sent 事件的列都是由代碼中的 Sent 事件的參數來定義的(其中 epoch 為事件發生的時間,這個為系統默認列)。在代碼中定義了 Sent 方法的參數為 from, to 和 amount,分別對應了這筆轉賬的發起者地址,接受者地址以及轉賬的數量。
          在這里插入圖片描述

          代付功能

          Conflux Studio 支持 Conflux 系統合約提供的代付功能。

          通過系統合約可以為別的合約設置代付功能,系統合約提供給了四個方法:

          • add_privilege 添加合約代付白名單,在代付白名單中的地址調用該合約的方法時不需要付手續費,費用由代付賬戶支付。其中添加特殊地址 0x0000000000000000000000000000000000000000 代表為所有調用該合約的地址代付費用
          • remove_privilege 移除合約代付白名單
          • set_sponsor_for_collateral 設置合約儲存費 (collateral for storage) 的代付賬戶及代付金額
          • set_sponsor_for_gas 設置合約手續費 (gas fee) 的代付賬戶、代付金額及每筆交易代付金額上限

          啟用一個合約的代付需要設置代付的賬戶、代付金額的及代付白名單。教程將會使用 Conflux Studio 通過系統合約設置代付賬戶及代付金額,通過 Coin 合約添加代付白名單。設置完成后,minter_key 賬戶調用 Coin 合約的方法時將不會被扣除手續費,手續費由 sponsor_key 賬戶代付。

          設置代付賬戶及代付金額

          在 Conflux Studio 中訪問系統合約地址 0x0888000000000000000000000000000000000001,在合約調用區域能看到前文中提及的四個設置代付的方法。
          在這里插入圖片描述

          選擇 set_sponsor_for_collateral 方法,該方法有三個參數:

          • contract_addr 設置代付的合約地址。填入 contract_addr
          • Value 設置代付金額。填入整數 40
          • Signer 代付賬戶地址。填入 sponsor_key 地址
            在這里插入圖片描述
            填好以上參數并執行運行,系統合約將為 Coin 合約設置好儲存費代付賬戶,此時 sponsor_key 賬戶將會被扣除 40 CFX。

          選擇 set_sponsor_for_gas 方法,該方法有四個參數:

          • contract_addr 設置代付的合約地址。填入 contract_addr
          • upper_bound 設置每筆交易代付的上限。填入 1000000000000
          • Value 設置代付金額。填入整數 40
          • Signer 代付賬戶地址。填入 sponsor_key 地址
            在這里插入圖片描述
            填好以上參數并再次執行運行,系統合約將為 Coin 合約設置好手續費代付賬戶,此時 sponsor_key 賬戶將會再次被扣除 40 CFX。

          完成這兩個方法的調用后 Coin 合約代付賬戶便設置好了,sponsor_key 賬戶將為 Coin 合約的手續費和儲存費各提供為 40 CFX Token 的代付服務。由于目前代付白名單中并沒有賬戶地址,因此還需要添加白名單地址才能完成代付設置。

          添加代付白名單

          在 Coin 合約中集成了設置代付白名單的方法,通過調用此方法可以添加或刪除代付白名單。

          在 Conflux Studio 中訪問 contract_addr 合約,選擇 add_privilege 方法:

          • account 添加白名單的地址。填入 minter_key 地址
          • Value 不填
          • Signer 這筆交易的簽名地址。填入 minter_key 地址

          運行后就成功設置了代付白名單了,至此 Coin 合約的代付功能設置好了。

          代付測試

          在進行代付測試前,先查詢并記錄下 minter_key 賬戶的 CFX 余額。例如本教程中,minter_key 的初始余額為 97.6210937497093952 CFX。

          回到 Coin 合約調用頁面,再次調用 mint 方法并使用 minter_key 地址增發代幣 1000,完成代幣增發后再次查詢 minter_key 的余額,仍然為 97.6210937497093952 CFX。

          可以看到增發代幣的這筆交易,原本應該由 minter_key 賬戶支付的手續費,變成了由 sponsor_key 賬戶支付。

          前端項目

          前端項目源碼可以前往 Conflux 前端。

          預備

          下載項目并安裝依賴

          • 下載前端項目:git clone https://github.com/ObsidianLabs/conflux-frontend-react
          • 使用 npm install 或者 yarn 進行項目依賴安裝

          Conflux Portal 的安裝及配置

          Conflux Portal 是由 Conflux 提供的瀏覽器插件,目前提供了 Chrome 及 Firefox 的支持,用戶可以使用 Conflux Portal 進行私鑰的管理以及交易簽名。

          前往 Conflux Portal GitHub 下載安裝。項目的源代碼在 GitHub 中可以找到。

          在這里需要將 Conflux Studio 中生成的地址導入到 Conflux Portal 中。完成插件安裝后,在 Conflux Portal 的頁面中選擇 Import,將 Conflux Studio 中的 minter_key 的私鑰(在創建錢包章節中介紹了如何將私鑰導出)粘貼到輸入框中,點擊 Import 按鈕完成私鑰導入。
          在這里插入圖片描述

          運行前端項目

          在運行項目之前,需要修改一些默認的環境變量。

          前面的教程中部署合約后會生成一個 contractCreated,這個值便是部署在網絡中智能合約的地址。打開項目根目錄并找到 .env 文件,這個文件提供了項目的環境變量,將 REACT_APP_CONFLUX_COIN_ADDRESS 的值修改為 contract_addr

          使用 yarn start 啟動前端項目,開發服務器運行起來后會在瀏覽器中打開前端頁面(如果沒有打開,請在瀏覽器中訪問 http://localhost:3000)。

          項目運行起來后,頁面將顯示四個卡片信息,分別為

          • 左上角 Conflux 網絡信息模塊
          • 右上角 Conflux Portal 模塊
          • 左下角 Coin 合約模塊
          • 右下角 SponsorWhitelistControl 合約模塊
            在這里插入圖片描述

          連接 Conflux Portal

          點擊右上角組件中的 Connect to Conflux Portal 按鈕,Conflux Portal 頁面將被打開,輸入密碼和選擇賬戶后完成連接。連接成功后,將會在按鈕下看到當前連接的賬戶地址以及賬戶中的 CFX 余額。
          在這里插入圖片描述

          運行 Coin 合約代幣增發和代幣轉賬操作

          左下角的組件為 Coin 合約組件,可以通過這個組件調用代幣增發和代幣轉賬功能。

          • 代幣增發:選擇 mint 方法并在 receiver 中填入增發地址 minter_key 地址和在 amount 中填入增發代幣的數量 100,點擊 Push Transaction,在彈出的 ConfluxPortal Notification 窗口中點擊 Confirm 按鈕來確認交易。

          • 代幣轉賬:選擇 send 方法并在 receiver 中填入收款人地址 receiver_key 地址和在 amount 中轉賬代幣的數量 20,點擊 Push Transaction,在彈出的 ConfluxPortal Notification 窗口中點擊 Confirm 按鈕來確認交易。
            在這里插入圖片描述

          查看 Coin 合約中的余額

          選擇 balanceOf 方法并在 tokenOwner 輸入框中填入查詢的地址,點擊 Query Data 按鈕可以查詢到賬戶的余額。
          在這里插入圖片描述

          查看 Sent 事件

          選擇 Sent 事件并點擊 Query Data 可以查詢到轉賬操作所觸發的轉賬事件的記錄。
          在這里插入圖片描述

          前端項目解析

          項目使用 React 進行開發。主要由三大部分組成:視圖組件、js-conflux-sdk 以及 Conflux Portal。

          項目根目錄下的 .env 環境變量,在這里定義了兩個環境變量,分別為

          • REACT_APP_CONFLUX_NODE_RPC:Conflux 的網絡節點地址,目前默認為 Oceanus 網絡的地址
          • REACT_APP_CONFLUX_COIN_ADDRESS:已部署的 Coin 智能合約地址

          視圖組件

          視圖組件在項目的 src/components 中,其中 App.js 為頁面的主入口,負責頁面的排列及合約信息的讀取。
          在這里插入圖片描述

          ConfluxNetwork.js

          負責渲染 Conflux 網絡信息,Node URL 的值為 .env 環境變量文件下的 REACT_APP_CONFLUX_NODE_RPC 設置的值(默認為 Oceanus 網絡)。

          ConfluxPortal.js

          負責渲染 Conflux Portal 的連接信息,并提供了連接 Conflux Portal 的交互按鈕。

          • connectConfluxPortal 調用 Conflux Portal 的 enable 方法啟用 conflux (conflux portal 實例由瀏覽器插件注入到 windows.portal 中),完成 enable 后調用 getAccount 方法獲取到 Portal 中的賬戶。
          • refreshBalance 調用 Conflux SDK 的 getBalance 方法來更新賬戶余額信息
          • renderPortalButton 根據當前不同的狀態,渲染連接 Portal 的按鈕
          ConfluxContract.js

          負責渲染 Conflux 合約信息,本項目中提供了 Coin 和 SponsorWhitelistControl 兩個合約。

          ConfluxContract.js 由三個組件組成,分別為:

          • ConfluxContract 負責根據傳入的合約 abi 來渲染合約的信息,包括合約地址、合約方法和事件,合約提交的交互邏輯及顯示執行后的結果
          • ContractMethods 負責渲染合約 abi 中的方法和事件的表單及相對應的按鈕
          • ConfluxForm 負責根據方法或事件的 abi 來渲染輸入表單

          lib

          lib 在項目的 src/lib 中,這里的文件主要是為視圖提供包括連接網絡、構造交易、獲取賬戶、讀取合約等服務。
          在這里插入圖片描述

          conflux.js

          conflux.js 是 js-conflux-sdk 的封裝。js-conflux-sdk 是由 Conflux 提供的 JavaScript SDK,本前端項目使用 SDK 來連接 Conflux 網絡,和合約進行交互以及構造合約中的實例。

          conflux-portal.js

          conflux-portal.js 是 Conflux Portal 的封裝,本前端項目通過調用瀏覽器插件來完成交易的簽名。調用 Conflux Portal 提供的 enable 方法可以啟動項目和 Conflux Portal 的連接(需要提前檢查瀏覽器是否正確安裝插件,在 constructor 中通過檢查 window.conflux 是否為空來判斷)。conflux-portal.js 提供了獲取賬戶 getAccount 和發送交易 sendTransaction 兩個主要的方法。

          abi

          lib/abi 文件夾下提供了兩個 json 文件,分別為 Coin.json 和 SponsorWhitelistControl.json,這兩個文件是構造合約所需要使用的 abi 文件。

          總結

          在本開發教程中,我們學習了如何使用 Conflux Studio 來完成一個完整的 Coin DApp 開發,其中包括了:

          • 使用鑰匙對管理器創建賬戶及導出賬戶私鑰
          • 切換 Oceanus 網絡,查看網絡信息
          • 賬戶申請 CFX Token
          • 創建、編譯并部署項目
          • 解析 Coin 合約代碼,學習如何編寫合約的讀寫方法及事件
          • 使用合約瀏覽器調用 Coin 合約的代幣增發、轉賬、查詢余額及查詢事件
          • 設置并使用智能合約的代付功能
          • 將私鑰導入 Conflux Portal 并連接前端項目
          • 在前端項目中調用 Coin 合約的代幣增發、轉賬、查詢余額及查詢事件
          • 解析前端項目代碼,學習如何通過 Conflux Portal 和 Conflux JavaScript SDK 連接網絡并實現交易

          關于 Conflux Bounty

          Conflux 基金會為了鼓勵用戶參與生態建設,提供了 Conflux Bounty 賞金平臺。通過完成 Bounty 賞金平臺發布的各項任務,參與者可以獲得 FC (Fans Token) 作為獎勵。

          FC 的價值

          FC,全稱 Fans Coin,是由 Conflux 基金會與社區成員共同研發的生態代幣,用于記錄和感謝對 Conflux 生態建設做出貢獻的社區成員。FC 目前在 Oceanus 上運行,Conflux 基金會承諾,在主網上線后,鎖定和未鎖定的 FC 都可以與主網 CFX 進行 1:1 承兌,以此保障所有社區成員的勞動成果都可以獲得獎勵。
          在這里插入圖片描述

          FC 賞金分配方案會展示在賞金任務詳情頁中,包括最高獎金數量、獎金分配人數、獎金數量分布、排行名次確定方式等信息。賬號余額中的賞金獎勵可以隨時申請提現至 Conflux 錢包。Conflux 團隊會對所有的提現申請進行審核。

          對于已經通過的提現申請,Conflux 團隊會在每周二中午 12 點(如遇節假日,往后順延至下一個工作日)進行提幣操作。完成提幣操作后,您的 Conflux 錢包將會收到您提現的賞金獎勵。

          Bounty 的價值

          Conflux Bounty (https://bounty.conflux-chain.org) 的宗旨是為每一個通證找到價值。Bounty 分為幾個板塊:技術、品牌、社群、資源、其他等。

          • 技術板塊:分為產品、SDK、教程、開發、測試等;主要是獎勵社區的一些技術資源貢獻者。
          • 品牌板塊:分為文案、設計、視頻、媒體、推廣等;主要是獎勵在各大網絡平臺分享 Conflux 的各種最新動態,擴大 Conflux 的生態影響力的活躍貢獻者;
          • 社群板塊:分為活動、推廣等;主要是獎勵舉辦各種 Conflux 相關線上線下活動,幫助解答社群問題,活躍日常氣氛等。
          • 資源板塊:分為政務、商務、人力等;主要是獎勵為生態中引進企業資源,擴建Conflux 生態等。
          • 其他板塊:分為周邊、采購等;主要是獎勵一些其他的零散任務。

          關于 Obsidian Labs

          黑曜石實驗室(Obsidian Labs) 是全球最大的區塊鏈開發工具(IDE)提供商,也是 Conflux Studio 的開發團隊,致力于為區塊鏈開發者提供必備的工具及服務,幫助鏈上應用生態快速發展。目前,除了 Conflux Studio 外,Obsidian Labs 還為 EOS、Nervos、Substrate、Alogorand 等明星項目提供了專屬的 IDE 和框架工具。






          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          轉自:csdn
          原文鏈接:https://blog.csdn.net/weixin_45029854/article/details/107638406
          作者:Sam @黑曜石實驗室
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          智能合約 web3.js ABI Address三者的關系

          前端達人

          web3.js是以太坊提供的一個Javascript庫,它封裝了以太坊的JSON RPC API,提供了一系列與區塊鏈交互的Javascript對象和函數,包括查看網絡狀態,查看本地賬戶、查看交易和區塊、發送交易、編譯/部署智能合約、調用智能合約等,其中最重要的就是與智能合約交互的API。

          下面就介紹如何使用web3.js提供的接口調用智能合約。

          系統和軟件

          
          
          1. Ubuntu 16.04 64
          2. nodejs 6.10.0
          3. npm 3.10.10

          示例合約

          本文以下面的MetaCoin合約為例,說明在應用中使用web3.js操作智能合約的方法。

          
          
          1. // 本文中用到的MetaCoin合約
          2. pragma solidity ^0.4.2;
          3. contract MetaCoin {
          4. mapping (address => uint) balances;
          5. event Transfer(address indexed _from, address indexed _to, uint256 _value);
          6. function MetaCoin() {
          7. balances[tx.origin] = 10000;
          8. }
          9. function sendCoin(address receiver, uint amount) returns(bool sufficient) {
          10. if (balances[msg.sender] < amount) return false;
          11. balances[msg.sender] -= amount;
          12. balances[receiver] += amount;
          13. Transfer(msg.sender, receiver, amount);
          14. return true;
          15. }
          16. function getBalance(address addr) returns(uint) {
          17. return balances[addr];
          18. }
          19. }

          這個合約有三個函數:

          MetaCoin:構造函數,在合約被部署到區塊鏈時執行 
          getBalance:返回某賬戶的余額,它只讀數據,不會修改數據 
          sendCoin:向另一個賬戶發送指定數量的MetaCoin,它會改變狀態變量balances 
          啟動一個以太坊節點,將上面的合約部署到區塊鏈中,并記錄下合約的地址,可以通過truffle部署,具體參考這篇文章。 接下來就可以按照下面的步驟在項目中通過web3.js來使用這個合約。

          添加web3到項目中

          首先新建一個Nodejs項目并初始化:

          
          
          1. $ mkdir web3test && cd web3test
          2. $ npm init

          會提示輸入項目信息,全部默認即可。 
          接下來下載web3.js到項目中:

          $ npm install web3 --save 
          • 1
          • 2

          以上命令會將web3.js下載到web3test/node_modules目錄下,其中–save參數會web3.js添加到package.json配置文件中。

          創建web3對象

          要使用web3.js與區塊鏈交互,需要先創建web3對象,然后連接到以太坊節點。 在web3test目錄下新建index.js文件,在其中輸入以下代碼:

          
          
          1. var Web3 = require("web3");
          2. // 創建web3對象
          3. var web3 = new Web3();
          4. // 連接到以太坊節點
          5. web3.setProvider(new Web3.providers.HttpProvider("http://localhost:8545"));

          獲取已部署的合約實例

          要使用智能合約,必須先從區塊鏈中獲取到合約實例,獲取合約實例需要合約的ABI和合約的地址:

          
          
          1. // 合約ABI
          2. var abi = [{"constant":false,"inputs":[{"name":"receiver","type":"address"},{"name":"amount","type":"uint256"}],"name":"sendCoin","outputs":[{"name":"sufficient","type":"bool"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"addr","type":"address"}],"name":"getBalance","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"inputs":[],"payable":false,"type":"constructor"},{"anonymous":false,"inputs":[{"indexed":true,"name":"_from","type":"address"},{"indexed":true,"name":"_to","type":"address"},{"indexed":false,"name":"_value","type":"uint256"}],"name":"Transfer","type":"event"}];
          3. // 合約地址
          4. var address = "0xb2cdd356e58280906ce53e1665697b50f88aac56";
          5. // 通過ABI和地址獲取已部署的合約對象
          6. var metacoin = web3.eth.contract(abi).at(address);

          metacoin就是獲取到的合約對象實例,此時metacoin對象中就包含了與合約函數同名的Javascript函數,之后就可以通過metacoin對象來調用合約中的函數了。

          調用合約函數

          MetaCoin合約中有兩個函數:getBalance和sendCoin,可以通過metacoin對象直接調用這兩個函數。

          首先來看getBalance,由于getBalance函數只是從區塊鏈中讀數據,而不修改數據,因此我們通過在getBalance后面加上.call()的方式調用:

          
          
          1. var account_one = web3.eth.accounts[0];
          2. var account_one_balance = metacoin.getBalance.call(account_one);
          3. console.log("account one balance: ", account_one_balance.toNumber());

          這里:

          在getBalance后加上.call()來顯式指明用call的方式調用 
          通過call的方式調用可以得到getBalance函數的返回值 
          通過call的方式調用的函數只在節點本地虛擬機中執行,不會產生交易,不會花費費用,不會修改數據 
          下面來看sendCoin函數,由于sendCoin要修改合約內部的數據,所以要使sendCoin生效,必須要向區塊鏈發送交易,可以在sendCoin后面加上.sendTransaction()來指明這是一筆交易:

          
          
          1. var account_one = web3.eth.accounts[0];
          2. var account_two = web3.eth.accounts[1];
          3. // 提交交易到區塊鏈,會立即返回交易hash,但是交易要等到被礦工收錄到區塊中后才生效
          4. var txhash = metacoin.sendCoin.sendTransaction(account_two, 100, {from:account_one});
          5. console.log(txhash);

          這里:

          在sendCoin函數后加上.sendTransaction()指明要向區塊鏈發送交易 
          合約代碼中sendCoin函數只有兩個參數,而在web3中通過.sendTransaction()調用合約函數的時候需要增加最后一個參數,它是一個javascript對象,里面可以指定from/value/gas等屬性,上面的例子用from來指定交易的發送者 
          上面的調用語句執行后,會向區塊鏈提交一筆交易,這筆交易的發送者是account_one,接收者是metacoin的地址,交易的作用是以account_two和100作為參數執行合約的sendCoin函數 
          函數會立即返回交易的hash,表明交易已經提交到區塊鏈,但是并不知道交易何時處理完成,交易要等到被曠工收錄到區塊中后才會生效 
          監聽合約事件

          當通過.sendTransaction()調用合約的時候,交易會被提交到區塊鏈進行處理,這個處理需要一定的時間,如果需要等交易完成之后再執行其他操作,就必須要知道交易何時完成,那么如何知道交易何時完成呢?可以通過監聽合約事件來實現。

          在合約中可以定義事件,事件可以帶有參數,在合約函數內部完成某些操作時,可以觸發事件,向外界傳達一些信息。例如,在MetaCoin合約中定義了一個事件叫做Transfer,表示一個轉賬的事件,它帶有三個參數:交易的發送者、接受者、轉賬數量。在sendCoin函數中,轉賬成功后就會觸發Transfer事件,將對應的參數傳給該事件,這樣外部監聽到事件后,可以取出事件的參數來獲得交易發送者、接收者、數量。同時事件中還帶有其他信息,比如交易hash等。

          在web3中使用事件,要首先獲取事件對象,然后監聽事件,如果事件發生,就會在回調函數中獲取到事件信息:

          
          
          1. // 獲取事件對象
          2. var myEvent = metacoin.Transfer();
          3. // 監聽事件,監聽到事件后會執行回調函數
          4. myEvent.watch(function(err, result) {
          5. if (!err) {
          6. console.log(result);
          7. } else {
          8. console.log(err);
          9. }
          10. myEvent.stopWatching();
          11. });
          12. // 輸出:
          13. { address: '0xb2cdd356e58280906ce53e1665697b50f88aac56',
          14. blockNumber: 651,
          15. transactionIndex: 0,
          16. transactionHash: '0xcc71bc2824cc84d1ee831c46189e3a80cf0af05697ba0370693aa97390c8067b',
          17. blockHash: '0x1d53f04206f3926d0f311b1230a9dd0b0c5aadac35b169a6a609e384ab130c6f',
          18. logIndex: 0,
          19. removed: false,
          20. event: 'Transfer',
          21. args:
          22. { _from: '0x68b73956d704007514e9257813bdc58cdf3c969a',
          23. _to: '0x9c3c1a2f5ef913fac44f0348a78f68d835f3f26e',
          24. _value: { [String: '100'] s: 1, e: 2, c: [Object] } } }


          從輸出可以看出,獲取到的事件信息包括事件的參數、事件名、區塊號、交易hash等。

          通過檢測事件中的transactionHash與調用合約函數返回的交易hash是否一致,可以判定某一筆交易是否已完成:

          
          
          1. var account_one = web3.eth.accounts[0];
          2. var account_two = web3.eth.accounts[1];
          3. var account_one_balance = metacoin.getBalance.call(account_one);
          4. console.log("account one balance:", account_one_balance.toNumber());
          5. var txhash = metacoin.sendCoin.sendTransaction(account_two, 100, { from: account_one });
          6. var myEvent = metacoin.Transfer();
          7. myEvent.watch(function (err, result) {
          8. if (!err) {
          9. if (result.transactionHash == txhash) {
          10. var account_one_balance = metacoin.getBalance.call(account_one);
          11. console.log("account one balance after sendCoin:", account_one_balance.toNumber());
          12. }
          13. } else {
          14. console.log(err);
          15. }
          16. myEvent.stopWatching();
          17. });
          18. // 輸出:
          19. account one balance: 7000
          20. account one balance after sendCoin: 6900


          watch中的回調函數如果被執行,說明事件已被觸發,也就是說某筆交易已經處理完,檢查交易hash是否一致,可以判定產生這個事件的交易是否是自己發送的交易,如果是,就可以進行其他操作,比如查詢最新的余額


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          轉自:csdn
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務


          async function

          前端達人

          這篇文章多看幾遍加深理解

          async function 聲明定義了一個異步函數,它返回一個AsyncFunction對象。異步函數 是指通過 事件循環(event loop) 異步執行的函數,通過返回一個隱式的 Promise 作為其結果。使用異步函數的代碼的語法和結構更像使用標準同步功能。(The async function declaration defines an asynchronous function, which returns an AsyncFunction object. An asynchronous function is a function which operates asynchronously via the event loop, using an implicit Promise to return its result. But the syntax and structure of your code using async functions is much more like using standard synchronous functions.

          語法

          async function name([param[, param[, ... param]]]) { statements } 
          
          • 1

          參數

          • name:函數名稱
          • param:要傳遞給函數的參數。
          • statements:函數體語句。

          返回值:返回一個promise對象,將返回異步函數返回的值(如果異步函數是resolved則返回resolved的值;如果拋出異常,則rejected從異步函數中拋出的異常)。(A Promise which will be resolved with the value returned by the async function, or rejected with an uncaught exception thrown from within the async function.)

          異步函數可以包含await表達式,該表達式暫停異步函數的執行 并等待 Promise的執行結果返回,結果返回后就恢復異步函數的執行。

          await 關鍵字只在異步函數(async functions)內有效。如果在異步函數外使用它,會拋出語法錯誤。
          當異步函數暫停時,它調用的函數仍會繼續執行。

          舉例一:

          function resolveAfter5Seconds() { return new Promise(resolve => { setTimeout(() => { resolve('resolved'); }, 5000); }); } async function asyncCall() { console.log('calling'); let result = await resolveAfter5Seconds(); console.log(result); // 5s之后輸出結果 } asyncCall(); //返回的是一個promise對象 // console.log(asyncCall()); // Promise { <pending> } 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16

          運行效果:
          在這里插入圖片描述
          舉例二:

          let resolveAfter6Second = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Second = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let sequentialStart = async function () { console.log('sequential start'); const slow = await resolveAfter6Second(); console.log(slow); const fast = await resolveAfter4Second(); console.log(fast); } sequentialStart() //立即輸出 // sequential start // start slow promise //再過6秒后輸出 // slow promise is done // slow // start fast promise //再過4秒后輸出 // fast promise is done // fast 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39
          • 40
          • 41

          運行效果:
          在這里插入圖片描述
          換一種await的寫法,結果完全不同:兩個計時器被同時創建

          let resolveAfter6Seconds = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Seconds = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let concurrentStart = async function () { console.log('concurrent start'); let slow = resolveAfter6Seconds(); let fast = resolveAfter4Seconds(); console.log(await slow); console.log(await fast); } setTimeout(() => { concurrentStart(); }, 2000); //2秒后執行 // concurrent start // start slow promise // start fast promise //再過4秒后執行 // fast promise is done //再過2秒后執行 // slow promise is done // slow // fast 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39
          • 40
          • 41
          • 42

          運行效果:
          在這里插入圖片描述
          在 concurrentStart 中,兩個計時器被同時創建,接著執行await。等待的是 promise的resolve回調,resolve后面的代碼( console.log(‘fast promise is done’);)會繼續執行。
          這兩個計時器同時運行。但是 await 仍舊是順序執行的,第二個 await 還是得等待第一個執行完。在這個例子中,這使得先運行結束的輸出出現在最慢的輸出之后。
          也可以把 concurrentStart 改寫成如下,運行效果一樣:

          let resolveAfter6Seconds = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Seconds = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let concurrentPromise = async function () { console.log('concurrent start'); return Promise.all([resolveAfter6Seconds(), resolveAfter4Seconds()]).then((messages) => { console.log(messages[0]); // slow console.log(messages[1]); // fast }); } setTimeout(() => { concurrentPromise(); }, 2000); //2秒后輸出 // concurrent start // start slow promise // start fast promise //再過6秒后輸出 // fast promise is done //再過2秒后輸出 // slow promise is done // slow // fast 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39
          • 40
          • 41

          并行執行兩個或更多的任務,如下例所示:

          let resolveAfter6Seconds = function () { console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }) } let resolveAfter4Seconds = function () { console.log('start fast promise'); return new Promise(resolve => { setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let parallel = async function () { console.log('start paralel'); await Promise.all([ (async () => console.log(await resolveAfter6Seconds()))(), (async () => console.log(await resolveAfter4Seconds()))() ]); } setTimeout(parallel, 2000); //2秒后輸出 // start paralel // start slow promise // start fast promise //再過4秒后輸出 // fast promise is done // fast //再過2秒后輸出 // slow promise is done // slow 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39
          • 40
          • 41

          運行效果:
          在這里插入圖片描述
          如果希望并行執行兩個或更多的任務,你必須像在parallel中一樣使用await Promise.all([job1(), job2()])

          也可以把parallel改寫成如下,運行效果一樣:

          let resolveAfter6Seconds = function(){ console.log('start slow promise'); return new Promise(resolve => { setTimeout(() => { resolve('slow'); console.log('slow promise is done'); }, 6000); }); } let resolveAfter4Seconds = function(){ console.log('start fast promise'); return new Promise(resolve =>{ setTimeout(() => { resolve('fast'); console.log('fast promise is done'); }, 4000); }) } let parallelPromise = function(){ console.log('parallelPromise start'); resolveAfter6Seconds().then(msg => console.log(msg)); resolveAfter4Seconds().then(msg => console.log(msg)); } setTimeout(() => { parallelPromise(); }, 2000); //2秒后輸出 // parallelPromise start // start slow promise // start fast promise //再過4秒后輸出 // fast promise is done // fast //再過2秒后輸出 // slow promise is done // slow 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39

          async/await和Promise#then對比以及錯誤處理:
          大多數異步函數(async functions )也可以使用 Promises函數 編寫。然而,當涉及到錯誤處理時,異步函數不太容易出錯。
          上面例子中的concurrentStart函數和concurrentPromise函數在功能上都是等效的。在concurrentStart函數中,如果任一awaited調用失敗,它將自動捕獲異常,異步函數執行中斷,并通過隱式返回Promise將錯誤傳遞給調用者。
          在Promise例子中這種情況同樣會發生,函數必須負責返回一個捕獲函數完成的Promise。在concurrentPromise函數中,這意味著它從Promise.all([]).then()中返回一個Promise。事實上,在此示例的先前版本忘記了這樣做!
          但是,async函數仍有可能然可能錯誤地忽略錯誤。
          以parallel異步函數為例。 如果它沒有等待await(或 return)Promise.all([])調用的結果,則不會傳播任何錯誤。
          雖然parallelPromise函數示例看起來很簡單,但它根本不會處理錯誤! 這樣做需要一個類似于return Promise.all([])處理方式。(詳見

          使用async函數重寫 promise 鏈

          返回 Promise的 API 將會產生一個 promise 鏈,它將函數分解成許多部分。例如下面的代碼:

          function getProcessedData(url) { return downloadData(url)// returns a promise .catch(e => { return downloadFallbackData(url);// returns a promise }) .then(v => { return processDataInWorker(v);// returns a promise }) } 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10

          可以重寫為單個async函數:

          async function getProcessedData(url) { let v; try { v = await downloadData(url); } catch (e) { v = await downloadFallbackData(); } return processDataInWorker(v); } 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9

          在上述示例中,return 語句中沒有 await 操作符,因為 async function 的返回值將被隱式地傳遞給 Promise.resolve。

          return await promiseValue; 與 return promiseValue;的比較

          返回值隱式的傳遞給Promise.resolve,并不意味著return await promiseValue;,只是在功能上等同于返回return promiseValue;。
          重寫的上面代碼,在processDataInWorker拋出異常時返回null:

          async function getProcessedData(url) { let v; try { v = await downloadData(url); } catch(e) { v = await downloadFallbackData(url); } try { return await processDataInWorker(v); // 注意 `return await` 和單獨 `return` 的比較 } catch (e) { return null; } } 
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13

          簡單地寫上return processDataInworker(v);將導致在processDataInWorker(v)出錯時function返回值為Promise而不是返回null。

          return foo;return await foo;有一些細微的差異:
          return foo;不管foo是promise還是rejects都將會直接返回foo。相反地,如果foo是一個Promise,return await foo;將等待foo執行(resolve)或拒絕(reject),如果是拒絕,將會在返回前拋出異常。


















          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          轉自:csdn
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務


          提高操作效率的B端設計

          資深UI設計者

          我從自身實踐的B端項目經驗中總結了幾個最典型實用的b端的交互設計,來提高用戶的操作效率。

          目錄:

          一、簡約至上

          二、提高用戶的操作效率

          三、智能化操作設計



                 在設計領域已經有很多經過時間和實踐檢驗的定律法則來作為設計的指導原理,它能夠幫助設計師更快更有效的將需求轉化成合理的界面,并且可以有預見性的去提高產品的用戶體驗。被推崇的有尼爾森十大原則、用戶界面設計的八項黃金法則等。但是實踐出真知,一切的方法論都是源自不斷實踐中提煉和優化的。從原則的輸入理解,到實踐內化,就是自身不斷進步的過程。站在巨人的肩膀上,我們應該總結更多屬于自己的設計方法去解決問題優化設計。我從自身實踐的B端項目經驗中總結了幾個最典型實用的b端的交互設計,來提高用戶的操作效率。


          一、簡約至上

                

                 1951年威廉.埃德蒙.??耸紫忍岢?,認為人們從數組中選擇目標的時間取決于可用選項數量。這表明提出的選項數量與隨后的選擇反應時間之間存在線性關系。從廣義上說,界面越復雜,用戶就越難找到自己的核心操作點,功能越多,就越難發現真正對用戶有價值的東西。

                  2011年Giles Colborne在《簡約至上》,提出“交互設計四策略”,即:合理刪除、分層組織、適時隱藏和巧妙轉移這四個令交互設計最大程度簡單易用的策略。其本質上就是消除多余的信息干擾,保留了用戶主操作流程的心流。

                 作為設計師我們利用“刪除、組合、隱藏、轉移”,不單單是為了簡化而簡化,我們首要明白的就是要在對用戶真正重要的事情上節省他們的腦力。需要把組織成功的標準清晰地構建在產品的簡單上。一次交互就是用戶與設備之間的一次對話,提高效率就是要節約他們的認知成本,學習成本,操作成本,衡量的指標就是完成某個目標的時間。

                B端管理項目有大量的表格處理,一個表格對應的數據項有很多,遵循簡約至上的原則我們不會把所有字段都展示給用戶看,只會優選跟業務最核心、用戶關心的數據來展示給用戶,讓他們看到的盡量簡約的表格信息。即使是最常用的查詢工具,我們也會根據優先級排序,把常用的展示出來,其他的折疊收納,用戶想用到的時候可以展開更多查詢條件。我們無時無刻不遵循著這個設計原則。

           


          二、提高用戶的操作效率


          1、快速定位目標信息


                 在信息量大的B端系統里,快速找到目標信息是最常用的功能。除了導航上的搜索,我所負責的項目幾乎在每個信息頁面中都使用了查詢,篩選、排序功能,這也是常規表格對信息處理的一種快捷方式。常規的信息定位有搜索、查詢、篩選、排序,不同的方式數據的檢索模式也不同。根據不同業務場景,合理的使用才能幫助用戶縮小信息范圍,找到目標信息,提高用戶完成一個任務的效率。


          搜索:是用戶指定任意條件(文本、語音等),平臺對此條件進行檢索后,展示對應內容。搜索由用戶自定義條件,主動表達意圖 ,目的性明確。由于搜索行為是用戶主動表達意圖,往往一個簡短的關鍵詞并不能完整表述用戶想法,因此,搜索結果的內容通常包含多種類型從精確到模糊的展現規則。


          查詢:是利用關鍵字、詞組對系統內的相關信息進行多條件組合檢索。同時用戶也可以輸入指定條件的信息作為搜索項,但由于查詢功能無法對非結構化的文件內容進行查找,所以輸入條件不夠精準將無法查詢到最終信息。


          篩選:是平臺為用戶提供指定條件,用戶可以選擇查看符合一類或多類條件下的內容。投顧項目一般都是先大范圍查詢,再從查詢結果列表中,進行表頭(快捷、對應、條件更明確細化)的信息篩選。


          排序:是根據已設定的內在邏輯,將一組“無序”的記錄序列調整為“有序”的記錄序列。




          2、縮短操作路徑


                  縮短操作路徑簡單的說就是減少操作的步驟來提升操作效率,是基于對用戶、任務及環境的清晰理解的前提條件下,對用戶操作的路徑進行優化。我們可以從以下兩方面入手:


          2.1、通過預測用戶下一步的行為

                  通過預測用戶下一步的行為,對用戶進行直接引導,縮短用戶的行為路徑,減少操作步驟。比如在一系列連貫的操作流中某個鏈路執行出現問題時,用戶下一步的行為是需要及時查看錯誤內容并處理相關信息,在執行結果中增加一個快速查看的按鈕,引導他去查看和處理問題。這比他去菜單中重新查找對賬信息效率要高很多。



          2.2、通過用戶操作路徑分析減少操作步驟

                涉及到大量的信息管理時,那對于信息的快速處理就涉及到批量操作。通過用戶操作路徑分析,用戶勾選批量執行的操作頻繁,單項處理在較少情況才會用到。針對此分析,我們找到了一些具有共同批量操作特點的管理頁面,對其進行操作路徑的優化。批量操作可完全合并成一個執行觸發點。將這個執行點,單獨成一個tab切換頁,細化操作為另一個切換頁。tab頁面的設計,也為錯誤信息的顯示騰出了空間,整個頁面清晰可對比。經過操作路徑的驗證,這個按鈕使用率極高,明細操作幾乎沒有使用到,也縮短了管理頁面的操作時間。




          3、減少記憶負擔


                 減少記憶負擔,是減少用戶在操作時,需要記憶的信息量。一方面我們需要,簡化多余的信息,減少用戶對頁面的認知負荷,另一方面我們可以設計記憶性功能可以幫助用戶記憶。


                 為什么要去減少用戶的記憶負擔,一方面,縮短整個操作的時間快速達成操作目標,另一方面,降低記憶數據量,有助于提升用戶使用的愉悅感。從心里學來講, 人們往往更容易記住那些自己喜歡的事物,而對不喜歡的東西記起來比較吃力,在信息大爆炸時代,我們要記憶的很多信息如登錄號、證件號、密碼、賬戶號等,這些信息有的不但復雜,而且對用戶來說枯燥無味不想記憶,有一種天然的排斥感。那我們通過幫助用戶去記憶留存,再在合適的機會調用顯示,會提高他們在使用過程中的輕松和愉快感。比如對歷史登錄賬戶號的保留,秘鑰儲存功能,再到短信驗證的直接不用密碼即可登錄,驗證碼還可以直接復制到剪貼板,這都是為了降低他們的記憶成本。



                隨著業務的發展,平臺菜單數越來越多,對用戶來說非目標菜單的數量增加,用戶需要更長時間來記憶所選項目的位置,到最后完全只能選擇上方的搜索框進行菜單搜索。Google對用戶的測試表明,沒有一個人始終會把搜索作為第一選擇。相反,他發現只有在網站沒有提供有效導航的情況下,用戶才會使用搜索。搜索需要輸入關鍵詞,即使有模糊匹配,還要進行選擇,而且這個過程不一定順利,可能需要反復操作才能順利找到才能找到自己心中的目標。我們小組設計師通過競品分析和用戶訪談得到的一個驗證性的問題,就是平臺存在菜單設計命名不合理的情況,急需優化。優化思路一個是合理菜單命名與菜單結構,但這個不是一蹴而就的事情,需要從產品整個角度去整理和長遠排期,持續迭代。為此我們先選擇了幫助用戶記憶的思路,即做一個菜單收藏的功能。用戶可以手動把常用菜單直接收藏在首頁,如果在沒有收藏或者收藏未滿限制數量時,會根據記錄的用戶訪問次數提供最常用的菜單(以用戶為導向,自定義功能;以首頁為核心提供業務線支持),無需去記憶菜單位置,不斷尋找菜單。




          4、信息可對照 


                在處理信息的時候,提供信息的對照,減少了跳轉,增強關聯信息的對比,可以很大程度提升用戶處理信息的效率。從系統上講就是分屏,處理多任務事件(蘋果和Windows系統均很好的使用了分屏功能)。從頁面角度來講,其實就是合理化信息模塊展示,一個頁面不止展示一個信息層級的內容。信息內容有從屬關系(避免跳轉)、因果關系(顯示結果)、并列關系(同級對比)。



                同樣具有審批功能的B端項目可能審批流程的設計會完全不同。我負責的另一個項目主要任務是對重大任務的監控,保障日間重點工作按時完成,審批必然嚴格,且需要單條仔細處理。所以我們設計的是樹菜單的形式,讓用戶可以將待處理信息的條目和內容可以直接對照來處理,提高效率。



          三、智能化操作設計


                隨著B端行業日益成熟,越來越多的C端設計師轉型成B端設計師,B端行業的設計思維也不斷的融合和革新,如今B端產品也越來越重視產品的情感化建設、整體的用戶體驗、簡約高效的智能化提升。

                首先讓大家了解一個概念,那就是泰斯勒定律,也就是我們常說的復雜性守恒定律。泰斯勒定律認為每一個過程都有其固有的復雜性,這個復雜性存在一個臨界點,超過了這個點就不能再簡化了,你只能將固有的復雜性從一個地方移動到另外一個地方。



                對于我所負責的項目來說,最能體現產品日趨智能化的交互設計就是清算流程的設計。以往的清算流程是分大流程,點擊流程步驟跳轉至相關操作頁,再進行子模塊的操作與檢驗。完成后,切換回住流程去執行下一個模塊的操作。操作員的操作連續性差且操作步驟多,完全由操作員手動操作觸發,體驗繁瑣及不流暢。為此我們重新梳理了所有清算流程步驟,精間可合并的操作步驟,然后將所有步驟按照時間節點順序排列,完成先前步驟才能進行下一個步驟。流程下方就是對應的執行模塊,只需一鍵執行便可完成當前清算步驟。極大的提高了用戶清算的操作成本。



                后續我們UE小組也會針對平臺進行用戶調研,建立了用戶畫像。對于運維人員痛點分析后,提出清算流程自動化設計,用定時任務直接去執行相關的流程操作,用戶不用進行操作,即可完成結算,只需要關注狀態和處理錯誤信息。



                 自動化智能設計的最大缺陷就是無法遇到極致的準確率。實際處理過程中,還是會有清算錯誤信息存在。為了解決這個問題,我們保留了執行按鈕(不手動操作時,自動跑完),運維人員也可以手動執行,處理問題。除了將操作日志信息模塊,作為組件,分屏來顯示錯誤信息,我們還按照商戶維度來計算狀態,以便于運維人員發現具體的錯誤位置。幫助操作員去查看和解決錯誤信息。智能化的設計解放了很大一部分的重復勞動,讓用戶更聚焦有意義的工作。

                  智能化已然成為了設計趨勢,這將會對系統的性能提升和信息處理精準化提出更高的要求。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼ben_lanlan,報下信息,會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          文章來源:站酷  作者:上仙修行

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          關于后臺系統設計規范總結

          資深UI設計者

          一套完善的產品化設計系統,可以解決內部協作的一致性問題,解決設計系統更新的周期性問題,解決一群設計師與工程師如何規?;纳a各種業務、UI的問題,從而最終解決用戶體驗一致性的問題。說到自己,公司的產品從接手開始便是以antdesign作為前端框架,所以很多人會說后臺用antdesign、Element或者Taro的框架就足夠了呀,當然不~在已有的成熟框架下,也并不能完全滿足產品日(sang)益(xin)旺(bing)盛(kuang)的需求,所以設設計規范還是很有必要的。

          作為B端設計師,視覺表現層面權重逐漸減少,更多的是需要梳理邏輯流程,將線下業務更好的梳理到線上流程,所以熟知設計規范可以更效率的完成工作。



          設計規范的目的:


          1、解決內部協作的一致性問題

          為設計師內部溝通協作起到決定作用,當同一個項目存在多個設計師橫向設計的時候,設計規范會避免顏色錯誤、間距失調、控件混亂等問題。

          2、解決設計系統更新的周期性問題

          隨著產品的不斷推進和發展,為了新增的需求和不斷優化的用戶體驗,這時候會需要對某些規范控件進行調整,在有設計規范的情況下,可以迅速對接開發快速全局調整控件,極大的提升了設計和開發的工作效率。


          3、解決設計師與工程師如何規?;纳a各種業務

          關于和開發對接,圖標在如今有了iconfont的項目管理下,項目可以建立自己的圖標庫。再加上設計建立的可復用的公共控件庫,開發可以更加快捷的復用控件,減少返工率,也為后期的修改降低開發成本。


          關于建立后臺設計規范:


          首先要了解項目適用的主要場景,也就是用戶爸爸一般是在什么情況下用什么樣的設備來進行操作的,然鵝你永遠不知道會有什么的場景和什么樣奇葩的設備在等待你。在后臺的設計群一直有一個經久不衰的話題,那就是后臺設計的設計分辨率是向下適配還是向上適配更合適(是1980*1080 還是 1440*900 ),這兩者都是可以的,本案由于用戶使用筆記本的情況居多,且設備并不是很新所以采用1440*900的分辨率向上適配1980向下適配1200。
          在清楚的了解到項目背景之后,開始著手于設計規范的建立,這里關于設計規范的建立是隨著設計的不斷深入從而不斷完善的,不必刻意深入,但是要隨時更新規范文檔。



          關于頁面構成


          開發與設計所理解的頁面是不一樣的,所以會造成開發出來的頁面有時候會因為各種原因與高保真相差較大,在設計看來(比如sketch),一個頁面是由多個組結合而來,每個組里包含一個或多個字段、圖片和圖標等,在調整大小、間距、顏色之后慢慢成為高保真。而在開發的角度來看,整個頁面就是由多個box構成,盒子與盒子之間存在空白間隔,且盒子存在一定的屬性,例如盒子默認對齊于左上,盒子之間相互嵌套或覆蓋需要基于所屬盒子來定位。


          顏色

          根據品牌背景和產品定位來確定你的品牌色,用于字體、icon、按鈕、插畫等業務流程。功能色則是為特殊場景,例如失敗、成功、提醒等情況。


          字體

          通過購買商用字體或使用免費字體來使用,如果選用免費字體同時也要注意區分系統,通常情況下mac系統使用默認字體蘋方字體,windows系統使用微軟雅黑。如今免費等字庫已經越來越多了,所以這對設計師來說是一個好消息,今年阿里也在UCAN上公布了普惠體,年尾oppo也推出了自己的免費字體,文章末尾附上群友整理的免費字體導圖。


          邊角

          倒角的使用可以起到樣式的區分,從而讓用戶感知到功能區域的分別。


          圖標

          快速幫助用戶理解產品并順利完成操作,好的圖標具有高度濃縮并快捷傳達、便于記憶的特性,能夠更好的傳達品牌特性。


          陰影

          陰影的添加可以更好的提高界面品質,讓用戶易于區分功能區域


          按鈕

          按鈕是傳達它將要發起動作的載體。 用戶可以點擊一個按鈕來開始一個過程或工作流程,或觸發一個動作。

          用法:

          1、要傳達重要的行動。如:提交表單;

          2、要導航到另一個屏幕,觸發一個模式或啟動一個動作。如:在進程中指定新的動作或模式;

          3、按鈕上的文本應保持簡潔,帶著明確、可操作的動詞,例如:注冊、下一步、下載 ;

          4、優先考慮最重要的行動。行動號召太多會引起混亂,并使用戶不知道下一步該做什么。

          選擇輸入框

          如無特殊需求,則默認采用框架內輸入框,特殊情況可同研發一起討論修改。這邊因為一些特殊原因,在修改了代碼的情況下實現了標題、選擇、輸入同時在框架內,這樣為寸土寸金的后臺界面留出了更多的空間。


          表格

          表格在后臺系統中無處不在,對數據管理和分析起到了重要的作用,方便用戶閱讀,分析和比較數據。表格一般由表頭、表尾、數據單元格組成。


          模態/非模態彈窗

          用戶交互的兩種方式,模態彈窗強制交互完成當前操作流程,非模態則是弱提示。

          缺省狀態

          缺省頁是指操作異常狀態下給予用戶反饋的提示頁面,它的作用不僅是提醒用戶,安撫情緒;更重要的是用“空白”觸發用戶的操作行為,營造良好用戶體驗。


          結語


          以上是我對于設計規范的部分總結,還有很多沒有涉及到,包括非常重要的可視化部分,可以多了解一下ECharts(https://www.echartsjs.com/zh/index.html),然后希望可以和大家互相學習。設計規范的建立是長征的第一步,貫徹執行才是根本,在B端龐大的設計系統中,我們需要維護好產品的組件庫,不斷的完善用戶體驗和清晰的梳理線上業務,保證產品的功能需求才是重中之重。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼ben_lanlan,報下信息,會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          文章來源:站酷  作者:請叫我紅領今

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          整理數據報表系統的7個步驟

          資深UI設計者

          清晰且有效的數據報表可以反映出數據變化,進而幫助團隊人員確定后續的產品優化迭代方向,找出可能存在的問題。那么,產品經理應當怎么整理出清晰且直觀的數據報表?本篇文章里,作者總結了產品經理整理數據報表的可操作步驟,一起來看一下。

          之前聊數據埋點的時候曾經提了一下,說是后面聊一下數據報表的事情,今兒個正好有空,捋一捋,跟大家做個分享。

          上次分享的是《產品經理整理埋點需求的6個步驟》,有興趣的朋友可以進去看看。

          大家都很關心數據的事情,因為數據能比較直觀地反應哪些地方發生了新的變化,能夠提醒相關人員去關注和調整,同時一個新的優化上線之后也能夠根據數據去判斷優化方向是不是正確的問題。數據是最便捷的方式。

          但是你想看數據就需要先把數據報表理出來,一個業務或者一個APP會產生大量的數據,你需要根據關聯性和重要性去整理出具體的數據表,然后再去觀察,直接看明細或者日志那你得瘋。

          怎么整理數據報表呢?

          它需要根據核心業務流程和業務指標來梳理,然后兼顧到職級分層、部門分類、重要程度、使用頻次來分別處理。

          我們以電商業務為例來簡單說說,選電商是因為大家對電商業務更熟悉。

          我整理了一下,大致上可以按照以下步驟去整理數據報表系統。

          第一步,確認要做哪些表。

          你先確定有哪些部門需要看報表,常規來說包含市場、商務、運營、產品、客服、售后等部門。

          然后你去看這些部門都會需要哪些報表,譬如市場部門需要渠道流量轉化表等,運營部門需要營銷轉化表、業務流程表、銷量排名表等,產品部門需要業務流程表、產品日常數據表等(觀察用戶留存與活躍的),客服需要用戶反饋問題進度表等、售后需要售后問題進度表等。

          以上只是我不專業的一個舉例,實際上表是非常多的。

          這里面有個地方需要注意一下,有些表看上去字段是差不多的,譬如渠道流量轉化表和業務流程表,很多字段都是重復的,那么要不要并表就是一個需要考慮的問題。有的公司管理比較嚴格,那么最好不并表,這樣可以通過后臺權限來控制展示,如果相對寬松那么可以向相關部門做一下確認然后決定要不要并表。

          注意:數據后臺和管理后臺是分開的,不能混淆。管理后臺用來管理用戶、商品、商戶和看明細數據(用戶信息表、購買訂單表)等等,數據后臺就是用來看統計數據的。

          第二步,整理不同部門報表需要展現的字段。

          以業務流程表為例。

          先把業務主流程的關鍵節點梳理出來,到成交算是一個流程。電商的話流程大概是用戶注冊/登錄→查看商品詳情→加入購物車→立即購買/結算→立即付款→完成付款。

          那么業務流程表的字段也就清楚了:

          注意:報表字段是有了,但是也需要說清楚這些字段的具體含義,譬如注冊/登錄用戶數,指的是在統計時段內,注冊+登錄用戶的人數之和,需要去重。

          不要小看這個說明,這個說明決定了大家的理解能不能一致,邊界請不清晰,上面那個例子,如果沒有后面那個“需要去重”那么技術在處理的時候是不會去重的,這樣的話如果一個用戶在指定時段內登錄了多次就會統計多次。

          一定要寫這個說明,不寫的話技術就自己發揮了,每個人對業務的理解是不一樣的,所以一定要寫。

          第三步,去擴展報表的統計維度。

          數據報表是有了,但是統計維度也需要定義,譬如需要按照日期、按渠道、按類目(商品)、按商戶、按地區等等維度去看數據,那么就需要把這些和報表相關的維度加上去,這樣就能實現按維度看數據的目的。

          這個比較簡單,有什么維度加什么維度就行,但是在處理的時候需要注意,多個條件組合能不能篩選出數據的問題,這個比較細節。

          第四步,整理核心轉化公式數據表。

          核心轉化公式數據表是給公司高管和核心業務骨干看的,高管是不可能看什么部門表的,看不過來也沒必要,高管們看的表只需要體現核心數據和指標就可以。

          高管們關心的也就是部門負責人關心的,部門負責人關心就應該是一線員工關心的,這就是一個拉齊公司內部認知的一個表,所以核心轉化公式數據表特別重要,重要到需要單列一個步驟說明。

          整理核心轉化公式數據表之前就需要去梳理業務的核心轉化公式,電商業務的核心轉化公式如下:GMV=注冊登錄用戶數*購買轉化率*客單價*人均購買數量*(1-退貨率)。

          這就是一個用戶從曝光到復購的一個簡化的轉化公式,這個公式的意義在于聚焦提高產值的關鍵步驟,目標不會偏。

          注意:這個公式很重要,不能錯,如果自己沒把握的話可以問一下公司領導,知道弄清楚為止。

          其實做KPI的時候也一定會需要這個核心轉化公式,這樣大家就能知道在哪些環節可以提高績效,分別是提高多少,由哪些部門具體負責。

          根據這個核心公式就可以整理相關的字段:

          這樣公司領導每天看這個數據就知道業務有沒有在向預定目標發展,以及距離目標還有多遠。

          當然有了字段以后也需要加維度,這個就參考前面的步驟就可以。這里的統計維度其實是比較少用到的,但是功能還是必備。

           第五步,整理日常大盤數據表。

          大盤表是給所有員工看的,可以作為數據后臺的首頁。

          大盤表通常是昨日數據的匯總統計,譬如GMV、銷售訂單數、銷售商品數、退貨商品數、退貨總金額、新增商戶數、新增用戶數、新增商品數,大概看一下數據的變化,給大家一個總體的印象。

          第六步,整理實時統計表。

          有一些業務對于數據的實時性要求比較高,所以會涉及到需要做實時統計表,實時統計表一般每小時更新一次數據,如果流程出現問題就可以及時進行排查和修復,但是對于大部分業務來說其實不需要,如果不是發布了新的代碼,理論上是不會出現這個問題。

          當然像電商APP,如果遇到雙11這種,一般來說還是需要看一下實時數據的,因為全公司都很關心當天的戰果,屬于重要時刻。所以電商APP需要做實時表,字段的話一般也就是大盤數據表上的字段就行,額外字段的話可以根據領導的要求做。

          第七步,最后確認報表字段和整理成需求文檔。

          把整理好的表格和各部門對一下,根據各部門的要求調整完成后制作成需求文檔。

          這個步驟就不多說了,按照需求的整理流程處理就行。

          以上就是整理報表系統的幾個步驟,當然因為細節太多了,其實沒有辦法在一篇文章里面講的非常清楚,但是至少80%的東西還是在了,所以還是有參考性的。希望對大家有所幫助。

          實際上做報表系統是一個持續優化和新增的過程,如果是從0開始做的話就需要單獨立項然后分期做,一下子肯定是不現實的,因為工作量太大了,項目的進度不好控制,還有就是有些表并不需要馬上做的,也可以緩一緩,這樣優先級高的數據報表就會更快的上線。

          如果業務不大的話甚至可以用excel先統計起來。總之展現形式和處理方式還是很多樣化的。

          產品經理在數據方面我認為其實可以多花點功夫,形成一套比較具有實操性的方法論比較好,一個數據產品和一個APP產品在競爭力上還是有差異,實際上越細分專業度越高,競爭力越強。當然首先至少要做到及格。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼ben_lanlan,報下信息,會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          文章來源:人人都是產品經理  作者:代號道長

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務

          ERP和APS的聯系與區別

          資深UI設計者

          ERP系統可以幫助跟蹤、存儲信息,有助于推動后續的產品決策,而APS系統是對ERP系統的補充和優化,具體而言,APS系統和ERP系統有什么關系?本篇文章里,作者就二者的關系、區別及應用等方面做了總結,一起來看一下。

          APS作為對ERP計劃系統的補充和優化,集成主要集中在與ERP計劃系統的交互層次上。二者其實有很多相似和聯系的地方。

          • ERP系統是企業資源計劃的簡稱,是指建立在信息技術基礎上,集信息技術與先進管理思想于一身,以系統化的管理思想,為企業員工及決策層提供決策手段的管理平臺。
          • APS系統是高級計劃與排程的簡稱,是解決企業內部生產排程和生產調度問題,常被稱為排序問題或資源分配問題。

          首先,APS的需求計劃模塊從ERP的訂單輸入中獲得客戶的實際需求,然后需求計劃模塊再結合外部數據中預測需求通過APS算法計算得出預測生產計劃;同時再通過APS中的供應鏈計劃模塊中的約束條件,得到指導MRP的約束生產計劃,傳回ERP的主生產計劃模塊。

          一、APS與ERP的關系

          APS的制造計劃模塊與ERP的MRP通過制造訂單,結合BOM、庫存信息及采購信息等數據綜合考慮,反復交互論證,得出將要生產排產的生產任務單。

          該生產任務單包含的信息為所要加工產品的數量級需求日期。APS的排產計劃模塊則會根據算法而得到工作中心的生產排單以及在制品的排隊序列。同時接受對車間活動的監測數據,實現對車間變化信息的動態反映。

          二、APS與ERP的區別

          ERP是依賴于MRP,主要基于無限物料、無限能力的理論,是通過缺料分析、能力分析、由人進行調整決定采取行動。APS的計劃是基于約束理論通過事先定義的約束規則,由計算機自動采取計算。另外,APS與ERP在計劃上也有許多關鍵的不同。

          總之,ERP在除生產計劃外的財務管理、成本管理、采購管理、銷售管理、庫存管理、人力資源管理等方面表現出了良好的管理效率和管理規范。而APS系統作為計劃系統能夠很好地規劃基于供應鏈的長、中、短期計劃系統,但是APS系統不能獨立運行,它需要大量的基礎數據的支撐才能良好地運行。

          三、APS能取代ERP系統嗎?

          APS不能取代ERP系統,ERP系統采用的計劃模型確實又不能滿足目前的需要,ERP的計劃模塊的改變同時將影響到整個系統結構的變化。因此,用APS來優化ERP生產計劃系統,既可以強化ERP的計劃功能,同時又不必影響到其他成熟的商業流程。

          四、APS計劃層次概覽

          理論上,APS系統層次日趨立體化和豐富化,目前大多數APS包括6個主要的模塊:供應鏈戰略模塊、供應鏈計劃模塊、需求計劃、制造計劃模塊、排程計劃模塊、運輸優化模塊。

          • 供應鏈戰略模塊用來支持戰略假設分析,確定生產地點、配送中心和其它實體的最優組合及選址方案,并對不同的成本和物料約束條件進行建模分析。
          • 供應鏈計劃模塊通過對物料、產能、運輸以及服務水平等的諸多約束對供應鏈進行建模和最優化分析,并制定出各流程的詳細計劃。
          • 需求計劃模塊:用統計工具、因果要素和層次分析等手段實現市場與客戶需求預測及管理。其關聯預測功能,甚至可以通過產品水平水平的預測推出各零部件的需求量,從而優化采購決策。
          • 制造計劃模塊:根據已有數據,與 ERP 的 MRP 通過制造訂單反復交互論證,得出將要生產排產的生產任務單。
          • 排程計劃模塊:考慮了生產中的產能、工序、物料及時間等約束條件制定出最優的生產計劃。
          • 運輸優化模塊可確定運輸模型以進行假設分析,并在約束條件下自動建立運載數量、發貨時間、運輸路線的安排。

          五、APS之車間計劃與排程計劃

          車間作業計劃的目標是通過對制造過程中車間層、車間層以下各層次物流的合理計劃,排程與控制,縮短產品的制造周期,減少在制品,降低庫存,提高生產資源的利用率,最終達到提高生產率的目的。

          從功能方面看,車間作業計劃層比物料需求計劃層有更具體的目標,那就是減少工件在制造系統中的“空閑時間”。

          據調查,在中小批量自動化制造系統中,工件在系統中的“通過時間”主要由4部分:加工準備時間、加工時間、排隊時間和運輸時間。其中加工時間只占整個通過時間的的5%左右,大部分時間消耗在排隊時間上,從而引起系統效益大衛降低。

          車間作業計劃層主要由生產作業計劃層、排程計劃層和生產活動控制層有機組成,其結構圖如下所示。其中生產作業計劃層是在戰術層下達的月、旬或周生產計劃的基礎上,根據各種生產資源的實時狀態數據,制定具體的生產作業計劃,該計劃將確定計劃期間內各種制造設施的具體使用狀況,每日/班的工件種類及數量等。

          排程計劃是在生產作業計劃的基礎上確定生產任務進行加工的順序,以及加工過程中各種制造資源的實時排程。上述的生產計劃于排程都只是為了運行層內物料的流動做出計劃,雖然在規劃時期系統能運行在最優或次優狀態,但實際系統運行中總會出現各種隨機的擾動,從而使系統是實際狀態與期望狀態之間產生偏差。

          所以,生產活動控制的目標就是應用反饋控制原理校正這種系統的偏差,使物料流動和系統資源利用等盡可能與生產計劃于排程計劃所期望狀況吻合。

          讓我們重點關注排程計劃層,它在車間作業計劃的三個層次中起到一個承上啟下的作用,具體來說,排程計劃就是針對一項可分解的工作如產品制造,探討在盡可能滿足約束條件如交貨期、工藝路線、資源情況的前提下,通過下達生產指令,安排其組成部分操作使用哪些資源、其加工時間及加工的先后順序,以獲得產品制造時間或成本的優化。

          車間排程計劃的重要性在于它保證生產計劃的有效實施,高效低耗低使用生產資源均衡生產,減少原料的加工準備、等待與傳送時間,縮短產品生產周期、確保產品交貨期,從而提高設備利用率與生產效率,同時,減少了在制品中的資金占用,降低了生產成本,使企業能更好地適應多變的市場需求。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼ben_lanlan,報下信息,會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          文章來源:人人都是產品經理  作者:山人小道 

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

           

          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合