my name is alan blogs

Drupal 6 Popup Forms

alan — Mon, 18 Apr 2011 03:03:29 +0000

my blog_Drupal 6 Popup Forms

18.04.2011

I did a lot of searching for a nice solution to make simple "confirm this action" type forms in Drupal 6 work as popups rather than directing the user to a new page.

At first the solution seemed to be the Popups module (http://drupal.org/project/popups). However on installing this and testing it on a development site I found it didn't work "out of the box". The reason turned out to be a conflict with Typekit. I disabled the Typekit module and it worked fine. However, this made me suspicious (and besides I wanted to use Typekit) so I did some research and found out that there is also an unresolved conflict between the Popups module and standard javascript optimization in Drupal. That ruled it out as far as I was concerned.

A better solution seemed to be the Modal Frame API, which I hear has been brought into core for Drupal 7. However this looked like quite a lot of work for me in creating my own custom module or implementation of the API. Possibly I would have done it eventually, but I did some more searching and found...Automodal! This module does exactly what I wanted. It implements the Modal Frame API and gives you a selector in your Automodal settings page. Add this selector to the link that you want to appear in a Modal Frame and it just works!

My real-world implementation of this was for node subscriptions. I wanted users to be able to click "Subscribe" on nodes or node teasers, and not to have to go to a pointless interim page just to click a "subscribe" button. So by enabling Modal Frame API and Automodal, and adding the "automodal" class to my link, I was able to make the subscribe form pop up. Joy! The only problem was that once they submitted the form, the parent page didn't refresh. A quick bit of Googling later and I discovered the useful hint to append "?automodalReload=true" to the end of my link. Double joy!

The only disadvantage is that it's not as fast as a true Ajax-only solution; the Modal Frame loads a full Drupal node, then reloads the parent page when it's finished - so my popup solution feels a little slower than it should be. However it does the job, and I'm happy.

click image to enlarge_

other recent blogs

Deleting cookies using PHP

alan — Mon, 31 Jan 2011 16:53:08 +0000

my blog_Deleting cookies using PHP

31.01.2011

This issue cost me several hours due to poor documentation of the setcookie() function in PHP. How do I delete a cookie in PHP?

The Context:

A Drupal site using a few jQuery modules, including autosave. Autosave was being used to persist the user-entered values in a medium-sized form, so that if they left the computer, closed the browser etc without completing the form, their original values would be there when they came back. However, the client was also worried about privacy, and therefore wanted the autosaved values to be deleted once the form was submitted, so that another user coming to the same computer wouldn't see the form populated with the previous information.

Autosave uses cookies to store the form data, and I didn't want them deleted immediately upon form submission, but only after some post-processing in one of my custom modules had taken place, so what I needed to do was delete those cookies in a PHP function after calling node_save().

The Problems

I quickly found out that I need to use the setcookie() function - however here is where the consensus ended. Various different sources indicated that cookies could be removed by:

Simply calling setcookie("cookiename") without any parameters
Calling setcookie("cookiename", "") - i.e. setting a blank value
Calling setcookie("cookiename", "", TIME) where TIME is some time safely in the past, e.g. the day before.

On further inspection it seemed as if 3) was the way to go, and the only safe way of removing the cookie across browsers. The browser detects that the cookie's expiry date was in the past, and removes it. Great! Except...it didn't work for me.

Further inspection revealed that when the cookie has been created with a domain (as it usually will be for Drupal sites) you need to add the domain and the path to the setcookie() statement. E.g. setcookie("cookiename", "", time()-(60*60*24), "/", "mydomain.com"). This didn't work either! This is because my cookie domain, set in my settings.php file for Drupal, was "www.mydomain.com", not "mydomain.com". However, setcookie("cookiename", "", time()-(60*60*24), "/", "www.mydomain.com") also didn't work - because the PHP setcookie() function automatically adds a leading "." to the domain name! So my browser was searching for cookies on the ".www.mydomain.com" domain, which obviously didn't exist.

The Solution

Finally I stumbled across the bit of information I needed. If you include the Path variable "/", but EXCLUDE the domain variable altogether, then PHP will automatically look for the cookie on the domain from which the PHP statement is being called. So: setcookie("cookiename", "", time()-(60*60*24), "/") finally worked!

