JQM leaves C-grades usable, not appealing to look at. Does the market share of C-grade browsers justify making a whole new stylesheet for them? Are there any credible statistics on their popularity?
Blackberry 4.x - You can get the ans here- https://stackoverflow.com/questions/1868567/what-market-share-do-each-of-the-blackberry-models-have
as u can see for 4.x its too less to worry about and its diminishing everyday.
Windows Mobile - http://en.wikipedia.org/wiki/Windows_Mobile#Market_share
As read from the article, the market share is very less and no major manufacturer supports. so gone case.
All older smartphone platforms and featurephones – As the link says all browsers/smartphones not supporting CSS3 media queries will experience C class experience. Here is a link to give u an idea of browsers. http://www.quirksmode.org/m/css.html#t021
And correspondingly for those os' or browsers the market share is way low to consider making a separate style sheet for them without media queries.
Here are metrics from a site I work on from Jan 2012 to March 22nd for mobile. Out of MANY thousands of visits:
64.49% Safari (iOS)
26.01% Android
2.95% Chrome
2.56% Mozilla Compatible Agent
2.42% Firefox
1.03% Internet Explorer
Keep in mind that market share of handsets does not exactly translate to actual web usage. A lot of people still have feature phones and other C-Grade devices. However, that's pretty irrelevant because the experience of surfing the web on those things SUCKS. The users all know it and thus they do not use it for surfing the web. I think it's noble that jQuery Mobile even tried to support them, but they really didn't have to because none (statistically speaking) of those people are surfing the web on their crappy little old devices.
Related
Sencha Touch is brilliant but IE cannot open websites which is developed using Sencha Touch.
I am not interested in using IE, but my opinion is not important since many others may use it.
Since Microsoft announces HTML-5 Support and I have worked with the great tools to make native apps even using HTML-5 and Java so it is obvious that IE 10 must support HTML5. But it seems sencha touch websites cannot be explored by IE 10 too, since I cannot explore Kitchen Sink (on sencha.com) using IE 10 however I can easily do this using Chrome.
Further to this problem, I want to make an web-site for a small company, is it right to use Sencha Touch to develop it or jQuery is a better choice? (I yearn for you say Sencha Touch :) since I am completely unfamiliar with jQuery)
I appreciate the time you are spending.
Sincerely yours,
PEYMAN MORTAZAVI
Call me old-fashioned, but when I see the Kitchen Sink demo failing in IE10, I blame the developers behind the demo, and not those behind the browser. IE10 is an oustanding browser that is worthy of our attention, and not merely for the fact that it will be used by millions upon millions immediately following its official release, but also because it's a great browser from a technical perspective.
If you're going to build a solution for your clients, you should avoid libraries that wish to distance themselves from supporting half of the market, meaning they don't actively develop with IE in mind. The excuses for not supporting IE simply aren't there today as your code won't require that much variance to work properly in the latest version of Microsoft's browser.
Use jQuery, jQuery Mobile, or jQuery UI. You can get some great UI from and with all of them, and you'll find excellent support in all major browsers.
I am porting my Sencha Touch 2.0 app to 2.2.1 in order to support IE10.
So I have first-hand knowledge in the effort.
all Sencha websites / apps build previous to 2.2.0 and by developers targeting webkit browsers will never work on ie10 reliably because a bunch of stuff had to be done to the core of Sencha Touch in order for ie10 to work. Everyone has to go back and do what I'm doing... line by line of CSS and a few JS changes as well (esp if you do canvas stuff)
Running an old "kitchen sink" which was not properly architected for 2.2.1 and tested on IE10 is not going to work either. I do not know how much time Sencha folks spent testing kitchen sink on IE10 ...but one would assume...
I think what has thrown Sencha for a loop is developers don't have time or money to build business apps twice - once on ExtJS for laptop/desktop and 2nd time on Sencha Touch 2 for tablet touch/gesture support. This is the strange land of SDK's because the tablet real-estate so closely resembles that of a small laptop -- ergo as long as your UX people a really good, they can architect an experience that crosses over from tablet to laptop pretty good by building one code base in Sencha Touch.
But oooops - Sencha figured we'd all be building to small phones - a market dominated by webkit browsers. If that were the case, then this argument of IE market share would not hold - we all know Windows Phone numbers. It's hard to fudge/spin that. What's causing the rub is the tablet-laptop screen size being so similar.
IMHO...
IE10 in the Windows 8 preview is the same version that is slated for the tablets and mobile devices they have been producing. Saying it is for desktop support is not a very useful statement. The problem is this is what Microsoft is about to spend a very large amount of money marketing and pushing to businesses. This is not a case of a tablet/phone library not supporting a desktop, but of a tablet/phone library not supporting a target platform that is about to have billions of dollars of marketing spent to deploy it.
Any mention of Internet explorer seems to evoke deep emotion in everyone! However IE is a fact of life.
I would suggest that you use Google Chrome Frame. The first time IE visitors arrive at your site you can alert the user to install Google Chrome Frame and redirect them. It's a bit messy for the first visit but after that it should be seamless.
As I understand it Google Chrome Frame no longer requires admin rights to install.
Obviously people should just install Chrome in the first place but nobody's perfect.
Sencha Touch 2 is not designed to work on IE10. If desktop support is important for you, then you should use Ext JS 4.
Chrome and Safari use WebKit which Sencha Touch requires in order to function.
Internet Explorer might be able to display Sencha Touch apps in the future:
http://www.appleinsider.com/articles/08/11/06/microsofts_ballmer_considers_using_webkit_within_ie.html
http://www.favbrowser.com/opera-firefox-and-internet-explorer-to-implement-webkit-prefixes/
But who knows?
I had spent a month getting a project to work with Sencha Touch, but had to choose a more accessable framework. The goals of the project were to work across as many browsers (desktop and mobile) as possible. The webkit preference for Sencha, while admirable in how it is achieved, made it unusable for my needs.
I am glad they changed their licensing since I tried it. That was the second stumbling point for our project.
In mobile development world, which is the best programming language/technology that we can use so that almost the same code that will run on all versions. I know it is little bit of a broad question and the most probable answer is Java. If I want to provide support for maximum number of devices(android, Iphone and other high end classes only), how many different code bases I should have?
Thanks,
GL
[...] that we can use so that almost the same code that will run on
all versions [...]
All modern mobile smartphones / devices support HTML 5 / CSS / Javascript.
PhoneGap Augments these basic tools with the rest of the functionality you'd need.
Projects like jQuery Mobile are gaining a lot of traction as well.
I'd start there.
I wouldn't say it's "The Most Widely Used" technology... at least not yet... but I have a hard time believing anyone wouldn't agree things are going that direction.
UPDATE: For anyone who hasn't seen PhoneGap before - this (free) product will take your HTML / CSS / JS, and package them up inside a native application (which includes some shims to startup your app, and augment it with access to camera / files / gyro / etc from javascript). Your app works offline, and can be deployed through all of the available standard app stores.
If it's a web app, then you can develop using a highly adaptive layout, HTML 5, CSS, and the JS library of your choice, and you'll be fine.
If you are running native apps, you're pretty much stuck: Java for Android, Objective-C for iOS.
Regarding HTML5/CSS3, even if it is possible to reuse 90% of codebase (mostly non-rendering JS), there are significant differences when it comes to graphical presentations. Even, if you think that because Androids and Iphones use Webkit, so they should have roughly similar capabilities, they are quite apart.
Just to give a few examples: CSS3 3D transforms are mostly not supported on Android phones (Android 2.3), Audio tag implementation varies between Android and Iphone (Androids do not use buffering and streaming, while Iphones do).
And just do not get me started on how Androids lie about dimensions and aspect ratio. It is a bloody mess.
We have not tested latest Windows mobile phones, but until IE10 is shipped, support for HTML5 in windows world is abysmal.
To conclude, currently, there is no technology, "that we can use so that almost the same code that will run on all versions." HTML5 is 'almost' there, but will take perhaps a few years for Androids to catch up and Webkit to get the required speed and functionality to be able to compete head-on with native apps.
With the advent of smart phones, individuals are now able to access a given site or application in one of three ways:
Through the same site that is rendered on desktop machines
Through a minimized mobile version of the site
Through a proprietary mobile application
In an ideal world, users could choose from any of those three methods. However, there is a cost associated with implementing additional interfaces on top of the existing Web interface.
I'm seeking verifiable information (statistics, trends, Gartner predictions, etc.) that could help someone justify the creation of a minimized mobile site and/or proprietary mobile applications vs. having a well-crafted site that renders fine in mobile browsers.
I found an article covering Nielsen's 2009 recommendation but the article seems to suggest that you should address mobile users, not so much how to determine which method(s) are more appropriate (not to mention there aren't any references to mobile apps).
If your site renders fine in mobile browsers, why would you need a minimized one? Remember not everyone has an iPhone. Blackberry users usually need a special version, unless your site has Wikipedia like simplicity.
You can look at your logs and see how many users come that have mobile phones. Check this against the bounce rate, this will tell you if they can view your site or not.
With all the different mobile phone browsers and the mobile market being so diverse I'm having a hard time deciding on a way to create a text based online game for mobile phones.
I was thinking about using HTML / CSS / Javascript for front-end and Python CGI for server-side (with a DB).
Now this seems like a very obvious choice... BUT I'm having a hard time finding the "limits" to each one... by that I mean at what point will a popular web browser stop 'supporting' a technology. Like when it comes to HTML I assume you cant use HTML5 features in all popular mobile browsers... or maybe some allow JS but not jQuery... or maybe some don't allow some common CGI features or DOM is weird... I do not know.
I have read a few different tutorials on various mobile web browser development but nothing really helps to answer my question.
So what I'm asking is basically:
What languages/technologies do you recommend for a Text based mobile online multiplayer turn based browser game that will need to dynamically load a lot of info?(front front end to back end)
What are some common limitations between popular mobile web browsers I should look out for? I want to be compatible with all popular mobile web browsers.
One of the things to keep in mind is that there is a plethora of mobile browsers out there (Look here for details). So you are probably better off starting with iphone, android and blackberry and maaaybe opera mini browser support. These browsers have sophisticated java script support and you would be able to provide a good user experience. Later on you can work on supporting other mobile browsers.
Regarding your questions, if you look at these browser specs (and they are readily available on Internet) you will see that you will be able to use quite a bit of web technologies (HTML, CSS, Javascript, etc). That wont be a showstopper for you. Designing for a small screen, and a great user experience on small screens, that will make or break your game.
I've been developing with XHTML, CSS and Javascript for about 4 years now.
I love it a lot and hate it a little. I've looked into Flash and Silverlight a bit, but as a developer, I'm not too keen on them.
One reason is that they lock you into a vendor and generally, into using that vendor's tools. E.g. Adobe Flash or Microsoft Visual Studio, etc.
Also, Silverlight seems to mix content, layout/styling and behavior and into a single markup language, whereas I like the XHTML way of separating them out in code, but bringing them together in the user's web browser.
I also applaud the usability of the web, e.g. back button, hyperlinks, etc. which are set-in-stone standards that people are used to dealing with.
However, I'm seeing a lot of industry support for Silverlight and Flash. As far as .NET Developer jobs, I'm seeing less jobs for front-end/.NET developers and more jobs for Silverlight/.NET developers.
Will HTML developers still be employable in the future, or should I consider moving to a proprietary platform such as Silverlight?
While Flash/Silverlight skills may be worth developing, I think you will find that general web development skills will still be required for some years to come. Mobile apps in particular seem to place more emphasis on good, basic web design without dependence on plugins and or client-side code. Eventually, I would expect web standards to evolve to subsume the best (or at least most used) features of proprietary plugins. The web, at least, seems to be a place where people tend to favor solutions that maintain independence over lock-in to specific vendor technologies.
No, I think that idea will never fully catch on. The problem is really about the platform being developed on.
Look at how accessible the web is. Almost any machine can get on the web. My phone, my iPod, my laptop, my 11 year old PII machine, my gaming tower, all can access the same web.
The devices I have are not the limit to what can reach the web either. I think just about every gaming platform and cell phone can get on the web, as well as thin terminals running any OS imaginable. I'm sure there are others also.
The big thing looks like it's going to be the mobile market in the next few years. Some mobile devices can run flash, but it isn't used much because of the poor support & performance. The only way that the mobile web can work is by using pure standards based solutions, because that's really the only baseline that can be trusted to exist.
No matter what proprietary technologies come out, I can always rely on the fact that my XHTML pages will still render successfully on whatever device decides to access it. The same can't be said for flash or silverlight.
At the same time, I can also guarantee you that there will be a bigger market for flash and silverlight because the web is becoming more "media rich" in some niche markets (YouTube, Adobe Air, Hulu, Google Gears, etc. to name a few examples). There will absolutely be a market for it, but I wouldn't say it will defeat XHTML and web standards because the web is constantly being redefined.
No matter how much Flash or Silverlight try to take on, the technology will move so fast that the only baseline that I think will remain will be standards like XHTML and CSS.
Flash has been around for years and still hasn't taken over. I think that is one good example of how hard it is to replace XHTML.
Go for server-side development of any kind, but I wouldn't become a Silverlight or Flash specialist.
<CrystalBallMode>
To be honest I can't see it happening. Other than the reasons mentioned by tvanfosson and DanHerbert, the XHTML + CSS + JS stack just grew mature enough so that things like AJAX and jQuery make pretty much all the lightweight client side stuff easy with these tools (as opposed to things like streaming video, heavy computations or sockets etc.)
Common technological inertia will just guarantee that the existing things will stay around. People are much more likely to use something that has been around for a while and has been extended to meet the latest requirements than to use something totally new. Of course there are great paradigm shifts every now and then like the native to managed code transition but I don't see that happening with Flash or Silverlight.
</CrystalBallMode>
My hope is that what comes out of all of this is a new standardized web platform truly suited to building the web applications that people want to see with tools that developers really want to use. I see all of the effort going to trying to shoehorn these legacy web technologies into the "Web 2.0" model and I just wish that this effort could go towards making a truly revolutionary "Web v.Next".
Don't get me wrong, I really like what jQuery is doing to make Javascript client code easier, but it's still Javascript and my personal preference is to work with strongly typed languages with productive development tools.
In the meantime, I think tools like Silverlight and Flash have a lot to offer and help you do things more easily in some cases than in other web technologies, and there are some things you simply can't do any other way. But I don't think Silverlight or Flash or any other technology is the end game, just a step in the right direction.
Consider for a moment that you can manipulate a web page using Javascript, (X)HTML, and CSS with a great deal of overlap in functionality and yet ALL three technologies remain in prominent use today. The reason for this is because all three languages are different tools meant to solve different problems and no one of them can serve as an adequate replacement for the other.
Its the same thing with Flash / Silverlight vs these existing web technologies. In fact, I work in a dev shop that builds Flash based e-learning. One of our current products was originally built to use a purely Flash-based solution for navigation, etc. However, as the product has continued to evolve we have actually moved a lot of the functionality from the Flash-based e-learning module and into regular html pages.
In other words, I don't think that we'll be abandoning the current tools that web developers use any time soon. For the most part I see Flash / Silverlight as additional tools that will solve particular problems better than we were able to solve them previously.
Neither one is going to win out anytime soon. I expect which one is used will depend entirely on the purpose for many years to come.
The reason you're seeing so many job offerings for Silverlight of late is because it's a relatively new technology and just recently gained some momentum.
Though, I do expect Silverlight to make quick work of Flash.
I sure hope so. And yes, I think they will. There will be some development on legacy (XHTML/CSS/JS) apps for re-tuning purposes, but I think there will come a day when new apps are simply not created on those platforms.
Mobile phones are the issue right now. Flash isn't available on many of the major phone models. And their browsers are all over the map. Luckily there's Webkit (iPhone and G1).
If Silverlight makes it to a web platform then it will be a nice viable alternative to the hodgepodge of technologies that are currently in use. FYI, Microsfoft says Silverlight on Android is very possible. On the iPhone, hard to say, Apple is weird about such things.
AOL recently created a RIA version of it's email client in Silverlight. Looks nice and there's no Javascript errors to worry about. From a developer standpoint, that's huge.