Text dialer mode enhancement

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start dial digits in 123 mode. For example, enter 111
2. Switch to txt mode and add @domain.com
3. Switch back to 123 mode and check the URI you're going to dial. If correct, 
dial that number. CSS fails to make the call, mangling the URI

What is the expected output? What do you see instead?
If the dialed URI in step 3 is correct, dialing it should make the call. 
Instead CSS starts dialing a different URI (when you dial 111@domain.com) - 
1112@null and, of course, it fails...

What version of the product are you using? On what operating system?
r1848, Android 2.2

Please provide any additional information below.
Issue is related to recent ticket - "dial pad switch to txt erases numeric 
input":
http://code.google.com/p/csipsimple/issues/detail?id=1913

Instead of dialing the number (URI) it correctly displays (e.g. 
111@domain.com), CSS mangles the URI (making it 1112@null) and then calls the 
wrong URI. 

I've repeated test many times and, in my case, CSS always adds '2@null', 
replacing domain in real URI. I expect that switching between two modes (123 
and txt) should not change entered URI in any way and just dial it, when I 
press "Call" button.

Original issue reported on code.google.com by yok...@gmail.com on 28 Aug 2012 at 3:41

[GoogleCodeExporter]

Indeed was probably one of the reason why was as before issue 1913. 
In fact the underlying problem is that the field when in digit mode is 
considered as a phone number and so has some strip separator (and auto add 
separator) of country added and removed when called. The function to apply the 
remove of the separator depends on the manufacturer/device implementation. So 
possibly this will not be observed everywhere.

For example I tried to reproduce exactly your scenario and have not the 
problem. But from code it's possible that the problem is reached in case the 
manufacturer strip phone number digits this way.

So... I think that I'll partially revert the change of issue 1913 so that it 
keep the content only when switching from digit to text. And clear it when 
switching from text to digits.

I merge with 1913 to track this change in the other issue to that will be 
affected by the new fix.

Thanks a lot for reporting the issue. I was not sure of this change and forgot 
why I cleared the field previously this was probably one of the good reason.

Original comment by r3gis...@gmail.com on 28 Aug 2012 at 9:22

• Changed state: Duplicate

[GoogleCodeExporter]

I've seen the problem with removing entered data when I switch between 123 and 
txt modes before and I was going to ask you for the fix. And I'm glad that it 
was opened and fixed in issue 1913. Thank you for that!

IMHO, the best solution should be to keep whatever the user has entered in both 
modes (123 and txt) and to allow the user to check it and make any changes, he 
wants or needs. If user wants to enter digits in 123 mode and then to switch to 
txt, just show him, what was already entered and allow to edit it further. The 
same should happen when user switches from txt to 123 modes too. In other 
words, CSS should just dial whatever user sees on the screen without any 
modifications of the entered data (both plain digits and / or complex URI). It 
would be a simple and quite expected design. If there is a need for 
modification (to add/remove separators, county and / or area codes, etc), CSS 
has powerful filters, that can do it. But user should be able to enter and dial 
whatever he wants.

Bottom line, please don't revert the change of issue 1913 and just allow us to 
dial what we see (and entered) in our dial pad in any mode without additional 
restrictions.

Original comment by yok...@gmail.com on 28 Aug 2012 at 10:34

[GoogleCodeExporter]

The ability to enter whatever user wants is text mode.
The digit mode has parity with the android stock dialer. So it should 
automatically add separator and format as the stock dialer would do.

The filter doesn't apply to the csipsimple dialer by design because you are 
able here to choose your account.

Switching *from* text *to* digit while dialing is in my opinion absolutely 
useless to do. Did you find a reason to do that?
Btw, I didn't revert fully issue 1913. Only for the *from* text to *digit* 
which is normally absolutely useless and will lead to break the phone number 
formatter of android.

Original comment by r3gis...@gmail.com on 29 Aug 2012 at 7:38

[GoogleCodeExporter]

> The digit mode has parity with the android stock dialer. So it should 
automatically add separator and format as the stock dialer would do.

Under separator you mean '@domain.tld', right? That's the only thing that I see 
is added to the dialed number, when I make call via specific SIP account. It 
may be OK, unless the dialed number/URI has already such suffix. For example, 
if I dial '111@domain.com' I'd expect the dialer to keep all my data intact. If 
dialer replaces it with whatever it wants (for example dialing '1112@null' 
instead) - it doesn't help users, but rather creates unnecessary frustration.

> The filter doesn't apply to the csipsimple dialer by design because you are 
able here to choose your account.

