Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #15053 > unrolled thread

Re: Let's compile a list of ways to annoy the user.

Back to article view | Back to comp.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Let's compile a list of ways to annoy the user. Sylvia Else <sylvia@not.at.this.address> - 2017-12-02 11:23 +1100
    Re: Let's compile a list of ways to annoy the user. Rich <rich@example.invalid> - 2017-12-02 01:37 +0000
      Re: Let's compile a list of ways to annoy the user. Sylvia Else <sylvia@not.at.this.address> - 2017-12-02 13:12 +1100
      Re: Let's compile a list of ways to annoy the user. Huge <Huge@nowhere.much.invalid> - 2017-12-02 09:39 +0000
        Re: Let's compile a list of ways to annoy the user. Rich <rich@example.invalid> - 2017-12-02 18:02 +0000
          Re: Let's compile a list of ways to annoy the user. The Real Bev <bashley101@gmail.com> - 2017-12-02 12:44 -0800
            Re: Let's compile a list of ways to annoy the user. Huge <Huge@nowhere.much.invalid> - 2017-12-03 09:31 +0000
          Re: Let's compile a list of ways to annoy the user. Huge <Huge@nowhere.much.invalid> - 2017-12-03 09:43 +0000
    Re: Let's compile a list of ways to annoy the user. Eric Pozharski <whynot@pozharski.name> - 2017-12-02 15:31 +0200
    Re: Let's compile a list of ways to annoy the user. Sylvia Else <sylvia@not.at.this.address> - 2017-12-14 12:50 +1100
      Re: Let's compile a list of ways to annoy the user. Rich <rich@example.invalid> - 2017-12-14 02:06 +0000
        Re: Let's compile a list of ways to annoy the user. Sylvia Else <sylvia@not.at.this.address> - 2017-12-21 13:52 +1100

#15053 — Re: Let's compile a list of ways to annoy the user.

On 14/01/2016 11:42 AM, Sylvia Else wrote:
> We should probably limit it to things people have actually seen.
> 
> 1. Limits that are not stated up front.
> 
> 2. If the user tries to submit a form with invalid data, clear the form, 
> and make the user fill it all in again.
> 
> 3. Have an on-line support chat page that offers the option to print-out 
> the chat so far, but when the chat ends, go immediately to another page, 
> without letting the user print out the whole thing.
> 
> (I got that just the other day, and the page I got sent too was a 
> feedback page so that I could rate the experience I'd just had).
> 
> Sylvia.
> 
> 
> 
Just extending this old thread with a new user annoyance item:

When showing a user their credit card details, so that the user can 
update an expiry date, replace some of the card digits with asterisks as 
a security measure, and then complain about them when the user tries to 
submit the change.

Sylvia.

[toc] | [next] | [standalone]

#15054

Sylvia Else <sylvia@not.at.this.address> wrote:
> Just extending this old thread with a new user annoyance item:
> 
> When showing a user their credit card details, so that the user can
> update an expiry date, replace some of the card digits with asterisks
> as a security measure, and then complain about them when the user
> tries to submit the change.

Really?  Wow....  Talk about both developers and testing falling down
there.

One of my annoyances surrounding credit cards is the number of website
developers who don't comprehend that computers are *very* good at
removing characters that match a pattern.

So, when the CC processor takes credit card numbers in the form
123456781234 they then extend this requirement all the way to the end
user form.  I get esp.  annoyed by the ones that include "Enter CC
number ..  no spaces" because when that is there in the label it is
very clear they intentionally and purposefully passed along the
back-end API requirements onto the front.

 

[toc] | [prev] | [next] | [standalone]

#15055

On 2/12/2017 12:37 PM, Rich wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> Just extending this old thread with a new user annoyance item:
>>
>> When showing a user their credit card details, so that the user can
>> update an expiry date, replace some of the card digits with asterisks
>> as a security measure, and then complain about them when the user
>> tries to submit the change.
> 
> Really?  Wow....  Talk about both developers and testing falling down
> there.
> 

I dare say it didn't occur to any of them that this was silly. After 
all, if they didn't have a mindset that says that the user helps the 
computer, rather than the other way around, then we wouldn't see other 
silly stuff, such as the example you mentioned.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#15059

On 2017-12-02, Rich <rich@example.invalid> wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> Just extending this old thread with a new user annoyance item:
>> 
>> When showing a user their credit card details, so that the user can
>> update an expiry date, replace some of the card digits with asterisks
>> as a security measure, and then complain about them when the user
>> tries to submit the change.
>
> Really?  Wow....  Talk about both developers and testing falling down
> there.
>
> One of my annoyances surrounding credit cards is the number of website
> developers who don't comprehend that computers are *very* good at
> removing characters that match a pattern.
>
> So, when the CC processor takes credit card numbers in the form
> 123456781234 they then extend this requirement all the way to the end
> user form.  I get esp.  annoyed by the ones that include "Enter CC
> number ..  no spaces" because when that is there in the label it is
> very clear they intentionally and purposefully passed along the
> back-end API requirements onto the front.

*applause* And I would generalise that to any number where some organisation
(your bank, the DMV, whatever) sent it to you in one format, say "99-99-99"
and then get pissy when you type it into their website in that format,
insisting on "999999" - yes, UK banks and sort codes, I'm talking about you.

Can I also add American programmers who don't realise there are formats of
phone numbers other than (999)999-9999? Yes, Google Contacts, that's you,
that is.

The series of "Falsehoods Programmers Believe ..." pages are worth a read.

https://www.google.co.uk/search?q=falsehoods+programmers+believe


-- 
Today is Sweetmorn, the 44th day of The Aftermath in the YOLD 3183
        Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

[toc] | [prev] | [next] | [standalone]

#15061

Huge <Huge@nowhere.much.invalid> wrote:
> On 2017-12-02, Rich <rich@example.invalid> wrote:
>> Sylvia Else <sylvia@not.at.this.address> wrote:
>>> Just extending this old thread with a new user annoyance item:
>>> 
>>> When showing a user their credit card details, so that the user can
>>> update an expiry date, replace some of the card digits with asterisks
>>> as a security measure, and then complain about them when the user
>>> tries to submit the change.
>>
>> Really?  Wow....  Talk about both developers and testing falling down
>> there.
>>
>> One of my annoyances surrounding credit cards is the number of website
>> developers who don't comprehend that computers are *very* good at
>> removing characters that match a pattern.
>>
>> So, when the CC processor takes credit card numbers in the form
>> 123456781234 they then extend this requirement all the way to the end
>> user form.  I get esp.  annoyed by the ones that include "Enter CC
>> number ..  no spaces" because when that is there in the label it is
>> very clear they intentionally and purposefully passed along the
>> back-end API requirements onto the front.
> 
> *applause* And I would generalise that to any number where some organisation
> (your bank, the DMV, whatever) sent it to you in one format, say "99-99-99"
> and then get pissy when you type it into their website in that format,
> insisting on "999999" - yes, UK banks and sort codes, I'm talking about you.
> 
> Can I also add American programmers who don't realise there are formats of
> phone numbers other than (999)999-9999? Yes, Google Contacts, that's you,
> that is.
> 
> The series of "Falsehoods Programmers Believe ..." pages are worth a read.
> 
> https://www.google.co.uk/search?q=falsehoods+programmers+believe

I plucked this one from the "Old Calculator" thread.  In that thread, 
Paul Sture <nospam@sture.ch> said:

  > b) None of the prices shown was likely to match what I paid when I
  >    take postage, packaging and often-disadvantageous currency
  >    conversion rates into account.

