您现在的位置是:Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款 > 

06 facebook退出登錄在哪里(登錄移動wlan如何退出)

Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款2024-05-27 05:00:59【】2人已围观

简介你們產品。你應該幫助用戶高效地完成登錄任務。你所設計的反饋應該解釋清楚哪一個不能正確匹配:密碼還是郵箱。下面是個正面示例。在Mailchimp中,如果你輸入的用戶名不存在,他們甚至會在你嘗試重新輸入密

你們產品。

你應該幫助用戶高效地完成登錄任務。你所設計的反饋應該解釋清楚哪一個不能正確匹配:密碼還是郵箱。

下面是個正面示例。在Mailchimp中,如果你輸入的用戶名不存在,他們甚至會在你嘗試重新輸入密碼之前告訴你。檢測到問題,并會提供鏈接幫助用戶解決問題。

Quora網站的QA也采用了類似的方法。如果沒有賬戶與用戶所輸入的電子郵件地址相匹配,Quora的登錄表單就會提示你,同時提供給用戶立即創建新賬戶的選項。

Quora會告訴你如果沒有賬戶和你輸入的電子郵件地址匹配

但是,這種方案有一個較大的弊端:第三方可能會知道某個特定的電子郵件地址、人、姓名在網站或APP上注冊過了。這個時候,設計師就需要幫助用戶減輕疑慮,并且考慮使用環境。例如,不建議在網上銀行(安全原因)或者用戶比較擔心他們的會員身份(隱私原因)的服務中使用這種設計方案。

從可用性的角度來看,你幫助了用戶從無數用戶名中找到在你的產品中使用的那個,盡快完成了登錄。是否要采用這種方案,最終取決于你。

提醒用戶他們更換了密碼

用戶已經習慣輸入舊密碼,他們可能會忘記已經更改過密碼了。當他們收到“密碼錯誤”的提示時,他們往往會認為自己只是打錯了字母或數字。

在這種情況下,用戶需要的是提醒他們密碼已經更改過。最好告訴用戶他們多久之前更改過密碼,而不是給出讓人誤解的提示信息。此類提示信息只有當用戶輸入舊密碼的時候才出現。如果用戶是輸錯密碼,系統應該提示“密碼錯誤”這樣的信息。

舉個例子,如果用戶更改了Google賬戶的密碼之后嘗試使用舊密碼登錄,Google會顯示一條特殊的信息:“您的密碼在X天前更改過”。

解決多賬號登錄問題

當面對多個登錄選項時(例如,通過Facebook,Twitter或Google+登錄),用戶可能會忘記他們之前用來注冊的服務是哪一個,會猶豫該選擇哪個登錄方式或者干脆放棄登錄。更糟糕的是,如果用戶選擇了錯誤的登錄服務提供商,而不是他們曾經注冊的服務,他們可能會再次注冊,從而創建了第二個賬戶。

雖然網站和APP會盡力去匹配來自不同服務提供商的賬戶,但是不能100%保證Twitter和Facebook賬戶是否屬于同一個人。所以,為了解決多賬號登錄問題,你應該保持用戶的登錄狀態直到他們主動選擇登出。需要登錄的用戶越少,登錄問題就越少。

另一個好的解決方案就是記住用戶。Quora在用戶重新登錄時,不需要用戶輸入密碼。用戶只需要點擊他的個人資料圖片或者用戶名,就可以登錄進網站。

設計“忘記密碼”流程

和人們有時候會忘了把錢包或鑰匙放在哪里一樣,用戶會忘記密碼。因此,登錄過程需要很好地處理這種情況。登錄表單中需要提供“忘記密碼”的入口讓用戶重置密碼。

不要僅在用戶點擊密碼輸入區域或者輸入了錯誤的密碼之后才出現“忘記密碼”入口。當用戶已經輸入電子郵件地址,然后使用“忘記密碼”功能,不要讓用戶在“忘記密碼”頁面重新輸入他們的電子郵件地址。不要通過電子郵件發送當前或者臨時密碼。

正確的做法是向用戶注冊的電子郵件地址發送重置密碼鏈接。此外,確保重置密碼的郵件盡快發送給用戶。(如果用戶不得不等很長時間才能收到重置密碼鏈接,他們會感覺沮喪和不耐煩)

如果用戶不能訪問他們注冊的郵箱,那么接下來能做的取決于你提供的服務類型:你可以前置一些安全問題,以此作為登錄憑證。總的來說,如果用戶忘記了密碼,讓“忘記密碼”的流程簡單點。

在鎖定賬戶之前告知用戶

為了防止暴力攻擊,用戶的賬戶通常會在多次登錄失敗后被暫時鎖定。這當然是一個必要的安全措施,但是一定要在鎖定賬戶前告知用戶。

Mailchimp在用戶第3次登錄失敗后,會告知用他們的賬戶再有9次登錄失敗后會被鎖定30分鐘。

總結

即使已經是很常見的網頁和APP的登錄功能,也可以通過巧思和設計來進行優化。但是,不要把這些解決方案當成救星,用來處理各種錯誤情況。最好的解決方案是,設計你的用戶界面和交互方式來避免錯誤的發生。

