We've been having a discussion in the office surrounding a login page we're developing for a new web application. The web application is in intranet-based application, and is mainly used by users who have to use telnet applications as 80% of the daily job.
I created the initial page design in Photoshop, which we discussed and all approved. However, now I've given it over to one of the other developers to start building, he has noticed that there was no login (or other) button on the page - it's simply has two fields; one for username and the other for password. After querying it with me, I stated that it was intentional, as I didn't see the need - most people would just press enter anyway, as that's what they have to do in their telnet application. Then the discussion started...
There were several points made in-so-far as "if there's no button, they won't know what to do" and "they will expect the button and will raise support calls over the page not working". There were even suggestions that the users would just "sit there" not knowing what to do.
Now.. my question is: Do users really need a login button?
I'm genuinely interested to learn what sort of percentage of end-users would be able to cope with a simple login page that required them to press enter after entering their details to continue. It's important to note, there wouldn't be any on-screen prompt to press enter - they would see a tool tip over the password stating what to do, but that's it!
(Exclude mobile users from the fray - simply targeting run-of-the-mill desktops and laptop users :))
An example of the login box:
Answer
Ultimately it's probably not a good idea to go down this path without serious testing because of user expectation based around existing conventions.
That's an important point, because what I'm taking away from your description is that this is currently untested and you designed this UI under the assumption that your users would understand. This is generally a bad idea: always get feedback from your audience, especially when you're trying something new, and especially in a core area like login.
Your telnet argument is something to take into consideration, but also understand that you're building a web app here and you're likely going to be dealing with user expectation of web apps, not telnet. Your brain shifts between contexts: when you use a web app, you expect to single-click on items to follow them, whereas in desktop apps, you might expect to doubleclick. Recognising the mental model that users have when they're using your web app as opposed to a different space like telnet is an important aspect of designing a user interface.
There are some patterns emerging that are starting to diverge a bit from the standard "log in or sign up" convention, however. Each of these faces the same challenges: what do users expect and how do you build trust, expectation and discoverability around some of these new ideas? For instance, StackExchange employs single sign on, which can be confusing for users who aren't familiar with that pattern. Amazon (successfully) integrates registration and login into one form, although it remains to be seen how effective that pattern would be on other sites.
The point is, when you break convention, you're heading into unfamiliar territory and you need to realise the effect that can have on people. If you're thinking about doing this, I'd recommend grabbing some "run of the mill desktop and laptop users" from your immediate environment (say, the office manager and someone from the office across the road) and asking them to log in. You'll learn a lot. You might learn that your initial assumption was correct. But at least you'll have the data to prove it, instead of just the assumption. :-)
Edit: As you mentioned in a comment in an answer to your question on Programmers, "questioning the validity of the convention" is a good starting point, but you should make sure your answer to that question is founded in data. Anyone can question conventions, but conventions have become conventions for a reason: they're effective solutions to the problem. Moving away from those without good reason (and good reason in the UI world means having data or some form of metrics) will usually do more harm than good.
No comments:
Post a Comment