On 5/22/05, Kyrre Ness Sjobak <kyrre@xxxxxxxxxxxxxxxxxx> wrote: > That is the job of a well-written web portal. web portals are nice.. but surely a different website portal per repository is an inherently redudant and complex way of accessing information that should be available on the client computer via metadata. I don't think relying on web portals is the best solution long term. A client side application that reads metadata either from repositories on the network or repositories defined locally is the best primary way to 'find' packages. Unless of course, you are willing to jettison any hope of building a solution that allows people to use repositories on local media and will require everyone to have network access. Fire up an install application, that allows for some ability to browse the entire configured package catelog available on that client. > Auch. That i did not think about. But surely, some solution could be > found. Isn't license review as part of 'finding' a package good enough? I don't think license review is worth imposing on people as part of the install step for the vast majority of software. For the small percentage of proprietary software that exists for linux... provide a post package install license review mechanism... if those restrictive propretary eula's require a click-through before using the software. > But more intuitive. Almost every user "discovers" up2date immediatly, > and try to use that. They do not discover yum before someone points them > to it. And I say build something to replace up2date that is a client side app instead of relying on browsers and multiple website trolling everytime you want to find a package. If up2date is a poor implementation of an intuitive approach..then i say we re-implement that client side application approach.. instead of moving to a website portal download approach. > Also a good idea - but what about libs, such as gstreamer-mp3? BTW. > doesn't Ubuntu use an interface similar to this one? Plugins and kernel modules... are more difficult.. and go right back to the subtle but more difficult question of how users are expected to discover or find applications at all. For items that don't fit intuitively as menu items, you can extend the menu metaphor to include a "Search for Software" dialog. So for example, users who are looking for mp3 support would fire up the "Search For Software" dialog from the menu layout and search for mp3. The resulting list of packages and short descriptions should be enough for users to use to install the plugin package they want. Take a good look at the UI for the gnome "Search for Files" dialog from the gnome menu. I think a lot of the UI from that dialog could be mapped over to software installation functionality. Repos instead of folders, and things like Tag "whatever" contains the text "this text" with a pull down menu for package tags, so you can do very refined searches by adding multiple tag related alpha-numeric searches. This should be as intuitive to any user who is use to using the gnome menu as a primary way of interacting with their system. Can it be more intuitive than that? -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
