This seven point checklist presents some steps that creators and managers of community digital archives might take to make sure that their data is available in the long term. It is useful for many circumstances but it will be particularly relevant to community archives that depend on third party suppliers to provide technical infrastructure.

The economic downturn and poor trading conditions mean that some technology providers are unable to continue providing the services upon which community groups have depended. Because hardware, software and services are often very tightly integrated, the failure of a technology company can be very disruptive to its customers. This is especially true if systems are proprietary and customers are ‘locked in’ to particular services, tools or data types. The key message is that community archives need to retain sufficient control of content in order that services can be moved from one service provider to another. Change brought about through insolvency is disruptive and unwelcome: the more control that a group has over content, the less disruptive it will be.

Consideration of the following seven points might help reduce disruption in the event that a content management company withdraws its services.

1. Keep the Masters

Many community groups hold a mix of photographs, sound recordings, video and text in digital form. Some of these are digital copies that have been scanned – such as old photographs, letters: some are ‘born digital’ using digital cameras or digital sound recording equipment. In every case the underlying data will be captured in one of a series of file formats. A simple rule of thumb is that a high quality ‘original’ is retained which has not been processed or edited and that the community group has direct access to this high quality ‘original’ without relying on the content management company.

2. Know What’s What

The rapid proliferation of digital content means that it can be hard to keep track of content – even in a relatively small organisation. Typically a content management company will use a database to catalogue content and then use the database to drive a Web site that makes it available to the public. So, to retain control over content community archives should keep a copy of the catalogue. The database can be complex and even when it is implemented in open source software, it can be proprietary.

The tools used to describe a collection depend on the nature of the collection. For example archives are often described in ‘Encoded Archival Description’ while an images might best be described using the ‘VRA Core’ standard. It’s useful to know a little about the standards that apply in your area.

3. There Should be a Disaster Plan

Most content management companies will have some kind of disaster plan – a backup copy which can be made available in the event of some unforeseen break of service. Good practice means that the content management company should keep multiple copies of data in multiple locations. It is reasonable for a community group to see a copy of the disaster plan and for parts of the disaster plan to be written into the contract between the contractor and the community group. You should ask for evidence that the disaster plan has been tried out and agree how quickly your data would be restored should a disaster occur. It is also reasonable to request or keep a copy of your data for safekeeping, though you may need to plan how and in what format you receive this and you may want to update it periodically.

A common approach to backups is called the ‘Grandfather – Father – Son’ approach. A complete copy is taken every month and stored remotely (Grandfather). A complete copy is taken every week but kept locally (Father) and a daily backup is made of recent changes (Son). The frequency of backups should be dictated by the frequency of changes. Ask your service provider how they approach this.

3. Agree a Succession Plan

A good content management company will also have a succession plan and be willing to involve you in this. Although it is not a happy topic, a shared understanding of rights and expectations of what should happen when either partner is no longer able maintain a contractual relationship can go a long way to reassuring both parties. This is particularly important where a hosting company is employed to deliver content which is not theirs. It is not unreasonable to include a note within the contract clearly identifying that content provided to the hosting company remains the property of the party supplying it and that should there be any break in the contract that the contractor will be obliged to return it. In reality this does not guarantee that you will get content back if a company goes into liquidation but it does secure your right to ask the administrator for it, and if that is not successful then you are then clear about your rights to use the masters and backups which have been lodged with you.

5. Know Your Rights

Rights management can be daunting but it is important to be clear when engaging a third party contractor of the limits of what they are entitled to do with content that a community archive might produce. A good content management contract is likely to give the content management company a licence to distribute content on your behalf for a given period – and it should also specify that technical parts of the service such as software are the property of the content management company. In reality this can be complicated because the community archive may itself be depending on agreements from the actual copyright holders and elements of design and coding will be shared. But so long as you are clear that the content provider will not become the owner of the content once it’s on their site, and that you can terminate their licence after appropriate notice, then it will be easier for you to pass the masters to a new company.

6. Find a Digital Preservation Service

A small number of services exist to look after data for you: either funded as part of existing infrastructure or as a service you can buy. Many local government archives and libraries are developing digital preservation facilities for their own use and might welcome an approach from a community group. Other types of partnership might also make sense: many universities now maintain digital archives for research so it might be useful to talk to a university archivist. Facilities also operate thematically – for example there is a national facility allowing archaeologists to share short reports of excavations. Image and sound libraries may also be able to provide an archival home to data or provide advice, while other services provide digital preservation on a commercial basis. In the same way publishers have started sharing some of their content to reduce their risks and risks to their clients. Having a preservation partner can be very useful for you in the short term and in the long term and will make you a lot more confident that your data will be safe even if the content management company is not around to service it.

7. Put a Copy of your Web Site in a Web Archive

There are a number of services that can make copies of online content before a supplier goes into liquidation. A free service from the British Library called the UK Web Archive exists to ‘harvest’ Web sites in the UK. It can create a simple static copy of your Web site and present this back to you under certain limitations. The UK Web Archive is free but it is based on a recommendation: you need to ask them to take a copy and need to give them permission to do so. But once you’ve given them permission they can harvest the site periodically and so build up a picture of your Web site through time. The UK Web Archive is ideal for relatively static Web sites – but is less good with sites that require passwords, which change quickly or which contain lots of dynamic content. Similar services exist such as the US-based Internet Archive have paid for services that allow users to control the harvesting of content and allow more complicated data types to be managed. Considering the ease of use and how quickly it can gather content, every community archive should consider registering with a service like this as a way to offset the risks of a supplier going into liquidation.

See the briefing paper on Web Archiving for further information [1].

The UK Web Archive is one of a number of services that can make a copy of your Website. So, in the worst case, users can be directed to a version of your site fixed at one point in time [2].

Acknowledgements

This briefing paper was written by William Kilbride of the Digital Preservation Coalition [3].

References

1. Web Archiving, Cultural Heritage briefing paper no. 53, UKOLN, <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-53/>
2. UK Web Archive, <http://www.Webarchive.org.uk/>
3. Digital Preservation Coalition, <http:// http://www.dpconline.org/>

There may be times when there is no longer effort available to continue to maintain a blog. There may also be occasions when a blog has fulfilled its purpose. In such cases there is a need to close the blog in a managed fashion. An example of a project blog provided by UKOLN which was closed in such a managed fashion after the project had finished is the JISC SIS Landscape Study blog. The final blog post [1] is shown below.

Figure 1: Announcement of the Closure of the JISC SIS Landscape Study Blog

The blog post makes it clear to the reader that no new posts will be published and no additional comments can be provided. Summary statistics about the blog are also provided which enables interested parties to have easy access to a summary showing the effectiveness of the blog service.

Reasons For Blog Closure

Blogs may need to be closed for a number of reasons:

• The blog author(s) may find it too time-consuming to continue to maintain a blog or to find ideas to write about or the initial enthusiasm may have waned.
• The blog author(s) may have left the organisation or have moved to other areas of work.
• The blog may not be providing an adequate return on investment.
• A blog may be withdrawn due to policy changes of managerial edict.
• The original purposes for the blog may no longer be relevant.
• Funding to continue to maintain the blog may no longer be available.

Prior to managing the closure of a blog it is advisable to ensure that the reasons for the closure of the blog are well understood and appropriate lessons are learnt.

Possible Approaches

A simple approach to closing a blog is to simple publish a final post giving an appropriate announcement, possibly containing a summary of the achievements of the blog. Comment submissions should be disabled to avoid spam comments being published. This was the approach taken by the JISC SIS Landscape Study blog [1]. [1].

A more draconian approach would be to delete the blog. This will result in the contents of the blog being difficult to find, which may be of concern if useful content has been published. If this approach has to be taken (e.g. if the blog software can no longer be supported or the service is withdrawn) it may be felt desirable to ensure that the contents of the blog are preserved.

Preserving the Contents of the Blog

A Web harvesting tool (e.g. WinTrack) could be used to copy the contents of the blog’s Web site to another location. An alternative approach would be to migrate the content using the log’s RSS feed. If this approach is taken you should ensure that an RSS feed for the complete content is used. A third approach would be to create a PDF resource of the blog site. Further advice is provided at [2].

References

1. Goodbye, JISC SIS Landscape Study blog, 3 Feb 2010,
   <http://blogs.ukoln.ac.uk/jisc-sis-landscape/2010/02/03/goodbye/>
2. The Project Blog When The Project Is Over, UK Web Focus blog, 15 Mar 2010
   <http://ukwebfocus.wordpress.com/2010/03/15/the-project-blog-when-the-project-is-over/>

This document is 3 of 3 which describe best practices for consuming APIs provided by others.

Clarifying Issues

Certain issues should be clarified before use of an external API. The two key matters for elucidation are data ownership and costing. You should be clear on which items will be owned by the institution or Web author and which will be owned by a third party. You should also be clear on what the charging mechanism will be and the likelihood of change.

These matters will usually be detailed in a terms of use document and the onus is on you as a potential user to read them. If they are not explained you should contact the provider.

Understand Technology Limitations

API providers have technical limitations too and a good understanding of these will help keep your system running efficiently. Think about what will happen when the backend is down or slow and make sure that you cache remote sources aggressively. Try to build some pacing logic into your system. It’s easy to overload a server accidentally, especially during early testing. Ask the service provider if they have a version of the service that can be used during testing. Have plans for whenever an API is down for maintenance or fails. Build in timeouts, or offline updates to prevent a dead backend server breaking your application. Make sure you build in ways to detect problems. Providers are renowned for failing to provide any information as to why they are not working.

Write your application so it stores a local copy of the data so that when the feed fails its can carry on. Make this completely automatic so the system detects for itself whether the feed has failed. However, also provide a way for the staff to know that it has failed. I had one news feed exhibit not update the news for 6 months but no one noticed because there was no error state.

You will also need to be weary of your own technology limitations. Avoid overloading your application with too many API bells and whistles. Encourage and educate end users to think about end-to-end availability and response times. If necessary limit sets of results. Remember to check your own proxy, occasionally data URLs may be temporarily blocked because they come from separate sub-domains.

Other technology tips include remember to register additional API keys when moving servers.

Keep it Simple

When working with APIs it makes sense to start simple and build up. Think about the resources implications of what you are doing. For example build on top of existing libraries: Try and find a supported library for your language of choice that abstracts away from the details of the API. Wrap external APIs, don’t change them as this will be a maintenance nightmare. The exception here is if your changes can be contributed back and incorporated into the next version of the external API. APIs often don’t respond the way you would expect, make sure you don’t inadvertently make another system a required part of your own.

When working with new APIs give yourself time. Not all APIs are immediately usable. Try to ensure that the effort required to learn how to use APIs is costed into your project and ensure the associated risks are on the project’s risk list.

Some Web developers lean towards consuming lean and RESTful APIs however this may not be appropriate for your particular task. SOAP based APIs are generally seen as unattractive as they tend to take longer to develop for than RESTful ones. Client code suffers much more when any change is made to a SOAP API.

Acknowledgements

This document is based on advice provided by UKOLN’s Good APIs project. Further information is available at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

About The Best Practices For APIs Documents

The Best Practices For APIs series of briefing documents have been published for the cultural heritage sector.

The advice provided in the documents is based on resources gathered by UKOLN for the JISC-funded Good APIs project.

Further information on the Good APIs project is available from the project’s blog at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

This document is 2 of 3 which describe best practices for consuming APIs provided by others.

Risk Management

When relying on an externally hosted service there can be some element of risk such as loss of service, change in price of a service or performance problems. Some providers may feel the need to change APIs or feeds without notice which may mean that your applications functionality becomes deprecated. This should not stop developers from using these providers but means that you should be cautious and consider providing alternatives for when a service is not (or no longer) available. Developers using external APIs should consider all eventualities and be prepared for change. One approach may be to document a risk management strategy [1] and have a redundancy solution in mind. Another might be to avoid using unstable APIs in mission critical services: bear in mind the organisational embedding of services. Developing a good working relationship with the API supplier wherever possible will allow you to keep a close eye on the current situation and the likelihood of any change.

Provide Documentation

When using an external API it is important to document your processes. Note the resources you have used to assist you, dependencies and workarounds and detail all instructions. Record any strange behaviour or side effects. Ensure you document the version of API your service/application was written for.

Bench mark the APIs you use in order to determine the level of service you can expect to get out of them.

Share Resources and Experiences

It could be argued that open APIs work because people share. Feeding back things you learn to the development community should be a usual step in the development process.

APIs providers benefit from knowing who use their APIs and how they use them. You should make efforts provide clear, constructive and relevant feedback on the code through bug reports), usability and use of APIs you engage with. If it is open source code it should be fairly straightforward to improve an API to meet your needs and in doing so offer options to other users. If you come across a difficulty that the documentation failed to solve then either update the documentation, contact the provider or blog about your findings (and tell the provider). Publish success stories and provide workshops to showcase what has and can been achieved. Sharing means that you can save others time. The benefits are reciprocal. As one developed commented:

“If you find an interesting or unexpected use of a method, or a common basic use which isn’t shown as an example already, comment on its documentation page. If you find that a method doesn’t work where it seems that it should, comment on its documentation page. If you are confused by documentation but then figure out the intended or correct meaning, comment on its documentation page.”

Sharing should also be encouraged internally. Ensure that all the necessary teams in your institution know which APIs are relevant to what services, and that the communications channels are well used. Developers should be keeping an eye on emerging practice; what’s ‘cool’ etc. Share this with your team.

Feedback how and why you are using the API, often service providers are in the dark about who is using their service and why, and being heard can help guide the service to where you need it to be, as well as re-igniting developer interest in pushing on the APIs.

Respect

When using someone else’s software it is important to respect the terms of use. This may mean making efforts to minimise load on the API providers servers or limiting the number of calls made to the service (e.g. by using a local cache or returned data, only refreshed once a given time period has expired). Using restricted examples while developing and testing is a good way to avoid overload the provider’s server. There may also be sensitivity or IPR issues relating to data shared.

Note that caching introduces technical issues. Latency or stale data could be a problem if there is caching.

Acknowledgements

document is based on advice provided by UKOLN’s Good APIs project. Further information is available at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

References

1. Using the Risks and Opportunities Framework, UKOLN briefing document no. 68, <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-68/>

About The Best Practices For APIs Documents

The Best Practices For APIs series of briefing documents have been published for the cultural heritage sector.

