Netsight Blog

So thought I'd do a quick update of what we've been up to in the past couple of weeks, as things have been pretty busy here at Netsight.

First thing to mention is that whilst we are primarily known for our Plone work, the three largest projects that we are working on at the moment are not based on Plone. Aha! the doomsayers say, Plone is declining etc etc. But in fact the opposite, this is a positive thing... let me explain:

One of the main criticisms of Zope and Plone back when they started was that they were not very 'pythonic' ie. everything in Zope and Plone was done differently in every other python system. Some would say that Zope was so ahead of it's time that there wasn't anything else out there, so it was blazing its own trail.

Zope 2 was a very monolithic system and you basically had to use the entire stack. Not only that but every part of the stack was different to any other stack out there in the world. It was a big learning curve. The 'Z' shaped learning curve. Plone came along and hid a lot of this complexity to the average user, and simple customisation could be done fairly simply. As Plone got bigger, things got more complex, and some really clever stuff to make core developers lives easier made some simple customisations more tricky. This is now being addressed, and for Plone 4 much is being removed, creating a much sleeker system.

However the biggest wins for the likes of companies like Netsight that have to recruit, train and retain developers is that there is much more transferable code and skills between Zope and Plone and the rest of the python world. Since much of Plone nowadays is developed in the much more flexible Zope 3 style using Component Architecture you can transfer between other frameworks like Grok repoze.bfg, vudo... and not just the Zope based ones... but its now much easier to move back and forth with WSGI based frameworks like Werkzeug, Pylons, etc.

This is such a tangible benefit for a business. We have recently hired a new developer to work on one of the projects below, and we are currently looking for yet another developer to join us. What is great, is we can look for just 'python' developers, not specifically 'plone' developers as they don't need to know 'plone' now like they used to in order to be productive in a Plone environment.

To give some examples of this, let me talk about a few really interesting projects Netsight is working on at the moment... none of which directly involve Plone, but which all use skills transferable to and from modern Plone development. A no doubt Plone will be stirred into the mix at some point in both these projects' near future.

The first is a several month support and development contract with a large academic-related business. They employ 1,500 staff and their business is interacting with teachers and students across the globe. They built (using internal people) several Zope based web systems for managing the interactions with these teachers and students. These were built quite a few years ago, and are in need of a bit of a refresh and can do with moving to Zope 3. With the help of another company they have moved most of the code out of the ZODB and onto the filesystem so it can me managed much easier. Our first task is to build an events management system for them. They run events worldwide, and this system will take care of bookings and related tasks.

What makes this project so interesting is that we are able to now develop using Zope 3 style and technologies via Five on a Zope 2 existing system. This is really nice as it gives us a much nicer development model (classes, views, adapters etc) rather than the old style of a bunch of 'Script (Python)' objects. It makes it much easier for us to debug (via pdb) and to benchmark and test. Not only that, but we have a new developer working on the project, who whilst has python experience, has little specific Zope experience. Working in this way he has been able to concentrate on the pythonic aspects and leave the core Zope tasks to the more experienced developer on the project.

The second project is really quite a fun challenge. We are dynamically re-skinning an existing .NET portal site... without touching the original site. We are using a WSGI stack with modules that we are developing based upon xdv to dynamically clean up the (nasty, broken) HTML from the original portal and present a nice clean, reskinned site to the end user. Oh, and as we are gluttons for punishment, we are re-writing the URLs of the site too...

Like many digital agencies, Netsight has long held the view that speculative design work is damaging to us, to the client, and to the industry as a whole. But not so long ago we were talked into producing a creative pitch, our first in several years, and the process turned out to be of questionable value for all involved. So I'm taking the opportunity to remind myself (and anyone else who might be reading) why speculative design work is just so counter-productive.

A piece of speculative design work is an uninformed sales pitch, not an informed response to real requirements.
The sole point of a speculative design pitch is to sell your services as a designer. Therefore, to be successful, that piece of design is most likely going to show the client what they want to see, not what they need to see. So begins the process of a designer second guessing what the client will want to see. No matter how good the brief is, the pitch design will be deliberately indulgent (with that ever-elusive "visual impact" applied in spades) and will not necessarily serve the client's users in anything other than a superficial way. In the normal design process, a good designer will ask difficult questions of the brief and make suggestions which may challenge convention. He or she will do this as part of an iterative, investigative process. But these things rarely go down well in a speculative pitch as there is a high probability that, to begin with, they will land wide of the mark - and the creative pitch is a one-shot deal. Often the worst outcome of the speculative design pitch is that the piece of pitch creative is actually used, straight off the bat, as the final production design - without ever going through that process of discovery, collaboration and refinement which is essential to great design. This is something that many clients don't consider.

Speculative design is wasteful and ends up costing everybody money.
If the worst outcome is that a design born out of a sales pitch is adopted as the final design, then the only alternative is that the speculative pitch concept is largely discarded and a "proper" IA and design process is then followed to arrive at the final design. Clearly then a significant portion of work done to produce the sales pitch design has just been wasted, which will inevitably be paid for out of the overall project budget. And of course, agencies which regularly engage in speculative design work have to pad out their project rates overall to pay for the time they lose in pitches for projects they don't win. This is bad for everyone.

