page@swan.ulowell.edu (Bob Page) (03/25/88)
Good to see such interest! However ... it's not what I had in mind. The "USENET Seal of Approval" only certifies that the program is well-behaved, and doesn't attempt to test all the functions looking for bugs, or determining ease of use. In effect, it's not a 'review' at all. I suppose the two could be combined into one, but what I wanted was a checklist of things that programmers fall into when they program the Amiga. If Everything was done OK, they get the approval. If even one thing fails, they don't get the OK. Stuff like an index in the manual isn't so important at this level. joe@lakesys.UUCP (Joe Pantuso) wrote: >I really want this to happen. I believe it has a tremendous potential as a >source of information and a way for companies to advertise cheaply. In this >manner very small companies, or shareware authors, could get reviews in. >Instant publicity. > I believe that it would have to be officially recognized by Commodore, >and they would hopefully inform magazines and companies. This would make NR >more legitimate. Again, these are Good Things, but not what I was talking about, as the 'Amiga System Nice' checklist doesn't have to be officially recognized by Commodore, and the only benefit a company would get is "yes, it passes" or "no, it fails these tests." >There would be guidlines. There would be ratings systems. It would >be comprehensive and your ultimate source of information for almost >ANY purchase. Again, nice stuff, but different. So just what am I talking about, you ask? Here are some quick thoughts, off the top of my head: Does it call Delay(0)? Does it call WaitForChar(0)? Does it take over the machine? Does it fail when used with Fast RAM? Does it fail when used with $C00000 memory? Does it work with KS 1.1? Does it OpenLibrary(name, 0L) when it really wants version 33 (or so) ? If it has menus, does it provide keyboard shortcuts? (for >50% of the items?) Does it fail on disk full? Does it fail on disk read/write error? Does it fail on memory full? Does it fail on RAM disk full? Does it fail when memory is too fragmented? Does it lose memory on each run? Does it ignore return codes from AllocMem? Does it ignore return codes from OpenLibrary? OpenDevice? Does it allow the user to abort/stop the program with ^C or ^D? Does it fail when it can't find a particular file? Does it Forbid() or Disable() for long periods of time? Does it use Intuition-standard items (Menu placement, Amiga keys, etc) and a whole lot more. You get the idea? Programmer traps. It's possible to detect these things, even in a compiled program. I've already started getting some ideas in the email. Keep 'em coming! ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "Nicaragua" is Spanish for "Vietnam."
ain@s.cc.purdue.edu (Patrick White) (03/25/88)
In article <5677@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >... and the only benefit a company would get is "yes, it >passes" or "no, it fails these tests." This isn't much of an incentive for companies to go through the trouble of getting a U.S.A... I prefer the review idea for this reason. > Does it call Delay(0)? > Does it call WaitForChar(0)? ... Going to need source to make these kind of evaluations -- I doubt you could ever get a company to send source for it's product to a third party, and letting the companies give themselves the seal makes the seal totally worthless. -- Pat White ARPA/UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906
page@swan.ulowell.edu (Bob Page) (03/26/88)
ain@s.cc.purdue.edu.UUCP (Patrick White) wrote: >> Does it call WaitForChar(0)? > Going to need source to make these kind of evaluations Further down in the same article I pointed out that it is NOT necessary to have source. ..Bob -- Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page "Nicaragua" is Spanish for "Vietnam."
suh@cunixc.columbia.edu (Kenneth Suh) (03/26/88)
In article <5677@swan.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >However ... it's not what I had in mind. The "USENET Seal of Approval" >only certifies that the program is well-behaved, and doesn't attempt >to test all the functions looking for bugs, or determining ease of use. >In effect, it's not a 'review' at all. > >I suppose the two could be combined into one, but what I wanted was >a checklist of things that programmers fall into when they program the >Amiga. If Everything was done OK, they get the approval. If even one >thing fails, they don't get the OK. >So just what am I talking about, you ask? Here are some quick thoughts, >off the top of my head: > > Does it call Delay(0)? > Does it call WaitForChar(0)? > Does it take over the machine? many more examples like this follow... > >..Bob >-- >Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page > "Nicaragua" is Spanish for "Vietnam." I can see Bob's point of view. I guess there are still many more things that can be added. For example: Is the interface card Zorro II compatible? Does the peripheral pass the bus? Does the peripheral have its own power source? etc. I am sure that many users (I am not going to open a can of worms by saying "most average users".) would be mislead by the "Usenet Seal of Approval" in the sense that Bob puts it. Many people, including myself, would probably avoid a program that passed Bob's checklist but did not have a nice user interface.(Please don't address the problem of what a nice user interface is and is not.) Subjective things are still important. Maybe it would be possible for the "Usenet Seal of Approval" to consist of two parts: 1) Design of the program - Bob's suggestion 2) Miscellaneous For software: well documented good user interface "fast" etc. For hardware: well documented ease of installation etc. Let's come up with some criteria! If a product fails, then let's say why. I don't want to rush things too quickly. I must admit that I didn't think of judging a program at that level, but I am sure that this would get companies to check on these things themselves, especially when porting software over from non-multitasking environments. /ken Kenneth Suh PATH: suh@CUNIXC.COLUMBIA.EDU 312 McBain Hall, C/O Carman Hall SY.SUH@CU20B.BITNET Columbia University ..!rutgers!columbia!cunixc!suh New York, NY 10027