Re: Musings on the contacts user experience
On 06/05/11 02:08, Danielle Madeley wrote: On Fri, 2011-04-29 at 17:05 +0200, Guillaume Desmottes wrote: Not really, we could easily imagine being online without having Empathy running without having a people tab: user will just have to start Empathy to see his contact list. If we don't allow that atm, it's mainly because: A) The Shell presence doesn't have a 'Offline' mode or at least a way to properly integrate IM and desktop presence at the same time. Am I the only one who thinks this is simple as: Go Online for Chat and Calls [ Off | On ] No, I agree with you on this. As said before, I think the presence menu should have online/offline presence states and the rest should be done in the background (for all account types) (i.e. no starting separate clients etc). in the bottom of the presence menu? B) Some things (such as muc invitations, incoming file transfer) still require the 'empathy' process to be running. I am strongly looking forward to decoupling the empathy process from changing account presences when it goes on/offline. Me too. -- Regards, Martyn ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 17:05 +0200, Guillaume Desmottes wrote: Not really, we could easily imagine being online without having Empathy running without having a people tab: user will just have to start Empathy to see his contact list. If we don't allow that atm, it's mainly because: A) The Shell presence doesn't have a 'Offline' mode or at least a way to properly integrate IM and desktop presence at the same time. Am I the only one who thinks this is simple as: Go Online for Chat and Calls [ Off | On ] in the bottom of the presence menu? B) Some things (such as muc invitations, incoming file transfer) still require the 'empathy' process to be running. I am strongly looking forward to decoupling the empathy process from changing account presences when it goes on/offline. --danni -- Danielle Madeley Software Developer, Collabora Ltd. Melbourne, Australia www.collabora.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On 29/04/11 17:23, William Jon McCann wrote: So, my quick recommendations: 1. Contacts * A new application exclusive to and designed for GNOME * Searchable through the OS overview - Activating search results opens contact in Contacts app * App is primarily search based as well * Browsing is assisted through index paging * Primary way to initiate new conversations regardless of method * Should seamlessly integrate contacts from various Online Account providers 2. Chat * We initiate a new design exclusive to and designed for GNOME * Serves as the app backing the integrated GNOME chat functionality * Message based - a historical log of conversations * This serves as a record of what chats were performed / missed Hi, I do not understand why the Chat application would need to be based on a historical log of conversations. Such a list would have little consistency over time, making it harder to locate or recognise a particular person to talk to (now, when was the last time I talked to X?). There is clearly some value in it, but maybe it would be more useful as a side functionality than as the primary means of interaction. Real-time communications are opportunistic: you talk to people when they are available. Maybe recognition of current availability is more relevant than history, so a list showing the contacts that are online would work better. On the other hand, such an approach could work well for asynchronous (e.g. e-mail) communications. In this case, search would be preferable as the main way to locate a contact because the collection of contacts would be much greater and because one does not depend on the contact's state to start a communication. Regards, Felipe signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Le Sat, 30 Apr 2011 01:38:30 +1200, John Stowers john.stowers.li...@gmail.com a écrit : On Thu, 2011-04-28 at 16:20 -0400, Matthias Clasen wrote: I'm not sure we really want a separate people tab in the overview. I know it is tempting, now that we have these 'tabs', to just keep adding on there: places, documents, contacts, what have you... but I think it will lead to a clunky experience if we add a separate tab for each class of objects that we want to treat as important. Showing contacts (and documents, etc) in the search results on the other hand, seems like a very natural idea and makes a ton of sense. I'm already concerned with the performance of searching and display of many items in the overview, so I hope this is implemented smartly. I'm not sure if the delay is in rendering the icons, or in walking/filtering the long list of candidate matches in JavaScript, but I have many more contacts than I do applications. When I did the integrate Tracker into shell search experiment, it seemed that the rendering was slow. Ie. calling on time addResults(array of 10 elements) was ok, but calling 10 times addResults(array of 1 element) was horribly slow. Regards, John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Hi,
Travis Reitter wrote:
In general, I think there are a few scales of contact sources we should
consider (from smallest to largest / most- to least-frequent
communication):
* favorites
* local address book, IM contacts, web services (including Facebook)
* remote directory (eg, LDAP)
Having used Android for a few years, I really like having two types of
favourites: starred favourites that you always want to see there, but
who you don't necessarily call very often (sorry Mom!) and frequently
contacted - people who you contact often.
I would be really happy to have something like Thunderbird's
auto-completion heuristic for all applications where you use contacts -
contacts matching what you type are presented in a most frequently
contacted sort order - and while I have no evidence to think so, it
seems like more recent contact gets weighed more heavily too.
Most UIs sort favorites at the top of aggregated local addressbook
and/or IM contacts and leave out directory contacts entirely or require
switching views to see them (as in Evolution).
Android has a separate favourites view, as well as the search as you
type feature in the global view. And also application context specific
presentation of contacts (only contacts with a phone number get shown in
the phone app, only those with an email address in the email app, etc).
I'd prefer an address book to show the aggregate of {local address book,
IM contacts, web service contacts} in browse mode and only reveal
LDAP/huge directory contacts when searching. The nice thing about that
is the user can search for someone and select them as soon as they show
up, simply waiting for the throbber to stop if the person they had in
mind hasn't shown up yet (as the remote search(es) progress).
I like this idea too.
Cheers,
Dave.
--
Dave Neary
GNOME Foundation member
dne...@gnome.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Hey Alex! This is great. I've been doing some work on this recently, and we seem to be thinking about the same problems (good thing!) Alexander Larsson wrote: I've been looking at the contact feature for Gnome 3.2 [1], trying to understand what we want from this and how it would look. The initial page talks about a standalone contacts application, and while I think that is needed its not really the full extent of what we want. Contacts are a large part of social interaction, and social interaction is a huge part of what computers are used for these days. So we want to make these an integrated part of the desktop environment, rather than some external app. This means we want (in addition to any separate app) integration into the shell and the other apps in the desktop. Historically contacts have been just the data in the address book, something you type in once to make sure you don't forget it and then rarely look up. But things have changed. With the advent of social websites, etc we get to skip much of the type in info part, and we should be able to use the available information in many new ways. So, what kind of things do we now want to do with our contacts information? Here is a pretty comprehensive list of things that you might need contact information for. * Initiate direct conversation over the internet. This is typically email or chat, but can also be voip/skype, or e.g. facebook messages. * Initiate communication via external means: snail mail, phone nr You'd look up the data in the contact and write it on a postcard or dial it into your phone (or initiate the call via bluetooth) * Open up personal web pages (facebook page, blog, etc) * Look up information about the person This can be things like birth date, pin code for house, map to house, etc * View recent conversations * Send files to a contact * Export/Import contacts, and easily send them to someone else * Allow DND of contacts to apps, like the evolution composer * Get last known (geographical) location * Get availability status for im * Get last update (facebook, twitter, etc) * Edit contact data * Merge/link contacts from different sources * Extend presentation of contacts in the UI For instance, hovering over an email address shown in an app might show more contact information, including current online status. Obviously an important part of this is a common platform that supports all these features, and we have a bunch of good technologies for this, but I want to start with the user visible side instead. So, how would this look to the user? I'd like to start with email (i.e. evolution). This is where our current address book is, and one obvious step is to remove this in favor of a shared address book dialog. Additionally we need to make sure all the places thats currently using the address book in integrated places, like the email address typeahed, etc, also support all the new data. Overall this is not a large change, the main difference is the address book dialog. I don't think the traditional address book is much used in real life though. Email addresses are almost always looked up directly from the composer (via typeahead or the add addresses dialog), so its unlikely that the changes made here affect how users work with email contacts. This is bad, because we'd like to introduce a workflow that starts from the idea that you're gonna communicate with a person, so you look up the person and then see the available communication routes and chose one. This seems more efficient than starting with selecting a communications method and only then looking up the contact, because you'll be missing a lot of potential information to chose the right method (for instance, when looking up the person you might immediately see that his status is on vacation). In order to introduce this workflow for email we need to get the users used to it for other reasons. Just adding it as a possible way to initiate communications doesn't seem enough. The natural way to do this is via IM. When sending an IM message you always start by finding the person, and then initiate the communications. In a traditional system this is done via the IM main window, and if you think about it that window is really just a contact list. So, lets merge the traditional IM ui with the address book. Resulting in an integrated IM system that is also an entry into other forms of communication (and the other usecases above). This is especially fitting given the partial IM integration we already have in the shell (ability to get notified and reply to IMs, but you have to manually start a not-quite-integrated IM app to send IMs). How would such a ui look? I'm not sure, but to be usable it has to be easy to reach, i.e. it can't be a two-step thing (first find the contacts app, then find the person) it has to be directly available in the shell. The possibilities that I
Re: Musings on the contacts user experience
Hi! * Contacts search (but no contacts tab) in the shell overview, which will provide a quick way to initiate conversations. While I see the point of not having another tab I still think the shell integration of IM currently suffers from the fact that empathy still needs to be around and displays it's contact list. And I currently see no better way to resolve this than to have some kind of Contact list embedded into the shell that displays all online contacts without the need to search for them. People often have weird nicknames anyway, that I don't remember but which I can recognize when I see them in a list and searching is not particularly helpful here. This is related but not quite the same as contact management for the whole desktop. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Thu, 2011-04-28 at 16:20 -0400, Matthias Clasen wrote: I'm not sure we really want a separate people tab in the overview. I know it is tempting, now that we have these 'tabs', to just keep adding on there: places, documents, contacts, what have you... but I think it will lead to a clunky experience if we add a separate tab for each class of objects that we want to treat as important. Showing contacts (and documents, etc) in the search results on the other hand, seems like a very natural idea and makes a ton of sense. I'm already concerned with the performance of searching and display of many items in the overview, so I hope this is implemented smartly. I'm not sure if the delay is in rendering the icons, or in walking/filtering the long list of candidate matches in JavaScript, but I have many more contacts than I do applications. Regards, John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 13:19 +0100, Allan Day wrote: In general, then, my current position is that, despite it not being the primary way in which people will access messaging, we do still need a dedicated contacts app. I am open to being convinced that an integrated IM/contacts app would work, but I would want to see the 3 issues I've identified above resolved. Yeah, this, and the fact that Gnome 3.0, with gnome-shell and the non-spatial nautilus is very much going in the app-centric direction convinces me that you are right. That means we should probably not have the people tab, which is a good thing too as i kinda agree with matthias fear of piling all sorts of cruft into overview tabs. Also, we should probably not allow contacts on the dash. Until I'm convinced otherwise, this is my vision for how the different GUI parts of our contacts framework, then: * An add contacts dialog that can be used by different applications. This would, for instance, provide a graphical means to easily add recent or favourite contacts to an email. This GUI would probably be similar to the contacts app, and would probably share the same code base. * A dedicated contacts app for when you need it. * Contacts search (but no contacts tab) in the shell overview, which will provide a quick way to initiate conversations. * In the future - a conversation focused IM app, and possibly even a conversation focused email app Yes, I like this. The conversation focused IM app is especially nice, as it makes the difference between the contacts app and the chat app much more obvious. It also means that some of the concept design on the contacts app needs a bit of rethinking, as they focus quite a bit on initiating IM communication (via shortcuts on the main window, etc). Additionally I'd like to have an easy-to-integrate widget that lets apps pop up contact information on hover/click on any address shown in the ui (like all visible email addresses in evo). That would show contact info, current im status, last tweet, etc. My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. * I fear as we add more kinds of hits into the overview search it will eventually become useless (giving too many hits). We need to be consious about this and limit the number for items we search. For instance, if we search in all files on your system its likely that almost all words you type matches a bunch of files, making the typeahead to launch an app feature less useful. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 16:13 +0200, Alexander Larsson wrote: On Fri, 2011-04-29 at 13:19 +0100, Allan Day wrote: In general, then, my current position is that, despite it not being the primary way in which people will access messaging, we do still need a dedicated contacts app. I am open to being convinced that an integrated IM/contacts app would work, but I would want to see the 3 issues I've identified above resolved. to me it seems that it is not a question of what, but more like where. to me personally it doesn't matter if i can access my contacts through evolution, a dedicated app or a gnome-shell panel. it is more important to access my contacts where ever i am, be it my laptop, my computer at home, my phone or an internet cafe. an amazing thing would be to have them stored and synchronised (for example with couchdb) on my computer, my phone and on contacts.gnome.org as a web-app. as long as all the data stays accessible and synchronised from all places the ui and user experience is more a question of what the device and input methods can allow me on that device. daniel Yeah, this, and the fact that Gnome 3.0, with gnome-shell and the non-spatial nautilus is very much going in the app-centric direction convinces me that you are right. That means we should probably not have the people tab, which is a good thing too as i kinda agree with matthias fear of piling all sorts of cruft into overview tabs. Also, we should probably not allow contacts on the dash. Until I'm convinced otherwise, this is my vision for how the different GUI parts of our contacts framework, then: * An add contacts dialog that can be used by different applications. This would, for instance, provide a graphical means to easily add recent or favourite contacts to an email. This GUI would probably be similar to the contacts app, and would probably share the same code base. * A dedicated contacts app for when you need it. * Contacts search (but no contacts tab) in the shell overview, which will provide a quick way to initiate conversations. * In the future - a conversation focused IM app, and possibly even a conversation focused email app Yes, I like this. The conversation focused IM app is especially nice, as it makes the difference between the contacts app and the chat app much more obvious. It also means that some of the concept design on the contacts app needs a bit of rethinking, as they focus quite a bit on initiating IM communication (via shortcuts on the main window, etc). Additionally I'd like to have an easy-to-integrate widget that lets apps pop up contact information on hover/click on any address shown in the ui (like all visible email addresses in evo). That would show contact info, current im status, last tweet, etc. My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. * I fear as we add more kinds of hits into the overview search it will eventually become useless (giving too many hits). We need to be consious about this and limit the number for items we search. For instance, if we search in all files on your system its likely that almost all words you type matches a bunch of files, making the typeahead to launch an app feature less useful. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 16:13 +0200, Alexander Larsson wrote: My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. This is not really true. You can be online without having a chat application (e.g. empathy) running. The connection managers will run in the background with no UI. When a new chat message comes in, mission-control will dispatch it to the correct application (starting that application if necessary). You just need something to tell mission-control to go online (or away, or whatever other status you want). Right now this is handled by the empathy application, but it could easily be something that is built into the shell. In this setup you have no issue with conceptual minimize issues. jonner ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 09:30 -0500, Jonathon Jongsma wrote: On Fri, 2011-04-29 at 16:13 +0200, Alexander Larsson wrote: My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. This is not really true. You can be online without having a chat application (e.g. empathy) running. The connection managers will run in the background with no UI. When a new chat message comes in, mission-control will dispatch it to the correct application (starting that application if necessary). You just need something to tell mission-control to go online (or away, or whatever other status you want). Right now this is handled by the empathy application, but it could easily be something that is built into the shell. In this setup you have no issue with conceptual minimize issues. Maemo 5 (N900)'s implementation is superb on this topic. You have a dedicated chat application but you almost never use it. The normal flow is to either click on a shortcut on the desktop, or type a name's first letters directly at the desktop, and you can start a conversation right away. Notification bubbles are very nicely integrated with the WM to shw incoming messages and morph them into a conversation window as needed. There's also a contact widget to be used by applications, in addition to the address book which enables advanced operations (such as editing contacts, merging, etc.). Lots of thought has been poured in it apparently, and it looks hard to do any better. Xav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Le vendredi 29 avril 2011 à 14:31 +0200, Johannes Schmid a écrit : Hi! * Contacts search (but no contacts tab) in the shell overview, which will provide a quick way to initiate conversations. While I see the point of not having another tab I still think the shell integration of IM currently suffers from the fact that empathy still needs to be around and displays it's contact list. And I currently see no better way to resolve this than to have some kind of Contact list embedded into the shell that displays all online contacts without the need to search for them. Not really, we could easily imagine being online without having Empathy running without having a people tab: user will just have to start Empathy to see his contact list. If we don't allow that atm, it's mainly because: A) The Shell presence doesn't have a 'Offline' mode or at least a way to properly integrate IM and desktop presence at the same time. B) Some things (such as muc invitations, incoming file transfer) still require the 'empathy' process to be running. We should really think about the best way to solve A) and I'm planning to improve things regarding B). G. -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Le vendredi 29 avril 2011 à 09:30 -0500, Jonathon Jongsma a écrit : On Fri, 2011-04-29 at 16:13 +0200, Alexander Larsson wrote: My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. This is not really true. You can be online without having a chat application (e.g. empathy) running. The connection managers will run in the background with no UI. When a new chat message comes in, mission-control will dispatch it to the correct application (starting that application if necessary). You just need something to tell mission-control to go online (or away, or whatever other status you want). Right now this is handled by the empathy application, but it could easily be something that is built into the shell. In this setup you have no issue with conceptual minimize issues. Actually that's already what's happening in GNOME 3.0: the Telepathy chat handler has been removed from empathy's main process and now lives in empathy-chat. This process is started automatically when we start a new chat or receive a new message and stops when there is no more chats to handle (user closes all the chat window + some timer). G. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Hi, Some very brief thoughts. On Fri, Apr 29, 2011 at 10:13 AM, Alexander Larsson al...@redhat.com wrote: On Fri, 2011-04-29 at 13:19 +0100, Allan Day wrote: In general, then, my current position is that, despite it not being the primary way in which people will access messaging, we do still need a dedicated contacts app. I am open to being convinced that an integrated IM/contacts app would work, but I would want to see the 3 issues I've identified above resolved. Yeah, this, and the fact that Gnome 3.0, with gnome-shell and the non-spatial nautilus is very much going in the app-centric direction convinces me that you are right. That means we should probably not have the people tab, which is a good thing too as i kinda agree with matthias fear of piling all sorts of cruft into overview tabs. Also, we should probably not allow contacts on the dash. Another thing is that using Overview views for information types that are nearly unbounded like people is really difficult. Browsing isn't really a good interface for things like this. More on this below. Until I'm convinced otherwise, this is my vision for how the different GUI parts of our contacts framework, then: * An add contacts dialog that can be used by different applications. This would, for instance, provide a graphical means to easily add recent or favourite contacts to an email. This GUI would probably be similar to the contacts app, and would probably share the same code base. * A dedicated contacts app for when you need it. * Contacts search (but no contacts tab) in the shell overview, which will provide a quick way to initiate conversations. * In the future - a conversation focused IM app, and possibly even a conversation focused email app Yes, I like this. The conversation focused IM app is especially nice, as it makes the difference between the contacts app and the chat app much more obvious. It also means that some of the concept design on the contacts app needs a bit of rethinking, as they focus quite a bit on initiating IM communication (via shortcuts on the main window, etc). Additionally I'd like to have an easy-to-integrate widget that lets apps pop up contact information on hover/click on any address shown in the ui (like all visible email addresses in evo). That would show contact info, current im status, last tweet, etc. I agree we need both a people app (Contacts) and a messages app (Chat). There are key differences between people and messages: 1. People * Frequency and recency are basically meaningless (recent what?) * Browsing based interfaces aren't practical without heavy use of pages, indexes, tags, groups, etc * Search (or search assisted direct entry) is the primary mode of access 2. Messages * Recency is most important because it indicates currency * Frequency (with windowing) is important because it indicates durable relationships * Browsing history is relevant for finding and reminding * Resuming from a history is the primary mode of access Those are the big differences I think. There are lots of other more subtle distinctions of course. For example, in how starring, or bookmarking works. Different enough to deserve treatment in separate apps. So, my quick recommendations: 1. Contacts * A new application exclusive to and designed for GNOME * Searchable through the OS overview - Activating search results opens contact in Contacts app * App is primarily search based as well * Browsing is assisted through index paging * Primary way to initiate new conversations regardless of method * Should seamlessly integrate contacts from various Online Account providers 2. Chat * We initiate a new design exclusive to and designed for GNOME * Serves as the app backing the integrated GNOME chat functionality * Message based - a historical log of conversations * This serves as a record of what chats were performed / missed My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. The chat app doesn't have to be running, really. The OS shell itself will happily receive that new message for you. The issue is really more about sign in and sign out. * I fear as we add more kinds of hits into the overview search it will eventually become useless (giving too many hits). We need to be consious about this and limit the number for items we search. For instance, if we search in all files on your system its likely that almost all words you type matches a bunch of files, making the typeahead to
Re: Musings on the contacts user experience
Hi Dave, On Fri, 2011-04-29 at 10:46 +0200, Dave Neary wrote: Hi, Travis Reitter wrote: In general, I think there are a few scales of contact sources we should consider (from smallest to largest / most- to least-frequent communication): * favorites * local address book, IM contacts, web services (including Facebook) * remote directory (eg, LDAP) Having used Android for a few years, I really like having two types of favourites: starred favourites that you always want to see there, but who you don't necessarily call very often (sorry Mom!) and frequently contacted - people who you contact often. What are some use cases for the set (favorites - frequent contacts)? Thinking of Tomboy, which has both favorites and sorting by recency, I have a couple items in that set, and they'd be better off the list (they're only there because I added them as favorites a long time ago and haven't removed them since). If I really want to reach those notes, I can just search for them. I would be really happy to have something like Thunderbird's auto-completion heuristic for all applications where you use contacts - contacts matching what you type are presented in a most frequently contacted sort order - and while I have no evidence to think so, it seems like more recent contact gets weighed more heavily too. We could/should do something like a PID controller [1] to factor in both recency of communication and total volume in a smooth way. If you suddenly communicate with someone a lot, they'll quickly rise in the list. But they'll slowly drift down the list as time goes on (if you don't maintain communication with them). I believe Telepathy Logger already does something to this effect. Most UIs sort favorites at the top of aggregated local addressbook and/or IM contacts and leave out directory contacts entirely or require switching views to see them (as in Evolution). Android has a separate favourites view, as well as the search as you type feature in the global view. And also application context specific presentation of contacts (only contacts with a phone number get shown in the phone app, only those with an email address in the email app, etc). Regards, -Travis [1] http://en.wikipedia.org/wiki/PID_controller ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
Hi, Travis Reitter wrote: What are some use cases for the set (favorites - frequent contacts)? It's like recent documents, I suppose. Cell-phone/SMS/chat - recent calls/message history And in the Contact app, it'd be like a speed dial tab - the people you speak with most sitting right there. I guess it's a feel-good feature to have someone's close friends all collected together, like a list on Twitter. Thinking of Tomboy, which has both favorites and sorting by recency, I have a couple items in that set, and they'd be better off the list (they're only there because I added them as favorites a long time ago and haven't removed them since). If I really want to reach those notes, I can just search for them. There are a couple of notes I have pinned in the list, I only need them once or twice a month, but searching for them when I do need them is an extra step, a hassle I don't want. Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 14:31 +0200, Johannes Schmid wrote: them. People often have weird nicknames anyway, that I don't remember but which I can recognize when I see them in a list and searching is not particularly helpful here. I don't think this will be too big of an issue for most people. Telepathy and Folks can fetch extended info from contacts, so all Facebook (and most other web service contacts) will contain some version of their real name. If not (eg, you only have IM accounts and some contacts have obscure usernames), you can always alias your contacts to their real name to make real name searches work. -Travis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
(Sent again, didn't seem to reach the list last time) On Fri, 2011-04-29 at 11:23 -0400, William Jon McCann wrote: Another thing is that using Overview views for information types that are nearly unbounded like people is really difficult. Browsing isn't really a good interface for things like this. More on this below. Clearly if we do this we'd show some limited subset, but even just the local contacts can be sort of large. So, my quick recommendations: 1. Contacts * A new application exclusive to and designed for GNOME * Searchable through the OS overview - Activating search results opens contact in Contacts app * App is primarily search based as well * Browsing is assisted through index paging * Primary way to initiate new conversations regardless of method * Should seamlessly integrate contacts from various Online Account providers 2. Chat * We initiate a new design exclusive to and designed for GNOME * Serves as the app backing the integrated GNOME chat functionality * Message based - a historical log of conversations * This serves as a record of what chats were performed / missed This sounds good to me. The only thing I'm not sure about is that that contacts app is the primary way to initiate converstation. That seems very weird, as the rest of say an IM conversation will be done in the chat app. It seems more likely that people would start in the chat app when they're initiating a chat. My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. The chat app doesn't have to be running, really. The OS shell itself will happily receive that new message for you. The issue is really more about sign in and sign out. I'm well aware that technically there is no need for a UI app to be running all the time. When i say chat app running I'm talking about the mental model in the user, where you typically need something running to get feedback from it. But, you're right, this is really more about sign in/out rather than the actual app running. So if we were to have sign in done via the shell somewhere (and feedback on whether we're online or not), then that would probably be enough, and if you wanted to look at previous converstation or start a new one you could just open the chat app as if you were starting an app. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Thu, Apr 28, 2011 at 8:43 AM, Alexander Larsson al...@redhat.com wrote: * An icon in the system tray area which gives dropdown with online and recent contact shortcuts, as well as an item to open the contacts. * A people tab in the overview * Return contacts when searching in the overview None of these are imho ideal. The search one is very efficient, but not very discoverable, so it must be combined with something else. The icon in the system tray is not really matching the purpose of the system area (to show the state of the system). The people tab while good for fast lookups, will not be able to give the full set of features outlined above (being pretty low in UI complexity), and will make it hard to interact with other apps (via e.g. dnd). So it can't replace a full address book dialog, and doesn't make it natural to reach it quickly. Here is a start idea of a possible UI that builds on a combination of the above: * The address book is multi-window. The main window lists contacts in very short form, and allows searching grouping, sorting, filtering, selection, adding, removing, etc. It also has a few shortcuts on each contact to quickly start a conversation, but the main operation on each contact is bringing up a separate window with the contact information, status and possible operations. It probably looks something like the two-pane design on http://live.gnome.org/Design/Apps/Contacts * The overview gets a new tab people which contains a subset of the contacts information (online, favorites, recently contacted, etc) with a small preview of the contact (picture, name, nick, im status, last tweet, last IM, etc). Clicking on it will bring up the contact in a window, just like in the address book. * Search in the overview includes search hits from the full set of contacts, looking and working similarly to the people tab entries. * Make it possible to go online on IM from the user menu * Add a shortcut to the address book on the dash by default. The weakest part of this is imho the dash shortcut, as it makes the contacts dialog seem like an external app rather than a core thing, but I can't find a better place for it. We may also want to allow adding contacts to the dash, just to make the contacts a first class citizen of the overview, but i'm not sure how useful this is in practice. Hey Alex, thanks for these thoughts. I agree with most of them, so I'll just point out the few things where I see things differently or would put a different emphasis. One more addition for your 'tasks involving contacts' list: * Schedule a meeting and invite participants I'm not sure we really want a separate people tab in the overview. I know it is tempting, now that we have these 'tabs', to just keep adding on there: places, documents, contacts, what have you... but I think it will lead to a clunky experience if we add a separate tab for each class of objects that we want to treat as important. Showing contacts (and documents, etc) in the search results on the other hand, seems like a very natural idea and makes a ton of sense. Wrt to the contacts app: For better or worse, the gnome3 design is app-centric, so we should not avoid making things 'external apps' - quite the contrary, we need to encourage strong, new apps to make the shell design really work out. So I am all for making the contacts an app; that doesn't prevent it from being a well-integrated part of the experience. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Thu, 2011-04-28 at 16:20 -0400, Matthias Clasen wrote: One more addition for your 'tasks involving contacts' list: * Schedule a meeting and invite participants Speaking of corporatey use cases, the traditional address book is still used as a view of directory services like a company roster on an LDAP or Exchange server, where you might have tens of thousands of entries that your IT department keeps up-to-date for you. Granted I don't know how much time people really spend browsing these things, but it wasn't really clear from your musings if you're also targeting the corporate world or if this is more about keeping in touch with Facebook friends. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Thu, 2011-04-28 at 14:43 +0200, Alexander Larsson wrote: So, what kind of things do we now want to do with our contacts information? Here is a pretty comprehensive list of things that you might need contact information for. snip Another long-term (after Gnome 3.2) class of use cases I'd like is: * Start application-specific communication with someone where this could be a game of chess through a chess program, collaborative document editing through Gedit/Abiword/etc, pair programming in Anjuta/Eclipse, multi-user GIMP sessions (has anyone said they need to change their name?), remote music recording sessions. The potential for productivity, education, and entertainment here is really high. It's not like these programs couldn't already support these features (some do, to some degree, though I think few efforts have been merged to mainline), but I think they haven't thus far because they've been stuck choosing between: * entering IP addresses manually and resolving NAT/firewall issues (which is an obvious non-start for most users, including myself) * setting up an account system hosted on a server (which obviously gets into a bunch of issues of its own) We should be able to avoid both of these issues (particularly the firewall issue) by using Telepathy Tubes and making the process of starting this communication as seamless as possible through Folks/Gnome Shell/etc. So, this would obviously be a bit of work (particularly on getting these programs to integrate well), but I think it's a very nice set of goals to keep in the back of our minds. This is bad, because we'd like to introduce a workflow that starts from the idea that you're gonna communicate with a person, so you look up the person and then see the available communication routes and chose one. This seems more efficient than starting with selecting a communications method and only then looking up the contact, because you'll be missing a lot of potential information to chose the right method (for instance, when looking up the person you might immediately see that his status is on vacation). I think this is one of the most important changes to focus on to improve the user experience (making communications Person - method instead of method - application - Person). In order to introduce this workflow for email we need to get the users used to it for other reasons. Just adding it as a possible way to initiate communications doesn't seem enough. The natural way to do this is via IM. When sending an IM message you always start by finding the person, and then initiate the communications. In a traditional system this is done via the IM main window, and if you think about it that window is really just a contact list. So, lets merge the traditional IM ui with the address book. Resulting in an integrated IM system that is also an entry into other forms of communication (and the other usecases above). This is especially fitting given the partial IM integration we already have in the shell (ability to get notified and reply to IMs, but you have to manually start a not-quite-integrated IM app to send IMs). How would such a ui look? I'm not sure, but to be usable it has to be easy to reach, i.e. it can't be a two-step thing (first find the contacts app, then find the person) it has to be directly available in the shell. The possibilities that I see are: * An icon in the system tray area which gives dropdown with online and recent contact shortcuts, as well as an item to open the contacts. I'm a little wary about adding a permanent tray icon (though maybe the Gnome Shell people can jump in here) considering how many other methods we would have to contact people (depending on how many of these ideas we implement). At the least, I think it should be pinned to the right side to take advantage of the corner. * A people tab in the overview I agree with Matthias that we should make sure the People table would be particularly useful. With careful design, I think we could make it a decent alternative to search (for people who would rather browse). Though, honestly, the only 2 times I've opened the Applications tab were to compare it to Gnome 3 review screenshots. I'm a power-user, though, since I know the names of most programs I want to use (but gnome-shell/the .desktop files do a decent job of matching by generic names). * Return contacts when searching in the overview None of these are imho ideal. The search one is very efficient, but not very discoverable, so it must be combined with something else. The I think Google has shown that most people can wrap their head around Search String - many types of results. And, at the very least, I think you only have to be shown once that people are searchable to grasp the concept. So featuring it in tutorials, help sections and marketing for Gnome could pick up a chunk of the users who might not guess it's supported. Maybe we could change the default search text
Re: Musings on the contacts user experience
On Thu, 2011-04-28 at 16:43 -0400, Matthew Barnes wrote:
On Thu, 2011-04-28 at 16:20 -0400, Matthias Clasen wrote:
One more addition for your 'tasks involving contacts' list:
* Schedule a meeting and invite participants
Speaking of corporatey use cases, the traditional address book is still
used as a view of directory services like a company roster on an LDAP or
Exchange server, where you might have tens of thousands of entries that
your IT department keeps up-to-date for you.
In general, I think there are a few scales of contact sources we should
consider (from smallest to largest / most- to least-frequent
communication):
* favorites
* local address book, IM contacts, web services (including Facebook)
* remote directory (eg, LDAP)
Most UIs sort favorites at the top of aggregated local addressbook
and/or IM contacts and leave out directory contacts entirely or require
switching views to see them (as in Evolution).
I'd prefer an address book to show the aggregate of {local address book,
IM contacts, web service contacts} in browse mode and only reveal
LDAP/huge directory contacts when searching. The nice thing about that
is the user can search for someone and select them as soon as they show
up, simply waiting for the throbber to stop if the person they had in
mind hasn't shown up yet (as the remote search(es) progress).
Folks only supports enumerated contact stores now, but we should be
addressing this as part of bgo#646808 (or a bug we'll split off of it).
Granted I don't know how much time people really spend browsing these
things, but it wasn't really clear from your musings if you're also
targeting the corporate world or if this is more about keeping in touch
with Facebook friends.
Personally, I don't see the point of supporting browsing through huge
directories. I'd rather we support it in search (as above) and make it
dead-obvious (if) more people are available through search than browsing
(possibly through clarifying search box text).
-Travis
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
