Hello all
on a more general note, I'm wondering what people are doing, if anything, when the site visitor is using a browser that cannot fully utilize a form that OPS has generated from XForms? This might happen because they are using Safari ;-), or some other browser or device that simply can't run javascript, such as lynx, or a reader (that speaks the web page to someone having difficulty seeing) or maybe a mobile. Do you have a separate path that produces a regular html form without the javascript? Do you suggest they print the form and fax it in? Some other backup plan? Or is everyone else doing OPS on an intranet where do you don't need to worry about such variables? Thanks & regards Colin -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
That's a good question. Clearly, the day Safari and Opera are
supported, this will be less relevant. However, you will still have the problem of users using older browsers. I can see some ways: 1. The OPS XForms NG engine could theoretically be enhanced to include a non-Ajax version, which would potentially work with much older browsers. The ideas to do this are in our heads, but that won't be for tomorrow unless somebody sponsors it. 2. You can detect that the browser is not supported, and: 2.a. Display an error message or request to "upgrade". Users hate that, but sometimes it may make sense in that you probably don't want to support Netscape 3. There has to be a limit. 2.b. Fall-back to an alternative version of the application. This clearly kind of kills the idea of increasing your productivity by using XForms, since you in fact have to write two versions of your app. Of course you can still shorten your time to market because you first produce a version that works on newer browsers, and then later one that supports the old legacy browsers. #2.a is ok I think. #2.b appears bad both in theory and in practice IMO. #1 would be the way to go in the future. -Erik Colin O'Brien wrote: > Hello all > > on a more general note, I'm wondering what people are doing, if > anything, when the site visitor is using a browser that cannot fully > utilize a form that OPS has generated from XForms? > > This might happen because they are using Safari ;-), or some other > browser or device that simply can't run javascript, such as lynx, or a > reader (that speaks the web page to someone having difficulty seeing) or > maybe a mobile. > > Do you have a separate path that produces a regular html form without > the javascript? > > Do you suggest they print the form and fax it in? > > Some other backup plan? > > Or is everyone else doing OPS on an intranet where do you don't need to > worry about such variables? > > Thanks & regards > Colin -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Hi Erik,
hope the ObjectWeb conference is going well for you. Thanks for your response on this issue. A good summary (of the theory) as I was seeing it, though as I said in my original email, I don't see this as an issue for older browsers, but also other types of web-content-consuming devices. Obviously an extensible system along the lines of option 1, so there was a place in the logic flow for it to happen and most common cases handled, and the ability to add more specific, would be the ideal - something else to add to the list ;-) What I was hoping was that other ops developers might share their real-world examples of what they had done and how well it had worked out for them? Best regards Colin On Feb 1, 2006, at 4:58 AM, Erik Bruchez wrote: > That's a good question. Clearly, the day Safari and Opera are > supported, this will be less relevant. However, you will still have > the problem of users using older browsers. I can see some ways: > > 1. The OPS XForms NG engine could theoretically be enhanced to include > a non-Ajax version, which would potentially work with much older > browsers. The ideas to do this are in our heads, but that won't be > for tomorrow unless somebody sponsors it. > > 2. You can detect that the browser is not supported, and: > > 2.a. Display an error message or request to "upgrade". Users hate > that, but sometimes it may make sense in that you probably don't > want to support Netscape 3. There has to be a limit. > > 2.b. Fall-back to an alternative version of the application. This > clearly kind of kills the idea of increasing your productivity by > using XForms, since you in fact have to write two versions of your > app. Of course you can still shorten your time to market because > you first produce a version that works on newer browsers, and then > later one that supports the old legacy browsers. > > #2.a is ok I think. #2.b appears bad both in theory and in practice > IMO. #1 would be the way to go in the future. > > -Erik > > Colin O'Brien wrote: > > Hello all > > > > on a more general note, I'm wondering what people are doing, if > > anything, when the site visitor is using a browser that cannot fully > > utilize a form that OPS has generated from XForms? > > > > This might happen because they are using Safari ;-), or some other > > browser or device that simply can't run javascript, such as lynx, or > a > > reader (that speaks the web page to someone having difficulty > seeing) or > > maybe a mobile. > > > > Do you have a separate path that produces a regular html form without > > the javascript? > > > > Do you suggest they print the form and fax it in? > > > > Some other backup plan? > > > > Or is everyone else doing OPS on an intranet where do you don't need > to > > worry about such variables? > > > > Thanks & regards > > Colin > > > > -- > You receive this message as a subscriber of the > [hidden email] mailing list. > To unsubscribe: mailto:[hidden email] > For general help: mailto:[hidden email]?subject=help > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Free forum by Nabble | Edit this page |