Search should be clairvoyant: like a magical librarian who somehow correctly guesses what it was you were looking for; offering it up within a fraction of a second, along with a wealth of additional filtering options and navigational possibilities.

Without wishing to destroy the magic, here are my seven steps to improving findability:

1. Define what relevancy means in this context

Relevancy is a difficult thing to pin down. A set of search results is more or less relevant on the basis of how well the information retrieved meets the need of the user. Arriving at a definition of relevancy therefore means doing some fairly detailed analysis of your users and content. Some BIG questions need answering.
Is recall or precision more important? How do you go about catering to the competing needs of different user groups?

Clearly, discussions need to be had and decisions made. During this process it will be worth considering a range of scenarios where you might like to boost certain results over others:

• Field weighting
  e.g. results within titles are more relevant
• Recency of data
  e.g. results from recent data are more relevant
• Search phrase density
  e.g. results which contain the most number of uses of the search phrase are the most relevant
• Search phrase term proximity
  e.g. results where multiple terms are nearer to each other are more relevant
• Records which have been bookmarked, cited or linked to
  e.g. results which have already proved themselves to be useful to other users are more relevant

2. Provide lots of options, not just lots of results

Findability is not just about returning relevant results. A good search implementation will also provide lots of additional further options to the user, which they can use to hone in on exactly what they were searching for. Examples of this include providing:

• Meaningful facets through which the results can be filtered
• ‘Did you mean…?’ option – for alternative spellings
• ‘Users who searched for x also searched y’ option – for related searches
• Clustering of search results, e.g. by topic
• Sort options
• Hit-highlighting – to highlight the phrase terms in context

3. Enriching the data

Data not only has to be marked up consistently and correctly, it can often benefit from some enhancement before it goes online. In practice, this can mean additional classification processing or entity extraction through text mining. The goal is to ensure the content itself is rich enough to support the sort of advanced searching and filtering that we want to build within the site.

4. Measure relevancy

It’s worth setting up some relevancy metrics to monitor how search is performing over time. A good method is Mean Reciprocal Rank. To implement this you track click-throughs to search results, giving each click-through to a first result a score of 1, each click-through to a second result a score of 1/2, each click-through to a third result a score of 1/3, and so on. Adding all these together will give you the ability to track an overall relevancy score, with a higher score meaning that top links are performing better.

It is also a good idea to monitor searches that return zero results. A monthly list should be reviewed in case there are some sensible search queries in there which will have resulted in user frustration.

Regular reviews of search analytics are a vital part of ensuring that search is still performing well as the site and its content change over time.

5. Improving the user’s query

Normalising the user’s search phrase (and indeed the search index data) can help to improve findability. The following are all ways in which you do this:

• Converting all letters to lower or upper case
• Removing punctuation, accent marks or diacritics
• Expanding abbreviations
• Removing stopwords or “too common” words

Recall might also be improved upon in certain scenarios by converting the users query into a fuzzy query (to return results for close matches to the search terms in order of how well they match). It may also be worth expanding the user’s search to include synonyms using a thesaurus (to return results where matches have been found for the same or similar concept).

In these ways it is possible to enhance the input query before it has even been sent to the search engine.

6. Tuning the site for third party findability

Lots of users (yes, perhaps even MOST) start their search using a third party search engine. It is therefore essential that the site is Search Engine Optimised, meaning lots of quality in-bound links, the use of semantic markup, micro formats and much, much more.

It may also be worth creating an Open Search API – so that third party use of the site’s search facility is possible.

7. Finding also means re-finding

There is a very good chance that users will want to re-use the entries that satisfy their information need. Consequently, improving fundability should also mean making it as easy as possible for users to re-find what they found before. Helping users in this way can be done with features such as:

• Bookmarks
• Saved searches
• Direct exporting to citation software

So there you have it: seven steps to findability. It is a BIG topic and I’m certain to have missed out important considerations. Please do feel free to publicly rub my nose in some of them by responding below!

Some publishers choose to adapt an existing off-the-shelf journals platform to meet their needs for consolidation. However there can be technical problems inherent in this approach.

In a recent post to the CrossTech blog, publishing guru Geoffrey Bilder analysed the issues facing CrossRef members wishing to use the DOI system for non-journal content. Geoff’s analysis holds good for more than just the CrossRef DOI system, so I’ve taken it as a starting point below.

