305
iOS中注冊功能的體驗探究
通常，移動App的注冊功能通常采用手機號碼注冊或者郵箱帳號注冊。
不過在國內這樣隱私堪憂的環境下，需要手機號來注冊會流失不少用戶。即便是新浪微博這樣的應用，需要綁定手機號也令我不信任。除非是像淘寶、支付寶這樣需要手機號來提高安全等級的服務，才能弱化用戶的心理障礙。
首先，看下手機號碼注冊。
（注冊湖畔）
對於手機號碼輸入框，我們當然要默認使用UIKeyboardTypeNumberPad類型鍵盤。不過對於越獄用戶，如果裝了其它輸入法，則有可能使用其它類型鍵盤輸入非數字字符。對此，我們在客戶端最好進行過濾和檢查。因為客戶端如果發送了包含非數字字符的電話號碼給服務端進行校驗，是沒有意義且浪費流量的。
在用戶的輸入過程中，我們可以通過代理方法來判斷輸入是否合法，從而進一步決定是否接受輸入。
下麵是示例代碼片段：
- (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string
{
return [ValidationHelper validateNumeric:string];
}
...
+ (BOOL)validateNumeric:(NSString *)str2validate
{
NSCharacterSet *charSet = [[NSCharacterSet characterSetWithCharactersInString:@"0123456789"] invertedSet];
NSRange range = [str2validate rangeOfCharacterFromSet:charSet];
return (range.location == NSNotFound) ? YES : NO;
}
上麵隻是部分代碼示例，比如還缺少判斷是否為退格鍵、對輸入框長度進行限製。
同時，為了對用戶更友好，我們可以對電話號碼進行格式化。比如采用類似+86 137-5555-6666的格式，或者省略+86。這樣可以讓用戶在輸入過程中清楚地知道自己輸入了多少位數字、輸入了哪些數字，不至於擔心輸錯號碼或者多一位、少一位。從這個角度看，對輸入框長度進行一定限製，也是對用戶稍微友好的。
對於獲取驗證碼，這裏是由客戶端來做頻率限製。此處有一個細節：當點擊“獲取驗證碼”按鈕後，焦點應該放在驗證碼輸入框，因為用戶的下一步動作就是輸入驗證碼。我個人比較注意這樣的細節，比如瀏覽器新開一個tab，焦點是否放在地址欄；比如我在群裏點擊搜索按鈕要搜索群用戶，搜索框是否處於激活狀態供用戶輸入。這些都是為用戶，或者說作為用戶，考慮的細節體驗。我給阿裏旺旺和淘寶瀏覽器提過這方麵的建議。
除了在用戶輸入過程中對非法字符進行過濾，提交給服務端時也要再檢查一次。
用戶的任何輸入都是不可信的數據，同樣地，服務端對於客戶端提交的任何數據也要再檢查一次，不管客戶端是否已經檢查過。
比如在提交時，至少要檢查下驗證碼是否為空。如果為空，要不要彈窗呢？我覺得沒有必要用UIAlertView來給用戶提示，有點重！在這裏，我采用的是抖動提示，用戶一看就明了。
//TextField的晃動:Begin
@interface UITextField(shake)
- (void)shake;
@end
@implementation UITextField(shake)
- (void)shake
{
CAKeyframeAnimation *animationKey = [CAKeyframeAnimationanimationWithKeyPath:@"position"];
[animationKey setDuration:0.5f];
NSArray *array = [[NSArrayalloc] initWithObjects:
[NSValuevalueWithCGPoint:CGPointMake(self.center.x, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x-5, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x+5, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x-5, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x+5, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x-5, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x+5, self.center.y)],
[NSValuevalueWithCGPoint:CGPointMake(self.center.x, self.center.y)],
nil];
[animationKey setValues:array];
[array release];
NSArray *times = [[NSArrayalloc] initWithObjects:
[NSNumbernumberWithFloat:0.1f],
[NSNumbernumberWithFloat:0.2f],
[NSNumbernumberWithFloat:0.3f],
[NSNumbernumberWithFloat:0.4f],
[NSNumbernumberWithFloat:0.5f],
[NSNumbernumberWithFloat:0.6f],
[NSNumbernumberWithFloat:0.7f],
[NSNumbernumberWithFloat:0.8f],
[NSNumbernumberWithFloat:0.9f],
[NSNumbernumberWithFloat:1.0f],
nil];
[animationKey setKeyTimes:times];
[times release];
[self.layeraddAnimation:animationKey forKey:@"TextFieldShake"];
}
@end
//TextField的晃動:End
上述代碼來源於互聯網，應該是StackOverflow吧？忘記了。
（注冊微信）
上麵討論到通過客戶端來對驗證碼請求頻率做限製，除此之外，還可以通過服務端來做限製。
微信應該就是通過服務端來做限製的，因為我殺掉進程等了好久，然後重新嚐試注冊，還一直提示我“發送請求太快，稍後再試”，嚐試了好幾次都是這樣的提示，感覺體驗不好。我Google了一下這個提示，發現有不少用戶有相同困惑。
Server端永遠不要信任Client端（包括Browser）的數據。但如微信這樣的產品，在注冊獲取驗證碼環節上，對交互的把握，仍然會讓用戶覺得不爽。
所以，在驗證碼獲取上，我個人傾向客戶端控製或者C/S結合。因為至少客戶端控製可以讓用戶有個心理預期，比如60秒的時間。而像微信這樣，我根本不知道“休息一下”是休息多久！我嚐試了1分鍾、5分鍾甚至10分鍾後再次操作過，還是遇到這個提示。
除此之外，還有一些我個人認為的不足之處：
- 手機號碼沒有做長度限製。或許各個國家號碼長度不一，但如上圖，未免也太長了吧？而且微信的大多數用戶都來自大陸，完全可以為“+86”的用戶做下體驗優化。我認為服務了80%用戶的功能是十分有價值的。
- 驗證碼長度沒有限製。如果說電話號碼長度不可控，那麼驗證碼的長度應該是可控的吧？這個“休息一下，稍後再試”的提示在獲取驗證碼時會有，再校驗驗證碼時也會有！有點煩。如果說控製獲取驗證碼頻率可以節約短信費用，那麼校驗驗證碼的頻率控製又是為何？
- 驗證碼連基本判空都沒有。我沒有輸入驗證碼，直接點擊下一步，得到如上“驗證碼不正確”的彈窗提示。如果說發生了服務端驗證，那不應該把空串交給服務端驗證；如果說客戶端驗證通不過，那提示有點冗餘，而且不精準。
（短信注冊新浪微博）
如果說控製驗證碼發送頻率是節能環保省錢的考慮，那麼新浪微博直接把這個問題交給用戶了。
說實話，當我看到這個webview加載出來的內容時，一股有關部門氣息迎麵撲來。什麼時候，在（大陸）互聯網應用上注冊帳號還要花錢了？雖然隻是一毛錢短信費用。但就這一毛錢，也可以感受到新浪微博並沒有足夠為用戶考慮。（當然，這裏要強調下，應該支持正版，要有消費服務的意識。插曲。)
尤其是，這個接收號碼還這麼長，足足12位！
就不多吐槽了。
--------------------------------------------------
再看看郵箱帳號注冊。
（注冊湖畔）
郵箱注冊過程中可關注的兩個基本點是：
- 鍵盤應設置為UIKeyboardTypeEmailAddress類型。
- 對郵箱格式進行檢查。
下麵是一段檢查郵箱的示例代碼：
+ (BOOL)validateEmail:(NSString *)str2validate
{
NSString *emailRegex = @"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}";
NSPredicate *emailPredicate = [NSPredicatepredicateWithFormat:@"SELF MATCHES %@", emailRegex];
return [emailPredicate evaluateWithObject:str2validate];
}
（注冊知乎）
我在之前說過知乎的登錄模塊在剛開始的時候也沒有為郵箱輸入框設置UIKeyboardTypeEmailAddress類型鍵盤，從注冊界麵我們也可以發現知乎改了登錄界麵，不過漏了這裏。
或者，是故意地？
那麼，不妨再比較一下默認中文鍵盤和郵箱鍵盤，仍然可以發現在這個注冊流程中，還是郵箱鍵盤更方便。
（注冊新浪微博）
新浪微博的郵箱注冊界麵仍然是一個webview，並且從加載出來的頁麵仍然可以感受到：新浪微博並不怎麼為用戶考慮！
為什麼？
先不說那張驗證碼，就看下麵兩點：
- 需要用戶點擊按鈕來發送激活郵件。當用戶注冊成功了為什麼不自動發激活郵件呢？這讓我想起前幾天我第一次在萬達官網上買電影票的經曆，我輸入了打折卡號和密碼，網頁上已經顯示出折扣價了，於是我就繼續支付，結果沒有打折！！！因為我沒有點擊折扣價附近的“使用”按鈕。那時候折扣價是紅色字體突出的，吸引了我的注意力，而且我以前在其它網站買電影票都很順利，有點大意。不過，如果真心為用戶考慮，折扣價都已經算出來了，說明打折卡有效，為什麼不默認使用呢！？事後，我打了好多個電話要投訴，都沒人接。幸虧那次隻能省10塊錢。
- 需要查收激活郵件進行激活，才能登錄。這點簡直沒有點移動App的意識嘛！我用手機注冊，你還要我去郵箱查收激活郵件！？且不說你這是不是把手機當PC，就這注冊流程，完全被一封激活郵件打斷了！
簡短吐槽。結束。
--------------------------------------------------
Jason Lee @ Hangzhou
最後更新：2017-04-02 16:48:08