RE: [Pythoncard-users] What Do We Call These Things?

[David L. <wh...@oz...>]

Wow, if Bill Aitkinson is the God of Hypercard, Danny Goodman is surely one
of the prophets ;)

There's a reason why we're (well, you're) trying to implement Hypercard for
a wider audicence 20+ years after it's debut (not without a fight from Apple
i've read), and that is that it had/has a _simple_ NON programerish feel
about it - lots of people who felt intimidated by the idea of programming
where able to, and did, cope with Hypercard quite handily. It was simple
enough for Suzy Teen to keep her record collection on, yet capable enough
for the budding college biology student to start a species catalog on - and
even could work as a catalog for a business.

That original idea of a (3x5") card in a stack of cards is as sound now as
it was then. I suggest avoiding "compugeek speek" wherever possible - unless
you want to restrict your audience to that genre. Of course, there's a
surfeit of products for geeks...

Now, having said that (and, I realize, repeating to some extent the Good
man's post), I don't want to stifle any creativity/enhancements that are
possible. People _are_ more computer literate in general these days and that
implies a more computeresque interface and terminology, but I still say the
more of that you use, the less inclined "Aunt Doris", now retired, is going
to be inclined to take a stab at putting her award winning recipe collection
as a pass time for her "golden" years.

As for taking a leaf out of Microsoft's book... firstly, they bought or
stole the book or the idea for the book from someone else, drove all the
other book makers out of business and now sell poorly crafted books that
you're stuck with paying what _they_ think it, in their vastly self inflated
opinion, is a reasonable price for their Mediocre "books". (Now writing on
an Athelon running Windows 2000 Professional with Office 2000 and Visual C++
6.0 lurking. I hate Microsoft - every damned day. Of course, my other
computers are or will be running Linux :).) Secondly, I refer you to my
opinion wrt to using programerish jargon (valid and valuable though it might
be to a knowledgable user).

What I would hope to see in a Windows context, is a little control panel
sort of thing with the menubar and the stack itself floating on the desktop
with no menubar or other adornments the user didn't put there. This is
possible on Windows; you just have to write a new class (not a C++ class, a
Windows class) that doesn't use the non-client window styles (dunno how
easily that sort of thing is done in WxPython though). This "card" should be
able to get as close to looking like anything from a type-written 3x5 card
on up to something that looks like it was a 3-color press job, all depending
on the effort the user wants to put into their stack. The little control
panel thingie should be able to open several stacks at once and maybe
maintain a list of stacks it knows about (the "library").

No notion here that cards should be any particular size btw... although, I
think it makes sense to have all the cards in a single stack be the same
size - and maybe have "fold-outs"?

I guess my bottom line is that if you keep it simple, direct and
non-technical it will go far. Turn it into another forms-based application
generator and you're competing with the Microsurfs of Redmond - and, it
being a matter of legal judication, they cheat. The Hypercard paradigm has
stayed fresh enough to interest a new generation of developers 20+ years
after it's debut and there are few programs around that you can say that of.

Before I go, i've been meaning to mention that i've got some potential
resources: The original Hypercard spec book from Apple, Danny Goodman's
Hypercard book(s) up through 2.2, an actual Hypercard Manual and maybe even
still a book on an early Windows clone called SuperCard.

I now return to vigilant lurking :)

Dave LeBlanc
Seattle, WA USA

P.S. Oh geesh, I realize i've pretty much recapitulated what's already been
said, but i'm sending it anyway :)