click image to enlarge_

other recent blogs

table row links in Drupal Views

alan — Fri, 14 Jan 2011 19:34:16 +0000

my blog_table row links in Drupal Views

14.01.2011

The table view in Drupal Views is incredibly handy for displaying and ordering large amounts of data and allowing the user to interact with it. It comes out of the box with sortable columns which can be nicely ajaxified, any of the fields can be themed, made into links, etc - in other words all the flexibility of Views. However, as has happened to me quite often with Views, a client asked me for a piece of functionality that seemed quite obvious and natural to them, but which Views can't provide and which (apparently) couldn't be done using HTML/CSS. This client (www.myninetofive.com) wanted each row of the table to be a highlightable link to the node being displayed. In other words, not just the text within the cells, but the entire row, needed to light up when hovered over, and be clickable anywhere in the row.

A brief discussion on the drupal site contained a statement by one of the gurus to the effect of "You can't do this without using Javascript", and that statement was echoed in a couple of other threads I found. However, this is not the case as I discovered when some gentle pressure from the client encouraged me to go a little more deeply into the matter. Yes, you can't make an entire table row a clickable entity using HTML and CSS alone. However, using a mixture of Views functionality and CSS, you can simulate this behaviour to the point where the user will notice no difference!

The simple recipe is as follows. I'll presume at this point that you already have your view set up as a table and all styled the way you want it etc.

1. In Views, make every displayed cell in the table a link to its node.
2. In your CSS, use the following code for the links (modfying the selector as necessary in your case): .views-table tbody td a { display: block; width: 100%; height: 100%; }
3. Use the :hover pseudoclass on your table rows to make them highlight, e.g. tr:hover { background-color: yellow; }

Abracadabra! As far as I know, using :hover on table rows won't work in IE6, but I've tested it in IE7 and IE8, Firefox, Chrome, Opera and Safari. The whole point is that the table row is still not a clickable link as a whole, but since each link in each cell takes up the whole cell, and all the links go to the same place, and the whole row highlights when any link is hovered, the effect as far as the user is concerned is exactly the same. The only problem I can foresee is if you have wide cell spacing or padding that causes the links not to stretch to each others' edges, but you can play around with the CSS yourself to resolve small problems like these.

I found this trick at http://stackoverflow.com/questions/1460958/html-table-row-like-a-link and I think it's so useful and attractive that it could even be made part of the core Views offering (e.g. a tickbox "make whole row a highlightable link to the node" that activates the necessary links and CSS). Anyway, I didn't see anyone else offering this solution for drupal developers so I thought I would document it.

click image to enlarge_

other recent blogs

Drupal postcode proximity search

alan — Tue, 10 Aug 2010 16:50:50 +0000

my blog_Drupal postcode proximity search

10.08.2010

The brief: a website built around a UK postcode search. The user inputs their postcode, chooses a category to narrow the search if they want, and the results can be displayed as a list of teasers or a GMap. The teaser list needs to be sorted either alphabetically or by distance from the entered postcode. Sounds simple, right?

WRONG

I have always had the impression that the Views module wavers constantly between being incredibly useful and collapsing under the weight of its own complexity. I have used Views to create websites very rapidly, but likewise I have often gotten bogged down in its limitations, bugs and unexpectedly mysterious workings. Often it can be a case of getting 95% of the way there in an hour, then spending 2 days achieving the final 5%, and this was one of those times.

With Drupal 6, Views, Locations and GMap all being quite mature at this point I was taken aback by the problems I encountered accomplishing what I considered to be one of the more basic possible uses of a location search. Searching on Google informed me that I was not alone.

Initially I was going to write about the problems of doing a proximity search from a naked postcode, but the extremely active Drupal community have resolved this issue in the last couple of weeks. So instead I thought I would just write down a couple of the essential elements of the "recipe" that I have used to accomplish my postcode search site, in the hope that someone else out there might find it useful. Who knows, the next release of location or views might make all these comments completely obsolete!

Most of the required functionality came right out of the box with Location Views: once I had a content type associated with a location, and built a few sample nodes, it was relatively easy to create a view listing those nodes. Using "node view" allowed me to style them using Content Templates. I added a location: distance/proximity argument to the view, and this took as an argument the user-entered postcode...NOT! I couldn't work out for a long time why this argument failed to work, until I realized I was missing some small grey "helper text" underneath the settings:

