Soylent

Central Goal

To make interactions with other people as easy and enjoyable as possible.

Description

Soylent intends to be a "people browser" that wraps every useful bit of information about people into single, cohesive objects. So your friends may have a dozen IM screen names, email addresses, website usernames, icons, hundreds or thousands of photos, and so on. Soylent is meant to bring all those types of communication and content together so you can perform and reach them within a few clicks.

We're using the best-of-breed libraries to achieve our goals in the cleanest, most universal ways possible. That means libempathy/libmissioncontrol to perform Telepathy-based communication (instant messaging, voice and video communication), Evolution Data Server for email and contact store. Eventually, we're planning to tie into the Gnome Online Desktop and Mugshot to pull the power and features of social networks to the desktop.

The screenshot and mockup below should hopefully make the idea clearer and even inspire ideas the original authors hadn't even thought of.

Screenshots

Soylent 0.1.6 Screenshot

Soylent 0.1.0 Screenshot

Mockups

Current Mockup

Releases

SVN tree

Soylent development happens in the Gnome Git module "soylent"

Mailing List

soylent-devel

The list is very low-volume and questions/comments are usually responded to quickly.

Motivation

[TravisReitter] So the first, and most significant of my UI ideas is a "People Browser". This would serve a number of purposes, including replacing the buddy list. Part of that would be to discourage people (like me) from killing time by just messaging random friends who happen to be online (though getting a view of everyone online is just one click away, to avoid rioting).

The main goal is to transition from the current (and I'd say, flawed) contact thought-and-action chain:

  1. Think of something
  2. Decide to share your thoughts
  3. Decide (broadly) who to share with (ie, Everyone vs. Targeted audience). For now, we'll just consider the second option.
  4. Decide exactly who
  5. Decide type of conversation you want to have (based on general latency of conversation type)
  6. Remember what contact information you have for the people
  7. Remember which applications handle each protocol
  8. Manually open the appropriate application(s)
    1. Linearly search buddy list for the people in mind (matching screen names if you haven't aliased them)
    2. Click Contacts button in Evolution or remember email address(es)
  9. Open IM sessions/emails with each person
  10. (Remember what you wanted to tell/ask them)

to

  1. Think of something
  2. Decide to share your thoughts
  3. Decide (broadly) who to share with (ie, Everyone vs. Targeted audience). For now, we'll just consider the second option.
  4. Decide exactly who
  5. Find person in People Browser (should be a few clicks at most)
  6. Decide type of conversation you want to have (based on general latency of conversation type)
  7. Click appropriate contact action button (video call, phone call, text chat (real-time), email)

This transition requires fewer steps between conceptualization and conversation, it mainly cuts out specific-technology-related steps, making it a bit more human(e) and intuitive.

People Browser main use cases:

  1. Add person to system
  2. Remove person from system
  3. Add existing user to (more than one) group
  4. Remove person from group
  5. Remove group (but not its members from the system)
  6. View person's attributes
  7. Edit person's attributes
  8. Contact user:
    1. video phone call
    2. phone call (VoIP)
    3. text chat (real-time/IM)
    4. email

Action Buttons

Action buttons at the top of the browser are pulldown-buttons (pulldown menus with a default click action). The default click (left of the arrow portion of the button) will go to the first item in the list. So it'd act just like Firefox back/forward buttons. Each item in the list has a generic name (user-provided or gleamed from vcard) as well as the address and icon for the protocol. So it should be quick to glance at the list and choose the non-default address/protocol if necessary.

Communication Methods

The ordering of the communication methods (identified by username/protocol pairs) in the action button pull-down lists will be dynamically determined by which methods the user chooses most frequently. We would include a buffering range to prevent multiple commonly-used username/protocol pairs from constantly swapping position in the pull-down list.

Groups

Groups are sets of people associated for a given context. For instance, Co-workers, Family, Friends, etc. Because people in different contexts may have different screen names, email addresses, etc., PeopleBrowser will support a distinct primary address for each communication method (username/protocol pair) for each group. This will mean, for example, when you write an email to your "Local Friends" group about your party on Saturday, any co-workers will get the email at their personal address, not their work email address.

People may be members of multiple groups.

Group List

On the left hand side is a nautilus-like list of groups (dynamic and static). Common actions for groups in the group list:

  • Selecting a group displays its members in the main area.
  • Dragging selected people onto one of the static groups adds them to it
  • Dragging a group onto one of the action buttons at right performs the action on the group (without having to click on the group on the left side and then selecting the members before clicking the action button). Of course, this might not be very obvious, since the pulldown-buttons are buttons.
  • Right-clicking on one of the groups has an option to delete it. This could also be handled by changing the New Group button to Delete Group (to try to make things nice and compact by only showing context-relevant options, like Jokosher is supposedly doing)). I'm trying really hard to avoid making groups show up as objects in the main area, since I think it would make things needlessly complicated (without giving us much functionality).

Accessibility

All the buttons and fields would have a keyboard shortcut, to be keyboard accessible. I'm not sure the best way to show that, though. I'm not sure if underlined label letters are tied directly to Alt-letter combinations or not. But if we could just underline the Ctrl-letter, that could be confusing. Maybe we could just add the shortcut to the end of the tooltips.

Main Area

Selections would work the same they do in Nautilus. Hitting an arrow key selects an item in the field. Hitting arrow keys afterward moves a single selection around. Shift-arrows selects rectangles. Ctrl-arrow moves a dotted selection around without de-selecting the current selection. Ctrl-Shift-Space after that adds an icon to the selection (for non-contiguous selections).

  • Activating a person or group will provide details, not open an IM session.
  • Details would fill up entire middle pane. A button would revert the pain to the previous icon view (to remove the need for a Back button). The details would be similar to a contact-lookup-applet or Contacts window. There would probably be separate View (default) vs. Edit modes for user details, since it's painful to select more than one textentry field at once (for a copy-and-paste).
  • "Details" for a group would give an icon view of its members. Just like pushing into a folder in Nautilus -- though removing someone wouldn't delete them from the system (something that you'd very rarely want to do anyhow). That would have to be communicated well to the user (eg, "Remove from Group" instead of "Delete" should suffice).
  • To add a user to a group, you could copy-paste them from anywhere else, or drag them onto one of the groups in the left bar. To rapidly add someone to multiple groups, you could copy a handful of groups and paste them onto a user. Hopefully not too counter-intuitive (but fairly undiscoverable). Dragging a group from left pane onto a user would add them, but it would be impossible to do multiple groups -- maybe the left pane should be a mini multiple-selection icon view, like the concept of a "shelf"?
  • All of the "action button" items would be available in a right-click menu when clicking on a person or group. As appropriate, there would also be:
    • Remove from this Group
    • Delete
    • Block
    • Delete Group

libsoylent

To learn more about the future backend of Soylent look here.

Attic/Soylent (last edited 2018-08-18 14:59:20 by AndreKlapper)