Reference publications and databases introduce fundamental challenges to any existing system designed around the journal article content model. These challenges fall into two areas:

• Structure. Reference works and databases can have complex nested substructures and there is a need for granular identification of these content substructures along with a mechanism for recording the relationship between them (e.g. “part-of” relationships between sub-section, section and chapter divisions, as well as “previous-next” navigational relationships between entries).
• Versioning. Unlike most journals, many reference books and databases change over time. To properly support archiving and perpetual access business models, there is a need to identify and maintain previous versions of reference content.

Both of these areas require support from the core architecture of any publishing system; without such support publishers have to resort to ugly work-arounds such as coercing all content into journal-article-shaped chunks. Such work-arounds fundamentally compromise the end-user experience and ultimately risk devaluing the publisher brand.

Furthermore the technology stack commonly used to build a typical journals system does not necessarily provide a good base to build support for the structural and versioning requirements outlined above. This is because the mixture of technologies used tends to match closely the typical structure of a journal article.

In an article the metadata and content are two separable parts which map nicely to a relational metadata store (typically SQL or RDF) plus a full text retrieval engine (Lucene/Solr, Autonomy, etc). Although the full text may contain semantic annotations such as chemical or gene markup, the homogenous nature of the content means that a single metadata schema can be devised which will fit the whole collection well.

However, when publishers want to add non journal content to the system this simple separation of content and metadata will no longer suffice. Reference and book content is much more demanding in terms of hierarchical structure and navigation. Many hierarchical structures in reference books cannot easily (if at all) be modelled using conventional relational metadata; these structures fit much more naturally and easily into native XML. Trying to create a single relational metadata schema capable of modelling all hierarchies across the full variety of reference and book content that publishers produce is an impossible task.

The structural problems of adding books and reference content to systems designed to separate full text and metadata can be broken down into two distinct areas:

1. Fragile schema problem. The problem of updating conventional database schemas as requirements (and the real world) change is often called the fragile schema problem. Because the design of the database must be fixed at the outset, any changes to the system, to accommodate extra metadata, new content types or changes to business process become costly and risk-laden. This is because assumptions about the structure or schema of a database tend to be hard-wired into the structure of all the software written to talk to the database.
2. Divorce of metadata from full text. Systems which use RDF or SQL databases for metadata suffer from a fundamental structural weakness as it is normally impossible to issue queries which examine both the full text and metadata within a single request. RDF suffers particularly in this respect as it has no support for XML mixed content; full text search plays no part in the RDF world view. Furthermore, such systems also often require content to be ‘loaded’ into several different internal content stores (e.g. once for full text index, once to ‘strip’ metadata to the RDF/SQL store). This builds a structural inefficiency into the system as content must be found, queried and updated in multiple locations.

When we design the architecture for our publishing platforms we like to think hard about these problems. Often we conclude that XML database technology (such as MarkLogic Server) provides the best solution because it allows content to be stored and queried in a single place. Using an XML database removes the artificial split between content and metadata inherent in conventional journals systems and allows us to build search queries across an entire collection of content. This in turn helps to drive discovery and usage by building deeper links between related content and combining and assembling content from an entire collection in new ways.

However we also realise that different clients have different needs and that it is critical to prioritise meeting business goals ahead of making specific technology choices. The motivation for our overall technical architecture choice in a given project is simple; to learn the lessons of past systems and ensure we choose the best possible technology basis for any new system. Understanding the problems publishers have faced in trying to adapt legacy journals systems to the more challenging world of books and reference helps us to make the most appropriate technology choices for future publishing platforms.

The inaugural Semantico Symposium was held recently in London to discuss implications of the shift to mobile for publishers and information providers. An invited audience of publishing industry leaders debated the issues under Chatham House rules, covering the following three themes:

• Devices and technology
• Business models
• Future strategy options

This was a stimulating event with a high calibre guest list, delegates attending from organisations including Oxford University Press, Nature Publishing Group, Macmillan Education, Wiley-Blackwell, CrossRef, CABI, BSI Group and the Institute of Engineering and Technology. To do justice to the discussion, we’re going to report it over a couple of blog posts, starting with initial theme of devices and technology (yes, it’s a partwork!).

Forget devices, focus on the underlying technology

