Abstract

As part of the general goal to make Gnome more people-centric, Project Soylent proposes an infrastructure (mainly through a "People Browser" and Interaction Icons/"action launchers") to let users interact with "people" as opposed to "programs to communicate with people". For example, it should shift the thought process involved in reaching someone from "which program do I run to send a message to {this particular person(s)} over the AIM/ICQ/email/etc protocol" to more general thoughts like "how do I interactively/non-interactively communicate with {this particular person(s)}". Similarly, finding out more information about known/semi-known people, and quite possibly finding new people should be easier and more abstract.

Slogans

  • Gnome is Made of People!
  • Gnome: Software for People
  • Gnome is People!

Mentality

Just as folders are spatial file browser windows, icons of people are the people. That is, interacting with peoples' icons interacts with them.

Mock-ups

As incentive to read through the rest of this proposal, here are some (amateur) mock screenshots:

  • People Browser
    • [[User:NicolasTrangez]]: I dislike this, having those launchers in the panel. The pannel is way too small for this, and it doesn't make the interface coherent. I think we should not concentrate on GUI's now, rather on "how can we let GNOME users not work/'correspond' with email addresses, IM accounts etc, but with 'people'"
  • People Browser with Buttons
  • Person Properties

Associated Terminology

  • "Engaging" (?) a person - Activating a person's icon.
  • "Interaction Icons" - Panel icons which run commands/programs to perform intuitive actions when given people icons; action for multiple people may be slightly different than for a single person, as necessary, but should be equally inuitive.

Hooks into Existing/Upcoming Programs

  • Galago - When engaging a person(see Associated Terminology, above), check with Galago to determine how to communicate with them. Somewhere, maintain an ordered priority list of protocols to reach people. E.g., if the person is signed on to AIM, engaging opens a message window with them, otherwise, open a /msg to them on IRC, ..., open a blank email to them. Should we connect to all protocols we know people connect to, in the background, and start a client program to communicate with this person if they are signed on to a service with higher priority than we currently are?
  • Evolution Data Server - Track all sorts of metadata for each person. See Properties mock-up, above.
    • [[User:NicolasTrangez]] I've been playing with EDS today, see these samples
  • Beagle/BEST/Dashboard - Include a side bar in the browser (or elsewhere) to bring up context information (conversations, emails, blog posts, files, photos with multiple select people in it, etc.) on people, like Dashboard (or use Dashboard, but the project seems to be abandoned).
  • Project FOAF (Friend-of-a-friend) - This looks promising for both describing people and their relationships (and can even handle labelling multiple people in a single photo gracefully). My (TravisReitter?) biggest concern is security, since it doesn't seem to be inherent (at my first glance). However, that is for just plain publishing this online. At least initially, we could include a "personal" attribute, or some flag to not publish certain entries beyond the local computer (though eventually, we'd want to be able to push this metadata to other trusted people).

Example Behavior

Interaction Icons - dropping one or more people icons into these panel icons (which are regular Gnome Panel application launchers) perform the following actions

  • Mail - One person: opens an email to that person. Multiple people: opens a single email to all of them.
  • Message - One person: opens an instant message (in the preferred protocol [which they are currently signed on to]) to that person. Multiple people: open a chat (?) in the greatest-common denominator (?) protocol to all the people.
  • Blog - One person: opens that person's blog. Multiple people: opens a common feed aggragator, or known aggragator page (like a Planet); this may be too difficult in practice (include a planet which includes more than the selected people, include a planet which contains some, but not all of the selected people?) - rather, create a tool or modify Epiphany to nicely format a set of given RSS feeds?
  • Relationship - This would effectively be a mathematical Intersection operator, but I can't think of a better word to use than "Relationship". "Intersection" seems like it would confuse normal users. One person: our common features/interests (metadata) with them. Multiple people: what we all (or they all?) have in common ("big intersection" operator).
  • Profile - One person: displays lots of useful information about them, nicely hyperlinked. See Properties mock-up, above. Multiple people: I can't think of a useful group action for this one. Maybe default to split (see Splitter, below)?
  • Modifier Icons - These would behave as "in betweens" to modify the intended action for a set of people. To use them, select a group of people, drop them on a modifier, and then the cursor would change to signify a change in action, then the user drops them on the Interaction Icon. This could either work as a "swipe" (holding button from group icon dragging, mouse over modifier to include modification), or as a drop which then "throws the group back" to the cursor/hand, which then could then move over to the Interaction Icon and click it to perform the action.
  • Standard - Wipes away all modifiers for the current action, so the user doesn't have to find a safe place to put the cursor before releasing the mouse button, to then start over.
  • Splitter - Splits a group action into multiple individual actions; instead of openeing a single email with everyones' email addresses, open a single email for each person. Give a warning for large splits (?).

