“Keyboard fast, mouse slow” is one of my personal mantras. Using keyboard shortcuts is always faster than moving a mouse to click on buttons. If you followed all of the shortcuts I recommend here, you’d save yourself an average of five minutes every day, even with casual web use.

These keyboard shortcuts work for both Firefox and Chrome; most of them will also work for Safari, Opera and IE. If you’re a Windows or Linux user, simply substitute CTRL for ⌘. I’ve also made a PDF of the keyboard shortcuts for you to download.

The shortcuts above, plus a dozen more, some of them browser-specific:

For the past week I’ve been in the Cook Islands, preparing for the wedding of my brother. Rarotonga is a tiny island, barely 32 kilometers around, part of a chain of islets and atolls scattered through the middle of South Pacific that were first inhabited millennia ago as the Polynesian migration expanded from Taiwan.

Little has changed since I last visited: there are just a few thousand people living semi-permanently on the island, most of who get around on mopeds or one of the two buses (one marked “clockwise”, the other “counter-clockwise”). Stray chickens still wander the road, and everything works on island time. There are a few more buildings, and wireless internet is available in some locations (although ruinously expensive), so I only had to walk along the beach for a few minutes from the lodge I was staying in to get caught up on eMail.

I took the photos you see here with an 18 – 300mm lens mounted on a Canon 5D Mark III, which impressed me very much. I also embarked on a circumnavigation of the island and shot it with a helmet-mounted Hero 2 wide-angle camera; the video of that excursion will take some time to edit together, but you can expect to see it up on YouTube shortly.

Michelangelo’s Pietà is frozen perfection in Carrara marble. Once the last polishing pad was put aside, the sculpture was removed from the stream of time, remaining unchanged through the centuries.

Today that is no longer the case, for every form of art. James Cameron’s Titanic, originally shown a decade ago, was re-released as a “enhanced” version last month, pushed into 3D; ebooks go through multiple editions in a month. Nothing about art is fixed or permanent any longer.

Art has always faced an evolutionary imperative: inspire other creative works or die. Reflecting the impatience of their creators with the slow and indifferent process of natural selection, creative work is experiencing the selective pressure of cultural taste and creative inspiration. In response, art is beginning to evolve itself.

In the oldest cave systems, there is plentiful evidence that art was readjusted, replaced and redrawn by our forgotten ancestors; perhaps by the same painter, more likely by his descendants through the passage of deep time. In the interregnum between the birth of agriculture and today, art was enshrined, constant, unchangeable. Now, every creative work is under constant pressure to adapt to the rapidly changing expectations of its audience.

As always, this is due to technology: as editing tools become more powerful, the temptation to “tweak” becomes almost irresistible. This inevitably leads to a process of constant re-editing in which few works are ever permanent: like life, they exist in the stream of time, never left alone. In turn, the expectations of the audience changes: they grow bored with work that is static, fixed, and unchangeable.

The “mimetic drift” of constantly-evolved works leads to an entirely new set of concerns, most particularly the loss of original material. The film print of Star Wars shown in theatres in 1977 can no longer be seen, outside of some copies preserved on the archaic medium of laserdisc: according to Lucasfilm, the current edited version is all that exists. But there is immense value in the original work, even if only for archival purposes. It’s equally important to curate the process of alteration. All too often in the case of digital art, the past is disposable: there are entire digital graveyards filled with the ashes of old game code and corrupted forum postings, art that was made and lost, never to be recovered.

This process sharply brings into question concepts of ownership. If you have an oil painting on your wall, you have physical possession of it: you can reframe it, cut it into strips, and reassemble it. You don’t have the right to recreate it, at least in a traditional copyright system: that is the sole power of the intellectual owner of the work. So what happens when that painting is digital and net-connected? Does the artist have the right to come in through the internet and “fix” the painting? What about via a software update? And what does that imply about possession?

From the commercial side, “airbrushing” photos of models to make them more visually appealing has been a standard practice for decades. Coded into automatic correction algorithms, that aesthetic is making its way into consumer-level products, from simple processes that remove red-eye to suites of software that “enhance” and “beautify” images with no intervention from the photographer.

All of these trends call for an increased awareness on the part of both creators and their audience. This awareness could be summarized in a manifesto of just three points:

• Artists need to recognize that the creative act is a negotiation between themselves and their audience, and that every iteration and derivation of their work – from flawed first generation versions to fanfic – has value and should be retained.

• Both artists and audiences need better curative tools that will record the evolution of any piece of art and allow the audience to decide which version they want to interact with.

• As a culture, we should be forthright about communicating changes made to artistic work: it should always be clear what was changed, when, by whom, and how.

Marking the end-of-semester final sites from my classes, I’m discovering the same basic misunderstandings and bad habits repeated in pages made by many students. Most of the pages are valid, which is a great start, but they’re also incomplete.

While I emphasize best practices in my classes (and elsewhere on this blog), it occurred to me that perhaps they needed to be in one place, or presented in a series of articles. Thus, this entry.

Let’s take the start of a valid, accessible HTML5 page, shown at the top of this article. This is not yet set up for mobile, nor has it had metadata added to it, but the page is otherwise complete. Here’s the code:

1. <!DOCTYPE html>
2. <html lang=en>
3. <head>
4. <meta charset=utf-8>
5. <title>Ozymandius Corp – About Us</title>
6. <link rel=stylesheet href=styles.css>
7. </head>
8. <body>
9. <div id=wrapper>
10. <header role=banner>
11. <h1>
12. <a href=index.php>
13. <img src=assets/images/ozymandius-corp.jpg
14. title="Ozymandius Corp" alt="Ozymandius Corp">
15. </a>
16. </h1>
17. <nav>
18. <a href=index.php accesskey=1>Home</a>
19. <a href=about.php accesskey=2 class=current-page>About Us</a>
20. <a href=about.php accesskey=3>Products</a>
21. </nav>
22. </header>

What makes this a well-made page?

1. The least amount of HTML5 neccessary written.

2. title includes both the name of the company / site and the purpose of the page.

3. All the CSS rules are placed in a single linked style sheet.

4. div elements kept to a minimum.

5. ARIA roles used to make the content accessible.

6. Whether the logo is an image or text, it is inside a <h1> tag and linked to the index page.

7. A logical folder structure, with all filenames in lowercase. Local paths used, not absolute.

8. The logo image has the same text in the banner as the filename, alt and title values.

9. Avoidance of unnecessary ids and classes: we can specify the appearance of this content in CSS by using descendant selectors rather than an id.

10. accesskey conventions used for navigation

11. class used only where necessary (to highlight the current, active page, not repeatedly applied to sibling elements.

If you believe I've missed anything, or see room for improvement, please let me know!

What follows is a typical task list for iterative site management, covering tasks from a daily to annual cycle. It is scaled to a small-to-moderately sized website (a blog, a personal ecommerce site) run by a small team (one to three people) that does not carry advertising.

Every day

• Add new content

• Promote site via social media

• Check for and respond to new comments and mail

• Fix any mission-critical issues

• Attend to any bugs that can be solved in less than an hour

• Note new signups

• Check visitor levels and activity on site

Every week

• Check referrers, activity levels, devices used to access the site; make a note of overall trends

• Ensure that latest entries on front page are appropriately tagged and entered into site navigation (side bar, feature bar)

• Promote one article to an outside source (another person’s Twitter feed, ai inbound link from an external site) to bring in new visitors.

Every quarter

• Add a new feature to the site and/or remove a redundant or unused feature

• Optimize the appearance and functionality of the site for a single device (Android, Blackberry) or platform (IE7) that constitutes less than 5% of your visits.

• Evaluate attainment of goals for quarter; set or revise goals (number of visitors, average pageviews, average time on site, etc) for next 30, 90 and 180 days

Every year

• Re-evaluate design and functionality of the site; do a site refresh or redesign as appropriate.

• Renew domain and pay for hosting services

Every spring this site goes through something of a personality change; this season, especially so.

As the weather warms I tend to put web development somewhat on the back burner, using my vacation time for travelling and recuperation. This year that trend will be enhanced by the fact that the entirety of what I teach in my regular classes is now present in the form of articles here, and I have several Super Secret Projects to complete over the summer (details of which will be shared as I am able).

This does not mean the end of articles, by any means; only that the topics occupying my attention over the next several months will be far more varied, and updates more sporadic. Inevitably that will involve some web development: you can expect a daily report from the An Event Apart conference I will be attending in Boston in June, for example. I am also very aware that there are topics that require additional coverage (most especially JavaScript/jQuery, Responsive Design, and SVG), so you can expect more advanced tutorials in those areas. (I would also welcome your suggestions for future articles!)

On the whole, entries here will be far more diverse, and, I hope, even more interesting. If you’ve read this far, I hope you will continue to do so over the next four months.

Every installation of PHP makes an assumption about where it is on planet Earth. PHP does not read the location information from the computer it is installed on: that would be the role of JavaScript. Instead, every web server installation defaults to a pre-determined timezone. It is likely that this default won’t match the actual physical location of the server. For example, if you’ve downloaded and installed XAMPP, the server assumes its local timezone is Berlin, Germany.

This can be confusing, especially when using the date() function on a PHP page – date("Y") will obviously provide the right year 99.99% of the time, but date('l’) (a lowercase L, to generate the name of the day) will sometimes be right for your location (when Germany happens to be in the same day) and sometimes not (when Germany is one day ahead of you)*.

While you can look through the php.ini file or phpinfo() to locate the default timezone information, most people will probably find it easier to display it on a PHP page with a temporary line of code:

1. <?php echo date_default_timezone_get(); ?>

This will provide you with the geographical area that PHP assumes it is located in. Note that this information is provided in the format city/region. If "America" is referred to, it includes the entire continent, from the frozen north of Nunavut to Tierra del Fuego. Also note that the city location references the primary or capital city of the area, and does not recognize inter-city or national rivalries, so (for example) the correct timezone for Alberta is Edmonton, America.

If the timezone displayed on this test page is not correct, you can try editing the server’s php.ini file, but this may not be possible in a hosted web environment. Most people will find it easier to correct the timezone on the PHP page itself, before you calculate a date or time.

For any PHP5 script that needs to reference the exact local time on a server with an incorrect timezone, before you use any date or time functions, write:

1. <?php date_default_timezone_set('America/Edmonton'); ?>

(php.net has a complete list of PHP timezone values: find the one nearest and most relevant to you, replacing 'America/Edmonton' with the appropriate location).

If you follow this line with echo date_default_timezone_get() you’ll find that the timezone is now correct, as are all calculated dates. You just have to remember to start any page that uses PHP-generated time or date values with this line. It’s not unusual to ensure this by making it part of an include for every page:

1. <? date_default_timezone_set('America/Edmonton'); ?>
2. <!DOCTYPE html>
3. <head>

With this in place, confusing time results in PHP should be a thing of the past.

*this, of course, assumes you are not in Germany