Which reminded me of yet another one of my pet-peeves.  Sales sites
that charge postage and handling, but hide the amount of postage and
handling I'll need to pay until *after* I have entered payment details.

*No*....

I want to know the final price, including postage and handling, before
I decide if I'm going to fork over my payment details.  Reason: Once
I've forked over my payment details, I'm 100% dependent upon the site
properly offering an "abort this purchase" mechanism.

Not going to go there.  If the site keeps the postage and handling
hiddden until after the payment details, I'll simply go to some other
site.

It is also irritating how many sites (Amazon and eBay fall into this
category) where their summary listings of items searched for do not
include a price that is "price plus postage" in the list.  At least you
can learn the postage costs by looking at the item page, but they
already know that value, and could sum it into the price on the summary
listing pages.  But usually don't.

[toc] | [prev] | [next] | [standalone]

#15063

Websites that refuse to allow linux browsers but are perfectly happy if 
you select a windows 'user agent' instead.  These people frequently also 
demand newer versions of flash than are available for linux.

-- 
Cheers,  Bev
    Why is it so hot and what am I doing in this handbasket?

[toc] | [prev] | [next] | [standalone]

#15071

On 2017-12-02, The Real Bev <bashley101@gmail.com> wrote:
> Websites that refuse to allow linux browsers but are perfectly happy if 
> you select a windows 'user agent' instead. 

Grrrrr.   :o)


-- 
Today is Boomtime, the 45th day of The Aftermath in the YOLD 3183
        Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

[toc] | [prev] | [next] | [standalone]

#15072

On 2017-12-02, Rich <rich@example.invalid> wrote:
> Huge <Huge@nowhere.much.invalid> wrote:

[35 lines snipped]

> I plucked this one from the "Old Calculator" thread.  In that thread, 
> Paul Sture <nospam@sture.ch> said:
>
>  > b) None of the prices shown was likely to match what I paid when I
>  >    take postage, packaging and often-disadvantageous currency
>  >    conversion rates into account.
>
> Which reminded me of yet another one of my pet-peeves.  Sales sites
> that charge postage and handling, but hide the amount of postage and
> handling I'll need to pay until *after* I have entered payment details.

Hear bloody hear. I usually abandon the purchase when this happens.


-- 
Today is Boomtime, the 45th day of The Aftermath in the YOLD 3183
        Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.

[toc] | [prev] | [next] | [standalone]

#15062

