1

I'm currently designing a mini-application which displays user info (such as unread private messages, profile views, etc.) for a website which requires users to log in. Thus, naturally, the mini-app itself needs a username and password in order to do anything useful.

The username and password fields and other configuration options are stowed away in an initially hidden view, so as to leave the main "user information" view uncluttered. When the app is first displayed, it has no associated username or password, so it needs to ask for them somehow. My question is: should the interface...

  1. automatically expose the username and password fields when it detects that it doesn't have any login info, or...

  2. show its default view, but overlay a message recommending that the user log in (perhaps with an indicator highlighting the button which displays the login panel)?

Mini-apps of this type (namely, OS X Dashboard widgets) don't customarily show their configuration panels on their own, but wait until the user switches to that view voluntarily, so I think there's a risk of interrupting the user's expected workflow. On the other hand, this particular mini-app isn't much use to them until they do log in, so the first option may ultimately be more convenient — if they don't mind the interruption.

Improve this question
3
  • 2
    It seems you're question is currently structured around a specific interaction, whereas I believe the actual question is more of a: "should I display the sign-in fields by default to logged-out users, or should I provide them with a message telling them to 'click here to sign in' that then takes them to the sign-in screen", is this correct? This concept isn't exclusive to OS-X so it doesn't need to be focused on a specific OS. – JonW♦ May 3 '12 at 11:05
  • Good point! I was pretty focused in on my current project, but you're right, that choice could apply to just about any application or website that requires a login. – Evenio May 4 '12 at 11:05
  • In that case you may get more responses here if you edit your question to be more general. You can then use that information to apply to your specific use-case. – JonW♦ May 4 '12 at 11:36
2

Assuming there's no helpful or important information to display in a non logged in state, I'd definitely expose the login without additional user interactions.

In the scenario you described you're saving a step for the user by presenting the password fields by default.

A related thought: you might consider displaying some type of "teaser" information on the widget in its non logged in state, to give the user a sense for what they'll get/see by registering and logging in.

Improve this answer
0

this particular mini-app isn't much use to them until they do log in

if this is the case, how can there be a workflow to interrupt.

interrupting the user's expected workflow

For example, if the app is mail-app, how there can be a workflow without logging in?

The app should clearly notify the user that he/she is not logged in. And he should be proceed to the login form/page/window/activity "without much ado".

But, in case this app is like news app, or instagram where user can browse staffs without logging then the "teaser"-like notification (as Mike suggested) is enough to notify user that he is NOT getting his personalized flow.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.