When I make an outbound call via some SIP account and that account has its own 
set of filters I expect them to be applied. And why not?

It seems to me that sometimes we create some artificial limitations and then 
try to justify them. Limiting filters only to stock dialer is one of them... 
Removing / changing data in dial pad when I toggle its entering mode (123 vs 
txt) is another example.

> Switching *from* text *to* digit while dialing is in my opinion absolutely 
useless to do. Did you find a reason to do that?
Btw, I didn't revert fully  issue 1913 . Only for the *from* text to *digit* 
which is normally absolutely useless and will lead to break the phone number 
formatter of android.

It may look useless to you. But mangling entered data (removing part of it or 
the whole) when I toggle between 123 and txt modes back and force is definitely 
frustrating experience to me. It's unexpected and then I have to repeat 
entering the same data again... Not a fun. Please keep it simpler and 
predicable for users.

In the latest r1852 in '123' mode I've entered a number to dial (containing 
digits only), switched to 'txt' and back to '123' mode and the phone number is 
gone now... :( Dial pad should run similarly to Android stock keyboard. When I 
switch its mode I expect different sets of keys to enter new data, not the 
content change...

Original comment by yok...@gmail.com on 29 Aug 2012 at 7:53

[GoogleCodeExporter]

> Under separator you mean '@domain.tld', right? 

No. It's space or - char. In some countries it's added automatically to phone 
numbers.

> When I make an outbound call via some SIP account and that account has its 
own set of filters I expect them to be applied. And why not?

No. Has been discussed already in another issue. An option should be present. 
But CSipSimple dialer shows you the account you'll dial and you are aware of 
what you are doing while typing. The filters are for android integration to 
dial one number and get the app be clever for you. If you are inside csipsimple 
you see the account you are dialing, you dial what you want to dial and it's 
the number you dial that will be sent. The auto phone number formating is just 
a display and is actually not dialed by the user. It's to leave a way to bypass 
filtering/rewriting rules. However the option to apply filter on what has been 
entered is some enhancement to add. But it's not the expected behavior to have 
something rewriting automatically while you are inside csipsimple dialer.

> It seems to me that sometimes we create some artificial limitations and then 
try to justify them. Limiting filters only to stock dialer is one of them... 
Removing / changing data in dial pad when I toggle its entering mode (123 vs 
txt) is another example.

As your first assumption is wrong... The text formatting I'm talking about here 
has *NOTHING* to do with rewriting rules. BESIDES.... you probably didn't 
notice because probably in your country there is no such text formating rule 
for phone numbers... but if you dial from stock dialer it will send the 
information to csipsimple with additional space and hash. And here even WITHOUT 
any rewriting rule, the app will automatically remove these chars. It's because 
there is on android a library to add and remove it. It's part of the platform. 
I'm not inventing anything... just integrating the system... if you doubt... 
read the code...

> It may look useless to you. But mangling entered data (removing part of it or 
the whole)

Did you just try to press the input field while in digit mode????????
You are trying to complicate your life... Even when you are report problem... 
rather than telling me what is really annoying for you... you are telling me to 
fix some very complicate use case without focusing on the root use case that 
bother you... 

The fact you *think* you can't edit part of the field in digit mode -- which is 
actually possible !!! -- is the real root cause of why you are doing this 
complicate use case that is absolutely not natural for a user. -- At least I 
don't guess so --
Instead of having long debate on the very complicate use case I would prefer a 
feedback on the real use case behind. And to try to make your life *really* 
easier instead ;)

And last point -- not very import BTW -- : Even if was not possible to edit 
part of the content of the field in digit mode (which is possible), it would 
not be a reason to switch back to digit... again... you are in text mode you 
can do strictly more than in digit mode (there is no more feature in digit 
mode). Or there is maybe something I missed?

As it's possible to click on the digit text field and get the cursor and remove 
part of the digit input ... I still don't get the use case where it's necessary 
to keep the content of the field when switching FROM TEXT TO DIGIT.... 
(And if you actually read my comment just before you should have expected in 
r1852 what you observe... FROM TEXT TO DIGIT, content is cleared).

Original comment by r3gis...@gmail.com on 29 Aug 2012 at 8:13

[GoogleCodeExporter]

> However the option to apply filter on what has been entered is some 
enhancement to add. But it's not the expected behavior to have something 
rewriting automatically while you are inside csipsimple dialer.

But it is. It IS expected behavior, IMHO.