with <f8ea3sF4limU1@mid.individual.net> Sylvia Else wrote:
> On 14/01/2016 11:42 AM, Sylvia Else wrote:
>> We should probably limit it to things people have actually seen.
>> 
>> 1. Limits that are not stated up front.
>> 
>> 2. If the user tries to submit a form with invalid data, clear the form, 
>> and make the user fill it all in again.
>> 
>> 3. Have an on-line support chat page that offers the option to print-out 
>> the chat so far, but when the chat ends, go immediately to another page, 
>> without letting the user print out the whole thing.
>> 
>> (I got that just the other day, and the page I got sent too was a 
>> feedback page so that I could rate the experience I'd just had).
>> 
>> Sylvia.
>> 
>> 
>> 
> Just extending this old thread with a new user annoyance item:
>
> When showing a user their credit card details, so that the user can 
> update an expiry date, replace some of the card digits with asterisks as 
> a security measure, and then complain about them when the user tries to 
> submit the change.

Or take a deep breath and...  In registration form:  [a] cut off prefix;
[b] make user pick that prefix from drop-down list;  [c] make user input
rest of the number in input field *above* the list;  [d] by _make_ mean
real bisyness, by shortening input field to ten characters (luckily
numbers are just numbers and no utf8 is involved) so users can't input
all twelve right away.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [next] | [standalone]

#15145

On 2/12/2017 11:23 AM, Sylvia Else wrote:
> On 14/01/2016 11:42 AM, Sylvia Else wrote:
>> We should probably limit it to things people have actually seen.
>>
>> 1. Limits that are not stated up front.
>>
>> 2. If the user tries to submit a form with invalid data, clear the 
>> form, and make the user fill it all in again.
>>
>> 3. Have an on-line support chat page that offers the option to 
>> print-out the chat so far, but when the chat ends, go immediately to 
>> another page, without letting the user print out the whole thing.
>>
>> (I got that just the other day, and the page I got sent too was a 
>> feedback page so that I could rate the experience I'd just had).
>>
>> Sylvia.
>>
>>
>>
> Just extending this old thread with a new user annoyance item:
> 
> When showing a user their credit card details, so that the user can 
> update an expiry date, replace some of the card digits with asterisks as 
> a security measure, and then complain about them when the user tries to 
> submit the change.
> 
> Sylvia.

I pursued this with the government entity involved. The response I got was:

"The RMS is required to comply with Privacy Laws and other road 
transport legislation when dealing with any personal information 
including credit card details.

You need to re-enter your credit card details through a secure platform 
for verification purposes."

This is, of course, total garbage. I've asked for specifics. I'll see 
what happens.

Sylvia.

[toc] | [prev] | [next] | [standalone]

#15146

Sylvia Else <sylvia@not.at.this.address> wrote:
> On 2/12/2017 11:23 AM, Sylvia Else wrote:
>> Just extending this old thread with a new user annoyance item:
>> 
>> When showing a user their credit card details, so that the user can
>> update an expiry date, replace some of the card digits with
>> asterisks as a security measure, and then complain about them when
>> the user tries to submit the change.
> 
> I pursued this with the government entity involved. The response I
> got was:
> 
> "The RMS is required to comply with Privacy Laws and other road 
> transport legislation when dealing with any personal information 
> including credit card details.
> 
> You need to re-enter your credit card details through a secure
> platform for verification purposes."

Ok, fine, then don't pre-fill the field with asterisks, leave it
totally empty, which would be a huge clue to "reenter this detail
here".

> This is, of course, total garbage. I've asked for specifics. I'll see 
> what happens.

It's a BS answer, probably created by someone with little technical
knowledge who's reading from a checklist.

[toc] | [prev] | [next] | [standalone]

#15177

On 14/12/2017 1:06 PM, Rich wrote:
> Sylvia Else <sylvia@not.at.this.address> wrote:
>> On 2/12/2017 11:23 AM, Sylvia Else wrote:
>>> Just extending this old thread with a new user annoyance item:
>>>
>>> When showing a user their credit card details, so that the user can
>>> update an expiry date, replace some of the card digits with
>>> asterisks as a security measure, and then complain about them when
>>> the user tries to submit the change.
>>
>> I pursued this with the government entity involved. The response I
>> got was:
>>
>> "The RMS is required to comply with Privacy Laws and other road
>> transport legislation when dealing with any personal information
>> including credit card details.
>>
>> You need to re-enter your credit card details through a secure
>> platform for verification purposes."
> 
> Ok, fine, then don't pre-fill the field with asterisks, leave it
> totally empty, which would be a huge clue to "reenter this detail
> here".
> 
>> This is, of course, total garbage. I've asked for specifics. I'll see
>> what happens.
> 
> It's a BS answer, probably created by someone with little technical
> knowledge who's reading from a checklist.
> 

I pursued this further, and next got a reply

"Roads and Maritime Services has implemented rigorous security 
mechanisms to ensure that your information and accounts are protected. 
The latest strong encryption technologies have been used to protect your 
data when being sent over the internet."

So I sent a somewhat testy response to that, starting "This is even less 
of an answer to my question that the previous response was" and finally 
reached someone with a clue. The problem may thus ultimately get addressed.

But it's like getting blood out of a stone.

Sylvia.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web