On Tue, May 18, 2010 at 9:51 AM, Bertrand Rousseau < [email protected]> wrote:
> 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) > > I think a short description should also be added to that list, like the one in adding_backends.png. While it may be obvious what some backends would do (like local or RTM), some like twitter or email are more cryptic. user shouldn't need to add a new backend to see what a current backend does. Descriptions should also be simple and understandable, I don't think all users know what an XML file is ;) (adding_backends.png) > 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<https://launchpad.net/%7Egtg-contributors> >> Post to : [email protected] >> Unsubscribe : >> https://launchpad.net/~gtg-contributors<https://launchpad.net/%7Egtg-contributors> >> More help : https://help.launchpad.net/ListHelp >> > > > _______________________________________________ > Mailing list: > https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc> > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