Here is example how I use filters. I want to make direct calls to toll free 
numbers via "tf.callwithus.com" domain. In order to do so I've created a new 
gateway (let's call it "DC-TF"). This gateway is used only for outbound calls 
and therefore it doesn't have any Registration URI, User name, etc. I added to 
it one simple filter (Rewrite, Custom RegExp):
"matches": "^((\\+?1)?(8(00|55|66|77|88)[2-9]\\d{6}))$",
"replace": "$1@tf.callwithus.com",
But when I dial 1-800-444-4444 number from this account to make a test, I'm 
getting error. It's because the filer, associated with that account, doesn't 
work with it. Instead of expected "18004444444@tf.callwithus.com" URI, the 
account dials "18004444444@null". At the same time, it's working well, when I 
dial the number in stock dialer though... So now, if I want to dial toll free 
numbers, I have to remember; a) to allow "DC-TF" gateway (it's expected) and b) 
I have to remember to leave CSS and use stock dial pad. It's not a very big 
deal, but rather ... a bit weird.

> You are trying to complicate your life... 

No, I rather try to make it simple and predictable. In this particular case 
simple and predictable means, that CSS doesn't remove the number I just 
entered, when I toggle between '123' and 'txt' modes. Just keep it, no matter 
how many times I change the mode. If I want to remove my number, I have 
"Backspace" button. That's simple and predictable. 

> it would not be a reason to switch back to digit... again... 

Users should be allowed to do what they want. If they consider to toggle dial 
pad (for whatever reason) multiple times between '123' and 'txt', and that 
doesn't critically brakes main functionality of CSS, they certainly should be 
able to do so...  Toggling the edit mode between '123' and 'txt' is a good 
example of the action they should be allowed to do. And what they don't expect 
is - the app removes entered data from the field they just spend their time to 
enter. :(

> I still don't get the use case where it's necessary to keep the content of 
the field when switching FROM TEXT TO DIGIT.... 

OK, personal experience here - when I enter data in 'txt' mode I see it with 
extremely small font (I have to use a lens to check it) and sometimes parts of 
the data is presented as black text on black background (appears and 
disappears). When I toggle to '123' I want to final check it with the font, 
used in that '123' mode... I know that I better start to complain about small 
font in 'txt' mode, but I've decided to wait for someone else to open the 
ticket. At this time, I've mentioned it as one of the reasons, why one dumb 
user (like me) may want to toggle between '123' and 'txt' back and force... And 
believe me, there could be other reasons too...

Make it simple, keep the data unmodified. If I need a modification, I'm going 
to create a filter...

Original comment by yok...@gmail.com on 30 Aug 2012 at 4:09

[GoogleCodeExporter]

Regarding the black text on black background in 'txt' mode - I've opened new 
issue 1929.

Original comment by yok...@gmail.com on 31 Aug 2012 at 8:24

[GoogleCodeExporter]

Here is what I'd do when user toggles '123' and 'txt' modes.

First of all, let's focus on what to do with domain prefix (@domain.tld). Until 
user enters any characters except '@' symbol, CSS should append default domain 
prefix (DDP), associated with account/gateway making the call. As soon as user 
enters '@' symbol, CSS should use whatever user enters after that as a new 
specific domain (SP). If user removes '@', DDP should be re-used again.

a) In 'txt' mode always show the domain prefix.
If DDP is used, you may show that prefix slightly dimmer (grayed) or using 
slightly different color (highlighting, that it's 'default' and can't be 
edited). If user enters SP, show it as a regular data.

b) In '123' mode.
If DDP is used (user did not enter '@'), do not show it. But if user has 
entered '@', show whatever user entered.

Couple of related points:
1. Use formatting (extra dashes when displaying number) when user enters digits 
only (0-9 or '*' or '#' or '+'). If user enters anything else, show exactly 
what was entered (including even possible dashes, if he wants).
2. If DDP is used (no '@' entered yet), use DDP accordingly to outbound 
account. If user changes it while entering the data, change it automatically 
(grayed in 'txt' mode). It will help user to see exact URI he will dial.
3. If user enters specific domain (SP), it means that he want to make new call 
to that domain using chosen outbound account/gateway. Nothing contradictory is 
here and he should be able to do so. No any domain prefix replacement is 
expected here.

Important point to remember, as with any services, user is always right. Do not 
punish him (by removing entered data), when he changes dial pad mode. It leads 
to WTF moment, and if it will be repeated a number of times, he eventually may 
drop the service (program).

Original comment by yok...@gmail.com on 31 Aug 2012 at 8:40

[GoogleCodeExporter]

Regarding filters and using them directly from specific account, it'd be very 
nice to see the result of filter (associated with account/gateway) applied to 
the entered data.

