[Tfug] RDBMS reprise

[Bexley Hall]

Hi, Claude,

[argh!  in hindsight, this is WAY too long!  :< ]

On Sat, Feb 02, 2008 at 09:44:11AM -0800, Bexley Hall
wrote:

[cell phone]

>Granted, it doesn't do anything perfectly (and
generally 
>does many things poorly) but since you always have it
on
>you, many of us find it useful.  E.g., I recently got
a
>cell phone that plays mp3s and supports SD cards ==
my
>ipod nano is superfluous.  Only other way that that's
>going to happen is if they bolt a phone onto an iPod
(oh,
>wait... ;-)

But a phone (form factor) is really *not* the right
device
for storing grocery lists, address book, appointments,
etc.
It's just too damn small to be practical for the
variety
of people who would want to do those things.  E.g., my
Dad
can't even push the tiny buttons on many phones!  :<

And, you can play MP3's on a device *without* a
display!

>> I've tried playing with several and find that I
>> have to force myself to carry it -- and only at
>> certain times (e.g., while I do my daily walk I
>> carry one to log my time exercising and busy my
>> mind -- Soduko -- while walking).  I.e. I am
>> not *compelled* to carry it.
>
>In my opinion, if you have to force yourself to use
it,
>then it's not for you.

I almost agree:  this *implementation* is "not for
me".
But, the problems it addresses are exactly those that
I want
addressed!  I just can't figure out what is *wrong*
with
all of these devices ... i.e. why I haven't been able
to
find one that I *embraced* (I've looked at perhaps a
dozen
different PDAs... various Palms, Newtons, Cassiopeia
(?),
Phillips somethingorother, etc.).

On the one hand, I *think* about the problem that I am
trying to have solved and I find their solutions "OK".
Yet, in *practice*, they all are disappointing.  I.e.,
there is some *thing* that I (and THEY!) are failing
to
perceive in the design/specification that makes them
fall short of their potential...  Hence the puzzle.

