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? Or, for that matter: - when your (bandwidth-throttled) DSL connection slows to a crawl every evening - when you're in an area with poor 3G coverage - when you have a laptop, but not a 3G dongle - when internet connections in your country are slow and/or extortionately expensive In particular, that last one will price your application out of the market for most of the world's population. It's already bad enough that so many projects now only offer their documentation online with no downloads available - and the situation is only set to get worse... On 5 November 2010 09:52, Matthew Farwell <matt...@farwell.co.uk> 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. > > 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 <ricky.clark...@gmail.com> > > 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 javapo...@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> >> . >> 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 javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : kev.lee.wri...@gmail.com pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