So, OK, I could grumble (and I did) about how this vital info was easy to miss; on the other hand, where were they supposed to put it? Oh yes, that's right - in the comprehensive, helpful documentation for Views...oh. Anyway, let's put this down to developer blindness and move on, now that we know that the postcode argument needs to be country_postcode_distance or postcode_distance (where "distance" is the number of miles away from the postcode to return location results for).

My other argument was a category taken from a hierarchical vocabulary. I tried messing around with exposing a hierarchical-select filter in views, and very quickly ran into some horrible nightmares. To sum up, if I had done it that way there is no way I would have been able to style my form as specified by the graphic designer. So I learned how to add a hierarchical select field to my own form and passed the value of this field into the view as a simple TermID argument.

Now, the user needed to be able to switch easily between Displays in the same view (i.e. viewing the same results as a GMap or a node list) and also switch between alphabetical and distance ordering. Again, after some tinkering with trying to expose filters I realized that my form was going to get very ugly very quickly, so instead what I did was create my own links by passing arguments in the URL. So to display the A-Z list, I added a display to the View whose only difference was that there was an alphabetical sort in the sort criteria, then created a link (nicely styled as specified!) in the form http://mysite.com/myform?postcode=xxxxxx&tid=1&display=page_2. Then using $_GET I was able to choose which display of the view to display, and used views_embed_view($postcode, $tid, $display).

This also enabled the user's choices to be retained while switching between different displays of the view, since I took the $_GET values and also used them to set the values of the form fields. And in one key respect it saved my sanity, namely: sorting by distance.

This should have been easy. I had a view taking a postcode as its origin and calculating distance between the origin and each node listed. However, sorting by the distance proved a severe headache. Options were present to sort by distance from user location, distance from a static postcode, distance from a location-associated nid argument....the full list is here:

What wasn't there was an option to sort by distance from my postcode argument. This one cost me about 2 hours. I quickly settled on the need to use the "Use PHP code to determine latitude/longitude) option, but using standard views syntax to get the views arguments directly ($args[0], $args[1], etc) didn't work. Eventually I figured out that since in my particular case I was passing arguments in the URL, I could use $_GET here like anywhere else to get my postcode. Then I used location_get_postalcode_data() from the Location API reference to get my lat/lon pair. Lastly I just had to figure out that although that array came back in the form array('lat'=>xx.xx, 'lon'=>xx.xx), the return value for the sorting had to be in the form array('latitude'=>xx.xx, 'longitude'=>xx.xx). Live preview didn't work for this one (because of the use of $_GET) but when I saved the view and tried my form again, it worked! Here's the code:

Incidentally, using the Location API was invaluable when I needed to access the distance/proximity value in my Content Template. Again, I used the postcode value from $_GET and passed it into location_get_postalcode_data() to get the lat/lon array. Then I passed both lat/lon arrays (the origin, and the one from $node->locations) into location_distance_between() and hey presto!

These little tricks enabled me to solve my problem and provide a working postal code search facility to my client, but I'm under no illusions about them being a solution flexible enough for anyone else, which is why I'm not providing comprehensive code, just guidelines to other stuck developers about how they might solve their problem. Hopefully a couple more iterations of Views or Location may solve these problems. I had to find a quick and clean-as-possible solution in order to meet a deadline. I found myself caught in the nether world where Views was able to provide so much of the required functionality that it became worth it to try to hack around in search of that remaining 5% rather than coding something from scratch.

None of the above should be interpreted as criticism of the developers who work on the Views and Location modules. These are incredibly complex modules which have to integrate and play nice with a number of other incredibly complex modules, and Drupal itself, so it's no wonder that there are bugs and omissions. It was actually quite exciting to find out that in the 2 weeks since I started development on my project, one of my critical bugs was fixed in a development release!

That concludes my unnecessarily long summary of a developer's solution to a client request. Hopefully someone might find it useful, and if you do, a comment would make me feel all warm and fuzzy!

