I don't necessarily agree with that article. The supporting idea of
do-the-UI-then-the-underlying-infrastructure is that when making the UI
sometimes things messed up. That just means that the task of making the
UI is "incomplete", not that the paradigm is wrong.

By making the UI and then the underlying structure, I see 2 problems:
1) any new addition to the UI means complete update of the
infrastructure, which IMHO is a pain and an incovenience (poor
scalability) That is the whole point of using abstraction. I mean, we
could write the whole kernel in a huge big file, for all we care.
2) UI complexibility defines infrastructure sophistication. If you want
your user to have a simple, easy UI, then you infrastructure will lose
its customability (which is one of the main strenghts that Linux has).
On the other hand, if you want to make your software to have lots of
options and different settiungs, then the UI becomes a surreal
nightmare.

You would lose all the features that abstraction has (ease of update,
scalability, customization) only because of fear of problems in the
synchronization of your UI with the underlying system, while a good job
at designing the UI and the system would make that easier.

We need to understand that due to the fact that most Linux software is
Open Source (in other words, there is no one entity orchestrating the
development of it), of course we are bound to run into compatibility
problems once in a while. That why Apple computers don't have that many
problems in that area: there are so few people developing for Macs that
it is a lot easier to make sure that everything fits together seamlessly
(and that is the reason of why the only games for Macintosh are
Breakout, Super Breakout, and... Photoshop)

-Chris Alvarez


Chris Alvarez
[EMAIL PROTECTED]
ext. 1-3837
IS&T Web Applications Services
Novell, Inc., the leading provider of information solutions
http://www.novell.com

>>> [EMAIL PROTECTED] 07/21/04 12:46 AM >>>
A while ago I was complaining on #utah about how the way we use
computers typically is flaw.  I mentioned  how MS and others are trying
to abstract away the complexity of the underlying system, while still
forcing you to deal with that complexity (ie when things break you have
to go through the registry or the file system).

This slashdot comment has some interesting comments on this very subject
and makes the interesting point that abstraction is often a bad thing. 
Instead we should make the underlying system simpler, more robust, and
less breakable:

http://slashdot.org/comments.pl?sid=115172&cid=9756869

What do you all think?

Michael

-- 
Michael Torrie <[EMAIL PROTECTED]>

____________________
BYU Unix Users Group 
http://uug.byu.edu/ 
___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list


____________________
BYU Unix Users Group 
http://uug.byu.edu/ 
___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list

Reply via email to