WiX Template for Installing a Windows Service

The following is a lightweight template that allows you to create an installer for your Windows Service and dependent files. The following assumes that the WiX Toolset v3.7 is installed on the development machine. First, do the following to your application project:

• Right click in the design window for your class, and select “Add Installer”.
  

Then, create your setup project:

• To your solution, add a new Wix Setup Project.
  
• Add a reference to your service application project.
• Add references to WixNetFxExtension.dll and WixUIExtension.dll from C:\Program Files (x86)\WiX Toolset v3.7\bin\
  

The template follows. Replace instances of MyProduct with your product name, and MyCompany with your company name.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Name="MyCompany MyProduct" 
             Id="*" 
             UpgradeCode="{INSERT-A-NEW-AND-UNIQUE-GUID-HERE}" 
             Manufacturer="My Company" 
             Version="!(bind.FileVersion.MyProduct.exe)" 
             Language="1033">
        <Package InstallerVersion="200" 
                 Compressed="yes" />
        <Media Id="1" 
               Cabinet="media1.cab" 
               EmbedCab="yes" />
        <Directory Id="TARGETDIR" 
                   Name="SourceDir">
            <Directory Id="INSTALLDIR" 
                       Name="PFiles">
                <Directory Id="MyCompany" 
                           Name="MyCompany">
                    <Directory Id="MyProduct" 
                               Name="MyProduct">
                        <Component Id="MyCompany.MyProduct" 
                                   Guid="{INSERT-A-NEW-AND-UNIQUE-GUID-HERE}">
                            <File Id="MyProduct.exe" 
                                  Name="MyProduct.exe" 
                                  Source="..\MyProduct\bin\Release\MyProduct.exe" 
                                  Vital="yes" 
                                  KeyPath="yes" 
                                  DiskId="1" />
                            <File Id="MyProduct.exe.config" 
                                  Name="MyProduct.exe.config" 
                                  Source="..\MyProduct\bin\Release\MyProduct.exe.config" 
                                  Vital="yes" 
                                  KeyPath="no" 
                                  DiskId="1" />
                            <ServiceInstall Id="ServiceInstaller" 
                                            Type="ownProcess" 
                                            Vital="yes" 
                                            Name="MyCompany:MyProduct" 
                                            DisplayName="MyCompany:MyProduct" 
                                            Description="My Product Description" 
                                            Start="auto" 
                                            Account="LocalSystem" 
                                            ErrorControl="ignore" 
                                            Interactive="no" />
                            <ServiceControl Id="StartService" 
                                            Start="install" 
                                            Stop="both" 
                                            Remove="uninstall" 
                                            Name="MyCompany:MyProduct" 
                                            Wait="yes" />
                        </Component>
                    </Directory>
                </Directory>
            </Directory>
        </Directory>
        <Feature Id="ProductFeature" 
                 Title="MyCompany:MyProduct" 
                 Level="1">
            <ComponentRef Id="MyCompany.MyProduct" />
        </Feature>
    </Product>
</Wix>




Tất cả lập trình đều là lập trình web ?

Trong một bài dịch của bạn Hồ Hữu Hùng trang Vinacodedịch lại bài “All Programming is Web Programming” của tác giả Jeff Atwood viết ngày 14 tháng 8 2009. Jeff Atwood là một lập trình kỳ cực, sáng lập nên StackOverflow, một trang web hỏi đáp hàng đầu của dân tin học. StackOverflow viết bằng ASP.net, csdl: SQL Server. Nếu một ngày bạn không lượn vào StackOverflow quá 2 lần, chứng tỏ bạn chưa thực sự lập trình.

