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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