EDIT #1:I realized I could make my life even easier by calculating latitude and longitude for the origin once (in the form submit handler) and then passing the latitude and longitude as values in the URL. This meant that instead of calling location_get_postalcode_data() 12 times (once in the form submit, once in the Views sort criteria, and once for each node teaser displayed in the View), it only gets called once. Much better.

EDIT #2: Another problem became apparent in testing: the UK postcode data that ships with the Location Module is a reduced set, containing data only up to the area (in the form 'CO1' or 'HG3') rather than the full set of postcode data ('CO1 xxx' or 'HG3 xxx'). When I searched for the full set of UK postcode data, it became apparent why this was: there were over 2 million rows of data to import.

For those interested, I found a Drupal-friendly SQL script for the full UK postcode data here (scroll down to comment #17). However, I found this to be a problem for me. Even once I got it imported, which took quite a while due to MySQL timeouts, I found it slowed my Search page down by a factor of 10 (from average 0.5 seconds to average 5 seconds), and almost all of that time was taken up by the MySQL query used in location_get_postalcode_data(). There didn't seem to be a lot I could do in terms of optimization so I decided to revert to the reduced set of data (which provides a fairly accurate location, it just doesn't go down to the street level and therefore some distance calculations are probably slightly off).

If anyone has a Drupal site, using Location, working with the full UK postcode data set, that isn't slow as a dog when searching that table, then I want to know!

EDIT #3: The client raised a problem that was interesting. After searching by postcode and displaying the View as a GMap, the map was always centred by default on the same location, which was set by a GMap macro in the View settings. The client wanted the map to be centred on the postcode that had just been searched for (a totally reasonable request). However, this wasn't an option. Views offered me the ability to center on a node argument; in other words, if I passed in a nodeid, I could center the map on that node's location. This wasn't very useful to me, since I want to center on the postcode argument, not a node.

One possible workaround occurred to me: on every postcode search, I can create a node, set the node's location to the searched postcode, and then pass that node id as an argument to the View. These dummy nodes could then be deleted on the next cron run. However, this kind of hack should be regarded as a last resort.

I ended up settling for a much more elegant hack which I discovered here. It involves adding 1 line of code to the GMap module which enables the GMap macro field in my view to parse PHP. Once this is done, then it's easy for me to insert some php that reads my postcode (or more accurately, my lat/lon arguments) and outputs the macro using those to center the map.

Of course, now I have to remember to re-insert this line in gmap.module every time I update the GMap module, which is why hacking modules is usually a bad idea. However in this case it was worth it to me, as a) a fix was needed quickly, b) this is obvious and necessary functionality, and c) I am not being retained as the site's maintainer ;-)

It's probably clear from all of the above that Drupal + Views + GMap + Location is almost, but not quite, ready for this extremely common real-world application (searching by postcode).

click image to enlarge_

other recent blogs

Drupal update nightmares

alan — Tue, 15 Jun 2010 03:13:38 +0000

my blog_Drupal update nightmares

15.06.2010

Sometimes things go as planned, and sometimes they don't. That sentence sums up my relationship with Drupal. Tonight was one of the bad times. I just finished bringing my own site up to date with the latest Drupal security release (6.17 at the time of writing), and while I was at it I decided to update all my add-on modules to their latest versions too, because why not? While I was at THAT, I realized that I hadn't put my themes and modules in the right place when I built my site - they were sitting in the core "/themes" and "/modules" directories, which is baaaaaad) - so why not move them to the right place too?

So I did it all at once. But first, just to make sure the subsequent nightmare would be as annoying as possible, I overwrote my local versions of the modules with the new versions, then uploaded all the new ones to the right place on the webserver. Then I deleted the existing modules on the server.

No, since you ask, I didn't take a backup first. Why would I do that? It's only MY website. Some kind of brainfart caused me to skip every single one of the standard precautions I would take 100% of the time if I was altering a client's website. I didn't back up the database. I didn't back up the files. I didn't keep a local copy of the previous files. I just nuked everything and uploaded the new stuff, because at 3am sometimes I am an idiot.

Predictably, a lot of things went wrong. Allow me to list them.

