gtg-contributors team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Wed, May 19, 2010 at 7:51 AM, Paul Natsuo Kishimoto
<mail@xxxxxxxxxxxxxxxxxxx> wrote:
>  Since it seems like there will be some (healthy, needed)
> back-and-forth over UI ideas, maybe we should use a prototyping tool.
> That way we don't waste too much effort coding different concepts that
> may not get used, and no one has to defend something just because
> they've sunk time into it.
>
>  I have seen http://gomockingbird.com used before, but I haven't used
> it (or any others) myself. Anyone have a preference?
>

It's a great idea! Mocking bird is ok for me. I used WireFrameSketcher
(http://wireframesketcher.com/) some time ago.

> On Tue, 2010-05-18 at 14:34 +0200, Luca Invernizzi wrote:
>> On Tue, May 18, 2010 at 09:51:29AM +0200, Bertrand Rousseau 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.
>> I agree with Bertrand
>> >
>> > >
>> > > * 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.
>> > >
>> We could do that, but if we want to display the list of  backends and their
>> configuration in one window, well'need a window format that is short-and-wide
>> instead of tall-and-thin. Your mockup too has that format.
>> > >
>> > > * 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:
>> I'll expand the list
>>  - backend name (must be editable, since we can have multiple instances of the
>>    same backend
>>  - tags associated to the backend (must be very easily editable)
>>  - add/remove a backend
>>  - backend icon
>>  - "something is wrong with the backend" (e.g.: not configured
>>     properly, or bad communication with the server)
>>  - backend description (only when adding a backend) /author (like plugins)
>>  - backend enabled/disabled
>>  - password / some way of get authorization
>>  - filenames
>>  - username
>>  - if we should sync also closed tasks?
>>
>> Anyway, the list is long and every backend is different. That is why I'm
>> proposing and Empathy-like ui. I think that Paul's UI is great for advanced
>> users, but it could be a little confusing for most of our users. I don't think
>> that the amount of backends per user will be so great that we need an overview
>> of which tags are associated with which backend.
>> To lessen that need, I'm thinking about the possibility of showing the backend
>> icon at the side of the tags in the tags pane (should be optional, and not show
>> the default backend).
>>
>> >
>> > 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).
>> Do we really want plugins that add backends? Isn't that a bit convoluted?
>>
>> >
>> > >
>> > > * 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)
>> eheh, you're taking me too seriously. I just needed an icon to use as a test for
>> programming, and I sketched up that. It should be an xml tag, but I agree is
>> horrible. We'll be thinking about icons in a couple of months :)
>> >
>> > >
>> > >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!
> --
> Paul Kishimoto
> MASc candidate (2010), Flight Systems & Control Group
> University of Toronto Institute for Aerospace Studies (UTIAS)
>
> http://paul.kishimoto.name — +19053029315
>
> _______________________________________________
> 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
>
>



-- 
Bertrand Rousseau