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

Emil Ivov emcho at sip-communicator.org
Thu Aug 26 17:57:05 CEST 2010


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" :-) . 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 :)
>>
>> 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 :-( .
>>>
>>> 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 :) I promise to be very quick in my response next time :) 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 :-) .
>>>>
>>>> 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 :-) - 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 :-) .
>>>>>>>
>>>>>>> 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 ;-) ) 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 at sip-communicator.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help at sip-communicator.dev.java.net

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
emcho at 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 at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net





More information about the dev mailing list