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. 2) Changing default behaviour of key bindings (as has been mentioned by others). If you're in a textarea, Enter does the right thing. If you're elsewhere, it submits the page. Apart from the fact that you can't guarantee which submit will be called (generally the first button, but not necessarily the first visible button). So I would like to either disable Enter => submit altogether or say which button I would like to submit. Backspace. Again, in a text box or text area, fine. On a button or radio button or combobox, it goes back a page. Again, please note that I'm not talking about externally exposed websites, I'm talking about internal applications. I know that there are solutions to all of these problems, but in every framework and every browser the solutions seem to be different. Rant over. Matthew. 2010/11/4 Ricky Clarkson <[email protected]> > The thread about server-side frameworks leads me to wonder; will the > 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? > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- 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.
