Re: [GnomeMeeting-list] GM 3.00, big changes, already partly introduced in 2.00

["Bruno Hertz" <brrhtz yahoo de>]

Hi Damien, folks

I included some thoughts which spontaneously came to mind, from a user
perspective. They represent just my view, so feel free to ignore them.
Hopefully, one or the other remark might still be of use ...



Damien Sandras <dsandras seconix com> writes:

> The interface of the future...
>
> Following a few polls, on the mailing list, and formerly on the website,
> it appears that GnomeMeeting clearly has two types of users :
> 1) users who want to video chat with family and friends. They don't care
> about the protocol as long as it is easy, and as long as it works.
> 2) corporate users who want to use GnomeMeeting as a softphone with an
> IPBX like Asterisk, or Cisco, or anything else.
>
> There are more users in the first category than in the second,


This is likely to change with SIP support ( and the increased use of Linux
in corporate/public/government environments, of course :) )


> that's
> why I plan to redesign the GUI to ease things for that category of users
> without making things harder for the second category.
>
> Here is the list of use cases for GnomeMeeting :
> 1) I want to call a friend using his phone number via a PC-To-Phone
> provider OR I'm a corporate user who wants to call somebody's real
> phone. I need to enter an URL.
>
> 2) I want to call an online friend. I don't want to have to remember his
> address, so I can put him in my address book. I would like to see if he
> is online or not. LDAP is not well-suited for that as it is not
> real-time. Jabber is well-suited. I just want to double-click on him.
> The URL will be put in the URL bar and the call will begin.
>
> The URL will be known because either we have associated to the user when
> adding it to the address book, or because he is publishing it (through
> Jabber for example).


Not sure what you're getting at. Afaik, what you call is always a URL, i.e.
in the POTS case either, apart from servers you're registered on, where you
may omit the (proto and) domain bit.

So imho at least from the conceptual pov there's no need to distinguish
between numbers and URLs. That's by the way how SIP softphones generally
work, you can dial an URL, where that particular server is contacted as
given in the domain, or simply a number, where it is dialed on the server
you're currently registered on. It's the users choice whether he stores
complete URLs or just numbers in the phone book.

As to LDAP, I presume you mean it isn't realtime with regard to phonebook
storage (?) as opposed to read only access. Well, that may be right, I
actually don't know how it is generally set up in corporate situations,
where I guess you are more likely to find LDAP phone books than on the
internet. So yes, Jabber makes more sense for the common internet user,
while am LDAP backend still would be nice, but second prio from what you
say ...


>
> ---
>
>>From this, we can see that the URL bar should become the second choice
> for calling people. Having to know their URL is not convenient, so most
> calls are done either through ILS or through the address book where we
> have put "bookmarks".
>
> The address book is convenient for the less used URLs and phone numbers,
> or when you want to meet new people publishing their info in the yellow
> pages (ILS), but it is not convenient when you want to call your
> relatives. If there is a person I want to call often, I don't want to
> have to remember his/her URL and I don't want to have to open the
> address book to call him/her.
>
> That's why we need a contacts list.
>
> We can not know if the person is online or not. But SIP allows to send
> text messages. For example, I would have my girlfriend in my contacts
> list, with URL sip:600010123123 seconix com, and without knowing if she
> is online or not, I could message her. If she is present, she will
> answer and I can begin to call.
>
> So having a contacts list for your favorites, and the address book for
> the yellow pages (ILS) and for the contacts you do not call so often
> (phone number of the police, phone number of the talking clock, ...) is
> definitely required.


Isn't that commonly solved by letting the user store some kind of category(ies)
with the contact (cf. e.g. vcard categories)? Like 'family', 'friend', 'biz'
or such, so he can e.g. easily limit his view on the phone book to a particular
group. Plus, he'd have his favs in the history list either. Or do a category
'top ten', where the users default view is limited to those (which is configurable
through prefs, of course). I don't think you want to actually maintain two books.


>
> Having a system to see if the user is online is also required. That can
> be done later through jabber. The contacts list can be extended to
> support Jabber contacts, with a small phone icon next to their nickname
> if they accept H.323 or SIP calls.


That's really an issue where all the standard voip protos seem to be lacking,
i.e. checking the peers availability. Jabber would be nice, but at least in
my environment few people use it. Nothing better comes to mind, though, so
this sure would be a step forward.


>
> The URL bar needs to stay to be able to call other people and phone
> numbers than the ones that are in your address book and in your contacts
> list.


Definitely !!!!! It should be a free form field, where you essentially can
enter what you want.


