Package Manager GUI mockup

1

Hello there!

I was thinking about how Haiku’s package management front-end may look like. Here’s my mockup:

PM_mockup.png736×599 64.1 KB

Before continue reading my explanations, you may want study the mockup for yourself a bit, in order to point out un-intuitive parts.

The top row has settings to limit the list of available packages below.

The “Category” lists various categories of software, like “Audio”, “Video”, “Graphics”, “Games”, “Development”, “Shell”, “Miscellaneous” etc. It also offers “Haiku” for updates to the Haiku system.
Besides those, we’ll also have “Installed packages” for active packages, “Uninstalled packages” for those that have been downloaded, but aren’t active/installed at the moment. “Update available” will show all packages of your system (installed and currently uninstalled) that have an update available.
“Download in progress” will show all packages currently being downloaded.

“Depots” let’s you choose all or specific repositories (“Depots”) included in the list. It’ll work like the “Disk” pop-up in Tracker’s Find… panel. There’s an entry “Manage depots…” that’ll open the respective tab of the settings panel.

Lastly, you can filter the list with a search string tht will be applied to all visible columns of the list.

The list will behave like a Tracker window, i.e. you can choose what “attributes” are visible, their order and sorting order.

Delete will delete a downloaded package.
Update will update when available.
Uninstall will make a package inactive.
Install will download and install a package or make an inactive package active again.
The functions of all buttons are also available in a context menu.

To the left of the buttons is enough space for a status like a “Installation in progress….” with a barber pole.

The dotted line separating the bottm section is the handle for the split screen that lets you vertically resize the top section.

At the bottom are stats of the selected package to the left. The “Dependecies” will list other needed packages for that app.
To the right is a short description for the app, a screensh ot thumbnail that’ll open the full size version in ShowImage and contact email address and homepage URL opening in Mail or Web+ respectively.

I hope this mockup and the possible discussion in this thread can serve as inspiration for the devs that’ll work on this app.

Regards,
Humdinger

2

Awesome, I like it. It would be nice if one could filter based only on the package name. Say I wanted to install Java, I wouldn’t want a bunch of Java apps listed because they contain Java in their description.

Sort of off-topic: I don’t like how yum extender takes five minutes to reload all packages after installing packages. Synaptic does a much better job. Hopefully Haiku Depot could cache package lists so it doesn’t have this problem

3

nice mockup, the only thing I dont like is the confusion that might occur between the words “Software” and “Package”, at least to the average user. Is “software” the same thing as “package” ? or is “package” part of the “software” ? Is it technically called “software package” ?. I know these questions might seem obvious for the majority here but my experience with helping people around me taught me to question everything.

Another example of something obvious but not so much for a “simple user”, wich is : “Whats the difference between delete and uninstall ?”, “Is the delete more powerful than uninstall ?”, “Why not only use Delete ?”

So all I want to say is that beside the mockups, we should agree also on some “official” and “easy to grasp” terminology in order to increase usability. And believe me, some concept are really difficult for average people even if they dont complain because “it just works like that and you have to get along”, for example dealing with the question “should I click twice or once on that ?”.

And again, nice work.

4

In this specific example, I would question why Java should be installed in the first place. After all, apps needing it will automatically get it as a dependency. :slight_smile:
Generally, this problem can be avoided by temporarily removing the “Description” column.
Another possibility is to slightly highlight the filter string where it occurs. Then you can quickly skim the “Name” column. Would be a nice touch for Trackers type-ahead filtering as well.

Regards,
Humdinger

5

An awesome looking mockup, indeed! One thing that I find interesting when I update my software is a changelog, so I’d like to see it here too. There’s no room for it currently, though.

Another possibility to reduce the clutter is to combine Install/Uninstall buttons.

Drag-n-drop support would be also a nice touch, if you want to get some packages for future purpose, like installing it on a system without Internet connection or if NIC is not yet supported, etc.

Great work!

6

