Designing in the browser

Cover of Implementing Responsive Design by Tim Kadlec

Implementing Responsive Design by Tim Kadlec (New Riders, 2013) ISBN 978-0-321-82168-3

As we begin to transition towards a mobile-friendly design and workflow, I’m thankful that for the last five or six years we’ve been designing primarily in the browser, rather than in graphic editing applications such as Adove Photoshop or Corel PaintShop Pro.

I’m one of these people that usually has numerous books on the go at the same time. One of my current books is this excellent book by Tim Kadlec called Implementing Responsive Design—Building sites for an anywhere, everywhere web (New Riders, 2013) ISBN 978-0-321-82168-3.

The world is changing. We now have more networked devices on the planet than human beings. In the UK people now spend around 16 hours online every week, on a variety of devices (desktop computers, laptops, tablets, smartphones, game consoles, etc.). Very shortly there will be more mobile devices accessing the web than desktop and laptop machines.

Therefore, we need to change too. One of the things the web team is currently looking at is our strategy for designing for mobile devices. We’re very much in the early stages.

What is immediately clear, however, is that this will have a profound effect on how we work as a team. Designing for today’s devices and users requires a different kind of workflow than we’ve previously enjoyed/endured (delete as applicable).

Old workflow

When I began in the web team in 2006 we would typically design a website as though it was a brochure. We started with a fixed width (around 950 pixels), and we used desktop publishing, image manipulation, and occasionally presentation software to design our sites.

It was a terribly inefficient way to work. We would first design it as though it was a document, and then have to interpret it for real in HTML and CSS to view in a web browser. It certainly wasn’t a DRY (don’t repeat yourself) process.

And it also gave our clients completely the wrong impressions. Once they had signed off on a design they expected the website to look exactly like the image we’d promised them on paper. In every browser. On all screen resolutions. And of course we couldn’t deliver it. Does anyone else remember, for example, trying to provide smoked-glass effect backgrounds on IE6, which doesn’t support alpha transparent PNG files, and modern browsers, that did?

On one website build we were brought in quite late on in the project to take receipt of a number of site designs and code them up for our content management system. It was one of the most frustrating projects I’ve worked on. We had no say in the design; we were effectively handed a photograph of a website and told “build that!”

As you might expect much of the interactive nature of the web had been ignored and we kept returning to the designers asking them “How did you envision this to work?” “This bit says ‘slider’ but where does the text go? What happens when the image reaches this part, does it slide underneath, over the top?” A lot of these things hadn’t been thought through because the designers had been used to designing for print, which is static.

A different workflow

When we worked on the current incarnation of the website in 2007–2008 I realised that we needed a more efficient workflow, and because I was more familiar with HTML and CSS than I was with the nuances of Adobe Photoshop I started designing everything in the browser.

The reasoning I gave people was very simple: nothing looks more like a website than a website. People understood that.

I found it liberating. It meant that we didn’t need to rework things: we didn’t need to sketch it in a graphics package and then code it later. It meant that we were given immediate feedback, and could see what it looked like in IE6 and deal with it there and then.

And it meant too that clients could get a very real idea of the effort and issues that go into designing a site, the issues with cross-browser compatibility (now that’s not so much of an issue), and they began to realise that not everything needed to be pixel-perfect in every browser.

To be honest, it was a little intimidating at first. If you’ve never sat in front of a client and written code (whether HTML or CSS) you can feel very self-conscious. What if you get it wrong and they lose confidence in you?

The truth is that not every designer or coder gets it right the first time. But that’s the truth whether there is someone sitting with you or not. And I found it helpful for the client to see that. “Oh! That didn’t work,” I’d say. Then I’d sit and talk through the issue out loud until I found a solution. It was helpful for the client to effectively see the working out of these issues, to see the scribbles and the code syntax look ups.

I would often explain that I would sketch it out in code, to make sure the idea worked, then I’d clean up the code later.