Conflicts with new module versions caused my site to crap out completely with PHP errors.
- Fix: deleted a module I wasn't using anyway
The modules and themes couldn't be found after I moved them from /modules to /sites/all/modules and from /themes to /sites/all/themes. Also, because the themes couldn't be found, I couldn't navigate to admin/settings/performance to clear the cache to fix this.
- Fix: navigated to admin/build/modules which although themeless was still a functional form. Saving the modules page cleared the cache and the modules were picked up again.
Lots of images in my theme didn't show up because I'd hard-coded the URLs in the stylesheet and the page templates and then moved the theme.
- Fix: updated CSS files and content templates with the new image paths.
Javascript gallery stopped working.
- Fix: updated path to jQuery gallery in page.tpl.php
My hacks were lost. This was a real pain. I'd forgotten that as a shortcut, I'd hacked the Flickr and Twitter modules to add some extra tags for style purposes. When I updated to the new module versions, I lost all my hacks. This really was no more than I deserved, since hacking modules is NOT THE DRUPAL WAY. All right, sometimes it's the quickest and easiest way to accomplish something in a hurry, and sometimes in the real world we are in a hurry, but sometimes we pay for our hurry, and in this case it cost me another hour.
- Fix: wrote better CSS this time.

All this trouble taught me a couple of lessons which I thought I knew already, but apparently I needed to learn them again.

Put your add-on modules and themes in sites/all/modules and sites/all/themes
Don't hack core. Don't hack other peoples' modules - or if you absolutely must, don't forget that you've hacked them.
Always take a backup before updating anything.
Don't try to do anything important on a live server after 2am.

Like I said, I stick carefully to the guidelines when working on client sites but took shortcuts for my own, with a kind of mindset that it didn't matter because the only person who'd ever know was me anyway. So this is my confession to the world: I did not follow the Drupal Way, and for my penance I lost three hours of my life. I repent forevermore.

drupal

nightmare

click image to enlarge_

other recent blogs

Nonlocality

alan — Sun, 04 Apr 2010 02:09:34 +0000

my blog_Nonlocality

04.04.2010

I'm in Ireland today, preparing for Easter Sunday by staying up until the small hours on the computer (of course!). I had a nasty moment on the journey over here when I thought it was possible that I'd forgotten my laptop; then I realized that this would in no way prevent me from being able to do my job. All my essential data is stored on box.net and dropbox, so I can get at it anywhere I have an internet connection. My web development "tools" are for the most part quite basic - I code in Wordpad or Notepad (when I'm using Windows) or gEdit (when I'm using Linux), I use freely downloadable FTP/SSH tools like WinSCP and Putty, and all my communications take place using web-based email or Skype/phone. I can quite easily jump on someone else's computer anywhere in the world, do a couple of hours of good work, and never know the difference from being at home (or in an office somewhere).

This shouldn't really keep surprising me, since it was the whole point of moving to the country and becoming a freelance web developer, but it does. I love being nonlocal. I'm not really making enough money (yet) to be able to take full advantage of it, but I can see some future time when I can just wake up and decide "Why don't we all go to France for a few weeks?" and we just do it, and I can still work just like normal. I'll really feel like a far-fetched plan has come together.

nonlocality

remote working

click image to enlarge_

other recent blogs

The New New Flesh

alan — Tue, 23 Mar 2010 03:11:30 +0000

my blog_The New New Flesh

23.03.2010

I'm nearly finished the new version of my own site - visuals provided by the fantastic Marc De'ath of the Creative Coop, who I've been working with for the past year and a half, back-end courtesy of Drupal, and sweat and late nights provided by me. Sometimes the simple-looking sites turn out to require the most work, or at least more than you expect!

This will be the first time I've ever had a personal (business) website designed professionally, as part of an overall branding exercise. When I say "branding", we're not going over the top with it. But I'll be having business cards and possibly letterheads printed, and I may even have an email signature, something that for some reason, through 10 years of working in IT, I have always managed to avoid.

Needless to say, I love the new design. I've discovered for myself over the last few years that my skills are definitely in the area of coding and development, rather than visual design. I doubt I could have made it on my own as a web designer/developer, but I've found that working together with graphic designers is both easier and more rewarding. I knew that it was a complicated skill to make something work right and do what it was supposed to do, but I didn't realize (until i tried it) that it is at least as complicated to make something look good, or even just to make it not look bad.

