gtg-gsoc team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

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?


 * 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).

  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.


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


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,
-- 
Paul Kishimoto
MASc candidate (2010), Flight Systems & Control Group
University of Toronto Institute for Aerospace Studies (UTIAS)

http://paul.kishimoto.name — +19053029315

Attachment: signature.asc
Description: This is a digitally signed message part