While I felt self-conscious, I often found the client was delighted. They could see their ideas taking shape on an actual website in front of their eyes. They could then immediately see what worked and what didn’t. It was a really effective way to work.

A responsive workflow

Now things are changing again. We’re not designing for a best-guess fixed-width site, we now have thousands of mobile devices to take into account.

We do have a lot to learn still, but we are on the right road, and already having a workflow revolves around designing in the browser is a tremendous help.

As Tim Kadlec says:

Until the wonder-tool comes along, it’s important to work toward loosening the grip of your favourite graphic editing program. Don’t remove it entirely, but start moving toward an more agile approach. Create the visuals as you code. Tackle the two hand-in-hand and you’ll be much better equipped to work on the Web. (ibid., p. 173)

Advertisements

Coloured lists in Trello

Background colours on selected lists in Trello

Background colours on selected lists in Trello

As you probably know, we’re big fans of Trello here in the web team.

We have a number of project boards, overseen by one master, everything-we’re-doing™ board called @Web team. It currently has 24 columns (or lists) which makes quickly navigating to the right list a little tricky at times.

So today I quickly wrote a hacky little Tampermonkey (Chrome) / Greasemonkey (Firefox) script to add background colours to certain lists.

For colours, I simply selected an at-random theme from Adobe Kuler.

It could be optimised but it does what I need to without too much of a performance hit, and already I’ve found it really helpful to immediately identify the “in progress”, “this week” and “done” columns, as well as marking our project backlog columns.

// ==UserScript==
// @name Web team - Trello highlight lists
// @description Highlight certain columns in Trello.
// @include https://trello.com/b/YOUR-BOARD-URL
// @require https://code.jquery.com/jquery-1.11.0.min.js
// @version 2.1
// @copyright 2014, Gareth J M Saunders
// ==/UserScript==

$(document).ready(function() {

var black = '#393939',
brown = '#a39386',
green = '#a8C0aa',
red = '#a7585b',
white = '#fff';

$('body').hover(function() {
$("h2:contains('PROJECTS'), h2:contains('TEAM ADMIN')").css('color', black).parents('.list').css('background', brown);
$("h2:contains('IN PROGRESS')").css('color', black).parents('.list').css('background', green);
$("h2:contains('THIS')").css('color', white).parents('.list').css('background', red);
$("h2:contains('DONE')").css('color', white).parents('.list').css('background', black);
});
});

Please feel free to use it, adapt it, improve it, comment on this.

Obviously, change the ‘contains:’ keywords to find your own list headings, and the @include URL to that of your board.

Update

  • I noticed that I was trying to pull in the jQuery file under http rather than https, which was causing problems.
  • It turns out that the DOM loads long before the content, as there is some Ajax jiggery-pokery going on. So I’m using a hover event on the body to force the colours to change, which is a horrible hack but works, and does also pick up new lists created with these keywords.
  • 2014-12-08 I’ve discovered that rather than // @include https://trello.com/b/YOUR-BOARD-URL, I can use // @match //trello.com/* which will then work across all my Trello boards and follows the protocol of the board being viewed (which seems to always be https:// for me).

To do

  1. Use arrays and or variables to store common colours.
  2. Improve the event handling to determine the best way to load the script.
  3. Reduce duplication with regards to identifying the column (h2:contains gets repeated a lot) and adding the CSS rules.

Drop the assumptions, re-frame the question

More than two years ago, on 7 November 2011, I created a new card on our Trello board called “Fix memos on internal homepages”.

It then sat on the board for the next 24 months, and was not touched, apart from to shuffled around the board a bit, from one list to another: from ‘backlog’ to ‘this week’ to ‘backlog’ to ‘known issues’ to ‘backlog’ to ‘bugs’ to ‘known issues’ to ‘backlog’ before it was finally scheduled to be done four weeks ago, three weeks ago, two weeks ago, one week ago… this week.

In the end it only took about 30 minutes to fix!

The issue

The issue in question was this: if a user visited the current staff, current students’ or current postgraduates’ homepage (and a few other school websites) under a secure connection (https) then they were not able to read the memos or events. Instead, they were served an error message, e.g.

