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 <dgsiegel gnome org> http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred
Attachment:
signature.asc
Description: This is a digitally signed message part