[sip-comm-dev] Proposal to add a new GUI layout


#1

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner

UIServiceImpl.java (40.9 KB)

DialPanel.java.tar.gz (23.9 KB)


#2

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

- What is the purpose of the back button?

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Cheers,
Yana

路路路

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Regards,
Werner

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

路路路

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey folks,

袧邪 18.08.10 18:38, Werner Dittmann 薪邪锌懈褋邪:

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

I think this is an important discussion so thanks Werner for bringing it
up.

On a more practical note however, that kind of quick, experimental, and
meant-to-get-first-impressions modifications would be better off in a
branch of their own. There's no need for them to trigger builds, or
encumber existing code.

We don't currently have touch screen support on our Roadmap and before
it gets there we would need to agree on how we are doing it.

So, Werner, Yana, could you please create a touchscreen branch and have
fun in there? We'll bring it back to trunk once we've all agreed on the
design.

Thanks,
Emil

路路路

Regards,
Werner

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi Werner,

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Actually your commit surprised me a little, cause you were asking for the community opinion and finally you didn't wait for an answer :slight_smile: I promise to be very quick in my response next time :slight_smile: Otherwise I think that the touch screen user interface is quite important and I'm ready to work with you in this direction.

Regards,
Werner

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Ok, I see. If we make a branch, as Emil suggested this approach could work good.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

I have some ideas and we could inspire ourselves from all the touch screen phone interfaces we see recently. Feedback you obtain is also important.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

Ok. I think it could be a good idea to replace the text with an icon like for example the icon for backspace in android or iphone sms interface (see attached).

路路路

On Aug 18, 2010, at 6:38 PM, Werner Dittmann wrote:

Am 18.08.2010 12:30, schrieb Yana Stamcheva:


#6

Hi Yana, Emil,

having an own branch is a very good idea - sorry should have done it myself before
commiting to trunk :frowning: .

I'm just gathering some feedback from users that use touchscreen devices with
smaller touchscreens. I'll compile the feedback and send some ideas during the
next days.

Regards,
Werner

路路路

Am 18.08.2010 19:24, schrieb Yana Stamcheva:

Hi Werner,

On Aug 18, 2010, at 6:38 PM, Werner Dittmann wrote:

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Actually your commit surprised me a little, cause you were asking for the community opinion and finally you didn't wait for an answer :slight_smile: I promise to be very quick in my response next time :slight_smile: Otherwise I think that the touch screen user interface is quite important and I'm ready to work with you in this direction.

Regards,
Werner

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Ok, I see. If we make a branch, as Emil suggested this approach could work good.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

I have some ideas and we could inspire ourselves from all the touch screen phone interfaces we see recently. Feedback you obtain is also important.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

Ok. I think it could be a good idea to replace the text with an icon like for example the icon for backspace in android or iphone sms interface (see attached).

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Ok. We could also think of a backspace button that, when pressed continuously would react like delete for example. As I see on the Android screenshot I attached, they've written DEL on the top of the icon, which could be a good idea. WDYT?

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

I'm afraid that in most of the cases the modifications would be very specific for a particular device. For example in order to become usable on Android we should write a completely new interface from scratch. The same for iphone. It doesn't mean that we shouldn't try to make a common touch screen interface. It's just that I think this would be a tough task and I agree with you that a discussion should be opened and we should start thinking in this direction.

Cheers,
Yana

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Werner,

Hi Yana, Emil,

having an own branch is a very good idea - sorry should have done it myself before
commiting to trunk :frowning: .

Ok, I'll create a branch today and then we could move the modifications there.

I'm just gathering some feedback from users that use touchscreen devices with
smaller touchscreens. I'll compile the feedback and send some ideas during the
next days.

Great!

Cheers,
Yana

路路路

On Aug 20, 2010, at 11:00 AM, Werner Dittmann wrote:

Regards,
Werner

Am 18.08.2010 19:24, schrieb Yana Stamcheva:

Hi Werner,

On Aug 18, 2010, at 6:38 PM, Werner Dittmann wrote:

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Actually your commit surprised me a little, cause you were asking for the community opinion and finally you didn't wait for an answer :slight_smile: I promise to be very quick in my response next time :slight_smile: Otherwise I think that the touch screen user interface is quite important and I'm ready to work with you in this direction.

Regards,
Werner

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Ok, I see. If we make a branch, as Emil suggested this approach could work good.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

I have some ideas and we could inspire ourselves from all the touch screen phone interfaces we see recently. Feedback you obtain is also important.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

Ok. I think it could be a good idea to replace the text with an icon like for example the icon for backspace in android or iphone sms interface (see attached).

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Ok. We could also think of a backspace button that, when pressed continuously would react like delete for example. As I see on the Android screenshot I attached, they've written DEL on the top of the icon, which could be a good idea. WDYT?

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

