I'm someone who wants to be up on the latest web technologies but also appreciate that alot people still use IE6/7/8. Is it a waste of code/time if half of it wont be displayed on most browsers? Is it just a case of using different style sheets, or just use one style sheet and if a browser doesnt support text-shadow, then screw it, they can see it without the nice effects. What are peoples thoughts?
It depends on your userbase. I am an intranet developer and my company still uses IE6(!!!) so we have no choice but to support IE6. I also develop some public facing websites and we use Analytical tools to see the which Browser is being used more and ignore ones which are less used. in this case IE6 was the least used Browser.
I won't go for HTML5 and CSS3 till Internet Explorer 9 or Firefox 4 (absolute release, not alpha or beta) is released, because these two browsers make up the most of web traffic (afaik, correct me if I'm wrong) and using html5 or css3 will be a big loss.
And yeah, it depends on your userbase too.
I'm developing a small-business oriented online app and decided to support only IE8, FF and Chrome. I also went for one stylesheet that degrades nicely (text-shadow, rounded corners). IE8 users will see square corners but it doesn't make the site unusable in any way.
I just think that the cost of making everything look perfect in all browsers (and maintaining it!) is much higher than the benefits.
The above also applies to HTML5 IMHO - unless you know that vast majority of your users will have an HTML5-compatible browser there's no need to invest in it right now. Unless the whole point of your site is to use one of the newest features.
Just tell yourself what problem of your users you are actually solving and solve that one.
Related
I'm sure like most developers, you have gotten your code perfect only to test it on IE7 and it doesn't look right.
My analytics say that IE7 is one of the lower ranking versions of IE being used to view my website. My question is why do people still use IE7? Isn't it easier to update to a better version of IE than to still be on 7?
I'm not sure why you would be on such an old version of IE unless you are not computer literate and only use it for basic tasks.
I tried researching on the web but no such luck. Any thoughts?
Some people simply don't have a choice if their IT department has not upgraded them. If you're building your application for a specific client, build it to the lowest version they have to support. If you're just doing this on your own to publish, then just support 'modern' browser versions.
I am creating a dashboard project for which i am using nvd3 but as we know svg is not supported in IE8 so it does not render graphs/charts in IE8..please suggest how i can make nvd3 work in IE8
I'm in the same situation and I think I may just ditch nvd3 (besides no ie8 support, I'm finding other bugs). I'm wondering, has anyone successfully used r2d3 with nvd3?
My concern is that r2d3 uses d3v3 now, which nvd3 is not presently supporting (currently d3v2... d3v3 support in the works as of writing this).
For an alternative to nvd3, I'm considering:
MorrisJS!
- Works on ie8 (Raphael-based), but a newer project and less flexibility/options with the charts comparatively.
Google Chart Engine!
- I think this may be the way to go (for my project), I don't like that its not open source, but I'm already working extensively with the Google Maps API and this solution is very stable and easy to use from my experiences thus far. In limited testing in ie8 it works very well.
Also, here's another stackoverflow question on this topic, [question]: nvd3.js rendering solution for Internet Explorer
...seems r2d3 was the accepted answer there, but no one really verified it.
The library r2d3 is "a customized build of D3 powered by RaphaelJS. The combination of D3 and Raphael enable developers to easily build data visualizations that work in IE7+ and all modern browsers." - it has its limitations (see the link for details), but it would be a good place to start
Google has taken up the implementation of WebRTC in Chrome very seriously as indicated by the frequent updates in the Canary and Beta channel of Chrome. Are there any other browsers who are upto implementing this?
Firefox/IE/Opera are working on it. No word from Apple/Safari or Microsoft/IE, although IE is unlikely at best, because they're working on their own standard unfortunately. Crazier things have happened, but I wouldn't count on it. Apple has been fairly mum on the subject.
If you want support for those other browsers, we built a solution for it # Frozen Mountain (I work there) using IceLink.
Opera Mobile does offer support to WebRTC. And according to this article, Mozilla isn't all that far behind either. Ericsson Labs has their own custom browser which supports WebRTC. But it runs only on Ubuntu as of now. WebRTC itself is still under development and I'm sure that we can see complete support from all major browsers in some time.
Mozilla is far along in implementing WebRTC, and we're leading the design and implementation of DataChannels within WebRTC, as well as Identity work. We're working on a project-specific repo right now (alder), but pieces have already moved over into mozilla-central, such as initial support for getUserMedia.
I have an application that will need to better support tablets in the future. I have seen some apps already created with UP1 and ExtLib Mobile Controls but I was wondering if anyone knows of specific functionality that simply is too challenging to even consider bringing to a mobile device?
For example, are there partial refresh issues on specific devices? Can managed beans still be used behind the scenes? Is dynamic content totally viable on mobile?
I'd be interested in hearing what big challenges/functions people had to give up when they mobilized their existing XPage apps.
There isn't really anything in XPages that would prevent building mobile web apps as with other web app dev models. In other words: Everything you can do with web apps on mobile you should be able to do with XPages.
XPages 8.5.3 UP1 comes with Dojo Mobile 1.6.1. However that does not prevent developers from using other frameworks like JQuery or anything else.
There are some advantages in general for native apps and hybrid apps. But personally I think most of the typically rather simple business apps can be built with mobile web apps. If you need local data/offline that might be different though.
You can use Xpages to do anything that is possible with mobile web developement. Dynamic content may not be the way to go for everything, but it will run just fine. In ITANA available for free on openntf.org, i created a simple replication engine to replicate notes tasks from the local device using sqlite to the domino server. This makes it run very fast and allows the app to run offline as well.
So i believe anything you want to try will work, you can make the Xpage output anything you want, from html, to xml, or json, to accomplish your tasks.
I know that XPages was totally incompatible with older Blackberry's. I assume that's not the case these days but back at OS 5.0 I think even buttons wouldn't work. So if you're doing anything with BB make sure it's modern and tested.
We're not really getting tablet support in ext. library until the next dojo rev I think. But there is a preview of tablet support somewhere that you can get. I've not looked yet but it was mentioned at Lotusphere. so if you want to hit tablets you might want to roll your own right now until that comes available.
Tablets are a little more challenging as the mobile controls are designed for the mobile phone size devices. That said with a little trial and error you can get a nice navigator split screen and still use the one page app mobile controls to streamline it, with records opening in their own page just like the phone version. Type ahead as I'm discovering should be handled differently if you are using the iPhone themes from oneui2.1
The oneui2.1 gives your navs and views nice styling. The forms may need a bit of custom styling.
Split your design into custom controls then you can use a server ate xpage for mobile devices and straight web. Or if you forgo the use of mobile single page controls you can always just have a seperate style sheet to accommodate the iPad. Really depends on the functionality needed. Good luck
My suggestion for anyone wanting to do tablet specific development using XPages is to move to Notes 9.0 and dojo 1.8 asap. Dojo 1.8 has an experimental control called ScreenSizeAware. This is miles ahead of anything else either the Extension Library Mobile controls or Dojo provides for Tablet development.
I would like to know what the members of this great community think of developing and adjusting their web apps and sites in general to recent Google Chrome beta browsers on Linux and Mac OS X and of course Google ChromeOS.
Do you think it's too early and I shouldn't waste my time adjusting myself to something that might change due to bugs resolutions?
Thank you.
Since Google Chrome uses Webkit you could also (as an alternative) test against Safari or Konqueror instead. Chances are your test results will be very portable across these browsers.
I think you answered your own question. While it is good to test against multiple browsers, there is very little point in testing against a beta browser - especially one with as little marketshare as Chrome.
With that said, the only reason I could see testing against a beta browser, is that you want your website to look good in it as soon as it is released and becomes mainstream. But, I really only see this need arising for the browsers that, again, are more popular.
Code against the standard, if you code it right the browsers will move toward you - rather than you constantly playing catchup.