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).

Mike McConnell

Attendees have confirmed from Strathclyde, QMU, Glasgow, Aberdeen, Glasgow Caledonian, Abertay, SAC as well as a handful of maybes. Plenty of space for more people, so please let Duncan Ireland know if you’re planning on joining us.

Agenda

The draft agenda is:

Additional topic

Digital Asset Management was also suggested as a topic, if we breeze through the others, we may move on to that or if there is a greater interest in this than an existing item, please let Duncan know.

T4

If T4 users would like to attend a session specifically on T4 then please let Duncan know and we can arrange one for earlier in the day around T4 v7 hints, tips and experiences or any current issues which you’d like to discuss.

Scan me!

There is a debate running within the Web team at St Andrews just now about the value of using QR codes on web pages.

Our feeling here is that QR codes are most useful on print publications and where used on websites for contact information, for example, they should be an unobtrusive option (accompanied by a tasteful 16 x 16 QR icon perhaps) rather than splashed across the page.

Our feeling is also that there are better ways to enable people to import contact details into their address book software, such as microformats.

What are your thoughts? Please use the comments below and answer the poll. Thanks!

Erik Rothoff Andersson has written a fun little Asteroids-style JavaScript bookmarklet called “Kick ass”.

When you click the bookmarklet a white, triangular Asteroids-style spaceship appears on your screen, over which you have complete control. Using the arrow keys to navigate and the space bar to fire you can fly around any web page vaporizing the Web page contents.

… and now for the science bit

When you run the bookmarklet the JavaScript code iterates through the DOM adding a class of “ASTEROIDSYEAHENEMY” to each element, which is then styled to “display: none” when it detects that the bullet-thing, yeah, that fires from your white triangle intergalactic spaceship has hit it.

Or something.

High scores

So this evening (Sunday 19 December) I pitted the homepages of the Scottish universities against one another.

The four ancient universities did well to make it into the top 10.  Not that I’m implying that their homepage designs were influenced at all by how well they score on Homepage Asteroids.

Although, of course, they should!

Gareth @ St Andrews

University of St Andrews Web team blog

At the mildly recent IWMW 2010 conference hosted at the University of Sheffield in July UK Web Focus Brian Kelly encouraged all Web teams to blog on a regular basis.

It was a long journey back to Scotland so Team St Andrews planned a revamp of our WordPress blog, decided on categories, a convention about how to use categories and tags, and a basic content strategy.

Can you tell that it was an information architect and a Web editor that was planning this?

When we got back into the office we moved from a self-hosted WordPress installation on the St Andrews domain to a free, hosted account on WordPress.com: stawebteam.wordpress.com.

Why move?

We realised that one of the main reasons that we’d not been using the self-hosted WordPress account was not because of time restrictions (which you might expect would be our number one excuse) but because of the hassle involved in upgrading WordPress each time an update is released.

While WordPress has had automatic upgrading available for a few versions, the server configuration that we have prevents the WordPress scripts from running the upgrade — lack of appropriate permissions, or something.

So we moved to WordPress.com, and in order to keep things consistent we chose the same name as our team Twitter account: @stawebteam. (We’re clever like that.)

What we’ve lost in complete control (the only thing we’re really missing is the plugin that makes code examples look really pretty) we gain in not having to maintain the software.

We can now simply concentrate on writing great content … hang on, isn’t that what we tell our TERMINALFOUR Site Manager users about our enterprise content management system?  So it must be true.

Gareth @ St Andrews

• Outside locations e.g. St Salvator’s Quad
• Internal locations that are used for graduation, conferences and weddings e.g. Younger Hall, St Salvator’s Chapel, Lower College Hall
• Rooms within halls of residence
• Locations within Schools e.g. a clean room with the School of Physics and Astronomy

The tours give a unique insight into locations that are normally restricted to the general public so this help visitors, such as prospective students, decide whether to book a venue or rent accommodation. Parents have particularly appreciated the ability to see the venues for graduation.

Full Visual

The high quality virtual tours were taken by Full Visual, a company based in Edinburgh. Their very reasonable cost has enabled us to commission tours of bedrooms and kitchens from each of the University halls of residence.  Compared to conventionally commissioned 2D photography, the virtual tours are very cost effective, especially when you consider that each tour is comprised of over 100 photos!

Quicktime vs Flash

