Saturday, May 22, 2010

First two mockups

Here are two mockups presenting my basic ideas about future aptitude-Qt GUI:

Packages tab:


Updates tab:


Mockups for Show Package and Preview tabs will be finished tomorrow.

Any comments and constructive criticism are much appreciated.

7 comments:

  1. Nice mockups ...

    Just two things.

    I would love to see being able to open in tabs not only packages descriptions, but also some extra browse/search/fillters for the main list. One example would be browsing gnome packages in one tab and kde group in another one. Same for text searches I guess (maybe even by default a text search should open a new tab ?)

    Another thing is I would love to have a right click on position bring up some extra advanced actions (for example lock package version , force version etc). With your mockups you plan to place them in "More actions" position but it will be quite a hassle to get there (many clicks). IMHO a nice right click menu popup on a package would do better, and is commonly used in file mangers , browsers and all kind of apps.

    Best luck with your project :)

    ReplyDelete
  2. val-gaav: thanks for your comments I have already thought that no one is reading it ;)

    I would love to see being able to open in tabs not only packages descriptions, but also some extra browse/search/fillters for the main list. One example would be browsing gnome packages in one tab and kde group in another one. Same for text searches I guess (maybe even by default a text search should open a new tab ?)

    The behavior you describe is exactly the same as in Aptitude-GTK ;) There is Dashboard Tab and every search in new Packages Tab (Here are some screenshots : http://algebraicthunk.net/~dburrows/blog/entry/aptitude-gtk-status-a-visual-tour/ ). The use case you described is also valid. What do you think about this solution:
    First package tab is always open as described in mockup ). Searching is still local for given tab by default (but there could be an option to change behavior as you decribe). It is also possible to open new Packages tab (with ctrl+T shortcut, action in main menu and probably action in toolbar - I have forgotten about Undo/Redo actions on this mockups)


    Another thing is I would love to have a right click on position bring up some extra advanced actions (for example lock package version , force version etc). With your mockups you plan to place them in "More actions" position but it will be quite a hassle to get there (many clicks). IMHO a nice right click menu popup on a package would do better, and is commonly used in file mangers , browsers and all kind of apps.

    In my mockup: lock == hold, but this can be easily changed ;) Forcing version was planed in Package Informations tab (I am preparing mockup now), And more option menu will be the same as context menu. I have to think more about this

    ReplyDelete
  3. Ech, Blackquote tag is not working in comments and it is not possible to edit them :/ .

    ReplyDelete
  4. Well It's hard to find your blog. For some reason your posts do not appear on planet debian. I know planet kde has gsocers on the list. Does debian have some different policy about it? Being posted on debian planet would help to get some public attention. As it is now I've found your blog almost by accident and because I was interested in qt aptitude.

    Your solution with tabs sounds good to me. Also by checking the gtk+ aptitude screenshots I'm really happy you want to go with list of packages on the right. The screens there have it on the left which looks weird and just about every other package manager I've used has it on the right.

    ReplyDelete
  5. I know about this. Adding to planet debian was planned (Arthur wrote about this in his gsoc projects announcement). But as you see it haven't been added yet ( I hope it will soon change :) )

    After finishing first mockups iteration I will ask Polish community (on DUG and debian.linux.pl -> BTW why is it split?) about their opinions.

    And categories list on the right will be an option. It is one of feature requests from my buddy.

    ReplyDelete
  6. 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.

    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.

    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).

    ReplyDelete
  7. Just to clarify: the second paragraph of my earlier reply is not related to the comments about update priorities -- I wrote it after the rest of the message and apparently didn't pay attention to where I was typing *hangs head in shame*.

    ReplyDelete