|
I have a hard time comprehending ... could you confirm I got the point please You are saying (greatly simplified) If you know what your data looks like at app build time then a hard-coded GUI is better. If you dont know what your data looks like at app build time then a data-driven GUI is better. Is that the idea ? From: Len Bullard [mailto:cbullard@hiwaay.net]
Data-driven models work nicely for plotted events. IOW, if you are feeding data to a model across a process, as long as you understand
the event space, you can control that model. The problem of GUI-as-BoxesOnAScreen is most of the states are static or enumerated and data driving it where the drivers are HUI inputs to machine interfaces even if gesturally rich is objective impoverished.
The model of finding resources and acting on them is basic, thus REST. Almost all of the richness comes from domain specific-events and conditions. Data driving comes into its own when you drive the model against a dynamic event framework that is outward facing, e.g., a mission environment
with waypoints. Then everything is a sensor and everything else is a data resource be it internal or environmental. len -----Original Message----- > peter says I find it interesting that "data driven" can someone how be viewed as in opposition from giving the user a better UI. In the end, the metadata that should be used to build user interfaces is still data and exposing
that as early and directly as possible and giving the users ways to manipulate that data is the best way to build a powerful user interface. Exposing it directly as XML is probably not part of that scenario, but XSLT on top of XML can be directly below the
layer that is exposed to the user and is very flexible and powerful. >
I come from a long history of being pulled into doing UI when I wasnt really good at it
(20+ years ... think X10, DOS ... and on through all incarnations of Windows, Mac, Devices , Palm, PPC, BlackBerry, iOS .... ) "Data Driven" GUI has always been a holy grail. In some closed systems it succeed quite well ... especially when the expectations of the users were modest and the computer capabilities were equally modest. But as time advances I find the concept on less solid grounds then my liking. I spent a day at Balisage Pre-conference hoping that what I didn't know about XForms would enlighten and endear me to the concept. I am afraid it did not. I simply have not seen how a data driven UI ( unless that data is presentation oriented + program code) can achieve what "ordinary
users" expect out of a "normal UI". There are certainly a lot of cases where the UI can meet the minimum standards, and balanced against
the problem of multi devices and variety of input is a good tradeoff. But when you hit the bounds of "application" where users expect that it was actually written for them ... and where the function and display (the whole UX) is more than filling out form fields or showing some
tables, to me, I have not seen a "Data Driven UI" that meets that expectation - unless you constrain the space very tightly. That is you
create a very good UI framework then plug in the data driven stuff to fit it. But I have used many such things and while they work well within their box, if you push up against the edges they fail miserably. I would love to have someone show me the Holy Grail ... I still think it might be out there, but have not found it myself. ---------------------------------------- David A. Lee |