On Wed, May 19, 2010 at 7:51 AM, Paul Natsuo Kishimoto <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~gtg-contributors > More help : https://help.launchpad.net/ListHelp > > -- Bertrand Rousseau _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
