UI - Period.
- From: "Tom deL" <ted@xxxxxxxxxxxxxx>
- Date: 26 Oct 2005 08:52:31 -0700
Hi Tony,
> >The middleware has forced the backend to become so 'normalized' (or
> >whatever term you wish to use) that you have lost most of the
> >advantages of the data model for which you chose the product in the
> >first place.
>
> I disagree with the foregone conclusion that flattening an MV database
> is the only way to use it via middleware. mv.NET is an example of a
And after my recent pleas for accuracy in language you may rap my
knuckles. "Most often" this is the result of folks attempting Micro$oft
desktop compatibility.
> product that's been engineered to allow us to integrate with the
> non-MV world without changing how the database is organized. This is
> one of the major distinctions between for-fee value-add products, and
> for-free libraries like the D3 Class Library and simple wrappers like
> UO.NET.
Not so sure that I can agree with the distinction being based upon
development/licensing model: In my PHP client library for openQM I have
made every attempt to retain the PICKlike models (while admittedly
adding some SQLlike and PHPlike features).
Due to limited time I am going to stay with this thought and snip the
rest for now. I hope to revisit it soon.
This discussion is hinting at something that I have great difficulty
wrapping words around: The way that the intangibles in the PICK model
(note that I didn't say _data_ model) contribute in ways that seem to
make the whole greater than the sum of the parts.
With no offense meant to anyone, I think that most here would agree
that PICK people are sort of an odd lot. People in other related fields
might even see an almost religious fervor amongst us. I think that
there is a reason for this and that it is somehow embedded in the
system.
The first PICK professional I encountered was a young (early 30s) woman
who was a programmer for a vertical software vendor. In the course of
fulfilling her company's contract she provided me with an introduction
to PICK and the PICK way of database design and programming. She had
taken what at the time was the normal career track: majored in computer
science; graduate; work for big mainframe-ish companies. And then she
went to work for this PICK house.
She once made the statement that she would leave the computer field
before ever working for a company that didn't use PICK. This seemed a
rather radical thing for such a conservative person to say ... until I
had worked with PICK enough to get a feel for how well suited all of
the tools it offered were to the task of data management. Then that
statement was understandable to me.
I hope that the above wasn't a meaningless side track but one of the
things that I believe poses (posed?) the greatest threat to MV as
anything beyond a museum curiosity is the loss of that strangely useful
and intuitive collection of 'stuff'. If only one piece (data model)
remains the power is lost; it is just another backend.
The problem is that this collection of stuff seems sort of bound to the
3gl/CUI universe - all of the CUI 4gl's that I have seen lost this
feel. I have been attempting to conceptualize a GUI that could 'feel'
like PICK/BASIC - that would be as intuitively bound to the data
structure and processes as is PICK/BASIC, PROC and Access (sorry
Micro$oft, we had it first LOL).
So ... here is a hastily prepared challenge: Maybe some of the thinkers
here could turn their attention to this issue. What would a properly
PICK (MV, sorry again) GUI look and feel like? What would put one
inside the database as did TCL (literally and figuratively)? How can we
design something that will put the user in the correct frame of mind?
Perhaps many feel that this isn't an issue but my guts tell me that it
is central.
TIA,
-Tom
P.S. Jon Kristofferson e-mailed me some very interesting ideas about UI
some time ago. Jon, would you like to weigh in on this?
.
- Follow-Ups:
- Re: UI - Period.
- From: michael
- Re: UI - Period.
- References:
- Re: Value ...
- From: Bruce Nichol
- Re: Value ...
- From: Geoff Goodchild
- Re: Value ...
- From: None
- Re: Value ...
- From: jra
- Re: Value ...
- From: Homer L. Hazel
- Re: Value ...
- From: jra
- Re: Value ...
- From: Tom deL
- Re: Value ...
- From: jra
- Re: Value ...
- From: Tom deL
- Re: Value ...
- Prev by Date: Re: Startup puts a twist on PowerPC
- Next by Date: Re: Attempt to de-mystify AJAX
- Previous by thread: Re: Value ...
- Next by thread: Re: UI - Period.
- Index(es):
Relevant Pages
|