keithd@cadovax.UUCP (02/06/87)
References:
Is there ANY way we might convince the
software program reviewers for magazines like AmigaWorld and Amazing Computing
to rate all packages against a reasonable 'checklist' of clean vs dirty
features? If we could, we might heighten the awareness of some of these
features and some of the application-writers responsibilities to produce
a package that behaves well in the AmigaDos environment. Here are some of
the things I'd like to see on the list:
1) What does PM (the performance monitor) say about it. Does it hog the
pc even if it's doing nothing or does it do a nice clean 'Wait' allowing
other tasks to make better use of the machine at the same time.
2) Does it provide user access to the wonderful print options that are
available such as different aspect ratio and size printouts or does
it just hard coded to do one kind of print.
3) Does it allow you to cancel the print job cleanly and quickly?
4) Does it deallocate the memory it uses correctly in all exit cases
(even under error conditions)?
5)...
I'm sure there are more, but you get the idea. Those above are my
hot buttons.
If AmigaWorld and Amazing Computing printed 'checklists' like these
as part of their review columns on the packages they check out, you
can BET that most of the developers make sure they look good when
judged by the list. It will become the developers 'checklist' on
what-to-make-sure-the-package-can-do-well before shipping, and maybe
the printer and multi-tasking woes will diminish more quickly.
Anybody have any good connections at the magazines?
Keith Doyle
# {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
# cadovax!keithd@ucla-locus.arpaacs@amdahl.UUCP (02/07/87)
In article <1385@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >Is there ANY way we might convince the >software program reviewers for magazines like AmigaWorld and Amazing Computing >to rate all packages against a reasonable 'checklist' of clean vs dirty >features? ... <he goes on to describe some possible items> Say Hall-aayyyyy-loooo-ya! What a grrrreat idea! >5)... 5) Are the user interfaces presented in an "Amiga-like" fashion or, short of that, is at least reasonably "intuitive" to an Amiga user? >Keith Doyle ># {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd ># cadovax!keithd@ucla-locus.arpa -- Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs [ Opinions expressed herein are the author's and should not be construed to reflect the views of Amdahl Corp. ]
mark@unisec.UUCP (02/08/87)
If you're looking for a show of hands,
^^^^/>
\ /
| | <= there's mine (somewhat deformed, eh?)
| |
A certain amount of subjectivity is to be expected in a review, otherwise
it would be terribly boring for the reviewer. However, we really do need
some metrics to judge new products by. I have one particular product that
I'm thinking of that I bought based on a couple of 'rave' reviews, yet it
doesn't do what I expected. However, I won't bad-mouth the product because
I now realize that I was led to expect something else by overly zealous
(and quite likely inexperienced) reviewers. Though the product in mind
is probably outstanding for its intended market, it doesn't meet my
expectations at all.
Markmichael@stb.UUCP (02/11/87)
You forgot the most important one: Ease of use protected or not ease of use protected. -- Michael Gersten ihnp4!ucla-cs!cepu!ucla-an!remsit!stb!michael "Hey, you look a lot better since you got her back" "Yea, and now I'm going to take her out and shoot her"
mjp@spice.cs.cmu.edu (Michael Portuesi) (07/08/87)
Keywords: derek@speedy.WISC.EDU (Derek Zahn) writes: > > I think it would be a great idea to make a list of available Amiga software, > giving a list of important attributes: I would like to propose the following > list for consideration: > > * Program Name > * Company > * Copy Protection Scheme > * Replacement Policy > * List Price > * Operating System Version(s) under which it will run > * Works on 512K Amiga > * Works With Expansion Ram > * Runs if copied to Ram > * Runs if copied to Hard Disk How about: * Multitasks properly (i.e. does not busy-wait the machine, does not allocate all free memory available for itself unless needed) * Uses standard Intuition functions for user interface * Does it have bugs that guru the machine under normal use? * How well does it handle low-memory conditions? Does it notify the user, not notify the user, crash the machine? * Does it give back the resources it allocates when finished? * How well does it handle errors? My famous example of bogosity in this area is the PD terminal program Comm. On my one-drive system it prompts me to insert the Workbench disk to load the serial.device. If I click "cancel" on the requestor instead, Comm gurus the machine. I could go on about how bad Comm is, but that's a different post... There are certainly others...these are just off the top of my head. -- Mike Portuesi / Carnegie-Mellon University Computer Science Department ARPA: mjp@spice.cs.cmu.edu UUCP: {backbone-site}!spice.cs.cmu.edu!mjp BITNET: rainwalker@drycas (a uVax-1 run by CMU Computer Club...tons o' fun) "Paradise is exactly like where you are right now...only much, much better" --Laurie Anderson, "Lanugage is a Virus"