If proof were needed that these are nervous times for publishers, just consider the case of Flash. Not only does Apple not support Flash technology on the iPhone or iPad, but the world’s most popular video-sharing site, YouTube (owned by Google), is quietly in the process of moving away from Flash video. In addition the emerging HTML5 standard, which aims to reduce the need for such proprietary plug-ins, looks likely to make it all but obsolete.  So will Flash die? Almost certainly, say the tech-heads.

This is appalling news for publishers with large amounts of legacy online content in Flash. It also serves as an example of one of the strongest themes to emerge from our Symposium, which is that publishers and information providers who hope to thrive (or at the very least survive) in the turbulent times ahead would be well-advised to disregard, to a certain extent, the hype and wow surrounding high-profile device launches like that of the iPad, and focus on the underlying technology issues in cross-platform delivery. That’s where the real uncertainty lies. Marvellous though they are, it’s not about the devices – but about the content, and the user’s experience of the content.

There is no denying that the iPhone has instituted something of a paradigm shift in the delivery of content, but notwithstanding this undoubted fact, a good deal of skepticism was evinced by our delegates about what is perhaps the most significant innovation to be introduced along with that device, the App Store.

A significant strand of opinion believes that an app is really not that much different from a mobile-optimised website. As far as the user is concerned there is little difference. In the not-too-distant future, it was predicted, you will download something you think is an app but you will actually be interacting with a website optimised for mobile use.

The iPad experience of web surfing (about 42% of our small but select sample had had hands-on experience of the device) might make us question whether we need apps at all, in the opinion of one delegate. Maybe what we need is not apps but better-designed, more mobile-friendly websites.

So far, so heretical

However, there is another strand of opinion. From the user’s point of view, the experience of using an app is utterly different from that of using a PC. One virtue of the app is that it does a very narrow, specific thing. Apps streamline our use of the internet and cut out – or at least reduce – much of the pain associated with PCs (e.g. constant downloads of plug-ins, patches and updates, the state of total war we have to live in with viruses, spyware and spam, etc.).

A website is always going to feel like a place you go to, to harvest a crop of information. In the case of an app, the crop is turned into biofuel: information becomes the petrol that gets your knowledge car from A to B – to a designated destination. A website might be a field of dreams (if you’ll excuse a criminally over-used film reference), but an app helps you actually do something.

These two points of view are not, in essence, irreconcilable. It’s a matter of perspective; of whether you are looking at things from the producer’s end of things or from the consumer’s. If you strip away the wow, yes, an app is no more than a website. But what produces the ‘wow’ is fantastic usability – and that’s a matter of primary importance for most end-users.

Search lags on mobile

… Which is not to say at all that the current generation of mobile devices together embody a giant leap forward for usability. In actual fact they can look like a bad step backwards.

In particular, search took a while to get established on the desktop internet, and to reach its current state of utility. By comparison, search on mobile is very slow at the moment, even on 3G networks. Also, it is not that easy to find the app you want: the discoverability of apps is not great. This situation is liable to get worse before it gets better, as apps and app stores proliferate.

A certain frustration is surely excusable for those who soldiered through the difficult early years of the millennium when publishers were just beginning to build their first sites, and had to cope with the teething troubles of the early web – only to see many of the same problems coming back to them in 2010. There is a new network, and it has yet to organize itself effectively.

Monitoring the Big Tech face-offs

Focusing on underlying technology and networks throws a deal of emphasis on the importance of monitoring and understanding what is going on with some of the major tech companies – and not solely because a few (particularly Amazon and Google) have forged themselves into the publishing value chain, where they are fast becoming almost unavoidable links. We mentioned Flash earlier, owned by Adobe, but there are others to consider as well.

Apple’s new prominence, which has come about largely as a result of the huge success of the iPhone, is beginning to foreground some of the ways it has of going about things that most annoy people. The dead hand of control that it exercises over what can and cannot be offered through the App Store – amounting to censorship – has led to comparisons with China. Will Google’s Android prove to be a viable Open Source alternative?

Apple has become the company to attack, and the company to position against.

Microsoft appears to be positioning against Apple with Windows 7 by placing emphasis on social networking. This is an important battleground if it really can be established as a point of difference. RIM’s Blackberry Curve phone has crossed over into the teenage market not only because it is a lot cheaper than an iPhone, but because it offers their young audience a more effective way of interacting with their online social networks. It is too easy to write off Microsoft and believe that the important dust-up nowadays is between Apple and Google, but there may well be life in the old dog yet – and Microsoft still has significant market share in mobile operating systems.