An error has occurred fetching the memos.

An error has occurred fetching the memos.

The problem

The problem wasn’t affecting too many people, either. We would maybe receive one complaint about it every six months, so there was no urgency. But we considered it a significant issue to keep it on the board. For two years.

The reason that nobody fixed the issue was, I suspect, two-fold:

  1. Fear
  2. Prejudice

Fear

We feared that this problem would be very complicated and time-consuming to fix. Our fear led to inaction.

It sounds like it should be a complicated thing.

It sounds like we should need to know exactly what happens at both the server and browser levels when content is served using Hypertext Transfer Protocol Secure (HTTPS) compared with a non-secure communication.

It sounds like we may need to delve into server configurations or look up obscure chapters in books about PHP security to figure it out.

We didn’t.

Prejudice

Each time we discussed that card (as we shuffled it around the board trying to settle on the best list on which to ignore it) we spoke vaguely about what we suspected we needed to do, rather than simply stating the problem we were experiencing.

We always spoke about this incident with a particular solution in mind. And that solution was one that had emerged from our fearful speculation rather than simply stating the facts about the problem.

“Oh, that’s the problem where we have to force the pages to be loaded as http rather than https, isn’t it?”

And we would all agree.

“We’re going to have to do that using either .htaccess or PHP, aren’t we?” someone would continue.

And we’d all agree.

But we were wrong.

Drop the assumptions, re-frame the question

At the start of the week, I volunteered to look at this card.

I already had our pre-conceived idea at the ready and so I immediately spent a couple of hours reading up on forcing https pages to reload as http using .htaccess files.

“Boy this looks complicated!” I thought. “Surely there’s an easier way.”

And it was only at that point that I suddenly realised what I was doing. Or rather what I wasn’t doing. I wasn’t considering the actual problem itself; I was leaping straight to a solution.

The problem wasn’t that these pages weren’t forcing the page to be loaded under http, it was that the memos and events wouldn’t displayed if the pages were loaded under https. That’s a whole different issue.

I rewrote the ticket in Trello to reflect this: “Allow memos and events to be viewed under https“.

I then wrote myself an Agile-style story:

  • As a member of staff…
  • When visiting the staff homepage under an https connection…
  • I would like to view the events and memos, rather than an error message.

And it was at this point that I suddenly realised what the root cause of the issue was: the browsers were not pulling in the events and memos because they were hard-coded in the PHP and JavaScript files to be served under http.

So I changed these to protocol relative URLs.

Now, rather than referencing http://www.st-andrews.ac.uk/my-file.php I changed this to read //www.st-andrews.ac.uk/my-file.php so that the browser uses whichever protocol it’s currently receiving (see section 4.2 of RFC 3986 Uniform Resource Identifier (URI): Generic Syntax for details.)

And like I said, it took me about 30 minutes to update all six pages that were affected.

The lesson for next time: drop the assumptions, re-frame the question. Perhaps the answer is more simple than you first thought.

Using Trello from within Microsoft Outlook 2010

Trello board

Trello board

If you’ve been following this blog for a while then you’ll know that almost a year ago we moved our Agile board to Trello. It has been a great success.

Last year the University also moved both our email and meeting scheduling software to Microsoft Exchange. I’ve been a fan of Outlook since about 2000, first synchronizing it with  my Psion PDAs and then with a Windows Mobile smartphone. I do pretty much all my planning in Outlook. Or at least I did, until I discovered Trello.

So my question was: how can I use Trello within Outlook? Then I remembered Outlook’s little-used shortcuts feature.

1. Open up a Trello page in your browser. It doesn’t really matter which browser. I’m using Google Chrome 23 beta for speed.

2. Now drag a bookmark onto your desktop from the address bar .

Browser shortcut on desktop

Browser shortcut from Trello page on PC desktop.

3. Next, open up Microsoft Outlook and click on the Shortcuts icon in the left-hand navigation pane; it has a shortcut key of Ctrl+7.

