Re: Hello all

Hi Karl

Very very interesting and exciting!

First off with this, I think when you plug in a device we will simply
ask the user which datatypes they want to sync. They will be added to
the relevant part under each authority. This is much nicer than the user
have to pick where they want to sync I think.

How do you feel about having "sensible defaults". For example, a tab for
Contacts, Calendar, Todo, Notes, Photos, Music etc. Not sure quite how
far to go! Or perhaps none and just have an attractive start page. If
you plug in a device that supports a datatype you don't have a tab for,
it would be created automatically?

More sensible defaults: Under Contacts, the default authority is
Evolution. Under Notes, Tomboy. I dare say these defaults will be set
via something a distro could customise - gconf defaults?

In this UI, I imagine that the list of dataproviders down the side is
removed? Or do you imagine a context sensitive list? Initially I thought
no list and a user interacts with the canvas to invoke some kind of
chooser dialog?

If there is no list of dataproviders down side, do you prefer idea of
having a list of datatypes downside or tabs of datatypes at top?

We are thinking about building this UI atop our Dbus layer, as part of
the "Conduit as a platform" theme. I imagine at most a very teeny amount
of wrapping to make the grouping happen, but otherwise I think the dbus
layer is pretty capable as is.

The more I think about this the more I want it to happen! Perhaps I can
coerce you into some kind of UK hackfest :)


On Wed, 2007-10-24 at 12:57 +0100, Karl Lattimer wrote:
> Hello everyone, I'm Karl, and this is my introduction :)
> For some time I've been musing over the user interface in conduit, and
> as John has already blogged about was my first attempt at making the
> conduit UI rock.
> Since then I've been thinking in great detail about the way that
> information is presented to the user. In an attempt to clean things up
> and make an interesting jump into a dare I say it "new sync paradigm"
> what I've thought is the following;
>  * If there is only one type of data type per relationship then the most
> important UI feature is that data type. Therefore a tab type philosophy
> should probably be adopted to represent the data types the user cares
> about, i.e. notes, calendars, contacts, files etc... 
>  * If there is essentially one authority in a relationship then that
> authority should be shown at the root of the relationship. Currently
> conduit does this by showing the authority on the left. 
>  * Further to the authority, elements in the relationship can be either
> a replicant or a publishing destination depending on whether or not they
> can provide two way sync.
> After making these grand assumptions about the use case of conduit I
> have put together a display of what one of these relationships would
> look like. It becomes obvious that a vertical approach provides a
> cleaner and more spacious display. (see attached screenshot), within
> each of the tabs (and I'm not convinced about tabs but I'm yet to design
> the glade mockup), management of data providers and a list of the
> relationships that exist are a necessity but these should be displayed
> relevant to the task at hand, if I'm managing my notes relationships I
> don't want to see data providers that don't allow me to sync notes.
> I'm eagerly awaiting comments on this, as I've been drawing sketches on
> paper over the last few months wracking my brains on how I can make
> conduit UI zen happen.
> Regards,
>  K,
> _______________________________________________
> Conduit-list mailing list
> Conduit-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]