Tôi xin góp vài ý sau đây:
Tại thời điểm mà Jeff viết đang có một cuộc chiến giữa Microsoft ASP.net IIS Window Server và LAMP (Linux Apache MySQL PHP). Microsoft rất lo lắng trước sự gia tăng của mã nguồn mở. Tải về rồi cài, thích thì sửa, không thì cấu hình, mua theme giao diện về là có web site. chi phí thuê share hosting server Linux chỉ khoảng 5 USD/tháng. Trong khi xài Microsoft rất lằng nhằng về license, vậy là Microsoft nghĩ ra là phải làm cho việc lập trình web trên nền tảng Microsoft dễ đến mức không thể dễ hơn. Sự đơn giản này cũng như cách dùng CPanel cài một web site bằng WordPress step by step đã giết chết nhu cầu học lập trình một cách nghiêm túc. Ai cũng có thể tạo một web site. Hướng đối tượng là gì? Cấu trúc dữ liệu giải thuật là gì? Bộ nhớ heap, stack, con trỏ là gì? Mức độ phức tạp O là gì? Generic Programming, Machine Learning là gì? là những câu hỏi quá xa xỉ bởi giờ đây, chỉ cần xem video hướng dẫn, bạn có thể kéo thả ra một web site mà không mất một dòng code.

Tôi đã từ dùng Visual Studio 2012 beta, lúc đó Microsoft có một công cụ rất dị, LightSwitch. Chỉ cần vẽ giao diện các trường nhập liệu, thêm chút validation, Microsoft tự sinh ra cơ sở dữ liệu rồi cấu hình tự động lên tài khoản Azure. Ấn một nút run, là có luôn web site, thậm chí có lựa chọn tạo ra Desktop app. Tất cả mất tầm 10 phút. Kỹ sư trưởng của Visual Studio gọi lập trình đơn giản như bật công tác đèn ~ Light switch.

LightSwitch

Tôi bắt đầu lo cho nghề nghiệp của tôi. Tôi sắp 37 tuổi. Cứ đà này, dăm năm nữa, con người chắc khỏi kéo thả mà cứ nói chậm chậm, máy tính sẽ hiểu rồi tự đưa ra các giải pháp có sẵn, người dùng lựa, xác nhận là có một web site. Thất nghiệp đến nơi rồi !

Điều trở thành sự thật là Apple có Siri, Microsoft có Cotana, nhận dạng tiếng người rất chuẩn. Còn ứng dụng web kiểu kéo thả của Microsoft không nhận được ủng hộ của lập trình viên. Bạn thử tìm kiếm “Light Switch Job” mà xem. LightSwitch tự động, kéo thả ở nhiều khâu quá, khiến cho việc chỉnh sửa chi tiết sau này vào code trở nên khó khăn. Lập trình viên trở nên thụ động hoặc là họ cảm thấy sự sáng tạo của họ đã bị thay thế với một công cụ máy móc tạo ra sản phẩm hàng loạt giá cực rẻ. Có lẽ Microsoft đã định làm một cuộc cách mạng kéo thả WYSIWYG đối với ứng dụng web. Nhưng vì trào lưu Responsive ra đời, khiến việc kéo thả WYSIWYG trở nên không khả thi nữa. Mình nghĩ vậy…

Tóm lại ngày hôm nay (2014), làm một ứng dụng web nghiêm túc không thể kéo thả bừa được. Chính vì vậy Adobe DreamWeaver không còn là công cụ số 1 để làm web nữa, WebFusion cũng chết từ lâu.

Dream Weaver

Đúng là công việc lập trình web trở nên rất phổ biến nhưng nó sẽ không phải là tất cả. 2009 đến 2014 chứng kiến chu kỳ bùng nổ của ứng dụng di động trên IOS, Android và Windows Phone. Rất nhiều lập trình viên web chỉ có kỹ năng kéo thả, cấu hình đã cảm thấy bất an khi công việc ngày càng trở nên bèo bọt và việc lập trình di động ngày càng nhiều, thành công cũng lớn và mức độ khó, cạnh trạnh cũng tăng. Thế là người ta nghĩ ra PhoneGap, Cordova, jQuery Mobile, Kendo UI…để web dev nhanh chóng trở thành mobile dev.

Nhưng rồi đến năm nay 2014, người ta bắt đầu phàn nàn sự đi xuống trông thấy của các ứng dụng hybrid app so với native app. Tham khảo bài này The State of Native vs. Web vs. Hybrid.Người dùng di động trở nên khó tính hơn, đòi hỏi app phải mượt, đẹp, trải nghiệm không được giật, tối ưu cho từng hệ điều hành di động một.

