Keeping a blog alive when it’s not your primary source of exposure can be a tricky one. That certainly applied this week: all hands were on deck in production, pitches, or with existing clients. (It’s a busy time at Stink Digital at the moment.)
Better to be honest than to fill in the gaps with an old Youtube clip. (Oh, okay, let’s do that anyway:)
More next week…
Flash Camp came to Shoreditch today, so I took the opportunity to detach my head from coding for the afternoon to check it out. I heard some interesting talks on Flash animation, Pixel Bender, and Air, but when Seb Lee Delisle of Plug-in Media stepped up, I was really listening.
Like all of us at Stink Digital, and much of the ActionScript community, he’s deeply passionate about the fun stuff – I’m talking about things like Papervision3D, particle systems, webcam interactivity and augmented reality. You have to play to find new ways of doing things and Seb entertained the several hundred strong audience with various toys and experiments, such as interactive particle-generated fireworks projected onto large buildings, an augmented reality wormhole and even 3D Pong, which the Flash Camp crowd controlled via web cam by waving our arms in the air.
The most lasting impression, however, was left by a groundbreaking new Papervision3D site for CBeebies. What’s most absorbing about it for me is the level of detail in everything you can do and the soft, gentle feel they’ve managed to achieve – something quite tricky to accomplish in Flash 3D. At this time, the second half of the site is still a couple of weeks from launch, but promises to be pretty special. Check out http://www.bbc.co.uk/cbeebies/bigandsmall/ for more.
Nothing hits a site visitor dead in the eye like a message for lost content, or worse, an error message that says the error message format file itself cannot be found. While, as a developer, you never expect to present your clients or users with errors, it is best practice to anticipate the worst and actually turn a negative into a positive.
At Last.fm, back in the day, howls of “TEA!” used to reverberate around the office whenever the database went down or became overloaded. (Our error page told users to go away and make some tea before returning to attempt another refresh of the page.) I always maintained that they should set a browser cookie with each page reload and encourage users to drink a progression of increasingly alcoholic drinks, say tea > coffee > irish coffee > gin and tonic > double whisky on the rocks, but that’s another story, and probably has more to do with my Scottish heritage than the steadfastly “English” persona of this uniquely British, or rather European startup.
Back on topic, this little story reflects the need to rise above the negative and help visitors out of a potential dead end. At the very least, alert the user to the error and provide them with links to the home page, alternate content or equivalent content, or better yet, a search box.
Many a geek has been seen to inject humour into a 404 error page with games of space invader or insider techy jokes. Just yesterday, Marcel leaned over to show me the Revver.com 500 Error page which included words to the effect of: ‘our crack squad of coders has been alerted to this error and their game of virtua fighter put on hold to find a solution.’ That being said your target audience isn’t necessarily going to be a bunch of geeks, so what can you do?
Past best practice has shown that there are lots of ways to turn the error page into a sort of feature: you can use striking imagery, get lyrical and weave a poem, be apologetic and sincere, show some emotion, and humanize what is essentially a purely technology induced scenario.
In the end, I suppose, do whatever you want to do, just don’t make it boring.
We’re using Zend Framework as our PHP framework, to help us turn projects around quickly without sacrificing stability. We ended up choosing this over the likes of CakePHP, Symphony, CodeIgniter, etc. for a few reasons.
Firstly, we wanted to be sure to choose a framework that supported configuration over convention, as we don’t like the idea of having to learn and work by somebody else’s rules.
Secondly, the modular, flexible approach was really attractive – the nice thing about ZF is that even if you don’t use it you can still grab and use individual bits of it.
Thirdly, it’s full-featured – it has a very large set of functions and classes, and embraces design patterns throughout, so it’s really stable too (in general).
Now that we’ve been using it for a few months, we’ve used the majority of its features and have a lot more to say about it – both good and bad. We use the MVC configuration (which slightly invalidates the first reason above), and have extended an awful lof of the framework for our own shared library. That’s because it’s coded to be SO flexible that you end up having to set a lot of options every time you use any of the classes; and as soon as you do that a few times you realise you’re better off extending the ZF class to include your defaults.
Once you start making your own extension to the library, you find that you can kick off a new project and be looking at forms related to database fields, all covered by 3-level one way secure logins, all within 30 minutes of getting the repository going. Which is pretty amazing.
On the other hand, the Zend_Form output code is pretty naff (every element is within a DD tag and every label within a related DT tag), and modifying this is painful but ultimately rewarding. The default layout system doesn’t observe what we think as the crucial split between design and code. The image upload code (for forms) is pretty comprehensive in its aims, but not yet finished (and the manual is not in sync with the project’s progress).
Despite all this, the main downside to ZF is the documentation. It’s often poorly written, doesn’t go into enough detail and doesn’t give context for its examples – what use is
$this->getRequest();
when you don’t know what scope $this is? It isn’t always in sync with the most recent version, and the site it’s presented on is painfully slow! This all adds up to a steep learning curve being lightly greased, so that it takes longer than it should to find out how to use what are actually great components (often looking into the source is the only way to find out what’s going on).
Having said that, overall we’re massively happy with it, but we’ve found it takes a while to get a new bit of functionality working at all, then a bit longer before it works the way you want it to, but once you have it right it works very well and incredibly powerfully. We would (and do) recommend it to anyone willing to invest some time into making something that’ll pay dividends in the long run.
Yes, it’s cheesy. Yes, it’s simple. But hey — remember the good old days?
Software companies/developers – The predicament.
To the end user, it feels like decisions are easily made between the addition of new shiny features over drab bug fixing. The marketing vs. a fully functioning app.
How excited would the design and media world be if a bug-free creative collection was realised and released? Doing so would improve workflow and creativity many more times than a re-skin and add-ons that are sporadically used.
Product catalogues should be slim-lined (i.e. working towards v10.4 over a ‘major update’ after 10.02), and implement a two/three year product release cycle over an obviously rushed yearly renewal to shift as many £299 upgrades as possible. Products would be solid and brand images strong.
Our days are lived through these apps. Our creative blocks should be our own creative limits, not from the ‘boom’ of an unexpected error.
A solution!
I’ve just been working on the forthcoming search functionality for this site (coming soon to a screen near you!) and have had a week-long headache with a very simple problem.
I decided to use Lucene as our core search engine for two good reasons:
I know that there’s a lot involved with developing a decent search, and have generally avoided the issue when I’ve been able to in the past; instead going for Google Site Search or similar.
I was therefore really pleasantly surprised to find that I was indexing my first content about 30 minutes after finishing reading the documentation (which admittedly took me a few hours), and I was retrieving results as expected a few minutes later.
As with most of the Zend Framework I’ve come across so far, it provided a stable and feature-rich base to work form, but I needed to extend the classes to be useful for my needs. Having written my own Analyzer (a simple composite of existing pieces with stopwords and short words excluded) and wrapper class (as a Controller Helper) to ensure I’m always using the same encoding, analyzer etc., I basically found that I was up against a serious block.
Lucene doesn’t support documents (the individual items that each count as a ‘result’ in your index) being updated – instead you need to delete the right document and re-insert the newly modified one. This means you need to reliably find a document in the index, in order to delete it. As Lucene’s own internal documentID field is subject to change without your app knowing about it, the supported way of doing this is to store a database index as a field in your document, then search against that field.
For the last week (on and off) I’ve been battling against the strangest problem: my documents wouldn’t reliably be found when searching for them by their unique database ID. I tried all sorts of things, starting with the best practice method of storing the IDs as ‘Keywords’ (untokenized, stored, indexed fields) and retrieving them with the termDocs() method and – I thought – trying everything down the path to the lowest common denominator.
In the end the solution weas to index the IDs as ‘Text’ (tokenized, stored, indexed fields) – I use a numeric tokenizer as my data can contain numbers in the middle of words – and to simply retrieve the results using a query in the form ‘databaseID: x’. Simple I know but ultimately very frustrating.
I have to give big-ups to Kenny Katzgrau, whose code for the wpsearch plugin for wordpress I inspected, to see how he did it (I knew he was also using Zend_Search_Lucene).
All in all ZF’s Lucene implementation is great, but this problem gave me loads of headaches!
