I've just come across the HTTP_PROFILE header that seems to be used by mobile browsers to point to an .xml document describing the device's capabilities.
Doing a Google search doesn't turn up any definitive resources on what this is and how it should be used, can anyone point me to something along the lines of a spec/W3C standard?
I think you may find http://en.wikipedia.org/wiki/UAProf to be of interest?
I just found this page: http://www.mobileok.kr/eng/develop2/ddrserver.php
It didn't seem to be authoritative at first glance from the search results, but looks like it might be.
Device Atlas, Wurfl or TeraWurfl are well worth looking into if you want to do some proper mobile device detection. These provide easy access to device properties so you can use content adaptation techniques to serve pages and content which is carefully optimised for the device being used.
Related
HTTP_ACCEPTED_LANGUAGE allows a browser setting to determine the preferred language a website is displayed in (which can lead to some uncomfortable user experience do to mixed-language display when a framework is translated but the contents are not, or when it's only a bad auto-translation). I was hoping there was a way to display websites preferably in their native language if it is among my preferred languages, but there is a requirement I don't know whether it exists:
Can a browser be informed about a website's native language via HTTP? (Using the TLD, or worse, geolocation, doesn't count since that can be wrong especially for individual user-sites)
If you are asking about browser, the answer is yes. Just set the Content-language header on the server side and browser will know the language. The problem is, I don't think it will give you anything.
But you seem to be asking what is the real language of automatically translated web page. No, there is no such thing. And personally, I don't think it should be. I understand your problem, but there is no way to create idiot-proof protocol. The universe will just make better idiots.
That said, using automatic translation on the web site as default rather than optional is one of the most stupid ideas I've ever seen. Personally, I would not even attempt to use such web sites.
I want to redirect some URL to mobile version, if the user agent is a mobile.
Example :
klikkarir.com/jawa-pos/5215/lowongan-call-center-accounting-administration-pt-asia-teleservices-januari-2010.html
will redirect to :
m.klikkarir.com/5215/lowongan-call-center-accounting-administration-pt-asia-teleservices-januari-2010/
somebody help me.
I use http://detectmobilebrowser.com, and found it is the quickest and easiest way. It works quite well. This site generates server scripts automatically (php, perl, python, coldfusion, apache, jquery, etc.) that detects mobile browser and redirects accordingly. You can just copy and paste the code somewhere in your Index file.
The best method is to use WURFL to detect if a mobile device is hitting your page, several (php,java,c++) interfaces exist.
If you want to have simpeler but less accurate solution a quick useragent comparison might be sufficient, example.
You could try the Mobify Me service, there is a free version too.
Off topic, Start accepting answers
I believe there are three ways to go about this first detecting the screen size by number of pixels. I have tried this method and It works within parameters (HD and high resolution screens on mobile devices vs older low resolution desktop screens) another approach suggestion several places (http://www.inmotionhosting.com/support/website/how-to/mobile-redirect) is to use the .htaccess file. The idea here is to screen browsers on their acceptance of mobile MIME types - as I suspect there is no great push for full screen devices to take mobile MIME types this seems fairly reliable with the caveat that on tablet devices you may get the mobile version when they are capable of handling the main version. The third of course is to use the script solutions noted above.
Luck
DPR
I'm looking for best-practices for designing a site that with accessibility in mind. The site is going to have a lot of older and less-abled individuals visiting it, and I want to make it as friendly for them as possible. Is there a resource that describes all the right tags, and attributes to use?
There are many many resources depending on your goals.
Strongly suggest you start with:
Section 508 (US legislation, obviously US centric though)
W3C's Web Accessibility Initiative and Web Content Accessibility Guidelines
edit:
Forgot to mention that WCAG has come in for some considerable criticism which makes this guy's efforts very helpful.
Also wanted to add, from personal experience, to remember that WA doesn't mean "blind people with screen readers". There are all manner of access limitations which you have to think of as well: e.g. dexterity issues related to e.g. muscle control, unusual input devices, and simple screen magnification.
Good luck!
Here's a quick list I tend to follow
Ensure it uses clean XHTML markup ideally to AAA standards,
Try where possible to spilt HTML, CSS, Javascript into respective files,
Create different style sheets for print, screen, etc.,
Ensure you take into consideration colours and fonts for the hard of sight and colour blindness,
Try to only place the main navigation at the top of the code so that the actual content appears near the top of the code, this way people do not have to scroll to far to see the content especially if they are using a screen reader / low res,
If you do have a lot of navigation before the content then place a link near the top allowing users to skip to the content,
Ensure the very first link on the page is to a text-only / low graphics version of the site,
Ensure ALL pages and all Essential functionality will work without JavaScript turned on,
There are lots of plugins for firefox to assist with development including:
Web Developer
No Script
HTML Validator
Firebug
Ensure the page renders across all browsers including old ones even if that means it works though does not match design exactly.
Ensure HTML, CSS, JavaScript is kept to the minimum file size to aid downloading times e.g. Remove white space and blank lines,
Always use LABELS in forms and alt, title tags in links and images,
Only use Tables for tabular data and ensure data appropriately labelled,
Where possible do not use JavaScript to write content to a page but use CSS to hide it, that way is JavaScript is disabled or does not work properly then content will still appear,
Always ensure you use onkeypress as well as onclick events in JavaScript encase the user can not / is not using a mouse.
Finally if you have to use blank images on a page for tracking etc. then don't give them Alt tags. This is my own view and is one which is hotly debated on-line especially when 1x1px images used to be used for spacing. However as far as I see it, if you are using a screen reader then you don't what it reading out stupid comments for images it does not need to see.
Try looking at Wikipedia's article on Web Accessibility. It contains lots of links to various sources of information for different countries, which may be useful depending on your target audience. The W3C was one of the original standards, but has plenty of critics.
Among other things.. provide "alt" and "title" attributes for every "img" tag.
Get a text-only browser like lynx. If your site works in lynx, it's likely to work for people who need screen readers or have other handicaps. It's no substitute for looking up the regulations, but it's a quick and easy check.
For another perspective, see the Dutch Government Web Guidelines.
The government provides a standard called section 508 that lays out what makes a site compatible.
A good resource is found at W3C site: Web Content Accessibility Guidelines.
A few things to keep in mind:
have a CSS link on each page that easily allows the font size to be changed.
Visually try to have appropriate presentation that is easy to read in a backwards S fashion.. left to right, back down.. etc..
ensuring that all the alt tags, etc, as mentioned in the other responses is vital.
see if there are some disability websites out there that specialize in testing your site. no harm in seeing what they list as being important to do.
make sure things are easy to read and find. this alone will make the job much easier.
There are many many resources on this topic. In fact, the danger is of information overload, rather than not enough information.
But an alternative approach is to think about your HTML page in generic terms, rather than the visual output you see in the web browser. If you wrote a piece of software that interpreted the website what would be helpful? This is a round-about way of saying use good semantics. My top tips would be to use standard XHTML for content and CSS for design. Also look up topics such as "progressive enhancement" and "behavioral Javascript".
But for resources:
The W3C's Web Accessibility Initiative: www.w3.org/wai
www.WebAIM.org
www.Accessify.com
www.CSSZenGarden.com for inspiration on how semantic markup can be styled to look very different.
It hasn't been mentioned yet so I figure I would mention it. If you want blind users to be able to use your site avoid flash. At the most 1% of flash I find on the internet is accessible.
A good list of resources about accessibility (colourblind screen-reader,typography etc) is here in design way.
For validation of web site and general documentation I use the W3C.
If you're developing in asp.net the opensource NAAK tool might be useful.
A must read is Jeffery Zeldman's "Designing with Web Standards"
Not sure if you are using Dreamweaver, but he has also just realeased a toolkit to validate your site for accessiblity.
There are probably thousands of applications out there like 'Google Web Accelerator' and all kinds of popup blockers. Then theres header blocking personal firewalls, full site blockers, and paranoid cookie monsters.
Fortunately Web Accelerator is now defunct (I suggest you read the above article - its actually quite funny what issues it caused) but there are so many other plugins and third party apps out there that its impossible to test them all with your app until its out in the wild.
What I'm looking for is advice on the most important things to remember when writing a web-app (whatever technology) with respect to ensuring the user's environment isnt going to break it. Kind of like a checklist.
Whats the craziest thing you've experienced?
PS. I may have linked to net-nanny above, but I'm not trying to make a porn site
The best advice I can give is to program defensively. For example, don't assume that all of your scripts may be loaded. I've seen cases where AdBlocker Plus will block 1/10 scripts that are included in a page just because it has the word "ad" in the name or path. While you can work around this by renaming the file, it's still good to check that a particular object exists before using it.
The weirdest thing I've seen wasn't so much a browser plugin but a firewall/proxy configuration at a user's workplace. They were using a squid proxy that was trying to remove ads by replacing any image HTTP request that it thought was an ad with a single pixel GIF image. Unfortunately it did this for non-GIF images too so when our iPhone application was expecting a PNG image and got a GIF, it would crash.
Internet Explorer 6. :)
No, but seriously. Firefox plugins like noscript and greasemonkey for one, though those are likely to be a very small minority.
Sometimes the user's environment means a screen reader (or even a braille interface like this). If your layout is in any way critical to the content being delivered as intended, you've got a problem right there.
Web pages break, fact of life; the closer you have been coding and designing up against standards, the less your fault it is.
Something I have checked in the past is loading some of the more popular toolbars that people tend to install (Google, Yahoo, MSN, etc) and seeing how that affects the users experience.
To a certain extent it is difficult to preempt which of the products you mentioned will be used by your users since there are so many. I would say your best bet is to test for the most frequent products that your user base may employ and roll with the punches for the rest. If you have the time to test other possible scenarios, by all means do.
Also, making it easy for your users to report possible issues also helps lessen the time it takes to get a fix in place should it be something you can work around.
MSDN makes it sound so easy to detect a mobile browser:
if (Request.Browser["IsMobileDevice"] == "true" )
{
Response.Redirect("MobileDefault.aspx");
}
Actually, it looks like you can also just check Request.Browser.IsMobileDevice. But how does this actually work? I don't even have a .browser file... what's going on behind the scenes here? Are there some built-in defaults for ASP.NET 2.0?
A number of *.browser files are shipped with .NET:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
The runtime uses regular expressions from the *.browser files to match against the incoming User-Agent string, and then sets a bunch of properties based on each match it finds (there can be several in the hierarchy).
If you need in-depth mobile device support, consider installing the MDBF, which adds support for about 400 devices:
http://mdbf.codeplex.com/
Now, after 4 years, it's even more simple
Request.Browser.IsMobileDevice
Since for most sites, it is actually the size of the screen that matters and not so much the capabilities (at least when talking about modern phones with things like Safari and Chrome on them) wouldn't checking the resolution make the most sense?
Request.Browser.ScreenPixelsHeight
and
Request.Browser.ScreenPixelsWidth
I wouldn't rely on the MSDN link, there is no common standard unfortunately for mobile browsers and many try to mimic their non-mobile counterparts. Also it will return true if it doesn't recognize. See this link.
My current understanding is that there's just one exact solution to the problem of detecting whether a browser is mobile and next detecting its real capabilities. This solution is ScientiaMobile's WURFL (http://www.scientiamobile.com). Which, as of Aug30, is no longer free for every use. WURFL is now released with an ASP.NET API under AGPL. The data repository also comes with a specific license that disallows both copying and using with APIs different from the standard one (unless one purchases a commercial license).
So for practical purposes other approaches such as 51Degrees cannot be used with more recent and future versions of the WURFL repository and this will make it difficult for 51Degrees to detect new devices (Windows Phone 7.5, for example).
As for MDBF (a dismissed project), it may still work to detect whether a device is mobile (much better than the IsMobileDevice in ASP.NET). It is not entirely reliable as far as properties of the device are concerned. It insists that my HTC Desire Android has a 240x320 screen size, which is patently incorrect.
My company bought a WURFL license and we're absolutely OK with that.
Issues has been resolved while I added 51Degrees, just add 51degrees using Nuget thats all. See more here https://51degrees.codeplex.com
Simply use below code,
if (Request.Browser.IsMobileDevice)
{
Response.Redirect("MobileDefault.aspx");
}