[opensuse-gnome] package\selector small UI change proposal
I have another proposal for small changes to the UI. Would it be possible to implement something like this for the package selector? http://sukimashita.com/temp/yast2-gtk-package-selector-1.gif Similar for the categories (the themes have icons available) and perhaps the patterns (although it might be hard to retrieve a correct pattern<->icon mapping). One last thing I am missing is the ability to filter based on "Packages for Upgrade", "Normal Packages Packages", "To be Deleted", "To be Installed" etc. to for instance somehow be able to only list the packages that can be upgraded to abuse this as a selective upgrade tool. However, feeling the need for above might aswell just be the result of opensuse-updater failing to give me any hint (even a "Details" would be sufficient; the current only lists official updates) at which packages it would update when I click OK. The biggest issue are cross-vendor updates which can screw up stuff, which might be solved with a new checkbox for preferences and enabled by default? I'd be willing to supply patches if that looks ok to implement. --- Martin -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Sex, 2007-10-12 às 12:34 +0200, Martin Szulecki escreveu:
I have another proposal for small changes to the UI.
Hi Martin, The mockup looks great, thanks. Christian Jäger also suggested the use of icons. However, I am afraid we can only hack that for installed software. Zypp downloads a file from the repos that has some informations about the packages (names, descriptions, ...), but it doesn't have an inlined icon -- it doesn't even have all the RPM header info. We would need to download the entire package to extract that information. What we can do, for the available packages, is to use the icon of the group they belong to. E.g. for bombermaze, I guess the games/action. We already have exchanged some ideas privately about the interface. You guys can start a public discussion, if you wish. We'll certainly listen to the feedback. Maybe during next week I can start working on it; before changing the interface, I will want to re-work the code to support for this, which can take more time. Some stuff we need: * support for filters. Besides the name search, we need filtering based on statuses and repositories. Would be great if they could be used together. Maybe have a left pane for them, hiding them with expanders by default (the search would always be visible of course). * browse. Whenever the user wants to check out what other word processor (to give an example) are available, browsing is more reliable than search, that can miss something. So, browse should really be a first class citizen. Maybe we could have it together with search, on the filters pane, though it makes only sense for packages. Anyway, we probably want something external like yast-qt has, because it gives more flexibility to the user to list all Server Programs, without having to go through all nodes. And we really need icons for the browser, to make it easier to navigate. * dedicated interface for upgrading. We need to give the user more information on the upgrades (and downgrades) available. A nice extra could be doing a diff between the installed ChangeLog and the available one, so the user can check easily what's new. (they aren't very nice). Maybe an extra Upgrade tab page (or Version) should be available when a package has multiple versions. About the two pools approach, or the one of yast-qt, we can make it configurable, even through the interface, so don't loose your time arguing about it. :) In the same vein, we will probably also want to support a tile view (as suggested by Christian Jäger), maybe like the application-browser, besides the list view, since it lets the user see more stuff. Cheers, Ricardo
Would it be possible to implement something like this for the package selector? http://sukimashita.com/temp/yast2-gtk-package-selector-1.gif
Similar for the categories (the themes have icons available) and perhaps the patterns (although it might be hard to retrieve a correct pattern<->icon mapping).
One last thing I am missing is the ability to filter based on "Packages for Upgrade", "Normal Packages Packages", "To be Deleted", "To be Installed" etc. to for instance somehow be able to only list the packages that can be upgraded to abuse this as a selective upgrade tool.
However, feeling the need for above might aswell just be the result of opensuse-updater failing to give me any hint (even a "Details" would be sufficient; the current only lists official updates) at which packages it would update when I click OK.
The biggest issue are cross-vendor updates which can screw up stuff, which might be solved with a new checkbox for preferences and enabled by default?
I'd be willing to supply patches if that looks ok to implement.
--- Martin
-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Thanks to you all, I'm really happy to see how much you people care about giving the package-selector a more user-friendly design! Am Freitag, den 12.10.2007, 15:45 +0100 schrieb Ricardo Cruz:
However, I am afraid we can only hack that for installed software. Zypp downloads a file from the repos that has some informations about the packages (names, descriptions, ...), but it doesn't have an inlined icon -- it doesn't even have all the RPM header info. We would need to download the entire package to extract that information.
Could the package-selector not tap external sources, like an ftp-directory with icons, to downloads icons by package-name?
Whenever the user wants to check out what other word processor (to give an example) are available, browsing is more reliable than search, that can miss something. So, browse should really be a first class citizen. ! ^_^
Maybe we could have it together with search, on the filters pane, though it makes only sense for packages. ! ^_^
- dedicated interface for upgrading. We need to give the user more information on the upgrades (and downgrades) available. A nice extra could be doing a diff between the installed ChangeLog and the available one, so the user can check easily what's new. (they aren't very nice). Maybe an extra Upgrade tab page (or Version) should be available when a package has multiple versions.
Yes, either tabs, or on the other hand, dropdown-lists seem a good solution for pre-defined view-filters ('view installed', 'view not installed', 'view upgrades', 'view third-party packages'...) Differently coloured up- and down-arrows certainly aren't good enough (and not intuitive). One more ting: I think we need a way to easily tell third-party packages from core-packages, similarly as it is easy in Ubuntu's package-manager.
About the two pools approach, or the one of yast-qt, we can make it configurable, even through the interface, so don't loose your time arguing about it. :)
A simple and an 'advanced' mode, perhaps? Martin Szulecki wrote:
However, feeling the need for above might aswell just be the result of opensuse-updater failing to give me any hint (even a "Details" would be sufficient; the current only lists official updates) at which packages it would update when I click OK.
Yes, I also feel far from comfortable with the updater in its current state. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
I just now saw that the Package-Kit-devs are also thinking of moving to a look similar to GNOME-control-center: http://www.packagekit.org/wiki/index.php/DesignIdeas Would it not be nice to have an 'install more'-button in the application-browser and keep a consistent design when the package-selector comes up? Greets, Chris -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Here is a Mockup that tries to stay as much in app-browser/control-center desdign as possible, in keeping most stuff in the left pane: http://img486.imageshack.us/my.php?image=entwurf5nt8.png There are three basic views: add, remove and update software. Clicking a tile in 'add'-view would mark a package for installation; all marked packages would be installed after pressing the 'perform actions' button. Navigation shown here is a simplified categories-view. 'Package Names' view could be a traditional list view with tickboxes and version numbers; the side-pane changes according to selected view. In 'categories' view, version number would only be visible in the dialogue after clicking a tile (not shown) and selecting 'details' (or if there are multiple versions of a package). Please note the status bar on the lower left that indicates repositories being refreshed in the background! ^_^(I would love to see this stuff backgrounded; and as version-numbers wouldn't be visible in category-view anyway, it should be absolutely possible to mark packages for installation before the specific version-numbers are known.) Have a nice weekend! Chris -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Here is a Mockup that tries to stay as much in app-browser/control-center desdign as possible, in keeping most stuff in the left pane: http://img486.imageshack.us/my.php?image=entwurf5nt8.png
This is a very cool suggestion and I would like it if we persued something along this nature, I believe it has already been established that displaying Icons for software not yet installed would be very difficult. This is way more than I suggested ,but I like it. On Sat, 2007-10-13 at 18:09 +0200, Christian Jäger wrote: -- James Tremblay Director of Technology Newmarket School District 213 S. Main st Newmarket NH, 03857 603-659-3271 *318 CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/Education Good things to read! http://en.opensuse.org/OpenSUSE_mailing_list_netiquette http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Am Sonntag, den 14.10.2007, 08:27 -0400 schrieb James Tremblay:
This is a very cool suggestion and I would like it if we persued something along this nature, I believe it has already been established that displaying Icons for software not yet installed would be very difficult. This is way more than I suggested ,but I like it.
Nice that you liked it. :-) Recently I've found out that what Mac-users love so much on their computers is the perseverence of analogies: Their application installation might suck aus much as that of Linux, but the analogy is sane: They think of applications as physical objects that are actually at the place you've put them: they drag them to the application folder to install, they drag them from there to the trash to uninstall them. Now, we can't do that, I believe. But if users have come to think of their applications as 'the things in the app-browser' then they probably would consider it as natural that they also install and uninstall them in that familiar environment. And I agree you were very right in the respect that package-management should start with a 'pattern'-view. Here is my attempt at a mockup for that: http://img524.imageshack.us/my.php?image=patternsmw1.png (Yeah, I know it's cheap to use a filter to get around drawing more...) Have a nice sunday! Chris -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
that: http://img524.imageshack.us/my.php?image=patternsmw1.png (Yeah, I know it's cheap to use a filter to get around drawing more...)
Have a nice sunday! Chris Chris, That is perfect,from the launch button> more applications> software management >install software> server functions> web and lamp> http-server, simple, intuitive and easy to figure out even if you've never seen openSUSE before.
thanks -- James Tremblay Director of Technology Newmarket School District 213 S. Main st Newmarket NH, 03857 603-659-3271 *318 CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/Education Good things to read! http://en.opensuse.org/OpenSUSE_mailing_list_netiquette http://www.catb.org/~esr/faqs/smart-questions.html -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Hi Christian and all, The problem with the Application Browser is that it only has one depth of branches, and the categories tree is mainly two in depth (sometimes more, like Development->Languages->C++). This isn't an issue for the usual Applications Browser because it only shows the installed applications, and only the graphical ones of that. But I'm afraid it would be a mess for the package selector. Possibly we wouldn't need to recreate the widget, we could work around this by prepadding some whitespaces on the subgroups labels... If we do add the full tree, something it wouldn't allow to, is to see everything below a certain node together, because the listing is static. Inclusive, the user couldn't search for some package and press All to see all the found packages together in the same block. But I guess this is a very small misfeature. Something that you didn't show in your mockup is how can the user revert some action. I guess we could use toggle buttons? About the descriptions and other info, I guess that the confirm dialog would feature those, right? Anyway, I wonder whether it wouldn't make more sense to make a dedicated Installer for the newbie. It could just feature all the essential graphical applications. For removal, he could use the ordinary Browser. And, for upgrade, we could have a system that could check for upgrades, from time to time, whenever the user started an application. It is important to have a flexible interface so we can easily cope with the more experience users needs. Here's a mockup of mine: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/ricado-split-use-cases.s... We split completely the user cases. The other pool would be to revert changes. (Surely, we want to have a one-pool option to keep those guys happy. And of course, the tiles view.) I wonder whether this makes sense or if there are use cases, where everything should be together. Cheers, Ricardo Sáb, 2007-10-13 às 18:09 +0200, Christian Jäger escreveu:
Here is a Mockup that tries to stay as much in app-browser/control-center desdign as possible, in keeping most stuff in the left pane: http://img486.imageshack.us/my.php?image=entwurf5nt8.png
There are three basic views: add, remove and update software. Clicking a tile in 'add'-view would mark a package for installation; all marked packages would be installed after pressing the 'perform actions' button.
Navigation shown here is a simplified categories-view. 'Package Names' view could be a traditional list view with tickboxes and version numbers; the side-pane changes according to selected view.
In 'categories' view, version number would only be visible in the dialogue after clicking a tile (not shown) and selecting 'details' (or if there are multiple versions of a package).
Please note the status bar on the lower left that indicates repositories being refreshed in the background! ^_^(I would love to see this stuff backgrounded; and as version-numbers wouldn't be visible in category-view anyway, it should be absolutely possible to mark packages for installation before the specific version-numbers are known.)
Have a nice weekend! Chris
Sáb, 2007-10-13 às 18:09 +0200, Christian Jäger escreveu:
Here is a Mockup that tries to stay as much in app-browser/control-center desdign as possible, in keeping most stuff in the left pane: http://img486.imageshack.us/my.php?image=entwurf5nt8.png
There are three basic views: add, remove and update software. Clicking a tile in 'add'-view would mark a package for installation; all marked packages would be installed after pressing the 'perform actions' button.
Navigation shown here is a simplified categories-view. 'Package Names' view could be a traditional list view with tickboxes and version numbers; the side-pane changes according to selected view.
In 'categories' view, version number would only be visible in the dialogue after clicking a tile (not shown) and selecting 'details' (or if there are multiple versions of a package).
Please note the status bar on the lower left that indicates repositories being refreshed in the background! ^_^(I would love to see this stuff backgrounded; and as version-numbers wouldn't be visible in category-view anyway, it should be absolutely possible to mark packages for installation before the specific version-numbers are known.)
Have a nice weekend! Chris
We split completely the use cases.
-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Hello Ricardo, hello all! Am Dienstag, den 23.10.2007, 15:37 +0100 schrieb Ricardo Cruz:
The problem with the Application Browser is that it only has one depth of branches, and the categories tree is mainly two in depth (sometimes more, like Development->Languages->C++). This isn't an issue for the usual Applications Browser because it only shows the installed applications, and only the graphical ones of that. But I'm afraid it would be a mess for the package selector.
Yes, when you first mentioned that, I thought 'aha, that's the reason why categories grow too large and thus hard to navigate'. Is there any kind of flexibity at all; like changing views of the side-pane? Could we perhaps solve it by having a kind of 'tabs view', i.e. only the category selected on the left is shown, and only that category itself is broken down into sub-categories visible on the right? Combined perhaps with deeper sub-categories represented by clickable folders which lead to a sublevel when clicked? (I hope I get across what I mean here... -_-)
Possibly we wouldn't need to recreate the widget, we could work around this by prepadding some whitespaces on the subgroups labels...
Neat trick. ^_^
If we do add the full tree, something it wouldn't allow to, is to see everything below a certain node together, because the listing is static. Inclusive, the user couldn't search for some package and press All to see all the found packages together in the same block. But I guess this is a very small misfeature.
About 'the full tree'; wouldn't we drop the topmost category anyway (productivity, amusement)? I don't think novice users find that one useful.
Something that you didn't show in your mockup is how can the user revert some action. I guess we could use toggle buttons? About the
I thought along the lines of 'click once to mark for install, click again to undo'. Perhaps a tooltip when hovering the mouse-pointer over the marked tile would be sufficient, or perhaps an optical hint like 'pressed-down-button'-look? BTW, here a slightly 'cleaner' version of the inital mockup: http://img89.imageshack.us/my.php?image=entwurf6ul3.png
descriptions and other info, I guess that the confirm dialog would feature those, right?
Yes; although I have to say, I'm a still a big fan of the way Ubuntu's 'add/remove' dialogue presents information about the applications (including those intriguing icons; lucky .deb-people... ;)). In the mockup this information would only appear when the 'details' button is clicked, but that really was laziness on my part. I think it would be better to present as much info as possible about the application - including small icons for alternate versions where applicable.
Anyway, I wonder whether it wouldn't make more sense to make a dedicated Installer for the newbie. It could just feature all the essential graphical applications.
Just like the app-browser does, agreed there. The everyday-user needs to install either specific graphical applications or patterns that enable him to do something, not packages; those should be pulled as dependencies without user-interactions (and that's the way it is done already, thank you!).
For removal, he could use the ordinary Browser.
Agreed. Wouldn't it be a step-up in user-experience, if a user wasn't conscious of _using_ a package-manager anymore? It would certainly get rid of a 'scare-issue' for many. I think this 'lack of scare' is what Mac-users love so much about their OS. It seems they hardly ever get into a situation that overburdens them. I like drap-and-drop. My IDEAL package manager for computer-novices would consist of a window of available applications popping up from which you drag and drop icons into your application-browser. And uninstall packages by moving them to trash from the application-browser. How do you think about this as a long-term perspective? This brings me to another important issue: On many users the wonders of the contextual dialogue within the app-browser to remove applications or add them to 'favorites' is completely lost. One will find again and again, reviewers and blog-writers complaining ' the main menu only has six entries, and it's all apps that I don't use'. So it would be good to make it more obvious. The app-browser seems to support drag-and-drop. Does this go to the level that we could have areas in the left pane like 'drag here to uninstall'? (BTW, it would be VERY nice if uninstalling from the app-browser wouldn't pop up the package-manager to (unncecessarily) refresh repositories and ask for user-action. A quiet uninstall without frills after one confirmation would be ideal.) See this mockup: http://img136.imageshack.us/img136/7461/beefedupappbrowsersu8.th.png
And, for upgrade, we could have a system that could check for upgrades, from time to time, whenever the user started an application.
This can lead to some nag. Windows-applications are actually quite bothersome IMHO; at least once a day a Windows-app asks me to be updated.
It is important to have a flexible interface so we can easily cope with the more experience users needs.
Here's a mockup of mine: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/ricado-split-use-cases.s...
We split completely the user cases. The other pool would be to revert changes. (Surely, we want to have a one-pool option to keep those guys happy. And of course, the tiles view.) I wonder whether this makes sense or if there are use cases, where everything should be together.
It does look like a mix of the current two-columns-approach and YaST-QT. Two columns made sense for the 'installed/not installed'-analogy, I have troubles finding an analogy here. Could we not get rid of one column? I must say that for advanced package-management I personally prefer SmartPM's view - installed and uninstalled packages, and different versions, simply side-by-side. Such a look could perhaps be integrated as 'expert/packages-view' into an app-browser-like manager, too? I don't know exactly why but people constantly complain when there is more than one way to do something in openSUSE. :p) Though perhaps when 'novice-package-management' is embedded very unobtrusively into the app-browser they wouldn't realize they have two frontends, and that probably be OK for them... Again, it is so great to see that a user-friendly design has a high priority for the openSUSE-project - thank you all for your time! Greets, Chris -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Hi, Sorry for taking awhile. It seems people are interested interested in using PackageKit (http://www.packagekit.org/) which is meant to be a common package and update manager interface common for all distributions, they would just adapt the backend. But such work would require quite some effort, and there doesn't seem to exist any serious effort at the moment, so we should probably work out yast-gtk's selector. Qua, 2007-10-24 às 13:41 +0200, Christian Jäger escreveu:
Something that you didn't show in your mockup is how can the user revert some action. I guess we could use toggle buttons? About the
I thought along the lines of 'click once to mark for install, click again to undo'. Perhaps a tooltip when hovering the mouse-pointer over the marked tile would be sufficient, or perhaps an optical hint like 'pressed-down-button'-look?
Sure, you mean a Toggle Button, right? As in (paste to terminal): python import gtk window = gtk.Window() window.add (gtk.ToggleButton ("Package")) window.show_all() gtk.main()
descriptions and other info, I guess that the confirm dialog would feature those, right?
Yes; although I have to say, I'm a still a big fan of the way Ubuntu's 'add/remove' dialogue presents information about the applications
I guess you don't mean Synaptic, do you? Could you get me a shot of that program?
(including those intriguing icons; lucky .deb-people... ;)).
We could copy them, we don't need to use the ugly ones from yast-qt. :)
In the mockup this information would only appear when the 'details' button is clicked
Okay. I just think its too "buried", so I would vote to just have the info (on tabpages, like now) already visible there. I think most user would want to take a look at Details anyway, and it is much more comfortable for those that want to check the Details of several packages (e.g. when choosing a word processor).
, but that really was laziness on my part. I think it would be better to present as much info as possible about the application - including small icons for alternate versions where applicable.
I am not sure what you mean by small icons. I guess we would want to have a combo box like: Version: | 10.5 / | Repo: opensuse.org Details: ........... ................... ................... |Cancel| |Install| The repo and maybe other fields would change as the user chooses a version.
Anyway, I wonder whether it wouldn't make more sense to make a dedicated Installer for the newbie. It could just feature all the essential graphical applications.
Just like the app-browser does, agreed there. The everyday-user needs to install either specific graphical applications or patterns that enable him to do something, not packages; those should be pulled as dependencies without user-interactions (and that's the way it is done already, thank you!).
Yep, the installer should just lists all applications available, e.g. for word processing, and describe them, maybe even comparing them. Stuff like openoffice-plugin-* wouldn't be another package, they would just be displayed together with OpenOffice from some button or something... Anyway, what I want to do here is improve the yast-gtk package selector (possibly the updater too). I just want something more friendly than yast-qt for people comfortable with computers.
I like drap-and-drop. My IDEAL package manager for computer-novices would consist of a window of available applications popping up from which you drag and drop icons into your application-browser. And uninstall packages by moving them to trash from the application-browser.
How do you think about this as a long-term perspective?
I think Apple's success here has more to do with the fact that applications are self-contained. They are just some package file that you double-click, and independently where it is, it runs. As a result, people see an application package, just like a document file. So, they organize them, as they would organize their documents. In MacOS, the file manager is more integrated with the environment, their windows are not very big, so drag-n-drop is easier and is more used. But drag-n-drop is not what makes this friendly. Anyway, I think a nice installer's interface could very well compete with that system in terms of ease of use. People are already familiar with iTunes and other music repos apps, so it could very well work for packages.
This brings me to another important issue: On many users the wonders of the contextual dialogue within the app-browser to remove applications or add them to 'favorites' is completely lost. One will find again and again, reviewers and blog-writers complaining ' the main menu only has six entries, and it's all apps that I don't use'.
*snip* *mockup* *snip*
Yep, that's an issue, and your mockup solves it nicely. You should definitively open some bug report on that (https://bugzilla.novell.com/). What could be confusing about the mockup is that the Actions items looks like the Group ones, so you get the feeling they are buttons... If Actions was aligned to the bottom that might be enough to make it clear they are distinct (and they really should be aligned to the bottom anyway since they are not that frequently used to deserve such a visible spot). And to make it clear that the user can drag things there, maybe they should have a sunken shadow. Actually, I think you could just have the three sunken medium-size icons, no labels. And the user would get a tooltip on mouse hover. Something important about uninstall is that the user shouldn't care about dependencies. So, if it tells Skencil to uninstall, but keeps Inkspace, Skencil should not actually be uninstalled, just hidden. (Possibly a dialog for the user to confirm that.)
(BTW, it would be VERY nice if uninstalling from the app-browser wouldn't pop up the package-manager to (unncecessarily) refresh repositories and ask for user-action. A quiet uninstall without frills after one confirmation would be ideal.)
Right, though I'd say the popups madness ought to be addressed first. ;)
Here's a mockup of mine: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/ricado-split-use-cases.s...
We split completely the user cases. The other pool would be to revert changes. (Surely, we want to have a one-pool option to keep those guys happy. And of course, the tiles view.) I wonder whether this makes sense or if there are use cases, where everything should be together.
It does look like a mix of the current two-columns-approach and YaST-QT. Two columns made sense for the 'installed/not installed'-analogy, I have troubles finding an analogy here.
The revert column would have a fixed size... But okay, simple check marks should make more sense.
Could we not get rid of one column? I must say that for advanced package-management I personally prefer SmartPM's view - installed and uninstalled packages, and different versions, simply side-by-side. Such a look could perhaps be integrated as 'expert/packages-view' into an app-browser-like manager, too?
SmartPM is similar to yast-qt in this aspect, right? I like it more task oriented... Maybe we could have both worlds; display all packages in the different actions. The package would just be either enabled/disabled depending whether the action applies or not. :/ CU, Ricardo -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Hello, Am Montag, den 29.10.2007, 22:34 +0000 schrieb Ricardo Cruz:
Hi,
Sorry for taking awhile.
It seems people are interested interested in using PackageKit (http://www.packagekit.org/) which is meant to be a common package and update manager interface common for all distributions, they would just adapt the backend. But such work would require quite some effort, and there doesn't seem to exist any serious effort at the moment, so we should probably work out yast-gtk's selector.
They seem to want to go in the same direction, judging from the mock-ups on their page. So perhaps there can be some reciprocal code-contribution at a later time? Other than that, I agree. There are many merits in PackageKit but no advantage in usability; the project is too young to have received much user-feedback.
Qua, 2007-10-24 às 13:41 +0200, Christian Jäger escreveu:
Something that you didn't show in your mockup is how can the user revert some action. I guess we could use toggle buttons? About the
I thought along the lines of 'click once to mark for install, click again to undo'. Perhaps a tooltip when hovering the mouse-pointer over the marked tile would be sufficient, or perhaps an optical hint like 'pressed-down-button'-look?
Sure, you mean a Toggle Button, right? As in (paste to terminal):
*snip* I'm certainly missing some dev-packages in order for your python script to work - but I meant something akin to the 'active' look that you get when the mouse-cursor is hovering over a template. It seems very intuitive to me that a button that looks 'pressed down' can be released again by pressing (=clicking) once more; and also that I still have to press some 'activation'-button ('perform actions', in this case) in order to set something in motion.
descriptions and other info, I guess that the confirm dialog would feature those, right?
Yes; although I have to say, I'm a still a big fan of the way Ubuntu's 'add/remove' dialogue presents information about the applications
I guess you don't mean Synaptic, do you? Could you get me a shot of that program?
Found an image here: http://www.movingtofreedom.org/images/2007/03/ubuntu-add-remove-applications... I guess it is 'Synaptic in disguise'; pretty much standard, really - but the simple categorization, the nicely detailed descriptions of the applications and the colourful icons set it apart. This is not what I would want for openSUSE, but it is a list-view done right IMHO.
(including those intriguing icons; lucky .deb-people... ;)).
We could copy them, we don't need to use the ugly ones from yast-qt. :)
;)
In the mockup this information would only appear when the 'details' button is clicked
Okay. I just think its too "buried", so I would vote to just have the info (on tabpages, like now) already visible there. I think most user would want to take a look at Details anyway, and it is much more comfortable for those that want to check the Details of several packages (e.g. when choosing a word processor).
Yes, all info should be visible after clicking just one time. Otherwise this would loose out in terms of usability to the old package-manager.
, but that really was laziness on my part. I think it would be better to present as much info as possible about the application - including small icons for alternate versions where applicable.
I am not sure what you mean by small icons. I guess we would want to have a combo box like:
Version: | 10.5 / | Repo: opensuse.org Details: ........... ................... ................... |Cancel| |Install|
The repo and maybe other fields would change as the user chooses a version.
By 'small icons' I only meant that the options presented for multi-version packages would differ slightly from your design above. Instead of 'cancel / install' it would then be 'install from a)-, b)-, c)-repo / cancel' where 'a)', 'b)' and 'c' would look nicest if represented by friendly icons. But icons might not be easily done, and it is not important, anyway. The main thing is that different versions would be installable from this view.
I like drap-and-drop. My IDEAL package manager for computer-novices would consist of a window of available applications popping up from which you drag and drop icons into your application-browser. And uninstall packages by moving them to trash from the application-browser.
How do you think about this as a long-term perspective?
I think Apple's success here has more to do with the fact that applications are self-contained. They are just some package file that you double-click, and independently where it is, it runs.
[OT]If it were so easy... Actually I find their implementation of a good idea quite bad - in most cases you click on a .dmg-file, which results in mounting a virtual CD (now, how intuitive is that?) which presents which yet another windows where you see an icon of the application and an icon representing your applications folder; beneath it the instruction to drag the application-icon onto the application-folder. I don't understand why they don't dumb it down and let the user drag .dmgs onto their application-folder.[/OT]
Anyway, I think a nice installer's interface could very well compete with that system in terms of ease of use. People are already familiar with iTunes and other music repos apps, so it could very well work for packages.
Agreed. Just for fun, a quick mockup to show what I meant: http://img477.imageshack.us/my.php?image=dragdropxz7.png
This brings me to another important issue: On many users the wonders of the contextual dialogue within the app-browser to remove applications or add them to 'favorites' is completely lost. One will find again and again, reviewers and blog-writers complaining ' the main menu only has six entries, and it's all apps that I don't use'.
*snip* *mockup* *snip*
Yep, that's an issue, and your mockup solves it nicely. You should definitively open some bug report on that (https://bugzilla.novell.com/).
I had my 'enhancement'-bug reports repeatedly closed on me and been told bugzilla is not for that; so I won't. Perhaps I will put it into some feature-request-list on the Wiki.
What could be confusing about the mockup is that the Actions items looks like the Group ones, so you get the feeling they are buttons... If Actions was aligned to the bottom that might be enough to make it clear they are distinct (and they really should be aligned to the bottom anyway since they are not that frequently used to deserve such a visible spot).
And to make it clear that the user can drag things there, maybe they should have a sunken shadow. Actually, I think you could just have the three sunken medium-size icons, no labels. And the user would get a tooltip on mouse hover.
Yes, excellent!
Something important about uninstall is that the user shouldn't care about dependencies. So, if it tells Skencil to uninstall, but keeps Inkspace, Skencil should not actually be uninstalled, just hidden. (Possibly a dialog for the user to confirm that.)
(BTW, it would be VERY nice if uninstalling from the app-browser wouldn't pop up the package-manager to (unncecessarily) refresh repositories and ask for user-action. A quiet uninstall without frills after one confirmation would be ideal.)
Right, though I'd say the popups madness ought to be addressed first. ;)
Here's a mockup of mine: http://www.alunos.dcc.fc.up.pt/~c0607045/trash/yast/ricado-split-use-cases.s...
We split completely the user cases. The other pool would be to revert changes. (Surely, we want to have a one-pool option to keep those guys happy. And of course, the tiles view.) I wonder whether this makes sense or if there are use cases, where everything should be together.
It does look like a mix of the current two-columns-approach and YaST-QT. Two columns made sense for the 'installed/not installed'-analogy, I have troubles finding an analogy here.
The revert column would have a fixed size... But okay, simple check marks should make more sense.
Could we not get rid of one column? I must say that for advanced package-management I personally prefer SmartPM's view - installed and uninstalled packages, and different versions, simply side-by-side. Such a look could perhaps be integrated as 'expert/packages-view' into an app-browser-like manager, too?
SmartPM is similar to yast-qt in this aspect, right?
I like it more task oriented... Maybe we could have both worlds; display all packages in the different actions. The package would just be either enabled/disabled depending whether the action applies or not. :/
Or maybe use package-kit for advanced actions and the 'app-browser-integrated' package-management for novice-mode? Thanks for your interest. Greets, Chri -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
Qua, 2007-10-31 às 15:31 +0100, Christian Jäger escreveu:
Am Montag, den 29.10.2007, 22:34 +0000 schrieb Ricardo Cruz:
It seems people are interested interested in using PackageKit (http://www.packagekit.org/) which is meant to be a common package and update manager interface common for all distributions, they would just adapt the backend. But such work would require quite some effort, and there doesn't seem to exist any serious effort at the moment, so we should probably work out yast-gtk's selector.
They seem to want to go in the same direction, judging from the mock-ups on their page. So perhaps there can be some reciprocal code-contribution at a later time? Other than that, I agree. There are many merits in PackageKit but no advantage in usability; the project is too young to have received much user-feedback.
When I meant it requires serious effort, I wasn't talking about the GTK interface, but rather about the all operation. You know, installer's integration, Qt/ncurses interface, Zypp backend, extending it for Patterns and Languages. Possibly other stuff...
I'm certainly missing some dev-packages in order for your python script to work
Oh, you don't know what you're missing. PyGtk rocks for RAD. ;)
Found an image here: http://www.movingtofreedom.org/images/2007/03/ubuntu-add-remove-applications... I guess it is 'Synaptic in disguise'; pretty much standard, really - but the simple categorization, the nicely detailed descriptions of the applications and the colourful icons set it apart.
This is not what I would want for openSUSE, but it is a list-view done right IMHO.
Of course, it gets trickier when you want to present multiple versions, and allow for upgrades. Anyway, I guess we might go in that direction. I prefer though to have external buttons, rather than those check boxes. I think I would go for something like PackageKit. So, when I have the time, I will work on the storage, so we have some nice API, with some flexibility for some interface designing... We could maybe share some more thoughts then... Cheers, Ricardo -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
working link for app-browser mockup: http://img139.imageshack.us/my.php?image=beefedupappbrowserfj9.png -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org
participants (4)
-
Christian Jäger -
James Tremblay -
Martin Szulecki -
Ricardo Cruz