done@pro-sol.cts.com (Don Elton) (12/14/89)
Everyone knows that there aren't very many productivity programs availablef or
the Apple IIgs in native mode. Two of the big deficiencies I've no{ed are
lack of a stand-alone spreadsheet and lack of a powerful (i.e. dbase-like)
data base. I'm interested in finding out what users think is the most glaring
deficiency or perhaps which of the above would be the one they'd most likely
HAVE to add to their collection if one were offered on the market. If I've
left out some other category then mention that too but I'm mainly interested
in hearing what people would think about the above two.
On a related note, for each of the above two applications, what features do
you think are needed that can't be had elsewhere (i.e. AppleWorks GS for
example)?rnf@shumv1.uucp (Rick Fincher) (12/15/89)
In article <0.apple.net@pro-sol> done@pro-sol.cts.com (Don Elton) writes: >On a related note, for each of the above two applications, what features do >you think are needed that can't be had elsewhere (i.e. AppleWorks GS for >example)? I think the spreadsheet would need Macro capability and much better business and scientific graphics. Pen plotter output for the graphics would be great. The ability to link spreadsheets or make them 3-D would add a lot to its power. For the database relational capability (obviously) and the ability to calculate running totals of a field for the whole database as well as up to that record but not including values in subsequent records. Also the ability to of a number field to be based on the value in the last record. This would allow the program to generate invoice numbers, for example (Invoice# = Last Invoice# + 1). This would also be useful for numbering account transactions. I don't really have a feel for which is more needed, a database or spreadsheet. Whenever I work with either I wish it had some capabilities of the other. A hybrid program that would combine the calculating, summing, and number formatting capabilities of a spreadsheet with the searching, sorting, record oriented format of a database would be great. Maybe this could be something like the tabular form of the database in AWGS, but you could do spreadsheet calculations on the data in that format, while in the data format you could search and sort. Rick Fincher rnf@shumv1.ncsu.edu
bsherman@mthvax.cs.miami.edu (Bob Sherman) (12/15/89)
I think a look at DB Master Professional from Stone Edge will show you that
there is a VERY POWERFUL database available for the Apple II..
It seems to have \everything you have requested..
--
bsherman@mthvax.cs.miami.edu | bsherman@pro-exchange | MCI MAIL: BSHERMAN
>> Miami's Big Apple - 305-948-8000 - 24 hours - 300/1200 - PCP'able <<
>> Oldest Apple support board in Southeast. Now in it's ninth year. <<TE880714%STUDTEW.UFSIA.AC.BE@CUNYVM.CUNY.EDU (stef bracke) (12/16/89)
Dag,
A good Database program must be international:
- Allowing the use of the comma (,) instead of the point,
when typing numbers.
eg: We write 12,5 for "twelve comma a halve" (=12.5)
We write 1.200 or 1200 for "thousand two hundred"
- Allowing the use of different (definable) currencies.
eg: The Belgian Frank doesn't go beyond the point (comma).
So we haven't got any "halve a BF'" anymore.
What about an option in the program which let you convert
certain data. (Like currencies, weights, lengths...)
- Easy access to accents.
eg: Dutch, French and German are the national languages of Belgium.
The Dutch word for Belgium is BELGIE but you have to put a
trema on top of the E otherwise it would sound like BELGY
In general:
- Layout options like coverpage, ...
- VIEW-PAGE option.
- ...
a small contribution, Stefdone@pro-sol.cts.com (Don Elton) (12/16/89)
In-Reply-To: message from bsherman@mthvax.cs.miami.edu I use DB Master Pro for my customer database and agree that it's the most powerful db available for the Apple II but it can't really begin to compare to say the old CP/M dbase II or the current dbase III products with their programmability. I just wonder if dbm has a decent sales volume and whether there are enough Apple II users who would be interested in something more powerful, perhaps with the ability to run dbase programs written for other computers (there's a whole third market in dbase programs out there).
rnf@shumv1.uucp (Rick Fincher) (12/16/89)
In article <1276@umigw.MIAMI.EDU> bsherman@mthvax.cs.miami.edu (Bob Sherman) writes: > >I think a look at DB Master Professional from Stone Edge will show you that >there is a VERY POWERFUL database available for the Apple II.. > >It seems to have \everything you have requested.. > I wasn't requesting anything, merely responding to the original poster's request for features, particularly in comparison to AWGS. DB Master is a superb program. It amazes me that Barney Stone could cram all of those features into the limited memory he had. On the other hand, the fact that DB Master could be done on the IIe suggests that truly awesome things could be done on the IIgs and the easy interface with DA's etc. The 16 bit registers and greater speed and memory could be used for some really great search and sort algorithms. Maybe Don should contact Barney Stone and collaborate on a IIgs version of DB Master, if StoneWare isn't already doing one. Rick Fincher rnf@shumv1.ncsu.edu
rich@pro-exchange.cts.com (Rich Sims) (12/16/89)
In-Reply-To: message from done@pro-sol.cts.com (Don Elton)
I have no feel for what "most" users would think was more important, but for
myself, I'd go for the right database. "Right" meaning that it has some
features I would find useful. Some of the things I'd like are as follows:
(Gee, I never got to "design" a data-base before!)
1. Ability to merge data from other sources in a variety of formats, such as
fields delimited by tabs, returns, commas, etc.
2. A moderate "macro" ability during data entry, with the capability of either
using a 'standard' value or duplicating the previous entry, as desired.
3. Some way of linking long text entries to specific fields, either by direct
inclusion in the data file or as a separate file that's read when that field
is displayed -- sort of "semi-relational" I guess. By "long" text entries, I
mean I'd like to be able to include a text document that's a few k long.
4. I wouldn't find it particularly useful, but since this is a GS
application, I suppose some way of storing graphics would be mandatory for
most GS users.
5. Ability to define specific fields to hold particular data types and
disallow invalid entries. This should include an optional maximum entry
length.
6. A field (or two) that are *automatically* updated with the current date
and time whenever any data in that particular record is changed or the record
is created (or data added). This could be an optional field, not one that's
always created, although either way would be acceptable.
7. Mouse usage should be optional, not required!
8. Ability to create data entry "templates" that are accessible quickly and
easily by someone who's not necessarily familiar with all the "bells and
whistles" that the database provides. This is to allow creation of the file
format and data fields, and then to allow anyone to easily enter the data from
a prompted or menu-type environment.
9. It should recognize text and numeric data, and provide for treating either
type as the other.
10. Once the data is in the records, I'd like to be able to manipulate it
almost without limitation, with the options of modifying the data and either
replacing the existing data with the result or creating a new field to hold
the result.
This kind of thing should be programmable as a script or
series of macros that can be called up at any point, so
the sequence can be defined once and used over and over.
Right along with the above, search/manipulation capability
should include "pattern" or "expression" matching, rather
than just being able to match literal data chunks.
11. How about two variants? One to be RAM based for small data files and one
to be disk based for larger amounts of data. If only one were available, I'd
choose disk-based. After all, we can already keep small stuff in AppleWorks.
12. At the risk of drawing a lot of heat, how about designing the thing for
performance, not designing it to be useable on a one-floppy system. (If it
still is useable that way, fine -- if not, well, that's life!)
13. Report generation capabilities - along with all the normal stuff, it
should be capable of tabulating sub-groups of data as well as the entire
group, and preferably without any physical re-organization of the data file.
Let it do something simlar to this....
Sort the output by last name, then first name, group it by
ZIP code, and give me a count of the number of entries
using each different phone number prefix. (Not that I'd
use that particular one, but similar stuff would be very
useful to me.)
Oh yeah -- multiple data screens available, so they can be organized into
logical groups without cluttering up the display by trying to see everything
at once.
I can think of a dozen other features I'd like, but this is already too long,
so I'll give it up for now.mmunz@pro-beagle.cts.COM (Mark Munz) (12/17/89)
In-Reply-To: message from done@pro-sol.cts.com >Everyone knows that there aren't very many productivity programs >available for the Apple IIgs in native mode. Two of the big >deficiencies I've no{ed are lack of a stand-alone spreadsheet and lack >of a powerful (i.e. dbase-like) data base. I'm interested in finding >out what users think is the most glaring deficiency or perhaps which >of the above would be the one they'd most likely HAVE to add to their >collection if one were offered on the market. I think a dbase-like database program would be the most useful. Believe it or not, I think the "." prompt is the one of the better features (along with what it represents -- programmability). The problem I see is that folks think they want a "graphics-based" database but then they expect all the speed that you'd get from a text-based. The closer to dbase it is, the better -- for the simple reason that there are tons of books on dBase III (or IV) on the market which users could then take advantage of. Mark Munz
mmunz@pro-beagle.cts.COM (Mark Munz) (12/17/89)
In-Reply-To: message from bsherman@mthvax.cs.miami.edu >I think a look at DB Master Professional from Stone Edge will show you that >there is a VERY POWERFUL database available for the Apple II.. > >It seems to have \everything you have requested.. Well, I've seen DB Master Pro as well.. and well, how can I put it-- the interface sucks!! I did some dBase III programming a couple years ago and DB Master Pro doesn't add the needed versatility of a full-blown language. What we need is a database programming language, not some "user friendly" relational front end. The interface should be handled by the program that is written under the language. btw.. Stone Edge now has a Basic programmers tool that lets you edit existing database files with a BASIC program. Of course, that seems to be just an afterthought to DB Master Pro -- that along with the fact that it's $125 and requires DB Master Pro ($295?) in order to create database files. Of course, on an IBM -- $300+ isn't that much money, but on an Apple II, it's quite a bit!! It would probably have to be priced at under $250. (ooops, that should be $400+ -- my calculator broke) Mark Munz
mmunz@pro-beagle.cts.COM (Mark Munz) (12/17/89)
In-Reply-To: message from rnf@shumv1.uucp >On the other hand, the fact that DB Master could be done on the IIe >suggests that truly awesome things could be done on the IIgs and the >easy interface with DA's etc. The 16 bit registers and greater speed and >memory could be used for some really great search and sort algorithms. Adding an "easy interface" would kill the program from day one! Plus, you lose a nice hunk of speed that you'd gain from using the 816 the way it should be used!! Doesn't anybody use Text based programs anymore?? I mean, graphics are nice, but come on, it slows down most of my work (and I've got a TWGS, and Hard Drive). Mark Munz
SASQUATCH@ALBION.BITNET ("Kevin Lepard, 629-1827", 517) (12/19/89)
[stuff deleted] >Doesn't anybody use Text based programs anymore?? I mean, graphics are >nice, but come on, it slows down most of my work (and I've got a TWGS, >and Hard Drive). If any developers out there are listening (including folks at BB :) I by _far_ prefer text based programs. In fact, the only graphics based programs that get used on my GS are games and graphics programs. Other than that, the graphic stuff is just too slow for my taste. Sure, graphics are great for somethings, but unless that database lets me store graphics images, or that spreadsheet puts graphs and charts on the screen at the same time as my cells, I'd by far prefer to see the program switch between text and graphic screens as necessary. For what it's worth... >Mark Munz Kevin Lepard Bitnet: Sasquatch@albion.bitnet
cbdougla@uokmax.ecn.uoknor.edu (Collin Broadrick Douglas) (12/19/89)
In article <8912181746.AA01971@apple.com> SASQUATCH@ALBION.BITNET ("Kevin Lepard, 629-1827", 517) writes: >[stuff deleted] > >>Doesn't anybody use Text based programs anymore?? I mean, graphics are >>nice, but come on, it slows down most of my work (and I've got a TWGS, >>and Hard Drive). > >If any developers out there are listening (including folks at BB :) I by >_far_ prefer text based programs. In fact, the only graphics based >programs that get used on my GS are games and graphics programs. Other >than that, the graphic stuff is just too slow for my taste. Sure, graphics >are great for somethings, but unless that database lets me store graphics >images, or that spreadsheet puts graphs and charts on the screen at the >same time as my cells, I'd by far prefer to see the program switch between >text and graphic screens as necessary. > >For what it's worth... > >>Mark Munz > >Kevin Lepard >Bitnet: Sasquatch@albion.bitnet yes. I also prefer text to graphics in a lot of programs but there are occasions where graphics enviornments are needed (as pointed out above). But, I have also noticed that many of the text based GS specific programs are much slower than equivalent //e products (compare Appleworks to the Orca Editor for instance -- Appleworks even supports larger files). Why is a 16 bit text editor slower than an 8-bit integrated package? Shells appear to be slower (compare Davex to ECP 16). Is there a decent explanation for this? Collin Douglas cbdougla@uokmax.ecn.uoknor.edu
rnf@shumv1.uucp (Rick Fincher) (12/19/89)
In article <14289.chatter.infoapple@pro-beagle> mmunz@pro-beagle.cts.COM (Mark Munz) writes: >In-Reply-To: message from rnf@shumv1.uucp > > >Adding an "easy interface" would kill the program from day one! Plus, >you lose a nice hunk of speed that you'd gain from using the 816 the >way it should be used!! The interface has very little to do with the speed of the program. It will not affect search and sort algorithms, disk access, etc. The interface only determines how the program will present data to the user. Quick text handling can be done in the graphics interface (check out the word processor in AWGS). Many of the slow programs you see are the result of programmer inexperience with the toolbox, as they become more familiar with it their code gets faster. Sure a text oriented system will always draw to the screen faster but you lose fonts, DA's etc. With system 5.0 you are waiting less anyway. The text screen may be five times faster but what's the difference to the user between a .1 sec wait and a .5 sec wait? Since a disk oriented database (a powerful database would have to be disk oriented) is going to be speed limited by disk searches, the interface won't matter. BTW who decides how the '816 "should be used"? > >Doesn't anybody use Text based programs anymore?? I mean, graphics are >nice, but come on, it slows down most of my work (and I've got a TWGS, >and Hard Drive). I you consider the time it takes to manipulate the menu system on text sys- tems I think you'd find that the windowing interface is about as fast, not to mention easier. Apple did a fascinating study on this and found that the perceived speed of the interface was slower, but the actual speed was the same or faster because the "intellectual involvement" of the user was much less with the windowing interface, ie using the mouse required only low level motor control functions of the brain, menu interfaces require a high degree of operator concentration to remember commands, move to menu selections etc. That forces the operator to put brain power into operating the computer that should be going into the task at hand. Because the operator could operate the machine almost unconsciously, they perceived time lags to be greater than they actually were in comparison to other interfaces. Some people like text interfaces, but maybe nobody uses "text interfaces anymore" because they are a pain for people that aren't like us in that they don't use computers all day. It's not their job to remember a lot of commands or syntax nuances, that's what programmers get paid for. Rick Fincher rnf@shumv1.ncsu.edu
ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) (12/21/89)
In-Reply-To: message from done@pro-sol.cts.com Appleworks GS is adequate for me, but I'd like a relational database with a scripting language. Should be DBase compatible, but that may run into legal difficulties. The spreadsheet would need to be a real zinger to be profitable, again a scripting language would likely be the best. Stand alones need to allow custom interfaces and other niceties to beat out Appleworks. Porting FoxBase/Mac to the GS would be my idea of a profitable endeavour. :-|
done@pro-sol.cts.com (Don Elton) (12/21/89)
In-Reply-To: message from cbdougla@uokmax.ecn.uoknor.edu Shells under P16 or GS/OS frequently use the 16-bit text toolkit which is really pretty slow compared to using your own custom drivers which externally loaded EXE files might have difficulty using (since the EXE progs depend on the shell for the screen driver.). The custom screen drivers I've written for TIC Pro are incredibly fast... faster than 8-bit Appleworks for example.