In 'txt' mode even in my small HTC Aria there is a black area below the field 
to enter new data and above stock keypad, which is enough to display the result 
of filtered data in real time. Until filter is not triggered by any matching 
rule, user will see the same data below as he enters it in the data field (or 
you may even hide it at this time). But when filter is triggered, matches rule 
applies and user starts to see in that auxiliary field (read only) what URI 
will be actually used in outbound call.

Using example mentioned earlier in post 6, user (at the time when user finished 
entering the data) may see: 
Edited data:  180044444444
Filtered data: 180044444444@tf.callwithus.com

With this new feature user can see and check what exactly CSS is going to use 
in next call. Even if it was implemented only in 'txt' mode, it'd be useful for 
users who is using dial pad in '123' mode too. They may easily switch from 
'123' to 'txt' and check. And then, (if we fix current issue and will not 
remove entered data) user may continue to use '123' mode too...

Original comment by yok...@gmail.com on 31 Aug 2012 at 9:14

[GoogleCodeExporter]

Yes this point is a very good idea that covers all cases. It would be good to 
have that implemented indeed. 
Not so obvious to implement but would be a good target.
I can't promise it in short term as far as I'm concerned because other hot 
topic to finish before, but if any developer wants to contribute that proposal 
will be welcome.

About the rewriting rules I still believe on the fact it should be done as a 
separate button. 
As the button is not yet there to apply filter, I can't and probably nobody 
can't really have a clear opinion on that. What I'm sure of is that applying 
rules from this dialer would be very annoying for me as an user of the 
application. 

About how to present to user the option to enable or not filtering rules for 
csipsimple dialpad it's another topic that I can't really address for now until 
there's the engine to do that. 
There is several options to show it to user : 
 * as some switch to tell if we'd like rules to be applied or not 
     - in dialpad ui 
      or 
     - in the app settings
or 
 * as button in dialpad ui to apply rule when the button is clicked one shot apply. 
    (and so dialing will always dial what is displayed in screen in this case).
 * other ideas...
Maybe some of these options has to be explored. On my side it's clear that 
there is a miss here and many users expect the filtering/rewriting rules to be 
available in css dialer, but the solution is not to apply rules unilaterally 
here without giving a way to users to prevent that.... if so I would not use 
anymore my own app and so probably not continue developing it ;).
Anyway, about this point it's topic of issue 1448. Maybe if you have ideas with 
user interface full definition proposal you can share on the issue 1448 and we 
leave this one for the dialer input field management of text input.

Original comment by r3gis...@gmail.com on 31 Aug 2012 at 9:17

• Changed title: Text dialer mode enhancement
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

What do you think will be annoying here? Is it watching how the value will be 
changed in second (filtered data) display while user enters a new character in 
dial pad? I'd think it's rather a fun to watch how the filtered result could be 
changed with just one added/removed symbol in the edit pad. But if you think it 
is, there are two simple solutions:
a) delay displaying the string in filtered display for 1 sec after user enters 
a new character (start it with 5 sec delay and then reduce timeout until it 
will start bothering you)
b) make a pop up which will display filtered data after user presses a button.

Personally, I'd prefer the (a) approach, but (b) could be done too, even if 
it's less flexible (user will be required to hit the button all the time to 
check) and not in real time. I could live with that, pressing that button again 
and again... But eventually, after I'll get tired with it, I'll ask you to 
support (a) case and always show filtered data in second display (in 'txt' 
mode) :) 

Note: in all cases (using for filtered data a second display or a special 
pop-up) I expect to be able to make a copy of the filtered data to clipboard 
for further analysis... Please don't make it copy-protected. It will help users 
to troubleshoot potential problems with filters later on.

Regarding the switch to enable/disable filters, I think that we may start with 
simple presumption - all filters, associated with account/gateway, are active 
all the time. Then later, in "Settings | Filters | Account | List of filters" 
page we may add switch, toggling each rule. The page looks very similar to the 
one, that displays list of all accounts. There is a list of rules, there is tab 
on the right side to re-order rules and there could be a switch (icon) on the 
left side too. If rule is active - it's highlighted, or if it's not - its left 
icon is dark. Very similar to accounts page... But again, for simplicity sake, 
let's start with applying filters all the time.

Original comment by yok...@gmail.com on 1 Sep 2012 at 4:04

[GoogleCodeExporter]

This issue was closed by revision r2387.

Original comment by r3gis...@gmail.com on 30 Mar 2014 at 5:54

• Changed state: Fixed