Web Sites - Better Result for Going Live

This presentation is about some of the best practices which can help ensure that quality results are obtained from going live with web sites. The main topic covered is the site verification process, that includes, but is not limited to a discussion of a pre-launch checklist. The talk is largely language-agnostic, although some of applies to implementation in a Apache / CSS / PHP / Javascript environment.

Transcript

1. What This Talk Will Cover  Introduction.  Background.  pre-launch verification – the checklist framework.  Overview of main areas to verify.  Pre-launch verification details.  Something extra.  Parting thoughts.  Conclusion.
2. Site “Go Live” – For Better Results Introduction  Some of the 3 or 4 top concerns over sites delivered:  Late delivery.  Cost overruns.  Product does not do what client expected it to do.  Quality issues.  For today’s topic; we focus on the last of the foregoing.  In particular, as pertaining to the “Going Live” stage. Site “Go Live” – For Better Results
3. Site “Go Live” – For Better Results Background - 1  Common to all dev. methodologies – to identify:  Something to be done was either: • Completed as required. • Or not done.  Some unplanned thing was done with unwanted results. Site “Go Live” – For Better Results
4. Site “Go Live” – For Better Results Background - 2  Rocket Science (R.S.):  What we do seems like R.S. to lay people.  But it can include processes that are simple: Pre-launch checklist!  Identify errors before they occur at “go live”. Site “Go Live” – For Better Results
5. Background - 3 Site “Go Live” – For Better Results “A pre-launch checklist entails a systematic approach to ensuring that important details get addressed before a launch”.
6. Site “Go Live” – For Better Results Pre-Launch Verification – A Checklist PROJECT: ___________________ “OWNER”: ____________________ TASK COMMENT 1.0 Section 1.1 Item 1 1.2 Item 2  Use for pre-launch verification a framework for the checklist such as: Site “Go Live” – For Better Results
7. Pre-Launch Verification - Main Areas:  Removal of Test Debris.  Text Spelling & Grammar.  Embedded images.  Correct Link Usage.  Privacy.  Functionality.  Cross-Browser & Monitor Compatibility.  Look and Feel.  HTML "Clean“, Complete?  Site Map, Site Navigation.  When Javascript off.  Legalities, Contact details.  Site Optimisation.  The "Live" or production site. Site “Go Live” – For Better Results
8. Pre-Launch Verification - Removal Test Debris.  All make-believe data that were used for testing been removed from the site and its files / tables?  Fake accounts.  Dummy content.  Fictitious customers.  Place holders.  Stubs.  Other similar.  All hard-coded links to the staging domain been changed to point to the ‘live’ URL/domain? Site “Go Live” – For Better Results
9.  Use of theme and logo.  Applic. of colour, shades.  Line weight of borders.  Shapes (e.g. All rectan- gular shapes have either rounded or sharp edges?)  Style and appearance of pop-up windows.  Icons (e.g. same icon represents “Go Back” link on every page).  Page positioning of menus and other navigation aids.  Footer position & content.  Size and font type of: • body text. • headlines.  Are 'bulleted' and numbered lists handled consistently throughout? (e.g. Each item ends with either periods only or commas only). Pre-Launch Verification – Look and Feel  Is the site consistent across all its pages w.r.t.:  Is a favicon or site icon included in the site's home page? Site “Go Live” – For Better Results
10. Pre-Launch Verification - HTML Clean, Complete  Does each site page have a suitable HTML title and meta description?  Is the text between the HTMl <Title>...</Title> tags consistent with the headline displayed on the same page?  For best results build your site with an IDE (e.g. Dreamweaver, Komodo, PHPStorm, etc.) or a framework, Otherwise:  Has the site had its HTML validated with a tool such “HTML Tidy” , the “W3C Validator” or other similar utility? Site “Go Live” – For Better Results
11. Pre-Launch Verification – Embedded Images  Does the site include an "ALT" attribute for the IMG tag with all instances of embedded images? (This is to provide for those cases where the user's browser prevents access to images)  Do IMG tags of all images embedded in the site include a “TITLE” attribute with a short description? Site “Go Live” – For Better Results
12. Pre-Launch Verification – Navigation & Site Map  Do site pages include all necessary aids (menus, back, forward, top and bottom buttons/links and where appropriate, "breadcrumbs“) to ensure that users can;  Easily navigate the site.  Know at any time where in the site they are.  Avoid finding themselves stuck in a "cul-de-sac“.  Are all these elements of navigation consistent in their appearance, in their page positioning and in their use?  Has a site-map been included with the web site and is it XML-based for Google's ease of use? Site “Go Live” – For Better Results
13. Pre-Launch Verification – Correct Link Usage  Links are shown on the site in a way, which makes it obvious to new users that they are links?  If links are underlined, are they the only text to be shown that way in the site?  Has the operation of all the site’s links been verified with the W3C Link checker or by clicking on all the links?  Do visited links get visually differentiated by the site from the others which have not been visited?  Are users appropriately redirected instead of given a “raw” Error 404 page, if they follow an inactive link? Site “Go Live” – For Better Results
14. Pre-Launch Verification – When Javascript off  Does the site provide a graceful degradation of its’ operation for those users who have turned off their browsers' Javascript?  At a minimum such users should be issued a message to advise them that they should turn on Javascript to obtain the site's full benefits. Site “Go Live” – For Better Results
15. Pre-Launch Verification – Privacy  Page Hiding: Does the site hide from search engines and casual visitors those of its pages, which are to be restricted from general access through an appropriate use of: ;  Robots.txt standard.  Htaccess (for Apache-server hosted sites).  Admin only password(s).  Access permissions: has access to admin. and other sensitive files been restricted on a “need-to” basis only, by a change of those files CHMOD default settings ( i.e have these been changed to a value other than “777”)? Site “Go Live” – For Better Results
16. Pre-Launch Verification – Legalities, Contact  Imprint – does the site state the name(s) and addresse(s) of its’ owner and author?  Have distinguishing names, phrases and graphics to be used by the site been already reserved by others for their own exclusive use?  Is the site's own copyright \ trademark staked out either in the "About" page or footer of the site's front page?  Does the site state a disclaimer and terms of service?  Are the address, telephone no. and e-mail address for the site's contact person(s) accurate, up-to-date?  Does the main page’s footer or the “imprint” include a back-link to www.YourCompany.co.za? Site “Go Live” – For Better Results
17. Pre-Launch Verification – Functionality  Do all of the site’s search functions work properly?  Are all columns of information with the lines that need to be sortable by a click on the corresponding column titles, working correctly?  Is the transition smooth (without jerking or margin displacements) from one page to the next?  Are all eMail generated by the site sent as intended?  Are all computations provided with the site giving correct results?  Are all calculations supplied in the site that yield results in decimals doing so to a consistent number of places? Site “Go Live” – For Better Results
18. Pre-Launch Verification – Site Optimization.  Check that the site references long Javascript or CSS Style sheets from external files and not from inline code.  If the site does have inline style code, this should be placed within the <HEAD> ...</HEAD> tags, to enable progressive rendering of the pages.  Does the site use compressed formats for its’ images?  Has the site been reviewed for reducing the number of any unnecessary HTTP calls?  Does the site apply GZIP (or similar) content-encoding for transfers across networks?  Is the site configured for optimum performance? Site “Go Live” – For Better Results
19. Pre-Launch Verification – Browser Compatibility.  Does the site operate with reasonable consistency across the 2 or 3 latest versions of the Internet Explorer, Firefox, Safari, Chrome and Opera browsers?  If the site was built on a MS Windows platform, how does it look on Apple and vice-versa?  Has the site's appearance been checked (as applicable) with the different resolutions of 800 x 600, 1024 x 788, 1280 x 1024, 1920 x 1200 ( and 320 x 480 for some mobiles’ access) ? Site “Go Live” – For Better Results
20. Pre-Launch Verification - Going Live:  Has the URL for the prod. site been bought & registered?  All needed mail box addres- ses been created, enabled?  Has hosting been arranged and confirmed with the I.S.P.?  Who has the necessary passwords for FTP access to, and admin. of the site, as well as to its data bases, if any?  Is the Go-live site set up?  Is there documentation for the I.S.P. name and any special considerations, if the server set-up is non-std.?  Are “noindex, nofollow” clauses absent from HTML Meta tags, to enable search engine discovery?  If for going live the site is to be moved to a prod. URL, has a “301 Redirect” rule been added to .htaccess file? Site “Go Live” – For Better Results
21. A Digression; Something Extra - 1  A common challenge; keeping separate dev. and prod. boxes with identical configurations. "The code works fine on the dev machine but breaks in the production environment”.  Hence the dilemna:  Persevere with separate dev. and prod. machines? Or  Do we just develop on the production box?  The last of these alternatives; a bad idea. Site “Go Live” – For Better Results
22. A Digression; Something Extra - 2  Some possible answers:  One solution implied earlier; Build in a development environment that was cloned from a version of prod, then switch pointers to it from current prod. box with a redirect when work is completed.  Set yourself up Virtual Machines and / or emulate the production environment.  A class of emulator / VM products on the market:  VMWare  $vagrant and Puppet, PuPHPet Site “Go Live” – For Better Results
23. Parting Thoughts 1  The checklist not intended to be an exhaustive or definitive list.  We are not dealing with absolutes.  To go live or not to go live  Checklist used as a confidence indicator.  Good enough? A judgement call involved.  Will the error result in a show-stopper? Site “Go Live” – For Better Results
24. Parting Thoughts 2  The checklist should form only 1 component of your overall strategy;  e.g No justification to forego full regression testing.  Don’t let it become a tool for an inquisition:  Fit in use of the checklist with your H.R. practices.  It is about accountability, not witch-hunting! Site “Go Live” – For Better Results
25. Site “Go Live” – For Better Results Site “Go Live” – For Better Results Conclusion: Help prevent this with a pre-launch checklist!