One thing I like about this new design is that it removes all the "fat" from my site. I always had a lot of features that I thought would be cool when I developed my own site - rotating quotations, photo albums, things like that. However, I found that life always keeps you busy, especially when you have children, and there just isn't time to keep updating those things, so after a while the same old images and text just sit there gathering virtual dust. This new design focuses me on the things that I do keep up with - blog entries, the odd software review, and my web portfolio. All the other stuff is elsewhere on the web - my photos are on Flickr, my random daily thoughts are on Twitter, and my writing is drifting in the ether like a poltergeist waiting to find a suitable host to terrorize.

new site

web development

working late

click image to enlarge_

other recent blogs

Working from home

alan — Mon, 28 Sep 2009 01:19:56 +0000

my blog_Working from home

28.09.2009

I've been working from home for close to a year now and it's interesting to see how my attitude to it has changed. After 10 years of working in various different types of office, from the small-startup-in-condemned-warehouse variety to the cctv-system-recording-your-cubicle-time evil corporation type, and after years of school, I had developed a deeply ingrained attitude that work is not fun. Fun is something you have outside of work, and therefore during your working life you fantasize constantly about getting away from it. Weekends of stress release, holidays of escape, early retirement through sensible financial planning, writing a bestseller.

See, I slipped that last one in there because that was always my personal fantasy. I would write a bestselling novel when I was young and bypass the boring, awful world of adult work completely. It's not like I didn't work towards that goal, either, but four novels later, I still didn't feel like I had something publishable. Interesting, quirky, sometimes funny, something my children and grandchildren might one day discover with amazement maybe, but not something that was going to magically turn itself into big fat royalty payments, fame and respect.

In the meantime, while I was busy fantasizing about my ideal life as a writer, I spent more and more of my time on computers. I've always been totally addicted to computer games, but I was one of those kids who didn't just like to play them - at the age of 8 I was learning how to write simple games in BASIC on a Commodore Vic20. I was very proud when I managed to follow the instructions for building a program that would have a conversation with you. I filled the database with phrases to do with self awareness, existence and meaning, then talked to it for hours pretending that was really conscious and yearning to be free of its hardware shell. So, just your average 8-year-old thing to do, really.