“Software Center” in the title is just a place holder for the eventual name. But I do agree that we should come up and stick to a consistent terminology. “Software” is quite a broad, abstract term, that may include all software on your system. “Package” on the other hand can be quite specific, e.g. the “Java” package.

Believe it or not, that point did go around in my mind as well.
Install/uninstall is just such a nice word pair… I can install a package, no matter if I have it already locally on my computer or if I had to get it first from a depot. I can “de-activate” an installed package, but to re-activate a package, clicking “Install” doesn’t feel right. Changing the labels of buttons and menu items depending on the contents isn’t good design either…
Maybe tooltips like “Uninstall package without deleting” for the uninstall button and “Remove package from disk” for the delete button can help.

Thanks for the feedback so far!
Humdinger

7

One thing was missing from my mockup: How to deal with other versions of a package.
I propose another button “Version history” in the far left of the button bar or maybe below the stats of the package at the lower left. Click it and you’ll get something simple like this:

You’ll see every version available for the selected package. Here you see that you currently have 2.1.0 installed and an older version 2.0 uninstalled (but locally still on your disk). Nothing prevents you to have two versions installed side by side (I guess… that depends how clever our package management really is…).
To update to the newest version, just select 2.1.2 and press “Install”.
If that side-by-side thing doesn’t work - think Haiku system packages including the kernel - that may automatically uninstall (not delete) the currently installed version.

@diver: was that what you had in mind for your changelog? If not, maybe that log could be accessible from the menu bar instead of appearing in the GUI of the main window to avoid clutter.

Regards,
Humdinger

Edit: removes the unnecessary space around the list view.

8

My 5 cents:

- How about adding full category tree on the left, just like i’ve done it in SPM

- Info about package [down-left] could be made in outline style [just like apps categories]

9

Very nice mockup, with a design centered on package categories + current status, which I really like.

So far, my only negative reaction concerns the screenshot area: it’s clearly too small, and should definitively supports multiple screenshots (without having to click to see each ones at large enough size) not just a single one. Which means that somehow more space should be made for this when at least one screenshot is available.

Maybe the package info could be shown under some collapsable sections, for instance.

Another useful feature I like more and more: a way to see others packages by same publisher.

10

I could imagine that those screenshots will be too small regardless how big the thumbnails are. So, to actually see something useful, you’ll have to open them fullsize anyway. The screenshot area could show a thumbnail that is resized so it fits best to the available space. If the package provides more than one, show 2 halfsized, 3 or 4 quarter sized (2 rows), 5 or 6 third sized (2 rows) thumbnails. Additionally, a mouse over could show a (relatively huge) half-sized full image.

Yes. The screenshot area could be moved to the left, with an expando stats section below.

This could be achived with the filter function. Just like in Tracker, where type-ahead filtering accepts AND linked strings (SHIFT+Space), we could use “|” to separate search strings. The author “YellowBites” under the Wonderbrush title could be clickable. That would automatically fill the filter box with the name of all YellowBites’ apps plus the name “YellowBites” itself |-separated. (Also, the “Author” and “Name” columns would be activated if they weren’t already).

Regards,
Humdinger

11

Very nice! Makes me sorta wanta jump right in and code the thing… Anyway, what I would change is the bottom area. I think it’s showing too much all at once. I would organize pretty much the whole area into a tab view, with the tabs (more or less) About, Version History, Package Info, Dependencies. That way you have more room for each individual page and there isn’t so much different type of info.

12

Which leads to another, maybe silly, question: for the query part, can’t this be simply done by a (packagefs-based) live query, putting this central BeOS/Haiku fs feature back at core?

What would be needed, then, will be some sort of Tracker-live-preview support that will show the package info and the commands available.

IMHO, Tracker would greatly benefits from having live Preview support since long already, something that can’t be achieved with tracker add-ons right now.

13

Very nice!

The package description, author(s), link(s), and possibly screenshots should be put in a scrollable TextControl IMHO because they will be variable size from package to package. At least that’s what is done in BAboutWindow which contains basically the same info

