On Thu, 2006-11-30 at 21:21 -0500, Jeremy Katz wrote: > On Thu, 2006-11-30 at 09:29 -0800, Toshio Kuratomi wrote: > > On Thu, 2006-11-30 at 10:52 -0500, Jeremy Katz wrote: > > > The "problem" is that if you do something like this, you _really_ don't > > > want to be using the current UI. > > > > There's an assumption here of what the current UI is. From your > > background and the background of comps I would assume that "current UI" > > means anaconda's interface. However, comps.xml has been proposed as a > > replacement for the rpm group tag in general. Repoview already attempts > > to do this (with a horrible number of entries in the uncategorized > > listing). apt/synaptic and smart currently use the rpm group tag and it > > was proposed that they should be ported to use comps instead of > > rpm::group. I would say that apt and smart's UI would not suffer from a > > migration to comps provided that comps lists all the packages in the > > repository. > > And that _used_ to be anaconda's UI and anaconda used the group tag. > That was changed so that: > a) the grouping information could be changed by third parties without > requiring the packages to be rebuilt Exactly. The group tag is a bad place for this information above and beyond the UI that exposes the information. Currently we have the group tag and we have comps.xml as the two places where this information can live. So the information would better live in comps than the group tag... or we could invent yet another place to keep the information. > b) browsing through every package in the distribution wasn't > interesting when it was < 1000. browsing through 4000 packages is even > worse > No. Browsing through packages using this UI is uninteresting. Browsing itself is still interesting. Browsing can allow you to find things you didn't quite know you were looking for. It can allow you to explore a new subject. It can help you break a piece of information up into managable bites for learning. It can help you see the relationship between two areas you thought were separate. > > > Rather than focusing on the question > > > of "how do I fit this in comps" or "how do I list every package because > > > oh my god, how else do I find something", the _real_ question is trying > > > to figure out what the user experience we're trying to get at is, get > > > some mock ups and then figure out what the "right" implementation path > > > is from there. > > > > > User Experience > > Objective > > Allow a user to view a subset of packages in a set of repositories > > that matches categories of software that they are interested in > > installing. This allows the user to more quickly discover a package > > that fills a need for them. > > While a good high level description of what's wanted, it's not a very > good place to start for designing a UI. Things really need to be far > more focused. Use cases are one common approach; there are others. > > > Interface1 > > 1) Select a group from all groups valid for the repository > > 2) List all packages which match that group. > > 3) Allow the user to select another group from the groups that these > > packages have. > > Repeat from 2 until A) the list of other groups would have a single > > entry, B) there's only a single package in the package list. C) User has > > left this interface > > This is actually a direction that we (pnasrat, clumens, myself and a few > others) were looking at when we got to the current package selection UI. > The problems started coming in around how to sanely handle a native UI > where you want to allow multiple selection of packages, and then viewing > even more details without too many levels of nested dialogs. You are talking about what you wanted from the installer. But that's not necessarily relevant to what you want from a graphical package manager. Or from a web based package lister (a la repoview). repoview doesn't need to worry about multiple selection of packages, for instance. > > Interface2 > > yum groupsearch Development Python Cryptography > > Finds all packages in the repositories whose group information > > contains all of those patterns. > > Search is *definitely* something that's incredibly useful and important. > Realistically, it's probably more interesting than browse for most use > cases. Can the search that's currently there be improved, yep. Was > easiest to just start with 'yum search' and then improve from there. search and browse are very different. I would say that browse is at least as useful to get right as search, possibly more. Search works on the principle that you know what you are looking for, you just don't know its name. Browse works on the principle that you sense what you are looking for, you just don't know how to express what that is. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