Shortcuts sits beneath Mail, Calendar, Contacts, Tasks, Notes, and Folder List

Shortcuts sits beneath Mail, Calendar, Contacts, Tasks, Notes, and Folder List

4. Now drag the icon from your desktop onto the label “Shortcuts”. It won’t work unless you drop it right on the word “Shortcuts”.

5. Next, right-click the new icon (which will by default show the URL) and select “Rename Shortcut” from the context-menu, to give it a more user-friendly name.

Adding a shortcut to the Outlook shortcuts list.

Drag the shortcut onto the Shortcuts label, then right-click to rename it.

6. Click on the new shortcut link. Now you have Trello displaying within Microsoft Outlook. You can have as many shortcuts as you like, to as many boards as you like but remember you can always change boards within Trello too.

As far as I can see (using findmebyIP.com) it’s using the Microsoft Internet Explorer 7 engine to render the page, so obviously if FogCreek Software stop supporting IE7 in Trello then this top tip will stop working.

Trello being displaying within Outlook 2010

Trello being displaying within Outlook 2010

Update

If you want to take the Outlook/Trello integration even further you can now use Emello, which allows you to send emails directly to lists within your Trello boards. I’ve not used the service myself, but it certainly looks useful should you require that functionality, and the website looks slick and professional.

Trello at St Andrews

At the meeting of the Scottish Web Folk, on Thursday 31 May held at the University of Edinburgh, I gave the above presentation about Trello from Fog Creek Software.

Trello is, according to its own help text,

a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what’s being worked on, who’s working on what, and where something is in a process.

We’ve been using it since December 2011 within the web team at the University of St Andrews and are finding it really useful.

Summary of presentation

The first part of the presentation outlines something of our journey from a team of two members to (hopefully) six by the end of 2012. As our project backlog grew we knew that we needed to manage projects and tasks more collaboratively, to get details out of people’s heads and into a centralised tool.

We started to adopt Agile practices in 2008 which led to us creating a scrum board in the office. But in September 2012 Steve, our Web Manager, broke his foot and when he returned to working from home in December we knew that we needed to move the board online.

We had checked out a number of online, free and hosted applications such as Basecamp, Pivotal Tracker and Jira. However, Trello proved to be for us the perfect match.

The second part of the presentation takes a quick tour through the Trello interface and how it works.

The last part of the presentation involved a hands-on demo of the software. I’ve replaced this with two simple slides representing the two ways that we use Trello.

  1. We have one board called “Web team” which tracks the big picture: project requests, current projects being worked on, know issues, admin tasks, backlog of tasks, etc.
  2. Then we have multiple project boards, one for each project. These have a standard number of columns (backlog, in progress, waiting for, testing, done) and the labels (new feature, enhancement, PHP/JavaScript, bug, documentation, web team admin) are the same across every project.

If you have any questions or observations please leave a comment below or email me directly (gareth.saunders@st-andrews.ac.uk).

Note: this article was also posted to the Scottish Web Folk blog.

Moving our team task board online to Trello

20111104-taskboard

For the last few years the Web team have been using, and adapting, a form of Agile/Kanban board to manage what tasks need to be done and by whom. It has served us very well, but this week we moved it online to Trello, a free, hosted service from Fog Creek Software.

Why we went digital

When we started using the board the Web team consisted of three people: Steve the Web Manager, me (Gareth) the Assistant Web Manager, and Chris the Web software developer.

We all sat in the same room together, and the board was just a few steps away from our desks. It was handy, and quick, and accessibly. But as the team has grown we’ve now spilled out into an office on another floor of the same building.

It’s not quite so easy now for all five members of the team to add to or move tickets around the board. Occasionally some of us work from home too.

The main catalyst, however, was in response to a recent crisis in which our intrepid leader, Steve, fell of a ladder and broke his foot (you can see photos of his recent x-rays on TwitPic). He could be working from home for some time now and we wanted to make him feel included so we moved to Trello.

Trello

20111104-trello