Như vậy là lập trình web không phải là tất cả, lập trình di động đã tăng, và yêu cầu phải học bài bản hơn, kỹ càng hơn.

Có những video, tuts dạy tạo ra một web site (dạng To Do List, lịch sử từ demo của Ruby On Rails, hay PetShop của Java) hoàn thành trong 15 phút là cách để lôi cuốn lập trình viên dùng những framework này. Nó tiện, MVC ngon, code ít, convention over configuration… đó chỉ là chương nhập môn thôi. Vấn đề phức tạp vẫn còn đó rất nhiều: trải nghiệm người dùng (UX), phù hợp với nhiều màn hình (responsive), tăng hạng khi được tìm kiếm (SEO), tốc độ – khả năng chịu tải (performance -load), cách thức cập nhật thông tin chủ động hơn (reactive programming thay vì thụ động kiểu request – response), lưu-truy vấn dữ liệu phi cấu trúc (noSQL), phân tích dữ liệu lớn ra sao (big data)
Lập trình web mà giỏi hết những thứ trên chắc cần học – thực hành liên tục trong 7-10 năm rồi đó.

Kết luận là các bạn trẻ, bạn lập trình già hãy học CNTT nghiêm túc, liên tục. Đọc nhiều, code nhiều, đừng ngừng lại.
A- “Tất cả lập trình không phải là lập trình web”
B- “Lập trình web không đơn giản”.

——-Bài dịch của bạn Hồ Hữu Hùng. Cảm ơn tác giả đã có bài dịch rất hay ———–
Michael Braude đã công khai chỉ trích về sự phổ biến của lập trình web:

“Lý do mà hầu hết mọi người đều muốn lập trình web là bởi vì họ không đủ thông minh để làm bất cứ việc gì khác. Họ không hiểu về trình biên dịch, concurrency, 3D hay lớp kế thừa. Họ không có một manh mối gì về việc tại sao tôi lại sử dụng một interface hay một lớp abstract. Họ không hiểu về: các phương thức ảo, con trỏ, tham chiếu, bộ dọn rác, finalizers, truyền tham chiếu hay tham trị, các hàm hủy ảo trong C++, hay sự khác nhau giữa struct và class trong C#. Họ cũng không biết về các quy trình phát triển phần mềm như: Waterfall (thác nước), Spiral (xoắn ốc), Agile? Hãy quên tất cả những thứ đó. Họ cũng chưa bao giờ nhìn thấy một tài liệu phân tích yêu cầu (requirements document), họ cũng chưa bao giờ viết ra một tài liệu thiết kế (design document), họ chưa bao giờ vẽ ra được một lược đồ UML, và họ thậm chí còn chưa bao giờ nghe nói tới sequence diagram.

Nhưng họ biết làm một vài thứ: họ biết làm thế nào để ném ra một trang web ASP.NET, viết một số câu lệnh SQL (với cú pháp rất dở) để truy lục cơ sở dữ liệu, rồi đổ vào một dataset, và hiển thị kết quả lên lưới (grid control). Họ chỉ biết có bấy nhiêu đó. Và chắc chắn là trình độ cũng chẳng phát triển được gì hơn.

Xin thứ lỗi cho tôi vì việc đã xúc phạm, nhưng nói thực tôi không có một chút hứng thú nào để trở thành một ‘gã phát triển web’. Vì có hai lý do cho điều này. Thứ nhất, nó không đủ độ thách thức đối với tôi. Và thứ hai, bởi vì phần lớn các công ty Internet thì chứa đầy những kỹ sư tồi – đúng là như vậy bởi vì bạn không cần phải biết những thứ phức tạp để trở thành một tay phát triển web. Và tôi cũng đang lo xa rằng, Internet sẽ phải chịu trách nhiệm cho việc tập hợp của những thứ vớ vẩn và làm giảm giá trị trí tuệ của chúng ta. Bạn không cần phải thông minh để làm ra một trang web.

