i was reading an article about smartphones and features phones, and i was surprised to see that smartphones share only the 28% of the global MArket. In Africa, Asia, South American and so on there are still plenty of featured phones.....Than thanks to Java platform and Brew can run just a few third part made applications.
Now i was also reading another article about native app vs Web applications. Web application are crossplatform and thaks to html5 the gap between them and native apps is gonna be smaller.
My question is, Can features phone (or at least a part of them) run Web applications? SO Web applications are actually targeting also features phone........You just need a browser to run web app, do they have it? And are they gonna support html5 or only html4?
First off, the phrase "Feature phones" has no exact definition. All it really means is that they have less capabilities than "smart phones", but more capabilities than a "simple phone".
One of the capabilities that a smart phone is usually better at is the quality of the browser. Feature phones usually have a less full-featured browser that will likely not support much of HTML5 and usually be somewhat behind the capabilities of a recent smartphone as they are usually trying to work with smaller memory and a slower processor.
Plus, you can generally expect smaller screens and more limited user interaction making it more difficult to interact with a web app.
If you are going to build web applications for feature phone browsers, they would have to be incredibly basic. In my experience, feature phone browsers don't even fully support HTML4. Maybe they've changed since I last had a feature phone, but web browsing in general was almost pointless on my old feature phone. Web pages looked horrible, connection speeds were horrible (less than 3G), and the screen was way too small. Any web applications built for feature phones would have to pretty much be text-only to be usable.
Nokia Asha series support web app. Though they are not smartphone but can work like them except some features.
Related
What are the current best recommended resources for cross-browser testing in the CSS3 jquery world? I am adopting html5 and have adopted parts of css3 into my latest web project. I have also changed over to jquery for my scripting needs. The best answer I have seen for testing this pre-dates html5 and css3 being ready for primetime.
I am testing in Windows Opera, Safari, 2 Firefoxes+firebug, IE+f12 and two Androids. I test myself for input=expected output in my javascript and browser-sizing and other rendering issues. I test my php generated code by rendering it in firefox, then validating. I am trying to test for user experience by having myself and other people use the site and reporting on their opinion of the design, usability and overall impressions of the site-in-action. I present them with views on different sized devices. I even am lucky to have a friend with color-blindness;-} The F12 solution is particularly dissatisfying when testing in IE and the css rendering consumes large chunks of my development time.
Is better emulation available? Has anyone found a better (i.e. fast, easy, efficient, scientific) way to test across platforms yet? I am hoping for a strategy like unit-testing to emerge in the online community so we can make our apps more stable and robust as they become more powerful and influential. I can't seem to find a way to tame this chaos!
Have you used Selenium?
http://seleniumhq.org/
It is a tool to automate browser testing. Some people at Google made it and open sourced it.
You may want to look at RIATest for cross-platform cross-browser testing of HTML5 applications.
It works on Windows and Mac, supported browsers are Firefox, IE and Chrome. Automated testing scripts written on one platform/browser can be run against all other supported platforms/browsers.
(Disclaimer: I am a RIATest team member).
Now that Html5Boilerplate has reached version 2.0 and is oriented around mobile-first design, should Html5Boilerplate Mobile still be used for mobile-first sites? Just wanted to ask b/f I dig through the code of each.
It appears one of the obvious differences is that Html5Boilerplate has switched from CSS reset to normalize, and added mobile-first aspects like respond.js and mobile media query sections. Standard boilerplate appears more active on Github as well. Anyone have any opinion about these two?
Stealing this answer mostly from our mailing list thread on the subject...
HTML5Boilerplate is the one you should use if you are getting started
on websites. It is optimized to work and adapt on mobile browsers.
Mobile HTML5 Boilerplate is optimized for web apps that are explicitly
written to have different UX while on devices other than the desktop.
This means they might want to imitate the UI of native applications
or be close to it.
They may make heavy use of touch-based UI paradigms and other
interactions that are not possible on a desktop browser.
They explictly use media queries and other ways to detect a
non-desktop browser and serve an experience that is different.
When I say web apps, I mean websites that are used intensively to
accomplish certain tasks (like twitter.com / gmail.com / facebook.com
/ admin interface of wordpress.com ). These sites are required to take
advantage of the space available and help users accomplish their tasks
with minimal effort no matter what device.
On the other hand, we do have websites that users visit occasionally
because they found it on some friend's email or on reddit which has
content but users rarely interact with it (other than just visiting it
or at most leaving a comment), in which case html5 boilerplate would
be a good template to use. This would be a good option for most sites
that are content-rich and require minimal user interaction.
Unfortunately for us, mobile platforms are also creating silos by
specifying custom meta tags to use to optimize for their platform.
E.g. Apple recommends using apple-touch-icon meta tag to specify
things specific to webkit mobile browsers. Nokia has its own. We did
not want html5boilerplate to add such cruft to the defaults, but this
would be necessary for someone writing an application tailored to take
advantage of non-desktop devices. There is already a lot of
consistency, but we wish there was more standardization of mobile
optimizations.
We are planning an update to the mobile version with the newer files
as well, but there is no significant disadvantage to using it today. We do not yet have a meeting point where we could just have one project, but we are hoping in the future it does
merge into one :)
No, Html5Boilerplate Mobile should not be used for new projects; it is deprecated.
A deprecation notice was added in July 2015 to the project's GitHub repo (as of this answering -- Aug 2016 -- that was the most recent commit):
The H5BP team decided to no longer maintain Mobile Boilerplate since
HTML5 Boilerplate seems to be a good starting point for any kind of
project.
It depends on approach. Use HTML5 BP if you are going to have same mark-up for you mobile and desktop website. but if you are making separate website for mobile then go for Mobile Boiler Plate
It seems like the new "experimental" web browser in the Kindle is fairly limited in capabilities. Styling of even the included bookmarks looks a bit rough. In one video, the person mentions JavaScript being enabled in "advanced" mode but there was no demonstration of what that means. As of writing this, the product page only offers a quick paragraph about international support limitations.
What sort of web standards does the Kindle WebKit browser officially support?
Going back to Kindle firmware 3.2.x, the experimental browser absolutely supports JavaScript (ES3 spec), some CSS 2.x, and scores 55 (our of 555 possible points) on HTML5Test.com. It more or less passes the Acid3 browser test at 100%. This puts it on significantly better footing than Internet Explorer 8, other than on raw JavaScript performance benchmarks.
Strictly speaking, it is not an HTML5-capable browser despite having a non-zero score on HTML5Test.com. It doesn't support any HTML5 document features, but at the same time supports relatively advanced features like Web Workers, Cross-Document messaging, and Cross-Origin Resource Sharing.
With our Kindle 2 with International 3G, we were able to check Yahoo email, Gmail, Wikipedia, and some Maps from a remote site in Taiwan while on vacation. You can jailbreak a Kindle 2 to install the Kindle 3.x firmware. Any Kindle after the Kindle 2 can be updated to the latest 3.x firmware and have a quite functional, albeit archaic, browser compared to competing e-ink devices.
Even the very latest Kindle e-ink devices (firmware 5.8.x) only score 152 (out of 555) on HTML5Test.com, on par with Internet Explorer 9 which was 2 years behind competing browsers when it was released 6 years ago. They support some aspects of the ES5.1 JavaScript standard, but several aspects are missing/broken. It has partial support for WebSockets that makes it unusable for most web apps that use that feature, but no support for Server Sent Events which is bizarre for a device where battery life is critical. Amazon continues their history of what appears to be a purposefully broken CSS2.1 and CSS3 implementation, and the browser will hang or crash when trying popular benchmark sites like JetStream, ARES- 6, or Ringmark. One cool saving grace is the inclusion of Local Storage and Canvas support, which would make it possible to have games with decent functionality if their animations are optimized for e-ink refresh rates. The Kindle browser doesn't support web standard touch events in the browser, but there's other control possibilities a developer could employ.
That being said, even Kindle firmware 5.8.x is a decent browser on a device that has weeks-long battery life. It will reasonably render the low-end mobile (read: iOS and Android 2.x) versions of Twitter, Facebook, Wikipedia, and other major sites with only minor render issues. Amazon can and should provide a better web experience given the prices they charge, but in the worst case scenario the jailbreak community compensates wonderfully on the software side.
The Kindle 3 does handle Javascript but not Flash, movies or any of the other features. I have got around this with my Kindle 3 by building this website - http://www.anysubjects.com where I linked hundreds of great Kindle-friendly websites together.
I set myself the challenge of choosing only websites which were useful, and I could read without needing to change any of the settings on my Kindle, i.e. I did not need to change font size or the screen settings.
By doing this, I have built a site which does push the limits of the browser, but saves you a lot of time and frustration.
I don't have money to buy mobile phones, iPhone, etc, but I do want to make my web applications available to mobile devices. Are there some software to stimulate these devices, or what should I do?
BlackBerry Iphone and Android, you can use these simulators and emulators for testing.
Sure, there are emulators you can use. For instance, you could use have a look here for some device images from Microsoft http://www.microsoft.com/downloads/details.aspx?FamilyID=3d6f581e-c093-4b15-ab0c-a2ce5bffdb47&displaylang=en You can test on various screen sizes.
Also an interesting site is http://www.testiphone.com
My first testing platform is Firefox with his extensions with help of mobiready. You could use Openwave emulator (it is difficult find direct link) and Nokia SDK 40 Series. Althought this is a old and crapy software. You could use windows mobile emulator too.
depending on your scope & budget, deviceanywhere might be an option? i've got no experience with them myself, but I know a number of suppliers of ours (I work for a telco in europe) use their subscription-based test center on the web.
the product that might suit your needs would be 'test center' and there's a specific 'web developer' package that you could choose.
If you had some social networking applications and you wanted your users to interact with them using a mobile device would you use WAP or a slimmed down version of your regular website with HTML?
My train of thought is that WAP is dead or at least starting to bleed to death because of all the mobile web browsers available (Iphone, Opera Mini). Is this a good assumption?
Also, what kind of audience considerations should you take into account when choosing what kind of mobile access you wanted to develop?
I'm ot sure about my target devices. I'm pretty sure my users will be more "modern" so we can assume Windows Mobile, iPhone, and Blackberry devices.
WAP 2.0 = XHTML Mobile Profile. I'm assuming by WAP you mean WAP 1.0 and WML. Pretty much all mobile browsers these days support XHTML MP (or some close cousin).
For best practices on mobile development, refer to the dotMobi Mobile Web Developer's Guide.
I suggest you use something like WURFL to auto-detect mobile browsers, and serve them XHTML MP with Wireless CSS. I've built a mobile front-end for an application in this way, and it works well across lots of mobile browsers (mobile ie, opera, openwave, ...).
You shoud use standard XHTML 1.0 Strict or XHTML Mobile Profile. WAP is going to die very, very soon (if it hasn´t already).
http://en.wikipedia.org/wiki/XHTML_Mobile_Profile
Slimmed down HTML.
WAP sites are universally ugly, in my view, and with mobile browsers becoming more capable, Ajax applications are increasingly possible (and can work well with the limited bandwidth/data plans that people may have.
But if you need to support every mobile device on the planet, you may have to do something with WAP anyway.
What are your target devices? Everything, modern-ish phones, smartphones only....?
Having developed a few mobile applications I would say that the majority of clients support HTML. It is of course safe to serve these clients a slimmed down version of HTML in order to design your application for the common denominator. However, there is still a significant number of clients which only accept WML as their content type and thus HTML cannot satisfy all your users.
If you read the HTTP_ACCEPT header you can determine what the client is able to understand. In my experience it is safer to serve HTML whenever you can and fall back on WML when you have to.
The bottom line is that if you are reluctant to supporting two versions of your site, use slimmed down HTML (preferably XHTML). If you can support WAP in addition to HTML it makes a nice fallback for the clients which do not understand HTML.
Do remember that WAP has strengths of it's own that normal HTTP sites browsed from mobile handsets do not posess.
A major one is that you can get access to WAP billing, where you can charge small amounts of money from customers that may not have credit cards available.
Also you can use the MSISDN (mobile phone number) to uniquely identify and track visitors to you WAP site.