The advice provided in the documents is based on resources gathered by UKOLN for the JISC-funded Good APIs project.

Further information on the Good APIs project is available from the project’s blog at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

Make your API scalable (i.e. able to cope with a high number of hits), extendable and design for updates. Test your APIs as thoroughly as you would test your user interfaces and where relevant, ensure that it returns valid XML (i.e. no missing or invalid namespaces, or invalid characters).

Embed your API in a community and use them to test it. Use your own API in order to experience how user friendly it is.

As one developer commented:

“Once you have a simple API, use it. Try it on for size and see what works and what doesn’t. Add the bits you need, remove the bits you don’t, change the bits that almost work. Keep iterating till you hit the sweet spot.”

Obtain Feedback On Your API

Include good error logging, so that when errors happen, the calls are all logged and you will be able to diagnose what went wrong:

“Fix your bugs in public”

If possible, get other development teams/projects using your API early to get wider feedback than just the local development team. Engage with your API users and encourage community feedback.

Provide a clear and robust contact mechanism for queries regarding the API. Ideally this should be the name of an individual who could potentially leave the organisation.

Provide a way for users of the API to sign up to a mailing list to receive prior notice of any changes.

As one developer commented:

“An API will need to evolve over time in response to the needs of the people attempting to use it, especially if the primary users of the API were not well defined to begin with.”

Error Handling

Once an API has been released it should be kept static and not be changed. If you do have to change an API maintain backwards compatibility. Contact the API users and warn then well in advance and ask them to get back to you if changes affect the services they are offering. Provide a transitional frame-time with deprecated APIs support. As one developer commented:

“The development of a good set of APIs is very much a chicken-and-egg situation – without a good body of users, it is very hard to guess at the perfect APIs for them, and without a good set of APIs, you cannot gather a set of users. The only way out is to understand that the API development cannot be milestoned and laid-out in a precise manner; the development must be powered by an agile fast iterative method and test/response basis. You will have to bribe a small set of users to start with, generally bribe them with the potential access to a body of information they could not get hold of before. Don’t fall into the trap of considering these early adopters as the core audience; they are just there to bootstrap and if you listen too much to them, the only audience your API will become suitable for is that small bootstrap group.”

Logging the detail of API usage can help identify the most common types of request, which can help direct optimisation strategies. When using external APIs it is best to design defensively: e.g. to cater for situations when the remote services are unavailable or the API fails.

Consider having a business model in place so that your API remains sustainable. As one developer commented:

“Understand the responsibility to users which comes with creating and promoting APIs: they should be stable, reliable, sustainable, responsive, capable of scaling, well-suited to the needs of the customer, well-documented, standards-based and backwards compatible.”

Acknowledgments

This document is based on advice provided by UKOLN’s Good APIs project. Further information is available at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

About The Best Practices For APIs Documents

The Best Practices For APIs series of briefing documents have been published for the cultural heritage sector.

The advice provided in the documents is based on resources gathered by UKOLN for the JISC-funded Good APIs project.

Further information on the Good APIs project is available from the project’s blog at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

This document is the first in a series of four briefing documents which provide advice on the planning processes for the creation of APIs.

The Importance of Planning

As with other activities, design of APIs projects requires effective planning. Rather than just adding an API to an existing service/software and moving straight into coding developers should consider planning, resourcing and managing the creation, release and use of APIs. They need to check that there isn’t already a similar API available before gathering data or developing something new. Then spend time defining requirements and making sure they consider the functionality they want the user to access.

Although formal planning may not always be appropriate in some ‘quick and dirty’ projects some form of prototyping can be very helpful. Some areas that might need consideration are scale, weighing up efficiency and granularity.

Authors who change their specification or don’t produce an accurate specification in the first place may find themselves in trouble later on in a project.

Gathering Requirements

Talking to your users and asking what they would like is just as important in API creation as user interface creation. At times it may be necessary to second-guess requirements but if you have the time it is always more efficient to engage with potential users. Technical people need to ask the user what they are actually after. You could survey a group of developers or ask members of your team.

“The development of a good set of APIs is very much a chicken-and-egg situation – without a good body of users, it is very hard to guess at the perfect APIs for them, and without a good set of APIs, you cannot gather a set of users. The only way out is to understand that the API development cannot be milestoned and laid-out in a precise manner; the development must be powered by an agile fast iterative method and test/response basis. You will have to bribe a small set of users to start with, generally bribe them with the potential access to a body of information they could not get hold of before. Don’t fall into the trap of considering these early adopters as the core audience; they are just there to bootstrap and if you listen too much to them, the only audience your API will become suitable for is that small bootstrap group.”

Make The APIs Useful

When creating an API look at it both from your own perspective and from a user’s perspective, offer something that can add value or be used in many different ways. One option is to consider developing a more generic application from the start as it will open up the possibilities for future work. Anticipate common requests and optimise your API accordingly. Open up the functions you’re building.

Get feedback from others on how useful it is. Consider different requirements of immediate users and circumstances against archival and preservation requirements.

Collaborating on any bridges and components is a good way to help developers tap into other team knowledge and feedback.

Keep It Simple

The adage “complex things tend to break and simple things tend to work” has been fairly readily applied to the creation of Web APIs. Although simplicity is not always the appropriate remedy, for most applications it is the preferred approach. APIs should be about the exposed data rather than application design.

Keep the specifications simple, especially when you are starting out. Documenting what you plan to do will also help you avoid scope creep. Avoid having too many fields and too many method calls. Offer simplicity, or options with simple or complex levels.

Developers should consider only adding API features if there is a provable extension use case. One approach might be to always ask “do we actually need to expose this via our API?“.

Make It Modular

It is better to create an API that has one function and does it well rather than an API that does many things. Good programming is inherently modular. This allows for easier reuse and sustains a better infrastructure.

The service should define itself and all methods available. This means as you add new features to the API, client libraries can automatically provide interfaces to those methods without needing new code.

As one developer commented:

“It is not enough to put a thin layer on top of a database and provide a way to get data from each table separately. Many common pieces of information can only be retrieved in a useful way by relating data between tables. A decent API would seek to make retrieving commonly-related sets of data easy.”

Acknowledgments

This document is based on advice provided by UKOLN’s Good APIs project. Further information is available at <http://blogs.ukoln.ac.uk/good-apis-jisc/>.

This briefing document provides advice for Web authors, developers and policy makers who are considering making use of Web 2.0 services which are hosted by external third party services. The document describes an approach to risk assessment and risk management which can allow the benefits of such services to be exploited, whilst minimising the risks and dangers of using such services.

Note that other examples of advice are also available [1] [2].

About Web 2.0 Services

This document covers use of third party Web services which can be used to provide additional functionality or services without requiring software to be installed locally. Such services include:

• Search facilities, such as Google University Search and Atomz.
• Social bookmarking services, such as del.icio.us.
• Wiki services, such as WetPaint.
• Usage analysis services, such Google Analytics and SiteMeter.
• Chat services such as Gabbly and ToxBox.

Advantages and Disadvantages

Advantages of using such services include:

• May not require scarce technical effort.
• Facilitates experimentation and testing.
• Enables a diversity of approaches to be taken.

Possible disadvantages of using such services include:

• Potential security and legal concerns e.g. copyright, data protection, etc.
• Potential for data loss or misuse.
• Reliance on third parties with whom there may be no contractual agreements.

Risk Management and Web 2.0

Examples of risks and risk management approaches are given below.

Note that in addition to risk assessment of Web 2.0 services, there is also a need to assess the risks of failing to provide such services.

Example of a Risk Management Approach

A risk management approach [3] was taken to use of various Web 2.0 services on the Institutional Web Management Workshop 2009 Web site.

Use of established services:

Google and Google Analytics are used to provide searching and usage reports.

Alternatives available:

Web server log files can still be analysed if the hosted usage analysis services become unavailable.

Management of services:

Interfaces to various services were managed to allow them to be easily changed or withdrawn.

User Engagement:

Users are warned of possible dangers and invited to engage in a pilot study.

Learning:

Learning may be regarded as the aim, not provision of long term service.

<!–

Agreements:

An agreement has been made for the hosting of a Chatbot service.

–>

References

1. Checklist for assessing third-party IT services, University of Oxford,
   <http://www.oucs.ox.ac.uk/internal/3rdparty/checklist.xml>
2. Guidelines for Using External Services, University of Edinburgh,
   <https://www.wiki.ed.ac.uk/download/attachments/8716376/GuidelinesForUsingExternalWeb2.0Services-20080801.pdf?version=1>
3. Risk Assessment, IWMW 2006, UKOLN,
   <http://iwmw.ukoln.ac.uk/iwmw2009/risk-assessment/>

Performance and reliability are the principal criteria for selecting software. In most procurement exercises however, price is also a determining factor when comparing quotes from multiple vendors. Price comparisons do have a role, but usually not in terms of a simple comparison of purchase prices. Rather, price tends to arise when comparing “total cost of ownership” (TCO), which includes both the purchase price and ongoing costs for support (and licence renewal) over the real life span of the product. This document provides tips about selecting open source software.

The Top Tips

Consider The Reputation

Does the software have a good reputation for performance and reliability? Here, word of mouth reports from people whose opinion you trust is often key. Some open source software has a very good reputation in the industry, e.g. Apache Web server, GNU Compiler Collection (GCC), Linux, Samba, etc. You should be comparing “best of breed” open source software against its proprietary peers. Discussing your plans with someone with experience using open source software and an awareness of the packages you are proposing to use is vital.

Monitor Ongoing Effort

Is there clear evidence of ongoing effort to develop the open source software you are considering? Has there been recent work to fix bugs and meet user needs? Active projects usually have regularly updated web pages and busy development email lists. They usually encourage the participation of those who use the software in its further development. If everything is quiet on the development front, it might be that work has been suspended or even stopped.

Look At Support For Standards And Interoperability

Choose software which implements open standards. Interoperability with other software is an important way of getting more from your investment. Good software does not reinvent the wheel, or force you to learn new languages or complex data formats.

Is There Support From The User Community?

Does the project have an active support community ready to answer your questions concerning deployment? Look at the project’s mailing list archive, if available. If you post a message to the list and receive a reasonably prompt and helpful reply, this may be a sign that there is an active community of users out there ready to help. Good practice suggests that if you wish to avail yourself of such support, you should also be willing to provide support for other members of the community when you are able.

Is Commercial Support Available?

Third party commercial support is available from a diversity of companies, ranging from large corporations such as IBM and Sun Microsystems, to specialist open source organizations such as Red Hat and MySQL, to local firms and independent contractors. Commercial support is most commonly available for more widely used products or from specialist companies who will support any product within their particular specialism.

Check Versions

When was the last stable version of the software released? Virtually no software, proprietary or open source, is completely bug free. If there is an active development community, newly discovered bugs will be fixed and patches to the software or a new version will be released. For enterprise use, you need the most recent stable release of the software, be aware that there may have been many more recent releases in the unstable branch of development. There is, of course, always the option of fixing bugs yourself, since the source code of the software will be available to you. But that rather depends on your (or your team’s) skill set and time commitments.

Think Carefully About Version 1.0

Open source projects usually follow the “release early and often” motto. While in development they may have very low version numbers. Typically a product needs to reach its 1.0 release prior to being considered for enterprise use. (This is not to say that many pre-”1.0″ versions of software are not very good indeed, e.g. Mozilla’s 0.8 release of its Firefox browser).

Check The Documentation

Open source software projects may lag behind in their documentation for end users, but they are typically very good with their development documentation. You should be able to trace a clear history of bug fixes, feature changes, etc. This may provide the best insight into whether the product, at its current point in development, is fit for your purposes.

Do You Have The Required Skill Set?

Consider the skill set of yourself and your colleagues. Do you have the appropriate skills to deploy and maintain this software? If not, what training plan will you put in place to match your skills to the task? Remember, this is not simply true for open source software, but also for proprietary software. These training costs should be included when comparing TCOs for different products.

What Licence Is Available?

Arguably, open source software is as much about the license as it is about the development methodology. Read the licence. Well-known licenses such as the General Public License (GPL) and the Lesser General Public License (LGPL) have well defined conditions for your contribution of code to the ongoing development of the software or the incorporation of the code into other packages. If you are not familiar with these licenses or with the one used by the software you are considering, take the time to clarify conditions of use.

What Functionality Does The Software Provide?

Many open source products are generalist and must be specialised before use. Generally speaking the more effort required to specialise a product, the greater is its generality. A more narrowly focused product will reduce the effort require to deploy it, but may lack flexibility. An example of the former is GNU Compiler Collection (GCC), and an example of the latter might be Evolution email client, which works well “out of the box” but is only suitable for the narrow range of tasks for which it was intended.

Further Information

• The Open Source Software Definition,
  <http://www.opensource.org/docs/definition.php> which sets out the distribution terms for software to count as open source.
• The Free Software Definition,
  <http://www.gnu.org/philosophy/free-sw.html> which clarifies the sense of “free” that relates to the freedom to run, distribute and change the software.
• The Cathedral and the Bazaar,
  <http://www.catb.org/~esr/writings/cathedral-bazaar/> the classic text on open source development methodologies.
• Open Sources: Voices from the Open Source Revolution
  <http://www.oreilly.com/catalog/opensources/book/toc.html> with essays from many of the important figures in the free software and open source movements.
• SourceForge.net,
  <http://sourceforge.net/> which is a repository of thousands of open source projects.

Acknowledgements

This document was written by Randy Metcalfe of OSS Watch. OSS Watch is the open source software advisory service for UK higher and further education. It provides neutral and authoritative guidance on free and open source software, and about related open standards.

The OSS Watch Web site ia available at http://www.oss-watch.ac.uk/.

A Risks and Opportunities Framework for exploiting the potential of innovation such as the Social Web has been developed by UKOLN [1]. This approach has been summarised in a briefing document [2] [2]. This briefing document provides further information on the processes which can be used to implement the framework.

The Risks and Opportunities Frame

The Risks and Opportunities Framework aims to facilitate discussions and decision-making when use of innovative services is being considered.

As illustrated, a number of factors should be addressed in the planning processes for the use of innovative new services, such as use of the Social Web. Further information on these areas is given in [2].

Critical Friends

A ‘Critical Friends’ approach to addressing potential problems and concerns in the development of innovative services is being used to JISC to support its funding calls. As described on the Critical Friends Web site [3]:

