Many Cards Versus One Card and a List Field

[Randall Lee Reetz]

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
>