[Aptitude-devel] aptitude-qt mockups comments

[Piotr Galiszewski]

Hello Daniel,

So here are promised answers for your comments about aptitude Qt
mockups. (As aptitude-devel is cced: the mockups are available at
http://piotr.galiszewski.pl blog):

> I noticed that you divide updates according to their priority. This is a nice idea, but unfortunately the priority is only stored in the changelog. The changelog has to be fetched and < parsed separately from the package lists, it might not be available, and it can take a long time to fetch all the changelogs for a large update.
>

I have forgotten about this. This change the situation and with
reference to your later comment about useless  of this information for
users, i will abandon this idea. Maybe it will be better to
distinguish security updates from http://secutiy.debian.org?

> Is that pop-up with package information just a tooltip? I think it would be good to avoid having it be too easy to dismiss. e.g., it could appear when the user clicks on the package and disappear when they click again.
>

It is not pop-up. It is integral part of the list (maybe child in tree
view) which show on single click, and disappear on next click (exactly
like you described - it looks like my English is not good enough to
describe things in clear manner ;) ). There could be more than one
package information show at the same time.

> Unless you can find a way around these issues, I don't think you should plan to separate out updates by how important they are.
>
> It's also worth noting that the update priority isn't necessarily useful to users: it indicates how important the update is for the Debian archive, but not necessarily how important it is for people to install. For instance, a package that fails to build can get a "critical" update, even though there's no change that any user will care about. Actually, now that I think about it, maybe I should go so far as to hide that information in the default changelog display that aptitude-gtk shows, and only show it when they click through to the full changelog.
>
> I like the idea of filters down the left-hand side (it's one of my TODOs for the GTK+ code, actually, and it would be nice if you can design this so that the two UIs can easily share the list of filters).

I discussed this list with Sune on last Sunday, and we agreed that
sections are not good choice to be shown as categories. We decided
that debtags will be better. By default, there will be shown some
?most popular? tags as a categories: eg. kde, gnome (abbreviation from
suite::kde/gnome), admin, audio, im etc. "Manage Filters" will show a
dialog, where for example it will be possible to select tags (group of
tags) to show as categories. Other option should also be available. As
for sharing maybe saving list in xml will be good solution?

> I like the overall look, and at first glance it seems better than the GTK+ layout.
>
> It would be nice to be able to show the full URL that the package will be downloaded from, maybe even as a link. I occasionally get annoyed that this information isn't readily available from other UIs (including my own).
>

I agree. The problem is were this should be placed. Maybe "download"
link in place of "current"/"show details" column. See my proposal
below

>
> I have some questions about the version list.
>
> What will you do if there are more than two versions? Just put up a scrollbar?
>

No. There will be new row for each version without scrollbar.

> I'm not sure about using a whole column for "current" and "show details". Instead maybe you could make the version number a link that selects that version? That column would be handy for displaying the release that a package comes from. It would also be nice to flag the candidate version, although I'm not sure how to find a balance between cluttering up the UI ("default" is probably too much text) and having an indicator that's too cryptic (the meaning of "*" isn't obvious).
>

I thought about it, but I was not sure, if it will be intuitive for
users. But it will save some space, that could be used for different
purposes. As for indicator what do you thin about an arrow on the left
side presenting current version? As "candidate version" you mean a
newer package version than currently installed? I think that it is not
necessary, as versions are sorted in descending order,  Instead of
"install/remove" link there could be "upgrade" link do distinguish
this action.

I need to talk to some usability people what they think about this

> I'm not crazy about the "force version" wording. I would just write "install this version" or "install".
>

OK.

> I wonder if it would be good to have access to a real column-based list of versions, so the user can compare more information between the different versions (e.g., install size). On the other hand, I can definitely see that being an ugly bit of overkill for the list that shows up in the main info display.

Now user has to select each version to do this comparison. If it is
not enough it will be easy to add new tab "compare versions" to this
view.

Thanks a lot for your comments!
--
Regards
Piotr Galiszewski