It was pretty painless to set up and add users to our newly created organisation and board. I then spent a couple of hours migrating our open tickets over from the whiteboard into Trello.

Labelling and assigning tasks to users was simple thanks to Trello’s excellent keyboard shortcuts.

I did wonder if I’d miss physically moving cards from one column to the next, but Trello has a neat little trick whereby when you ‘pick up’ a card it rotates it a little to indicate that it’s been picked-up. It’s really effective and surprisingly satisfying:

20111104-trellomove

We’ve decided to trial working with Trello for a few months, certainly while Steve is recovering and may have to work from home.

So far the response from the rest of the team has been very positive (after we switched off email notifications). It’s attractive, it’s simple and it’s intuitive. No doubt we’ll report back in a few months with our thoughts on how the move from analogue to digital has gone.

Our journey into Agile, pt.2

Encountering Agile

Back in April 2008 I attended the Scotland on Rails 2008 conference in Edinburgh; I literally have the t-shirt to prove it.  It was an absolutely fascinating (read: über-geeky) conference let down for me slightly by the fact that I really didn’t have a clue what they were talking about most of the time as I had only just begun to explore Ruby on Rails.

It really was the most hardcore conference that I’ve ever attended. Most of what was said went way over my head as the speakers went into minute details about which new functions were available in Ruby 1.9 (does Ruby even have functions?! See: not a clue!), advanced class design, and there was even a talk called “Bonus Erlang Session”.  That could be the name of an experimental band from Germany for all I know.

But there were a couple of things that I really enjoyed, one was the keynote speech by David Black which was just inspirational (check it out on iTunes, it’s called The Flying non-Scotsman: or, My thirty-two year trip from the Borders to Edinburgh), the other was the number of speakers who kept talking about BDD (Behaviour Driven Development), SDD (Story Driven Development) and Agile.

 

The Art of Agile Development

The Art of Agile Development by James Shore and Shane Warden

 

O’Reilly had a book stall at the conference with a 10% discount.  So I bought this book: The Art of Agile Development by James Shore and Shane Warden.  It’s a great book that gave me a thorough grounding in Agile and XP practices and processes.  I thoroughly recommend it.

Planning poker

Fast forward a year and a half to December 2009 and there we were, a rather broken-looking Web team sitting around a table in Web HQ staring at a spreadsheet listing over 120 requested projects.

In The Art of Agile Development the authors write

XP assumes that customers have the most information about value: what best serves the organization. Programmers have the most information about costs: what it will take to implement and maintain those features… A successful plan needs to take into account information from both groups, as every decision to do something is also a decision not to do something else.

Taking that to heart, that we had the most information about costs, we sat down over two days and played planning poker using home-made cards with the list of projects.

Agile planning poker cards (PDF, 24.5 KB)

Planning poker (or the ‘planning game’) is normally used by teams to estimate individual tasks in a larger project, but we used it to estimate the size of projects themselves.

We looked at each project one-by-one on the list. Whoever knew what it was about would explain it to the rest of the group, something like

Okay, so this project is about replacing the virtual tour movies on the website, which are currently QuickTime movies, with the same movies but in Flash format.

Once we had enough detail we would silently vote on the complexity of the project.  We used homemade cards (you can download them above) using a sequence that was loosely based on the Fibonacci numbers.  Our cards used 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and Break.

Each player would select a card and then at the same time everyone would lay their cards out on the table.  We were looking for a consensus of opinion.  As I was facilitating the process I would invite whoever laid down both the lowest and the highest values and ask why they scored it that way.

That’s where the real value in the process came in.  It gave everyone an opportunity to speak about every project.

Someone who scored it low might say something like:

“Well, I scored it a 2 because I’ve done this before and it was really easy. We just need the source Flash files and then we already have a media template for Flash movies so it’ll take no time at all”

Then the person who scored it more highly might offer something like:

