From: Henrik N. O. <h....@bt...> - 2002-06-16 16:32:01
|
Jon, OK, well done; the ball is rolling :) I've looked at your installer, and have some thoughts. I still think that a self-contained HTML-Based installer would be very slick, but it seems that we may have problems in getting this ready for our first release (the beta is due out in a month!) However, I think that if we keep the documentation in HTML, we can easily migrate to such an installer later. Now, how can we proceed with the current version? If we place two large, friendly buttons (with pictures) at the bottom saying, 'Read about this program.' and 'Install this program on your hard disk', then the 'install' button can launch the installer and the 'read' button can launch the default web browser or notepad. The page that comes up upon pressing 'read', then contains program info, screenshots, install help, links, un-installhelp, etc. Once the user is in the browser, there should then be menu navigation, so that she can easily read about any other program, or about OSS. The way you have it now, you show the entire contents of the directory, which is more info than the user needs to know. I would propose instead that each app directory contain the following files: app_name.txt app_blurb.txt app_icon.ico app_info.html app_info.txt install_howto.html uninstall_howto.html install.exe (plus cab/zip, whatever files) The reason for having the exact same files in each directory is that it makes it easy to add or move program, without having to update some central database. (so the above would be the contents of Applications\AbiWord, for example.) the 'Applications' directory would contain a human/machine readable file called 'contents.txt., which would contain a listing of the apps in this directory: Contents of the Applications directory: --------------------------------------- 1. AbiWord - A simple word processor 2. OpenOffice - A complete Office suite 3. whatever. - etc. Most people would never view this file directly, except vthose who choose to browse the CD 'manually'. Upon entering the Applications directory, your install program would read this file, and using some basic string manipulation would know what it contains. The sub-directories would have the same name as appears on the list, ie. 'AbiWord' The program would then go into each directory and read out the relevant information. It would present a list of programs by name, and when you click on one of them you can see the icon and the blurb in a small frame. So when, you click on a directory you will be presented with a simple list of programs, and clicking on one of these would show an icon, (a small screen shot?) , and a short description. I think with this approach, we can stick to the original plan of doing all the documentation in HTML (which allows non-programmers to participate), but also puts us on much firmer ground with regards actually having a working installer in place by the first beta. Some misc. usability comments: 1. I don't think the user should be able to 'double click' to launch the installer. Many people don't differentiate between single a double, and just double click everything, which would launch the installer when they just intended to browse, which could be scary. (not kidding) 2. If the program doesn't have its own installer but just a zip file, then I think we should give it one. We cannot assume that the user has an unzipper. So, on the whole, I think it's a good step forward, and a branch we can build on. btw: Where is the source? I presume it's GPLed :-) Does anyone have familiarity with setting up a SourceForge CVS repository? - Henrik -- Henrik Nilsen Omma Theoretical Physics, Oxford 35 Frenchay Road 1 Keble Road Oxford OX2 6TG Oxford OX1 3NP h....@bt... he...@th... |