>When I was working in the private sector, I did use
my
>Palm throughout the day, for a variety of tasks. 
Once
>I went back to school, however, I found that it
didn't
>work well with how I now had to work (namely,
thinking
>a "week-at-a-time" rather than a "day-at-a-time."

That might be some part of my "problem".  I.e. I tend
to work on very long timescales.  A project may take 
months or years to complete.  So, the micromanagement
of my activities on any given day isn't very important
(i.e. I don't have to worry about "meetings at 9:00,
2:30 and 4:15").  But, rather, events with a longer
horizon (i.e., design approval on 3/14; first silicon
on 5/1; alpha test on 7/10; etc.).

Likewise, the contacts that I might have to track tend
to be sporadic in nature.  I can easily remember the
phone numbers, email, etc. of folks that I am in
contact
on a daily/weekly basis.  But, if I only touch base
with a PCB fabricator a few times in each project
(e.g.,
once prior to delivering artwork, again shortly
thereafter
to review any manufacturability issues, once more a
few
weeks later when sample boards are available and then,
a final time, when I make the production corrections),
then I need something to remember that contact
information
*and* the associated activities that go with that!

>Point being - just because it hasn't worked for you
>doesn't mean it does work well.  Just not for you,
>not for this particular task.

Of course!  But, my observation has been that it
apparently doesn't work well for LOTS of people!

Imagine if microwave ovens had this sort of
"unsuccess"
rate...  Or, televisions...

Granted, apples and oranges.  But, even if your TV
has severe shortcomings (I had a set that did not
implement MUTE as an independant function -- made it
a useless feature!; I've seen some sets that have
remotes
that require you to *hold* the "TV" button depressed
*while* changing the volume/channel; my Dragons don't
properly maintain the tape counter when the tape
"flips",
etc.), you still *use* it.

Of course, a TV is much *larger* than a PDA.  But,
often
PDA's *cost* more than TV's (so, one would think you
would
be motivated to find *some* way of using the PDA
despite
its problems -- just to salvage the investment!)

>> Yes, but *why* (not)??  :<  The idea seems
*perfect*;
>> keeping track of all this *cruft* that is just not
>> worth remembering (appointments, phone numbers,
>> addresses, etc.) -- yet is "inconvenient" to
>> *forget*!
>
>That statement is a classic example of a solution in
>search of a problem.

No, you've missed my point entirely!  The PDA *should*
be the solution to *my* problem.  *And*, this same
problem that others (apparently) have.  The question
is, *why* is it NOT?

I.e., I want something to track my contacts.  I want
something that I can use to jot down things to pick
up on this week's weekly shopping trip.  I want
someplace
to jot down questions I have DURING THE COURSE OF A
YEAR
for my MD prior to my annual physical (scraps of paper
on the refrigerator just don't cut it  :> ).  I want
a place to note books that I would like to peruse
next time I am at a bookstore.

I don't care about getting email, browsing the web,
etc.  I have a computer for those things.

Likewise, I don't care about watching TV, listening to
the radio, etc.  I have appliances that do those
things
quite well.

What I wan is *exactly* what a PDA *theoretically*
should
be!  But, the implementations don't seem to "fit". 
And,
apparently, they don't "fit" other people's
expectations,
either!

*WHY??*

I can *build* something to do the same sorts of
things.
But, if I were to start putting something together
*today*,
I would end up with something with the same "problems"
that the PDA (apparently) has.  But, I can't put my
finger
on what they *are* -- therefore, I can't *fix* them!

>What you (we, I, everybody) *should* be doing is
asking
>"What's the problem that I'm trying to solve?"  And 
>then -- and only then -- looking for the solution. 
All
>too often, we pick the solution first.

I don't think that is the case, here.  E.g., I once
set
up a database to track my "contacts" on a PC.  It did
the job perfectly (I track contacts by
*relationships*;
so, I can pick a person and track "relationships"
between
that person, their offspring/parents, employers,
fellow
employees, etc. until I get to the person I want). 
But,
it's not portable.  It ran on a PC (so I had to make
sure
I was using *that* PC in order to look things up).  It
was dependant on particular versions of software/OS,
etc.

I know why *that* solution failed to satisfy my
usability
requirements.  I can live without the complexity of
the
database's design in a PDA context (i.e. I assume most

folks wouldn't want to be bothered maintaining this
level
of detail -- it would be silly in a commercial
offering).
I just can't figure out what it is about the PDA that
keeps "failing to satisfy".

>I don't know that programmers are more prone to this
>syndrome than the rest of mankind but it frequently
>obvious when we do this.

As an engineer, I come up with designs *before*
implementations (i.e., I don't fall victim to the
"start_writing_the_code_and_figure_out_what_it_needs_
to_do_LATER" syndrome).  And, those designs are based
on an analysis of how users will actually *use* the
device in question (consumers tend not to think like
engineers -- e.g., George's comment about PBX client
wanting 5 rings instead of 4 or 6:  "What's the 
difference?  Why is 5 so important to you??").

>Incidentally, this is part of my love affair with
fvwm
>and emacs.  Whenever I find myself doing the same
thing
>over and over again, I add it to my to do list.  At
some
>point in the future, I spend a little bit of time
hacking
>away at the relevant config so as to
simplify/eliminate
>the issue.  This is why I insist on tools that (a) I
>expect to be around in the long term and (b) are 
>*designed* to be bent to my will.

Yes.  Though in a consumer device, this is often a
fatal flaw in a design.  Giving a user too many
options
often just confuses them.  They don't know how to
choose
from among the options and, thus, feel intimidated by
them.  E.g., how many folks driving automatics ever
use "2"?  Or, "D" nowadays (given the prevalence of
"overdrive" as the "default" for D, nowadays).  These
people can live with those choices because, when they 
were explained to them, the conversation went
something
like:  "Just keep it in 'D' always -- unless you are
towing something heavy up a hill; then use 'L/1'".
This allowed them to internalize the role of that
option.
And, to then dismiss it (since they rarely tow heavy
items up hills!  :> )

The same is true of programming languages.  Too many
ways to do the same thing often is counterproductive.
Unless you are initimately familiar with a particular
language -- and, thus, able to exploit subtleties
between different idioms -- the extra choices often
confuse things.

>Of course, the other problem that programmers
>frequently run into--or cause, as the case may be--is
>over-analyzing the problem and solving for
contingencies
>that may or may not exist.  This, of course, is the

I find the opposite to be true in many projects:
*expecting* the user to do a certain thing and not
handling the unexpected at all!  (I have a talent for
*breaking* things like this  :> )

>problem (partially) solved by the "release early,
release
>often" method and (more completely) by the Unix
>"worse-is-better" approach.

These approaches only work in desktop/mainframe
environments where the cost of a new release isn't
(terribly) expensive.  If, OTOH, you had to update
the software in every microwave oven you sold
because you screwed up in your assumptions, you would
find that you had lost more than you could ever hope
to recover!  (e.g., the controls in a typical
microwave oven cost less than $10 to produce; an
"upgrade" would cost 5 times that amount -- you
would replace the entire oven, discard the old one
*and* have to reimburse the store owner for his
labor!  And that doesn't count the "cost" to the
consumer for the gas, time, inconvenience, etc.)

Too often "programmers" think the world is a PC.
Note that there are 10 - 100 X as many embedded
systems out there IN CURRENT USE than the total
number of PC's *EVER BUILT*!  You don't get a
"second pass" at those -- get it right the first
time *or* piss off your customer (and, perhaps,
never *get* a "second time/sale").

Looking at a typical PC, so many "components" have
one (or more) processors: disk, CD-ROM, DVD, ZIP,
mouse, keyboard, monitor, motherboard thermal
management (etc), SCSI HBA, scanner, printer (2
if it is a laser), WAP, etc.  So, a "plain jane"
PC has at least 6 or 7 processors running dedicated
code in addition to the *one* that runs "updatable
software" (i.e. the x86).

And that doesn't count your non-PC stuff:  TV,
VCR (probably has 3 in it), DVD player, cable box,
digital camera, "HiFi" (probably has at least one
in each "component"), each of your remotes have one
(don't forget the one for your garage door opener!)
furnace, its thermostat, irrigation timer, ABS system
in your car, car ignition controls, car "entertainment
center", cordless (not cell) phones (plus another "in
the base"), cell phone, telephone answering machine,
and, of course, your PDA  ;-)

Note that this isn't even addressing the "techies"
out there who have all sorts of gizmos!  I'd wager
that this list just addresses the "typical (Tucson)
resident" (OK, if they aren't a homeowner, they
probably don't have an irrigation system and their
furnace might be a "shared resource" -- but much
of what remains is probably there, somewhere!)

It is frustrating when people adopt the attitude
that it is not important to "get it right" because
you can always "do it over".  You *can't* always
do it over!

Even for "products" that can be upgraded, that
attitude just shifts the cost to the end user.
What makes you think the end user *wants* to
have to spend time upgrading something that
he *thought* worked when he bought it?  Ever
had to bring your car in for a recall?  Even if
there is no (monetary) cost involved, it is
downright inconvenient!  You have to waste *your*
time because someone didn't do *his* job right.

<grin>  Obviously, this is an issue near and
dear to my heart... :>  I can just hear the designers
of the Therac saying "Well, we'll fix that in the
*next* version of the software... which, as a
registered user, you can purchase for just $99
(assuming you survive that hole we just burned
through your chest)"

>Back to the specific question of why PDAs aren't
>more prevalent:

But I wasn't asking why they weren't more "prevalent".
I was asking why are they purchased and then
UN-used so often.  I.e. people who have bought in
to the idea of having a personal organizer and
then been disappointed (implicitly) by it.

>I would suggest that it's because there are
>countless ways of doing this very thing.  PDAs
>are one solution, addressbooks are another, BBDB
>for Emacs is another, plain text files another,
>etc.  Myself, I find that a combination of cell-phone
>and notebook-based solutions is ideal for my
>needs as I pretty much always have my phone with
>me and, more often, than not, have my notebook in
>front of me.  Therefore, no PDA.

It will be interesting to see how well PIM
functionality
is "accepted" in cell phones.  Or, if it just turns
into yet another unused "feature".

>But this is only because I do all of my work from
>my notebook and always have it with me.  Sometimes
>I catch myself thinking or saying "I'll never go
>back to a desktop, the flexibility that the notebook
>offers is just too convenient."  In fact, that
>flexibility is only useful because of how I work
>today.

Exactly.  I suspect that if I had to travel more
for $WORK (or $PLAY), I would be more compelled to
find *some* portable solution.  E.g., when I *do*
travel, I begrudgingly pack a laptop.  But, find
myself grumbling whenever I am using it and, as
a result, using it as little as possible.

The same is no doubt true of the PDA -- using it
even *less* because it is not fulfilling some
requirement that I have (but can't yet identify)

>People who find themselves working on a variety of
>computers find webmail to be very convenient;

Exactly.  Or, rely more on portable tools than other
tools that might be "better" (i.e., I *depend* on
vi(1) and only use emacs(1L) when it is accessible).

>for me, all webmail implementations pale in
comparison
>to my mutt+emacs+postfix combination.  But that's
only
>because I wouldn't take advantage of webmail's
>distinctive characteristic--being web-accessible.

Exactly.  If I had to rely on webmail to track my
(email) address book, etc. it would be a terrible
solution -- despite the fact that it would implicitly
make my address book available to me wherever I
happened to need it!  :-/

>My point being: today I can't see myself ever giving
>up my notebook.  But when my palm pilot was a central
>part of my day, I couldn't see myself ever *it* up.

I guess I am not as "tied" to particular devices.
I move from machine to machine throughout the day.
My biggest concession to "normalization" was to
ensure each of the "PCs" had the same keyboard;
and, the UN*X boxen have the same keyboards (but,
curiously, I don't insist on UN*X boxen and PC's
having the *same* keyboards!  :-/)

>The challenge is to alway be open to where one finds
>oneself currently and respond to that, rather than
>to the past or to the (expected) future.

For me, an essential part of that is knowing
*what*/*why*
I have particular preferences/requirements. 
Otherwise,
things just "don't feel right" (e.g., the PDA) and yet
there is no rational explanation to help you move past
the problem to a solution.

> (That was a little more Zen than I intended.)

Gee, and me without a motorcycle...

--don


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