- Debugger: Getting mixed signals
- 'Packaging Infrastructure' Contract Weekly Report #4
- Haiku monthly activity report - 06/2015
- 'Packaging Infrastructure' Contract Weekly Report #3
- 'Packaging Infrastructure' Contract Weekly Report #2
- GCI 2014 winners trip report (mentor side)
- TeX Live and LyX; Changes to the boot code
- 'Packaging Infrastructure' Contract Weekly Report #1
- Beginning of 'Packaging Infrastructure' Contract
- Haiku monthly activity report - 05/2015
Usability goodness
Who would have thought that something like me being chosen as a student for GSoC would actually happen. But it did. Blissfully indeed.
Anyway, designing a good user interface is not as easy as it seems. The truth is, not even for a second did I think it was, really. On my project road map, I've set designing the installer UI as my first task. Following the discussions with the Usability Team, a satisfactory concept came to life. The final result doesn't reassemble a bit what I imagined when writing my application - but it's much better than the latter. The major difference is in the approach - there's not much reassemblence left with the old Be's SoftwareWallet design. Even though their idea was quite intuitive and useful, there were many things that 'could have been done better'. Thanks to DarkWyrm and Waldemar for making me understand this better!
As for the design itself. We decided that the 'Groups' list view is quite unnecessary, since there's rarely more than two installation profiles available. Instead, a simple BMenuField would do the job better - renamed to a more appropriate 'Installation type' label. Beside rearrangements, the window title tab label naming was changed to 'Install PackageName' instead of 'PackageName'. We also came to a conclusion that having a 'Install' button is more informative than simple 'Begin'. The installation size and volume disk space information would be included beside the two drop down menu choices, so that the user would know this info immediately after dropping down the menu. An exemplary screenshot of how this would look like can be seen below.
PackageInstall user interface design screenshot
In user interface design every detail is important - this is what I came to understand during the past few months. A perfect solution does not exist. Good user interface design is a matter of choosing the most optimal 'design philosophy'. I believe this time we made a good choice. We will see in time if this is true indeed.
First stage almost clear, I'll try to move to the implementation stage as soon as possible. Beside this user interface, two more are waiting in line - the PackageInspector and PackageUninstall designs. Yes - there will be a native .pkg uninstaller this time. Stay tuned.
- Sil2100's blog
- Login or register to post comments
Comments
Re: Usability goodness
Oh my goodness! Haiku developer from Poland! Great to see you here my fellow countryman! :) Good luck with your project. When it is done - maybe you will start thinking about Haiku installation program... :)
/RochK
Re: Usability goodness
lol some times you read what you want it to say :) tought that I was reading about automatic installer and pkg installer in one package but now after reading it again I can't find it on IsComputeron.com :)
any way nice to see you in here :)
Can't wait untill we can test it :)
Re: Usability goodness
Looking good, nice and simple.
It would be nice to see if the package contains a root folder or not (so if you select /boot/apps/ will it actually go into /boot/apps/CoolApp?) No great ideas for how this could be done I'm afraid.
Path selection I think could be greatly improved throughout the OS - have "/boot" and "/apps" become hyperlinks that pop up a menu of other items in the same folder - perhaps in the same style as tracker's right click menus, so you could click "/apps" and quickly navigate to /boot/home/differentapps/. Expander could also use similar improvements to path selection and the ability to add new folders from within the interface. Not strictly part of your project, but a lot of BeOS apps are distributed as zips so it is still a related area IMHO.
Simon
Re: Usability goodness
It would be nice to see if the package contains a root folder or not (so if you select /boot/apps/ will it actually go into /boot/apps/CoolApp?) No great ideas for how this could be done I'm afraid.
If the app doesn't have its own folder you can only select the install volume (if that was your question).
Allowing to select the full target path might require a modified "Save As" dialog, so you can select the parent folder (e.g., "/boot/apps") and enter the name of the app folder (e.g.: "CoolApp"), but this might not work with all packages and I think it would only be a hack.
Path selection I think could be greatly improved throughout the OS - have "/boot" and "/apps" become hyperlinks that pop up a menu of other items in the same folder - perhaps in the same style as tracker's right click menus, so you could click "/apps" and quickly navigate to /boot/home/differentapps/. Expander could also use similar improvements to path selection and the ability to add new folders from within the interface. Not strictly part of your project, but a lot of BeOS apps are distributed as zips so it is still a related area IMHO.
The drop-down will automatically suggest a few common paths. For selecting custom paths drag-n-drop could do what you want (in addition to the file open dialog). I doubt that much more is necessary in this case.
Re: Usability goodness
So no tree? I liked this tree because I immediately saw where all the stuff was going and thus where to edit config files for example.
When you come from windows you are naturaly more suspicious about 'where stuff goes'...
Re: Usability goodness
We've eventually decided to drop this feature - even though there were some heated discussions regarding this issue. Such information will be easily available for lookup using the PackageInspector application, so there's nothing to worry about.
Re: Usability goodness
How will the installer handle existing installation of a pakage?
say that sdl 1.2.1 are installed and now I will install 1.2.8 how will the pakage find that installation pakage?
Re: Usability goodness
PackageInspector... hmm I think it's nice to have but why the hassle if you could see it right away, couldn't you have a view named "details" which would be closed by default and it would open a tree when clicked upon?
You can't choose where individual files will go? Does the binary know where to find it's config files or must they be relative to the base dir?
Is there a log of the pro's and con's you discussed?
Re: Usability goodness
Usually I expect things in a package will either be put in a fixed location relative to your chosen install directory, or in a system-wide constant folder such as /home/config/setting/ - so you wouldn't be able to choose where individual files go (apps usually make assumptions about their support files relative to the executable).
I agree with you nutela, that it would be nice to be able to see the details of what was being put where in a details tree view (hidden by default). I like to know if things are being put into my system directories and don't want to have to run a different app to find that before I run the app to install it.
Re: Usability goodness
I agree with you nutela, that it would be nice to be able to see the details of what was being put where in a details tree view (hidden by default). I like to know if things are being put into my system directories and don't want to have to run a different app to find that before I run the app to install it.
Would the fact that it installs something into the system folder change anything for you? Would you not install the app, then? Would you move the files to a different location and thus break the uninstall function? Apart from being a "nice-to-know" thing for a few curious experts (who wouldn't even need it very often, either), what justifies this feature to exist in the installer itself? The PackageInspector can do that for those who have to look at the details (similar to GUI vs command-line).
BTW, the installer should notify the user that files will get overwritten before any files have been copied, so he can abort the operation cleanly.
Re: Usability goodness
Would the fact that it installs something into the system folder change anything for you? Would you not install the app, then? Would you move the files to a different location and thus break the uninstall function? Apart from being a "nice-to-know" thing for a few curious experts (who wouldn't even need it very often, either), what justifies this feature to exist in the installer itself? The PackageInspector can do that for those who have to look at the details (similar to GUI vs command-line).
BTW, the installer should notify the user that files will get overwritten before any files have been copied, so he can abort the operation cleanly.
Good point. Providing overwriting warnings are included I suppose I'm OK with it. Although it would still be nice to know if things are going into the system add-ons directory, as they could render the system unbootable, I think mainly it is just as a curiosity. I would like to avoid falling into the trap of providing buttons to satisfy every curiosity of every geek so I'll go along with you on this one.
A possible compromise solution would come through the design of this PackageInspector everyone keeps mentioning. If that can be associated with individual packages then it could be used as a "launcher". So I could associate .pkgs with PackageInspector on my system, then double-clicking would bring up the tree view of details and below it some text "This Package is not currently installed:" with an "Install Now" button that fires up the simple installer app. Even that use path is only 2 clicks to install, which beats the silly "wizard" approach of windows installers.
Re: Usability goodness
I always loved the information. It's what made the difference to Linux. Sometimes you want to save settings or change things. In those cases it's nice to know what files might be in charge. Sure it's not for the usual "Desktop user" whoever that is. But I don't think a Details Button will confuse beginners. They know they don't want to know details. Other users (like me) like to have a peek on what happens.
The other thing is the uninstall thing. I haven't met an installer/uninstaller without issues yet. Even apt messed once on me. It was special that you could (beside a logfile) just open a program package with the default application and check what files you had to delete.
I think it's fine to leave it out on the first release and concentrate on the system underneath. But it would make me sad not having that feature in HAIKU. Mac user often point on the "little things", I think lots of them got lost on the Mac. For me this is one of these "little things" from BeOS.
Would you move the files to a different location and thus break the uninstall function?
Yes that might happen, depends on how the default structure is done or maybe I want to have a program installed twice.
Another question is what happens with backup files one makes from settings or other things changed (something like rename config.file to config.fileold and copy a new one into the folder). Will the uninstaller be able to delete them? Would be cool, but you never know what those files are, because they don't belong to the files known to be from program. Sometimes there is no other way than manual uninstall. That is where I like to have another view on the install tree.
Re: Usability goodness
PackageInspector... hmm I think it's nice to have but why the hassle if you could see it right away, couldn't you have a view named "details" which would be closed by default and it would open a tree when clicked upon?
My original design had such a feature, but after considering the fact that it's not crucial information for a normal desktop user (who, in fact, just wants to get the job done), it would only cause unnecessary confusion. Also, since there will be a simple package uninstaller this time, the user doesn't really need to know where the files are placed to preform manual uninstallation.
But I think that after the PackageInspector is done and if lack of this feature would really be a bother, we will consider adding it once again.
Just a detail, but I'm wondering what happens if the 'install to' path is very long? Will Haiku in that case automatically show only the last x number of characters preceded by ".../" ?
(If not, there's a risk of getting layout problems)
The application is written with high font sensitivity in mind, so there's nothing to worry about. Although showing only the last x number of characters might not be the wisest choice, since information about on which volume the installation will take place is important.
To be honest, I will yet have to look into this to find the best solution. For now, I think even simple resizing of the field (when collapsed) seems to be good enough. Then, the only problem would be it not fitting on the screen when the menu is browsed, which is most unlikely to happen.
How will the installer handle existing installation of a pakage?
If the very same package being installed is already installed on the system, the user will be informed of this fact, deciding whether to continue the installation or not. However, if this is not the same package, but - as in your example - simply a newer version, it will treat it as a any other, different package and only prompt messages when a file would be overwritten.
Thus, this issue stays the same as on the BeOS.
Re: Usability goodness
Just a detail, but I'm wondering what happens if the 'install to' path is very long? Will Haiku in that case automatically show only the last x number of characters preceded by ".../" ?
(If not, there's a risk of getting layout problems)
Re: Usability goodness
Hey Lukasz (sorry I don't know how to write that fancy L thing),
nice you made it into GSoC and decided to work on a part of Hailku :-)
First I had to think about your BMenuField vs Groups list, I think it's hard to say what's better. I get your point and after thinking a bit I think both approaches are good. I like that your approach still gives all the needed information about disk space right away on the first sight.
Install vs Begin is a lot better, same with the tiltle saying Install Packagename.
I'm one of the guys who likes changeing directorys and know where files go, so naturally I don't like having no option to decide or at least have an information where things are put. But I do think it's better to leave that feature out on a first release. That's just candy and you're right on doing the system underneath first.
Good luck, have fun and thanks for your time :-)
Kossi
Re: Usability goodness
Maybe you recall that BeOS has this system folder so Be could update it with newer apps and ~/config/settings is for stuff you didn't want to get accidentally overwritten by Be Inc.
Re: Usability goodness
Maybe you recall that BeOS has this system folder so Be could update it with newer apps and ~/config/settings is for stuff you didn't want to get accidentally overwritten by Be Inc.
You're right, I somehow forgot that...
but on the other hand that didn't work since software didn't only come from Be Inc. If the user isn't supposed to do anything into the apps folder there is lots of jucky linking (for Haiku Menu) and the apps folder should only be assessable for the installer. But in that case every developer has to use the installer. No more shell scripts and no more manual updates for programs. I still see lots of install scripts or things you install by extracting and copying into a folder (that doesn't have to be a bad thing).
If the structure in apps is fixed and no one is allowed to change something, linking is needed. One still needs to find the program but a search might do the trick.
I still like the idea better to let a user decide rather he wants default paths or not and make the Tracker Menu a mirror of the file structure that only shows defined files (queries should do the trick, but I didn't find a way to do a query on a special folder and its subfolders yet). That way we get ride of dead links (-> how does the uninstaller find a program link when I moved it).
Anyway you guys are working on it so you have to decide and I'm not saying you have to do it my way, I'm only writing my thoughts.
(sorry this answer is so late)
Re: Usability goodness
In regards to uninstalling and what to do if files are moved, I would suggest that any files installed be "tagged" with special BFS attributes that indicate what package and version they are from. Then even if those files are moved they can still be removed on uninstall, or upgraded when a package is upgraded. Though in some cases we may want to prompt the user about those moved files as they may have moved them on purpose (to back them up for example.)
In regards to the original post, I like the simplicity of the installer, and I think it is a good compromise to provide another PackageInspector tool for people who want to get more detail about a package. Though it would be nice to have good integration between these tools, for example an "Install" button on the Inspector, and a small "Inspect" icon on the installer, maybe in one of the corners (top right, beside the description for example.) That way it is easy to move between the inspecting and installing functions.
Re: Usability goodness
In regards to the original post, I like the simplicity of the installer, and I think it is a good compromise to provide another PackageInspector tool for people who want to get more detail about a package. Though it would be nice to have good integration between these tools, for example an "Install" button on the Inspector, and a small "Inspect" icon on the installer, maybe in one of the corners (top right, beside the description for example.) That way it is easy to move between the inspecting and installing functions.
We already discussed that the inspector will probably get an install button, but the installer itself probably won't have any references to the inspector because it should not encourage to look at the details and it's a rarely *needed* function. Though, a small icon could be a good compromise in case we decide to add a reference.
Re: Usability goodness
We already discussed that the inspector will probably get an install button, but the installer itself probably won't have any references to the inspector because it should not encourage to look at the details and it's a rarely *needed* function. Though, a small icon could be a good compromise in case we decide to add a reference.
For reference, could you point us to where this discussion took place?
Re: Usability goodness
For reference, could you point us to where this discussion took place?
On the usability team's mailing list.
Re: Usability goodness
For reference, could you point us to where this discussion took place?
On the usability team's mailing list.
Great stuff Waldemar! Thanks!
One question: why is the mailing list closed-subscription? It's a bit odd, since Haiku is an open source project... ;)
Re: Usability goodness
I've fixed the usability mailing list configuration.
Re: Usability goodness
I've fixed the usability mailing list configuration.
Thanks Waldemar!
I have also added the list to the mailing lists page, as it was missing for some reason. ;)
PS: it would be nice if the mailing list description could be updated to something a bit more descriptive. Who is the admin of this list?
Re: Usability goodness
Today I installed the Gobe Productive 2.01 update boy was I surprised that it also installed new Data Translators! Therefore I think it's really stupid to not have a hidden view of the part of the FS tree were files are being installed. Or at least a list of files installed.
Re: Usability goodness
Today I installed the Gobe Productive 2.01 update boy was I surprised that it also installed new Data Translators! Therefore I think it's really stupid to not have a hidden view of the part of the FS tree were files are being installed. Or at least a list of files installed.
There will be a very simple solution to your problem: Go to FileTypes and change the default handler for .pkg files to PackageInspector. That way, you will always be able to first inspect the package and then click "Install" in the PackageInspector to actually install the package. At the same time, the rest of us won't be bothered with any package details.
Re: Usability goodness
There will be a very simple solution to your problem: Go to FileTypes and change the default handler for .pkg files to PackageInspector. That way, you will always be able to first inspect the package and then click "Install" in the PackageInspector to actually install the package. At the same time, the rest of us won't be bothered with any package details.
That sounds good.
Re: Usability goodness
In regards to uninstalling and what to do if files are moved, I would suggest that any files installed be "tagged" with special BFS attributes that indicate what package and version they are from. Then even if those files are moved they can still be removed on uninstall, or upgraded when a package is upgraded. Though in some cases we may want to prompt the user about those moved files as they may have moved them on purpose (to back them up for example.)
I love it when people come up with creative ideas on how to take advantage of attributes, and this is one great example. :)
Dumb question, but would it not be possible to deal with multiple versions of libraries required by different apps by placing them under /apps/app_folder/lib/? The installer can always poll the system, and if a different version of any given library that the program being installed already exists, instead of overwriting it, the new version could be installed under the app folder. The app being installed would use its version of the lib, and all others the version available system-wide under /beos/system/lib/.
Re: Usability goodness
If it works very elegant solution, but I don't know if it works :-)
Re: Usability goodness
If it works very elegant solution, but I don't know if it works :-)
We haven't discussed the details of the PackageInspector, yet, but we'll try to make it work nicely for power-users. We're open for suggestions. :)