The Critical Friend is a powerful idea, perhaps because it contains an inherent tension. Friends bring a high degree of unconditional positive regard. Critics are, at first sight at least, conditional, negative and intolerant of failure.

Perhaps the critical friend comes closest to what might be regarded as ‘true friendship’ – a successful marrying of unconditional support and unconditional critique.

The Critical Friends Web site provides a set of Effective Practice Guidelines [4] for Critical Friends, Programme Sponsors and Project Teams.

A successful Critical Friends approach will ensure that concerns are raised and addressed in an open, neutral and non-confrontational way.

Risk Management and Minimisation

It is important to acknowledge that there may be risks associated with the deployment of new services and to understand what those risks might be. As well as assessing the likelihood of the risks occurring and the significance of such risks there will be a need to identify ways in which such risks can be managed and minimised.

It should b noted that risk management approaches might include education, training and staff development as well technical development. It should also be recognised that if may be felt that risks are sometimes worth taking.

Gathering Evidence

The decision-making process can be helped if it is informed by evidence. Use of the Risks and Opportunities Framework is based on documentation of intended uses of the new service, perceived risks and benefits, costs and resource implications and approaches for risk minimisation. Where possible the information provided in the documentation should be linked to accompanying evidence.

In a rapidly changing technical environment with changing user needs and expectations there will be a need to periodically revisit evidence in order to ensure that significant changes have not taken place which may influence decisions which have been made.

Using The Framework

A template for use of the framework is summarised below:

References

1. Time To Stop Doing and Start Thinking: A Framework For Exploiting Web 2.0 Services, Kelly, B., Museums and the Web 2009: Proceedings,
   <http://www.ukoln.ac.uk/web-focus/papers/mw-2009/>
2. A Risks and Opportunities Framework for the Social Web, UKOLN Cultural Heritage briefing document no. 67,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-67/>
3. Critical Friends Network,
   <http://www.critical-friends.org/>
4. Guidelines for Effective Practice, Critical Friends Network,
   <http://www.critical-friends.org/daedalus/cfpublic.nsf/guidelines?openform>

If you have made the decision to create a mobile Web site [1] there are a number of best practice techniques to bear in mind.

URLs

Best practices for URLs for Web sites include:

• Choose a short, easily remembered URL (e.g. xxx.ac.uk/mobile, m.xxx.ac.uk, or xxx.mobi).
• Stick with established conventions.

Navigation

Best practices for navigational design for mobile Web sites include:

• Remember that users are struggling with a variety of “difficult” input devices (stylus, finger touch, control pad, keyboard or joystick) so keep navigation simple.
• Sort navigation elements by popularity – most popular at the top.
• Allow users to see all navigation at once.
• Stick to a maximum of 10 links on any page.
• Code each link as an ‘access key’ numbered 0-9; use 0 for home. This allows users to navigate your links using their phone’s numeric keypad ensuring compatibility with older devices.
• Let people find things with as few clicks as possible – limit your navigation to a max drill-down of 5 levels (users get disorientated by more).
• Use well-labelled navigation categories.
• Provide escape links from every page, either to the next section, to the parent section, to the home page, or all of the above. Note: Breadcrumbing your navigation can be very effective.
• Remember your users don’t have a mouse, so :hover and onClick aren’t helpful.

Markup

Best practices for markup for mobile Web sites include:

• Code in well formed, valid XHMTL-MP (Mobile Profile) See W3C [2].
• Validate all pages. Bad mark-up can easily crash a mobile device, or simply cause nothing to render at all.
• Keep the pages below 30k where possible, so they load reasonably quickly. Bloated pages hurt users.
• Avoid tables, reliance on plug-ins (e.g. Flash), pop-ups, client side redirects and auto-refreshes (which may incur extra download times and data charges).
• Separate content and presentation with CSS. External, inline and embedded CSS are acceptable.
• Avoid @import to reference external CSS files.
• Phone numbers should be selectable links.
• Avoid floats for layout.

Images

Best practices for use of images on mobile Web sites include:

• Aim to keep logos and images small so that they fit within the recommended screen size limitation: 200 pixels wide x 250 pixels height. (Images wider than the screen size limitation should only be used if there is no better way to represent the information).
• When sizing your image to fit the screen resolution, don’t forget about the browser furniture which is going to take up some screen real estate, the scrollbar etc., so your image needs to be slightly smaller.
• Go for bold, high contrast, reduced colour palette images (subtle hues and shading will be lost on the more basic mobiles).
• Use ALT attributes for images as some users may not be able to see images on the Web site (or may choose to disable display of images).

Content

Best practices for the content on mobile Web sites include:

• Make it useful – think about your audience and what they really need, especially when they’re on the go.
• Mobile users have a shorter attention span – provide content in small, snack-sized pieces.
• Provide one content item per page.
• Keep text to the very minimum on each page.
• Use short, direct sentences.
• Minimise scrolling.
• Have a meaningful but short title bar.
• Have your institution’s phone number in the footer of every page.
• Don’t expect people to fill out long forms.
• Lots of video, animation or large image files slow down your site – if you must have them, keep them to a minimum.
• Remember the user’s details. Remembering preferences and behaviour helps you speed up their access to information. Pre-completed forms and “customise my home page” settings are even more critical to mobile than PC sites.
• Label your form fields.
• Use heading styles H1, H2, H3, H4.
• Use minimally sized margins and padding (remember your screen real estate is already small).

Design

Best design practices for mobile Web sites include:

• Switch your thinking to portrait mode where the page is taller than it is wide
• Design to the limitations of the expected screen sizes – 200 pixels wide x 250 pixels height
• Use colour banding for navigation categories, to give a sense of where you are.

‘Sniffing’

It is possible to set up a service to divert all you mobile devices automatically from your desktop site to your mobile site. This process is called ‘sniffing’. You can also sniff to know what mobile handset your user has and display a site optimised to maximum of their capabilities. Both approaches are not recommended.

Testing

Test your site on as many emulators [2] as possible and as many phones as possible. Ask your community to help you test. Make sure your desktop site contains a link to your mobile site and vice versa. The recommended link wordings are: ‘Mobile Site’ and ‘Full Site’. You also need to make sure your mobile site is picked up by all the main search engines (e.g. send Google a mobile sitemap.)

Conclusions

When designing for the mobile Web recognize its limitations (small screen, no mouse) but also think about its extra capabilities (phone, camera, GPS, SMS, MMS, Bluetooth, QR reader, MP3 player etc). Too many mobile websites needlessly limit functionality, offering a bare bones experience that leaves the user wanting more. Mobile devices can do many things – use them in new ways to add real value.

Acknowledgements

This document was written by Sharon Steeples, University of Essex who ran a workshop on this topic at the IWMW 2009 event (see her accompanying handout at [3]). We are grateful to Sharon for permission to republish this document under a Creative Commons licence.

References

1. An Introduction to the Mobile Web, Cultural Heritage briefing paper no. 62, UKOLN,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-62/>
2. Mobile Web best practices (flip cards), W3C,
   <http://www.w3.org/2007/02/mwbp_flip_cards.html>
3. The Mobile Web: keep up if you can! Useful links including emulators, Slideshare,
   <http://www.slideshare.net/mobilewebslides/supporting-handout-the-mobile-web-keep-up-if-you-can>

Access to Web services used to be only through desk top computers. Improvement of laptop, personal digital assistant (PDA) and mobile phone technologies, alongside expansion of mobile networks, has meant that this is no longer the case. The number of mobile Web users is growing rapidly, now over half the globe pays to use one [1], and any organisation with a Web site will need to give consideration to mobile devices.

Challenges in Exploiting the Mobile Web

For most browsing the Internet using a mobile device is currently not an enjoyable experience [2]. The main challenges relate to interoperability and usability, and stem from the following issues:

• Web technologies may be incompatible with mobile devices – JavaScript, cookies etc. may not work
• There are serious device limitations – smaller screens, difficult to use keyboards, limited battery life etc.
• Mobile network connection can be very slow and intermittent.

At present mobile data connectivity can be costly but this is likely to change. Whatever the challenges, users will increasingly want to access Web sites while on the move.

Opportunities Provided by the Mobile Web

Gaddo F Benedetti, Mobile Web expert, states that “what sells the mobile Web is not how it is similar to the desktop Web, but how it differs” [3]. A mobile device is transportable, personal, always on, prolific and these days often location aware. Such factors offer many opportunities for institutions and organisations who wish to allow their resources to be used in exciting new ways.

Mobile Web Sites

If you are a Web site provider there are a number of options available to you. You could chose to do nothing or merely reduce your images and styling to help with mobile viewing. There are a number of third party sites that will help with this.

Alternately you can create handheld style sheets using CSS or create mobile optimised content using XHTML or WML (wireless markup language) to deliver content. New browsers are moving towards using modifications of HTML. Each approach has its pros and cons which will need consideration.

The Mobi Approach

In July 2005 a number of big companies (Google, Microsoft, Nokia, Samsung, and Vodafone) sponsored the creation of the .mobi top-level domain dedicated to delivering the Internet to mobile devices. Mobi has received criticism because it goes against the principle of device independence.

W3C Mobile Web Initiative

The W3C Mobile Web Initiative [4] is a initiative set up by the W3C to develop best practices and technologies relevant to the Mobile Web. They offer a helpful set of mobile Web best practices and Mobile Web Checker tools. One project WC3 have been involved in is the development of a validation scheme: the Mobile OK scheme.

Creating Mobile Web Sites

If you are creating a mobile Internet site you will need to give some consideration of what information and services your stakeholders will want to consume while on the move, for example opening hours, directions, staff information etc. Currently there are very few dedicated UK cultural heritage mobile sites, however in the US there are more and a number of examples are listed on the Tame the Web blog [5].

References

1. Nice talking to you … mobile phone use passes milestone, Guardian, 3 Mar 2009,
   <http://www.guardian.co.uk/technology/2009/mar/03/mobile-phones1>
2. Mobile Usability, Jakob Nielsen’s Alertbox,
   <http://www.useit.com/alertbox/mobile-usability.html>
3. Mobile First, Web Second, Mobi Forge blog,
   <http://mobiforge.com/analysts/blog/mobile-first-web-second>
4. Mobile Web Initiative, W3C,
   <http://www.w3.org/Mobile/>
5. Mobile Versions of Library Web sites, Tame the Web,
   <http://tametheweb.com/2008/06/18/mobile-versions-of-library-web-sites/comment-page-1/>

The use of open standards can help provide interoperability and maximise access to online services. However this raises two questions: “Why open standards?” and “What are open standards?”.

Why Open Standards?

Open standards can be useful for a number of reasons:

• Application Independence: To ensure that access to resources is not dependent on a single application.
• Platform Independence: To ensure that access to resources is not restricted to particular hardware platforms.
• Long-term Access: To ensure that quality scholarly resources can be preserved and accessed over a long time frame.
• Accessibility: To ensure that resources can be accessed by people regardless of disabilities.
• Architectural Integrity: To ensure that the architectural framework for the Information Environment is robust and can be developed in the future.

What Are Open Standards?

The term “open standards” is somewhat ambiguous and open to different interpretations. Open standards can mean:

• An open standards-making process.
• Documentation freely available on the Web.
• Use of the standard is uninhibited by licencing or patenting issues.
• Standard ratified by recognised standards body.
• Standards for which there are multiple providers of authoring and viewing tools.

Some examples of recognised open standards bodies are given in Table 1.

Other Types Of Standards

The term proprietary refers to formats which are owned by an organisation, group, etc. Unfortunately since this term has negative connotations, the term industry standard is often used to refer to a widely used proprietary standard e.g., the Microsoft Excel format may be described as an industry standard for spreadsheets.

To further confuse matters, companies which own proprietary formats may choose to make the specification freely available. Alternatively third parties may reverse engineer the specification and publish the specification. In addition tools which can view or create proprietary formats may be available on multiple platforms or as open source.

In these cases, although there may be no obvious barriers to use of the proprietary format, such formats should not be classed as open standards as they have not been approved by a neutral standards body. The organisation owning the format may chose to change the format or the usage conditions at any time.

It should also be noted that proprietary formats may sometimes be standardised by an open standards organisation. This happened during 2009 with the Microsoft Office and Adobe’s PDF formats.

As described in [1] Twitter is a micro-blogging service which allows users to send brief posts (known as ‘tweets‘) up to 140 characters long. The tweets are displayed on the users profile page or in a Twitter client by users who have chosen to ‘follow’ the user.

What are Hashtags?

Hashtags [2] are a community-driven convention for adding additional context to your tweets. They are a form of metadata and very similar to tags, as used on social networking sites and blogs. Hashtags are added inline to a post by prefixing a word with a hash symbol: #hashtag. Implementing a hashtag for an event is becoming increasingly popular and allows anyone to comment on event (before, during and after). Users can see all tweets collated through use of a hashtag in a number of ways:

• Using the hashtags site e.g. http://hashtags.org/tag/iwmw2009/
• Running a Twitter search for a term and then following that RSS feed.
• Using a relevant application such as Twemes [3] or Twitterfall [4].

Twitter Use at Events

Twitter can be used at events by:

Organisers

By creating a Twitter account an event organisers can offer updates and alert followers to important occurrences in a similar way to an RSS feed. Prior to an event this may take the form of general publicity material. During an event it could be used to alert delegates to problems, for example if a session is cancelled (followers can sign up to have messages delivered directly to their phone). After an event it could be used to alert followers to where resources are held. Organisers of annual events may find it useful to create a generic Twitter account, not a yearly one, which can be used for forthcoming events.

Delegates

Those interested in an event can sign up for the event Twitter account to receive relevant information. They can also tweet during the event using the hashtag. This can be a particularly engaging activity if it takes place during presentations and sessions. Discussion about the content of an event (and related) has become known as the Twitter ‘back channel‘.

Speakers

By following a Twitter hashtag a presenter could potentially get a better understanding of an audience’s knowledge and the event mood. During a presentation a presenter could answer questions on the fly, use Twitter as a way to ‘ask the crowd’ and as a feedback mechanism.

Benefits

A Twitter back channel has the potential to be embraced by the event organisers and the conference participants alike. It can allow deeper interaction and engagement with content better audience participation. Twitter users tend to get to know each other better so it can enable the establishment of a community alongside more traditional networking activities. Use of Twitter also means that those not physically present can still participate by asking questions and getting a good feeling for the event atmosphere.

Challenges