Medium

譯文地址:紫豆子設計站(買粉絲)

Android中判斷app何時啟動和關閉的技術研究

Android開發中不可避免的會遇到需要檢查app何時進入前臺,何時被用戶關閉。奇怪的是,要達到這個目的并不容易。檢查app第一次啟動并不難,但要判斷它何時重新打開和關閉就沒有那么簡單了。

這篇文章將介紹一種判斷app打開,重新打開和關閉的技術。

讓我們開始吧

判斷一個app打開和關閉的關鍵在于判斷它的activities是否正在前臺顯示。讓我們先從簡單的例子開始,一個只有一個activity的app,而且不支持水平模式。這樣想要判斷app是打開還是關閉只需要檢查activity的onStart和onStop方法即可:

[Java] 純文本查看 復制代碼

@Override

protected void onStart() {

super.onStart();

// The Application has been opened!

}

@Override

protected void onStop() {

super.onStop();

// The Application has been closed!

}

上面例子的問題在于當需要支持水平模式時該方法就失效了。當我們旋轉設備時activity將會重建,onStart方法將被再次調用,這時將會錯誤的判斷為app第二次被打開。

為了處理設備旋轉的情況,我們需要增加一個校驗步驟。當activity退出時啟動一個定時器,用于判斷短時間內app的這個activity是否又被啟動,如果沒有,說明用戶真的退出了這個app,如果重新啟動了這個activity,說明用戶還逗留在這個app中。

這種校驗方式也適用于擁有多個activities的app,因為從app的一個activity跳轉到另一個activity也可以用這種校驗方式來處理。

使用這個技術我創建了一個管理類,所有的activities在可見和不可見時都會通知這個管理類。這個管理類為每個activity處理上述的校驗步驟,從而避免錯誤的檢測。它也提供了發布訂閱(觀察者)模式,任何對app啟動和關閉感興趣的模塊都可以通過它來得到對應的通知。

這個管理類的使用分為三個步驟:

1)把它添加到你的工程中

2)Activities在可見性改變的需要發送通知

app中所有activities都要增加下面的代碼,用于可見性改變時通知管理類。最好的實現方式是把這段代碼加到工程的BaseActivity中。

[Java] 純文本查看 復制代碼

@Override

protected void onStart() {

super.onStart();

AppForegroundStateManager.getInstance().onActivityVisible(this);

}

@Override

protected void onStop() {

AppForegroundStateManager.getInstance().onActivityNotVisible(this);

super.onStop();

}

3)訂閱app的前臺可見性改變事件

在感興趣的模塊中訂閱app前臺可見性改變事件,application類的onCreate函數是一個不錯的地方,它可以保證每次app啟動和關閉,你都能得到通知。

public class MyApplication extends Application {

@Override

public void onCreate() {

super.onCreate();

AppForegroundStateManager.getInstance().addListener(this);

}

@Override

public void onAppForegroundStateChange(AppForegroundStateManager.AppForegroundState newState) {

if (AppForegroundStateManager.AppForegroundState.IN_FOREGROUND == newState) {

// App just entered the foreground. Do something here!

} else {

// App just entered the background. Do something here!

}

}

}

進一步的思考

有一些細節需要進一步討論,下面討論的幾點針對具體的應用可以做微調。

校驗時間

校驗定時器檢查app是否真的進入后臺的時間間隔是多少合適呢?上面的代碼設置為30秒,原因如下。

當你的app在運行時,可能存在第三方的activities會覆蓋全屏幕,一些常見的例子是Google應用內購買和Facebook登錄注冊頁面。這些情況下你的app都會被迫進入后臺,前臺用于顯示這些第三方頁面。如果把這種情況當做用戶離開了你的app,顯然是不對的。30秒超時設置就是用來避免這種情況的。例如當用戶在30秒內完成應用內購買,大部分用戶都可以做得到,那么就不會當做用戶突然離開app了。

如果你的app不存在上述這種情況,我建議可以把你的校驗時間設置為4秒,這樣對于低配設備當屏幕旋轉重新創建activity的時間間隔是合適的。

CPU休眠

可能存在的問題是當用戶關閉app或者app仍處于前臺時用戶鎖屏了,這時CPU可能不會等到定時器檢測就休眠了。為了保證這種情況下定時器能夠正常檢測用戶退出app,我們需要持有wakelock防止CPU休眠直到app關閉事件被確認。實踐中相比使用wakelock,這種情況并不算問題。

判斷app是如何啟動的

現在我們已經知道如何檢測app何時啟動和關閉,但我們不知道app是如何啟動的。是用戶點擊通知欄消息?還是點擊一個鏈接?亦或是他們直接通過桌面圖標或最近使用啟動?

跟蹤啟動機制

首先我們需要知道在哪里檢測app是如何啟動的。基于前面一個例子我們可以打印出app何時啟動,以及如何啟動。

public class MyApplication extends Application {

很赞哦!(68)

Instagram刷粉絲, Ins買粉絲自助下單平台, Ins買贊網站可微信支付寶付款的名片

职业:程序员,设计师

现居:吉林吉林昌邑区

工作室:小组

Email:[email protected]