Tôi thực sự hy vọng rằng mọi người đã sai và mọi thứ không “chuyển hết sang môi trường web”. Bởi vì nếu điều đó xảy ra, một ngày nào đó hoặc là tôi sẽ phải miễn cưỡng gia nhập phong trào tẻ nhạt này, hoặc là tôi sẽ phải chuyển sang một ngành khác.”

Hãy để qua một bên, trong chốc lát, sự tranh cãi ngớ ngẩn về việc cho rằng phát triển web thì không thách thức, và rằng nó chỉ thu hút những lập trình viên kém chất lượng. Thậm chí nếu điều đó có đúng đi chăng nữa, thì nó cũng không thích hợp chút nào.

Tôi ghét việc phải nói một tin xấu tới Michael, nhưng bởi tỷ lệ phần trăm người dùng web đang tăng lên, thì có thể nói rằng các ứng dụng trên desktop đã chết. Hầu hết các ứng dụng desktop điển hình đã bị thay thế bởi các ứng dụng web trong mấy năm vừa qua. Và rất nhiều trong số chúng bị thay thế mỗi ngày, khi mà các trình duyệt web ngày càng trở nên mạnh mẽ, nhiều khả năng và sức mạnh hơn xưa.

Bạn hy vọng rằng mọi thứ không “chuyển hết sang môi trường web” ư? Tỉnh lại đi anh bạn! Điều đó đã xảy ra rồi!

Bất kỳ sinh viên của ngành lịch sử máy tính nào cũng sẽ nói với bạn rằng sự thống trị của các ứng dụng web là chính xác như cái mà nguyên tắc về sức mạnh tối thiểu đã dự đoán:

“Ngành Khoa học Máy tính đã mất 40 năm để làm cho các ngôn ngữ lập trình trở nên mạnh mẽ nhất có thể. Ngày nay chúng ta phải đánh giá cao những lý do cho việc chọn những giải pháp không phải là mạnh nhất mà là giải pháp ít sức mạnh nhất. Ngôn ngữ lập trình càng ít sức mạnh, thì bạn sẽ càng làm được nhiều thao tác dữ liệu trong ngôn ngữ đó. Nếu bạn viết nó bằng một hình thức đơn giản, thì bất kỳ ai cũng có thể viết một chương trình để phân tích kết quả từ nó. Ví dụ, một trang web cung cấp thông tin về dự báo thời tiết sử dụng RDF (một kiểu lưu giữ liệu đơn giản theo chuẩn XML) để mô tả dữ liệu của nó, thì một người dùng có thể truy lục nó như là một table, có thể tính toán trên nó, vẽ đồ thị, suy luận mọi thứ về nó trong sự kết hợp với những thông tin khác. Còn nếu theo một hướng khác là trang thông tin thời tiết này được viết bằng một Java applet tinh xảo. Trong khi điều này có thể mang lại một giao diện người dùng rất ấn tượng, nhưng nó lại không thể phân tích được chút nào cả. Những bộ máy tìm kiếm khi tìm thấy những trang web này sẽ không biết dạng dữ liệu của nó ra sao và nội dung của nó đang nói về cái gì. Chỉ có một cách duy nhất để biết cái Java applet đó đang nói về cái gì là chạy nó hiển thị trước mặt một con người bằng xương bằng thịt.”

Môi trường web là tiêu biểu cho việc làm ra những thứ đơn giản nhất mà có thể vẫn hoạt động tốt. Nếu điều đó làm bạn kinh hãi — hoặc làm bạn bối rối — thì tôi xin khiêm tốn để nói với bạn rằng bạn không có tố chất để trở thành một lập trình viên.

Có phải tất cả các ứng dụng đều nên trở thành ứng dụng web không? Dĩ nhiên là không. Sẽ vẫn tiếp tục có những trường hợp ngoại lệ quan trọng và những loại phần mềm mà không có gì để làm đối với web. Nhưng chúng chỉ là những ứng dụng thiểu số và quá đặc thù. Đó là những ứng dụng ngách quan trọng mà thôi.

