Do front-end developers need any special considerations for the Amazon Silk Browser because of it's split architecture and it's re-sizing of images? Or can it be considered as just another webkit browser from a developer's perspective?
In general, you can develop content for Amazon Silk as you would for any other browser. The EC2 backend follows all standard caching semantics, and the media handling is as you'd expect.
In general, it's a good idea to set the height and width attributes explicitly on images and other page elements, and to design responsively for the form factor. In other words, the standard web development best practices apply.
In general I've found Silk - especially the newer versions - to behave as a pretty standard WebKit browser. Some of the Apple specific tuning isn't there so testing against Chrome on the desktop has been the closest experience (though one caveat there is that Chrome does seem to take webkit fixes faster than anyone else)
I've not seen anything that would indicate that accelerated browsing does anything different for EC2 hosted content - As hosted content often comes from a number of sources I don't expect they'd split traffic on internal and external networks though it sounds like something worth asking in the forums at forums.developer.amazon.com/forums/category.jspa?categoryID=3 to get an official answer
Related
I am writing a detailed estimate for a client (project has been accepted but it is now a matter of explaining the different functionalities) to develop a responsive layout website.
It is not my first development of that kind, but this one is a key account and path must be paved.
The layout will adapt from 300px width to 1200+px and thus virtually to "any" device and browser, but i am a little lost on my commitment to that. With desktop websites it is easy to write in your contract that the supported browsers will be "IE7+, up-to-date versions of FF, Safari, Chrome, Opera", but what do you write about a responsive website?
I have a bunch of devices that i know i'll perform tests with (let's say a PC, a Mac, iPad, iPhone, 2 or 3 Android devices) but what do i say to my client?
I can't write that the "website will work on any device", nor can I give an exhaustive list of the combinations of devices/browsers it will work on. And i don't want to be stuck with "my uncle has seen the website on his 2.2 Android old phone and it doesn't work".
There are a lot of desktop tools around to simulate various viewports and perform tests on, but they hardly work as the "real thing" ; or is there one standard we developers can refer to "contractually"? How do you manage that and what are your commitments towards your clients?
Take on a Progressive Enhancement approach for development. It isn't possible to get a website to be pixel perfect and work the same on every single browser.
Take of a tiered approach (Gold/Silver/Bronze). Old and untested browsers will get the content (IE7, older blackberry, older anything). Newish browsers get content and layout nice (IE8/9, Firefox < 4). And Modern browsers get a typical nice modern website.
It's possible to set this up with appropriate thinking. Build it from the bottom up. Bronze to Silver to Gold. Start with the very minimum setup (only colour, font, text. No divs, no layout, nada). This is your bronze. Next get the silver level setup. Include layout. This layout would be for smaller screens. And finally we would have gold. This would include media queries for larger screens and JS for increased usability and niceties.
It is possible to split between Bronze and Silver for the layout by wrapping your layout within #media only screen{} query. Older browsers do not understand it. The content still appears on those browsers. To split between Silver and Gold it's simply put in a min-width media query and you're set.
Also, ensure that the client understands the definition of "website will work on any device". Just because Opera Mini doesn't support line-height doesn't mean the site doesn't work on it. Here is an article that Brad Frost wrote on that subject: Support vs Optimization: http://bradfrostweb.com/blog/mobile/support-vs-optimization/
I hope this helps a bit
What devices/browsers to target with a responsive layout
You should be targeting a minimal resolution and not a device or browser. You should re-size your design and watch for the design to no longer work comfortably and then use media queries to respond and adapt the design.
Clients:
I think ideally you're looking for a way to explain the concept to customers. What you need to do is communicate the goal, which is to provide the best experience possible. I have found that you should be honest with your customer, let them know that you are following industry best practices and the design will be "functional" across the majority of devices and browsers on the market.
Here is a blurb that I like to use:
Compatibility across platforms: Due to the vast number of web
browsers, platforms and devices, the user experience of the website
may change to best fit the viewing platform.
If you would like to explain, or are asked to explain what this means, I would say:
We(I) always use best practices to meet industry standards for web
design. We(I) do our(my) best to insure that the design will be
"functional" on all main stream platforms. Because of the increasingly
vast number of web accessible devices available, I can not guarantee
that the design will look identical from one device to another.
You must also consider that new devices are created all the time. So you don't want to make your statement too concrete or you will be retrofitting you designs to accommodate the next iWatch or iFridge that hits the market.
Remember to communicate what is really important, that the content gets displayed. For the most part text and images should work almost anywhere. It's the fancy stuff like shadows, rounded corners, video (IE7), and media queries that don't always work but shouldn't obscure content.
Also, web applications can be a bit tricker since some form elements don't work across devices & browsers. (ex: File uploads).
Hopefully this helps.
I'm not a contract lawyer, you may want to run this across a paralegal or law savvy friend for further advice.
Having gone through this experience a lot of times these are the key points i tend to show to client to make them understand the concept.
What is cross browser, platform (OS), screen resolution and device screen size. I tend to take latest screenshots or links of W3C stats to show them some trends in past 2 years and where this market is going. it clearly convince them that they need a responsive layout.
If they want further evidence to these i show them twitter bootstrap and jquery UI and jquery mobile sites on at least 2-3 devices using Adobe Edge Inspect. Laptop, Tablet and Phone can be all on same network and just browse through the site to show them how it responds to different sizes.
I have a list of pros and cons collected over time for IE7, IE6, Chromeframe, Android native browser vs Chrome on Android, IPhone4 vs iPhone5 browser. usually i see which way they are more inclined and if its phone i will make them aware of pros and cons of that market. Most of the time they should understand that its not an app but a responsive site.
When you are writing a proposal do not put in "We will cover for all devices". You can never do that. Be realistic. Create virtaul machine and simulators to test at least the framework you are going to use before making these claims in writing. Setting up VM or Virtual Box is free and you can get Linux and eclipse or netbeans to run dummy phone and tablet and browse your framework on it.
For screen resolution and screen size again W3C stats are very realistic and convincing. Use them and use Resolution test kind of plugins in firefox or chrome and take some screenshots of your past work or just the framework so you can at least show the goodness involved or limitation of what can be done and cannot be done.
Most of the answers here are quite right just wanted to add how you can use both W3C and statistics to convince on the route for responsive layout. There are more than million sample sites online to convince people now and for past 6 month i have found that people do get convinced by step 1 alone.
It's quite clear. Your client wants a modern website. However, all browsers don't support all the modern features. Your client wants to spend money wise and have a site that improve through time. Not grow old soon and new bugs emerge as new browsers are released. This is why Graded Browser Support is for: http://jquerymobile.com/gbs/
Site will be usable with all the browsers. Mainstream browsers will get enhanced user experience. Most modern browsers will get the super cool newest goodies.
Let the client know, the more you "hack" the site to get some feature to work with some defect old browser, the more likely it will break on the new ones. It's not worth the time and money.
Here is what I do when designing responsive websites.
When an old or unsupported browser is detected, the website will simply exclude the jQuery elements that make it responsive, so the result is a fixed width site.
Now, what do you tell your client?
Just be frank. Tell them you made your website responsive for the modern devices out there. For the older devices, their website wont be so good-looking. Show them a couple of examples too. Some big companies, simply display a alert telling the user their browser it outdated and the website won't work properly. One example is Google.
So, essentially, your website works with all devices, but looks better and is responsive on the modern devices and browsers out there.
This spec http://www.w3.org/TR/webdatabase/ says:
This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.
Does this mean that HTML5 database is going away, and for some time we will have a de-facto standard using SQLite, possibly with browser differences? Or has the W3C published a plan of attack for finishing the standard?
According to this article:
[...] we think it is worth explaining our design choices, and why we think IndexedDB is a better solution for the web than Web SQL Database.
In another article, we compare IndexedDB with Web SQL Database, and note that the former provides much syntactic simplicity over the latter. IndexedDB leaves room for a third-party JavaScript library to straddle the underlying primitives with a BTree API, and we look forward to seeing initiatives like BrowserCouch built on top of IndexedDB. Intrepid web developers can even build a SQL API on top of IndexedDB. We’d particularly welcome an implementation of the Web SQL Database API on top of IndexedDB, since we think that this is technically feasible. Starting with a SQL-based API for use with browser primitives wasn’t the right first step, but certainly there’s room for SQL-based APIs on top of IndexedDB.
I'm not personally swayed by the arguments put forth in the article, but it seems clear that (for the time being) Mozilla has decided that Web SQL Database is dead.
Further interesting comments about this article may be found on Hacker News.
My understanding is that this is now called "IndexedDB"
http://www.w3.org/TR/IndexedDB/
Apparently the Firefox team has started implementing this:
http://hacks.mozilla.org/2011/01/indexeddb-in-firefox-4/
I don't know if anyone knows the answer. Mozilla doesn't like the dependence upon SQLite and has decided to go a different way. However, all WebKit based browsers already have it implemented and I don't see them removing it as any websites built to take advantage of the spec would be broken.
This means that at least in certain contexts, mostly within the mobile sphere where most browsers have a webkit implementation, it can still makes sense to use the HTML5 Web SQL spec. I see this as especially true for developers who are looking to create mobile applications using a framework like phonegap.
There are some times where as an application developer you want to provide users with access to data even if they aren't connected to the internet or if the connection is slow and some types of data is just more efficiently stored in a database than in a cookie or JSON cashe. For example, if you have data that has relationships it is much easier and quicker to do a join query to pull the data you need than it is to search a json map.
I don't think the spec is dead, and I actually hope that Mozilla will reverse their stance so that developers can use it to solve problems outside of the mobile webkit world.
I am nearly finished a web application. I need to test it and find the security issues before it release. Is there any methods / guideline to do this kind of testing? Or is there any tools to help me check my application is ready to go online? Thank you.
I would say:
check that there are no warnings or errors even in strict mode (error report).
In case you store any sensitive data (as passwords, credit cards, etc.) be sure they are encrypted with non-standard algorithms. Use SSL and try to be somehow paranoid with it.
Set your database with specific accesses by action and hosts, and do not use root account.
Perform exhaustive testing (use unit test when possible). Involve as many people you can.
Test it under the main browsers (Firefox, Chrome, Opera, Safari, IE) and if have time in others.
Validate all your HTML/CSS against standards (W3C). (recommendable)
Depends on the platform you are using, there are profilers which can help you identify bottlenecks in your code. (can be done in later stages).
Tune settings for your web server / script language.
Be sure it is search-engine friendly.
Pray once is online :)
This is not a complete list as it depends in:
which language/platform/web server you are using.
what kind of application you developed (social, financial, management, etc.)
who will use that application (the entirely world, an specific company, your family or just you).
are you going to sell it? then you must have at least most of the previous points.
is your application using very sensitive information (as credit cards)? if so, you should pay for some professional (company?) to check your code, settings and methods.
This is just my opinion, take it as it is. I would also like to hear what other people suggests.
Good Luck
As well as what's already been suggested, depending on what type of application it is, you can use a vulnerability scanner to scan your application for any vulnerabilities that could lead to hackers gaining entry.
There are quite a few good scanners out there, but note when using them that the results may or may not be 100%. It's hard to say.
For a list of scanners, commercial and free, see: http://projects.webappsec.org/Web-Application-Security-Scanner-List
For more information on scanners: http://en.wikipedia.org/wiki/Web_Application_Security_Scanner
Good luck.
Here you can find a practical checklist to use before launching a website
http://launchlist.net/
And here is a list of all the stuff you forgot to test
http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf
I'm working on a large site’s re-write and redesign. I have been reading up on HTML 5 and wanted to know what the cons are before adopting it for this design implementation.
The design needs to work in A-grade browsers (yes including IE6 :( ), so I'm wondering how <footer> / <section> etc will be rendered (inline/block etc.).
I'd also like to know the pros so that I can sell it to any conservatives within the business.
If we disregard the things which are unchanged since HTML 4.01…
Pros? Not a lot. There are a few things which work in a minority of browsers. There are a few things which work in a minority of browsers but with added JavaScript can support most browsers in a relatively sensible way.
As for cons…
The whole spec is still a draft, and subject to change.
Practically nothing in the spec is supported consistently across browsers (and faking it with JS fails when JS isn't around)
QA tools are immature and often lag behind the specification
It's useful as something to experiment with, but I wouldn't build a mainstream website with it.
Pros:
The more sites are using it, the faster we'll have a reliable spec and support across browsers. So just by building your new site with HTML 5, you help speeding up the advancement of web technologies for all of us.
Cons:
Incomplete QA tools
Incomplete native browser support
The argument that the whole spec is still a draft doesn't really count. Just look at CSS. Even the latest changes to the CSS 2.1 recommendation still have draft status.
If you want to use the HTML 5 specific elements, take a look at http://ejohn.org/blog/html5-shiv/. This approach allows you to use the HTML in browsers that don't support them now.
HTML5 isn’t one thing. There are some parts of HTML5 you can use right now.
For instance, you can change your doctype to the HTML5 one (<!doctype html>). Boom. Your document is now HTML5. Because the HTML5 spec was based on a lot of work figuring out what browsers already do, things like this just work. So, if you prefer the HTML5 syntax, feel free to do that now.
As for the new elements, as has been mentioned, they’re lacking support in IE. You can shim quite a lot of support for HTML5 into IE with JavaScript, if you’re happy with that. Note that unknown HTML elements are displayed as inline by all browsers, so you’d need to add display: block; for new block-level elements yourself for older browsers.
Dive into HTML5 is well worth a read to get you up to speed, particularly Chapter 3.
There are no cons - most of the things will work just as they do in XHTML 1.0 or HTML 4.01. Pros will slowly come in next few years, but bring more semantics (and somehow easier understanding of the content by search engine bots from SEO point of view). HTML 5 moreover enables designers to use any web fonts (not just the limiting basic five such as Arial/Helvetica, Verdana, Times New Roman etc.)
see this as well:
http://www.alistapart.com/articles/semanticsinhtml5/
http://www.zeldman.com/2009/07/13/html-5-nav-ambiguity-resolved/
http://www.zeldman.com/2009/07/20/web-fonts-html-5-roundup/
What are the most common things to test in a new site?
For instance to prevent exploits by bots, malicious users, massive load, etc.?
And just as importantly, what tools and approaches should you use?
(some stress test tools are really expensive/had to use, do you write your own? etc)
Common exploits that should be checked for.
Edit: the reason for this question is partially from being in SO beta, however please refrain from SO beta discussion, SO beta got me thinking about my own site and good thing too. This is meant to be a checklist for things that I, you, or someone else hasn't thought of before.
Try and break your own site before someone else does. Your web site is basically a publicly accessible API that allows access to a database and other backend systems. Test the URLs as if they were any other API. I like to start by cataloging all URLs that have some sort of permenant affect on the state of the system - this is easy if you are doing Ruby on Rails development or trying to follow a RESTful design pattern. For each of those URLs, try running a GET, POST, PUT or DELETE HTTP methods with different parameters so that you can ensure that you're only giving access to what you want to give access to.
This of course is in addition to obvious: Functional testing, Load Testing, SQL Injection, XSS etc.
Turn off javascript and make sure your site can still be navigated.
Even if you want to ignore the small but significant number of people who have it disabled, this will impact search engines as well.
YSlow can give you a quick analysis of different metrics.
What do friendly bots see (eg: Google); check using Google Webmaster Tools;
Regarding tools for running functional tests of a web pages, I've found that Selenium IDE to be useful.
The Firefox (version 2 only compatible at the moment) plug in lets your capture almost all web events, and save them and replay them in the same browser.
In conjunction with another Firefox https://addons.mozilla.org/en-US/firefox/addon/1843"> Firebug
you can create some very powerful tests.
If you want to set up Selenium Remote Control
you can then convert the Selenium IDE tests into nUnit tests, which you can run automatically.
I use cruise control and run these web tests as part of a daily build.
The nice thing about using Selenium remote control is that it can run the same functional tests on multiple browsers and operating systems, something that you can't do with the IDE.
Although the web tests will take ages to run, there is an version of Selenium called Selenium Grid that lets you use any old hardware you have spare to run the tests in parallel as part of a computing grid. Not tried this myself, but it sounds interesting.
All of the above is open source and free which helped me convince management to use if :-)
For checking the cross browser and cross platform look of your site, browershots.org is maybe the best free tool that can safe a lot of time and costs.
There's seperate stages for this one.
Firstly there's the technical testing, where you check all technical functionality:
SQL injections
Cross-site Scripting (XSS)
load times
stress levels
Then there's the phase where you have someone completely computer-illiterate sit down and ask them to find something. Not only does it show you where there's flaws in your navigational logic (I find that developers look upon things way differently than 'other people') but they're also guaranteed to find some way to break your site.