I would like to use this JS plugin to use the CSS template layout :
http://code.google.com/p/css-template-layout/
But I know that it is recommended to first have a website working without JS. So, my project consist in doing a tourism website...will I lose a lot of 'potential user' if JS is required to visit my website ?
Tkx,
About 4% of my visitors don't have javascript support includes bots though, that would explain quite a few percent. There are a few classes of browser that won't run your javascript as intended:
Screen readers/accessible browsers (like for blind people)
Mobile browsers
Console-based browsers (Used sometimes by sysadmins from servers with no gui installed)
Off-brand browsers or older browsers with buggy javascript engines
Search Engines (Google)
I don't think that many people just turn javascript off anymore. However, things like NoScript --where javascript is disabled for a site initially and must be explicitly enabled-- are becoming more popular.
The problem is more apparent on mobile browsers, but you will likely serve different content to them anyway.
Related
For example, we have a cool styled website, can we use developer options(f12) from browser to snatch this?
Ignoring any legal / copyright implications, you can grab the client-side code this way, yes. All HTML, CSS, JavaScript and imagery can be seen through the F12 Developer Tools.
However, there is no way to know what server-side code a website is using (outside of the server owner themselves configuring something incorrectly and thereby exposing that information).
The answer from Obsidian Age is a good one. I'm going to add some more information that may be useful to you.
I've used this technique myself of getting source code via the developer window. Usually I want to find out how they did some neat CSS or JS trick so that I can try it in my own apps.
The files that make up a website such as HTML, JavaScript, and CSS you can find in the Network tab and can easily copy these.
However you should know the JS, CSS, and even (sometimes to a degree) the HTML files have been minimized and are typically missing any comments from the original developers. Chrome has a nice feature that will un-compress JS files and you can even set break points and step through the JS code.
I know that Apple products like the iPad or the iPhone have trouble with flash apps.
What web development tools should I use in order to avoid compatibility issues when creating a website? My only constraint is that the languages must provide for interactivity and animation - such as in jQuery.
HTML, CSS, and PHP are a few that I can think of that will behave on 99% of all internet enabled devices.
What tools & languages are available to use when creating a website intended to be viewed on any device's internet "explorer"?
Should I just stick to HTML, CSS, & PHP? I want a certain level of interactivity so that, for example, a user can hover over images and have pop-ups containing data to appear... or when an object is clicked, an action can happen without a page reload.
Can someone point me in the right direction and help me develop a list of languages that are all-device friendly?
I am familiar with programming in several web-focused languages, I'm just wondering which ones to stay away from. Certain ones will limit the devices that can view the site and besides that constraint, the site needs to be interactive and animated.
HTML, CSS, PHP, JQUERY are truly your best bet for developing for a wide range of devices. If the scope of devices is the main goal I would stay away from using HTML5 and CSS3. You still may run into problems using much jquery with IE7 below. Mobile browsers on the other hand are much more advanced or up to date with standards then desktop browsers. I would suggest creating two versions of your application. One dedicated to running on mobile devices and one for desktop browsers. It is a shame apple wouldn't support flash applications. If all you need is hoovers for interaction you won't even need jquery / but for the other it will be useful.
The "Web" is a name for the concept of having interlinked documents accessible over the internet. Therefore, to have a website you really only need a document able to link to other documents, namely HTML.
HTML is not really a programming language or a tool though, it is a document format.
If you want to make a website you need use HTML to Markup what you're writing. Then you use CSS to format different sections of the document you marked up.
PHP though, is completely separate from this, PHP is for creating dynamic HTML, or any document on the server side.
If you want to achieve a flash-effect on a site you use Javascript to modify the page content (HTML) and appearance (CSS).
If you need to learn HTML/CSS I would highly recommend http://htmldog.com/
As per the question, HTML CSS and Javascript are pretty much the only mobile-browser compatible method for website content as they don't need plugins.
What exactly are you trying to do?
Basically I am currently doing some research, and I am interested to find out how I could render web pages without a browser: I have some algorithms that I would like to run to calculate the visual aspect of each blocks of DOM node(s) for each page.
What you're asking for basically, is a browser rendering engine, otherwise known as a layout engine... For example, Firefox uses the Gecko layout engine to render the pages. Theoretically, you could adopt this engine for whatever project you're working on, saving you a lot of time.
The Gecko engine is used in more projects than just Firefox, and since it's open source, you could easily get the source code and try to throw it in an application.
Wikipedia has a nice list of layout engines, so there are other alternatives to Gecko, like GtkHTML.
Basically, you want to create the data structures a browser internally creates so that it knows how to render the page.
Check out the Firefox source.
I suspect it's rather complex.
I'm tyring to get phonegap up and running on blackberry storm (9530 simulator). I had been testing my webapp from withing BB's built in browser, and it was looking ok, but then it totally bit once I tried to look at the some code from within phonegap, even though I was pointing phonegap to the same url (I hadn't yet gotten to the point of running code locally on the device).
I tried a test case on google and got similiar results. see below. I suspect that I'm missing something basic here. I would have expect both images to be nearly identical.
Browser
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530WebGoogle.jpg
Phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBB9530PgGoogle.jpg
[Update]
To shed some light on what is happening, I ran the browser and the embedded browser (phonegap) against the W3 mobile web acid test: http://www.w3.org/2008/06/mobile-test/
I definitely notice differences between the two, but I don't yet know the 'why' and the 'how-to-address'.
Acid via built-in browser
(source: eleganttechnologies.com)
BTW - I ran this earlier today and got a couple more green square than just now.
Acid via browser embedded into phonegap
http://www.eleganttechnologies.com/outside/ImgDeviceBb9530PgAcid.jpg
Disclaimer: I don't know anything about phonegap, but have a pretty good theory. By default the embedded browser control on BlackBerry uses an older version of the rendering engine than the BlackBerry browser itself does.
At the BlackBerry developer conference last year, a talk was given about this, and there's an undocumented option to use the newer rendering engine. \
The option ID is 17000 (yes, a magic number, which could change, use at your own risk etc), and should be set to true. Not sure how you'd pass this option through phonegap (I'm not familiar with the toolkit) but using the BlackBerry APIs it's something like:
BrowserContent content;
...
content.getRenderingOptions().setProperty(RenderingOptions.CORE_OPTIONS_GUID, 17000, true);
I don't know the specifics of the browsers you are using, but I do know that most of the big sites will detect your OS + browser combination to decide what HTML to show you.
If Google is seeing a different user agent, you might get a generic mobile version of the HTML instead os the Blackberry specific HTML you get for the built in browser.
If you have access to a web server, try hitting it with both browser setups and see if there is any difference in the log file. That might tell you something interesting.
As we can see in your Acid tests...
One browser (the built-in one) is reporting correctly as a BlackBerry9530, and the other (phonegap) is not presenting the user-agent ["Testing with ."].
In this case, Google is providing you with the default view of their homepage, whereas when you are reporting yourself as a BlackBerry device, you will get the BlackBerry specific rendering.
By the sounds of things, using phonegap is removing the default user-agent (most probably because it's not recognising your device). As phonegap is open-source, the best bet is to get in there, and debug it and find out what happens with the user-agent when the http requests leave the device and track it back from there.
Maybe one browser has capabilities that another one does not?
Hm. By looking at the screenshot I would say that the second page is probably missing some resources. It may be missing some images, scripts and the CSS files, which would explain different l&f. Knowing how Blackberry Browser Field API works, I would guess that the implementation that uses the BrowserField was not done correctly. Just my guess. In addition to that, when the browser field is initialized the caller needs to configure it properly by enabling the appropriate browser features - scripts, styles etc. Again, the API is done in a very weird way, I have gotten myself into this trap once. When setting the options, you cannot just create one mask (like CSS | WML | SCRIPT) and make one call. Options are numeric and, I believe, non-overlapping - but you still need to call the API for setting each option independently.
Also the way asynchronous loading of the resources for BrowserField takes time to understand.
Just my $0.02.
How can i start the development of a site that can be browse from mobile phones? For example, if you browse Gmail site from an iPhone the site looks different from the normal site. You have to design two differents sites to do this? How can I know if the site is accessed by a mobile browser?
You don't HAVE to design two different sites, but you probably want to if it's important to let mobile users access your site.
There are a few ways to deal with this problem, each with pros and cons. I'm assuming that your site has its information in a database, and publishes that data using a set of templates? (Like a Ruby on Rails or Django site; a PHP site; a blog; etc.) If you've hand-coded a bunch of static HTML pages, this is going to be way more labor intensive for you.
1: Same HTML, different stylesheets for SCREEN and MOBILE
The idea: You deliver the same HTML structure to all requests. You create a stylesheet for SCREEN and one for MOBILE.
Good: For you, the programmer. It's easier for you to maintain 2 stylesheets than it is to maintain 2 totally separate template sites.
Bad: For your users. A site that's easy to use on a mobile device usually is inefficient for a normal browser; and sites optimized for a desktop / laptop often fail miserably on a mobile device. Obviously it depends on how you code your pages, but in most cases, pushing your normal site to a mobile browser will be bad for your users. (See http://www.useit.com/alertbox/mobile-usability.html for a summary of Jakob Nielsen's recent usability research on mobile sites.)
2: Maintain separate sites
(Gmail maintains even more than 2 systems! They basically have different container applications / templates that process the same data: the full AJAX browser version; the plain HTML browser version; a basic mobile version; a native Blackberry application; and a native iPhone application.)
This is the emerging standard for sites that really care about having both a mobile and desktop presence. It's more work for you, but in general it's much better for your users.
On the upside, you can probably create one stripped down pure HTML site that works for mobile and that acts as a fallback for the rare web user who doesn't have javascript, or who has major accessibility issues that prevent them from using the "full" site.
Also, depending on your user base: in the US, people generally have access to a desktop / laptop, and use their mobile devices for auxiliary access. For example, I book my plane tickets and rental car using my desktop computer, but I want to look up my reservation code on my mobile. In many cases, you can get away with limiting the functionality that you offer on the mobile site, and require the full computer to perform uncommon use cases.
The basic procedure:
Design & build UIs for mobile and screen.
Launch the sites at two different URLs; the emerging convention is www.yoursite.com for the desktop version, and m.yoursite.com for the mobile version. (This allows users to browse directly to m.yoursite.com if they know of the convention.)
On www.yoursite.com, sniff the user agent and test to see if the user's browser is mobile. If so, direct the user to m.yoursite.com.
There are sniffers written in various server languages (PHP, Perl, whatever) that you can probably use. Check the licenses. Here's an example of a sniffer written in php.
From Wikipedia's article on user agent sniffing: "Websites specifically targeted towards mobile phones, like NTT DoCoMo's I-Mode or Vodafone's Vodafone Live! portals, often rely heavily on user agent sniffing, since mobile browsers often differ greatly from each other. Many developments in mobile browsing have been made in the last few years, while many older phones that do not possess these new technologies are still heavily used. Therefore, mobile webportals will often generate completely different markup code depending on the mobile phone used to browse them. These differences can be small (e.g. resizing of certain images to fit smaller screens), or quite extensive (e.g. rendering of the page in WML instead of XHTML)."
On m.yoursite.com, provide a link back to www.yoursite.com. Users who click on this link should NOT be redirected back to the mobile site, and how you accomplish this depends on your implementation.
You may want to follow Quirksmode for his emerging articles about mobile testing.
3: Templates output different data chunks depending on the user-agent, and maintain separate stylesheets
Like (2), this requires you to sniff the user agent. Unlike (2), you're still using all the same page logic and don't have to maintain two separate sites. This might be okay if you're just dealing with a blog or website that's mostly about reading data.
In your template code, you can say things like
if( $useragentType != mobile ) {
echo( 'bigBlockOfRelatedArticlesAndAds.php' );
}
This lets you mostly maintain one set of template files. You can also streamline the pages that you're sending to your mobile users, so they don't get a big bloated page when they just wanted to read your blog post or whatever.
The majority of mobile devices these days support "mobile stylesheets" which are simply alternate stylesheets to display things simpler. You can add a mobile stylesheet to your site in the normal way and include the media="handheld" attribute:
<link rel="stylesheet" type="text/css" href="/mobile.css" media="handheld" />
Then those styles will apply to mobiles.
The only problem with this method is if your HTML is bulky, it may take a while for the page to load since most mobile browsers are slower (except Opera Mini). That's why the bigger sites like flickr and digg use separate sites.
Additional notes:
Bulky HTML doesn't affect Opera Mini as much because it uses a proxy which does the rendering externally then sends a special "image" to the device.
Use simple, clean HTML then you can send the same to normal browsers and mobile devices
You'll have to check on the combinations of stylesheets with media attributes. IIRC adding the code above will make browsers ignore the first stylesheet. If you add media="all" to the first one, both will be used (and you can thus override the original styles rather than start afresh).
For checking how a weppage looks in a mobile Browser use Opera Mini Emulator
Check out the WURFL project. Its intention is to help developers target multiple phone browsers, and started way back before there was Mobile Safari, back in the days of HDML, WAP and XHTML-MP. It's up-to-date however, storing capabilities of modern devices such as iPhone. It has data on over 400 devices, and has libraries in Java, PHP, Perl, Ruby, Python, .NET, C++. Depending on how broad you want to target your mobile app it's something to look at. Here's a list of sites that use WURFL.
Another related project written by Luca Passani (the co-founder and maintainer of WURFL) is Switcher. You can use this to automatically redirect to the mobile version of your site.
Keep it simple, think opera mini and you will get it right.
(iPhone has more off a normal browser...)
Focus on content
Avoid plugins
Follow the web standards
Separate content from layout/design, use css as much as posible.
Use text and pictures.
Add the rest of the bells and whistles if you must, but make sure the the site:s content is always available even when the bells and whistles are turned off.
If you can browse the page with a simple browser like lynx and normal browser like firefox then you are on the right track.
For more info feel free to visit the any browser campaign
Edit: In case it is not obvious you work with different css for different types of browsers, but always use the same content.
Visit the css zen garden for a nice demo.
Update:
Adding a link to css media types, and as stated by others it is the handheld option that is interesting.
http://www.w3.org/TR/CSS21/media.html
You have to design two differents sites to do this?
Yes
How can I know if the site is accessed by a mobile browser?
Your programming language has probably some way of looking through the client's information. PHP, for example, has a superglobal variable $_SERVER that has all kinds of information of both the serving server, and the visiting client. In this case, you would be interested in the value of $_SERVER['HTTP_USER_AGENT'], which would give the following result, should I visit a page:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
This tells you that I'm running Mac OS X 10.5.6, using Safari 4.0. There are known keywords for various mobile browsers. One version of iPhone's browser, for example, has the following user agent:
Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3
the "iPhone" already gives it away, but is further confirmed by the keywords "Mobile" and "Safari"
Most sites have a slightly different sub domain for mobile sites (most use "m"). e.g. flickr uses m.flickr.com
(there is a recommendation to use the .mobi TLD but I've never seen that used)
Make the design super simple, don't use too many graphics, where you need to keep them as small as possible.
This might be helpful for the design.
I would probably construct a different set of pages for mobile users, making use of the same business objects etc. as you're using for the main site.
If the differences between the design of the two sights isn't to great you might be able to get a way with just serving separate CSS files?
Your site should limiited to the mobile phone which can support on maximum requirements. you can not even entertain all the mobile phone.
Your web site should have different set of css style, and HTTP AGENT must check the client type according to the request Css selection should take place .