Minor T-mobile WTFs



  • This morning I went to the T-mobile site to add some minutes to a pre-paid cell phone.


    The first WTF moment was when I was logging into my phone account, which is keyed to your phone number. I started entering the number into the account box using an NNN-NNN-NNNN format (hyphens included), and was a little confused for a moment when I found myself typing numbers into the password box. Then I realised that T-Mobile has set to automatically send you to the password box after you have entered 10 characters into the account box, no matter what those characters were. This is a bit disingenuous given that there is no indication on the page as to what format the account number should be entered in. I would have hoped that a phone company would have thought to allow a phone number to be entered in more than one format.


    The second WTF was when was actually buying the minutes. I entered my credit card details etc and hit submit. T-mobile came back and said that my bank had denied my transaction. WTF??? There should have been no reason for that. So I ignored the problem and went onto some other tasks. 10 minutes later I get an SMS from T-Mobile saying that I have new minutes. WTF?? they said the transaction had been denied.


    The third WTF was that I was still logged into the T-Mobile website, so I navigated to the account balance (said by T-Mobile to be "real-time"), and it was still showing the old values. I refreshed a few times and nothing changed. It was only when I logged out and in again that I saw the new balance.


    I don't mind the actual T-mobile phone service, but their website needs a bit of an overhaul.



  • on the first, you are the wtf... 



  • @dysmas said:

    on the first, you are the wtf... 


    MPS .. is that you??



  • Ignore the troll.  All three are legitimate complaints.  The first one is one that really bugs me all the time: when programmers only accept data entered in one format.  C'mon, we're supposed to be making things easier for people!  We should accept phone numbers in every conceivable format and make it "just work".  Same for SSNs or anything else. 



  •  I hate sites that feel the need to push me to the next text field when they have determined I am done. Going back to edit these fields is a pain as they keep bumping me out to the next field.

     

    That is one common practice I would like to see gone.

     

    As far as the format issue I agree. Is it too tough to make it check for (xxx) xxx-xxxx, xxx-xxx-xxxx or xxx555xxxx? Otherwise explicityly tell me what format you want it in. Don't make me guess.



  • @DeLos said:

     I hate sites that feel the need to push me to the next text field when they have determined I am done. Going back to edit these fields is a pain as they keep bumping me out to the next field.

     

    That is one common practice I would like to see gone.

    Agreed.

     

    @DeLos said:

    As far as the format issue I agree. Is it too tough to make it check for (xxx) xxx-xxxx, xxx-xxx-xxxx or xxx555xxxx? Otherwise explicityly tell me what format you want it in. Don't make me guess.

    Programmers tend to be lazy jackasses.  Even telling the user the expected format is just silly.  I also hate forms that have separate fields for each section of the phone number, SSN, etc..  Simple text boxes are easy to use and it is a trivial amount of effort for the programmer to normalize the data before checking validity.  Expecting users to enter data in your preferred format is bad UI design.



  • @DeLos said:

     I hate sites that feel the need to push me to the next text field when they have determined I am done. Going back to edit these fields is a pain as they keep bumping me out to the next field.

     I have seen this done well exactly once...In the Windows XP installation "Enter your CD key" prompt, it manages to cleanly move you between boxes, let you click anywhere, edit what you've typed, backspace between boxes, etc.  

    Sadly, it's the best UI feature I've ever seen Microsoft develop, though it probably took a whole ten minutes to code.  It also seems to have never been reused, as the CD key prompts for Microsoft games are usually as disfunctional as all the rest that are out there.



  • Oh come on...

    number = number.replace(/[^0-9]/g, ""); // Javascript
    $number =~ tr/[^0-9]//; # Perl
    $number = preg_replace('/[^0-9]/', '', $number); // PHP
    number = Regex.Replace(number, "[^0-9]", ""); // C#
    number = re.sub(r'[^0-9]', number, '') # Python (I don't actually know python, but I pulled this together from examples)

    Was that so hard?



  •  @MiffTheFox said:

    Oh come on...

    That won't work! I always enter my phone number by what it spells: 555-LOVE-JOY.



  • @MiffTheFox said:

    Oh come on...

    Forgot 1:

    number.gsub!(/[^0-9]/, '')  #Ruby


  • You would expect 'modern' languages and/or frameworks to have something like a PhoneNumber.Parse(... arbitrary string ...). Things like telephone and credit card numbers are widely used in a multitude of environments, and still in this day and age everyone gives his own implementation to it (or copy/pastes it from somewhere else).



  • @OzPeter said:

    ...Three WTFs...

    I am staggered.  Well over a year ago, nearer two, I had (almost) exactly the same complaints about the T-Mobile self-service website (there may be some differences as I was using the UK portal).  In particular the bullshit about claiming your account was denied, then (seemingly) randomly deciding whether to apply the credit or not.  Endless confusion.  After a handful of such instances I changed networks out of irritation.  (And yes, I did tell them about the problems, and ultimately inform them that was the reason I was transferring).

    I can't believe that it's still this shit with the same problems so much later.  At least I know it's not worth considering returning to them!



  • @Zagyg said:

    At least I know it's not worth considering returning to them!


    I'm with them for one reason .. "You want your GSM phone unlocked? Sure .. here's the code you need to do it!"



  • @pbean said:

    You would expect 'modern' languages and/or frameworks to have something like a PhoneNumber.Parse(... arbitrary string ...)
     

    That would just have to be a simple regexp to strip out non-digits. Many countries don't have a standard X-digit number plan; some countries even have different length numbers within a single exchange zone. The countries that do have a fixed number of digits can still have exceptions and may not be completely consistent with things like area codes, or it might not even have area codes.Most countries include the trunk prefix in their numbers (actually AFAIK only NPA countries don't, other than countries without area codes), so do you want to normalise them out with the country code? Eg my 04xx xxx xxx becomes +61 4xx xxx xxx. And then different types of numbers are written differenly.

    One size does not fit all! :)


  • Discourse touched me in a no-no place

    @Zemm said:

    The countries that do have a fixed number of digits can still have exceptions and may not be completely consistent with things like area codes
    And even if the parsing did take into account things like hyphens and parens, user idiocy would still conspire against it.

    Like the people in the UK who think that the in London area code consists of 4 digits. (e.g. the person responsible for my business cards.)

    (London has a 3 digit area code, some other large cities (e.g. Newcastle, Manchester) has 4 digits, other areas (Gloucester e.g.) have 5. Longer ones may exist, but those are the ones I know of.)



  • @Zemm said:

    @pbean said:

    You would expect 'modern' languages and/or frameworks to have something like a PhoneNumber.Parse(... arbitrary string ...)
     

    That would just have to be a simple regexp to strip out non-digits. Many countries don't have a standard X-digit number plan; some countries even have different length numbers within a single exchange zone. The countries that do have a fixed number of digits can still have exceptions and may not be completely consistent with things like area codes, or it might not even have area codes.Most countries include the trunk prefix in their numbers (actually AFAIK only NPA countries don't, other than countries without area codes), so do you want to normalise them out with the country code? Eg my 04xx xxx xxx becomes +61 4xx xxx xxx. And then different types of numbers are written differenly.

    One size does not fit all! :)

     

    Well, if anyone would create a .NET class for parsing phone numbers, it would probably follow the other parsing functions in .NET:

    PhoneNumber pn = PhoneNumber.Parse(inputNumber, new CultureInfo(inputCountry));

     



  • @MiffTheFox said:

    PhoneNumber pn = PhoneNumber.Parse(inputNumber, new CultureInfo(inputCountry));
     

    I guess something like that could work: Then there'd be a large "phone number database" like what WTNG set out to be that can be updated like the TimeZone database. But even then there could be problems with a forced approach.

    What PJH was talking about was the "0207" and "0208" problem: When the area codes 0171 and 0181 were merged into 020 the 7 or 8 became the first digit of an 8-digit local number. We have the same problem when (075) xxx xxx became (07) 55xx xxxx in the 1990's: where some people just made it (0755) xxx xxx, or worse, (075) 5xx xxxx like how Facebook formatted it for a while.


Log in to reply