Publishers likewise dare not forget, in the age of the read/write web, that online publishing is not just about how the stuff gets delivered, but also about how it gets produced, edited, commented, redacted, peer-reviewed … etc., etc. Nowhere is this more true than in the field of academic publishing – because one of the central concerns of academic publishing is scholarly communication.

What this becomes is a debate about how we consume and produce information. Corporate positioning takes on a philosophical, even ideological aspect, the nuances of which publishers have to tune their ears to detect. The first task is to be aware.

Government unhelpful

Someone who seems to have a bit of a tin ear in this regard is the great clunking fist himself – if Gordon Brown can be held responsible for the controversial Digital Economy Bill which, at time of writing, is awaiting Royal Assent. There wasn’t much controversy here: instead it was roundly condemned as a piece of rushed and unworkable legislation that will, nevertheless, no doubt remain on the statute books for many years to come.

The debate continues

Tune in next time for a further report from the Symposium, as we move to discuss business models.

More on this excellent seminar can be found at The International Association of Scientific Technical and Medical Publishers website.

Video by River Valley TV.

1. Site Copy

Copy has a direct impact on search engine optimisation as it provides the crawlers with meaningful semantic information about the site. The book content of any publishing site will contain excellent copy but marketing and home page material should be carefully considered as this is often where crawlers, users and off-site links find themselves first. The number of keywords per site should be limited to three or four and these should be added to the content in such a way that the content remains natural and readable.

Particular attention should be paid to drafting text for hyperlinks. This is because the words that point to a particular page are heavily weighted by Google when determining keywords for that particular page. Never use phrases like “Click here for our contact form” (for example); instead use words that describe the page you’re linking to by thinking of what a user would search for if they were looking for that page. In our example this might be “Contact us now using our contact form“.

2. Incoming Links

Google rates a pages relevance using an algorithm called PageRank which is calculated based on the number and relevancy of links pointing to the site. The concept is that each link represents a vote of confidence for your site. But the votes are not equal, links from pages with a high PageRank are worth more. The PageRank of any site is shown on the Google Toolbar, which you can download from Google. Wikipedia have a good explanation of the PageRank alogorithm.

3. Google Webmaster tools

Google Webmaster Tools offers a comprehensive selection of tools for configuring a site for improved search results on Google. The main offering is the ability to submit an XML sitemap that improves the crawl across the site making it easier to control what pages are being indexed. The use of XML sitemaps will improve discoverability of the content for any site. In addition to this, is the ability to see when crawls have taken place and when they are next scheduled. This is of particular importance on each content update to ensure that the most recent updates have been picked up. Google Webmaster Tools also provides:

• A top search queries feature, where information about user search queries that have returned pages from your site are shown.
• An interface for quickly finding all links to a site, allowing incoming links to be tracked.
• Keywords and their frequency within the site.
• Internal links.

4. Google Analytics

Google Analytics offers further integration with Google search as the script that enables the tracking of the site provides constant activity feedback back to Google. Google Analytics should be used to determine where users are coming from and where users are landing. This information in itself will not help search ranking and discoverability, but it will provide metrics with which to measure the progress of any search engine optimisation activity. There are other analytics packages, such as Yahoo! Web Analytics (which provides real-time statistics), but Google Analytics has been recommended as it is the leading search provider and integrates well with other Google tools.

4. URL structure

Have a look at many complex publishing sites and you might notice that there are no PageRanks on many of the deeper linked pages within the sites. This is most likely due to Google’s crawlers not reading complex page URLs as these pages are often less meaningfully marked up and are the result of a a query. For more details you can read Google’s explanation of this behaviour.

Many sites can benefit from an overhaul of the URL structure to provide more meaningful and less complex URL structure. Care needs to be be taken in making sure that the original links are still operable and their appearance in search engine results will diminish over time.

5. Error pages

If the user requests an unknown page, return a friendly error message and use the correct HTTP status code. This might sound obvious, but it’s a surprisingly common mistake on publisher platforms. If you don’t return the correct error code (for example “404 Not Found”) then Google will cache dead or bad links on your site, leading to less than optimal search experience for your users. Similarly, link resolution services such as CrossRef can only quality check your DOI metadata if the HTTP codes are used correctly.