As Twitter use at events has yet to become mainstream and many will not have appropriate networked devices Twitter may cause a divide in the audience between those using Twitter and those not. Some have argued that event organiser’s involvement should be discouraged and that the back channel should ‘stay a back channel’ and not be brought to the forefront. As with any networked technology some may see its use as disruptive and inappropriate.

Use of a live display (sometime referred to as a ‘Twitterwall’) which provides a live feed of tweets tagged for the event may have dangers. It can allow inappropriate content to surface and may need to be managed. Some events may choose to moderate a back channel display.

Conclusions

As an organiser it can be very exciting to see your event peaking (if your event hashtag is being highly used at that time) and see Twitter well used at your event. However it pays to remember that Twitter is first and foremost a communications mechanism and that the content of Tweets is more valuable than their quantity. Twitter can be an exciting way for you to allow your community to better connect with an event, by listening to what they say and treading carefully you can ensure that everyone benefits.

References

1. An Introduction To Twitter, Cultural heritage briefing page no. 36, UKOLN, <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-36/>
2. Hashtags, <http://hashtags.org/>
3. Twemes, <http://twemes.com/>
4. Twitterfall, <http://www.twitterfall.com/>

Increasingly WiFi networks are available in lecture theatres, conference venues, etc. We are beginning to see various ways in which networked applications are being used to enhance conferences, workshops and lectures [1].

However there is a need to address issues such as being clear of potential uses, being aware of user requirement and the logistics of providing and supporting use of networked applications.

Availability Of The Network

If you are considering making use of a WiFi network to support an event you will need to ensure that (a) a WiFi network is available; (b) costs, if any, for use of the network and (c) limitations, if any, on use of the network. Note that even if a WiFi network is available, usage may restricted (e.g. to academic users; local users; etc.).

Using Mobile Telephony Networks

You should remember that increasing numbers of users will be able to make use of mobile phone networks at events. This might include users of iPhones and similar smart phones as well as laptop users with 3G data cards.

Demand From The Participants

There may be a danger in being driven by the technology (just because a WiFi network is available does not necessarily mean that the participants will want to make use of it). Different groups may have differing views on the benefits of such technologies (e.g. IT-focussed events or international events attracting participants from North America may be particularly interested in making use of WiFi networks).

If significant demand for use of the WiFi network is expected you may need to discuss this with local network support staff to ensure that (a) the network has sufficient bandwidth to cope with the expected traffic and (b) other networked services have sufficient capacity (e.g. servers handling logins to the network).

Financial And Administrative Issues

If there is a charge for use of the network you will have to decide how this should be paid for? You may choose to let the participants pay for it individually. Alternatively the event organisers may chose to cover the costs.

You will also have to set up a system for managing usernames and passwords for accessing the WiFi network. You may allocate usernames and passwords as participants register or they may have to sign a form before receiving such details.

Support Issues

There will be a need to address the support requirements to ensure that effective use is made of the technologies.

Participants

There may be a need to provide training and to ensure participants are aware of how the networked technologies are being used.

Event Organisers, Speakers, etc.

Event organisers, chairs or sessions, speakers, etc should also be informed of how the networked technologies may be used and may wish to give comments on whether this is appropriate.

AUP

An Acceptable Use Policy (AUP) should be provided which addresses issues such as privacy, copyright, distraction, policies imposed by others, etc.

Evaluation

It would be advisable to evaluate use of technologies in order to inform planning for future events.

Acceptable Use Policies

There may be a need to develop an publicise an Acceptable Use Policy (AUP) covering use of networked technologies at events. As an example see [2].

Physical And Security Issues

You will need to address various issues related to the venue and the security of computers. You may need to provide advice on where laptop users should sit (often near a power supply and possibly away from people who do not wish to be distracted by noise). There will also be issues regarding the physical security of computers and the security against viruses, network attacks, etc.

References

1. Using Networked Technologies To Support Conferences, Kelly, B. et al, EUNIS, <http://www.ukoln.ac.uk/web-focus/papers/eunis-2005/paper-1/>
2. AUP, IWMW 2007, UKOLN, <http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2007/aup/>

Archiving is a confusing term and can mean the backup of digital resources and/or the long-term preservation of those records. This document talks about the physical archiving of your Web site as the last in a series of steps after selection and appraisal of Web resources has taken place. This will be part of a ‘preservation policy’.

Approaches

Before archiving it is important to consider approaches to preserving your Web site:

What to do now

This includes quick-win solutions, actions that can be performed now to get results, or to rescue and protect resources that you have identified as being most at risk. Actions include domain harvesting, remote harvesting, use of the EDRMS, use of the Institutional Repository, and ’2.0 harvesting’. These actions may be attractive because they are quick, and some of them can be performed without involving other people or requiring changes in working. However, they may become expensive to sustain if they do not evolve into strategy.

Strategic approaches

This class includes longer-term strategic solutions which take more time to implement, involve some degree of change, and affect more people in the Institution. These include approaches adapted from Lifecycle Management and Records Management and also approaches which involve working with external organisations to do the work (or some of it) for you. The pay-off may be delayed in some cases, but the more these solutions become embedded in the workflow, the more Web-archiving and preservation becomes a matter of course, rather than something which requires reactive responses or constant maintenance, both of which can be resource-hungry methods.

Domain Harvesting

Domain harvesting can be carried out in two ways: 1) Your Institution conducts its own domain harvest, sweeping the entire domain (or domains) using appropriate Web-crawling tools. 2) Your Institution works in partnership with an external agency to do domain harvesting on its behalf. Domain harvesting is only ever a partial solution to the preservation of Web content. Firstly, there are limitations to the systems which currently exist. You may gather too much, including pages and content that you don’t need to preserve. Conversely, you may miss out things which ought to be collected such as: hidden links, secure and encrypted pages, external domains, database-driven content, and databases. Secondly, simply harvesting the material and storing a copy of it may not address all the issues associated with preservation.

Migration

Migration of resources is a form of preservation. Migration is moving resources from one operating system to another, or from one storage system to another. This may raise questions about emulation and performance. Can the resource be successfully extracted from its old system, and behave in an acceptable way in the new system?

Getting Other People to Do it for You

There are a number of third party Web harvesting services which may have a role to play in harvesting your Web site:

UKWAC

The UK Web-Archiving Consortium [1] has been gathering and curating Web sites since 2004. To date, UKWAC’s approach has been very selective, and determined by written selection policies which are in some ways quite narrow, it currently only covers UK HE/FE. However it is now possible to nominate your Institutional Web site for capture with UKWAC.

The Internet Archive

The Internet Archive [2] is unique in that it has been gathering pages from Web sites since 1996. It holds a lot of Web material that cannot be retrieved or found anywhere else. There are a number of issues to consider when using the Internet Archive. To date it lacks any sort of explicit preservation principle or policy and may not have a sustainable business model and so its use cannot guarantee the preservation of your resources. There are also issues with the technical limitations of the Wayback Machine e.g. gaps between capture dates, broken links, database problems, failure to capture some images, no guarantee to capture to a reliable depth or quality. The National Archives use a model where they contract out collection to the Internet Archive, but also maintain the content themselves.

HANZO

Hanzo Archives is a commercial Web-archiving company [3]. They claim to be able to help institutions archive their Web sites and other Web-based resources. They offer a software as a service solution for Web archiving. It’s possible for ownership to be shared at multiple levels; for instance, one can depend on a national infrastructure or service to do the actual preserving, but still place responsibility on the creator or the institution to make use of that national service.

References

1. UKWAC, <http://www.webarchive.org.uk/>
2. The Internet Archive, <http://www.archive.org/>
3. HANZO, <http://www.hanzoarchives.com/>

This document provides some approaches to selection for preservation of Web resources.

Background

Deciding on a managed set of requirements is absolutely crucial to successful Web preservation. It is possible that, faced with the enormity of the task, many organisations decide that any sort of capture and preservation action is impossible and it is safer to do nothing.

It is worth remembering, however, that a preservation strategy won’t necessarily mean preserving every single version of every single resource and may not always mean “keeping forever”, as permanent preservation is not the only viable option. Your preservation actions don’t have to result in a “perfect” solution but once decided upon you must manage resources in order to preserve them. An unmanaged resource is difficult, if not impossible, to preserve.

The task can be made more manageable by careful appraisal of the Web resources, a process that will result in selection of certain resources for inclusion in the scope of the programme. Appraisal decisions will be informed by understanding the usage currently made of organisational Web sites and other Web-based services and the nature of the digital content which appears on these services.

Considerations

Some questions that will need consideration include:

• Should the entire Web site be archived or just selected pages from the Web site?
• Could inclusion be managed on a departmental basis, prioritising some departmental pages while excluding others?

You will also be looking for unique, valuable and unprotected resources, such as:

• Resources which only exist in web-based format.
• Resources which do not exist anywhere else but on the Web site.
• Resources whose ownership or responsibility is unclear, or lacking altogether.
• Resources that constitute records, according to definitions supplied by the records manager.
• Resources that have potential archival value, according to definitions supplied by the archivists.

Resources to be Preserved

(1) RECORD

A traditional description of a ‘record’ is:

“Recorded information, in any form, created or received and maintained by an organisation or person in the transaction of business or conduct of affairs and kept as evidence of such activity.”

A Web resource is a record if it:

• Constitutes evidence of business activity that you need to refer to again.
• Is evidence of a transaction.
• Is needed to be kept for legal reasons.

(2) PUBLICATION

A traditional description of a publication is:

“A work is deemed to have been published if reproductions of the work or edition have been made available (whether by sale or otherwise) to the public.”

A Web resource is a publication if it is:

• A Web page that’s exposed to the public on the Web site.
• An attachment to a Web page (e.g. a PDF or MS Word Document) that’s exposed on the Web site.
• A copy of a digital resource, e.g. a report or dissertation, that has already been published by other means.

(3) ARTEFACT

A Web resource is an artefact if it:

• Has intrinsic value to the organisation for historical or heritage purposes.
• Is an example of a significant milestone in the organisation’s technical progress, for example the first instance of using a particular type of software.

Resources to be Excluded

There are some resources that can be excluded such as resources that are already being managed elsewhere e.g. asset collections, databases, electronic journals, repositories, etc. You can also exclude duplicate copies and resources that have no value.

Selection Steps

Selection of Web resources for preservation requires two steps:

1. Devise a selection policy- defining a selection policy in line with your organisational preservation requirements. The policy could be placed within the context of high-level organisational policies, and aligned with any relevant or analogous existing policies.
2. Build a collection list.

Selection Approaches

Approaches to selection include:

Unselective approach

This involves collecting everything possible. This approach can create large amounts of unsorted and potentially useless data, and commit additional resources to its storage.

Thematic selection

A ‘semi-selective’ approach. Selection could be based on predetermined themes, so long as the themes are agreed as relevant and useful and will assist in the furtherance of preserving the correct resources.

Selective approach

This is the most narrowly-defined method which does tend to define implicit or explicit assumptions about the material that will not be selected and therefore not preserved. The JISC PoWR project recommend this approach [1].

Resource Questions

Questions about the resources which should be answered include:

• Is the resource needed by staff to perform a specific task?
• Has the resource been accessed in the last six months?
• Is the resource the only known copy, or the only way to access the content?
• Is the resource part of the organisation’s Web publication scheme?
• Can the resource be re-used or repurposed?
• Is the resource required for audit purposes?
• Are there legal reasons for keeping the resource?
• Does the resource represent a significant financial investment in terms of staff cost and time spent creating it?
• Does it have potential heritage or historical value?

An example selection policy is available from the National Library of Australia [2].

Decision Tree

Another potentially useful tool is the Decision Tree [3] produced by the Digital Preservation Coalition. It is intended to help you build a selection policy for digital resources, although we should point out that it was intended for use in a digital archive or repository. The Decision Tree may have some value for appraising Web resources if it is suitably adapted.

Aspects to be Captured

It is possible to make a distinction between preserving an experience and preserving the information which the experience makes available.

Information = content (which could be words, images, audio, …) Experience = the experience of accessing that content on the Web, which all its attendant behaviours and aspects

Making this decision should be driven by the question “Why would we want to preserve what’s on the Web?” When deciding upon the answer it might be useful to bear in mind drivers such as evidence and record-keeping, repurposing and reuse and social history.

References

1. JISC PoWR, <http://jiscpowr.jiscinvolve.org/>
2. Selection Guidelines for Archiving and Preservation by the National Library of Australia, National Library of Australia, <http://pandora.nla.gov.au/selectionguidelines.html>
3. Digital Preservation Coalition Decision Tree, Digital Preservation Coalition, <http://www.dpconline.org/graphics/handbook/dec-tree-select.html>

Institutions now create huge amounts of Web-based resources and the strategic importance of these is finally being recognised. Long-term stewardship of these resources by their owners is increasingly becoming a topic of interest and necessity.

What is Web ‘Preservation’?

Digital preservation is defined as a “series of managed activities necessary to ensure continued access to digital materials for as long as necessary” [1]. In the case of Web resources you may choose to go for:

• Protection: Protecting a resource from loss or damage, in the short term, is an acceptable form of “preservation”, even if you don’t intend to keep it for longer than, say, five years.
• Perpetual preservation It is best to think of this as long-term preservation where ‘long-term is defined as “long enough to be concerned with the impacts of changing technologies, including support for new media and data formats, or with a changing user community” [2].

Why Preserve?

There are a number of drivers for Web resource preservation:

• To protect your organisation: Web sites may contain evidence of organisational activity which is not recorded elsewhere and may be lost if the Web site is not archived or regular snapshots are not taken. There are legal requirements to comply with acts such as FOI and DPA.
• It could save you money: Web resources cost money to create, and to store; failing to repurpose and reuse them will be a waste of money.
• Responsibility to users: Organisations have a responsibility to the people who use their resource and to the people who may need to use their resources in the future. People may make serious choices based on Web site information and there is a responsibility to keep a record of the publication programme. Many resources are unique and deleting them may mean that invaluable scholarly, cultural and scientific resources (heritage records) will be unavailable to future generations.

Whose Responsibility is it?

There are a number of parties who may have an interest in the preservation of Web resources. These may include the producer of the resource (Individual level), the publisher of the resource, the organisation, the library (Organisational Level), the cultural heritage sector, libraries and archives, the government, consortiums (National Level) or international organisations, commercial companies (International level). Within organisations the Web team, records management team, archives and information managers will all need to work together.

What Resources?