I'm afraid that in most of the cases the modifications would be very specific for a particular device. For example in order to become usable on Android we should write a completely new interface from scratch. The same for iphone. It doesn't mean that we shouldn't try to make a common touch screen interface. It's just that I think this would be a tough task and I agree with you that a discussion should be opened and we should start thinking in this direction.

Cheers,
Yana

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi Werner,

I've created the touchgui branch and you could start playing with it :slight_smile:

Cheers,
Yana

路路路

On Aug 20, 2010, at 11:00 AM, Werner Dittmann wrote:

Hi Yana, Emil,

having an own branch is a very good idea - sorry should have done it myself before
commiting to trunk :frowning: .

I'm just gathering some feedback from users that use touchscreen devices with
smaller touchscreens. I'll compile the feedback and send some ideas during the
next days.

Regards,
Werner

Am 18.08.2010 19:24, schrieb Yana Stamcheva:

Hi Werner,

On Aug 18, 2010, at 6:38 PM, Werner Dittmann wrote:

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Actually your commit surprised me a little, cause you were asking for the community opinion and finally you didn't wait for an answer :slight_smile: I promise to be very quick in my response next time :slight_smile: Otherwise I think that the touch screen user interface is quite important and I'm ready to work with you in this direction.

Regards,
Werner

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Ok, I see. If we make a branch, as Emil suggested this approach could work good.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

I have some ideas and we could inspire ourselves from all the touch screen phone interfaces we see recently. Feedback you obtain is also important.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

Ok. I think it could be a good idea to replace the text with an icon like for example the icon for backspace in android or iphone sms interface (see attached).

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Ok. We could also think of a backspace button that, when pressed continuously would react like delete for example. As I see on the Android screenshot I attached, they've written DEL on the top of the icon, which could be a good idea. WDYT?

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

I'm afraid that in most of the cases the modifications would be very specific for a particular device. For example in order to become usable on Android we should write a completely new interface from scratch. The same for iphone. It doesn't mean that we shouldn't try to make a common touch screen interface. It's just that I think this would be a tough task and I agree with you that a discussion should be opened and we should start thinking in this direction.

Cheers,
Yana

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi Yana,

thanks, I just prepared my git-svn and created the branch in my sandbox.

Below is a short feedback regarding the touch screen handling and video.
The device is meant as a replacement for a "black phone" :slight_smile: . It uses
modern technology and handling of the device should be as simple as possible
by copying the "look-and-feel" of a black-phone via the touch screen
and the dialpad shown on the screen.

Dialpad:

<Feedback>
We need a dialpad to dial the number to call. Also, when the call is
active, we need to use the dialpad to enter passwords (voicemail),
options or transfer calls to another extension or external number.
The dialpad must be accessible all the time. Before an active call and
during an active call. Like in any phone, the dialpad is the center of
the phone.
</Feedback>

Video:

<Feedback>
Yes, linphone video image uses less space than ekiga, due to its floating
video panel. But, linphone and ekiga have the option to set the size of
the video. The most popular sizes are: 352x288 (cif) - 320x240 (qvga) -
176x144 (qcif) - I think SC should have only this sizes as options,
they fit well on any screen, even on ours, while providing a nice
resolution. Linphone have a nice feature, the give you the option to
disable video at any time, before or during a call. Also it permits
to enable or disable the "Self View".
</Feedback>

Wener's note: some of these features are available in SC (switch
on/off video during the call). Not sure about selectable sizes.

<Feedback>
Attached you will find an image of the unit.

Is a 9 inch, touch screen 1024X600 with a built in camera (1.3 mp) -
The picture is showing the old model, the newer is nicer. The headset
is removable and is connected via an USB port. It is running a customized
version of Ubuntu.
</Feedback>

路路路

Am 26.08.2010 14:08, schrieb Yana Stamcheva:

Hi Werner,

I've created the touchgui branch and you could start playing with it :slight_smile:

Cheers,
Yana

On Aug 20, 2010, at 11:00 AM, Werner Dittmann wrote:

Hi Yana, Emil,

having an own branch is a very good idea - sorry should have done it myself before
commiting to trunk :frowning: .

I'm just gathering some feedback from users that use touchscreen devices with
smaller touchscreens. I'll compile the feedback and send some ideas during the
next days.

Regards,
Werner

Am 18.08.2010 19:24, schrieb Yana Stamcheva:

Hi Werner,

On Aug 18, 2010, at 6:38 PM, Werner Dittmann wrote:

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Actually your commit surprised me a little, cause you were asking for the community opinion and finally you didn't wait for an answer :slight_smile: I promise to be very quick in my response next time :slight_smile: Otherwise I think that the touch screen user interface is quite important and I'm ready to work with you in this direction.

