There is some really weird advice in that article.
Hey Accountname! Thanks for registering on http://site.com ( Site world )
Your account is Accountname and the IP address this was created from was 2.3.4.5 on 11/10/2013 12:35 ETA. The link to your profile is here : http://site.com/profile/accountname
If you did not create this account, you can deactivate it by clicking here
Not all startups are aimed at techies, and my mum would be scared and more than a little put off by that.
When you run a high traffic site that deals with hundreds of support tickets a day, you figure out ways to solve them before they start.
The email above solves the following problems:
1: Many users forget their account name and search their inbox for site name, sitename.com or their account name. Displaying those prominently lets them easily find this email.
2: Accounts get created on other peoples email /constantly/ and we had tons of requests a day asking to delete the account or to get more information. Having the link to delete it saves us the time of having to field this request. Same thing with the profile and IP address.
You can look at the profile link and be "Oh, thats my kid- Must have used my email for some reason" - When no profile is present, the IP also solves this issue.
It doesn't seem apparent at first, but when users complain about this in large amounts, you realize its worth solving.
Regarding point 1, my favourite solution to the problem of users forgetting the account name is to use the email address to log in, rather than forcing the user to make up an account name. Are there any reasons for not doing that?
I have my own mailserver and add a different random number to my email address each time I give out my email, so if I get spammed I can blackhole that address, determine the responsible party and complain to them.
If a site makes me login with an email address, I usually have to copy-paste the address because I don't have the patience to memorize dozens of random numbers, many of which I rarely use.
Yes! And then they continue redirecting me even when I retype .com a few seconds later! Google is a big offender - when I travel, I want .com, not whatever country I'm in.
While I agree with most of those, how many of the points are just a matter of author's preference? Is there any data behind it?
> Important step here: Once I type the new password and click “OK” you automatically log me in. I don’t have to go log back in again.
I actually prefer to have a chance to log in using my new password so that I can save it in the browser. If it logs me in automatically, I need to log out, and log back in. Or worse, I forget to save the password and have to do the whole reset password dance again next time.
You can save the password from that form just as easily. Its just a matter of the webmaster labeling the field correctly so your browser recognizes it as a login form.
There's a major problem with this: privacy. The password process needs to prevent against discovering that someone else has an account. The way to do this is to respond exactly the same way whether the account exists or not. Less user friendly, yes.
I used to say the same, and was a staunch advocate of that. However, it was pointed out to me that virtually every. single. website. that does this still leaks that self-same info during registration: i.e. what do you do on your site to prevent "existing account discovery" when someone tries to sign up with an email address that one of your users already has?
I presume authentication (at least currently) is not an important issue for unsubscribing. For example, bad people are not unsubscribing users from their competition as yet...
How about stop sending me marketing crap when I sign up for something. Much better solution.
My biggest bugbear is actually Atlassian JIRA where when you upgrade/install it, it tells Atlassian to SPAM you so every damn time. You have to then click through to unsubscribe. Even though you just gave them $20,000 in license fees.
I can only recommend getting in contact with Atlassian wrt. your problems. I've contacted them twice about errors on their pages and I've gotten great service both times.
I regularly send out emails when something is amiss, and getting a proper response AND getting the problem fixed is rare. Sadly.
We have contacted Atlassian support many times and they have been great. The real problem is that the defects we raise shouldn't exist. They are just crap engineering problems. The result every time is upgrade which means firing up a new instance to run side by side (resulting in the spamming starting again), an hour long migration and test run because half the time it doesn't work. We have to do it this way due to previous fucked up installs and upgrades by them and actually a 99.9% SLA to keep up.
Anecdotal, but there have been a number of times I've clicked a result on Google, and have been unable to get back to the results page without either double clicking the back button or finding it in the history. You'd just go to the original page that redirects you to the actual content and get stuck in a loop.
Its absolutely true. Why would google disregard such absolutely accurate data about the quality of its presented results? Now, It may or may not be true that webmasters do this for that reason or they are just lazy. Doing specially crafted redirects (mostly from mobile to full sites) does it. Here is a example, where you cant press the back button
But how does the Washington Post prevent the back button in the case above? You click the link which takes you to m.washingtonpost.com which in turn redirects you to www.washingtonpost.com but there's no back button available back to m.washingtonpost.com.
If Google is really using that algorithm, then I'm afraid I'm polluting their data. When I am looking for something on Google, I ctrl+click on all the relevant-looking links so they open in new tabs. Since I haven't even read any of the results yet, it is inaccurate to assume that the last link I ctrl+clicked was the most relevant.
Yeah, mobile versions of ordinary website truly are the bane of the internet.
The worst part is when the mobile version is unusable, but I can't change my phone's user agent string, to gain access to a website that has a desktop version that would very obviously work perfectly fine on my phone.
Good points here, especially on session length when related to logging users out.
I do however disagree with: "Anyways, the point of this is that in almost all uses, mobile site versions are god-awful." While the option to view the full site should always exist, there are enough experiences that designers would want different on mobile. There is a subset of power users who just want the full experience - but I think OP is generalizing here.
Anyways, the point of this is that in almost all uses, mobile site versions are god-awful.
I think you're right, unless the site commits the abonimable sin of redirecting from a specific desktop-targeted page to the homepage of the mobile site when it detects a certain user agent.
STOP DOING THAT.
It is absolutely the worst thing I have seen happen to site usability now that mobile sites are becoming more popular. And it's compounded in several cases by broken "view desktop version" links that still prevent me from actually seeing the page I requested in the first place.
Poor implementation that literally prevents users from viewing your content on popular devices is appalling UX, and it's one of the few things that will make me leave your site forever and never return.
I agree - some of the time. For blog posts, the mobile site is fine (because it knows what I want to do; read the post.)
However, changing the requested content, not letting me look at the main site using one button at the top of the page, and stopping me zooming on a real page are all ways to get me to never visit your site again.
I read quite a lot of stuff direct from iOS Twitter in the WebView - I just ignore sites that mess me around.
One way to read this would be: create a responsive, well-designed main site that functions well on both mobile and desktop.
My bigger pet peeve is when the mobile site is so dumbed-down that I can't access the features that I need, but then the full site won't load on my phone.
I think this will be less of a problem as responsive mobile design takes over. When I'm looking at a mobile website, I don't mind that it appears slightly different as long as all the same content is there.
I think point 3 is a good example of 'less is more' being applied in a wrong manner. Double email-address form fields are indeed silly, but passwords are invisible. The second field is there to catch typos (it is unlikely users make the same typo twice) and copy-paste mishaps.
But then again, you can always reset the password if you made a typo.
- Username and password should enable you to change the email
- Email alone should enable you to reset the password
So there is no risk in removing both duplicate fields. But maybe by now it's expected to type in a password twice. Users might be so used to it that it feels wrong to only insert it once.
But then again, you can always reset the password if you made a typo.
Exactly. We dropped the "confirm your password" box in our forms a while ago.
Related problems since that time: 0.
People often forget their passwords anyway, so a streamlined password reset facility seems more practically useful than hassling people to type the same thing twice.
Why? Because you are then using UI
features I have no way to know about
in advance. Simple HTML I can know
about in advance but not what can
be done with JavaScript, AJAX, etc.
The XKCD panel included below point 4 seems misguided to me.
Asking for the admin password prevents AUTOMATED, DRIVE-BY installs of device drivers etc. Only responding since people seem to take XKCD's opinions on tech seriously.
The point of the cartoon is not that admin passwords for driver installs are bad but to point out how the current state of computer security fails to protect all the other aspects of computer use.