Conclusion

In conclusion, a little attention to the copy and structure of your site can pay dividends in terms of search engine rankings and discoverabilty.

To be fair, it’s not always the developer’s fault. There are times when their hands are tied, even though they may have the best intentions at heart, by budget constraints – or by a customer who is not willing to pay a little extra money for features that will make their website more accessible. There is also the lack of tools in their working environment which would enable them to fully test a web site (the cost of these tools is not inconsiderable). The aforementioned problems and hindrances can all add up to the development of a product that does not meet accessibility standards.

The Standards

The standards themselves can be migraine-inducing and can some times cancel each other out. And there are so many of them. Different countries have their own set of standards and sets of laws; the UK has the Disability Discrimination Act, the USA has Section 508 of the Rehabilitation Act, Japan has the Japanese Industrial Standards X 8341-3 and the W3C has a set of its own. Which one is the best? Which one should you be focusing on? Should you be using online or desktop tools to test your website?

In a nutshell, your best tool is simple common sense. Look into the web site you are developing, identify its structure and content, and the answer should present itself. If you feel you do not have the necessary skills and knowledge to improve the accessibility of your site alone however, you may want to consider hiring an experienced professional to do it for you. Both online and desktop tools, either free or not, are very helpful but they lack the human factor, and an experienced eye.

The sooner you start implementing accessible features in the development process, the better. It will save you and your customers time and money but in return, you will earn the users’ trust and loyalty. If they can use the web site you have created without difficulties, they will come back again and again.

Screen readers

One extremely helpful tool to test your web site for accessibility is a screen reader. Screen readers are applications which you install on your workstation and they will “read” the contents of a screen (dialogue boxes, application interfaces and web pages) out loud to you. They are mostly used by users who have visual impairments and thankfully, they are also used by a small percentage of web developers for testing according to a recent survey conducted by WebAIM.

The Windows operating system has one set up out of the box called Narrator, so does Mac OS X Leopard in the form of VoiceOver, and Ubuntu, a popular Linux distribution also comes with its own screen reader, named Orca pre-installed.

NVDA

Personally, I have never found Narrator to be very easy to use and have encountered some problems while using it for testing web sites so I started looking for an alternative solution. The answer to my problem came in the form of  “NVDA” (NonVisual Desktop Access). And best of all? It is absolutely open source and free. Of course, there are other products out there such as the ever-popular JAWS, but this small application can save you (or your business) money and it works really well for a piece of software that is still in its infancy.

The NVDA web site offers extensive documentation on how to install and use the application, which can also be run from a USB stick (portable version). As expected from a screen reader, most of the functions are accessed via keyboard shortcuts which take some time getting used to if you have not used such a programme before. But once you master the shortcuts you will realise how powerful this tool is in helping you build web sites and web applications that are easily accessible by visually impaired users and it will help you identify any problems that a screen reader use might face while trying to use your web site.

That is not the end of your journey though… Do not forget that there are other impairments such as colour blindness, auditory impairments, cognitive disabilities and  movement disorders such as the Parkinson’s disease, to name but a few. These can cause difficulties to many who use the Internet on a daily basis and using a variety of tools to check your web sites can help make your site more accessible for them, also allowing you to achieve your goals faster and more efficiently. It might seem difficult to follow all these guidelines and to use these tools at first but it soon becomes second nature. And the end result is a web site that can be accessed by everyone without difficulties.

Good luck!

Who am I today?

Who wants to maintain multiple personalisation logons on different websites?

How many usernames do you have? Do you really keep different passwords for all of those sites? And do you trust all of the sites you’re registered with to keep your password secure, given that it could be used to log in to many other websites (unless you really do keep different passwords for each site)?

The only way of mitigating this problem is to move the user sign-on and registration processes away from individual websites to centralised systems designed specifically to manage your online identity information.

A single centralised identity provision service for the whole internet can clearly never exist; consequently we have to live with the fact that there have to be multiple identity providers. But within this why should publishers proliferate their own tiny personalisation islands, often not even allowing users to share personal information and preferences between a single publisher’s own different websites, let alone across different publisher websites?

Informal evidence from librarians suggests that most users will not use the personalisation features that publisher platforms provide at all if they require a separate registration process.

