gtg-contributors team mailing list archive

[Karlo Jež <karlo.jez@xxxxxxxxx>]

On Tue, May 18, 2010 at 9:51 AM, Bertrand Rousseau <
bertrand.rousseau@xxxxxxxxx> 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     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
>> 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     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-gsoc<https://launchpad.net/%7Egtg-gsoc>
> More help   : https://help.launchpad.net/ListHelp
>