I discovered when I got my first job that computer knowledge was indispensable, and a lot of basic programming principles from when I was young came back to me as I wrestled with making Excel and Access do what I wanted. Around that time I saw The Matrix, and some kind of Tunguska-scale lightbulb blew in my head: I wanted to be a programmer. Through a combination of hard work, shameless blagging, fast learning and what was then a shortage of developers, I talked myself into a job for which I was utterly unqualified, as a VB6 programmer (I didn't even know how to debug).

For the years that I worked as a corporate software developer, building websites was just a hobby of mine. Actually, I only really thought of it as something I was teaching myself in order to have somewhere online to display my writing. As the online store of writing grew, so did the website, until I needed a content management system, and David Angier recommended Drupal, so I learned first how to use, then how to customize it. When I started making websites for friends, or friends of friends, I still only thought of it as a hobby. It didn't occur to me to try to make money from it until about 2005, and when I tried, I didn't take it too seriously at first, because I was still in a weird frame of mind regarding work. I still thought that I was only doing nasty horrible adult work until I managed to start writing for a living. So when a contracting job came up in Dublin, then in Cork, I took them and the world went back to normal (working in an office and moaning about it, waiting for the weekends all week).

It was the birth of my son that changed my attitude about what I do for a living. At the time I was living and working in the centre of Dublin. I was earning more than I'd ever made in my life, but fully half of what I made was going on the rent for our lovely big sky-high 2-bedroom apartment. We were talking about buying a house, and I realized that in order to do it, we'd have to move miles out of the city centre, and I'd have to commute to work for an hour or more every day. What's the big deal, right? It's just that it's something I said I would never do. I promised myself that when I was young. I could dabble in the world of work as long as I was free to walk away from it at any moment, but I couldn't trap myself.

So my son was born, and two months later we made a very big leap of faith. I gave up my cushy contractor job (with what has turned out to be perfect timing, just before the collapse of the Irish economy) and we moved into the depths of the Yorkshire countryside, and I started building websites for a living, and taking it seriously this time.

All this started out with my observing how my attitude towards working from home has changed. I talked about how work was not fun, by definition, and that I clung to my escape fantasies of writing and other activities (yeah, at one point I wanted to be a professional poker player too). At first, when I started working from home, it was bizarre. Decide what to do with my own days? Manage my own time? Yeah, right...surely I would just play games all day? At first, that's what did happen: because work is not fun, I would play loads of online chess and poker and then rush to meet deadlines for websites, forcing myself to do the work because it was not fun. But gradually, without my even noticing, this began to change. The thing I had missed, the obvious point, was that I actually really enjoyed my work now. I love building websites. It's endlessly challenging and different and satisfies both the problem-solving and artistic parts of me. I found myself spending less time playing games and more time working. Being in business for myself has made me realize with great clarity that if I don't make it happen, it will never happen, and there will be no excuse, and far from stressing me, this has released a great deal of energy.

I was at the dentist the other day and explained what I do, and he commented that it must be hard to motivate myself to work every day without the spur of an office and a boss and all that. He said that he didn't think he could do it. I found this completely bizarre, that this highly skilled and intelligent person thought he wouldn't be able to motivate himself to work, and I explained that it was really no effort, because I enjoyed the work; he didn't say anything, and the obvious thought occurred to me: he doesn't enjoy his. He doesn't know what it would be like to enjoy his work. Work is not fun. Then he started drilling my teeth, and that wasn't fun for me either, so I hope he at least got some satisfaction from that.

So here I am: I've been quite lucky. I took a risk that seems to be paying off. The website jobs are coming in, and I have the indefatigable Marc De'Ath to thank for much of that. I get to work from home; which means that if I want to I can play around with my son for half the day, take country walks, and then catch up in the evening and at night. It means I get to watch films while I work, and have as much coffee and chocolate as I want without being laughed at (except by Jo). It means I can live in the countryside and not have to commute anywhere for my job. Most of all, I've discovered that I love my job, after doing it for several months, which means that if I have to work hard, I don't feel hard done by. I'm not missing out on anything. I'm not looking forward to the weekend. I'm not waiting for retirement. My job is fun. I'll be very happy to do this for as long as I can.

click image to enlarge_

other recent blogs

Favicons

alan — Thu, 17 Sep 2009 05:33:44 +0000

my blog_Favicons

17.09.2009

A favicon is that little icon that appears in the left-hand side of the address bar of your browser when you visit a website, or in your bookmarks menu if you bookmark it, or on the tab if you are using a browser with tabs. Creating a good favicon is an important part of developing a website, since that icon is the most frequently-visible representation of your website. If you design it right, just seeing it will make your site pop into someone's mind when they open their bookmarks. If you get it wrong, or don't bother with it at all, you've missed an opportunity to make your site stand out just a little bit more.

The favicon is often a tiny version of a company's logo, but you can have a bit more fun with it than that. In fact, it's amazing just what people have been able to do within that 16x16 pixel space. You might not consider yourself much of a graphic artist, but the proliferation of online tools for web developers means that you don't have to be. A site I've been using a lot is Favicon.cc, an online favicon generator for static or animated icons. You can import from an image file as a starting point, or design a favicon from scratch. If you have a logo image, then generating a favicon is as simple as importing the logo and clicking a button. Take your new favicon.ico file, drop it into the root of your website directory, and hey presto! The boring default "blank" icon that people saw in their address bars when visiting your site is replaced by something a bit more eyecatching.

As of the time of writing, I've been experimenting with creating animated favicons, and I'm using one on this site. It's a close-up of my eye (imported from a digital photo), with a differently-colored iris in each of the 4 frames of the animation. Slightly cheesy but it made me smile. I've got 15 tabs open in my browser and mine is the only one with a moving favicon, so it stands out.

The main catch is that browsers differ significantly in their implementation of favicons. Internet Explorer doesn't seem to support animation at all, and has problems with transparency, while other browsers, e.g. Opera and Safari, also don't display the animated favicon on my site, and therefore may require different code. If you want to explore this in more detail, you could try clicking here, or here, or maybe here. The good news? The animations work in Firefox, and it's only a matter of time before the other browsers follow suit.

One last note: I work mainly with Drupal, and it's shocking how many Drupal websites out there still use the out-of-the-box default Drupal favicon. It just doesn't look professional in my opinion.

click image to enlarge_

other recent blogs