Regards,
Werner

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Ok, I see. If we make a branch, as Emil suggested this approach could work good.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

I have some ideas and we could inspire ourselves from all the touch screen phone interfaces we see recently. Feedback you obtain is also important.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

Ok. I think it could be a good idea to replace the text with an icon like for example the icon for backspace in android or iphone sms interface (see attached).

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Ok. We could also think of a backspace button that, when pressed continuously would react like delete for example. As I see on the Android screenshot I attached, they've written DEL on the top of the icon, which could be a good idea. WDYT?

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

I'm afraid that in most of the cases the modifications would be very specific for a particular device. For example in order to become usable on Android we should write a completely new interface from scratch. The same for iphone. It doesn't mean that we shouldn't try to make a common touch screen interface. It's just that I think this would be a tough task and I agree with you that a discussion should be opened and we should start thinking in this direction.

Cheers,
Yana

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hey Werner,

From what I see this is a relatively specific device (it looks pretty
nice by the way!) and as such, it would probably be best if it had a
device specific user interface. Some of the constraints below, while
making perfect sense for that kind of phones, are not necessarily
compliant with the general touch screen trends.

One such feature is having a dial-pad centric interface. The iPhone for
example doesn't have the dialpad showing by default.

My point is that, it would be hard to make SIP Communicator's user
interface fit all possible devices out there. I am even wondering
whether we should be trying at all.

The best thing to do would be to simply use SIP Communicator as a basis
and then develop the interface independently as per the device/customer
specs (that's the kind of stuff we do for our customers at Blue Jimp for
example).

Cheers,
Emil

袧邪 26.08.10 16:49, Werner Dittmann 薪邪锌懈褋邪:

路路路

Hi Yana,

thanks, I just prepared my git-svn and created the branch in my sandbox.

Below is a short feedback regarding the touch screen handling and video.
The device is meant as a replacement for a "black phone" :slight_smile: . It uses
modern technology and handling of the device should be as simple as possible
by copying the "look-and-feel" of a black-phone via the touch screen
and the dialpad shown on the screen.

Dialpad:

<Feedback>
We need a dialpad to dial the number to call. Also, when the call is
active, we need to use the dialpad to enter passwords (voicemail),
options or transfer calls to another extension or external number.
The dialpad must be accessible all the time. Before an active call and
during an active call. Like in any phone, the dialpad is the center of
the phone.
</Feedback>

Video:

<Feedback>
Yes, linphone video image uses less space than ekiga, due to its floating
video panel. But, linphone and ekiga have the option to set the size of
the video. The most popular sizes are: 352x288 (cif) - 320x240 (qvga) -
176x144 (qcif) - I think SC should have only this sizes as options,
they fit well on any screen, even on ours, while providing a nice
resolution. Linphone have a nice feature, the give you the option to
disable video at any time, before or during a call. Also it permits
to enable or disable the "Self View".
</Feedback>

Wener's note: some of these features are available in SC (switch
on/off video during the call). Not sure about selectable sizes.

<Feedback>
Attached you will find an image of the unit.

Is a 9 inch, touch screen 1024X600 with a built in camera (1.3 mp) -
The picture is showing the old model, the newer is nicer. The headset
is removable and is connected via an USB port. It is running a customized
version of Ubuntu.
</Feedback>

Am 26.08.2010 14:08, schrieb Yana Stamcheva:

Hi Werner,

I've created the touchgui branch and you could start playing with it :slight_smile:

Cheers,
Yana

On Aug 20, 2010, at 11:00 AM, Werner Dittmann wrote:

Hi Yana, Emil,

having an own branch is a very good idea - sorry should have done it myself before
commiting to trunk :frowning: .

I'm just gathering some feedback from users that use touchscreen devices with
smaller touchscreens. I'll compile the feedback and send some ideas during the
next days.

Regards,
Werner

Am 18.08.2010 19:24, schrieb Yana Stamcheva:

Hi Werner,

On Aug 18, 2010, at 6:38 PM, Werner Dittmann wrote:

Hi Yana,

thanks for the comments. Ineed this was a fast implementation of some ideas
I got from some feedback. The goal of the current implementation was to
do it fast as possible to get first impressions from users that use
touch screen computers and to avoid too much modification of
existing code.

Actually your commit surprised me a little, cause you were asking for the community opinion and finally you didn't wait for an answer :slight_smile: I promise to be very quick in my response next time :slight_smile: Otherwise I think that the touch screen user interface is quite important and I'm ready to work with you in this direction.

Regards,
Werner

Am 18.08.2010 12:30, schrieb Yana Stamcheva:

Hi Werner,