>
> ---
>
> Here is the proposed design for GnomeMeeting 2.00 (which won't support
> jabber except through GOSSIP, because of the lack of time and of
> developers).
>
> Main GUI :
>
> |-----------------------------|
> | Menu                        |
> |-----------------------------|
> |                             |
> |Fav. | Dialpad | Current Call|
> |Statistics                   |
> |                             |
> |                             |
> |                             |
> |                             |
> |                             |
> |                             |
> |                             |
> |                             |
> |                             |
> |                             |
> |-----------------------------|
> |                       |   | |
> |-----------------------------|
>
>
> * The Fav. tab will contain a sort of roster with 2 categories :
> - the SIP/H323/IAX/Jabber accounts, their status (online/offline) and
> the number of voicemails for each of them, if applicable
> - the contacts without online presence, just an association between a
> name and an url
> - the Jabber contacts, merged with those contacts without online
> presence, and organised in groups of contacts
>
> When clicking on a contact, you will be able to text message him, except
> if he is an H.323 contact. It will only work for SIP and Jabber
> contacts.
>


Hm. Here I see group organization mentioned although it wasn't in the phone
book vs. contact list discussion above. Apart from that, I myself see no
need to group/limit the fav list other than by the aforementioned category.
I.e. it wouldn't be fav, it would be book, as said view limited e.g. by
category or name. Then, when highlighting an entry, you'd have choices
what function to perform on them (buttons, context menu, left/right click
or whatever), i.e. call or SIP/Jabber message them. More precisely, I
wouldn't mix the operation to perform into the list organization. Nice
though to see IAX mentioned here.


> * The Dialpad tab will contain the dialpad.
> * The current call tab will be invisible when there is no call, and
> visible when there is a call. It will display your remote contact and
> sliders to update your video and audio transmission settings


If you want to hide it, do it, although I see no need for it. Actually,
in a tabbed setup, I'd consider it rather unusual behavior. Anyway,
if possible I'd recommend including the chosen codec into the current
call display.


> * The statistics tab will stay the same.


Also, what about some diagnostics somewhere, like control/session package
interchange? Don't know, just an idea since users often enough have to
debug their stuff especially in nated environments. A topic I see often
come up in the * list is one way audio, so some hint whether the client
is actually receiving media would be beneficial I guess (e.g. the current
statistics I see on v1.0.2 includes only totals, from what I understand).


>
> You will notice that the bottom of the UI still has an URL bar with the
> same connect/disconnect button. You will be able to enter URLs for less
> common contacts directly using that URL bar, for example, when using GM
> with Asterisk, and dialing random phone numbers. It will be a quick and
> efficient way to dial.


I'd leave it at the top. Everybody else has it there.


>
> Text Chat:
>
> The text chat window will be separated from the main GUI. That will
> allow resizing it. It will also contain tabs, a bit like GAIM's window
> currently.


I myself wouldn't mind having a restricted messaging tabbed window, since
I don't expect GM to be that multipurpose. If it does voip, and does it
well regarding several protos, including audio quality, latency and stuff,
it will be a killer app. Look at what people are complaining about regarding
linux softphones on the * list: audio quality and latency. Very few are
concerned with messaging, and even more few with video. From own experience,
I can tell you that most linux softphones are not really usable because
either their internal buffering or audio setup makes them a drag. GM used
to be a notable exception, and another is currently coming up, i.e. Xten.
It's in the stage of beta testing, I have it here and it goes pretty well.
To the point that I'm myself considering using it instead of GM until SIP
support is available.


>
> ---
>
> FAQ.
>
> Q1: So, GnomeMeeting will finally become an INSTANT MESSENGER?
> A1: No, GM will not become an instant messenger supporting badly
> videochat and voip, it will be the opposite : a softphone supporting
> instant messenging.
>
> Q2: Will it support proprietary protocols like MSN, Yahoo, SKYPE.
> A2: No, GM is a softphone, not an IM, and my little spare time doesn't
> allow me to spend nights on the reverse engineering of protocols that
> will surely change every 6 months. We also want quality VoIP and
> VideoChatting, not hacks.
>
> Q3: Will it be compatible with Windows?
> A3: It will be ported to Windows (anyone to help?). And it will support
> only STANDARD protocols, so the answer is yes.
>
> Q4: What will it be useful for, if it is not compatible with MSN or
> skype ?
> A4: It is a softphone, not an IM. Try to use Skype with an IPBX. But
> anyway, you are free to use something else. When enough people will use
> something else, I will silently retire and get a decent family life...
>
> ---
>
> Comments?


See above :) Keep up the good work. Great stuff, and highly appreciated,
too.

Regards, Bruno.