> I think we cab use HC and Mac terminology here, to avoid
>misunderstandings. That is, FreeCard documents are stacks, the FreeCard
>engine is simply called the FreeCard application, and a FreeCard page is
>simply a card.
I'm fine with that.
>
>>* Creation and maintenance of new documents, pages ("cards"?), and individual
>>objects, including resetting the properties of any object where appropriate
>
> Do you mean changing objects' properties, or do you mean a "Reset" button
>that discards changes made up to a prior point in time? Please clarify.
I meant the former, and "change" is probably more in line with my meaning
then "reset."
>
>>* Navigation from document to document and page to page
>
> Definitely. I guess you already have ideas? Go menu? Navigator palette?
>Arrow buttons? None of these? All of these? ... ?
I have some (I admit to a strong preference for a button-driven UI over
pull-down menus); but my goal in this document is to establish a set of
generalized goals, not to push (or even propose) specific solutions.
>
>>* Interaction with the engine via keyboard, mouse (trackball, etc) and
>>display,
>>with audio and visual feedback.
>
> This goes without saying, I guess.
Yup...the user won't get far without it
>
>>* Object scripting, including handler debugging and variable/message viewing
>>* Direct command input (ie: message box)
>
> An actual feature request! This is definitely one of HyperCard's most
>sought-after features people request from clones.
>
>>* Online and/or printed instructions on how to use FreeCard
>
> Any suggestions what we should start with? A help stack, HTML docs,
>PageMaker etc. files to generate printed manuals, ... ? My personal opinion
>would be to start with computer-viewable docs and create printed docs at a
>later date (this would probably be something people could make money off).
My suggestion is to take the FreeUI document as a starting point and
1. Create a comprehensive list of goals and desired capabilities
2. Focus on individual goals/capabilities and create more detailed
specifications for each.
3. Merge this into a specification document for those programming FreeUI
and a preliminary help manual.
4. Update the help manual to reflect changes made during implementation
and testing.
My preference would be a help stack, and I wouldn't print anything except
basic installation instructions and instructions on how to print a manual.
>
>>* Import/conversion of HyperCard stacks
>
> Just to provide additional technical details: Conversion should be
>possible with an "exporter" HC stack and an "importer" FC stack. Actually
>having FC open HC stacks would require knowledge of HC's file format, which
>is a closely-guarded secret and would require a good programmer to
>reverse-engineer HC's file format.
>
>>1. Consistency: All aspects of FreeUI should share a common look and feel.
>>It should appear to the user/developer as wholly integrated. A consistent
>>look
>>and feel should permeate every aspect of FreeUI, including documentation and
>>help/error messages.
>
> Definitely. I urge everyone actually creating a window/dialog/palette for
>FreeUI to look at existing dialogs in already finished parts of FreeUI and
>to make their window layout resemble this dialog. Just look at how HC's
>button/field/card/stack info dialogs all look so similar.
I will suggest we go farther...I'll specify details in a later post.
Rob Cozens, CCW
http://www.serendipitysoftware.com/who.html
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