"Near, but not of, the evil empire"

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Monday, January 07, 2002 14:12
> To: pythoncard-Users
> Subject: RE: [Pythoncard-users] What Do We Call These Things?
>
>
> > From: Dan Shafer
> >
> > Kevin suggested that he was thinking of moving away from HyperCard's
> > stack-background-card metaphor for a number of reasons. But he
> > remains appropriately adamant about keeping the simple-is-good
> > philosophy behind PythonCard. He ran up the flagpole the idea of
> > using Application, Form, and Panel. What follows is my thinking on
> > the subject, FWIW.
> >
> > Whether it's good, bad or indifferent for PythonCard to "lose" its
> > "HyperCard-ness" is, I think, less important in the long run than the
> > simple-is-good philosophy. But I think there's something
> > fundamentally sound and intuitive about the stack-background-card
> > metaphor that shouldn't get lost, at least for the Inventive User
> > audience. These non-programmers don't want to think in terms of
> > applications, forms and panels. Those are "geeky" things.
>
> The reasoning goes like this...
> Application is pretty obvious. A script is really an application.
> Applications are what everyone runs on their desktops. We even
> use the term
> WebApp which is really a horrible name. I suppose you could use the term
> "Program", but my gut tells me that if you say "Application" even newbie
> programmers and creative users know what you're talking about. Since there
> is no required runtime environment to use a PythonCard application, the
> stack/document confusion can go away.
>
> Form is 100% from my experience with Microsoft (MS) and wanting
> to leverage
> the "education" they've already given 3 million plus VB coders.
> Visual Basic
> programmers design Forms. .NET uses the terms WinForms for things outside
> the browser and WebForms inside the browser. [As a side note, the current
> implementation of WinForms and WebForms does not provide an easy way to
> translate between the two, which I'm told is because MS is a large company
> with two large programming groups that are not communicating very well :)]
> Whether you like it or not you are going to here about Forms a
> lot as the MS
> marketing kicks into high-gear this year.
>
> In MS terms, a Form can have "decorators" like a menubar, statusbar, and
> various window styles. That is what we are doing with Background in the
> resource file. I would like something that is just the stuff inside the
> Form. In wxPython, this can be a wxPanel and PythonCard is using a Panel,
> but for the most part it is hidden from the user code. MS also uses Panels
> inside Forms. You can nest Panels.
>
> For PythonCard, there is not much difference between the GenericDialog
> (modal dialogs) and Background classes except that GenericDialog is modal
> and needs buttons with specific button ids for OK and Cancel. You
> should be
> able to use the same layouts for either "window style".
>
> The only real reason PythonCard doesn't do scrolling windows
> right now is I
> couldn't decide where to split the panel/background/window
> settings. I did a
> working scrolling window demo back in August which just contained a really
> big Panel and it worked fine, but the window has a different window size
> than the Panel and at the time we still had 'size' in the 'stack' and we
> still don't distinguish between window and panel size. The same issue
> applies to other window styles.
>
> > I'm not certain that stack, card, background is the requisite
> > terminology set, but I do feel that something _like_ that set of
> > terms is necessary.
>
> Another possibility is what I suggested back in October when I started to
> get more serious about making PythonCard wxPython specific.
> PythonCard is a
> simplified way of doing wxPython applications. A more direct clone of the
> HyperCard stack/background/card metaphor could be used in an application
> written in PythonCard and would provide the lightweight database
> persistence
> expected of HyperCard apps. Even if/when we get the document classes in
> shape to support automatic saving of data and metadata for components, it
> will still be optional because not all applications need it.
>
> In fact, this could be a commercial possibility for someone or
> some company
> that wants to cater to ex-HyperCard users. Just an idea. I
> specifically want
> to avoid the GPL so that this kind of thing is at least a possibility.
>
> When PythonCard started I was definitely thinking in terms of stack,
> background, and card. All PythonCard apps use a Single Document Interface
> (SDI) style instead of Multiple Document Interface (MDI) and the resource
> format reflects the further restriction that there is only one menubar,
> which is more of a Mac thing, that Windows or Linux SDI where
> each "Window"
> can have its own menubar.
>
> As we progress the sweet spot I have in mind is somewhere between an
> "inventive user" and a VB-programmer and I would like to cater to both.
> PythonCard should be appropriate for someone learning Python as
> their first
> programming language in addition to someone coming from
> HyperCard, HyperCard
> clones, Visual Basic, REALBasic, and the tired masses of people
> like me that
> beat our heads against Java trying to build GUIs and eventually gave up. I
> don't particularly care about meeting the needs of teams of
> "sophisticated"
> programmers that would be more happy with Delphi or Microsoft
> Visual Studio,
> though hopefully PythonCard will be useful to those folks as well.
>
> Obviously, this stuff is not entirely crystal in my mind and we have a lot
> of room to morph the existing structure.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>