OK. I misunderstood. Usually in security terminology “clear text” is used when you are talking about storing or transmitting data.

Have you looked into how browsers handles “text” input field vs. “password” input field? I think browsers automatically saves text field contents for autocomplete.

So if I entered a password in a normal text field it, if I let someone else use my browser for instance, they’d might see my password if my browser suggested it.

I think CC numbers are less sensitive than passwords. I give out my CC number all the time. When you hand your CC to someone at a restaurant or something they can see it. I think passwords are more sensitive. If someone uses my password maybe I don’t know about it. If someone abuses my CC it shows up in the CC statement and I can get my money back.

I’d prefer if the default for the input field was of the password type with stars/dots and then a “show password” checkbox if you know no one is looking at your screen and you are unsure about what keys you are pressing. I guess those dots/stars annoys me mostly when entering passwords on the iPhone.

We don’t STORE the password in clear text in our database! It’s just for when you create your password, not using the HTML password field type, to make entering your not-all-that-important password as easy to double-check as your credit card.

After all, have you ever seen a signup form that blanks out your CC numbers?

But it seems like a solution to a problem you don’t need to have. Why not just avoid sending passwords in cleartext? Ie. use SSL and store a hash or digest of the password in your database and not the password itself.

If the problem is that people don’t see it ahead of time, then it’s a matter of a design refinement to make it more visible as opposed to changing the entire approach. That’s valuable feedback and I have no problem with it.

And it’s very different than telling somebody they’re fucking crazy just because they bucked a trend. Which is what I wasn’t planning on putting in BIG BOLD CAPS at the top of the article. But that’s what people have said, expletives and all. Now that’s a calamity howler.

Honestly, the whole app takes a really different approach to most web-based software (and especially others in our field). As of now (because our interactive help system’s not yet online) it takes reading the guide to learn all the things you can do with the 3 input fields. Surely everyone would have less of a learning curve if it was all CRUDed up like a normal app. But does that mean we shouldn’t design the rest of the app that way?

I’ll refine it, but I won’t change the very basis assumptions the design is based on.

FWIW, I didn’t write this post to explain the signup form. I wrote it to explain my theory of positive selection.

I’d also argue against the perception that it’s really causing a problem. The feedback we’ve received regarding the clear text password is 3:1 positive. People have mentioned it positively in tweets and blog posts, intending to highlight the design for the world at large, not just directly to us.

There’s no way a single app can please everyone. I’m going to stick with pleasing the people who already predisposed to enjoying the kind of software I believe in designing.

I think this might be a pet peeve of your own as judging from the reaction stuff like that has thrown off and even frustrated some of your users. Not something you want to do right off the bat.

But – if you have to write a blog post to many of your users to explain a portion of your sign up form it’s not a good sign. I think you should hide the clear text and let people turn it off. That’s my opinion.

You have a good point and a good intention. But throwing people off base and doing something that confuses and/or possibly frustrates them is not a sound decision. It’s such a trivial thing and it’s causing problems why not just nix the problem in the butt and focus on continually improving the app itself?

Just my two cents.

This is just v1 and we’ll experiment with making it more obvious, but I’m not going to make it be a regular password field because of the above

Mislav, the sign in version of the password field is a regular password field, with bullets and all. What you’re describing is not a problem.

To me there is nothing wrong with experimentation and convention breaking, they are somewhat important, but being able to accept criticism and not be overly attached to design decisions is also great.

If you act like you always know beforehand what is best for your costumers and ditch honest feedback as “calamity howlers”, the decisions will tend to be treated as they are set in stone, which might compromise the product.

I pushed for a single password field when I worked at blurb.com and we never really had a problem with it. It makes the sign up form look less intimidating.