14

My quick mockup, a mash of first and second example presented here (second is Synthetic) as sort of integrated into (Navi)Tracker with navigation bar on the left (here displaying package categories).

Also, it worth to think about web-interface for managing packages from localhost or another computer via network (password protected login, obviously). Website with official Haiku packages - HaikuDepot - sort of AppStore would be great, too.

15

I have question about our PM, before the real design starts - how about PM that could be based and rely entirely on haikus tracker and specific BeFS Database attributes/extensions-*? No dedicated app for PM. Only modified tracker that reads specific directories and symlinks with info that will be sucked from repository. Then every haiku apps could benefit from this… for example query / find… of course tracker will need a small redesign or option to redesign himself when it jumps to ‘special’ directory where all files/symlinks to PM database lays…

im finding in it a lot of possibilities. for example using attributes and only thacker we could build a nice RSS viewer. Only thing we need is a tracker with GUI that “reacts” to attributes in specific folders and redesign self slightly using attributes in this ‘specific directory’. How about that?

for example:

if tracker jumps into folder that has a “packagemanagement” attributes in directory then while jumping into that directory it adjust itself to view this directory like normal package manager [like humdinger proposed]

if tracker jumps into folder that has a “rss” attributes in directory then while jumping into that directory it adjust itself to view this directory like normal RSS Agregator [similar to LifeRea / QuiteRSS]

yeah, we could build even a database that could be used as professional ERP or Business Manager Soft , based on tracker and bfs. But we need tracker to be more flexible in GUI terms and GUI View in tracker should rely strongly on BeFS attributes

*-This idea continues a haiku way to DO things introduced in Beos era for example: with emails in BeFS attributes.

Im waiting for Your comments
cheers
StreaK

16

I really like the idea, but it seems complicated. I see two ways of doing this.

  1. There would have to be a system settings file for each different filetype: pkg, rss, etc.
  2. We could make the tracker code extendable from the Haiku API so that one could easily make a specialized tracker-like app for a specific filetype.

I think this is a very good idea and should be developed

17

I like stippi’s idea to use tabs to separate the amount of info of a package.

I don’t see the point of streak’s idea doing all in Tracker instead of a dedicated app. Sounds complicated to me, esp. also considering the managing of online depots. One might add the possibility to install/uninstall packages that are already on disk with a Tracker add-on. But even that seems to me easier from within one dedicated app instead of either having to know the different locations of the packages or starting a query “manually”.

Anyway, this thread is to collect some ideas and anything might spark the creativity of the devs that will eventually come up with a PM front-end. So keep 'em coming!

Regards,
Humdinger

18

Here is what I got so far:

Almost none of it is functional. It is based on dummy package info hard-coded into the application. I want to get a bit further along (if time permits) so that I can be sure of what I really need for the app to work as one would want. Ingo says Oliver and he are really close to having hybrid builds working and then they can merge into trunk. That will update the Haiku Package Kit so that HaikuDepot could actually connect to real repositories. Most of the information displayed in the screenshot will however have to come from other sources. I imagine an open Wiki type of webpage, where this information can be entered (and translated) by “anyone”. But stuff like user-ratings will need more than a Wiki page, since the ratings should be entered directly in HaikuDepot and uploaded to the service.

19

One thing that comes to mind is that the version in the package title area could be a drop-down. I don’t think that multiple versions of the same package can be installed in parallel. A package defines where its files appear in the unified package FS. Two versions of WonderBrush would definitely clash in defining the same files in the same locations, for example. But the use-case of wanting to install an older version rather than a most current, possibly broken version, would be handled by the drop-down. The additional benefit would be that the user can get to all information in the package description area for the version chosen in the drop-down.

20

Very nice work, stippi! Watching you evolving the GUI was a pleasure to see.
Have you considered how to choose between different versions of a package? A user may want to have different versions installed in parallel or downgrade to an older version etc.

Thanks
Humdinger