I made an argument for writing a small cHTML or XHTML interpreter in
Java, so that you could get the benefits of HTML style "document" interfaces
while still enjoying the response and customizability of Java for building UI's
and applications.
See http://www.ai.mit.edu/people/hqm/imode/pico.html and also my flame
at http://www.ua.com/developers/hqm/docucentric.mhtml
I suppose there are really two questions:
1) HTML was nice, in the way the Macintosh GUI was nice, because all
applications suddenly had the same UI. So users could more easily
use new apps without learning a whole new command set and philosophy
for each application. In other words, the constraints of the system actually
made the user experience more consistent and productive.
2) HTML was nice,for programmers, because it let them stop
spending so much effort tweaking their UI. Well, at least initially,
now with javascript, etc, it is as bad as it ever was.
But I would also say that the keitai platform is different from the desktop
environment, because screen real-estate is so precious, that it is more
worthwhile
for the programmer to spend the extra effort making a fully custom
interface, if it
saves the user just a few keystrokes or presents a few more bytes of
information on
a screen.
But if screens continue to get bigger, moving up to PDA size (1/4 VGA) I
still think
the best integration would be writing the browser in Java, so you
can customize it if desired. Another approach would be to allow the browser
in the phone
to talk to the Java VM, so you could write servlets on the phone.
Basically, I like the HTML "document" model of user interface for a lot of
applications --
the user receives a document full of hyperlinks that he can scroll through
and follow
links. That still makes sense for many type of application, even on a cell
phone.
At 02:53 PM 5/17/01 -0700, you wrote:
> > [but ... java=(bigger than cHTML)!] What am I missing in here?
>
>Somebody mentioned it a couple of days ago in this forum -
>there's (apparently) no integration between the Java VM and
>the built-in i-mode browser. Not surprising, east vs. west.
>
>I guess what's being described here is an iAppli that acts
>as a web cache. Catch this though - the cached cHTML looks
>'similar' to the original i-mode HTML! 'Similar' says to me
>another rasterizer (+ui) is being used, see above.
>
>Something must be lost in the 'focuses a function of converting
>the user interface'. ;]
>
>-chris
>
>Mika Tuupola wrote:
> >
> > On Thu, 17 May 2001, Juergen Specht wrote:
> >
> > > -- Fujitsu Ltd. and TurboLinux Japan KK said they are releasing
> > > the beta version of a jointly developed tool which converts
> > > Compact-HTML codes for i-mode into i-mode-based Java source codes.
> > >
> > > This version focuses a function of converting the user interface.
> > > One page of HTML will be converted into a Java program that produces
> > > a similar display image on the i-mode screen.
> >
> > Errr... Now whats the point? I could imagine the the on the fly
> > generated javacode is larger in the bytes than what the
> > chtml page would be.
> >
> > If you combine the size of the browser and the chtml page
> > the resulting size in bytes is larger though so this would
> > make sense only with phones who dont have browser but can
> > run Java.
> >
> > What am I missing in here?
> >
> >
> > --
> > Mika Tuupola http://www.appelsiini.net/~tuupola/
> >
> > [ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
>
>--
>Christopher Lowery - software designer - ephemerist
> .--. .--. .--. ,--, .--,
> |`.--. |`--+ +--+ +--'| .--,'|
> `|__| `|__| |__| |__|' |__|'
> www.onegoodwindow.com/graphics-hut - 1admw.com (wap)
>
>[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
[ Did you check the archives? http://www.appelsiini.net/keitai-l/ ]
Received on Fri May 18 05:41:26 2001