gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

Paul Natsuo Kishimoto wrote:
> Hi,
>
>   First, administrivia: if Karlo joins ~gtg-contributors (SoC will
> certainly make him a major contributor!) then it will be a superset of
> ~gtg-gsoc. We can use the former list and get free input from people who
> are neither students nor mentors.
>
> UI-related thoughts...
>
>  * Some previous discussion: https://launchpad.net/gtg/+bug/336623 .
>
>
>  * I agree the backend UI should be easy to get to. Some applications
> (e.g. I use Back-In-Time) have a preferences button directly in the main
> interface. Is this desirable/not for GTG?

I'm not really for this, but I agree this is nice sometimes. If someone 
as a good feeling, he can post a screenshot/mockup of that.

>  * How about making the backend UI the first tab of the preferences
> dialog? As you say, the first preferences tab is currently quite empty.
> Even if it weren't, "configuration is *always* necessary" means that
> backend config is more important than the other behaviour options,
> therefore the tab can be first.
>
>
>  * I would still advocate for something like the UI I describe at the
> link above. A simpler concept is: backend names in one column, and a
> list of tags in a second column (instead of one additional column per
> tag).

On my side, I would recommend to put down a list of information that 
need to be displayed to the user. Here's what I can think of:

 - backend name
 - tags associated to the backend (must be very easily editable)
 - add/remove a backend
 - "something is wrong with the backend" (e.g.: not configured 
properly, or bad communication with the server)

if I want to edit the backend/add one:

 - backend form

>   The point is that the user should be able to see, at-a-glance, which
> tags are assigned to which backends, instead of going up and down the
> list in listing_backends.png and assembling that overall picture
> mentally.
>
>
>  * When adding a new backend, it should be possible to choose a backend
> offered by a plugin that is disabled but *can* be enabled (i.e. is not
> missing dependencies). Then the plugin is automatically enabled without
> the user having to touch the 'Plugins' tab.

I agree with this. I'd let the user know about this, though (simply 
mentionning that activating the backend will enable the plugin should 
suffice I guess).

>  * Icons for backend types — solid idea. Does <> = readwrite, or does it
> represent XML syntax? Nontechnical users won't understand the latter
> meaning.

I guess I would use a generic "file" icon for local file, and the 
service name for other (RTM excepted since we can't seem to have the 
right to use it - how lame)

> On Tue, 2010-05-18 at 00:59 +0200, Luca Invernizzi wrote:
> > Hello there,
> >  I've started working on the multi-backend support expansion, and I'd
> >  like to discuss with you the UI.
> >  I'll keep it short :)
> >
> >  First of all, here's the current status:
> >  - added support for keeping only a subset of tasks in the backend (depending
> >    on the tags)  (70%)
> >  - refactored the handling of the backends. We now have a BackendTypeManager
> >    which is in charge of backend *types* and generation of new backends, while
> >    the instances of backends are handled in the datastore. (60%)
> >  - started working on defining a prototype for backends  (50%)
> >  - ui for adding and managing backends   (20%)
> >
> > Point of discussion:
> > - ui for managing backends: the current "preferences ui" is fine for plugins,
> >   but backends differ from plugins in two points:
> >   - configuration is *always* necessary
> >   - they need to be added and removed (since we can have two instances of the
> >     same backend)
> >   Therefore, I was evaluating to take backends configuration out of the
> >   preferences window, in the Edit menu (which is quite empty). This would be
> >   easier to find for the user and let us use a different interface.
> >   I've started experimenting with a ui similar to the Empathy account dialog
> >   (picture attached). Attached you'll see my little experiment.
> >   I think this ui suits backends better because:
> >   - we have just one window, not a preference window for each backend.
> >     This means that everything is one click away and the user always has a
> >     global view
> >   - (Ubuntu) users are used to empathy
> >   I know that this is quite similar to the old plugins preference window. Well,
> >   fashion is cyclic :D
> >
> >   Tell me what you think!
> >     Luca
> >
> > Ps: Yay! I actually remembered to attach pics!
>
> Cheers,
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp