Randall,
Sounds like a good project, and you have a solid understanding of the
problem. How about YOU being first to solve it?
Seriously,
JD
On Jan 14, 2008, at 3:21 PM, Randall Lee Reetz wrote:
Jerry,
On many of your points I agree. It is possible (though definitely
not automatic) to store data external to a stack (in a text file)
and use cards as UI modes; different ways of viewing and interacting
with the raw (external) data. When HyperCard was born, data was
static or reasonably static lists of friends and family (the
personal rolodex), or limited storage of content (anatomical parts,
insect facts, gardening tips). Today, data is expected to be
dynamic... isn't trusted if it isn't. In fact, we are realizing
that local data is dead data... that the only way to expect data to
stay relevant if lots and lots of people and organizations have
access to it (as authors and editors).
The fact that you can force the xTalk card/stack metaphor fit this
new dynamic model of data doesn't really mean this force is ideal...
quite the opposite. The only real reason I can come up with when I
ask my self why I use xTalk still or why I would recommend it to
others just starting out, is that the language and creation metaphor
are so human... that and the fact that the ideal solution doesn't
exist yet. Nothing that humanizes the access, manipulation and
analysis of dynamic data yet exists. Said another way, nobody has
yet HyperCard-ed dynamic data use affordances.
What would it take to do this? What would a humanization of dynamic
data handling look like? Well, the basis of useful data is
typing... somehow divining the data storage (or live access)
organization protocol of the source and automatically setting up
reasonable affordances for presenting this data (should it be
presented as a graph or a trellis or a table or a list or a
ontological tree or a topology or a simulation or a linear story or
2 or 3D diagram...? How should the user filter the data for
relevant subsets or patterns? How should the user select
boundaries? Should the environment auto locate anomalies, averages,
patterns, symmetries, exceptions, repetitions, duplicates, periods,
growth, semantic crossovers, data type confusions, source location
or entity, acquisition method, authority, agreement, etc.? How
should linguistic or mathematic semantics be brought to bare in all
of this?
I don't know exactly what HyperCard-ing or xTalk-ing dynamic data
would look like... but I do know that RunRev and SuperCard and
HyperCard are not it. I also know that someone somewhere will offer
up a solution that is good enough and this will be the next true
revolution in user level complexity handling.
Google is in a good position to lead us into this promised land...
but I don't see them doing so fast. What they need to get better at
(I would be surprised if they weren't hard at work on this) is
client side/server side shared computing and its sundry tools.
Surely they don't want to own the mips such a scheme would require
(or do they?)! I guess we are talking about a "web 3.0" vision.
Does anyone remember the Kaleida Project (Apple, IBM, et. al.) http://en.wikipedia.org/wiki/Kaleida_Labs?
One of there big pushes was a user level instantiation of the
model/viewer/controller development framework. What they really
didn't get (and it might have killed them) was the network or cloud
as base or source, and exactly HOW dynamic data would become because
of it. But the demos I saw at the time showed discrete interest in
making manipulation of data a live and user level process where the
experience and manipulation of data was assumed to be a dynamic
process. However, though these concepts were reafiable within the
ScriptX language, they were no more automatic than they are in your
run of the mill xTalk incarnation. ScriptX had full object
support... sat on top of a true OO method and data model. But
scripting looked more like C++ or Lingo than any natural language I
have ever spoken. Nothing I have mentioned previously that would be
required to automate dynamic data access and manipulation was
included at base architecture in the IDE.
Who will do it first?
Randall
On Jan 14, 2008, at 11:56 AM, Jerry Daniels wrote:
On Jan 14, 2008, at 12:49 PM, Russell Martin wrote:
if I can't realistically store large amounts of data
in stacks (and get acceptable speed), then what is the point of
using a
stack based development tool?
Russell,
This is an excellent question. The relevancy of cards (or even
stack-based data-rich lists) being used for data is the issue, I
think. The idea of local-only data is becoming anachronistic in a
world where data is more likely to be stored in "the cloud" where
it can stored and shared. I store my data in a cloud (on a server
"somewhere" identified by a URL). I just tag field and button data
with Rev field names and save/load them to and from text files. I
also index records in separate file for fast searches and lists in
my UI.
The idea of factoring data from UI is not a bad idea or a new one.
That said, I DO use cards, but they house the different UI's
dictated by the workflow of my apps. Rev stack/card metaphor serves
very nice for this. The case for "factoring" comes from the idea
that sending your app to someone else with all its data uses a lot
of bandwidth whereas sending an app that accesses the separate data
makes for easy app sharing. Sharing an app is sharing human
intelligence--a good thing.
If your data is forever to be local and never shared, it might make
more sense to use the cards for record data. Myself, I think of my
apps as being used by someone other than myself--even if it's just
someone with whom I work. Since everyone with whom I work is
tethered to the cloud, i put my data into the cloud.
My 2 centavos,
Jerry Daniels
Daniels & Mara, Inc.
Makers of GLX2
http://www.daniels-mara.com/glx2
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