“See, I gave it a 20 because it’s not as straight forward as it initially looks for a couple of reasons.  We do have a media template for Flash movies but it doesn’t allow us to embed multiple movies on the page. And then there is the issue about lack of Flash support for iPhones and iPads.  Should we be thinking about going down the HTML5 path?”

Having heard the evidence we would vote again until we had a consensus.  Sometimes we would end up with three 13s and one 20, for example, in which case I would ask the person who scored it 20 if he was happy for it to be given a score of 13 or if he felt very strongly about the 20.

It was a really useful exercise.

By the end of the two days we still had a list of 120+ projects but each project now had a value indicating how difficult or complicated we reckoned each one was.

Prioritization

We took this list to our boss and she prioritized them, according to the factors that she was aware of and how they fitted in with wider University priorities and projects. P5 was high, P1 was low.  Over 20 projects got binned straight away.

By the end of day three we now had a list of just under 100 projects but we now knew the approximate size or complexity and their priority.  The project list didn’t feel quite so daunting. We also, crucially, had the commitment from our boss that all new project requests should first go to her.

We then used this list to start disengaging from and postponing half- (or hardly-) completely projects that had a low priority.  Most people, to be honest, were very understanding.

Next post I’ll finish this series by explaining how we broke down our projects, what we’re doing now and where we’re hoping to go.  I’ll also take a look at Agile tools that we’re using.

Our journey into Agile, pt.1

Scrum sprint

Diagram of a Scrum sprint, taken from Scrum in five minutes from Softhouse

In November of last year (2009 if you don’t have a calendar to hand) we started to seriously look into using Agile methodologies to better manage and run our Web projects.
The crunch came when we realised that in many cases we weren’t delivering what we had promised to do, we were snowed under.  We took a day out to evaluate where we were and to our horror we discovered that we

  1. were working on over 20 projects concurrently.
  2. were not moving very quickly on any of them.
  3. had a backlog of over 120 projects, which we estimated would take around 13 years to complete if things continued as they had been going.

Something had to change.  We had to change.  We needed to stop saying yes to everyone about everything and we needed to find a way to more efficiently and effectively plan and manage our projects.

Agile

That’s when we turned to Agile for assistance.

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams

Definition of Agile from Wikipedia

Agile is something that we’d looked into a couple of times in the past. It struck a chord with us: iterative, incremental development was something that we did anyway.  We often practiced pair programming, we were using something akin to a Scrum task board, we had a daily stand-up meeting each morning, at times we would have ‘customers’ sit with us to iteratively work through a design.

Simply adopting certain methodologies doesn’t make you Agile though, but it was a good start. Iterative and incremental, if you like.

Almost Agile, even.

Oh, hang on …

Multiple projects

One of the things that we struggled with most was how to run multiple projects using Agile. Because everything we read talked about the importance of running only one project at a time.  Everyone that I spoke to from commerce or business about it stressed the importance of running only one project at a time, and everyone from higher education I spoke to stressed how impossible it was to run only one project a time.

Then I discovered this paper from Karl Scotland, formerly Development Team Leader at BBC Interactive: Agile planning with a multi-customer, multi-project, multi-discipline team (DOC, 225 KB) who gave me the confidence that it could work. In this conclusion he wrote:

The team is able to manage the various complexities of multiple customers, projects and disciplines by working in a way which allows them to treat the work as if there were only a single customer, project and discipline.  Thus they work on a single pool of stories which are shared by all the different customers, projects and disciplines.

So we could run more than project at a time, if we were careful.  We got planning.

Next week I’ll explain what we did next…

A few highlights from IWMW 2010

