Package Manager GUI mockup

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.

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!

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.

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.

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.

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

I don't really get it. I hear this so often that "everything" could be accomplished with Tracker. This gets limiting so quickly! Just because it sort of works for People files, and barely even works for Mails, it can't be abused for everything. It's not only that a dedicated app is easier to write, it's probably also far easier to use. I agree the list itself resembles what could be done in a Tracker window. Maybe every Tracker window should have the "filter" text field. But what about all the other controls? If I were to implement this in Tracker, I would have to rewrite Tracker to support having these flexible views. In the end, I would want it to look exactly like HaikuDepot looks now (or will look when its done), because I would want everything in one window. So what would be the point?

I fully agree with that. As far as packages go, there is the new Package Kit as an API abstraction for managing them. There will be lots of additional data per package needed to drive the representation in HaikuDepot. I will try to keep a clear layer between that data and the UI itself, it's just good design. I will however not make extra effort to faciliate writing alternative software centers. Like for example by putting parts of it into a library for no other purpose than to faciliate alternative front ends. If some developer deeply dislikes something about HaikuDepot, he has the choice of either pulling out a library himself and writing his GUI on top, or to simply improve HaikuDepot.

The interface is very nice, and I really love Stippi's simplifications...so friendly! Assuming users are coming to Haiku with no previous experience with package managers, it might be wise to use the most simple layman's terms possible. We can't assume they'll know what a depot is, or even what a package is. When we're in the middle of all this, it seems obvious, but for the sake of newcomers, I'd just suggest the labeling be made as unambiguous as possible.

Looking good. Is HaikuDepot the final name though? Seems a little abstract. Something like "Software Installer" or "Software Center" would be much more user friendly IMHO.

Has this progressed any further than just a mock-up yet?

i tried haikudepot , and it's a good start, but I think it needs more threads. The UI is too often blocking/hanging.
If you type in the searchfield: "a" then the haikudepot should not block you from adding also let's say "b" after the "a" . At the moment it blocks till list is displaying all software with "a".. etc...
I would put them in different threads. I think stippi needs to experiment with it, till he manages to give the user a smooth experiance.

i tried it too in vbox , yes, might be that is just 1 second or half a second, but it's a little inconvenient that you can not write fluently. And I can imagine that after we have more packages, it will increase.

The same is true, when you have clicked on a package, then the information is updated in the info-panel (bottom of the window), but you can not click fast on one, and then on another.
Or When you are in list of packages, and you are switching with keyboard from one to another package, there it blocks too for also let's say 1 second in vbox.

I would prefer that it works like that:
For example I'm at package.1 in the list, then i go with the keyboard down the list, to package.2 and package.3... etc.. till say package.5
I would like that haikudepot can continue downloading the "info" of package.1 , while I'm going down the list.
Then the thread of the info-panel could from time to time check if the list-view is still pointing at package.1 , if not, interrupt the process of downloading/displaying and moving to the actual position of the list.