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.
Related
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.
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.
Is it safe now to develop web application with HTML 5 specifications? or should we wait longer for final standards?
I want to start developing a new project. I want it to be up to date in every aspects. should I wait more for html 5 or I can start programming based on it?
It all depends on your audience.
If most of your audience is going to be fairly hip web developers that know to use a decent browser, you are probably going to be fine using HTML5.
However, if your audience is any government institution (school, etc), business place, etc, you might not want to use it yet. My school currently runs on Internet Explorer 6/7, and one of my teacher constantly complains about that "Your browser is not supported" message at the top of Youtube. These people probably don't have any control over the browser they use, and might be a bit behind due to the IT guys.
Find your audience, and use what you are comfortable using with them.
It depends what you which features you want to implement. HTML 5 is a very broad standard covering video, dynamic bitmaps, geolocation, more semantic tags etc.
No browser has implemented all HTML5 features, all have implemented some
This will tell you most of what you need to know about and which browsers support it.
http://diveintohtml5.ep.io/
Which part were you particularly interested in? Many people want to use canvas which is the dynamic graphics tag (simulates svg in an element). Canvas works on all major browsers except IE, though support for canvas is predicted in IE9
It depends on your audience. If they have the latest browsers then you can start using parts of HTML 5. If you don't have a good understanding of your user base then you might want to use web analytics to understand the capabilities of their browsers. Developers tend to have newer browsers but corporations or schools may not. You should also do some research on HTML 5 and understand if you can get up to speed with it quickly if deployment time is a concern.
Use progressive enhancement. A lot of the HTML5 features (application cache, the custom form fields, the extra semantic tags) will do no harm in unsupported browsers (though you might need the HTML5 shiv from Remy Sharp), but give a bonus to users and spiders who can use them. Other features (video tag, database storage, web workers, geolocation) can use workarounds for compatibility with older browsers - the Modernizer library linked by Mark Pilgrim makes this very easy. If your app is usese Geodata, for example, you could use the browser-based geolocation where available and fallback to something IP-based.
What are the topics we should pay attention while designing web site for Internet Explorer 8? Is there any new standard,we should obey for best appearance?
You should never design a site for a browser, you should design sites using the subset of css/javascript that is supported by everyone.
Granted, if by design for ie8 you mean you will not be supporting 7 or 6, that subset gets alot bigger.
With IE8, Microsoft is planning to bring compliance with W3.org web standards. http://www.w3.org/
http://channel9.msdn.com/posts/Charles/IE-8-On-the-Path-to-Web-Standards-Compliance-ACID-2-Test-Pass-Complete/
So, make sure your site is valid according to web standards. You can validate your site by going to http://jigsaw.w3.org/