IM, Contacts & Social hackfest: Conversation: Design: Contact Chooser Design
We want applications to grow Tubes support. This requires two things:
high-level tubes classes (tp-glib have StreamTube + danni has half of DBusTube)
- reusable widget to show contacts
Should this use Telepathy (-> telepathy-gtk) or Folks (-> folks-gtk)?
This design will be implemented by Tiffany's SoC project.
DanielleMadeley: I agree. Certainly in visual look and feel if not sharing code itself.
DanielleMadeley: we should also consider the scope for "meeting management". That is, in a MUC tube you need to be able to view the current members of the "meeting", invite members and potentially kick members (anything else?)
Tiffany's SoC mockup
Notes from the Hackfest
Tiffany Antopolski—Danni's SoC student—needs to be able to pick multiple contacts with whom to share a document from within Evince. There was agreement earlier in the week to add a contact picker (with various modes?) to folks-gtk, to avoid her needing to write yet another one. Allan says, “hey, I designed this”, and projects a selection of mockups. See attachments.
RodrigoMoya: BTW, I wrote a contacts picker for Ubuntu One (using e-d-s) following a design from the Canonical design team that might be a good starting point. The design I followed had, IMO, some issues, but as I said, it might be a good starting point. It's located at http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/files/head:/nautilus/
The widget needs to be able to filter the available contacts based on (for instance) Telepathy contact capabilities. Alex notes that we may also want to filter on non-Telepathy aspects.
Should we hide incapable people fully? Or maybe we should grey them out, so you search for them and they show up but you can't activate them. Allan would show only capable contacts when you're not searching, and when you start searching show all matching contacts, but indicate that some people are not selectable.
Contact groups: we could show all contacts, but have searching “collabora” match the group name as well as the contacts' other details. Allan and Alex note that they are not showing groups in GNOME Contacts; Allan was talked out of it. Allan points out that dealing with work vs. personal divisions is out of the scope of the initial attempt; counter-example of Facebook making groups very accessible precisely to let people separate Work / Friends / Not actually friends.
(Stef mentions that the “friends list” model is wrong: we are each members of a number of overlapping sets of people.)
Second thing that came up which will not be part of folks-gtk: in collaborative apps (eg. shared document editing), you need a way to manage the participants. Invite people, remove people, notice people leaving. Do we need to support a concepts of roles within the group: read-only vs. read-write? We need applications to be able to hook into it: they'll need to be able to add/remove emblems to participants, and add extra buttons.
Allan suggests something similar to the linking concept we have for concepts: on one side, have the current participants; on the other side, have a list of contacts.
(Guillaume wonders: is it worth separating the model and the view, to allow applications to reimplement the view without reimplementing the model.)
Can we leverage the contacts app here: if you select the contact, it opens them up in the contacts app, rather than in a dialog in the window. Ditto chat, says Danni: Empathy (and the messaging tray) can already do that, no need to reimplement it. We would like a way to say “start a text chat with all of these participants” (or ditto voice calls). Perhaps we could represent current sets of participants as temporary groups in any future by-group view, to aid selecting the same people in other applications. We don't have the infrastructure to do this at present, but we could build it. Allan likes using the document as the portal to access the group, rather than trying to communicate that group to other applications. This gets complicated because you may not know how to start other collaborative activities. Telepathy doesn't really provide this right now; Travis notes that we should probably add this.
Do we actually have any collaborative apps? They're starting to appear: Abiword, Gobby over tubes, etc. What are you meant to do with a collaborative PDF, asks Alex? It's a slideshow. Very useful for videoconferenced presentations. Inkscape has its own collaboration, which could work much better if it were using Telepathy. A few designers have been talking about tools they need. They desperately want image editing with real-time chat built in and a log: ideally log the text against versions of the document, so you can look at the discussion yesterday and see the state of the document at the time. “Wave has spoiled you—in a good way!” Google Docs does something like this, albeit without the logs. Danni points out that we have the all the technology to transport the data, but it's currently a pain to actually use it in applications.
We might also want to be able to have fallback options when people can't actually (eg) partake in a document sharing session, but we do have an email address we could at least send them the PDF. Again, similar to Facebook: you can invite your Facebook friends to events, and also type in email addresses to let luddites know about the party. Travis notes that we have a chicken-and-egg problem with cool apps we write which depend on everyone else installing them too. Also he wonders about avoiding writing desktop applications which just reimplement existing web services.
Returning to the contact selector, Guillaume would really like to use it in at least these places in Empathy (See also: 650861):
- When you invite a contact to a room: you can invite anyone who's on the same Telepathy account who's not already in the room. Currently you can see a big list, or you can type to search that list, or to add people by id who are not in the contact list by just typing their JID: they show up in the search results with no presence. We should make it possible to keep this “add by ID” functionality with the new selector widget.
technical note: we need to fix this to not go via handles, because we're interning a tonne of contact IDs into the CM forever. 652832
- New chat and new call: we need a way to add phone numbers, but we also need to be able to enter IDs for calling SIP addresses, or for that matter JIDs/AIM IDs who are not on your roster. If you enter a phone number, you need to be able to select with which account you want to make the call.
Post Hackfest Comments
Futher design work on this topic: