Re: A mockup for an alternate conduit GUI.

["John Stowers" <john stowers gmail com>]

On Tue, Jul 22, 2008 at 11:49 AM, Martin Owens <doctormo gmail com> wrote:
> Why have a GUI at all? For all your online syncing needs you could
> integrate plugins into firefox for the configuration end, adding
> buttons to photo sites ect.

I agree. Some technical challenges remain, such as how does one call
into dbus from a firefox extension. I have heard mentions of this
being possible. This is not an insurmountable technical problem.

For devices you could have a status panel
> icon which pops up informing users of syncing opportunities.

I agree.

>
> The problem with current thought is that it assumes syncing is an
> application in it's own right, when it's nothing of the sort. It's an
> exercise in integration with the system by providing data paths
> between formats. Those multiple formats themselves being intolerable
> to me (rar rar open standards)

Trust me. This is *not* current thought, at least exclusively.

I am trying to integrate Conduit synchronization functionality into
applications where it makes sense. We have an eye of gnome plugin for
image upload/sync from that application, and a totem plugin doing the
same with video. I have hacked on cheese with integration for both.
Nautilus plugin for proof of concept file sync/backup.

The politically incorrect question I ask myself is "what is my
incentive to spend more time on integration with GNOME applications
when Conduit is not in GNOME. Shouldn't I continue to add
functionality to Conduit to make it more useful and bug free. Isn't
that a better use of my time?". This is not a false dichotomy when one
has the combination of
1) a small development team
2) people constantly reminding them that sync on linux has sucked for
far too long

>
> Let me know when I can plug my blackberry into a default ubuntu
> install and have it ask me if I want to sync the contacts.

Maybe when Ubuntu provides me a blackberry to test on ;-). In order to
test windows mobile stuff I went out and bought a (terrible) WM5
phone. To test syncml support I went and bought a Nokia. People who
want Palm support talked to Jc2k at Lugradio and offered to loan him
one.....

Seriously though, I had some productive discussions with folks at
GUADEC, and there is already integration work happening with
gnome-phone-manager. The path forward will involve depreciation of the
current GUI, and moving control of certain functionality into other
applications. This is already technically possible. Everything Conduit
knows is exposed over DBus.

There are still open UI questions - where does one put configuration
for SyncML phones?, other phones/devices?. We live in an imperfect
world, where not all required information about a device can be
queried and an automatic configuration guessed. The risk is that in
optimizing for the zero configuration case one makes the other cases
exponentially more painful. It does not have to be this way, only
through discussion, experimentation and mockups will and answer reveal
itself.

Is it wise to design a second GUI for minimal configuration of mobile
devices, or is it smarter to make the current GUI dual mode? Mode one
being more complex, and mode two being simpler, and the default once
the configuration parameters have been entered.

I suppose my conclusion is that merely saying the current GUI and
interaction model for conduit sucks does not remove the burden of
having to come up with a new and better one.

I like your ideas about the mobile use case, and that is a goal for my SOC work.

Regards, John

>
> Best Regards, Martin Owens
>
> 2008/7/21 Kris Northfield <kris northfield gmail com>:
>> Funny you should post that, I have a mockup that's been sitting in my
>> home directory for a while now waiting for some polish but I think
>> I'll just post it 'as is'. There are bits that I'm not happy with at
>> the moment but the general ideas are there. What do people think?
>>
>> My main aims were:
>>
>> 1. add a big 'sync' button to avoid having to right click on the
>> applet (also add a cancel button on the toolbar)
>> 2. make the data providers more 'manageable' (not sure that's what i mean)
>>
>> Right now the tree view isn't too much of a problem but presumably
>> over time more and more providers will be there, making it more
>> confusing and longer.
>>
>> In my proposed solution you have an "Add Conduit" button from which
>> you can choose a data type, photos for example, this adds an icon to
>> the left panel which then features a drop down to select relevant
>> providers.
>>
>> Clicking an icon in the left panel filters the view, you can then
>> further divide data types into custom groups (e.g. personal
>> photos/work photos) using a drop down at the top of each group (i
>> don't really like this, i think it is over complicating things) you
>> can also sync the current group only.
>>
>> Regards,
>> Kris.
>>
>>
>>
>> 2008/7/16 Andrew Stormont <andyjstormont googlemail com>:
>>> Pls, tell me what you think.
>>>
>>> You'll probably have to view it in inkscape, since I have no idea how to
>>> add an opaque background :p
>>>
>>> Andy Stormont.
>>>
>>> _______________________________________________
>>> Conduit-list mailing list
>>> Conduit-list gnome org
>>> http://mail.gnome.org/mailman/listinfo/conduit-list
>>>
>>>
>>
>> _______________________________________________
>> Conduit-list mailing list
>> Conduit-list gnome org
>> http://mail.gnome.org/mailman/listinfo/conduit-list
>>
>>
> _______________________________________________
> Conduit-list mailing list
> Conduit-list gnome org
> http://mail.gnome.org/mailman/listinfo/conduit-list
>