In this post I wanted to highlight our recent experiences developing an intranet in Drupal.
In this it has been really important for us to not over-engineer our solution as our client is currently undergoing a major restructure - so while the need for a new intranet was pressing, this has to be built during a period of great organisational change. Having developed many applications over the years in different technologies, I was naturally a bit apprehensive about the impact of changing architecture on the build.
When organisations look to rebuilt their intranets, the obvious tactic - or 'strategic leap' - is to revolutionise design and structure and develop a brand new and improved experience for users. While this is clearly the most impressive approach in terms of demonstrating improvement and change, it is probably the worst way of effecting real improvement and productivity gains for users and the organisation at large.
I have recently switched development environment from Mac to Ubuntu. By and large this has proved a really positive experience as I can so closely match my development machine to the production servers we run. I ran into one sticking point during set up - configuring Netbeans to compile SASS. This ought to be straightforward and it is, although I couldn't find any clear documentation. So to save anyone else similar pain, here are the steps I went through to get my set up working.
At Sereno, we use a range of tools to help us keep on top of Drupal development and to keep our clients actively engaged and aware throughout our projects. I'm not suggesting the following approach is best for everyone - the joy of using Agile is that you should really be tailoring all your processes and tools to meet your particular team size and style of working - but this set of tools certainly works well for us.
At Sereno, we've been using Personas in projects for many years. In case you've never come across them before, personas are short character studies of the people who are going to use your website or application. They're usually fictionalised descriptions of real users, and they help you think through your design process from your user's point of view.
We have been using various approaches to lean or agile project management for some time now. With each Drupal project, we refine our processes. Or perhaps I should say, we simplify them with each iteration. So we use fewer software tools, we have fewer stages, our sign off lists get shorter. And this is making us much better at project management.
There is a gulf between managing learning and development in large SMEs (up to about 1,500 employees) compared to very much larger enterprise organisations but I suspect the gap is narrowing.
One of the strengths of Drupal is the energy and commitment of its community. I was reminded of this at the Drupal Science Camp in Cambridge last weekend.
Well organised with great facilities, the Camp offered sessions for newbies to seasoned developers/systems administrators. Oh, and a good night out in Cambridge, where we could get to know each other a bit better.
When creating a website or application, it is common practice to complete the information architecture with a menu system. However, approaches to menus differ wildly and menus should be handled with extreme care, especially on larger content managed sites. We have recently been working on a site with many content items that have been housed in an enterprise level content management system (CMS). This CMS was built to enable easy insertion of content items into menus.