I don't think that duplicating the whole MainFrame is the best approach to introduce a new touch screen interface. I see that the only difference for now between the two classes is only the new tabbed pane and dial panel added into it. Even if we think that in the future we would need a lot more changes, the MainFrame contains logic related to account loading, operation set loading, etc. things that are not related to the user interface and should not be duplicated in every new MainFrame interface implementation. I therefore think that even if we decide to stay with the MainFrame interface we should think of introducing an abstract class, where we would keep the implementation of all the common methods.

Actually there is an abstract class - the MainFrame class that currently contains
just one static method from the "old" MainFrame class. Both other classes,
MainFrameStandard and MianFrameTouch extend this abstract class. The intention
was to fill in/move common functions and fields to the abstract class. This
could be step-by-step process. But before doing so I started ask for some comments
first :slight_smile: .

Ok, I see. If we make a branch, as Emil suggested this approach could work good.

Also the new DialPanel that you've added to the impl/gui/main package is slightly different from the one we have in the main/call package and I have some questions/comments about it.

- I don't think the call button should be there, instead I think in a touch screen alternative we should move it at the top just right to the number field.

Yes, I tried to play with some layout classes but this is definitley not my field of
experience - thus I failed to do that ;-). Mayby you have an idea how to arrange such
a nice layout.

I have some ideas and we could inspire ourselves from all the touch screen phone interfaces we see recently. Feedback you obtain is also important.

- What is the purpose of the back button?

The backbutton deletes the digit left of the cursor, a mini edit function.

Ok. I think it could be a good idea to replace the text with an icon like for example the icon for backspace in android or iphone sms interface (see attached).

- What is the purpose of the delete button? If it's meant to delete the number in the number field, why don't we use the "x" button in the field instead?

Yes, it clears the whole field. I decided to use an extra and bigger button here
because the "x" button in the field is fairly small. Using a finger to hit the button
could lead to also hit another button nearby, either the "call button" or the "show
history button".

Ok. We could also think of a backspace button that, when pressed continuously would react like delete for example. As I see on the Android screenshot I attached, they've written DEL on the top of the icon, which could be a good idea. WDYT?

Otherwise, I'm also thinking that we would probably need similar modification in other parts of the gui in order to make the whole interface touch compatible and wouldn't it be a good idea to think of this as a new skin or something like that, instead of introducing "if (touchscreen)" everywhere in the code?

Yes, modification in some other parts may (will) be necessary to get a real good
touch screen experience. I'm not familiar with skins, but I'm not sure that just
another skin will lead to a good touch screen UI. IMHO we need to modifiy other
parts in addition to another skin. However, before starting this adventure we
may have some discussions about this :slight_smile: - but it may help to make SC usable on
smartphones (Android? MeGoo? others?) that are touch screen based.

I'm afraid that in most of the cases the modifications would be very specific for a particular device. For example in order to become usable on Android we should write a completely new interface from scratch. The same for iphone. It doesn't mean that we shouldn't try to make a common touch screen interface. It's just that I think this would be a tough task and I agree with you that a discussion should be opened and we should start thinking in this direction.

Cheers,
Yana

Cheers,
Yana

On Aug 13, 2010, at 12:56 PM, Werner Dittmann wrote:

Dear all,

with this proposal I step into a field that is somewhat outside my main
expertise. However, I give it a try :slight_smile: .

During the last few days I got some feedback regarding SC's usability on
devices that do not have a keyboard (or only a "soft keyboard") and
use touch screens as their main user interface. The standard SC GUI requires
a keyboard to enter digits and letters, even if I just want to set up a
simple phone call.

To enhance SC's usability I did a small refactoring of the MainFrame class
(see attached TAR file with sources) and splitted it into three parts:
- an interface class, an abstract class and the real MainFrame class.

This refactoring provides a way to add new main GUI classes to accommodate
different needs. The new, touchpad oriented GUI introduces a tabbed pane
that contains a dial pad in one pane an the usual contacts in the second
pane. The use can now touch the digits and other buttons to setup a call
without the need of a keyboard. Which GUI class to use is controlled
by a new property in the user's "sip-communicator.properties" file, the new
property is:

net.java.sip.communicator.TOUCHSCREEN=true

The class "UIServiceImpl" evaluates the property. If set to true it
instantiates the touch pad oriented GUI, if false SC's standard GUI.

Attached are the files that implement the whole stuff (only a few) and
two screenshots that gove you an idea about the touch pad GUI. The implementation
works quite ok, but obviously the real GUI specialists (Yana :wink: ) would
find some waeknesses anyhow.

What do you think? Is it worth to put it into trunk?

Regards,
Werner
<SC-touch4.png><SC-touch3.png><UIServiceImpl.java><DialPanel.java.tar.gz>---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net