Nếu bạn muốn phần mềm của mình được trải nghiệm bởi nhiều người dùng nhất có thể, thì không có cách nào tốt hơn là nên phát triển nó dưới dạng một ứng dụng web. Dạng web là cách hiệu quả nhất, lan tỏa nhất và hầu như có thể phân tán ngay lập tức. Bất kỳ người dùng nào chỉ cần một đường truyền Internet và một trình duyệt, bất kỳ họ ở đâu trên thế giới, thì với chỉ vài cú click chuột là đã có thể tương tác với phần mềm mà bạn viết ra. Người dùng tiếp cận đến thậm chí cả những ứng dụng web dở nhất . Đó là lý do tại sao tôi lại đúc kết ra một điều luật cho chính mình, tôi tạm gọi nó là Atwood’ Law:

“Atwood’s Law: bất kỳ một ứng dụng nào mà có thể viết bằng JavaScript, thì cuối cùng nó sẽ được viết bằng JavaScript.”

Viết ứng dụng giống Photoshop, Word, hoặc Excel bằng JavaScript thì mới nghe tưởng chừng như là hoang tưởng, nhưng điều đó là không thể tránh khỏi. Nó sẽ xảy ra. Thực tế, nó đã và đang xảy ra. Bạn hãy nhìn xung quanh mà xem.

Là một lập trình viên phần mềm, tôi hạnh phúc nhất khi sản phẩm mình viết ra được người dùng đón nhận. Điều gì là đáng nói nếu phần mềm của bạn thường đi theo một lộ trình cố định là đầu tiên nó được đóng gói trong các file nhị phân, sau đó nó được mua và cấp license và tải về và cài đặt và bảo trì rồi cập nhật? Cùng với tất cả những công đoạn cũ kỹ này, đó là những rào cản truyền thống giữa lập trình viên và người dùng, tôi lấy làm ngạc nhiên khi ngành công nghiệp phần mềm vẫn còn được tổ chức theo cách này. Nhưng trong thế giới mới của lập trình ứng dụng web, những hạn chế này đã không còn nữa. Không có ranh giới nào nữa. Phần mềm của bạn có thể sử dụng ở bất cứ đâu.

Lĩnh vực lập trình web thì còn lâu mới đạt đến mức độ hoàn hảo. Nó thực ra còn nhiều thứ cần phải cải tiến. Bất kỳ một tay Coder nào cũng có thể đẻ ra một ứng dụng web tồi, và có đến 99% các ứng dụng web là hoàn toàn dở ẹc. Nhưng điều này cũng đồng nghĩa có những lập trình viên tài năng đang giới thiệu những sản phẩm của họ đến hàng trăm, hàng ngàn, có thể thậm chí hàng triệu người dùng, điều mà họ chưa bao giờ có thể mơ tới ở thời trước khi có web. Không có gì buồn và lãng phí tiền bạc hơn khi sản phẩm của mình chết ẻo và không được ai biết đến mà sử dụng. Việc viết phần mềm dưới dạng ứng dụng web cho phép các lập trình viên đưa sản phẩm của họ đến trước mặt một ai đó, ở một nơi nào đó. Thậm chí nếu sản phẩm đó rất tồi.

Nếu những tranh luận về người dùng và nghề phần mềm vẫn chưa đủ để thuyết phục bạn, thì chúng ta hãy quan tâm đến góc độ kinh doanh:

“Bạn đang làm một ứng dụng web, phải không? Giờ không phải là thời điểm của những năm 80 nữa. Ứng dụng web của bạn dù đang lộn xộn và dở dang thì vẫn nhiều thành công hơn những phần mềm hoành tráng của đối thủ được viết dạng ứng dụng desktop.”

Không lâu nữa, tất cả lập trình sẽ là lập trình web. Nếu bạn không nghĩ rằng đó là một lý do để chúc mừng những lập trình viên bình thường, thì có thể bạn nên tìm một nghề khác.