Where am I from today?

Given the fact that multiple identity management systems exist, the login process for any website supporting devolved or federated authentication needs to allow the user to select which identity provider to use in order to allow the user to login. And this is the first part of the usability challenge – designing a good user interface for selection between multiple providers is hard because the whole concept of identity providers being separate from individual websites is alien to most users’ web experience.

When I login I expect a website to ask me my username and password. I don’t expect to be first asked where I come from. This confusion is further compounded by the large number of identity providers in the Shibboleth system (740 in the UK Federation alone). Asking a user to select from a list of 740 places where they could be from is clearly a massive barrier to usability. Only the most determined user will survive the logon process!

OpenID based systems don’t have the problem of large federations as potentially anyone can set up an identity provider service. The usability challenge here is to pick the best (shortest) list of providers and give the user a way of entering a (very long) text string if their provider is not on the list. Again another usability challenge for all but the tech heads amongst us.

How can I logout of the web?

Many web users find the concept of logging out of a web site hard to understand. The continuing growth in usage of social networking sites means the problems of leaving yourself logged in to a site on a public terminal have to be spelt out very clearly on all courses for internet safety taught to young adults. Think what could happen if you leave your Facebook profile open to the next stranger to walk up to a terminal.

The Shibboleth and OpenID systems both suffer from logout issues. Because these systems offer the benefit of a single sign on process, once you’ve authenticated with your chosen identity provider you can enter any number of participating websites without having to type your credentials again. This sounds like a benefit, until you realise that on a public terminal your identity will be used to enter these other sites. The Facebook problem again, this time replayed in the context of a publisher provided site.

Surely the designers of these technical systems thought this through? Well, theoretically Shibboleth supports the idea of federated logout, but OpenID has no support for this at all. And the Shibboleth system has serious technical problems which have not yet been overcome.

Currently the only practical solution is to educate users to close down and exit their web browser when leaving a public terminal. Hardly intuitive or a good user experience.

But what does a Project Manager really do?

Here are my top seven attributes of effective project management: the things we PMs ought to be doing to keep everything on track …

1. Building confidence within the whole project team.

Without confidence, a project can very quickly lose its way. The Project Manager should therefore regularly check the health of ‘project confidence’ by reviewing the following questions:

• Is there confidence that the project is on track?
• Are roles and responsibilities clearly defined and understood?
• Is everyone happy?

In my experience, regular demonstrations of progress are the best way to build trust. With regular review meetings, there is the opportunity to review the project against its business case and to provide assurance that the development is on track. It is the Project Manager’s job to ensure that these reviews take place at the right intervals, that the right people are there, and that the points raised during the review are followed through.

2. Managing change

As the saying goes: the only constant is change. Requirements that were specified, costed and signed off at the outset of a project will often need to adjust to fit the changing business context. Project teams usually uncover unexpected additional complexities, or indeed opportunities, along the way. Either way, it is sensible to plan for change.

Part of the Project Manager’s role is to coordinate change with as little pain as possible. This can involve de-scoping lower priority deliverables in exchange for incorporating new ideas within the existing budget. More often it means arranging for an additional budget with a corresponding adjustment to the project plan. Clear communication and a documented agreement are essential for ensuring that change is managed effectively.

3. Planning

One could say that a Project Manager is like the conductor of an orchestra. Without necessarily being proficient on any particular instrument, the conductor coordinates the intricate timings and dependencies within a piece of music. He is responsible for each detail and also for the overall quality of the final piece.

In reality, a Project Manager is perhaps more like a bus conductor – handing out tickets and coordinating at what points people get off and on. However, it is crucially important to plan the route the bus is going to take. As such, a Project Manager needs to agree ’smart targets’ with the production team and to track progress carefully. Without this the passengers would have no idea as to where they were going or indeed when they were going to arrive.

4. Communication

As everyone knows, enterprises of any sort in our knowledge economy rely heavily on the flow of knowledge. Project Managers must ask themselves:

• Does each team member know all that is necessary to do their job?
• Are project requirements well documented?
• Is the business case for the project well defined and understood?
• Are the key stakeholders being given the appropriate opportunities to review progress?
• Is there an audit trail of project decisions, issues, risks, changes?

