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