Re: GUI Mockups

[Martin Owens <doctormo gmail com>]

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.

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.

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 

>