[999] in IS Home Pages
Re: Updates to IS Support Sheets
daemon@ATHENA.MIT.EDU (Kevin M. Cunningham)
Thu Feb 24 12:48:36 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Message-Id: <v04020a00b4db0057ed15@[18.152.1.50]>
In-Reply-To: <v04020a0ab4daf5fc65af@[18.152.0.126]>
Date: Thu, 24 Feb 2000 12:48:13 -0500
To: Kris Nyzio <knyzio@mit.edu>
From: "Kevin M. Cunningham" <kcunning@MIT.EDU>
Cc: Theresa M Regan <tregan@mit.edu>, Robyn Fizz <fizz@mit.edu>,
is-home@mit.edu, sw-release-team@mit.edu, fortoul@mit.edu,
rclarke@mit.edu, sharari@mit.edu
At 9:59 AM -0500 2/24/2000, Kris Nyzio wrote:
>MinK: Download now points to:
>https://nic.mit.edu/swdist/mit/win/Mink-10-18-99.exe
>Oracle: Supported/Recommended versions for Mac/Win is 7.3.2
>Download site for Oracle Mac is now:
>http://web.mit.edu/is/help/oracle/oramac.html
>Download site for Oracle Win is now:
>http://web.mit.edu/is/help/oracle/orawin.html
Howdy all,
I really like the fact that the Oracle links above point the user to installation instructions, not directly to the downloadable file. The MinK link, on the other hand, troubles me, and reminds me that we may not all be proceeding with the same principle in mind regarding the "download site" URL on the Product Support pages. So, just to make it explicit, let me say what principle I hope we are trying to follow here:
**Wherever possible, the "download site" URL for a product should point to an html page with download/install instructions rather than directly to the downloadable item itself.**
(A MinK installation page, by the way, is at http://web.mit.edu/is/help/mink/#download.)
This principle was espoused some time ago by the Self Help team, and was implicit in the development of the Product Support Sheet database. We have long known that it hurts both users and support providers to let users download installers/program files without first making sure that they see relevant download/installation instructions. Such installation instructions are specifically written in order to make users' lives easier, and to head off potential questions to overloaded support providers such as the Help Desk (by answering predictable questions up front), so it really doesn't make sense to bypass them.
Putting it into specifics, I think the procedure should be:
1) Where an "installation instruction" web page exists, we should point users to that.
2) Where no web page exists but a READ ME file exists (e.g., on net-dist, in some cases), we could point to the download directory to give the user an opportunity to read the README.
3) Where no download/installation page or directory exists, we ought to make sure such a page gets written (by pubs or by someone else), and point to that.
In no case should the link just start downloading something. (In fact, the current name "download site" and the little diskette icon on the Product Support pages might be misleading and may need to be reconsidered.)
The way that http://web.mit.edu/software/ currently works is NOT the model we should follow (I don't even think it's a model "THEY" should follow, but that's a different discussion...)
We might already be doing the first two steps above; I doubt we have a process in place to do the third. Of course, in the short term, in the absence of alternatives, we may *have* to link to the downloadable item, but we ought to establish a process whereby we develop installation instructions or README pages for any installer/software we eventually have users download.
As far as new installation instruction pages are concerned, they could be put in the appropriate place in /is/help for each product -- if the needed subdirectory didn't exist, we could create it. (We may want to create subdirectories for all the software we can think of now anyway. This has been my plan for some time.) And a convention might be to name the installation pages .../is/help/productname/install.html.
It may be that this is the procedure we are currently following in populating the "download site" URLs. If not, I hope we can make it our procedure to hunt down installation instructions where they exist, create new pages where they don't, and build on the /is/help/ directory structure.
This will help cultivate a systematic approach at helping users obtain software efficiently.
--Kevin
P.S., If it seems overkill to make sure there are installation instruction gateways for each product, note that the initial recommendation by the Self Help group was that any relevant LICENSING agreement information should also be presented before any download (there are even cases where this is a legal requirement). Although I put hooks for this in the database, we've let that fall by the wayside, in the hope that licensing information will be included in the installer itself. This may or may not end up being a reasonable hope -- it depends on what requirements the Software Release Team is placing on folks who write installers.