A couple of weeks ago I attended my fourth Institutional Web Management Workshop (IWMW 2010), which this year took place at the University of Sheffield. (Twitter tag: #iwmw10)

The event provides an opportunity for those involved in institutional Web management (mostly universities and colleges) to hear about case studies, share best practices, find out about new, emerging technologies and develop professional networks (mostly around coffee, in the pub, or sitting around a table in Pizza Hut with a handful of Welsh blokes looking very damp and hungry … it’s a long story!).

Turbulence

The theme of the event this year was ‘The Web in turbulent times‘ and as you might expect the message at times wasn’t entirely encouraging, particularly when one plenary speaker invited us to look around the hall and told us that a lot of us won’t have our current jobs this time next year. Cue nervous laughter.

I’m fairly confident that the magical St Andrews bubble that we inhabit in this small corner of Fife will hold out, particularly since we’re currently advertising for a new post: Website Migration Project Officer, but I certainly wouldn’t want to become complacent and I welcome anything that can help us to become more efficient and effective.

Mobile and Agile

It was encouraging throughout the conference to see both mobile Web and Agile practices popping up in a few plenary (keynote) presentations, as well as in workshops and barCamps.

The mobile Web is something that is clearly going to grow and grow, and it was both encouraging and inspirational to see how universities are addressing it.  It was equally encouraging to hear the debate between device-specific apps (e.g. iPhone apps) vs open-standards (e.g. HTML5-based apps). I don’t have an iPhone, and love my Opera Mobile browser on my Windows Mobile-based device, so no guesses on which side of the debate I sit on.

HTML5

One of the presentations that I was most eagerly looking forward to was HTML5 (and friends) from Patrick A. Lauke from Opera and he didn’t disappoint; you can view his slides here …

… except that I could have listened to him for another 45 minutes. And probably the 45 minutes after that too. HTML5 is one technology that I’m really looking forward to exploring more of this year.

Agile project management

When I signed up for the conference I chose to attend a workshop entitled “A little project management can save a lot of fan cleaning … or (Agile) project management for the Web” because we’ve begun to employ Agile methods in our project management and developments and I wanted to hear more about what an experienced Web team is doing.

The workshop abstract promised:

  • Common misapprehensions about project management.
  • Nightmare situations when dev work goes pear shaped.
  • How project management can save your sorry ass.
  • The ‘light’ project management approach.
  • Is agile a better model for the fast paced work of the Web?
  • Are agile and traditional project management complimentary or mutually exclusive?
  • Sexy web based tools to avoid the dreaded MS Project.
  • 100% death by PowerPoint free, guaranteed!

Unfortunately, the workshop also appeared to be largely Agile-free.  I was disappointed to discover when I turned up that about 50% of the workshop was looking at PRINCE2 project management, which follows a more ‘waterfall’ project management approach, rather than Agile.

I got the feeling that the person who was presenting the Agile aspect of the workshop had been thrown in at the last minute (which I guess fits in with the Agile Manifesto: “We … welcome changing requirements, even late in the development”!) but I’m not sure that it really did Agile, and SCRUM in particular, justice, unfortunately, and didn’t go into the depth that I was either hoping for or the abstract suggested that it might.  Unfortunately, the workshop didn’t do as it said on the tin.

WordPress

The other workshop that I attended, WordPress beyond blogging, was really encouraging.

There can be a tendency in some sectors to dismiss WordPress as not robust because it runs on PHP and MySQL (rather than, say, Java and Oracle database), but it was great to hear how WordPress is being used in other institutions (and for some pretty key services) and gave me a courage to return to St Andrews and explore how we might be able to use it in a number of projects that we’re working on.  Besides, there are currently 11.4 million blogs hosted on WordPress.com which is running their own software, so I guess they must be doing something right.

What I bought back

From most other IWMW conferences I’ve returned with something practical to try out: in previous years it’s been microformats, RSS auto-discovery, OpenSearch, etc.  but there wasn’t so much of that this time.  Maybe I just attended the wrong workshops and barCamps, but what I did bring back was:

  • A desire to start exploring HTML5 now.
  • Encouragement to blog more, and encourage the Web team to blog more (which is why we moved our 3 post WordPress blog from a self-hosted installation to WordPress.com!) Brian Kelly will be so proud of us!
  • Keep exploring Agile/SCRUM and build on the progress that we’ve already made.
  • Explore how we can use WordPress.

And of course, one of the most valuable aspects of IWMW was that I returned with existing friendships strengthened and new ones made.