[openbeos] Re: Data or App Centric?
- From: Helmar Rudolph <news@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 22 Feb 2005 11:16:25 +0200
Jonas Sundström wrote:
> Helmar Rudolph <news@xxxxxxxxxxxxxx> wrote:
> ..
> > The concept should be neither data nor app-centric
> > but _TASK_ centric.
>
> How would this work for the ISV or the lone dev man? I mean, we're used
> to a certain way of designing a "complete" application, packaging that
> application, and marketing/publishing/distributing it. What now? Design
> and implementation by committee?.. A True bazaar model?
Well, the design issue is not really one, because on BeOS you
code using the BeOS API, so for the task centricity, you'd have
similar guidelines.
Implementation of what? Continued in next paragraph...
> In a Task-oriented system, who makes what, and how can it be anything
> but chaos? Who takes care of the big picture, and how can an ISV sell
> you a solution when applications are merely sets of disjoint
> components?
First of all, there is no chaos, just a different way of
accomplishing things. That ISVs have to rethink the way they are
doing things goes without saying, but remember, the computer is
for those who use it - we're after their satisfaction. If the ISV
is still logged in "software stong age", that's his problem.
Secondly, this isn't really applicable to BeOS, where no proper
ISVs exist. They are all small outlets who can benefit greatly
from adapting to the new situation, because ...
Thirdly, no one says there can be only one tool for a particular
purpose. It's just that using the task centricity and the
toolchain approach, you'd break up the process into components,
which - if you think about it - could provide ISVs with the
opportunity to sell smaller items of their once large application.
I admit though that I have only thought about the end user, and
how they can make the often frustrating computing experience more
effective and more efficient and less annoying and intimidating.
This is an area, BTW, where the poor, "threatened by chaos" ISVs
have failed miserably in the past 10 years, so I don't mind their
cages being rattled.
> The idea of making a system of only (or primarily) components,
> ignores the code which exists to bind the components together.
Tell that to the manufacturers of the telex machine, who spent
lots of time and money on perfecting it. Seriously, though, just
because in the past a lot of time and effort was spent on
perfecting the imperfect doesn't give them a reason to survive or
be.
We must NEVER NEVER EVER forget that a computer is meant to make
our life easier. It should allow us to spend more time on OTHER
things. Computers, by and large, aren't up to that task, though,
and that's partly because the way the OS and the applications
were designed.
Now with the OS we have a unique chance to change that, but on
the application side it's been a major gripe of mine for a long
time that the BeOS apps are largely Windows copycats. There was
little if any innovation coming out of the BeOS programmers camp.
Fancy gimmicks yes, but not true process innovation. The
completely inconsistent user interface to this day is a MAJOR
stumbling block in becoming accepted and therefore mainstream -
or at least less marginalised.
The toolchain approach would put the power into the hands of the
user, who can decide how to adjust the tool chains to suit their
needs. In fact, an entire new "industry" could spring from
assembling different chains to perform different tasks. The once
mighty "25mb+ install brigade" of ISVs would, however, transform
into tool developers, whose products would adhere to /work under
a consistent user interface, rather than forcing the user to
adjust to the way they thought the application should look and
work.
At the same time it empowers the small developer who cannot spend
the resources on a fully fledged application to participate in
the market and to "throw in" his expertise where it could really
make a difference to the end user. He is no longer disempowered
because "the large ISV" owns the mindshare of the user. The focus
of the operation would be the task, and the task is driven by a
tool chain to which everybody can contribute.
Sure, all this is new and therefore open to much discussion
and deliberation, but quite frankly, I have no interest in BeOS
or Haiku if all it does in the end is just as inefficient as what
one does on Windows, MacOS or Linux.
"Carpe diem" or be damned to eternal marginalisation. Oh, no need
to add that a more efficient way of computing would also almost
guarantee you the media attention you need to gain critical mass.
Otherwise no one will give a hoot on projects like Haiku, SkyOS
or whatever else is out there on the fringe.
> Perhaps this glue code can be seen as the "task logic", if by task you
> mean the use cases of the application as implemented by the author. (I
> imagine all task paths would still have to be pre-designed to some
> degree.)
The task logic, however, is open, because I may want to change
the task process to suit my needs rather than what the ISV
thought I should do when sending email or writing a document or
converting images or ripping MP3.
> Perhaps I should ask what's really bugging me.. What is a Task?.. Isn't
> it something that is primarily virtual, existing in the head of the
> user?..
Most tasks can be defined quite clearly. But as mentioned above,
tasks are flexible, and if I want to plug anoter tool into the
chain, I should be able to do just that.
Example: maybe for the next two weeks I want all incoming
faxes to be emailed to my webmail box because I am on holiday,
while a hardcopy is printed.
Example: before sending an image via email, call up the
size/quality checker to ensure it's not sent larger than it
needs to.
Example: why can't a tool developer plug a module into BeMail
that supports Macros that would grab chunks of text and fill
them in for the user, ie Java +Ctrl-E(xpand) => "Java is a
programming lanugage designed for blah blah..." Why having to
wait for the developer to implement the feature when a simple
chain element could be plugged into the process of composing
emails.
These are just two, but in general and in different areas, the
user could benefit greatly from a more flexible approach to
handling data and performing actions on the computer.
> Task-awareness would forever be like that Office clip, trying
> to sell you stuff you don't need.
Wrong.
> Or trying to push you into some kind of action pattern, much
> like the configuration wizards* we all love to hate.
Wrong.
It would be the exact opposite. It would provide you with a
predefined "path", but allowing you to change that path at every
point/joint. I forsee certain standard tasks to be delivered out
of the box, but I also forsee the vacuum of "but I need the task
to do this and that for me" to be filled very quickly. It's just
that in this case it's far more likely that even a small
developer or task-genius can help out, rather than having to wait
for the large ISV to release a new version.
> Anyway, I haven't read "the book" so perhaps there's something
> I'm not seeing.
I haven't read the book either; I'm just thinking out loud,
because computers have -even for me- not become easier to operate
- which defeats their reason for existence.
ONLY if you can spend more time with family and friends and AWAY
from the computer has it served its purpose. Until then it
remains one of mankind's largest time sinks. We can do better
than that; we just have to get off the coke and coffee-induced
stupor and start thinking and acting outside the box.
Helmar
Other related posts:
