Evolution from web to desktop?
Ricky Clarkson
current spate of evolution of web development ultimately bring us back
to desktop development, albeit with some changes?
Clay observed that the focus is switching from server-side frameworks
to client-side frameworks. Google Gears (which I realise is going to
be replaced by Web Storage) gave applications the ability to store
data locally. JavaScript has been beefed up in terms of performance
to presumably be competitive with conventional desktop languages.
I'll imagine a couple of steps that could follow this:
1. Browsers start to allow other languages than JavaScript to run
code in web pages, in response to (my imagined) demand from businesses
to allow such code to be distributed as binary.
2. Browsers add yet more features that are traditionally the domain
of desktop apps, e.g., drag and drop between web pages or from native
file managers to web pages, clipboard access, CD/DVD/Blu-Ray burning,
printing, access to areas of the hard drive, managing their own window
positions and sizes.
3. The browser disappears into the OS (see Google Chrome OS), such
that there is no visible difference between running a desktop app and
a web app; the only real difference is that the desktop app can write
to anywhere the user can and requires installation but the web app can
only write to its own storage area or anywhere the user explicitly
gives it access to.
4. OSs allow desktop apps to sandbox themselves like web apps are,
and allow silent installation (java-web-start style) and update of
desktop apps that declare themselves 'sandboxable'.
5. Nobody gives a monkey's whether your app is a desktop or a web app
anymore, the difference is the toolkits you use to create the app
rather than what it can do.
What do you think?
Casper Bang
keyboard accelerators! It's darn right impossible to build enterprise
apps that's optimized for data processing that runs across any browser
and/or language. So I would say, for your vision to hold true, we have
to fix that part. It's scary how little focus that topic has
considering the implication, but I guess it's just not a very sexy
feature.
Stephen Haberman
> I think you are on to something... with one caveat: Browsers SUCK for
Agreed! The sooner the better. Really surprised it hasn't been solved
by now.
- Stephen
CKoerner
On Nov 4, 12:38 pm, Stephen Haberman <stephen.haber...@gmail.com>
wrote:
Reinier Zwitserloot
libraries / frameworks out there that let you write a desktop app in
the form of servlets and templates / static HTML/js/css files, and
some hooks for app startup, shutdown, and some interaction for the
very minimal "chrome" (UI elements) on the window edges, and then
packages it up for you into a single executable which, when run, opens
a webkit / gecko embedded browser, starts up an internal server, and
makes it "just work".
Something like iTunes (the music store part runs on HTML, or so I
hear), or Steam (which is all HTML running on top of an embedded
webkit).
As far as I know no such tool is available for java, nor for python,
ruby, or the CLR. Personally I'd say such a desktop environment would
easily be far nicer to write in than swing, and has the considerable
advantage that you can share a lot of code between this desktop
version and a web-based app. You also can use all the latest and
greatest HTML5 features, because you know exactly what kind of browser
you end up running on (though this conflicts with the "hey, I can turn
this into a webapp in a snap" idea).
JamesJ
What if...
Javascript and HTML 5 were to morph or were implemented over a
"foundation language", which had a common specification and test suite
across browsers. The "foundation language" could be made for it's
portability and the common building blocks to support higher language
features. Then other languages could be ported to run on the new
foundation. (I.e. in the spirit of the JVM, but only for client-side,
and controlled as a public standard, maybe call it HTML6) Java
suffers from too much control to ever really full fill this need
across platforms. It will only really happen when the entities behind
the browsers do it together. HTML5 seems to be way closer to this
than at any other approach in the past. Maybe the momentum will keep
going?
Adobe seems to get this, they keep writing good stuff that builds on
top of the stuff others offer, along side their own solutions.
Why not client side Ruby, Java, Groovy, Clojure, Scala etc. along side
JavaScript all running on the VBM (virtual browser machine, or keeping
in the spirit of a few of last pod casts you could misinterpret this
as , violent, bm).
This would require way too much coordination between companies all set
on dominating the digital world to really happen. But ahhh, wouldn't
be nice to have client side, write once, in your language of choice,
run on anything that supports a browser.
ADRA
> Why not client side Ruby, Java, Groovy, Clojure, Scala etc. along side
> JavaScript all running on the VBM (virtual browser machine, or keeping
> in the spirit of a few of last pod casts you could misinterpret this
> as , violent, bm).
will either end up with lobotomized implementations of these languages
(like what Microsoft did with all .NET languages), or you end up with
a huge surface for remote attacks. Can my java apps run Swing, AWT,
Sockets, File IO, JNI? If so what dictates the permissions model? If
not, can you really (not legally, but philosophically) call it Java?
For example, I believe that VB died at 6.0 and some other language was
born with the same name later on. You may call it Java, and it may
basically have the same syntax, but that doesn't make it Java.
> This would require way too much coordination between companies all set
> on dominating the digital world to really happen. But ahhh, wouldn't
> be nice to have client side, write once, in your language of choice,
> run on anything that supports a browser.
enough. Imagine trying to strong arm Microsoft or Apple into natively
supporting language bindings for Java, Ruby, etc?? It will not happen.
Its not in their interests and in fact it would probably hurt their
proprietary platform development efforts.
From Reinier:
> hear), or Steam (which is all HTML running on top of an embedded
> webkit).
that there are pieces of code that can be reused over the true web
interface. Both examples cannot exist without an internet connection
and cannot function without them. The same code running the web site
is also power the client web browser engine. At least the steam
version is not being served from the local application. There is
possibly a little extra sugar into the steam HTML that allows for very
simple primitive integration with the rest of the steam application,
but make no mistake, there is still a ton of native code in steam and
iTunes (I don't use the store, just the app, so I can't say anything
about how itunes or its store work with web pages). They are not
defacto portable in themselves, though it may simplify porting for
specific areas of development.
Positives:
1. Code reuse between the web page presenting the data and the
integrated application means less coding and redundant work
2. Slightly easier time porting the application to other platforms
(assuming the web engine of choice exists on all said platforms)
3. Easier to work with for experienced web developers
Disadvantages:
1. Non-native feel -- Steam looks fine in general, but when you go to
the web interface, you KNOW you're not running natively. In the old
steam days I always giggled when I could right click and bring up the
embedded IE's context menu.
2. Poor / difficult bindings with the rest of the system -- Unless
you're truly writing an application from scratch on a system (assuming
there was a an RCP HTML shell engine available) you will always need
to worry about the web interface hooking back into the host
application. I think steam gets it done using steam:// uri handlers
and maybe some other magic, though I'm really not sure. That context
shift really means a friction in interacting between the two layers of
code on the platform. The web interface works well for Value because
most of the web interface is mostly self-encapsulated. There is very
little interaction between stream the windows client and the web site
that is hosted from within the windows steam client that making and
supporting these bindings was simple since there weren't many to be
made. Do I believe that steam will eventually be a big webkit GUI with
widgets and pages hosted from a local mini-server? I doubt it, but
stranger things have happened. Even then, the run-time that would
enable that would need a ton of systems access that one would never
give to standard web browsers or cookie-cutter browser hosted local
apps.
3. Basically no 'desktop integration' which one assumes is necessary
since you wish to write a 'desktop application' using web tech. The
caveat being as in the steam case where they use bindings to escape
into a native layer for processing things which that cannot be done in
HTML. As expressed in the previous point, this is not as straight
forward as people may hope.
Prediction: In 2012 the holy war over which RCP web engine of choice
to run will be in the latest thing. If in fact this technique does get
popular, not all will be portable despite the hope. You'll have a
strata that will look and perform really well on specific platforms or
for very specific purposes, and there will be others that are so jack
of all platforms that you may as well call them web browsers (with the
limited integration that goes along with it). It'll be just another
layer of frameworks that everyone will have to learn 3 of.
Steven Herod
The technical direction of the desktop will be shaped by the skill
set.
If 'most of' the world knows CSS / JS / HTML etc, then it's going to
drive the technical direction, and what ever short comings that are
currently in these platforms will be eventually corrected.
Vince O'Sullivan
> The technical direction of the desktop will be shaped by the skill set.
>
> If 'most of' the world knows CSS / JS / HTML etc, then it's going to
This first point may well be true...
>, and what ever short comings that are
> currently in these platforms will be eventually corrected.
Ricky Clarkson
True dat. You presumably need the community to be skilled in a more
low-level language too. E.g., Python attracts a lot of C programmers,
because/so there are lots of native libraries wrapped to be used in
Python.
Most Java programmers simply don't have the C++ skills, as far as I
have seen, to hack at the JVM itself, for example. I'm sure as good
software engineers we could do it if we needed to, but we'll generally
avoid it if possible.
Matthew Farwell
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Kevin Wright
Kevin Wright
mail / gtalk / msn : kev.lee...@gmail.com
twitter: @thecoda
Carl Jokl
lines as I have been thinking too for some time. Albeit I am not sure
if it will happen.
Considering Flash, Java and .Net amongst others all have some kind of
Virtual Machine. It would be good it the "JavaScript" engine were a
virtual machine too supporting some kind of bytecode. This means that
it could be targeted by any compiler which could compile to that
bytecode.
In terms of supporting all the languages. Support for the languages
may not be so much of the issue. It is really a matter of the API's.
Saying that something cannot be called Java because it doesn't support
the whole JavaSE API set may not be a fair statement. We already have
had JavaME which is branded as "Java" but only supports a much more
limited set of APIs which are suited to that platform.
In that case would it not be reasonable then to have a JavaWE (Web
Edition) or JavaBE (Browser Edition), such that the APIs are limited
to just those which are supported currently by JavaScript.
Needless to say JavaScript doesn't support anything like the rich
functionality that Java or .Net do but surely you have to start
somewhere. If broad support for the browser VM came into place then
expanding the functionality could be done bit by bit via the W3C. In
the case of things like Flash, JavaFX and Silverlight it may be that
the functionality needed for those could be provided by loading
additional libraries beyond the core "Browser JM Libraries" to provide
that functionality.
The aspect that could make it interesting is the prospect of
seamlessly pass objects from server to client back to server the way
thick clients have been able to such as with RMI, RPC, CORBA etc.
Steven Herod
> ...but there's no reason to believe the latter. Look at Java.
Apple, MSFT and Google all innovating like crazy with Firefox
foundation rounding out the pack.
People are building server side stuff in javascript (node.js) which I
view as either madness or curiosity, so I wouldn't say never.
I just thing technology goes where the numbers are - an none of this
is innovation, sometime in the future someone is going to announce a
deeply embedded web technolgy based desktop stack with all the
sophistication and convenience of Delphi, circa 1995. (But with
Webness)
Casper Bang
hypermedia system, and the associated ability to link and being
addressable. And you already can do windows without toolbar, statusbar
etc. and using i.e. GWT (history iframe) you can specifically target/
control back/undo experiences. Disabling navigation/history completely
makes me think of Flash/Silverlight/Applets and various amputated
experiences (i.e. Parley's client).
Dominic Mitchell
The elephant in the room, with regards to moving application onto the web is:What do you do when your train goes through a tunnel?
-Dom
Kevin Wright
--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Alexey Zinger
From: Carl Jokl <carl...@gmail.com>
To: The Java Posse <java...@googlegroups.com>
Sent: Fri, November 5, 2010 6:16:13 AM
Subject: [The Java Posse] Re: Evolution from web to desktop?
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
Carl Jokl
Describing JavaScript as bytecode is nonsense.
1) It is not a binary format.
2) It is not close to machine code.
Yes the different browsers are putting in features like JIT for
JavaScript, the problem is that each JavaScript engine is doing things
in its own way.
JavaScript was intended as s glue language just like Visual Basic.
Both have ended up being used to try and solve problems for which they
were not well suited.
I for one and I think other developers also would be happier if they
could target the browser scripting engine using a more powerful
language than JavaScript. At the moment there is no way to write to
the scripting engine directly bypassing the JavaScript language. That
is where a 'real' bytecode system would come in.
On Nov 5, 2:59 pm, Alexey Zinger <inline_f...@yahoo.com> wrote:
> JavaScript already is running in a JIT-enabled VM with the same bells and
> whistles managed code developers are used to. What it doesn't have is type
> safety, so you can effectively think of JavaScript as your medium of
> distribution -- bytecode. It just happens to be human readable, so a lot of
> people write it by hand. But you can just as easily have a tool that "compiles"
> your strongly typed language into JavaScript, package it for distribution with
> some limited compile-time optimizations and rely on the client-side VM to do the
> rest. This is exactly what GWT does.
>
> Alexey
>
> ________________________________
Alexey Zinger
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
Carl Jokl
JavaScript.
How many people here develop with JavaScript because they really like
and enjoy using JavaScript?
How many people here develop with JavaScript because they have no
other choice?
I wish there was a bytecode which could be targeted by compilers. To
make that work would require all the browser vendors to agree on that.
There are existing bytecode formats which would be useful to reuse.
That gets into a political problem where both Microsoft and Oracle can
be sue happy and someone using just the bytecode / JIT part of the
platform without taking the rest could lead to upset. I also think the
Browser developers might have misgivings about incorporating such a VM
into their browser (a bit of 'not invented here' syndrome).
It would be great if it happened. I just don't think it will without a
lot of pressure from some big entity.
Fabrizio Giudici
> With all due respect JavaScript is Source Code and not byte code.
> Describing JavaScript as bytecode is nonsense.
>
> 1) It is not a binary format.
> 2) It is not close to machine code.
doesn't ever make sense, the Java bytecode isn't.
> Yes the different browsers are putting in features like JIT for
> JavaScript, the problem is that each JavaScript engine is doing things
> in its own way.
> JavaScript was intended as s glue language just like Visual Basic.
> Both have ended up being used to try and solve problems for which they
> were not well suited.
> I for one and I think other developers also would be happier if they
> could target the browser scripting engine using a more powerful
> language than JavaScript. At the moment there is no way to write to
> the scripting engine directly bypassing the JavaScript language. That
> is where a 'real' bytecode system would come in.
In spite of the premises, I agree with you! But to me it's clear that
since fifteen years up to today we've been moving on the IT world by
patches and kludges. Every time that there is just the 1% of problems to
fix (because Java has got it all, since its inception, but there's that
1% missing that creates problem), instead of focusing on fixing that
(which is possible), we declare the thing 'dead' and decide to restart
from scratch. Here we are, now, with JavaScript reinventing the wheel
for the n-th time. Let's go with JQuery and REST; of course, before
resolving all the problems that exist with these approaches, when we'll
get to that infamous 1% somebody will pull another rabbit out of his
hat, and we'll restart from scratch again. This is the cirque du
technologie today. Fortunately, sooner or later, we retire and/or die...
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
Alexey Zinger
Subject: [The Java Posse] Re: Evolution from web to desktop?
Carl Jokl
code implies to me a binary format. If it is not intended to be read
and be delivered over the internet it would make sense to use a binary
format. After all this code is being produced by a complier and not by
hand. Bytecode systems are generally intended to be produced by tools
and compilers and not written by hand.
I would not call anything based on text 'bytecode' which does program
logic I would call it just 'scripting' or a 'script'.
I am sorry if I am mistaken about Java bytecode not being close to
machine code but I am just going on what I was told which may be
incorrect. I have not got hardcore enough to read / write raw bytecode
yet.
Mark Volkmann
> Doing things the current way still leaves you forced to use
> JavaScript.
>
> How many people here develop with JavaScript because they really like
> and enjoy using JavaScript?
> How many people here develop with JavaScript because they have no
> other choice?
It seems to me that this view of JavaScript comes mainly from people
that have used JavaScript in the past and disliked it due to seeing
lots of badly written code and issues with the DOM API. I've yet to
hear someone that has read the book "JavaScript: The Good Parts" say
they still think JavaScript is a bad language ... unless they dislike
all dynamically typed languages.
--
R. Mark Volkmann
Object Computing, Inc.
Carl Jokl
that the compiler can catch a lot of mistakes at compile time in a
statically typed language. I can appreciate many like dynamically
typed languages. What is annoying at the moment is that people simply
have no choice. If the scripting engine provided an intermediate
format that compilers could target then developers could use what they
prefer.
Mark Volkmann
> I must confess I am not so fond of dynamic typing. I like the fact
> that the compiler can catch a lot of mistakes at compile time in a
> statically typed language.
I understand that. There are excellent arguments for using both static
and dynamically typed languages. I think we've all heard them by now.
No point rehashing them. People that feel strongly about using
strongly typed languages are not going to like JavaScript.
> I can appreciate many like dynamically
> typed languages. What is annoying at the moment is that people simply
> have no choice. If the scripting engine provided an intermediate
> format that compilers could target then developers could use what they
> prefer.
More choice would be good, but I don't see it happening. Most people
won't use a new browser-supported programming language unless it is
supported by at least IE, Firefox, Chrome and Safari. It's hard to
imagine the groups that control those browsers agreeing on a new
language to support.
Ricky Clarkson
down that road!
I don't see what's so bad about having JavaScript as a compilation target.
> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
Carl Jokl
change. At least if some bytecode system was available new languages
could be used which don't need to have existed at the time bytecode
was added to the browser as long as the compiler of that language can
target the bytecode.
Perhaps it is pointless making the point because I don't see realistic
prospects of getting all the browser creators to agree on providing
this nor making all the implementations compatible.
Never mind though. HTML 5 is going to fix everything, so I am told. I
will just sit back and watch HTML 5 heal all the problems with web
development.
Fabrizio Giudici
> You say "bytecode does not need to be binary" but the whole name BYTE
> code implies to me a binary format. If it is not intended to be read
> I would not call anything based on text 'bytecode' which does program
> logic I would call it just 'scripting' or a 'script'.
I strongly disagree. A "script" is something that it's still totally
human readable and must be interpreted or precompiled by the executor. A
bytecode is something that needs a lower level processing to be run (not
that it's not ready to be run, since hotspot does a lot of things). So,
JavaScript fits for me in the bytecode category, especially if you look
at the one greatly optimized and 'squeezed' by GWT (which, in fact, is
no more human readable). I agree that JavaScript is not 'pure' bytecode,
but it can be considered 90% like that.
The real point is that 'real' bytecode has been designed with a specific
purpose, and JavaScript-as-bytecode is being repurposed. But as I said,
the whole web thing has been repurposed. Of cours,e I strongly prefer
things that has been designed for a purpose, rather than things that
have been repurposed... that's why I don't like JavaScript.
As a language, I don't like dynamic stuff (if not by specific things).
And if I have to move away from Java, I really want to see something
newer, not a thing as old as Java.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudic thei - www.tidalwave.it/people
Fabrizio...@tidalwave.it
Rob Ross
On Nov 5, 2010, at 2:52 AM, Matthew Farwell wrote:
> For me, the main advantage of using a browser for RIA is you don't need to install anything on client machines. However, there are a couple things that always irritate me when I'm doing RIA for clients, as opposed to a traditional application.
>
> Please note that I'm not talking about public web sites, I'm talking about internal applications that are not exposed to the public. So please don't respond 'I wouldn't want this to happen on my browser', it's not going to happen on your browser. You will never see this application, you won't even know it exists.
>
> 1) Disabling navigation/back button functionality. This gets me every time. I NEED to be able to prevent the user from going back a page. No discussion, no 'You should educate the user not to do that'. Taking firefox as an example, you can go back a page in (at least) three ways: backspace, click on the back button, right click on the page. That means I have to somehow prevent the user from doing these three things. And not counting refresh, multiple submits and preventing them from entering a different URL. What is needed is the option to disable navigation. Full stop.
No, you are doing it wrong. This is NOT how a web page is supposed to work, whether on a corporate LAN or via the Internet at large.
I ** HATE ** it when web apps try to get around the fact that they are web apps by playing little tricks like hiding the menu or trying to disable the back button.
I'd suggest if you *really* need to do this, HTML is the wrong tool for the job you are trying to do. Write a real desktop application for god's sake, in Swing for example. Not every problem can be solved by HTML!
Rob
Rob Ross
On Nov 4, 2010, at 11:21 AM, Reinier Zwitserloot wrote:
> I'd love to believe it. I'd be somewhat more convinced if there were
> libraries / frameworks out there that let you write a desktop app in
> the form of servlets and templates / static HTML/js/css files, and
> some hooks for app startup, shutdown, and some interaction for the
> very minimal "chrome" (UI elements) on the window edges, and then
> packages it up for you into a single executable which, when run, opens
> a webkit / gecko embedded browser, starts up an internal server, and
> makes it "just work".
>
> Something like iTunes (the music store part runs on HTML, or so I
> hear), or Steam (which is all HTML running on top of an embedded
> webkit).
>
> As far as I know no such tool is available for java, nor for python,
> ruby, or the CLR. Personally I'd say such a desktop environment would
> easily be far nicer to write in than swing, and has the considerable
> advantage that you can share a lot of code between this desktop
> version and a web-based app. You also can use all the latest and
> greatest HTML5 features, because you know exactly what kind of browser
> you end up running on (though this conflicts with the "hey, I can turn
> this into a webapp in a snap" idea).
I think Swing is a pretty great environment for writing desktop apps, but that comes with lots of practice.
I find it highly amusing that people are bemoaning how hard it is to write desktop apps in an HTML browser.
Well DUH. It was never designed for that purpose. It is designed to display marked-up text. Period. Everything else has been bolted on with staples and duct tape.
If you want to write a desktop application, use a desktop application framework like Swing or SWT (in the Java world), or Qt if you want to go mostly-native but a little cross platform. Or if cross platform is not an issue at all, use Cocoa on the Mac and/or .Net on Windows.
I think maybe the reason there's so much effort to turn the browser into something it was never meant to be is that like all humans, people tend to stick with what they know, and don't want to invest the mental energy into learning new frameworks (like Swing) that have already solved all these problems.
Rob
Dominic Mitchell
Doing things the current way still leaves you forced to use
JavaScript.
How many people here develop with JavaScript because they really like
and enjoy using JavaScript?
I certainly do. The popularity of tools like node.js show that I'm not alone either.
How many people here develop with JavaScript because they have no
other choice?
There are lots of other choices for browser based development. GWT. Flex. C++, if you want to go the native plugin route.
I wish there was a bytecode which could be targeted by compilers.
Are you an ASN.1 person by any chance?
To
make that work would require all the browser vendors to agree on that.
There are existing bytecode formats which would be useful to reuse.
That gets into a political problem where both Microsoft and Oracle can
be sue happy and someone using just the bytecode / JIT part of the
platform without taking the rest could lead to upset. I also think the
Browser developers might have misgivings about incorporating such a VM
into their browser (a bit of 'not invented here' syndrome).
It would be great if it happened. I just don't think it will without a
lot of pressure from some big entity.
This is a nearly fantastical viewpoint. What do you think the installed base of browsers is worldwide? At a guess, I'd say well over a billion. Look at the hard time that people are having already rolling out new features like CSS3 (which are simpler than new VMs). Do you seriously think the investment in a new VM would be able to pay for itself? How long would it be before it was deployed to a wide enough audience to be usable?
And don't forget that Microsoft already tried this with VBScript. It was an utter failure.
-Dom
Mark Volkmann
>
> I think maybe the reason there's so much effort to turn the browser into something it was never meant to be is that like all humans, people tend to stick with what they know, and don't want to invest the mental energy into learning new frameworks (like Swing) that have already solved all these problems.
Maybe that's the reason for some people. However, for many I think the
reason is simply that they want the deployment characteristics of web
apps and also want a rich UI. So we do the best we can with the tools
we have today and hope that HTML 5, CSS 3, ECMAScript 5, JavaScript
libraries (like jQuery), GWT, and so on will make this doable and will
continue to improve.
Reinier Zwitserloot
iTunes. But the *GUI* is *ALL* html/css/js. It's also true that both
require the internet to function, but there is absolutely nothing
stopping you from having the embedded webkit access servlets running
in the same process space as the webkit itself. With a very simple
tweak to the webkit's URL scheme resolver, you can even do this
without opening any TCP ports, routing it all in-process. Just because
(AFAIK) no app exists that uses this scheme doesn't make it
impossible, and doesn't make it a bad scheme. I'd use such a thing in
a heartbeat to build all my future desktop GUIs. Sure, it won't be
portable by default, but porting relevant sections between the web and
this app will be very simple.
The non-native feel bit: Well, yeah, but, the web certainly doesn't
suffer from this. On the contrary, your average modern web app has
_vastly_ better user interface design than your average modern desktop
app. Also, the more complicated modern desktop apps seem to reinvent
the UI wheel anyway - photoshop hardly looks native. Neither does the
Microsoft Office suite, even. That should tell you all you need to
know about the value of looking like the rest of the OS (i.e: very
overestimated). I've also seen plenty of web apps that manage to
recreate the look of a certain OS rather well. I ascribe to the theory
that either (A) you lock the UI look down so its the same across all
invocations of an app, or (B) the UI is shit. In java, I always
strongly suggest to set the LnF to something specific, and most apps
do. The pipe dream of writing an app once and having it magically look
"native" on all platforms the VM runs on is worthless. So, on this
point, I emphatically do not agree. Non-native feel is a non-issue.
Note also that *ALL* "RIA" schemes (javaFX, AIR, and Silverlight)
haven't really gone the native LnF route either, so evidently I'm not
the only one that has come to this conclusion.
Poor bindings: That's spanning the cart in front of the horse, isn't
it? I see no technical reason for why an embedded webkit + servlet
packaging tool has to use awkward stream URI handlers. If you feel the
steam UI is badly built (and its certainly not great, I'll gladly give
you that), that's probably the fault of Valve, not of the concept.
Take for example Firebug on firefox: It looks fantastic, integrates
extremely well with firefox, and yet its mostly written in js, html,
and css.
What kind of interaction are you thinking of? Drag and Drop? Check out
Mailplane for the mac. It runs gmail in a custom browser window and
fully supports just about everything you expect from a mail client,
and such clients really push the envelope on OS interaction: You can
drag and drop files, you can register mailplane as the handler for
'mail:' URLs and other send email requests, and when such a request
includes a subject and a 'to', etc, it's all filled in for you in a
new actual window that is showing the gmail new message page. It does
offline too, seamlessly, and takes care of logging in for you. It also
ships with a little badgy thing (similar to the notification icons at
the bottom right on a windows machine) which shows a count of unread
messages and which you can click to quick-open new mails. Mailplane is
also integrated with growl (a mac notification thing that pops up
little boxes when things happen), and clicking on such a growl
notification opens mailplane and loads the email. It's perfect.
In other words, your points 2 and 3 are just flat out wrong; Mailplane
proves it.
I think the mistake you're making is thinking that an app is a
mishmash of everything it does. You have a GUI which is entirely
disconnected from all the other things the platform does - you know,
the basic idea behind MVC. This is a _good_ thing. In other to let the
controller drive the GUI here and there you need some way (easier than
websockets) to force new URLs / new windows out of the webkit wrapper,
but an API for this is trivial, and as I mentioned, mailplane shows
this can be done well. You also need to hook into the OS interaction
which is primarily GUI driven, such as cross-app drag and drop,
hooking into "app responsible for opening items of type X" system
config, and possibly the copy/paste buffer. There's really not much
more than that. Want a notification badge device? Code that natively,
separate from the GUI. I'd do that even if I was writing a swing app,
because that's how you're supposed to do it. Need to, I dunno, show up
in the context menu of files when right clicked? Same deal. The
responsibility for registering that is surely not the job of the GUI
layer and therefore has nothing to do with html/css/js. The java-
written backend takes care of that. And when clicked, it sends a
message to the controller which in turn has the job of telling the GUI
layer to start rendering whatever is appropriate for that.
On Nov 5, 8:33 am, ADRA <dche...@gmail.com> wrote:
> > Why not client side Ruby, Java, Groovy, Clojure, Scala etc. along side
> > JavaScript all running on the VBM (virtual browser machine, or keeping
> > in the spirit of a few of last pod casts you could misinterpret this
> > as , violent, bm).
>
> The surface area that you're talking about is really really big. You
> will either end up with lobotomized implementations of these languages
> (like what Microsoft did with all .NET languages), or you end up with
> a huge surface for remote attacks. Can my java apps run Swing, AWT,
> Sockets, File IO, JNI? If so what dictates the permissions model? If
> not, can you really (not legally, but philosophically) call it Java?
> For example, I believe that VB died at 6.0 and some other language was
> born with the same name later on. You may call it Java, and it may
> basically have the same syntax, but that doesn't make it Java.
>
> > This would require way too much coordination between companies all set
> > on dominating the digital world to really happen. But ahhh, wouldn't
> > be nice to have client side, write once, in your language of choice,
> > run on anything that supports a browser.
>
> Having browser developers agree on HTML/CSS/JS standards are tenuous
> enough. Imagine trying to strong arm Microsoft or Apple into natively
> supporting language bindings for Java, Ruby, etc?? It will not happen.
> Its not in their interests and in fact it would probably hurt their
> proprietary platform development efforts.
>
> From Reinier:
> > Something like iTunes (the music store part runs on HTML, or so I
> > hear), or Steam (which is all HTML running on top of an embedded
> > webkit).
>
> that there are pieces of code that can be reused over the true web
> interface. Both examples cannot exist without an internet connection
> and cannot function without them. The same code running the web site
> is also power the client web browser engine. At least the steam
> version is not being served from the local application. There is
> possibly a little extra sugar into the steam HTML that allows for very
> simple primitive integration with the rest of the steam application,
> but make no mistake, there is still a ton of native code in steam and
> iTunes (I don't use the store, just the app, so I can't say anything
> about how itunes or its store work with web pages). They are not
> defacto portable in themselves, though it may simplify porting for
> specific areas of development.
>
> Positives:
> 1. Code reuse between the web page presenting the data and the
> integrated application means less coding and redundant work
> 2. Slightly easier time porting the application to other platforms
> (assuming the web engine of choice exists on all said platforms)
> 3. Easier to work with for experienced web developers
>
> Disadvantages:
> 1. Non-native feel -- Steam looks fine in general, but when you go to
> the web interface, you KNOW you're not running natively. In the old
> steam days I always giggled when I could right click and bring up the
> embedded IE's context menu.
> 2. Poor / difficult bindings with the rest of the system -- Unless
> you're truly writing an application from scratch on a system (assuming
> there was a an RCP HTML shell engine available) you will always need
> to worry about the web interface hooking back into the host
> application. I think steam gets it done using steam:// uri handlers
> and maybe some other magic, though I'm really not sure. That context
> shift really means a friction in interacting between the two layers of
> code on the platform. The web interface works well for Value because
> most of the web interface is mostly self-encapsulated. There is very
> little interaction between stream the windows client and the web site
> that is hosted from within the windows steam client that making and
> supporting these bindings was simple since there weren't many to be
> made. Do I believe that steam will eventually be a big webkit GUI with
> widgets and pages hosted from a local mini-server? I doubt it, but
> stranger things have happened. Even then, the run-time that would
> enable that would need a ton of systems access that one would never
> give to standard web browsers or cookie-cutter browser hosted local
> apps.
> 3. Basically no 'desktop integration' which one assumes is necessary
> since you wish to write a 'desktop application' using web tech. The
> caveat being as in the steam case where they use bindings to escape
> into a native layer for processing things which that cannot be done in
> HTML. As expressed in the previous point, this is not as straight
> forward as people may hope.
>
> Prediction: In 2012 the holy war over which RCP web engine of choice
> to run will be in the latest thing. If in fact this technique does get
> popular, not all will be portable despite the hope. You'll have a
> strata that will look and perform really well on specific platforms or
> for very specific purposes, and there will be others that are so jack
> of all platforms that you may as well call them web browsers (with the
> limited integration that goes along with it). It'll be just another
> layer of frameworks that everyone will have to learn 3 of.
Reinier Zwitserloot
The javascript engine in a browser is for client side stuff. There's
absolutely no need for a VM instruction set. If must avoid writing
javascript, then, well, avoid it. Tools like GWT show that you can
write in a completely different language (other than the similar
names, java and javascript are entirely different beasts), and yet end
up running on a vanilla browser install.
If you want to run an all-desktop app via browser, clearly you need
some what one might traditionally call "server side" elements here.
Possibly javascript will evolve to offer these features too but I
don't think this is a particularly good fit for that language. Much
simpler to use JS for client-side stuff, and then whatever you're
comfortable with (i.e. java, with its DB bindings, threads, file and
socket APIs, and much faster numeric math options) for the "server
side" stuff.
Reinier Zwitserloot
possibly serve as a VM substrate?
Byte code is just a name. Should we stay out of space because a
spaceship doesn't have a sailing mast? Your argument is ridiculous.
That's a
Your logical reasoning is
Reinier Zwitserloot
and javascript/html/css. The last one of that list of 4 was by far the
easiest to write in.
Alexey Zinger
But I'm not prepared to throw the baby with the bathwater just yet. Java still has some elegance left in her to fulfill much of the declarative UI syntax need. With generics, optional arguments, and static imports, a lot of this work gets easier. I'll outline some of the patterns I developed in my use of GWT, but they can be easily translated to other Java GUI frameworks (I'm doing this from memory, so I may not get some of the API names correctly, but you get the idea):
public class Util
{
public static <P extends Panel> P panel(P panel, Widget... widgets)
{
for(Widget w : widgets)
p.add(w);
return panel;
}
public static <W extends UIObject> W css(W widget, String... styles)
{
for(String style : styles)
widget.addStyleName(style);
return widget;
}
}
import static Util.*;
public class MyGui implements EntryPoint
{
public void onModuleLoad()
{
panel(
css(RootPanel.get(), "main"),
panel(
new HorizontalPanel(),
css(new InlineLabel("Hello, world!"), "helloLabel"),
css(new Button("click me"), "button");
);
}
}
Subject: [The Java Posse] Re: Evolution from web to desktop?
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
Stephen Haberman
> public class MyGui implements EntryPoint
> {
> public void onModuleLoad()
> {
> panel(
> css(RootPanel.get(), "main"),
> panel(
> new HorizontalPanel(),
> css(new InlineLabel("Hello, world!"), "helloLabel"),
> css(new Button("click me"), "button");
> );
> }
> }
Reminds me of AxisPanel from [1]:
AxisPanel p = new AxisPanel()
.y().width("100%")
.x(myNorthContentPanel).css("north").q()
.x().width("100%")
.y(myWestContentPanel).css("west").q()
.y(myCenterContentPanel).css("center")
.width("100%").align(0,0).q()
.y(myEastContentPanel).css("east")
.width("100%").align(1,0).q()
.q()
.x(mySouthContentPanel).css("south").q()
.q();
I prefer UiBinder, though I can understand that before that was
available then something like this might look attractive.
- Stephen
[1] http://sonymathew.blogspot.com/2008/12/fluent-dsl-for-rich-ui.html
matthew...@gmail.com
The problem is that if I use a browser for writing desktop applications, then I have to jump through a lot of hoops just to get basic stuff like this working, just to prevent a user from doing something silly.
You said that 'This is not how a web page is supposed to work'. I agree completely. But this thread is about desktop applications. Not web pages. Two different things.
Speaking from personal experience, the clients we talk to are interested in having web/browser based applications because:
1) It makes their deployment a lot easier. All they have to deploy is a server. To update their applications, they deploy a new war. That's it.
2) The development is thought to be cheaper. Whether it is or not is a different matter, but that is how it is perceived to be.
Unfortunately, you are not my client. In general, my clients do not understand that clicking on the back button is a bad idea. They don't understand that it's a bad idea to hit backspace outside of a textbox or text area. So as a developer, I have to create code to ensure that if my client does something silly, then it doesn't screw his data.
The problem is not that web browsers were not designed for use as desktop applications. You said elsewhere that it wasn't designed for it. Agreed. The problem is that they are being used for desktop applications. I could say no to my clients, but then I wouldn't earn any money :-)
Matthew.
Reinier Zwitserloot
environment for writing desktop apps") which is either trivially true
and thus uninteresting (A browser is obviously not meant for desktop
apps), or which you haven't backed up (if we funge the definition of
browser a smidge to include embedded geckos and webkits). I'll
highlight the parts where you're just making unsupported statements:
On Nov 5, 9:42 pm, matthewjfarw...@gmail.com wrote:
> The problem is that if I use a browser for writing desktop applications,
> then I have to jump through a lot of hoops just to get basic stuff like
> this working, just to prevent a user from doing something silly.
An embedded webkit can easily be configured to disable the back button
and doesn't normally have one in the chrome unless you specifically
put it there. However, the web model basically dictates that the back
button should work and should do sensible things, it's part of what
makes the UI of web apps far superior to non-web based desktop apps -
as any user interface expert can tell you, undo beats the pants off of
"are you sure" dialog boxes, or no way to revert, any day. The back
button is 'undo' for navigation. When ajax is involved, managing
history is a real pain on browsers, especially older ones, but if we
are allowed to handwave an entire platform away for a single flaw, let
me buy some new batteries for my wireless keyboard; I'm sure I'm going
to exhaust the current ones if I'm going to list all of the silly
things swing makes you do just for basic stuff to work. Look at the
bigger picture; don't get hung up because there's a single flaw that
annoys you. Especially a flaw that can be fixed pretty much outright.
There's a bit of miscommunication in this thread, in that some are
talking about deploying a webapp to a vanilla browser (and usually, in
a way that works amicably on all major ones), vs. deploying a desktop
app as a desktop app, but using a largely hypothetical java-based
platform that involves an embedded webkit, a few hooks to manage the
chrome and GUI/OS interaction, and a servlet runner of some sort.
When deploying to a vanilla browser I still say a webapp is generally
a far better plan than a swing app, but obviously there are far more
corner cases where a web app clearly isn't going to work. Something as
simple as local file interaction isn't even possible, so if you need
that, clearly "webapp" is not a good direction to take. That goes
without saying, or, at least, I assumed so. When the case isn't as
clear, though, web apps win. Just look at the state of IT 2010.
> You said that 'This is not how a web page is supposed to work'. I agree
> completely. But this thread is about desktop applications. Not web pages.
> Two different things.
> Unfortunately, you are not my client. In general, my clients do not
> understand that clicking on the back button is a bad idea.
client.
Rob Ross
On Nov 5, 2010, at 3:21 PM, Reinier Zwitserloot wrote:
> You are positing a declaration ("A browser is not a suitable
> environment for writing desktop apps") which is either trivially true
> and thus uninteresting (A browser is obviously not meant for desktop
> apps), or which you haven't backed up (if we funge the definition of
> browser a smidge to include embedded geckos and webkits). I'll
> highlight the parts where you're just making unsupported statements:
>
> On Nov 5, 9:42 pm, matthewjfarw...@gmail.com wrote:
>> The problem is that if I use a browser for writing desktop applications,
>> then I have to jump through a lot of hoops just to get basic stuff like
>> this working, just to prevent a user from doing something silly.
>
> "basic stuff like this" - what are you referring to? The back button?
> An embedded webkit can easily be configured to disable the back button
> and doesn't normally have one in the chrome unless you specifically
> put it there. However, the web model basically dictates that the back
> button should work and should do sensible things, it's part of what
> makes the UI of web apps far superior to non-web based desktop apps -
> as any user interface expert can tell you, undo beats the pants off of
> "are you sure" dialog boxes, or no way to revert, any day.
Uhm, maybe a really bad interface expert would say that. "Back" implies you have navigation state, which is something the user now has to remember. It introduces modality into the human-computer interaction, and that always increases the cognitive load on the user.
Modal apps like Web UIs, Dialog Wizards, etc, are harder to use than non-modal apps. For example, iTunes is a great non-modal app (not the *store*, the player.) I find a song by searching. I double click to play. I can hit stop to stop. There's basically just one UI screen to interact with. No navigating required.
Then when you do go to the store, that introduces the Web paradigm into the mix, and complicates things again. I'm a savvy, experienced computer user and even *I* sometimes get lost when I'm navigating the iTunes store.
I'm not saying there is no place for modality in apps, just that it should be avoided when possible, and it introduces extra complexity. Modal navigation is NOT something a good UI expert would ever recommend, and certainly is no evidence that the Web paradigm is "superior" to desktop apps. Now you're just being silly.
> When deploying to a vanilla browser I still say a webapp is generally
> a far better plan than a swing app, but obviously there are far more
> corner cases where a web app clearly isn't going to work. Something as
> simple as local file interaction isn't even possible, so if you need
> that, clearly "webapp" is not a good direction to take. That goes
> without saying, or, at least, I assumed so. When the case isn't as
> clear, though, web apps win. Just look at the state of IT 2010.
Sure, you have your Web-tools hammer and by god you see nails all around. Even when a screw or a rivet might be the better tool for a particular case.
Rob
Rob Ross
On Nov 5, 2010, at 1:42 PM, matthew...@gmail.com wrote:
> And this is precisely the point that I was trying to make. A browser is not (currently) a suitable environment for writing desktop applications. But the problem is not HTML. HTML is markup, and is perfectly fine for what I need to do.
>
> The problem is that if I use a browser for writing desktop applications, then I have to jump through a lot of hoops just to get basic stuff like this working, just to prevent a user from doing something silly.
>
> You said that 'This is not how a web page is supposed to work'. I agree completely. But this thread is about desktop applications. Not web pages. Two different things.
>
> Speaking from personal experience, the clients we talk to are interested in having web/browser based applications because:
>
> 1) It makes their deployment a lot easier. All they have to deploy is a server. To update their applications, they deploy a new war. That's it.
You could have just as simple a deployment situation with a client-server Swing app, deployed via JNLP. You deploy your app to a single HTTP server, and that's it.
In the simplest case of "pure" client-server, all your business logic is in the client, and your back end is a "dumb" database. You can still use ORM tools like Hibernate to simplify data access.
A 3-tiered model introduces a bit more complexity, but it's not too hard to manage. Your client and server code are now separate, so you have a War and a JNLP bundle to deploy. But the backend can continue to use Hibernate, and the front end can call RESTful web services on the application server, and leave all the business rules on the server.
Rob
Cédric Beust ♔
Uhm, maybe a really bad interface expert would say that. "Back" implies you have navigation state, which is something the user now has to remember. It introduces modality into the human-computer interaction, and that always increases the cognitive load on the user.
Modal apps like Web UIs, Dialog Wizards, etc, are harder to use than non-modal apps. For example, iTunes is a great non-modal app (not the *store*, the player.) I find a song by searching. I double click to play. I can hit stop to stop. There's basically just one UI screen to interact with. No navigating required.
Cédric
Rob Ross
On Nov 5, 2010, at 10:03 PM, Cédric Beust ♔ wrote:
>
>
> On Fri, Nov 5, 2010 at 3:52 PM, Rob Ross <rob....@gmail.com> wrote:
>
> Uhm, maybe a really bad interface expert would say that. "Back" implies you have navigation state, which is something the user now has to remember. It introduces modality into the human-computer interaction, and that always increases the cognitive load on the user.
>
> That's a nice academic explanation, but I don't think it applies to the real world.
>
> For having been sitting in many, many usability lab sessions behind a one way mirror, I can tell you that the Back metaphor is understood by a staggering amount of users from all backgrounds.
>
> It's actually reaching a point where this metaphor is leaking into non web applications, which is why you see it appear in more and more places (e.g. the Windows File Explorer, most Help systems, Android, etc...).
I think the problem is that because the Web has been so ubiquitous, its navigation model has seeped into the consciousness of millions of programmers and it affects the way they develop even non-web based applications. And once users adopt this navigation model, they need "breadcrumbs" to help find their way back and forth along the "path". The need for breadcrumbs might be a sign that an application could use a re-design. It's like covering up a bad code smell with cologne.
>
> Modal apps like Web UIs, Dialog Wizards, etc, are harder to use than non-modal apps. For example, iTunes is a great non-modal app (not the *store*, the player.) I find a song by searching. I double click to play. I can hit stop to stop. There's basically just one UI screen to interact with. No navigating required.
>
> Interesting example because I have often missed a Back button in iTunes. I'm looking at a play list, I insert a CD, switch to the Library, launch "Import to my library", and now I want to go back to the play list I was at in the beginning... and... which one was it again?
>
> With a Back button, the cognitive dissonance would actually be much lower. It's the perfect illustration of "Don't make me think".
>
> By the way, I think you are misusing the term "modality", which might be why we seem to be in disagreement on this issue.
I'm using it in the simplest possible way to describe a human/computer interaction where the human has to keep a state model in his/her head as the software is used. The simplest example is something like Photoshop, where depending on your current mode (i.e., which tool is selected), clicking an object or using the keyboard can produce vastly different results.
A more modeless example would be a simple text editor. There is no state to keep track of, as you type, your words are recorded. They're all there in front of you at one time (I'll grant the scrolling metaphor introduces some complexity), all the commands you can use to modify your document are scattered all around the periphery of your data, in menus, toolbars, and context-senstive pop-ups, etc.
A typical business web app requires either horizontal or vertical navigation through a conversation or long running transaction, where data is entered or information is assembled in discrete steps. (I'm not talking about general web "surfing" where this is not really a problem.)
When you're on page 3 and suddenly you need to go back to page one to look up something you entered there, so you can come back to page three, then you are experiencing the pain of this kind of model. And each page in the conversation looks different, buttons have moved, menus that applied to one page don't appear in another. A desktop app could be more easily designed to keep all that relevant information "together", either in space or time, and make it easier for the user to keep track of what they are doing.
Rob
Cédric Beust ♔
> By the way, I think you are misusing the term "modality", which might be why we seem to be in disagreement on this issue.I'm using it in the simplest possible way to describe a human/computer interaction where the human has to keep a state model in his/her head as the software is used.
The simplest example is something like Photoshop, where depending on your current mode (i.e., which tool is selected), clicking an object or using the keyboard can produce vastly different results.
A more modeless example would be a simple text editor.
Cédric
Rob Ross
see here: http://en.wikipedia.org/wiki/User_interface#Modalities_and_modes
specifically
"Heavy use of modes often reduces the usability of a user interface, as the user must expend effort to remember current mode states, and switch between mode states as necessary."
also:
http://en.wikipedia.org/wiki/Mode_(computer_interface)
"An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state." (Page 42)." - Jeff Raskin
Rob
> --
> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
Miroslav Pokorny
On 11/05/2010 04:14 PM, Carl Jokl wrote:Who has ever said that bytecode must be binary? "Close to machine code" doesn't ever make sense, the Java bytecode isn't.
With all due respect JavaScript is Source Code and not byte code.
Describing JavaScript as bytecode is nonsense.
1) It is not a binary format.
2) It is not close to machine code.
Actually your last statement is not true. Except for the method dispatching stuff most of the jvm instructions are very close and often translatable into a single instruction on most cpus. Its no coincidence that the default(most used) size for math in the jvm is an int of 32 bits which is thenatural size for most cpus of today.
Fabrizio Giudici
>
> With a Back button, the cognitive dissonance would actually be much
> lower. It's the perfect illustration of"Don't make me think"
>
Partially agree and partially not. I mean, there are actually a lot of
places where back makes sense. I'm extensively using it e.g. in my
Android application. But there are cases in which it starts not making
sense, for instance when you perform non reversible operation. The "pay"
page is a typical example. Note that since nobody can block the back
function in a web browser, everybody providing a pay service is forced
to print in flashing colors "DO NOT PUSH BACK UNTIL THE OPERATION IS
COMPLETE". So, while it makes sense to provide back functions, it also
makes sense to disable them at least in some places.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it
Cédric Beust ♔
On 11/06/2010 06:03 AM, Cédric Beust ♔ wrote:
Partially agree and partially not. I mean, there are actually a lot of places where back makes sense. I'm extensively using it e.g. in my Android application. But there are cases in which it starts not making sense, for instance when you perform non reversible operation. The "pay" page is a typical example. Note that since nobody can block the back function in a web browser, everybody providing a pay service is forced to print in flashing colors "DO NOT PUSH BACK UNTIL THE OPERATION IS COMPLETE". So, while it makes sense to provide back functions, it also makes sense to disable them at least in some places.
With a Back button, the cognitive dissonance would actually be much lower. It's the perfect illustration of"Don't make me think" <http://www.amazon.com/Think-Common-Sense-Approach-Usability/dp/0789723107>.
Cédric
Reinier Zwitserloot
doesn't work. If there's an explicit back button, itll be gray, and
the keyboard shortcut ways to do 'back' just don't work. In other
words, if you are building a non-modal app, this is a non-issue. If
you are building a modal app, then the back button should work, and it
can be made to work quite easily. If it doesn't, that's a program bug,
not a design flaw. I continue to believe you're just stubborn and not
willing to keep an open mind on this one.
I have programmed plenty swing and SWT, so my toolbox is stuffed
plenty. It turns out that, by experience, that hammer is actually
better at screwing in screws than the screwdriver. It happens.
Reinier Zwitserloot
HTML5 based (and plenty of them not particularly modal) used daily by
millions upon millions of satisfied users: google docs, gmail, vimeo,
youtube, remember the milk, google groups, reader, wordpress, ....
Examples of interesting, mostly well designed swing interfaces, used
daily by millions of millions of satisified users: .... uh....
IntelliJ?
Who is being silly?
Reinier Zwitserloot
so many obvious reasons I'm not going to insult anyone's intelligence
by listing them.
On Nov 5, 11:57 pm, Rob Ross <rob.r...@gmail.com> wrote:
Reinier Zwitserloot
photoshop where depending on what tool is active, shortcut keys / key
modifiers do completely different things.
Huh? What? That makes no sense at all - those things aren't even
remotely similar to each other!
Casper Bang
redirect header, forcing the client to issue a GET thereby placing a
new most-recent history entry. It is surprising how few e-commerce
sites honor this idiom though, double-submit remains a real issue in
2010.
On Nov 6, 10:12 am, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:
>
> > With a Back button, the cognitive dissonance would actually be much
> > lower. It's the perfect illustration of"Don't make me think"
> Partially agree and partially not. I mean, there are actually a lot of
> places where back makes sense. I'm extensively using it e.g. in my
> Android application. But there are cases in which it starts not making
> sense, for instance when you perform non reversible operation. The "pay"
> page is a typical example. Note that since nobody can block the back
> function in a web browser, everybody providing a pay service is forced
> to print in flashing colors "DO NOT PUSH BACK UNTIL THE OPERATION IS
> COMPLETE". So, while it makes sense to provide back functions, it also
> makes sense to disable them at least in some places.
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> java.net/blog/fabriziogiudici -www.tidalwave.it/people