If all you do is run ajax requests off of a single page, back just 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. On Nov 5, 11:52 pm, Rob Ross <[email protected]> wrote: > 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, [email protected] 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 -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
