Related
It seems every resource regarding things like CSS3 and HTML5 nag me about particular things not being implemented in older browsers, and hacky workarounds. Really who uses IE 9 or 10 anymore anyway? IE11 is out, Edge is default on W10, and I assume most / all people use it. To me it seems to make the most sense to simply make the page render properly on the latest Chrome (what I use), Firefox, Edge, and Safari..
Ughhh apple. My understanding is that the Windows version of Safari is very outdated and trying to get a (questionably obtained) image of macOS working in a VM has been unsuccessful. I'm not spending a dime for any Apple products just to test my site on their browser. So what can I do in order to test how my site will work in it?
Regarding your question...
Who uses IE 9 or 10 anymore anyway?
Typically, people with older Windows systems. This is important for your website based on whether or not IE 9/10 users will be accessing the website that is being supported. (A review of your website's web logs can shed light on this.) If your website is an internal intranet site, then an organization's IT department may dictate the browsers that users can use. However, large eCommerce websites will often support older browsers out of fear of losing customers to rivals.
Regarding your second question...
How do I go about ensuring the site is functional and looks reasonably
good on apple products conveniently, without any apple products while
on a minimal budget?
Without actual Apple products, something that emulates these displays is needed. One option is the "Inspect" option with the Chrome browser. (Display your website on Chrome, right-click, select "Inspect".) Inspect allows you to choose between a Desktop or Mobile display. With a Mobile display, you also have the option of selecting several Apple displays (e.g. iPhone, iPad, etc.). This is probably the next best thing to having the actual Apple device and its display for website testing.
I am developing a responsive website. For each and every change I made in javascript, css & html file, I need to test it in all possible screen size in portrait and landscape mode. Normally we used to test it in 3 to 5 different browser window size, and in portrait & landscape. I felt changing screensize and orientation again and again is a tedious job. So planned to write a tool, which will open multiple browser windows in a different screen size with the given url loaded in it. Any idea, or advice how to start this?
PS. If you are voting for deleting this question, please consider commenting with some suggestion how I can start, or is there any free tool available for this.
Thanks in advance.
There are number of great tools and services for helping test a website in just about every possible OS/browser/size these days.
BrowserStack.com allows you to pull up your website on nearly every combination of OS/browser/size and use the site to see how elements and features perform. There are other many other services that do this.
Another option would be a browser extension/plugin like Chrome's Window Resizer. It allows you to quickly toggle between common (and custom) window sizes. This is the most manual of the three options here, and the only free option.
One final option is Adobe's Edge Inspect. This app allows you to connect several devices to your computer and simultaneously browse a site across each of the devices. It also allows you to remote inspection on each of the connected devices.
Tools like Selenium can drive browsers and resize them as needed. Depending on the language of your choice, google for something like: selenium resize browser (language of your choice)
We are programming a web application (not 'just' a web site, but functionality-wise a real application), and have the following discussion for the next release:
our UI designer wants to replace the browser's right-click context menu (showing our own menu where appropriate, or no menu at all) because he wants the web app to be more like our (existing) Windows app
our developers (and I) strongly object because this is bad practice, and simply something you do not do in a web application
Thus, I'm looking for "more solid" arguments - like best practice guidelines, any statements from reputable sources, coding arguments etc. - for the pros and cons of this issue, which I can hopefully use to resolve it once and for all...
You can't do that reliably anyway. In Firefox, go to Settings, Contents, JavaScript/Advanced (I'm guessing the captions, no English Firefox (; ) to override context menu behaviour and bang, your app doesn't work anymore. My online-banking application did this in their old version, so I couldn't do copy & paste with the mouse. I hated it, so I enabled the protection in Firefox and it worked. Kind of. Their new version doesn't do such bad things anymore.
Instead, use a little drop-down arrow where a context menu is needed, that can either be clicked or just hovered over to show the menu. JetBrains' TeamCity web app does that very well.
If your application is to run in an intranet, maybe the UI designer arguments are valid: as long as all of the users of the application are well known and you want to emulate some Windows application, I think it's ok to restrict the right-click or any other input, because it's just the requirements of this application, as it would be to any other app.
But if your application is to run in the internet, disabling or replacing right-click is a very bad idea, and these are only some of the arguments I reminded of:
First of all, changing the behavior of the user interface is aggressive and annoying -- no one wants to get used to "new controls" just to access your site, and generally people hate to leave their comfort area. I mean, I know what my right click does and I want it to do always the same thing.
People can understand the difference between Windows apps and web apps, so there's no need to "emulate Windows app behavior".
Not everyone uses Windows :-)
Also, this is innefective, sice there are several ways to overwrite this behavior, such as settings in Firefox or even plugins that disable specific javascript instructions, such as this one.
depending on your audience you stand a very good chance your users do not even KNOW there's a right click menu. So please don't make this the only alternative
I personally believe you should leave browser's default behaviors alone... users are used to them, so no need to get them used to your way of doing things.
However, if you're building an intranet (instead of a public site), then I'm for tweaking as much as possible to improve usability.
An argument I would use (in quotes for dramatic effect):
Lack of consistency & reduced
functionality compared to other
unhindered web interfaces will lead to
a loss of user confidence - which
is undesirable to say the least.
Of course, if many or most of the web application users are already familiar with or regular users of the Windows app, the UI designer could be on the right track and the consistency with the Windows app could be a winner.
That said, in my opinion it's hard to make a custom context-menu within a web page intuitive, and while some users might warm to it, I'm guessing most will probably never use it.
because he wants the web app to be more like our (existing) Windows app
I think right-click in a Windows app is a bad idea.
In a web browser it's a UI disaster because nobody will be expecting it.
I think it depends on whether you perceive the context-menu as part of the browsers chrome or not. If you do (and I ascribe to this view), then it should be off target, but otherwise it is a good place for adding some usability to your application.
Replacing the browser right-click context menu for specific areas of your GUI from your web application can be quite useful. Doing this just to disable the context menu will annoy your users, who may try to find a way around it. Also, removing or replacing the browser right-click context menu from the entire area of your application will usually be annoying and can make it more difficult to debug.
Unfortunately, I cannot offer any more solid arguments, and I'm not exactly taking either side of the argument, but I thought I would share my experience both as a developer of a web application and as a web user.
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 .
I know this might be a no-brainer, but please read on.
I also know it's generally not considered a good idea, maybe the worst, to let a browser run and interact with local apps, even in an intranet context.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion. These folks are not particularly tech savvy; I don't even consider thinking that they could understand the difference between remote delivered applications and local ones.
So, I've been asked if it's possible. Of course, it is, with IE's good ol' ActiveX controls. And I even made a working prototype (that's where it hurts).
But now, I doubt. Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone? People will use the same browser to surf the web, can I fully trust IE? Isn't there a risk that Microsoft would just disable those controls in future updates/versions? What if a website, or any kind of malware, just put another site on the trust list? With that extent of control, you could as well uninstall every protection and just run amok 'till you got hanged by the IT dept.
I'm about to confront my superiors with the fact that, even if they saw it is doable, it would be a very bad thing. So I'm desperately in need of good and strong arguments, because "let's don't" won't do it.
Of course, if there is nothing to be scared of, that'll be nice too. But I strongly doubt that.
We use Citrix for home-office, and people really like it. Now, they would like the same kind of environment at work, a nice page where every important application/document/folder is nicely arranged and classified in an orderly fashion
I haven't used Citrix very many times, but what's it got to do with executing local applications? I don't see how "People like Citrix" and "browser executing local applications" relate at all?
If the people are accessing your Citrix server from home, and want the same experience in the office, then buy a cheap PC, and run the exact same Citrix software they run on their home computers. Put this computer in the corner and tell them to go use it. They'll be overjoyed.
Isn't it madness to allow such 'dangerous' ActiveX controls, even in the 'local intranet' zone ? People will use the same browser to surf the web, can I fully trust IE ?
Put it this way. IE has built-in support for AX controls. It uses it's security mechanisms to prevent them from running unless in a trusted site. By default, no sites are trusted at all.
If you use IE at all then you're putting yourself at the mercy of these security mechanisms. Whether or not you tell it to trust the local intranet is beside the point, and isn't going to affect the operation of any other zones.
The good old security holes that require you to reboot your computer every few weeks when MS issues a patch will continue to exist and cause problems, regardless of whether you allow ActiveX in your local intranet.
Isn't there a risk that Microsoft would just disable those controls in future updates / versions ?
Since XP-SP2, Microsoft has been making it increasingly difficult to use ActiveX controls. I don't know how many scary looking warning messages and "This might destroy your computer" dialogs you have to click through these days to get them to run, but it's quite a few. This will only get worse over time.
Microsoft is walking a fine line. On one hand, they regularly send ActiveX killbits with Windows Update to remove/disable applications that have been misbehaving. On the other hand, the latest version of Sharepoint 2007 (can't speak for earlier versions) allows for Office documents to be opened by clicking a link in the browser, and edited in the local application. When the edit is finished, the changes are transmitted back to the server and the webpage (generally) is refreshed. This is only an IE thing, as Firefox will throw up an error message.
I can see the logic behind it, though. Until Microsoft gets all of their apps 'in the cloud', there are cases that need to bridge the gap between the old client-side apps and a more web-centric business environment. While there is likely a non-web workaround, more and more information workers have come to expect that a large portion of their work will be done in a browser. Anything that makes the integration with the desktop easier is not going to be opposed by anyone except the sysadmins.
The standard citrix homepage (or how we use it) is a simple web page with program icons. Click on it, and the application get's delivered to you. People want the same thing, at work, with their applications/folders/documents. And because I'm a web developer, and they asked me, I do it with a web page... Perhaps I should pass the whole thing over to the VB guy..
Ahh... I know of 2 ways to accomplish this:
You can embed internet explorer into an application, and hook into it and intercept certain kinds of URL's and so on
I saw this done a few years ago - a telephony application embedded internet explorer in itself, and loaded some specially formatted webpages.
In the webpage there was this:
Call John Smith
Normally this would be a broken URL, but when the user clicked on this link, the application containing the embedded IE got notified, and proceeded to execute it's own custom code to dial the number from the URL.
You could get your VB guy to write an application which basically just wraps IE, and has handlers for executing applications. You could then code normal webpages with links to just open applications, and the VB app would launch them. This allows you to write your own security stuff (like, only launch applications in a preset list, or so on) into the VB app, and because VB is launching them, not IE, none of the IE security issues will be involved.
The second way is with browser plug-ins.
For example, skype comes with a Firefox plug-in, which looks for phone-numbers in web-pages, and attaches special links to them. When you click on these links it invokes skype - you could conceivably do something similar for launching your citrix apps.
You'd then be tied to firefox though. Writing plugins for IE is much harder than for FF, I wouldn't go down that path unless forced to.