GNOME Bugzilla – Bug 629902
New call UI
Last modified: 2012-03-28 15:52:37 UTC
For 3.0 we'd like to create a new audio/video UI. Requierements: - Keep the same features as the current one - Use the new Call API: http://telepathy.freedesktop.org/spec/Channel_Type_Call.html - Muji support (bug #599168) but the first version could be 1-1 only as a first step Ideally, it would be cool if it allows us to fix some other bugs in the process (maybe not in the first iteration) - In fullscreen mode, display our preview on top of the remote video (bug #582442) - Alllow to change audio input (bug #590048) - Allow to change video input (bug #599167) - Be able to record calls (bug #593605) - Support to "hold on" (bug #623348)
(In reply to comment #0) > - Use the new Call API: > http://telepathy.freedesktop.org/spec/Channel_Type_Call.html I opened bug #629903 regarding Call support so we can use this bug to focus on the UI part. Also, we don't have to wait that Call is undrafted. As this new UI will be a new channel handler, we can keep the current UI and the right one will be used depending of the type of the channel (StreamedMedia or Call). yeah MC!
Created attachment 172859 [details] first iteration of some wireframes for emapthy video chat A first iteration of a design for this sort of thing. Still todo: * audio only calls. * Possibly some more settings integration. * The window menu for the video chat window. * Switch video and audio sources * Call recording
Hi Nick. Thanks a lot, this looks like a really good start. I have a few questions though: • You moved the dialpad to the toolbar which is fine, but the current UI has more pages in the sidebar: ∘ audio input: I guess that's replaced by the microphone in the bottom toolbar? ∘ video input: to tweak the video we send ∘ details: display debug info Maybe they could be display using the view menu or something? They are not so important so that's fine if they are less accessible. • Page 4, 1.0 : Isn't the 'Disable Camera' button redudant with the other camera in the bottom toolbar? • Swap Camera should probably be "Switch Camera" if there are more than one cam, as it's not guarantee to have exactly 2 cams. • We should have a way to invite people to a multi party call
Video input and debug stuff will be in the menu if at all. As I mentioned above those menus are still todo. Simple audio input stuff would be with the mic more complicated setup would need a more complicated setup. I certainly want to think a little more on multiple microphones, speakers etc. Disable camera shouldn't be there on you, correct. This was part of the stuff for managing other people. I'll remove it. I'll do the swap/switch transition and add information on the rotation there. Ah, the magic of a multi-party call. I was trying to stay away from the call setup in the short term but there'll certainly be something in the menu. Would we be able to drag a contact onto the window to invite them as well? I'll update the wireframes with these changes.
(In reply to comment #4) > Ah, the magic of a multi-party call. I was trying to stay away from the call > setup in the short term but there'll certainly be something in the menu. Would > we be able to drag a contact onto the window to invite them as well? Yeah that should be doable.
Created attachment 173087 [details] second iteration of the wireframes this should address most of the comments above and fixes the majority of the remaining todos. notifications would be good to improve, but not necessary for this to proceed. I'm on holiday for the next week so responses will be a little slower than normal.
*** Bug 643801 has been marked as a duplicate of this bug. ***
Hey Nick, I'm working on the Call UI and was wondering how to implement incoming calls (a way to accept/refuse an incoming call from an existing call window). Any chance you can update the mockups with that? Or put your thoughts in a comment if you're too busy :)
We also need to think of a way to show detailed connection statuses (see bug #618567). Perhaps "%status: %detailed_status", such as "Disconnected: unauthorized" or "Disconnected: call refused" ? I expect to mostly happen when a call fails (i.e. when disconnected). Or maybe we can just put whatever string we want in the status bar, as long as it's understandable.
(In reply to comment #8) > I'm working on the Call UI and was wondering how to implement incoming calls (a > way to accept/refuse an incoming call from an existing call window). Any chance > you can update the mockups with that? Or put your thoughts in a comment if > you're too busy :) A modal popup on the call window? They are not so terrible as they use to be in GNOME 2 and it would be clearer than a small icon becoming sensitive.
Some additions, in normal and group calls it would be nice to be able to start a private chat with the target. I was thinking of one more item in the right click menu. Also, there is no mention of main video background for space not covered by video. Currently, the background behind the video window is grey which is not that nice looking, I think it could be changed to black, like in totem.
Some notes about the mockup: The pause symbol for Hold is not clear to me, I would use the word "Hold". It's impossible to not support DTMF, farsight will send DTMF as audio if DTMF events are not supported. Why are the audio input and output volumes in separate places ? Also, in the assets to draw, we'll need a "hold" image that can be sent to the other side if we stop sending video to a protocol that doesn't support that natively. This way, we can make sure that a call can always be held and allow multiple calls at the same time. Also, we may want something in the desktop shell to indicate to the user that he is currently in an active call (as a privacy thing).
Another missing thing is that we may want to integrate text chat with the video chat in the same UI. Many protocols actually allow video and text chat using the same group.
(In reply to comment #12) > It's impossible to not support DTMF, farsight will send DTMF as audio if DTMF > events are not supported. A CM may not implement the Hold interface though. Empathy only makes the dialpad in the call window sensitive if the given CM implements it.
Nick, I see the remote video (not the local preview) also has an "i" button. What options should that button contain?
(In reply to comment #3) > • You moved the dialpad to the toolbar which is fine, but the current UI has > more pages in the sidebar: > ∘ audio input: I guess that's replaced by the microphone in the bottom toolbar? > ∘ video input: to tweak the video we send These two should go to a new tab in the preferences as per page 14 of the wireframes, right? We can change the contrast/brightness/gamma at the moment from "Video input", maybe we should add that to the preferences somehow? > ∘ details: display debug info > Maybe they could be display using the view menu or something? They are not so > important so that's fine if they are less accessible. We need to think of a way to show this, if we want to show it at all.
There is the bottom toolbar with some buttons, and there's also a statusbar with "Calling...", "Foo is not answering", "Call refused". I wonder what should we do with the toolbar while the statusbar is shown. Should we ever show both at the same time? Or should we hide the toolbar while the statusbar is shown?
Currently one replaces the other. They can't be shown at the same time.
The main Empathy window has Help->Debug. We should probably do the same in the call window, instead of Help->Call log, which can be confused with History. Also, any reason for Fullscreen to be in Call and not in View? Other than 'View would only have one item' :-)
Partly because it would lead to a single item menu which is super bad, but partly because it really is a call related option. As for the string, I think Help -> Debug call would be better than either of the above, would that be OK?
(In reply to comment #20) > As for the string, I think Help -> Debug call would be better than either of > the above, would that be OK? Help->Debug is what I said above, and yes, it would be OK :-) I'll use that.
(In reply to comment #20) > Partly because it would lead to a single item menu which is super bad, but > partly because it really is a call related option. Atm that's the only item in the 'Call' menu.
Updated wireframes: http://nickr.org/linux/wireframes/empathy-video-chat-wireframes.pdf These cover a number of other bugs as well now, but they're still broadly call focused. I am minded to move the full screen toggle onto the toolbar full time, since in real life there's plenty of space on all screens and it has to be there for full screen anyway. This means we can lose the call menu. If others agree I'll do an update of the wireframes to show that but I wanted to get something out quickly.
Created attachment 194388 [details] third iteration of the wireframes
(In reply to comment #23) > I am minded to move the full screen toggle onto the toolbar full time, > since in real life there's plenty of space on all screens and it has to be > there for full screen anyway. This means we can lose the call menu. If others > agree I'll do an update of the wireframes to show that but I wanted to get > something out quickly. Sounds like a good idea to me. I don't really like it in the call menu atm.
Any reason you don't hold the current call when answering a second call? And I still think we should investigate integrating the chat and call uis into a single window.
(In reply to comment #26) > Any reason you don't hold the current call when answering a second call? And I > still think we should investigate integrating the chat and call uis into a > single window. Current technical limitations. My initial design was for an integrated call and chat window but I was asked to keep it separate for now. However the design can easily be integrated into a future new chat window, from a design perspective it's pretty componentised. As for call holding, there's a partly technical, partly design reason. I don't want to hold the call without the users permission. However I would very much like to be able to put a call on hold whilst answering another - however we can currently only have one concurrent call so when that's fixed we can add that.
The technical bit about holding calls is relatively easy, that's what we've been doing in Maemo 5 and 6. But I agree that we should have a single active call. Maybe there shuold be a "hold active call and answer" button or something instead of "end active call and answer new one". But then the UI probably needs to reflect the held call so the user can end it. That's how cell phones seem to work.
Having worked on a couple of GSM call UIs I can say that they are annoying to design ;-) "Hold call and answer" is certainly Sjoerd's favoured option. I'll have a think and see where we could fit a held call into the UI, especially in some of the worst case multi party calls.
We've implemented a floating toolbar, the wireframes should show that :-) It's possible in some protocols to have a call fail because you don't have enough credit. We should have a place to show such an error with an optional link/button to buy some credit.
(In reply to comment #30) > It's possible in some protocols to have a call fail because you don't have > enough credit. We should have a place to show such an error with an optional > link/button to buy some credit. I think that's bug #618567 we should do a better job at error reporting.
Removing bug #618567 bug #623348 and bug #652998 as dependencies. We can fix that later. The Call1 branch has been merged to master so all we still have to do is to make empathy-call the new default. :)
Created attachment 208127 [details] [review] always build empathy-call
Created attachment 208128 [details] [review] Stop approve StreamedMedia channels
Created attachment 208129 [details] [review] Drop empathy-av So long and thanks for all the calling...
Created attachment 208130 [details] [review] Stop requesting StreamedMedia channels
Review of attachment 208127 [details] [review]: ++
Merged to master. Congratulations to everyone involved in this huge work!
Did this meet the original goals? These are be done (fuck yeah!): - In fullscreen mode, display our preview on top of the remote video (bug #582442) - Alllow to change audio input (bug #590048) - Allow to change video input (bug #599167) - Use the new Call API: http://telepathy.freedesktop.org/spec/Channel_Type_Call.html - Keep the same features as the current one But these remain open: - Muji support (bug #599168) but the first version could be 1-1 only as a first step - Be able to record calls (bug #593605) - Support to "hold on" (bug #623348)