The JISC Preservation of Web Resources (PoWR) project [3] recommends a selective approach (as oppose to full domain harvesting). This won’t necessarily mean preserving every single version of every single resource and may not always mean “keeping forever”, as permanent preservation is not the only viable option. Your preservation actions don’t have to result in a “perfect” solution but once decided upon you must manage resources in order to preserve them. An unmanaged resource is difficult, if not impossible, to preserve. Periodic snapshots of a Web site can also be useful and could sit alongside a managed solution.

How Do I Preserve Web Resources?

Web preservation needs to be policy-driven. It is about changing behaviour and consistently working to policies. As a start an organisation might go about creating a Web resource preservation strategy. Some of the following questions will be worth considering: What Web resources have you got? Where are they? Why have you got them? Who wants them? For how long? What protection policies do you have?

Ways of finding out the answers to these questions include a survey, research, asking your DNS manager. Once you have found your resources you need to appraise them and select which require preserving. The next step is to move copies of your resources into archival storage. Once this process is completed the resources will need to be managed in some way. For further information see the Web Archiving briefing paper [4].

References

1. Digital Preservation Coalition Definitions, Digital Preservation Coalition, <http://www.dpconline.org/graphics/intro/definitions.html>
2. Digital preservation, Wikipedia, <http://en.wikipedia.org/wiki/Digital_preservation#cite_note-1>
3. JISC PoWR blog site, <http://jiscpowr.jiscinvolve.org/>
4. Web Archiving, Cultural heritage briefing paper no. 53, UKOLN, <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-53/>

Cloud computing is an umbrella term used to refer to Internet based development and services. The cloud is a metaphor for the Internet. A number of characteristics define cloud data, applications services and infrastructure:

• Remotely hosted: Services or data are hosted on someone else’s infrastructure.
• Ubiquitous: Services or data are available from anywhere.
• Commodified: The result is a utility computing model similar to traditional that of traditional utilities, like gas and electricity. You pay for what you would like.

Software as a Service (SaaS)

SaaS is a model of software deployment where an application is hosted as a service provided to customers across the Internet. SaaS is generally used to refer to business software rather than consumer software, which falls under Web 2.0. By removing the need to install and run an application on a user’s own computer it is seen as a way for businesses to get the same benefits as commercial software with smaller cost outlay. Saas also alleviates the burden of software maintenance and support but users relinquish control over software versions and requirements. They other terms that are used in this sphere include Platform as a Service (PaaS) and Infrastructure as a Service (IaaS)

Cloud Storage

Several large Web companies (such as Amazon and Google) are now exploiting the fact that they have data storage capacity which can be hired out to others. This approach, known as ‘cloud storage’ allows data stored remotely to be temporarily cached on desktop computers, mobile phones or other Internet-linked devices. Amazon’s Elastic Compute Cloud (EC2) and Simple Storage Solution (S3) are well known examples.

Data Cloud

Cloud Services can also be used to hold structured data. There has been some discussion of this being a potentially useful notion possibly aligned with the Semantic Web [2], though concerns, such as this resulting in data becoming undifferentiated [3], have been raised.

Opportunities and Challenges

The use of the cloud provides a number of opportunities:

• It enables services to be used without any understanding of their infrastructure.
• Cloud computing works using economies of scale. It lowers the outlay expense for start up companies, as they would no longer need to buy their own software or servers. Cost would be by on-demand pricing. Vendors and Service providers claim costs by establishing an ongoing revenue stream.
• Data and services are stored remotely but accessible from ‘anywhere’.

In parallel there has been backlash against cloud computing:

• Use of cloud computing means dependence on others and that could possibly limit flexibility and innovation. The ‘others’ are likely become the bigger Internet companies like Google and IBM who may monopolise the market. Some argue that this use of supercomputers is a return to the time of mainframe computing that the PC was a reaction against.
• Security could prove to be a big issue. It is still unclear how safe outsourced data is and when using these services ownership of data is not always clear.
• There are also issues relating to policy and access. If your data is stored abroad whose FOI policy do you adhere to? What happens if the remote server goes down? How will you then access files? There have been cases of users being locked out of accounts and losing access to data.

The Future

Many of the activities loosely grouped together under cloud computing have already been happening and centralised computing activity is not a new phenomena: Grid Computing was the last research-led centralised approach. However there are concerns that the mainstream adoption of cloud computing could cause many problems for users. Whether these worries are grounded or not has yet to be seen.

References

1. Software as a service, Wikipedia, <http://en.wikipedia.org/wiki/Software_as_a_service>
2. Welcome to the Data Cloud, The Semantic Web blog, 6 Oct 2008, <http://blogs.zdnet.com/semantic-web/?p=205>
3. Any any any old data, Paul Walk’s blog, 7 Oct 2008, <http://blog.paulwalk.net/2008/10/07/any-any-any-old-data/>

API stands for ‘application programming interface’. An API is the interface that a computer system, computer library or application provides to allow requests for services to be made of it by other programs and/or to allow data to be exchanged between them. A Web API is the Web version of this interface [1]. It comprises of documented code and is effectively a way to plug one Web site or Web service into another.

Recently many Web sites have exposed APIs and made them available to external developers. The term Open API is often used to describe the technologies that allow this interaction.

What Can Web APIs be Used For?

Developers can use Web APIs to build tools for the host Web site and enrich their own applications with useful functions from third parties. This provides several advantages:

For the host site:

The advantage of exposing ones APIs is that developers will create new features and applications for free. These applications will then drive traffic to the site.

For the developer:

Creating applications allows developers to promote their own work on higher profile Web site and build on existing work. Their own Web site can then benefit from the traffic. Developers can also mix and match information data from different sources to creation a solution to a problem.

Getting Started

To access a Web API developers will normally need to register for a (often free) account and get a private key which is required for calling server functions. Each API has its own terms and conditions that will need to be followed, for example there may be limitations on the number of calls to the site per day.

Someone with programming experience could build an application using available APIs fairly quickly but there are now a number of good development tools available such as Yahoo Pipes [2] that allow those with little programming experience to begin developing simple Web applications.

Examples of Web APIs

Many commercial companies now expose their APIs including Facebook, Yahoo, Google, Google Maps, Flickr and YouTube.

There are a number of API directories including Programmable Web API directory [3], Webmashup [4] and the WebAPI Directory [5]. A list of useful APIs for library services on the TechEssense.info blog [6].

Opportunities and Challenges

Web APIs are likely to become increasingly important and more organisations will want to make their own APIs available as a way to raise their profile and add value. Amazon recently released graphs that show the growth in bandwidth being consumed by their customers via their various Web services. More activity network activity takes place in this way than through all their other Web sites combined. Uptake of data and software by third party Web applications through Machine to Machine (M2M) interfaces is becoming more important than user interfaces.

This move of focus means that more work will be done to make sure that APIs that deigned in an appropriate and compatible manner. There will also be significant challenges relating to how organisations use the data available, which may be personal and sensitive.

References

1. Wikipedia: API, Wikipedia, <http://en.wikipedia.org/wiki/Application_programming_interface>
2. Yahoo Pipes, Yahoo!, <http://pipes.yahoo.com/pipes/>
3. Programmable Web API directory, <http://www.programmableweb.com/apilist>
4. Webmashup, Webmashup.com, <http://www.webmashup.com/Mashup_APIs/>
5. WebAPI Directory, WebAPI.org, <http://www.webapi.org/webapi-directory/>
6. Services/APIs/Systems/Technology/Data that we could use, Mashed Library, Ning.com, <http://mashedlibrary.ning.com/forum/topic/show?id=2186716%3ATopic%3A9>

AJAX (Asynchronous JavaScript and XML) is “a group of interrelated Web development techniques used to create interactive web applications or rich Internet applications” [1]. Using AJAX it is possible to develop Web applications which have a rich user interface which can approach the usability of well-written desktop application.

The Origins of AJAX

The key technical components of AJAX are:

• XHTML – a stricter, cleaner rendering of HTML into XML.
• CSS for marking up and adding styles.
• The Javascript Document Object Model (DOM) which allows the content, structure and style of a document to be dynamically accessed and updated.
• ” The XMLHttpRequest object which exchanges data asynchronously with the Web server reducing the need to continually fetch resources from the server.

Since data can be sent and retrieved without requiring the user to reload an entire Web page, small amounts of data can be transferred as and when required. Moreover, page elements can be dynamically refreshed at any level of granularity to reflect this. An AJAX application performs in a similar way to local applications residing on a user’s machine, resulting in a user experience that may differ from traditional Web browsing.

Examples of AJAX usage include GMail and Flickr. It is largely due to these and other prominent sites that AJAX has become popular only relatively recently – the technology has been available for some time. One precursor was dynamic HTML (DHTML), which twinned HTML with CSS and JavaScript but suffered from cross-browser compatibility issues.

AJAX is not a technology, rather, the term refers to a proposed set of methods using a number of existing technologies. As yet, there is no firm AJAX standard, although the recent establishment of the Open AJAX Alliance [2], supported by major industry figures such as IBM and Google, suggests that one will become available soon.

Developing AJAX Applications

AJAX applications can benefit both the user and the developer. Web applications can respond much more quickly to many types of user interaction and avoid repeatedly sending unchanged information across the network. Also, because AJAX technologies are open, they are supported in all JavaScript-enabled browsers, regardless of operating system – however, implementation differences between browsers cause some issues, some using an ActiveX object, others providing a native implementation.

Although the techniques within AJAX are relatively mature, the overall approach is still fairly new and there has been criticism of the usability of its applications; further information on this subject is available in the AJAX And Usability Issues briefing document [2].

Advantages and Disadvantages of AJAX

As described in Wikipedia advantages provided by use of AJAX include:

• State can be maintained throughout a Web site.
• A Web application can request only the content that needs to be updated, thus drastically reducing bandwidth usage and load time.
• Users may perceive an AJAX-enabled application to be faster or more responsive.
• Use of Ajax can reduce connections to the server, since scripts and style sheets only have to be requested once.

The disadvantages include:

• Clicking the browser’s “back” button may not function as expected.
• Dynamic Web page updates make it difficult for a user to use bookmarks.
• Browser does not support JavaScript or have JavaScript disabled, will not be able to use its functionality.

References

1. AJAX (programming), Wikipedia,
   <http://en.wikipedia.org/wiki/Ajax_(programming)>
2. The Open AJAX Alliance,
   <http://www.openajax.org/overview.php>
3. AJAX And Usability Issues, Cultural Heritage briefing document no. 20, UKOLN,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-20/>

It is important that managers and governing bodies are fully aware of the implications of a digitisation project, especially the need to maintain resources beyond the project. Managers need to have sufficient knowledge to devise and implement relevant policies and procedures including a training plan.

Staff and Volunteers

Digitisation projects often require the recruitment of staff or volunteers. At the implementation stage these are some valuable skills including (a) awareness of general issues in digitisation; (b) practical digitisation skills and experience; (c) broader organisational skills; (d) methodical approach; (e) keyboard skills; (f) experience of databases, collections management systems, image management software; (g) ability to apply due care in handling museum objects and (h) discrimination in relevant areas e.g. visual (ability to distinguish colours), audio (awareness of background sounds).

Production may be in-house, through shared hardware and personnel, or using an external digitisation company.

Location

A separate photographic, audio or video studio is ideal. If museum objects are to be kept in the studio then security will need to be in line with that of stores. Control over movement of works of art should follow Spectrum standards.

Hardware

Hardware is a general term to describe the equipment needed for digitisation such as scanners, cameras (still and video), and audio and video recorders. The choice of equipment will be dictated by the scale and ambition of the project. The gap between consumer and professional equipment is becoming less well-defined.

Digitisation Strategy – Selecting Suitable Approaches

2D and 3D material may be captured in digital format through scanning or digital photography. The table below illustrates possible approaches.

Notes

• Resolution is that captured when scanned or photographed, lower resolutions may be used in publication.
• TIFF should used for capture (and/or archive), other formats such as PNG or JPEG may be used in publication.
• Black and white photographs may be in grey tones, and sometimes colours from chemical processes used, e.g. sepia prints, or from aging.
• Sizes will vary with the size in pixels and the content of the image.

Acknowledgements

This document has been produced from information contained within the Renaissance East Midlands Simple Guide to Digitisation that was researched and written by Julian Tomlin and is available from http://www.renaissanceeastmidlands.org.uk/. We are grateful for permission to republish this document under a Creative Commons licence. Anyone wishing to republish this document should include acknowledgements to Renaissance East Midlands and Julian Tomlin.

Depending on the scale of the project, certain project planning tools and approaches should be applied since digitisation is likely to be seen as a discrete project, rather than purely an operational process.

Perhaps the first and potentially most useful is to outline the scope of the project. This can be done using mind mapping software which allows you to explore different elements of the project through a web of ideas.

Long-Term Issues

It is important to consider the long-term aspects of any decisions:

• Would it be better to go broader and digitise more objects in a simpler manner, or deeper by digitising at the highest possible quality?
• Might this form part of a strategy to digitise further sections of the collection?
• Are further resources likely to become available to pursue the above?

Factors in Selecting Material for Digitisation

It is important to establish copyright from the outset of your project as this may take a significant amount of time, and influence the viability of the project. If copyright cannot be traced then suitable records should be kept of attempts to establish copyright. You may then choose to publish uncleared material ‘at risk’. Legal advice should be sought if you are in any doubt.

Permission

Decisions will be informed by:

Collection Factors:

The condition of the objects; their importance and relevance; whether a selection would be sufficient and more realistic than digitising a complete collection; their relationship to other published collections. Is this part of a strategy to publish a certain area of the collection, for instance, and the need to reduce handling while providing access through digital surrogates.

Human Resources:

Will staff or volunteers need recruiting and do they have the necessary skills or is there a need for training?

Equipment issues:

Should digitisation take place externally through a specialist service? Is equipment available in-house or through a partner?

Standards:

What standards are to be used?

Rights:

Do you have rights over the material to be digitised?

Sustainability:

How will the digital resource be sustained, especially beyond the timescale of the project?

Project Planning Tools

Common project management tools include the following:

• A SMART analysis. Projects should be SMART i.e. Specific, Measurable, Achievable, Realistic and Timebound.
• Project Justification: Why are you doing this?
• Project Plan: Examining resources. A feasibility study may come first.
• Work Breakdown Structure: Defining tasks and sub-tasks.
• PERT (Project Evaluation and Review Technique) model: Analysis of tasks, timescales and interdependencies.
• GANTT Chart (named after Henry Gantt): A table listing tasks set against the project timescale, with milestones.

