Friday, September 14, 2012

HTML5 for any device? yet?

Mark Zuckerberg made an widely recognized statement  on the usage of HTML5 for mobile devices:

When I’m introspective about the last few years I think the biggest mistake that we made, as a company, is betting too much on HTML5 as opposed to native… because it just wasn’t there. And it’s not that HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.
source: http://blog.tobie.me/post/31366970040/when-im-introspective-about-the-last-few-years-i
A more technical detailed feedback is provided here: http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

This means two major things:
  • HTML5 is not ready yet (that is no real news) for a simple replacement of native apps
  • HTML5 is the major enabling technology to deploy feature rich content to the mobile web.
If you ever tried to create a productive web application using the HTML5 stack which should run on "all" common mobile devices you are aware that this is a pretty tough job and still requires to limit the functions to a small subset of functionality and as a result UI experience. In case you have to provide a feature rich application like Facebook you obviously have to workaround hundreds of issues and the result is still not sufficient for an individual user on one device.

A very helpful overview of the state of the different mobile browsers Facebook introduced ringmark a test suite (including results for most common mobile browsers) which shows which relevant API function is implemented on a particular mobile browser prioritized by different levels of importance.

The current state of the standards is published by W3C on a regular basis, latest release http://www.w3.org/Mobile/mobile-web-app-state/

What you see in the test results is that HTML5 can be used in case:
you want to deploy content driven application focus on online access and integration.

In any case you just have to start small, test and verify the behavior for your defined target audience. The HTML5 path is definitely the right path to follow but still requires lot of work from either the vendors and the standardization groups.

Thursday, September 13, 2012

First web page of the INTERNET

I'm not 100% sure but according to this article the first web page of the INTERNET was published by the W3C and is still available here http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html.

All links still OK.

In case you create a web page today with this amount of links and come back in 10 years - how many links still pointing to the correct content? Even if you only have links to self owned content. Do you think you are able to reproduce your targets in ten years?


Compare PDF in automated test scenarios

Do you ever had to test a process which creates a PDF based on well defined test data? You want to ensure that the result is equal or confirms to an given acceptance criteria which you can describe by an existing PDF? You want to automate this operation?

In this case you looking for a tool which compares two PDF files and at least provide you the answer to the question "are those two files the same?". Based on your use-case this means:
  • the contained text is the same on the same page of the PDF
  • the contained appearance (layout) is the same
In addition you need an command line interface to use the function within automated test procedure.

As you might know Adobe Acrobat provides a compare function which is very sufficient (see http://tv.adobe.com/watch/acrobat-tips-and-tricks/comparing-two-pdf-documents/)  but requires a commercial license and to integrate this function in your automated test environment isn't simple (from technical and commercial point of view).

Fortunately the tool comparepdf is available as free software. It is very simple to install, integrate and use. It provides different compare modes for the scenarios mentioned above. In addition a rough overview of the kind of difference is provided and can be used to integrate in automated test reports.

Once you have identified a difference you might be interested what and where the difference appearce. Therefore the GUI based DiffPDF tool can be used free of charge. Not as powerful as the Adobe Acrobat compare function but in many scenarios it helps to see whats going wrong without the need to buy a Adobe Acrobat license.