Many Cards Versus One Card and a List Field
Jerry Daniels
jerry at daniels-mara.com
Mon Jan 14 17:21:47 EST 2008
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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
More information about the use-livecode
mailing list