Involving Your Users/Evaluation

There should be evidence of demand for the digital assets that you are planning to create. This may be available, for example in having a large number of enquiries for a particular collection, if not it should be tested.

In order to ensure that your resource delivers its intended outcomes as effectively as possible, it is a good idea to start with the needs of the end user in mind, basing the design and structure of your resource on how they will use it. If this is a Web site, once you have defined your own objectives (i.e. why you want to do it, what it will help you to achieve), you should consider: (a) Who the site is for and who do you want to use it? (b) What are these users’ needs from the site: what will they want to do, and why? (c) How will they be using the site? and (d) What do you want users to get from their visit?

Acknowledgements

This document has been produced from information contained within the Renaissance East Midlands Simple Guide to Digitisation that was researched and written by Julian Tomlin and is available from http://www.renaissanceeastmidlands.org.uk/. We are grateful for permission to republish this document under a Creative Commons licence. Anyone wishing to republish this document should include acknowledgements to Renaissance East Midlands and Julian Tomlin.

Copyright is a type of intellectual property that protects artistic works such as literature, music, art and recordings. It provides protection for creators as well as publishers. It is also important for publishers, such as museums, to protect themselves against breaches of copyright.

Copyright varies country by country although there is increasing harmonisation within the EU, and international treaties cover many countries.

There is no need to register copyright.

Some key facts relating to UK law:

• In a literary, musical or artistic work (including a photograph), copyright lasts until 70 years after the death of the creator.
• In sound recordings and broadcasts copyright usually belongs to the producer, broadcaster or publisher.
• Sound recordings are generally protected for 50 years from the year of publication. Broadcasts are protected for 50 years.

These guidelines are an interpretation of UK law. Please take appropriate legal advice before making any significant decisions regarding copyright of resources used in your service or project.

Establishing Copyright

It is important to establish copyright from the outset of your project as this may take a significant amount of time, and influence the viability of the project. If copyright cannot be traced then suitable records should be kept of attempts to establish copyright. You may then choose to publish uncleared material ‘at risk’. Legal advice should be sought if you are in any doubt.

Permission

For material in copyright, you should seek permission from the creator or copyright holder. This will relate to particular uses, for instance in a guidebook or on the museum’s web site.

There are some exceptions to the copyright owner’s rights. For example, you may be allowed limited copying of a work for non-commercial research and private study, criticism or review, reporting current events, and teaching in schools. The copyright holder should still be acknowledged and there are limits in terms of the number of copies and for large amounts of material.

Safeguarding Copyright

Since placing material on the web makes it easier for people to easily reuse it, you should consider ways of safeguarding your copyright.

Common ways are to make users register to use material, publish only low-resolution images, and imbed digital watermarks.

You may judge that while these approaches might help protect misuse they will also limit what might be considered to be unharmful usage. Low-resolution images may still be good enough for many uses, but are not generally good enough for paper-based publications. Digital watermarks can be removed by expert users.

Certainly, restricting some services to registered users may be appropriate for a comprehensive high-profile service such as SCRAN, the Scottish online learning resource, but for a smaller site this approach could be off-putting for the majority of users and still not prevent misuse.

You may chose to licence your digital assets through a Creative Commons licence which provides a more open approach to rights.

Acknowledgements

This document has been produced from information contained within the Renaissance East Midlands Simple Guide to Digitisation that was researched and written by Julian Tomlin and is available from http://www.renaissanceeastmidlands.org.uk/. We are grateful for permission to republish this document under a Creative Commons licence. Anyone wishing to republish this document should include acknowledgements to Renaissance East Midlands and Julian Tomlin.



Micro-blogging is defined in Wikipedia as “a form of blogging that allows users to write brief text updates (usually 140 characters) and publish them, either to be viewed by anyone or by a restricted group which can be chosen by the user. These messages can be submitted by a variety of means, including text messaging, instant messaging, email, MP3 or the Web” [1] [2]. Popular examples of micro-blogging services include Twitter and FriendFeed.

What Is Twitter?

Twitter, the most popular example of a micro-blogging service was launched in July 2006. Twitter allows users (who can register for free) to send brief posts (sometimes known as ‘tweets‘) which can be up to 140 characters long. The tweets are displayed on the users profile page and are delivered to users who have chosen to receive them by following the users’ tweets. Readers of a user’s tweets are referred to as ‘followers‘.

Although the tweets will be delivered to a user’s followers, the tweets can normally be accessed by anyone, even users who have not signed up to Twitter. They are published on the user’s Twitter home page and can also be accessed by an RSS feed.

Twitter Clients

For many the initial experience with a micro-blogging service is Twitter. Initially many users will make use of the Twitter interface provided on the Twitter Web site. However regular Twitter users will often prefer to make use of a dedicated Twitter client, either on a desktop PC or one a mobile device such as an iPhone or iPod Touch.

As well as allowing tweets to be read and posted Twitter clients often allow Twitter followers to be put into groups, Twitter posts content searched, etc.

The Echfon iPod application [3] and the Twhirl [4] and TweetDeck applications for the PC [5] are both popular. An example of how TweetDeck is being used is described at [6].

Use Of Twitter

Examples of uses of Twitter in the cultural heritage sector include:

Brooklyn Museum

A pioneer in the museum sector. See <http://twitter.com/brooklynmuseum>

Scottish Library and Information Council (SLIC) and CILIP in Scotland

See <http://twitter.com/scotlibraries>

Organisers of the Museums and the Web 2009 Conference

Use of Twitter to support its annual conference. See <http://twitter.com/mw2009>

The Getty Museum

See <http://twitter.com/GettyMuseum>

As can be seen from these examples and articles at [7], [8] Twitter can be used by professional bodies and institutions as well as by individuals.

Getting Started With Twitter

If you wish to evaluate Twitter either to support individual interests or those of your organisation you would be advised to register and allow yourself a period of several weeks in order to give you time to ‘get Twitter’ [6]. Remember that you will probably need to follow a critical mass of Twitter users to gain tangible benefits and you will also need to post as well as read tweets to gain the benefits of membership of a viable Twitter community. You should also remember that Twitter may not be for you – you do not need to use Twitter; rather you should be able to use it if it is beneficial.

References

1. Micro-blogging, Wikipedia,
   <http://en.wikipedia.org/wiki/Micro-blogging>
2. An Introduction to Micro-blogging, UKOLN Cultural Heritage Briefing Document No. 35,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-35/>
3. EchoFon, <http://www.twitterfon.com/>
4. Twhirl,
   <http://www.twhirl.org/>
5. TweetDeck,
   <http://www.tweetdeck.com/beta/>
6. Getting Twitter, UK Web Focus blog, 21 Oct 2008,
   <http://ukwebfocus.wordpress.com/2008/10/21/getting-twitter/>
7. Learning from our Twitter xperiment,Lynda Kelly, 20 Aug 2008,
   <http://museum30.ning.com/profiles/blogs/2017588:BlogPost:9689>
8. Twitter for Librarians: The Ultimate Guide, 27 May 2008,
   <http://www.collegeathome.com/blog/2008/05/27/twitter-for-librarians-the-ultimate-guide/>

Micro-blogging is defined in Wikipedia as “a form of blogging that allows users to write brief text updates (usually 140 characters) and publish them, either to be viewed by anyone or by a restricted group which can be chosen by the user. These messages can be submitted by a variety of means, including text messaging, instant messaging, email, MP3 or the Web” [1].

Popular examples of micro-blogging services include Twitter and FriendFeed. In additional the status feature of social networking services such as Facebook provides another example of micro-blogging.

What Is Video Micro-blogging?

Video micro-blogging is the multimedia equivalent, whereby short video posts can be published. The best-known example of a video micro-blogging service is Seesmic [2].

What Benefits Can Micro-Blogging Provide?

Rather than seeking to describe potential uses of micro-blogging tools such as Twitter, it may be preferable to provide analogies for their use. As described at [3] micro-blogging tools such as Twitter can be regarded as:

• The bar where everybody knows your name.
• An interactive business card (see [4]).
• A room of experts who can respond to your queries (see [5]).
• A room of friends who can listen to your concerns.
• A room of strangers who can sometimes surprise you.
• A digital watercooler, particular useful for home workers to share office gossip.

Other potential benefits include:

• Listening into announcements, discussions or informal conversations about your organisation or the services provided by your organisation.
• Providing business intelligence related to your peers, your funders or, in some circumstances, perhaps, competing organisations.

Micro-blogging can be regarded as a tool which can support a community of practice by providing a forum for work-related discussions and informal chat.

The Downside To Microblogging

A superficial look at Twitter might lead to the conclusions that micro-blogging services such as Twitter provides nothing more than trivial content and has no relevance to the information professional. However many Twitter users who have chosen to spend time in exploring its potential benefits. Twitter, like blogs, can be used for a variety of purposes although it also has the potential to be used as a communications medium, with Twitter users asking questions and discussing issues. In this respect Twitter has some parallels with chat rooms. But as with chat rooms, Instant Messaging, email and Web sites such tools can be counter-productive if used for inappropriate uses and if used excessively or to the detriment of other work activities.

Developing Good Practices For Micro-blogging

A simplistic response to potential misuses of micro-blogging tools would be to ban its use. However this approach would result in staff missing out on the benefits of making use of informal contacts and your organisation exploiting the benefits described above.

If you feel there is a need to establish a policy covering use of micro-blogging you might wish to ask whether you trust your staff to use such technologies in an appropriate fashion. And if you feel there is a need to implement such policies remember that staff can misuse their time at work in other ways which do not need access to technologies. Perhaps the best advice would be to ensure that you keep up-to-date with examples of effective use of micro-blogging [5] and ways of appreciated its benefits [6]. Managers should also encourage their staff to be innovative.

References

1. Micro-blogging, Wikipedia,
   <http://en.wikipedia.org/wiki/Micro-blogging>
2. An Introduction to Seesmic, UKOLN Cultural Heritage Briefing Document No. 37,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-37/>
3. Twitter, microblogging and living in the stream, The Edtechie Blog, 9 Sep 2008,
   <http://nogoodreason.typepad.co.uk/no_good_reason/2008/09/twitter-microblogging-and-living-in-the-stream.html>
4. Twitter? It’s An Interactive Business Card, UK Web Focus blog, 17 Apr 2008,
   <http://ukwebfocus.wordpress.com/2008/04/17/twitter-its-an-interactive-business-card/>
5. What Can Web 2.0 Offer To The IAMIC Community?, UK Web Focus blog, 22 Sep 2008,
   <http://ukwebfocus.wordpress.com/2008/09/22/what-can-web-20-offer-to-the-iamic-community/>
6. Getting Twitter, UK Web Focus blog, 21 Oct 2008,
   <http://ukwebfocus.wordpress.com/2008/10/21/getting-twitter/>

Creative Commons (CC) [1] refers to a movement started in 2001 by US lawyer Lawrence Lessig that aims to expand the collection of creative work available for others to build upon and share. The Creative Commons model makes a distinction between the big C (Copyright) meaning All Rights Reserved and CC meaning Some Rights Reserved. It does so by offering copyright holders licences to assign to their work, which will clarify the conditions of use and avoid many of the problems current copyright laws pose when attempting to share information.

What Licences?

There are a series of eleven Creative Commons licences available to download from the Web site. They enable copyright holders to allow display, public performance, reproduction and distribution of their work while assigning specific restrictions. The six main licences combine the four following conditions:

	Attribution – Users of your work must credit you.
	Non-commercial – Users of your work can make no financial gain from it.
	Non-derivative – Only verbatim copies of your work can be used.
	Share-alike – Subsequent works have to be made available under the same licence as the original.

The other licences available are the Sampling licence, the Public Domain Dedication, Founders Copyright, the Music Sharing licence and the CC Zero licence. Creative Commons also recommends two open source software licences for those licensing software: the GNU General Public licence and the GNU Lesser Public licence.

Each license is expressed in three ways: (1) legal code, (2) a commons deed explaining what it means in lay person’s terms and (3) a machine-readable description in the form of RDF/XML (Resource Description Framework/Extensible Mark up Language) metadata. Copyright holders can embed the metadata in HTML pages.

International Creative Commons

The Creative Commons licences were originally written using an American legal model but through the Creative Common international (CCi) have since been adapted for use in a number of different jurisdictions. As of April 2009 52 jurisdictions have completed licences and 7 jurisdictions licences are being developed.

The regional complexities of UK law has meant that two different set of licences have had to be drafted for use of the licenses the UK. Creative Commons worked with the Arts and Humanities Research Board Centre for Studies in Intellectual Property and Technology Law at Edinburgh University on the Scotland jurisdiction-specific licenses completed December 2005 (version 2.5) and the Information Systems and Innovation Group (ISIG) to create the England and Wales jurisdiction-specific licenses completed April 2005 (version 2.0).

Why Use Creative Commons Licences?

There are many benefits to be had in clarifying the rights status of a work. When dealing with Creative Commons licenced work, it is known if the work can be used without having to contact the author, thus allowing the work to be exploited more effectively, more quickly and more widely, whilst also increasing the impact of the work. Also in the past clarification of IPR has taken a huge amount of time and effort, Creative Commons could save some projects a considerable amount of money and aid their preservation strategies. More recently, because Creative Commons offers its licence in a machine-readable format, search engines can now search only CC licenced resources allowing users easier access to ‘free materials’.

Issues

Although Creative Commons has now been in existence for a while there are still issues to be resolved. For example in the UK academic world the question of who currently holds copyright is a complex one with little commonality across institutions. A study looking at the applicability of Creative Commons licences to public sector organisations in the UK has been carried out [2].

Another key area for consideration is the tension between allowing resources to be freely available and the need for income generation. Although use of a Creative Commons license is principally about allowing resources to be used by all, this does not mean that there has to be no commercial use. One option is dual licensing, which is fairly common in the open source software environment.

References

1. Creative Commons,
   <http://creativecommons.org/>
2. Creative Commons Licensing Solutions for the Common Information Environment, Intrallect,
   <http://www.intrallect.com/cie-study/>

This document provides top tips which can help to ensure that Web sites can be preserved.

The Top 10 Tips

1 Define The Purpose(s) Of Your Web Site

You should have a clear idea of the purpose(s) of your Web site and you should document the purposes. Your Web site could, for example, provide access to project deliverables for end users; could provide information about the project; could be for use by project partners; etc. A policy for preservation will be dependent of the role of the Web site.