The tours on the University website are currently in Quicktime movie format.  The website will be updated in the near future with tours in Flash, which is more universally supported by web browsers and provides a better user experience e.g. controls are overlaid on the screen to allow the user to zoom in and out of the tour.

So, if you want to give visitors to your website a unique view of your university, I would highly recommend the friendly staff at FullVisual!

So, another poll for you: who (primarily) trains your CMS end-users?

Thanks for your help, and feel free to leave any comments.

The online documentation takes you so far, and outlines the various steps:

1. Set up a development environment (Consider the uPortal Quickstart)
2. Copy the entire skin directory
3. Rename the skin directory
4. Register the new skin in the portal
5. Make modifications to skin files
6. Test the new skin in a test environment
7. Move the new skin to a public environment
8. Restart the portal server
9. Verify the new skin within the portal

But it’s the finer details that I’ve struggled with. Thankfully we’ve got a contract with uPortal consultants Unicon who came up trumps last night with a top tip that has sped up development incredibly.

Creating a new skin directory

Steps 2 and 3 above instruct you to “Copy the entire skin directory” and “Rename the skin directory”.  Here’s what I did.

uPortal comes with a default theme (called universality) and two skins (uportal3 and ivy). In uPortal themes control the page structure and layout, while skins control the design of themes.

For our purposes the ivy skin was close to what we wanted to achieve so I just copied the ivy folder within the uPortal war source directory (\uPortal-3.1.1\uportal-war\src\main\webapp\media\skins\universality\) and renamed it standrews.

This new standrews directory contains the following files and folders:

• [images]
• ivy.css
• ivy_base.css
• ivy_jsr168.css
• ivy_legacy.css
• ivy_thumb.gif
• jquery.css

The next step was to rename any instance of the old skin name (ivy) with the new (in this case: standrews).  So we now get:

• [images]
• standrews.css
• standrews_base.css
• standrews_jsr168.css
• standrews_legacy.css
• standrews_thumb.gif
• jquery.css

But it doesn’t stop there.  There are also references to the theme within the standrews_base.css file.  I used my web editor of choice (Blumentals WeBuilder 2010) to replace within these files an instance of ‘ivy’ with ‘standrews’.

The standrews_thumb.gif file shows a thumbnail screenshot image of your new theme, but since I’ve not created it yet I simply edited the existing file to make it look different from the original.

Register the new skin

The next step is to register your skin within uPortal by editing the skinList.xml file within the uPortal-3.1.1\uportal-war\src\main\webapp\media\skins\universality\ directory.

It’s simply a case of copying the XML entry for ivy and making the necessary adjustments, e.g.

<skin>
<skin-key>standrews</skin-key>
<skin-name>St Andrews</skin-name>
<skin-description>New design</skin-description>
</skin>

Redeploy uPortal

Redeploying uPortal (ant deploy-war) and restarting Tomcat will now give you the option of your new skin.

So far so good.

Modify skin files

But it’s step 5 that I was struggling with: make modifications to skin files.

The problem is that once I’d discovered where Tomcat stores the files: apache-tomcat-6.0.18\webapps\uPortal\media\skins\universality\ (and accounting for uPortal minifying the files too) whenever I made a change to a CSS element within, for example, standrews_base.min.css and then refreshed my browser nothing would happen.

Turn off uPortal caching

And I couldn’t find any documentation to explain that uPortal itself was caching the CSS and JavaScript files used by the skin.  Not the browser, the application.

I fired off another email to Unicon and within a couple of hours (they’re in the US) I got the reply I was looking for:

The caching can be turned off by commenting out a couple lines in the web.xml file.  The web.xml file can be found in the following locations:

• /path/to/uportal-war/src/main/webapp/WEB-INF/web.xml
• /path/to/tomcat/webapps/uportal/WEB-INF/web.xml

Commenting out filter-mapping for *.css and *.js disables the caching. The code that needs to be commented is around line 186. This is what it looks like in my environment.

<!-- Comment out filter for development purposes
<filter-mapping>
<filter-name>pageCachingFilter</filter-name>
<url-pattern>*.js</url-pattern>
<url-pattern>*.css</url-pattern>
</filter-mapping>-->

I then redeployed uPortal and that was it.  That was the missing link.  Now I can edit the CSS files, refresh my browser and there are the changes.

That’s one piece of information that would be a welcome addition to the JA-SIG Wiki.

Gareth @ St Andrews