I do understand why it is so tempting for a client to request creative pitches. Hold a beauty parade, and you'll get 5 or more completely different responses to a brief which you can consider and choose between without having to pay a penny. You might even be tempted to take your favourite bits and pieces from the different pitches and instruct the appointed agency to combine them into one (frequently horrific) chimera design...

So what is the alternative? Of course the obvious answer is to look at your potential agency's past work and case studies, and where appropriate talk to their previous clients to find out how well they fulfilled the brief.

But there is another option, and it's one that we're using very effectively with more and more clients. We call it the "Pre-production Phase", and it's simply a small package of requirements analysis, IA and design prototyping which stands alone from the main project. This approach is not uncommon but is often mistakenly thought of as a "paid pitch" - although to think of it as this is to miss the point. The pre-production phase aims to understand the client's values, their users, their competition, their business processes, their objectives and criteria for success - and to distil these down into a meaningful proposition which is independent of the technology that would be used in production (in our case, Plone). Both the process and the deliverables of the pre-production phase have intrinsic value to the client, and can be considered in isolation and in advance of the main bulk of the project.

The pre-production phase might typically cost something in the region of 10% of the total project budget, but this is in no way wasted investment. Virtually all of the work done in the pre-production phase would have been needed in the main build phase - it is simply being moved into its own stand-alone work package - and the clarity that the pre-production phase brings to the main project is invaluable, frequently leading to savings elsewhere. This then is surely the ideal solution: reduced risks and lower costs for all parties.

So last night was the Plone Wessex Users Group meetup. A small friendly bunch of Plonistas in the UK capital of Plone, Bristol ;)

Six of us: (Ben & James (Open Comms), Rick (Freelance), Mike (Films at 59), Matt Wilkes (Team Rubber) and myself (Netsight) gathered in the Hope and Anchor pub for chat about Plone, life, the universe and everything. Things we talked about:

• Plone skinning and how its sometimes harder now than before
• Deliverance (much to the joy of Ben, an XSLT die-hard)
• Importing/Exporting content from Plone (XML importing strategies)
• Buses in Bristol and how expensive they are
• The upcoming Balloon Sprint in Bristol
• Converting an existing client base to Plone from a legacy CMS
• WSGI (incl. a quick code demo, and run-down of how WSGI works and how to setup an XSLT processor)
• Caching
• Plone marketing and new plone.org site
• Budapest and upcoming Plone Conference
• Extension 42 of Netsight's phone system
• Team Rubber's new branding and sexy business cards
• BMEX and bandwidth in Bristol

And probably quite a few other things between the pints of beer :)

Meetings are normally every month or so, go subscribe to the Plone Wessex Google group (link above) for more info.

OK, so I'm going to let you into a little secret here... this new blog, for one of the UK's longest established Plone development companies, isn't actually written in Plone. Shock! Horror! How can this be? Well our own website was actually designed and built before Plone even really existed. Before Plone, we did all our development in old-skool Zope 2. I guess it's a testament to our designers that even since the last time we re-designed our website nearly 7 years ago our website still gets a lot of praise for its design.

For several years now we've been saying 'we need to get a blog sorted out', but just never got around to it. We've developed countless blogs for clients, but never had time to do our own. In case you are wondering then why this new blog already has a history of articles, that is because for the past year we've had a mailbox setup at work that we've been emailing blog posts to ready for when we got the blog sorted... which of course was only meant to be temporary... (yeah, right!).

So what is this blog running on then, if it isn't Plone? Its running Zine a python based 'clone' of Wordpress. This was partly an experiment and no doubt will change a few times over the life of this blog. So why Zine then? Well, we have been starting to use a technology called Deliverance that allows you to apply a look and feel (theme) to a website without actually touching the site itself.

This was originally created for Plone to allow designers to create themes for Plone without having to know all the guts of Plone and get their hands dirty with python code and viewlets and the likes. It also allows you to apply the same theme to multiple sites and make them look coherent. The upcoming new plone.org website (which Netsight did the visual design for) is going to be using Deliverance to theme both Plone itself and also Trac, the issue tracking tool that the Plone project uses. In our case we use Deliverance to theme both Zine and our own Zope website.

In fact though, Deliverance doesn't theme our website, but uses our website as the theme. Yes that's right, you can specify a URL for the theme file for deliverance, so this could be a local file, or another site somewhere. So we had great fun playing around with this, theming our blog with various other public sites, Ikea, Disney etc etc. And the fantastic thing about it all was that we needed to touch neither the theme source (ie Disney's site) or the content source (Zine). This meant I could setup Zine nice and quickly without needing to get to grips with its (frankly, weird - a separate rant) way of handling theming and customisation.

For those interested in the technical details I'll be writing a subsequent post with technical details of the setup of our site and blog and how we are combining zope, zine, wsgi, deliverance (xdv) all together as one. I'm also hoping to write a bit about the cool project we are working on using the concepts in Deliverance to theme an existing large legacy portal for an organisation.