ulc-devs team mailing list archive

[Frederik Elwert <frederik.elwert@xxxxxx>]

Hello all,

Am Freitag, den 25.11.2011, 18:10 +0100 schrieb Patrick Seemann:

> I found the Document which discusses various Unity Design proposals.
> (you can read this if you need some more information about
> it: http://www.mail-archive.com/ayatana@xxxxxxxxxxxxxxxxxxx/msg05723.html)
> 
> 
> I've attached the page (pdf) which illustrates the so called "People"
> lens. As the name suggests, the lens gathers contact information from
> multiple source, such as email, social networks and regular contacts
> (via gnome contacts). The proposal also suggests that the contact
> information are displayed inside the dash and not via an external
> application (such as gnome contacts).
> 
> 
> Even though the design proposal looks interesting, I think it is not
> possible to implement with the current lenses api. I haven't found any
> information on whether somebody has worked on this particular proposal
> already and if so, how an implementation would roughly look like.

This was also my impression: They propose ideas how lenses could be
extended in the future, but this is not possible with the current APIs.

> Does anybody know if it is possible to have a list of contacts in one
> view (like the mockup shows) and another view that displays the
> details for the selected contact? that would require two views which
> you can independently update to show requested information.
> 
> 
> To me it seems like the design of this People lens destroys the
> purpose of the dash in some way. As far as I know, the Dash (and
> scopes) are supposed to be an interface through which you can search
> various things and that's it. Designing such a people lens is like
> integrating a complete contacts application into the dash. It's like
> creating a calculator lens that has buttons and everything just like
> the regular gcaltool. You wouldn't really need gcaltool anymore. (just
> an example...)
> But maybe I'm wrong and unity was designed to include lenses like this
> in the future?!

Yes, agreed. This proposal basically suggests re-implementing GNOME
contacts inside the dash. Independent of this being possible with the
current API, I would also think that this is not really desirable. The
dash should be for searching, and other applications should be
responsible for handling the results.

The new GNOME apps are a great as very streamlined apps that focus on
usability and ease of use. I think the dash should complement this and
work great with these apps, but not compete against them.

> The design proposals document was created in May this year so I don't
> know if this is still a valid document!

I think we should not follow these proposals, unless we really think
they describe something we think is desirable. I think we should stick
more to the common unity lens features and do something with that.

So I think these are the things we need to discuss:

     1. What categories make sense for our lens? (Categories are the
        sections the main dash view provides for displaying results,
        like “most used apps”, “installed apps”, and “downloadable apps”
        for the application lens.)
     2. What filters make sense for our lens? (Filters are those items
        in the unfoldable right-hand column used to limit search results
        by certain criteria.)
     3. How to display results in the dash?
     4. Which actions to perform on the contacts?

Here are my first thoughts on this:

Ad 1: I could think of these categories to make sense for us:
      * Online contacts
      * Recently used contacts
      * all contacts
Online contacts are those that are currently available for chat. We
should get this information from telepathy. Since libfolks can merge
contacts, one can link contact information from the system address book
(EDS) and telepathy chat buddies. Thus, we can have complete address
information available for online contacts.

Recently used contacts should be contacts that one recently interacted
with, be it by mail, chat, or voice call. I just don’t know if this
information is available in Zeitgeist. Evolution, telepathy, and
possible other applications would have to pass this information to
Zeitgeist, and I don’t know if they currently do. If not, we could
easily do without this category for now, and maybe talk to application
developers about Zeitgeist integration for future use.

All contacts would be, surprise surprise, all contacts. Just one open
question: Is it possible to assign one dash item to multiple categories?
Should the contacts listed in “recently used” also be listed in “all
contacts”?

Ad 2: I can think of these possible filters:
      * Address book
      * Category
      * Group

One issue with this is that different sources use different grouping
criteria: Evolution has different address books, and additionally allows
to add categories to contacts. Empathy/Telepathy allow to assign
contacts to groups. I don’t know how libfolks handles these, and how one
deals with only chat contacts having groups, and only EDS contacts
having categories, etc. I think we should first see what is possible
with libfolks, and then discuss what is reasonable.

Ad 3: I think we need to discuss these display related questions:
      * Image
      * Title
      * Renderer

For the image, I think the contact photo is the natural choice. I think
we have two image sources, EDS photo and (possibly multiple) telepathy
buddy icons. I think the photo should have precedence. If we have no
photo, but multiple buddy icons, I am not sure how to handle this. But
maybe libfolks and/or GNOME contacts already provide a reasonable image
selection mechanism that we could use.

Another issue is contacts that have no image information at all. Most
mockups I have seen so far simply use a stock person icon in this case.
But since I guess that in many address books, having photos for all (or
most) contacts is rather not the case, I am not really in favour of this
solution. On the Nokia N9, they create an ad hoc image using the
initials (e.g. FE for Frederik Elwert). I think this solution is quite
nice, since it makes contacts distinguishable.

Regarding the title, this should obviously be the name. One question,
however, is which name representation to choose. Evolution has a “file
as” field, which can either be “Family Name, Given Name” or “Given Name
Family Name” (but why not “Family Name Given Name”, as common in Japan
or Austria?). Should we use this, or should we always use “Given Name
Family Name”, which is a bit more informal (the N9 actually does this)?
This also affects sorting, i.e. sorting by family name or given name.

Regarding the renderer, I have to be honest I have no clue what the
difference of the lens renderers is. ;-)

Ad 4: I think the default action would be to display the contact in
GNOME contacts. This would mean we depend on it, but I think that’s
okay. One question could be if we want to perform different actions
depending on the category. Especially worth discussing could be if we
want to directly start a conversation with online contacts instead of
displaying the contact.

I think we could easily start with always using GNOME contacts, and
discuss other options later after we get a feeling how everything works.

Wow, that became a rather lengthy e-mail. Please feel free to write your
ideas, comments, and criticism. Once we agree on specs for these
aspects, we should add the results of our discussion to one (or possibly
more) blueprints in launchpad.

Regards
Frederik