Source: http://techmaster.vn/2014/10/tat-ca-viec-lap-trinh-deu-se-la-lap-trinh-web/

Is Your Responsive Design Working? Google Analytics Will Tell You

Responsive web design has become the dominant method of developing and designing websites. It makes it easier to think “mobile first” and to create a website that is viewable on mobile devices.

In the early days of responsive web design, creating breakpoints in CSS for particular screen sizes was common, like 320 pixels for iPhone and 768 pixels for iPad, and then we tested and monitored those devices. As responsive design has evolved, we now more often start with the content and then set breakpoints when the content “breaks.” This means that you might end up with quite a few content-centric breakpoints and no particular devices or form factors on which to test your website.

However, we are just guessing that our designs will perform well with different device classes and form factors and across different interaction models. We need to continually monitor a design’s performance with real traffic.

Content-centric breakpoints are definitely the way to go, but they also mean that monitoring your website to identify when it breaks is more important. This information, when easily accessible, provides hints on what types of devices and form factors to test further.

Google Analytics has some great multi-device features built in; however, with responsive design, we are really designing for form factors, not for devices. In this article, we’ll demonstrate how WURFL.js and Google Analytics can work together to show performance metrics across form factors. No more guessing.

Why Form Factor?

Speeding up and optimizing the user experience for a particular device or family of devices is always easier. In reality, though, creating a device-specific experience for all types of devices is not feasible, given that the diversity of web-enabled devices will just continue to grow. However, every device has a particular form factor. Luke Wroblewski, author of Mobile First, outlines three categories to identify device experiences:

• usage or posture,
• input method,
• output or screen.

Because devices vary between these categories, we get different form factors. Hence, treating form factor as the primary dimension through which to monitor a responsive website makes sense. This will indicate which type of device to test for usability.

The examples in this article all use WURFL.js, including the form factors provided by it, which are:

• desktop,
• app,
• tablet,
• smartphone,
• feature phone,
• smart TV,
• robot,
• other non-mobile,
• other mobile.

Feeding Data To Google Analytics

The first step is to put WURFL.js on the pages that you want to track. Simply paste this line of code into your markup:

<script type="text/javascript" src="//wurfl.io/wurfl.js"></script>

This will create a global WURFL object that you can access through JavaScript:

console.log(WURFL.form_factor);

Now that the script tag is in place, the only other thing to do is add the highlighted lines of code to Google Analytics’ tracking code:

/* Google Analytics' standard tracking code */
_gaq.push(['_setAccount', 'UA-99999999-1']);
_gaq.push(['_setDomainName', example.com']);
_gaq.push(['_trackPageview']);

/* Tell Google Analytics to log WURFL.js' data */
 _gaq.push(['_setCustomVar', 1,’complete_device_name’,WURFL.complete_device_name,1]);
 _gaq.push(['_setCustomVar', 2,'form_factor',WURFL.form_factor,1]);
 _gaq.push(['_setCustomVar', 3,'is_mobile',WURFL.is_mobile,1]);

/* The rest of Analytics' standard tracking code */
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

Or, if you have updated to Google Analytics’ new “Universal Analytics“, you would add this:

/* Google Analytics' new universal tracking code */
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-99999999-1, 'auto');

/* Define the custom dimensions */
ga('send', 'pageview', {
  'dimension1': WURFL.complete_device_name,
  'dimension2': WURFL.form_factor,
  'dimension3': WURFL.is_mobile
});

Further, if you are using GA Universal Analytics, you must remember to define the custom dimensions. You do that by clicking Admin → Custom Definitions →Custom Dimensions.

For Universal Analytics you need to define the custom dimensions in the Admin section. (Large preview)

Analyzing The Data In Google Analytics

Now that the data is in Google Analytics, we need to make it available for inspection. We can use custom variables in Analytics in a number of ways, the most obvious being to look in the menu on the left and click Audience →Custom → Custom Variables:

“Custom Variables” report. (Large version)

If you are are using Universal Analytics, you’ll have the custom dimensions available as any other dimension in all reports in GA:

Accessing custom dimensions. (Large preview)

Already, we’re getting a pretty good picture of how form factors behave differently. The best metrics to focus on will obviously depend on your website, but in general, pay attention to bounce rate and pages per visit.

BIG PICTURE WITH DASHBOARD WIDGETS

With dashboards in Google Analytics, we get a high-level overview of the most important metrics. This is a good place to monitor how your website performs across form factors. Once again, bounce rate and page impressions per visit are good metrics to start with. The purpose of the dashboard widgets is to alert you and to visualize how your website’s performance changes for certain form factors.

Let’s create a few widgets to display the status of different form factors. First, create a pie-chart widget that shows how much your website is being used by different form factors.

Widget displaying form factors. (Large version)

In the Dashboard, click Add Widget, select Pie, then the Sessions metric, and group it by the form factor custom variable. Note that the label in the green drop-down list is Custom Variables, not the actual name. In our example, theform factor variable is in the second slot, but make sure to choose the right slot if you’ve implemented it in a different order. Again, if you have converted to Universal analytics, the procedure is similar, but in stead of selecting custom variables, you simply add the name of your custom dimension as you would with any other dimension.

Next, create a few widgets to display visits and bounce rates per form factor. The widgets will indicate whether changes to the website have had a positive or negative impact. Obviously, you want higher visits and a lower bounce rate.

Creating a “form factor” widget. (Larger version)

Create this widget by adding a filter to the standard metrics. Choose a timeline diagram and filter the data with your custom variable where you have stored the form factor. Create one widget for each of the form factors that you want to monitor:

“Form factor” widgets in the dashboard. (Large version)

You might find that some form factors disappear in the statistics for global bounce rates because the data set is now bigger (as in the example above). As indicated by the red arrows, something dramatic has happened with smartphones and feature phones. Specifically, some changes were made to the landing page to increase traffic from tablets, and the changes clearly had a negative impact on traffic from smartphones and feature phones. Identifying the reason for the drop in traffic requires more fine-grained Analytics reports, and the drop might not have been easy to spot without having monitored form factors.

FORM FACTOR SEGMENTS

Any custom variable that you put into Google Analytics is, of course, available in most reports as filters or dimensions, so tweaking them to your needs is quite easy. Another way to keep form factors at the top of mind is to put them in segments by creating conditions. Here is one segment per form factor that you’ll want to track:

Configure a segment. If you’re using Universal Analytics, you must use your custom dimensions rather than the custom variables. (Large version)

The same, but in Universal Analytics:

(Large preview)

Google Analytics will show these segments in most of its standard reports as separate dimensions in charts and tables:

Segments chart. (Large version)

You can make “form factor” a dimension in most reports. As mentioned, bounce rate and general engagement are key metrics to follow, but goals and conversion rate are obviously interesting, too. You might find the need to create new goals or at least review your funnel for certain form factors.

After monitoring form factors for a while, you might conclude that you need to offer different user experiences for one or more form factors. Furthermore, you might need to tweak goals, funnels and advertising campaigns to account for differences in usage per form factor or device type.

We have used Google Analytics here, but WURFL.js is, of course, compatible with other analytics tools, as long as custom variables like the ones above are allowed.

Conclusion

In this article, we have looked at how performance per form factor is a key metric for monitoring a website and how WURFL.js and Google Analytics help to visualize this data. Once you put WURFL.js’ data into Analytics, it will be available in most standard reports as filters or dimensions, so tweaking the reports to your needs is quite straightforward. And the dashboard widgets will give you a high-level overview of their status. Also, bounce rate and page impressions per visit are key metrics, at least to start; so, defining form factors as segments will give you nice visualizations in most standard reports.

As a next step, look into conversions and goals in Google Analytics to see how to integrate and monitor form factors, which will vary according to the website’s function and purpose. To give you a head start, we have made atemplate that you can install in your Google Analytics dashboard (This template uses custom variables, not custom dimensions). Just follow the instructions to assign an Analytics property, which will then appear under Dashboards →Private.

(al, ml, il)