It is easy to see that without an effective communication strategy in place a project is likely to suffer. Here at Semantico we have set up project processes and template documents to help to make our communication consistent and improvable. We use web-based tools such as our issue-tracking system Jira which ensures that all issues are managed through a scheduled workflow and can be audited.

Of the various types of project meetings I coordinate, my favorite is the morning Scrum with each project team. These meetings are ultra-efficient – no more than 15 mins – and the agenda is always the same:

• What progress was made yesterday?
• What is the plan for today?
• Are there any impediments stopping you from proceeding?

These meetings are a great way to monitor progress and identify any ‘blockers’ which need addressing.

5. Risk analysis

The Project Manager is ultimately responsible for ensuring the health of the project. Regular risk analysis is an essential part of this. The process starts with identifying possible risks so that they can be logged, evaluated (scored according to impact and probability) and assigned to ‘risk owners’. Naturally, logging them is not enough, it is also important to make a decision about how best to manage each risk. This will sometimes take the form of deciding on a contingency plan. However, it is preferable, where possible, to mitigate the risks in the short term by taking actions to reduce the probability or impact.

6. Problem solving

Even with the best planning, communication and risk analysis, you can still encounter tricky times in a project. Here the Project Manager must do their best to identify win-win outcomes. I believe that the best way to do this is to remember to focus on ‘interests’ as opposed to particular ‘positions’.

There is a famous story about two sisters arguing over an orange. They eventually settle on dividing it in two. They later discover that one sister had wanted the peel and the other, the fruit. Had they communicated more effectively what their interests were, both could have had 100% of what they wanted. However, because they focused on winning rather than win-win, they each only got 50%. The moral is to remember to delve into the real interests of each party, and only then to consider solutions that deliver to all. Likewise, a Project Manager must consult with all key stakeholders before recommending a solution that works well for everybody.

7. Quality control

Quality is defined in ISO 9000:2000 as ‘The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs’.

It is difficult to deliver ‘implied needs’ with precision – but it is important to try! The unspoken, undocumented requirements can be very important. It is likewise essential to manage even the smallest details that crop up. Project Managers know from bitter experience exactly where the devil is – and by paying close attention to the detail they help to ensure that small problems don’t become diabolical ones!

All Semantico projects, big or small, include a traditional ‘Quality Assurance Cycle’ where our software gets tested thoroughly at the end of each iteration. Where possible, we also like to arrange mid-project web demos to provide our clients with the opportunity to review our progress. As already mentioned, this is the single most effective way to build project confidence. Crucially, it also provides an opportunity to review the software’s features and functions before it becomes too expensive to change direction if the need arises.

—-

So there you go, seven important attributes of what a Project Manager’s job should be – if they’re doing the job properly!

The students’ first year Human Computer Interaction (HCI) module asks them to design an “electronic document shopping system” that could enable book publishers to create a unique environment dedicated to the marketing and sale of electronic-only content.

We were invited to talk to the students, explaining a little bit about the commercial environment of perfoming HCI, or usability design, and how their project relates to the live work that we do at Semantico. Expecting a sea of blank faces, I was pleasantly surprised to find that they were interested, listening, and even posed a few questions. Questions that, sometimes, were not easy to answer.

Here’s the news:

Student: “I just wanted to know why DRM is still an issue considering the lessons learned by the music industry, now that iTunes has unlocked everything”.

Me: “erm…”

To be honest, I don’t know. There are lots of issues affecting the feasibility of eBook publishing models right now, from user demand to digital paper technology, but DRM is a funny one. In many respects, the student in question had just pointed out the elephant in many of our rooms.

But that’s old ground. What was even more informative about the time I spent on campus on behalf of Semantico was seeing and hearing today’s University students in action, and it caused me to think again about the nature of user research. Are we trying to design for today, or to capture and anticipate tomorrow?

eBook publishing stands on the brink of a new era. Users may not know yet what they want. We may need to take the lead in answering some of the biggest questions: What do we sell – chapters, volumes or subscriptions? How do we monitor use? Who controls the content? Is platform independence possible?

Those students didn’t have the answers, but as many of the boldest and most successful online innovations have germinated in halls just like this around the world, we are certainly going to be listening to their ideas.

Each year, the team uses the calendar to illustrate ’stoopid’ interface choices, from distracting mashups to meaningless metaphors.

Great for cubicle walls.