>* global variable names
>* objects supported, including default property settings
>* libraries of general purpose handlers (eg: justify, stripBlanks, etc)
>* a standard heading for all handlers listing information such as author,
>last modification date, copyright, etc.
>* a standrd format for printed and online documantation & help
>* standard programming conventions
>* standrd icons and or other resources (whether in a resource fork or not)
>* a list of all the lists :{`)
Hi folks,
This is exactly what documentation is all about. Recently someone
contacted me who had experience in this field, I'm sure he'll speak up if
he already made it to the list. Anyway, we'd certainly need programmers to
provide the information for these lists beforehand, so I guess every part
of the program (XBF, Anthony's interpreter etc.) should contain such a list
with only its globals etc. so the documentation crew can collect them from
there into one central list. As for a standard format for these docs, I'd
suggest HTML. Pure HTML that is, without any layout. Just <H1> ... <H5>
tags for the headlines, teletype and preformatted for keywords and code
listings. The best part of this is that it's not only cross-platform, but
also the standard format for help files under both Windows and MacOS 8.x
>(an example I'll propose: "Whenever an
>>answer dialog is to be displayed as the result of a user action, the dialog
>>is skipped and the default answer is returned if the optionKey is down.")
I don't like this. The option key is for other things, and hitting return
will usually be fast enough. Also, imagine you have a script triggered by
an option-click and it brings up a dialog. You'd never even see it. It'd
interfere too much with what users are doing.
Also, with object-oriented programming such standards aren't that
important to be written down like this (though they surely should be
documented). The reason is that we'll have classes or utility routines that
take care of e.g. showing *any* type of dialog. These would simply do this
kind of thing, and every dialog would inherit the behaviour since they all
use the same utility routine.
>But it all starts with sharing our goals & objectives and adding detail as
>we get further into the design. If you have not already done so, take a
>closer look at the applications you use every day. What is it about each
>app's UI that you find innovative, and what features leave you cursing?
>What apps' UIs would you list as especially good/bad?
Sounds great. Since I'm rather busy on XBF and other non-FreeCard
projects, I will have to do that later, though.
>Whether or not that's agreeable, can we get some idea of how many people
>are interested in partnership? We have the magnificant seven who voted in
>the first or second round and Adrian & MP0wered who spoke up during the
>discussion. Will those who are not one of the nine and want to be a
>partner let us know who you are. Likewise, any among the nine who don't
>want to be partners should say so.
Well, I'd like to be a partner.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
