最近母校120周年校慶，各種活動，一直沒時間更新，今天終于有時間坐下來認真完成之前的內容了，接著我上次的內容，根據流程將功能點確定之后就需要考慮如何去一一完成。
首先，判斷功能點的位置，按照我之前的分類：一進入APP，用戶本身就有不同的訴求，已經在店里的看到二維碼要掃的；搜索去哪里玩的和人已經在商圈想找個確定的店吃飯的。
那么最開始的4個點就已經確定了，用戶打開APP就需要用到這幾個點：二維碼掃描，搜索功能，地圖檢索，APP內推薦以及優惠券。
在討論具體功能之前，個人覺得有一個大前提，就是這類型的APP是跟地理位置高度相關的，所以，在城市的自適應選擇上也應該是優先的，也就是說用戶第一次進入APP之后，APP提示是否使用當時用戶的地理位置以提供更準確的附近商店信息。之后每次打開監聽地理位置并在異常的情況下（所在地和選擇的所在地不一致）提示用戶是否更改地理位置。（因為用戶短期內的位移并不大，所以假設在進入APP到瀏覽完畢關閉APP，地理位置不變）
下面開始具體描述上述的幾個具體功能。
掃碼：使用場景相對單一，用戶到店看到吧臺的相應APP二維碼（提示用戶使用APP內嵌掃碼功能）——>打開APP，點擊掃碼功能。
這個功能本身相對簡單，具體流程如下，點擊掃碼按鈕——彈出是否可以訪問相機進行掃碼——調用相機程序并解析二維碼——返回結果
我增加了一個圖片反饋，讓用戶在誤觸的前提下將異常狀態糾正的體驗更友好（我覺得在使用場景的前提下，大部分用戶都會給予掃碼相機權限，所以我把誤觸或者沒有注意否定權限歸到異常）
搜索：設計搜索跟數據庫本身的設計有著密切的聯系，先不考慮這部分性能如何優化結果的問題。
首先我們先考慮具體的用戶行為，我個人將他們分為兩種：
1.喜歡自己輸入搜索內容后逐級篩選.
2.喜歡用定義好的備選項去挑選。
但我覺得不論這兩種行為，都可以將搜索內容本身固化成對應維度的值同時返回結果，舉個例子，我在搜索框內輸入鐘樓，點擊搜索后，結果返回搜索的內容，同時清空搜索框并把鐘樓固化到位置維度里。（我個人的想法是，因為維度取值本身就是確定的，那么，搜索的內容去遍歷維度取值，有相同值就返回，沒有就不固化，異常值就不考慮固化，搜索本身是需要首字母比對加快速率，同時需要二次確認文字）
之后考慮下具體的邏輯步驟，首先，一般的想法是，用戶使用搜索功能是在他確定了一個大概范圍的前提下他才會使用這個功能，但是，我認為還有另一種可能就是他認為搜索可以解決他的需求（具體需要數據做支撐，用戶在非常模糊的目標下所填寫的搜索內容是一個籠統的范圍），所以，我的想法是，在搜索框添加焦點事件，當搜索框獲得焦點時，轉換成一個展示以下幾個維度的頁面（一個娛樂項目的幾個屬性分別是：類別本身，地理位置，性價比，人氣，評分），用戶面對這個頁面的行為也分為兩類1.無視篩選直接輸入搜索內容，2篩選一部分籠統的類別地點信息后直接點擊搜索。
第一種情況就用我之前描述的行為解決方案，根據他搜索的內容直接固化成維度值。但是，手動輸入有一個很重要的問題，就是用戶會不會自主考慮篩選的關系，也就是說他搜索的內容是不是以層級逐層遞進的，對這個問題，我的直覺是，不可能，因為太難了。那么，對于交互本身，我們需要判斷的是當前搜索的細化內容跟之前的細化內容是否是包含關系，比如，優先搜索地點，之后品類，這就存在包含關系，但是還存在，先搜索火鍋，后搜索燒烤，這就是同一維度的不同類別，需要做判斷來分辨是否需要遞進，或者重新在原有搜索內容前提 下更改某一個類別的取值。
第二種情況就需要考慮維度本身的值如何定義，類別來看，吃和玩本身就大不同，分類做遞進效果更好（其他類目暫時不討論，邏輯上也一致，把所有業務覆蓋的點歸類，可以合并的歸成父類，然后點擊展示具體子類，樹形結構），舉個例子，火鍋跟燒烤就應該劃歸在美食這個父類別下，密室逃脫就放在消遣娛樂這類父類下。之后的問題就變成了，子類是否應該支持多選，我個人不覺得多選是一個好點子，雖然這么做很符合理性假設，但是，大部分人并不習慣去遍歷全部后挑選，或者說他們不考慮自己所可能做的全部活動，之后全部篩選，而是選擇一個，發現選的不好，再換一個，這個邏輯更符合實際（當然，需要數據進一步驗證），但是體驗上需要最后一步頁面的保留，也就是說，用戶選擇某一個子類之后，看了一圈發現沒有自己想要的，他點擊同樣篩選位置應該返回的是跟這個子類同級別的菜單欄，而不是從頭來過，比如，美食父類的火鍋子類，用戶沒有滿意的火鍋美食，他就會想說有沒有燒烤，那么點擊類別篩選的時候應該在父類項已經選中美食，同時子類選中火鍋。（當然，你也可以認為用戶想去玩了，這個邏輯相比我的邏輯更需要數據的證明，不是么）
現在討論下位置這個維度，對于位置來說，地標是不是優于政府劃分的行政區域本身（對于用戶來說，他們只能通過他們知道的地點或者地標來搜索，對于現在的二級遞進設置，我以個人的經歷為例，找了半天小寨，不知道小寨在哪個區....最后就是一個個試，后來反應過來，試了試直接搜索小寨，結果還挺好的，但是我們做交互的時候為什么不能直接在篩選欄的上面置頂的提示一下用戶，“找不到想要的地標？試試直接搜索吧”效果應該會更好，你說呢
至于好評，客單價，距離，人氣，開店時間，這類型的篩選，選擇按什么排序即可，額外說下好評，評價這個東西，我個人還是覺得是不是可以防止刷單，對有圖片的好評單獨列出來，同時，刷單需要的獨立IP，同時，刷單人并不會真正到店體驗，而是通過網絡傳播圖片，所以圖片的雷同性很高，針對這個，可以通過數字圖像處理做反刷單算法，同時恢復真實好評的占比。
考慮完維度的如何取值定義，流程圖如下：
第三個主要功能，地圖檢索，這作為一個獨立的功能有他特有的使用場景，日常吃飯，飯后就近的娛樂需求，這類型需求對地點的要求相對苛刻，所以以地圖展示更符合交互結果（個人觀點，需要運營數據驗證），一般人走路10-20分鐘也就600-1200米的半徑，地圖本身比例尺應該以這個為界限，（按照30分鐘，2公里計算，展示給用戶的也是徒步的時間而不是距離，這個我上一篇文章已經提到了，大部分人對時間的概念性大于距離，展示給他們時間更優于距離，至少我是這么認為的），方向確定了，那么開始解決實際展示的邏輯，首先，用戶點擊入口按鈕，之后顯示一個以4公里為直徑的圓并幾乎沾滿整個屏幕，當然，這個根據具體地圖設計定，但是最好的結果是4公里，同時標注主要周圍的商圈，同時地圖最上角顯示篩選的維度，這里的維度就僅僅只有類別跟如何排序，因為距離已經是一個限定條件，就不需要再篩選了，同時,頁面所最大能顯示的數量需要跟美工討論下，對這個的分析我并不是很在行....就不亂給意見了，設置好分辨率本身所對應的頁面展示數量，就開始嘗試展示搜索結果，結果以所在的地理位置對應的圖標展示，但是這樣就有一個問題，沒有辦法對圖標進行排序，這個方面我的想法是，排序的展示方式以圖標顏色的深淺區分，（現在的評分體系一般是5分，那就把顏色基本分成5個標志性顏色，展示出來），綠色以深色為高，紅色以淺色為高，具體需要跟美工人員商議，畢竟我只是個外行=。=
流程如下：
最后一個功能APP推薦：乍一看這個功能的名稱無法理解他到底想描述什么，我對這個板塊的定位是，以運營為核心，我上篇文章提到了，人們打開這類APP的具體需求基本已經大概確定了，有到店想要查看有沒有團購的，有打算在某個時間段出去玩的，有對地點要求特別高的，還有的就是，女性類通用需求：是否打折？是否新奇？是否有活動？（把他們歸于女性需求雖然有些偏激，但是這類需求的典型代表確實是追求新鮮感跟貪便宜的妹子群體~），同時這些也是刺激消費的重要一環，消費類需求的定義不應只是局限在用戶已經想要什么，而是基于盡力讓他們發現有很多東西適合他們，同時推銷給他們，就如同很多商場的促銷打折活動，他們的目標并不只是這一個商品，而是吸引你進店然后推銷給你更多的產品，在這個方面，推薦大家一本書昂德希爾的《[顧客為什么購買》，閑話撤完，開始聊正事，這個功能我對他的定義是一系列板塊，比如上一篇所描述的，用戶有小團體，情侶，家庭聚會各種不同的需求，那么針對某一個時間點對一個類別進行活動促銷是一個很好的方式（為什么不單獨列出來團建，我個人覺得，消費者跟付款者的不一致，導致這些人對于團購本身沒有太大的興趣，更多的是嘗試更貴的或者更高大上的店，畢竟，一個月才一次，還是公司掏錢，當然就~~嘿嘿~~不過，團購也可以針對這點做一些高大上的團單，滿足這些人的需求），同時，打折促銷是也是一個不錯的細分類別，當然，具體的哪些在哪段時間可以優先做活動還是由數據決定的，比如，在年底，家庭聚會普遍，那么就可以單獨拉出來做活動，周末的情侶出游，就可以試圖做一些促銷活動等等，至于交互，用戶點擊相應活動頁，彈出頁面頂上應該有分欄作為提示，目的是在下拉的過程中讓用戶清楚知道自己所在的位置和還有多少類目，做一提示，同時，分欄也有篩選的作用，或者說直接在數據庫所對應的商品表增加一欄，目的是記錄當前所有的商品狀態（正價，打折，XX活動等），直接使用搜索結果即可。說到這里，我覺得搜索功能是否可以改善一下，增加一個類目是活動項，顯示的結果是不同產品正在進行促銷或者根據當前各種活動的不同來做篩選，是不是更好呢。
同時，既然是刺激消費，應該還有一個需求是優惠券，這個更多的邏輯應該是產品需求，目的就是刺激消費，所以邏輯上應該是越易用越好，否則，如果出現，選了半天，發現券不能用（有些店的商品是不能使用券的，但是并沒有任何提示），我觀察過我幾個同學在這一步的反映，直接關閉糯米，大概2.3次之后就卸載了..優惠券成了一個搬石砸腳的行為，很奇怪他們的設計人員是如何想的，不好用的看似有利于消費者的行為都會讓他們覺得你是騙子，這樣的結果往往還不如不做。批判完了，考慮交互行為，最原始的優惠券的整個流程應該是，首先，在店面附近發給你一張優惠券，強調在哪個或者哪些店里可以使用，使用的前提是什么，那些不包含在優惠范圍內，之后，用戶判斷是否需要去消費，同理，APP內的優惠券也可以應延用這個邏輯，首先，領取券后在搜索欄可篩選出使用的優惠券的店鋪和商品，然后之后的流程跟搜索本身一致。