What It Shouldn't Be

Project Soylent should not be "Yet Another Addressbook," "Yet Another IM Client" or "Yet Another anything." Users already have applications on their desktops that they're accustomed to. We don't want to stomp in and just assume that users want to use this. We're the new kid on the block, and there's no proof that we're going to make it past that yet. Let's design this to integrate well with existing applications and technologies, so it's a more convenient way of doing the exact thing they can already do.

Questions/Undecided Points

  • What should we finally call this project?
    • [[User:TravisReitter]]: See the [[Project Soylent/Final Name]] page for name ideas. We'll determine the final name there.
  • What should the browser be called? "People Browser" doesn't sound very appealing.
  • Should the people browser be separate (but interact with) nautilus, or should it all be under the same umbrella?

Ideas & Experiments

Related Projects

  • I (JoeGeldart?) have developed a shared information layer that exposes an RDF graph over DBUS as part of my dissertation. The report I wrote is at RDF without Revolution and a current snap-shot of the code is at Frege source-code. The system provides a shared storage layer (with support for smushing nodes along functional and inverse-functional properties) and a set of bindings for python (although other languages are planned) that makes using information from the graph as easy as idiomatic OO. I am currently researching adding features to allow temporal (and other modal logic) modelling of information. I am also developing ontological descriptions of user interfaces to allow a better modelling of task interaction so that software can be modularised in a more task-oriented way and then joined together as appropriate. I plan for Frege to be the first system to take advantage of the theory of identity I'm researching for my doctoral proposal. It was quite a big project. But I feel I've run through most of the issues Soylent will do, and found solutions to them. The open research questions are a lot more precise now, and infinitely easier to hit. One of the most important is that you're inevitably going to reinvent the RDF data-model if you build an open information system such as a personal information system inevitably must be, so you may as well start with the RDF data-model. I agree with people who criticise the RDF/XML serialisation for being awkward, however it isn't the only serialisation in town and it is not the main part of RDF -- the data-model.

Related Work

[[User:TravisReitter]]: GlynnFoster? pointed out Sun's own work on this idea. Docking people on the side of the screen might be useful. At least as a cache (which may be what is intended, when the search box is empty, as in the screenshot on that page), or when the number of people search results fit on the side of your screen.

Original Author's Personal Note

[[User:TravisReitter]]: My goal with this little intro is to hopefully plant a seed of interest into the minds of our talented developers. I am currently busy with college courses, so I cannot dedicate much time to carefully spec'ing or implementing these goals, but I'd love to organize and fine tune these concepts with anyone interested I have been using Gnome almost exclusively since the 1.4 era, have read Planet Gnome constantly since its creation, but have no experience programming GTK+ or Glib, etc (frankly, they intimidate me, even though I've been programming a little in C for a couple years).

IRC

TravisReitter?: I've registered #ProjectSoylent on irc.freenode.net, and a few of us have joined it, so I think we should standardize on that one. I don't have a huge preference for one over the other, so long as we don't split the channel over two networks.

Development Ideas

For more implementation-specific ideas, hack on the scratch pad]