Re: GUI Mockups

[Alexandre <airmind gmail com>]

Hi Martins,

On Mon, Dec 29, 2008 at 3:49 AM, Martin Owens <doctormo gmail com> wrote:

Hey Alexandre,

Very nice moc-ups. I like the way the sources have data classes and each
one of those can sync with data types of the same type.

I've been working on a project to hopefully make a great deal of the
work of integrating with data sources and with authorising and
connecting to online services, much more easy.

The idea is to have online services become available via dbus much like
hardware does when you plug it in via HAL. These services then integrate
with an infrastructural data class system, once again available via dbus
which allows data access to all the different services attached.

Are you referring to https://launchpad.net/coisas?

What you mentioned is very close to the way Conduit works internally. It's just that Conduit is focused on synchronization, so the data is usually retrieved, used and discarded, rather then being able to browse them. But it works just like that, each dataprovider output data in classes according to their type, and it already includes a few online services implementations.
Conduit includes a DBus API, but again, it's more focused on synchronization.
However, these days I was just building a data browser for data-providers. The idea was to use the Conduit architecture to get data from data-providers and show them to the user. It's somewhat usable, I was able to view my Flickr photos. It was a quick and dirty hack, but required no changes to dataproviders.
 

The grand scheme is to have syncing as an unrelated, light weight client
application or daemon which sits on top of this infrastructure. Whilst
some people want and expect data to magically transport it's self
around, I'd be happy with stable and predictable data access to devices
and online services which is all available with the same dbus API.

I was thinking about that, eventually we can get all data to become a series of properties (including metadata), which can go through anything, and be used anywhere. In a way it's what Xesam and others are doing, but they dont cover how to actually get the data (sort of), or how to actively interact with services.
But that is all already implemented inside Conduit, it's just confined to a purpose.
Maybe your project and Conduit might interact very well. Either by exposing the Conduit data-providers to your service, or as a daemon or client as you said. Conduit already includes a good architecture to discover services and devices,
 

Best Regards, Martin Owens (Canonical)

On Mon, 2008-12-29 at 02:16 -0200, Alexandre wrote:
> Hi,
>
> I've been thinking for a while about how to improve the Conduit user
> interface, especially how to improve experience with removable
> devices, such as iPods (part of my Google Summer of Code project
> actually). As I got to think about that, it became clear to me that
> the Conduit experience could be much improved if it based on things to
> sync, like devices, applications or online services. The user dont
> think about dataproviders and conduits or about connecting one
> datasource to a datasink to sync his files. He wants his cell-phone or
> iPod to be in sync with his desktop or online data. Or he wants his
> desktop data to be in sync with an online service.
> After thinking about it for a while, I came to what I think could be a
> good solution, and made some mockups to feel how it would work. These
> are what I came up with:
>

> http://img399.imageshack.us/img399/8659/mockup1us8.png
>
> http://img399.imageshack.us/img399/4085/mockup2ec4.png
>
> http://img399.imageshack.us/img399/7702/mockup3cx9.png
>
> http://img399.imageshack.us/img399/7501/mockup4mw1.png

>
> These explain most of what I've been thinking. There is an alternative
> way to do the last one, with the Home tab, in which instead of each
> category separately, we can show the third pane directly.
> One thing to notice here however, is that the Music, Video and
> Pictures tabs of Home are not only decorative, they filter their input
> data to only let their desired types to come in, and provide some
> functionality, such as separating Music files by their artists and
> albums, etc. And I would like to have the same thing with the
> removable drives. Dataproviders for removable drives would be very
> close to what the Folder dataprovider currently is, but it would not
> let the user change the root directory (which would be the removable
> drive directory), but instead only choose a sub-directory of the
> drive.
> Another thing I think would be nice, is a baloon notification when a
> device supported by Conduit is inserted, which jumps to that device
> tab when the notification is clicked.
>
> Well, this kind of interface is especially for what I did the new
> configuration system. See how the configuration is embed in the
> window. The user just follows the flow, he selects what he wants to
> sync, adds to what he wants to sync, and immediately configures what
> he just selected.
> Most of it is easily implemented with the current architecture, but
> one idea I had was to use the DBus interface to this, so that we would
> have an actual application using all the parts of the DBus API. And
> would leave the current interface intact, maybe for debugging
> purposes.
>
> So, what do you think?
>
> Alexandre Rosenfeld

>