2 Have A URI Naming Policy

Before launching your Web site you should develop a URI naming policy. Ideally you should contain the project Web site within its own directory, which will allow the project Web site to be processed (e.g. harvested) separately from other resources on the Web site.

3 Think Carefully Before Having Split Web Sites

The preservation of a Web site which is split across several locations may be difficult to implement. However also bear in mind tip 4.

4 Think About Separating Web Site Functionality

On the other hand it may be desirable to separate the functionality of the Web site, to allow, for example, information resources to be processed independently of other aspects of the Web site. For example, the search functionality of the Web site could have its own sub-domain,(e.g. search.foo.ac.uk) which could allow the information resources (under www.foo.ac.uk) to be processed separately.

5 Make Use Of Open Standards

You should seek to make use of open standard formats for your Web site. This will help you to avoid lock-in to proprietary formats for which access may not be available in the future. However you should also be aware of possible risks and resource implications in using open standards.

6 Explore Potential For Exporting Resources From A CMS

You should explore the possibility of exporting resources from a backend database or Content Management Systems in a form suitable for preservation. When procuring a CMS you should seek to ensure that such functionality is available.

7 Be Aware Of Legal, IPR, etc. Barriers To Preservation

You need to be aware of various legal barriers to preservation. For example, do you own the copyright of resources to be preserved; are there IPR issues to consider; are confidential documents (such as project budgets, minutes of meetings, mailing list archives, etc.) to be preserved; etc.

8 Ensure Institutional Records Managers Provide Input

You should ensure that staff from your institution’s records management teams provide input into policies for the preservation of Web site resources.

9 Provide Documentation

You should provide technical documentation on your Web site which will allow others to preserve your Web site and to understand any potential problem areas. You should also provide documentation on your policy of preservation.

10 Share Your Experiences

Learn from the experiences of others. For example read the case study on Providing Access to an EU-funded Project Web Site after Completion of Funding [1] and the briefing document on Mothballing Web Sites [2].

References

• Providing Access to an EU-funded Project Web Site after Completion of Funding, QA Focus, UKOLN,
  <http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-17/>
• Mothballing Web Sites , QA Focus, UKOLN,
  <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-04/>

Wikipedia defines a mashup as “a web application that combines data from more than one source into a single integrated tool” [1]. Many popular examples of mashups use the Google Map service to provide a location display of data taken from another source.

Technical Concepts

As illustrated in a video clip on “What Is A Mashup?” [2] from a programmer’s perspective a mashup is based on making use of APIs (application programmers interface). In a desktop PC environment, application programmers make use of operating system functions (e.g. drawing a shape on a screen, accessing a file on a hard disk drive, etc.) to make use of common functions within the application they are developing. A key characteristic of Web 2.0 is the notion of ‘the network as the platform’. APIs provided by Web-based services (such as services provided by companies such as Google and Yahoo) can similarly be used by programmers to build new services, based on popular functions the companies may provide. APIs are available for, for example, the Google Maps service and the del.icio.us social book marking service.

Creating Mashups

Many mashups can be created by simply providing data to Web-based services. As an example, the UK Web Focus list of events is available as an RSS feed as well as a plain HTML page [3]. The RSS feed includes simple location data of the form:

<geo:lat>51.752747</geo:lat>
<long>-1.267138</geo:long>

This RSS feed can be fed to mashup services, such as the Acme.com service, to provide a location map of the talks given by UK Web Focus, as illustrated.

Tools For The Developer

More sophisticated mashups will require programming expertise. The mashup illustrated which integrates photographs and videos from Flickr and YouTube for a wide range of UK museums was produced as a prototype by Mike Ellis, a software developer [5].

However tools are being developed which will allow mashups to be created by people who may not consider themselves to be software developers – the best known is Yahoo Pipes [6] which “provides a graphical user interface for building data mashups that aggregate web feeds, web pages, and other services, creating Web-based apps from various sources, and publishing those apps” [7].

Allowing Your Service To Be ‘Mashed Up’

Paul Walk commented that “The coolest thing to do with your data will be thought of by someone else” [8]. Mashups provide a good example of this concept: if you provide data which can be reused, this will allow others to develop richer services which you may not have the resources or expertise to develop. It can be useful, therefore, to seek to both provide structured data for use by others and to avoid software development if existing tools already exist. However you will still need to consider issues such as copyright and other legal issues and service sustainability.

References

1. Mashup (web application hybrid, Wikipedia,
   <http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid)>
2. What is A Mashup?, ZDNet,
   <http://news.zdnet.com/2422-13569_22-152729.html >
3. Forthcoming Events and Presentations, UK Web Focus, UKOLN,
   <http://www.ukoln.ac.uk/web-focus/events/>
4. Location of UK Web Focus Event, UKOLN,
   <http://www.acme.com/GeoRSS/?xmlsrc=http://www.ukoln.ac.uk/web-focus/events/presentations-2007.rss>
5. Mashed Museum Director,
   <http://www.mashedmuseum.org.uk/mm/museumdirectory/v3/>
6. Yahoo Pipes, Yahoo,
   <http://pipes.yahoo.com/pipes/>
7. Yahoo Pipes, Wikipedia,
   <http://en.wikipedia.org/wiki/Yahoo!_Pipes>
8. The coolest thing to do with your data will be thought of by someone else, Paul Walk, 23 July 2007,
   <http://blog.paulwalk.net/2007/07/23/>

Page layout, content and navigation are not always designed at the same time. It is often necessary to work through at least part of these processes separately. As a result, it may not be possible to test layouts with realistic content until a relatively late stage in the design process, meaning that usability problems relating to the layout may not be found at the appropriate time.

Various solutions exist for this problem. One is the possibility of testing early prototype layouts containing ‘greeked’ text – that is, the ‘lorem imsum’ placeholder text commonly used for layout design [1]. A method for testing the recognisability of page elements was discussed in Neilsen’s Alertbox back in 1998 [2], though the concept originated with Thomas S. Tullis [3].

Technique

Testing will require several users – around six is helpful without being excessively time-consuming. Ensure that they have not seen or discussed the layouts before the test! First, create a list of elements that should be visible upon the layout. Nielsen provides a list of nine standard elements that are likely to present on all intranet pages – but in your particular case you may wish to alter this list a little to encompass all of the types of element present on this template.

Give each test user a copy of each page – in random sequence, to eliminate any systematic error that might result from carrying the experience with the first page through to the second. Ask the test user to draw labelled blocks around the parts of the page that correspond to the elements you have identified. Depending on circumstances, you may find that encouraging the user to ‘think aloud’ may provide useful information, but be careful not to ‘lead’ the user to a preferred solution.

Finally, ask the user to give a simple mark out of ten for ‘appeal’. This is not a very scientific measure, but is nonetheless of interest since this allows you to contrast the user’s subjective measure of preference against the data that you have gathered (the number of elements correctly identified). Nielsen points out that the less usable page is often given a higher average mark by the user.

Scoring The Test

With the information provided, draw a simple table:

This provides you with a basic score. You will probably also find your notes from think-aloud sessions to be very useful in identifying the causes of common misunderstandings and recommending potential solutions.

When Should Page Template Evaluation Be Carried Out?

This technique can be applied on example designs, so there is no need to create a prototype Web site; interface ideas can be mocked up using graphics software. These mockups can be tested before any actual development takes place. For this reason, the template testing approach can be helpful when commissioning layout template or graphical design work. Most projects will benefit from a user-centred design process, an approach that focuses on supporting every stage of the development process with user-centred activities, so consider building approaches like this one into your development plans where possible.

Conclusions

If a developing design is tested frequently, most usability problems can be found and solved at an early stage. The testing of prototype page layouts is a simple and cheap technique that can help to tease out problems with page layout and visual elements. Testing early and often can save money by finding these problems when they are still cheap and simple to solve.

It is useful to make use of various methods of usability testing during an iterative design and development cycle, since the various techniques often reveal different sets of usability problems – testing a greeked page template allows us to separate the usability of the layout itself and the usability of the content that will be placed within this content [2]. It is also important to evaluate issues such as content, navigation mechanisms and page functionality, by means such as heuristic evaluation and the cognitive walkthrough – see QA Focus documents on these subjects [4] [5]. Note that greeked template testing does look at several usability heuristics: Aesthetic & minimalist design and Consistency and standards are important factors in creating a layout that scores highly on this test.

Finally, running tests like this one can help you gain a detailed understanding of user reactions to the interface that you are designing or developing.

References

1. Lorem Ipsum Generator,
   <http://lorem-ipsum.perbang.dk/>
2. Testing Greeked Page Templates, Jakob Nielsen,
   <http://www.useit.com/alertbox/980517.html>
3. A method for evaluating Web page design concepts, T.S. Tullis. In ACM Conference on Computer-Human Interaction CHI 98 Summary (Los Angeles, CA, 18-23 April 1998), pp. 323-324.
4. Introduction To Cognitive Walkthroughs, QA Focus briefing document no. 87,
   <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-87/>
5. Heuristic Evaluation, QA Focus briefing document no. 89,
   <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-89/>

Further Information

• Getting Started With User Centred Design, UsabilityNet,
  <http://www.usabilitynet.org/tools/gettingstarted.htm>

When designing a Web site or program, the obvious question to ask at once is, “who are my audience?” It seems natural to design with users in mind, and just as natural to wish to build a product that is satisfactory to all one’s users – however, experience shows that it is difficult to design something that appeals to everybody [1]. Instead, it is useful to start with a few sample profiles of users, typical examples of the audience to whom the design should appeal, and design to their needs. Not only is it easier for the designer, but the result is usually more appealing to the user community.

Researching A User Persona

The first step in developing a user persona is to learn a little about your users; qualitative research techniques like one-to-one interviews are a good place to start. It’s best to talk to several types of users; don’t just focus on the single demographic you’re expecting to appeal to, but consider other groups as well. Focusing on one demographic to the exclusion of others may mean that others do not feel comfortable with the resulting design, perhaps feeling alienated or confused. The expected result of each interview is a list of behaviour, experience and skills. After a few interviews, you should see some trends emerging; once you feel confident with those, it’s time to stop interviewing and start to build personas.

Developing A User Persona

Once you have an idea of each type of persona, write down the details for each one. It may help to write a sort of biography, including the following information:

• Vital statistics: name, age, gender and personality details (shy, timid, outgoing?)
• Interests and hobbies
• Experience and education
• Motivation

You can even find a photograph or sketch that you feel fits the personality and add it to the persona’s description.

Why User Personas?

The intent behind a user persona is to create a shared vocabulary for yourself and your team when discussing design questions and decisions. User personas provide easy-to-remember shorthand for user types and behaviour, and can be used to refer to some complex issues in a simple and generally understood way. Sharing them between management and development teams, perhaps even with funders, also provides a useful avenue for effective communication of technical subjects. Furthermore, it is much easier to design for a persona with whom one can empathise than for a brief, dry description of user demographics.

It is good practice, when making design decisions, to consider each user persona’s likely reaction to the result of the decision. Which option would each user persona prefer?

User personas can also feed in to discount usability testing methods such as the cognitive walkthrough, saving time and increasing the effectiveness of the approach.

Finally, the research required to create a user persona is an important first step in beginning a user-centred design process, an approach that focuses on supporting every stage of the development process with user-centred activities, which is strongly recommended in designing for a diverse user group.

Conclusions

User personas are a useful resource with which to begin a design process, which allow the designers to gain understanding of their users’ expectations and needs in a cheap and simple manner, and can be useful when conducting discount usability testing methods. Additionally, they make helpful conversational tools when discussing design decisions.

References

1. The Inmates are Running the Asylum, Alan Cooper, ISBN: 0672316498

Further Information

• Ten Usability Heuristics, Jakob Nielsen,
  <http://www.useit.com/papers/heuristic/heuristic_list.html>
• Getting Started With User Centred Design, UsabilityNet,
  <http://www.usabilitynet.org/tools/gettingstarted.htm>

A key issue in usability is that of understanding users, and a key part of user-centred design is that of describing the tasks that the users expect to be able to accomplish using the software you design [1]. Because of the origins of usability as a discipline, a lot of the terminology used when discussing this issue comes from fields such as task analysis. This briefing paper defines some of these terms and explains the relationship between usability and task analysis.

What Is Task Analysis?

Within the usability and human-computer interaction communities, the term is generally used to describe study of the way people perform tasks – that is, the way in which a task is currently performed in real-life situations. Task analysis does not describe the optimal or ideal procedure for solving a problem. It simply describes the way in which the problem is currently solved.

Gathering Data For Task Analysis

Since the intent of task analysis is description of an existing system, the ideal starting point is data gathered from direct observation. In some cases, this is carried out in a controlled situation such as a usability laboratory. In others, it is more appropriate to carry out the observation “in the field” – in a real-life context. These may yield very different results!

Observational data can be gathered on the basis of set exercises, combined with the “think-aloud” technique, in which subjects are asked to describe their actions and their reasoning as they work through the exercise. Alternatively, observations can be taken by simply observing subjects in the workplace as they go through a usual day’s activities. The advantage of this latter method is principally that the observer influences events as little as possible, but the corresponding disadvantage is that the observations are likely to take longer to conclude.

Unfortunately, there are significant drawbacks of direct observation, principally cost and time constraints. For this reason, task analysis is sometimes carried out using secondary sources such as manuals and guidebooks. This, too, has drawbacks – such sources often provide an idealised or unrealistic description of the task.

A third possibility is conducting interviews – experts, themselves very familiar with a task, can easily answer questions about that task. While this can be a useful way of solving unanswered questions quickly, experts are not always capable of precisely explaining their own actions as they can be too familiar with the problem domain, meaning that they are not aware on a conscious level of the steps involved in the task.

Analysing Observations

There are several methods of analysing observational data, such as knowledge-based analysis, procedural [2] or hierarchical task analysis, goal decomposition (the separation of each goal, or step, into its component elements) and entity-relationship based analysis. Data can also be visualised by charting or display as a network. Some methods are better suited to certain types of task – e.g. highly parallel tasks are difficult to describe using hierarchical task analysis (HTA). On the other hand, this method is easy for non-experts to learn and use. Each answers a slightly different question – for example, HTA describes the knowledge and abilities required to complete a task, while procedural task analysis describes the steps required to complete a task.

A simple procedural task analysis is completed as follows:

1. Choose the appropriate procedure to complete the task that is being analysed.
2. Determine and write down each step in that procedure; break down each step as far as possible.
3. Complete every step of the procedure.
4. Check that the procedure gave the correct result.

These steps can be charted as a flowchart for a clear and easy to read visual representation.

Conclusions

Task analysis provides a helpful toolkit for understanding everyday processes and for describing how human beings solve problems. It is not appropriate to perform detailed task analysis in every situation, due to cost and complexity concerns. However, the results of a task analysis can usefully inform design or pinpoint usability problems, particularly differences between the system designer’s assumptions and the users’ “mental models” – ways of looking at – the task to be performed.

References

1. Task Analysis and Human-Computer Interaction, Crystal & Ellington,
   <http://www.ils.unc.edu/~acrystal/AMCIS04_crystal_ellington_final.pdf>
2. Procedural Task Analysis,
   <http://classweb.gmu.edu/ndabbagh/Resources/Resources2/procedural_analysis.htm>

Usability refers to a quality attribute that assesses how easy user interfaces are to use. The term is also used to refer to a number of techniques and methods for improving usability during the various stages of design and development.

What Does Usability Include?

Usability can be separated into several components [1] such as:

Learnability:

How easy it is to get to grips with an unfamiliar interface?

Efficiency:

How quickly an experienced user can perform a given task?

Memorability:

Once familiar with an interface, is it easily forgettable?

Errors:

How easy is it to make mistakes/recover from mistakes?

Satisfaction:

Is the design enjoyable to use?

These characteristics are all useful metrics, although the importance of each one depends on the expected uses of the interface in question. In some circumstances, such as software designed for a telephone switchboard operator, the time it takes for a skilled user to complete a task is rather more important than learnability or satisfaction. For an occasional web user, a web site’s designers may wish to focus principally on providing a site that is learnable, supports the user, and is enjoyable to use. Designing a usable site therefore requires a designer to learn about the needs of the site’s intended users, and to test that their design meets the criteria mentioned above.

Why Does Usability Matter?

More attention is paid to accessibility than to usability in legislation, perhaps because accessibility is perceived as a clearly defined set of guidelines, whilst usability itself is a large and rather nebulous set of ideas and techniques. However, a Web site can easily pass accessibility certification, and yet have low usability; accessibility is to usability what legible handwriting is to authorship. Interfaces with low usability are often frustrating, causing mistakes to be made, time to be wasted, and perhaps impede the user from successfully reaching their intended goal at all. Web sites with low usability will not attract or retain a large audience, since if a site is perceived as too difficult to use, visitors will simply prefer to take their business elsewhere.

Usability Testing

User testing is traditionally an expensive and complicated business. Fortunately, modern discount (‘quick and dirty’) methods have changed this, so that it is now possible to quickly test the usability of a web site at any stage in its development. This process, of designing with the user in mind at all times, is known as user-centred design. At the earliest stages, an interface may be tested using paper prototypes or simple mockups of the design. It is advisable to test early and often, to ensure that potential problems with a design are caught early enough to solve cheaply and easily. However, completed Web sites also benefit from usability testing, since many such problems are easily solved.

User testing can be as simple as asking a group of users, chosen as representative of the expected user demographic, to perform several representative tasks using the Web site. This often reveals domain-specific problems, such as vocabulary or language that is not commonly used by that group of users. Sometimes user testing can be difficult or expensive, so discount techniques such as heuristic evaluation [2], where evaluators compare the interface with a list of recommended rules of thumb, may be used. Other discount techniques include cognitive walkthrough in which an evaluator role-plays the part of a user trying to complete a task. These techniques may be applied to functional interfaces, to paper prototypes, or other mockups of the interface.

A common method to help designers is the development of user personas, written profiles of fictitious individuals who are designed to be representative of the site’s intended users. These individuals’ requirements are then used to inform the design process and to guide the design process.

Conclusions

Considering the usability of a web site not only helps users, but also tends to improve the popularity of the site in general. Visitors are likely to get a better impression from usable sites. Quick and simple techniques such as heuristic evaluation can be used to find usability problems; frequent testing of a developing design is ideal, since problems can be found and solved early on. Several methods of usability testing can be used to expose different types of usability problems.

References And Further Information

1. Usability 101: Introduction to Usability, J. Nielsen,
   <http://hcibib.org/tcuid/chap-4.html>
2. Heuristic Evaluation, J. Nielsen,
   <http://portal.acm.org/citation.cfm?id=142869>

• Ten Usability Heuristics, J. Nielsen,
  <http://www.useit.com/papers/heuristic/heuristic_list.html>

<!–

• Usability Evaluation with the Cognitive Walkthrough, Rieman et al,
  <http://www.bui.fh-hamburg.de/pers/ursula.schulz/eulerev/cogwalk1.htm>

–>

• Personas: Matching a design to the users’ goals,
  <http://www.uie.com/articles/personas/>

Why The Interest In Facebook?

Facebook has generated much interest over recent months. Much of the interest has arisen since Facebook announced the Facebook Platform [1] which enabled third party developers to build applications which could be used within the Facebook environment.

Since Facebook was developed initially to support students it is not surprising that student usage has proved so popular. This interest has also spread to other sectors within institutions, with researchers and members of staff exploring Facebook possibilities.

What Can Be Done Within Facebook?

Social networks can provide a range of benefits to members of an organisation:

Connections with peers

The main function of Facebook is to provide connections between people with similar interests. Friends can then send messages to each other (either closed messages or open for others to read).

Groups

Facebook users can set up discussion group areas, which can be used by people with interests in the topic of the group. Creation of details of events, which allows users to sign up to, is another popular use of Facebook.

Sharing resources

Many of the popular Facebook applications are used for sharing resources. Some of these replicate (or provide an interface to) popular social sharing services (such as Flickr and YouTube) while other applications provide services such as sharing interests in films, books, etc.

An environment for other applications

he opening of the Facebook Platform has allowed developers to provide access to a range of applications. The ArtShare application [2], for example, provides access to arts resources from within Facebook.

Web presence

Although originally designed for use by individuals since November 2007 Facebook can be used as a Web hosting service for organisational pages.

It should also be noted that organisational pages in Facebook were redesigned in 2009 so that they more closely resemble personal pages [3]. Organisational pages are now also able to share status updates.

What Are The Challenges?

Reservations about use of Facebook in an institutional context include:

Privacy

There are real concerns related to users’ privacy. This will include both short term issues (embarrassing photos being uploaded) and longer term issues (reuse of content in many years time).

Ownership

The Facebook terms and conditions allow Facebook to exploit content for commercial purposes.

Misuse of social space

Users may not wish to share their social space with other colleagues, especially when there may be hierarchical relationships.

Liability

Who will be liable if illegal content or copyrighted materials are uploaded to Facebook? Who is liable if the service is not accessible to users with disabilities?

Sustainability and Interoperability

How sustainable is the service? Can it provide mission-critical services? Can data be exported for reuse in other systems?

Resources

The cost implications in developing services for the Facebook platform.

Institutional Responses To Such Challenges

How should institutions respond to the potential opportunities provided by Facebook and the challenges which its use may entail? The two extreme positions would be to either embrace Facebook, encouraging its use by members of the institution and porting services to the environment or to ban its use, possibly by blocking access by the institutions firewall. A more sensible approach might be to develop policies based on:

Risk assessment and risk management

Analysing potential dangers and making plans for such contingencies. Note that the risk assessment should also include the risks of doing nothing

User education

Developing information literacy / staff development plans to ensure users are aware of the implications of use of Facebook, and the techniques for managing the environment (e.g. privacy settings).

Data management

Developing mechanisms for managing data associated with Facebook. This might include use of Facebook applications which provide alternative interfaces for data import/export, exploring harvesting tools or engaging in negotiations with the Facebook owners.

References

1. Major Facebook Announcement Thursday: Facebook Platform, Mashable, 21 May 2007,
   <http://mashable.com/2007/05/21/facebook-f8/>
2. Artshare, Brooklyn Museum Blog, 8 Nov 2007,
   <http://www.brooklynmuseum.org/community/blogosphere/bloggers/2007/11/08/artshare-on-facebook/ >
3. 3. New Facebook Pages: A Guide for Social Media Marketers, Mashable blog, 3 Mar 2009,
   <http://mashable.com/2009/03/04/new-facebook-pages/>

About This Document

This document gives advice on addressing possible barriers you might face when setting up a blog in a cultural heritage context.

Piloting Your Blogging Service

Libraries will often trial a service to test the product and to gauge the response of their library users. Developing your blog as a ‘pilot’ project provides a low-risk, comfortable environment to experiment with the service, and gather feedback from your library community. Setting up the service as a trial allows bloggers and their managers or colleagues to see exactly how much time or resource support is required. It also provides an exit or withdrawal strategy if needed.

Small-scale Activities

Experiment with blogs by supporting a small-scale activity, such as a special event or occasion. This negates the need for ongoing support or commitment, but it gives a taste of the strengths and opportunities of blogs.

A blog for an internal working party or committee is another way to introduce blogs. Inviting library staff to join a closed membership blog gives the opportunity to experiment with the blog and add posts and comments without it being exposed to the general public.

Policies To Soothe Institutional Concerns

Many organisations are reluctant to release material to their library users until it has been vetted by a publications group or similar process. This may be presented as a barrier to establishing a blogging service. To counter this argument, it may be wise to develop a robust set of policies outlining the quality processes to which the blog style and content will be subjected (see briefing paper no. 5 on Developing Blog Policies [1]).

Include a statement in your blog policies to welcome feedback and notification of errors, and that any identified problems will be addressed as quickly as possible. A fundamental advantage of blogs is that they allow for immediate alterations or changes.

Low Cost, Minimal Resources

Many conventional communications have associated costs (paper, laminating, etc) but setting up a blog can be a low cost solution. Popular blogging sites like WordPress, Typepad, LiveJournal and Blogger allow for template modification to match organisational themes for no outlay. Little knowledge of HTML or design principles is needed to create a professional-looking blog.

Demystifying Blogs With Best Practice Examples

Your library colleagues have likely come across negative as well as positive coverage of blogs and blogging in the press. Blogs have been described as vanity publishing and as a platform on which anyone can relate excruciatingly detailed minutiae of their lives.

Responsible blogging offers the opportunity to engage with your library users using a format with which they are familiar. There are many great library related blogs available and it may help to build these into a collection for circulation amongst your colleagues. Look at the blogrolls on your favourite blogs for new leads or keep an eye on your library association literature for pointers to new blogs displaying best practices.

Participating On Other Blogs

It will help to advocate for a blogging service if you are familiar with blog processes and have actively engaged or participated in blogging. Build your confidence by participating in group blogs, or set up a blog outside of work. If you are part of a society or organisation, start a blog to highlight the group’s events or activities. Use a blog to record your professional development, such as library association chartership.

Demonstrating Value

Hosted blog services all contain built-in statistical reporting, providing information on number of views and popular posts. It may be useful to read the ‘Evaluating your Blog‘ Briefing Paper [2] for more information on demonstrating the value of a blog.

Encouraging Enthusiasts

Seek out blog ‘champions’ or colleagues who are supportive of blogging activities. One approach for creating interest may be to add a ‘Learn to blog’ session to your staff development activities. Invite colleagues (or better yet – users!) who are blog enthusiasts to share their activities.

References

1. 1. Developing Blog Policies, Cultural heritage briefing document no. 5, UKOLN,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-5/>
2. Evaluating Your Blog, Cultural heritage briefing document no. 10, UKOLN,
   <http://www.ukoln.ac.uk/cultural-heritage/documents/briefing-10/>

About This Document

This document provides advice on a variety of technical issues which need to be addressed when you are planning your blog service.

Externally Hosted Or Locally Hosted Software?

Where should you host your blog software? Traditionally when organisations have wished to provides IT services they have either installed software in-house, or negotiated a contract with an external provider. However many Web 2.0 services, including blogs, can be used for free by external blog providers such as WordPress or Blogger.

What are the pros and cons of making use of a 3rd party service?

Advantages

Little technical expertise needed. No negotiations with an IT Services department needed. You can select your preferred providers based on your requirements, rather than needing to comply with locally approved solutions. You may have more flexibility and be able to experiment with a service provided by a third party.

Disadvantages

There may be risks related to the long term availability of a third-party service. You may not be able to be guaranteed desired levels of service. There may be legal issues, such as data protection, privacy, accessibility, etc. which could be unresolved. You will not receive the level of support you would receive from an in-house supported product.

Note that a briefing document on “Risk Assessment For Use Of Third Party Web 2.0 Services” [1] provides further information on the risks of using externally-hosted services.

Selection Of The Software

It may be useful to make the choice of the architecture (in-house or external) and the particular blog software by considering the choices made by similar organisations to yours. Discussions on mailing lists (e.g. the lis-bloggers mailing list [2] may be helpful.

Blog Configuration Options

Once you have selected your blog software and either installed it or set up an account, you will then have to make various decisions about how the blog is configured. This will include:

Appearance of the blog

You will normally be able to select a ‘theme’ for your blog, from a number of options, which may cover the number of columns, use of sidebars for additional content, etc. You may also wish to brand your blog with logos, organisational colour scheme, etc. Note, though, that configuration options may not be available (or may cost) with third-party blog services.

Additional Content

You may wish to provide additional content on your blog. This might include additional pages or content in the blog’s sidebar, such as a ‘blogroll’ of links to related blogs or blog ‘widgets’. An example of the administrator’s interface for blog widgets on the UK Web Focus blog is shown.

Tags

You may wish to chose the ‘categories’ (or tags) to be associated with your posts. This will allow readers to easily access related posts. You may wish to select categories prior to the launch of your blog; you will be able to add new categories at a later date.

Policy on User Comments

You will need to establish a policy of whether you allow your readers to give comments on blog posts and, if you do, whether such comments need to be moderated before being appended to a blog post.

Options for Blog Authors

You may need to set up various options for contributors to this blog. This might include use of spell checkers, conventions for how dates are displayed, email addresses of the contributors, etc.

Managing Accounts

If you have chosen to have a team blog, you will need to set up accounts for the contributors to the blog.

References

1. Risk Assessment For Use Of Third Party Web 2.0 Services, QA Focus briefing document no. 98, UKOLN,
   <http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-98/>
2. lis-bloggers, JISCMail,
   <http://www.jiscmail.ac.uk/lists/LIS-BLOGGERS.html>