OU blog

Personal Blogs

Christopher Douce

TM470 Considering evaluation

Visible to anyone in the world
Edited by Christopher Douce, Friday, 4 Oct 2024, 16:04

When planning your project, an important question to ask is: how can I tell if my project has been a success?

The extent of your evaluation very much depends on what you do during your project. For some projects, you might consider asking your stakeholders the question: “does this solve your problem?” You can ask this question in different ways: you could prepare a short survey (if you have a number of stakeholders), carry out an interview, or carry out a usability study.

If you consider design (rather than coding) to be your strong point, you may choose to carry out an interaction design project, where the output may well be a detailed high level prototype that could be presented using a prototyping tool. Since you may sidestep some of the important software development skills that you might otherwise demonstrate, is really important to ensure that you carry out your interaction design project in a really thorough way to clearly satisfy the requirement that your project is all about computing. If you are confident with software development and enjoy this aspect of your studies, you may well want to combine design with an aspect of software development; it is completely up to you.

Most interaction design projects are iterative. In fact, a practical recommendation is that a solid project that is based on the interaction design module should have three different development iterations, or phases. The thinking behind this is that this gives you the best opportunity to demonstrate your skills. When you get to the end you may want to ask the question: has my project solved the problem I set out to solve?

Consider an example of an app that could to pre-order a coffee from a local café, or to book a slot for your dog in a pet grooming parlour (you can choose another example if you prefer). 

Iteration 1: First initial sketches

Designs can be presented (and detailed) using different levels of fidelity, which (of course) relates to the idea of detail. A low fidelity design (or sketch) might be a rough sketch on paper (which is known as a paper-based prototype). A high fidelity design might be a design that closely resembles the final product. There are other terms that you might want to consider too: the idea of a vertical prototype (a prototype that covers a small bit of functionality in a lot of depth), or a horizontal prototype (a prototype that covers all the functionality of a product, but in a small amount of depth).

You might begin your design by creating some low fidelity designs, perhaps using paper-based prototyping. In other words, writing a bunch of sketches. You might want to combine this with other approaches from interaction design, such as the writing of user profiles and scenarios. It is up to you. Whatever you do needs to link back to the requirements of whatever it is you are designing. Different products will treat requirements in different ways.

When you have completed your first round of sketches (which could be made either using a pen or pencil, or using a tool), you should show them to whoever has the problem that needs to be solved (the café owner, or manager of the pet grooming parlour) to carry out your first round of evaluations.

Iteration 2: Wireframes

When you have received feedback, and have further refined your requirements, it is then a good idea to try to flesh out your design. You might have a second round of sketches, or you might move from pencil and paper to a prototyping tool. Choose whatever tool or product works best for you and your project.

When you have completed you second set of designs, go back to your stakeholders to get some further feedback. Here you should get some useful data (information about what works well, and what needs to be looked at in a bit more detail) to further refine you prototype further.

Iteration 3: Higher Fidelity prototypes

A high fidelity prototype is all about showing what a final (or polished) version of a product or system might look like. With this final iteration (or phase) you might get elements of your designing working. You may well develop software and create databases. 

As well as considering prototypes in terms of low and high fidelity, there is another couple of dimensions that can be considered helpful: horizontal and vertical prototypes. A horizontal prototype is a demonstration of a design across all its key functionality, but to a limited depth. A vertical prototype, on the other hand, means that you implement a small amount of functionality in a lot of depth. With a vertical prototype, you may well ‘go deep’ with the technology; you may have to choose appropriate software components and frameworks, and justify your choice.

When it comes to your project report, you should share your high fidelity prototype by walking your examiner through a series of screenshots.

Depending on the aim of your project, you might stop at this point. You may well have demonstrated a lot of technical skill and knowledge in a lot of detail. If your project is less about practical software development and more about design, it would be a good idea to carry out a final evaluation of your prototype to answer the question: does my design do what it supposed to do?

Using the DECIDE framework

The DECIDE framework can help you to plan (and run) an evaluation. It is featured within the interaction design module and its accompanying set text. Taking a letter at a time, here are the components of the framework: 

Determine the goals (of your evaluation): What are you aiming to get from your evaluation? Remember, this isn’t the goals of your project, it is the goals of your evaluation. What do you need to do to determine whether it is a success.

Explore the questions: What questions are you trying to find answers for? Or, alternatively, what questions do you need to ask to carry out an evaluation?

Choose the evaluation approach or paradigm: How are you going to approach your evaluation? You can choose a number of different approaches. You might wish to carry our a heuristic evaluation (which doesn’t involve users), a predictive evaluation (to predict how efficient your design is, perhaps using a cognitive walkthrough approach), or user testing (which can involve real users).

Identify the practical issues: This point relates to the detail of how you run your evaluation. If you need participants, how will you go about recruiting them? How will you ensure they are representative? How will you collect data? Will you be making notes on a data collection form, or if you’re carrying out an interview, will you be using the voice recorder app on your mobile phone? When you have captured data, where will you be storing your data, and how will you be making sure your data is secured.

Decide about the ethical issues: If you involve anyone in your evaluation, you need to think about ethics. Essentially, you need to gain permission, and you need to make sure that everyone knows what your evaluation is all about. An important point to emphasise is that you’re carrying out an evaluation of the performance of a product or a solution rather than the performance of your participants. Remember that your participants are always more important than the task of completing your evaluation. 

Evaluate: With your evaluation all planned, your data collection approach chosen, and permission gained, it is now time to carry out your evaluation. After you’ve gathered your data, it is time to analyse your data, interpret your data and then share your findings. In terms of your project report, this will mean the need to write a summary or conclusion.

Carrying out your evaluation

The DECIDE framework helps you to understand why you intend to carry out your evaluation, what criteria for success you consider to be important, and how you intend to carry out your evaluation.

If your project has an evaluation section, a recommendation is to show what you did in series of step by steps. In other words, adopt a narrative approach. Use a series of appendices to share the resources you may have created during the course of your evaluation. If participants are involved in your evaluations, consider taking a photograph of the environment in which an evaluation takes place, sharing that photograph within the body of your report.

Reflections

Although I have suggested three phrases or iterations is often appropriate for an interaction design project, there are no ‘right’ number of iterations. Every project is different. Whilst carrying you’re your project you may discover that you need more phases, and more evaluations.

References

Rogers, Y., Sharp, H., Preece, J. (2023) Interaction Design: Beyond Human-Computer Interaction, 6th Edition. Wiley.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering resources and skills

Visible to anyone in the world

During the planning stages of your project, it is really important to consider resources. There is a link between the notion of resources and one of the module learning outcomes:

L03. Identify, list and justify the resources, skills and activities needed to carry out the project successfully. Identify and address any associated risks

To satisfy the requirements for a distinction level project, you need to have:

… identified the resources, skills and activities, the timely availability of which is essential. Has judged risks appropriately.

Resources can be thought of in a couple of ways. Firstly, you should draw upon and use academic resources. Your choice of these resources will make up your literature review chapter. Secondly, there are the resources that you will need to use to get your project done. There is, of course, a link between both of these types of resources and the skills that you need to apply.

There is another link to bear in mind, which is a link to the risks that you have to take account of. Some risks that you identify might lead you choosing certain types of resources over another. Whatever you do, it is going to be important to justify your decisions about what you have done within your project report. Your considerations need to be convincing.

To read more about risk, and how it relates to TM470, it is worth reading an accompanying blog, Considering project risks

Academic resources

Your TM470 project is all about building on your earlier learning and studies. This means that you need to identify what academic resource might be useful when thinking about your project. The starting point is, of course, the previous modules you have studied. 

The TM470 module materials has a resource called Preparing a Literature Search, which you should read. To offer some complementary guidance, the following blog offers a bit of guidance: TM470 Understanding the Literature review.

The library also maintains a list of links to online databases that relate to ICT which might be useful. A really important point (which I share to students) is: the OU library is your friend. It is a huge resource. Do make sure you find the time to look at it.

When working on your project, it is worthwhile thinking about the following categories of academic resources:

  • Module materials.
  • Textbooks that accompany module materials.
  • Academic articles (such as those found within academic journals).
  • User guides or instruction manuals.
  • Technical websites.

It is all very well knowing which modules, textbooks, articles and databases may help you with your project, but when it comes to your TM470 project you actually need to get on and do something. This takes us to the following section, which addresses the question: ‘what do I need to complete my project?’

Resources you need to complete your project

Your TM470 project will be typically based on a level 3 module. The TM470 module team have written a number of few short articles about what a project (which is based on an earlier level 3 module) might look like.

You might want to draw on TM356 Fundamentals of Interaction Design, for example. In doing so, you may wish to apply the interaction design life cycle. With ID projects, students should ideally carry out a number of design iterations, potentially leading to either a high fidelity prototype, or a design of a particularly implemented software tool or system.

There are many different approaches to prototyping. A prototype can, of course, being as a paper prototype, and then lead onto a series of higher fidelity prototypes. Some students have used PowerPoint, for example. There are other tools that could be used, such as Balsamiq, Adobe XD or Figma. When you have created a design, you will need to carry out an evaluation. This leads to the questions: ‘what do we do to carry out an evaluation?’ and ‘what do we need to carry out an evaluation?’.

Unpicking this further, we can identify different broad categories of resources that we might need.

Software: Software products, such as prototyping tools, software development environments, or products to help you manage information or aspects of your project.

People: Put more broadly, the people category includes stakeholders. Stakeholders can be defined as anyone influenced by or affected by a project. People might also be participants; people who might help you with the testing or evaluation of your product.

Tools: Broadly, tools are anything that helps you to do what you need to do. If you’re capturing requirements and interviewing stakeholders, you might want to use a data recorder. If you’re carrying out an evaluation, might choose to make notes about happens.

Facilities: by facilities you might think about rooms, spaces, or physical places where project related activities occur. If you’re gathering requirements and need to run a focus group, you’ll need to find a place where this takes place. If you will be creating software as a part of your project, you will need a computer and maybe some server space to get it working. If you are evaluating an interface, you’ll need to find somewhere to do that evaluation. 

Different projects will require, of course, different resources. Since your project is only small, you should only use what you have easy access to.

The link to skills

By identifying the resources you need for your project, you will begin to think about the skills you have, the skills that you need to apply, and the skills you need to develop.

As mentioned earlier, resources can be thought being in two broad types: academic resources, and resources you need to complete your project. When writing and preparing your literature review, you may well develop your academic reading and critical thinking skills. When it comes to project resources and project management, you may well need specific skills to make progress on your project.

Practical advice

The different two types of resources needed to be treated differently. Think of your literature review as a narrative (or story) of what you have read. Don’t present a summary of papers, or articles that are relevant to your project. Instead, show the examiner what you have read, what readings are going to be useful within your project, and explain why they are important. There are different ways to structure a literature review, but a practical recommendation is to adopt a thematic approach.

Let’s turn to the other type of resources: project resource. In the planning section of your report, create a table that summarises the resources you need. Give each resource a name, and then offer a brief summary of that it is and why it is important to your project. If appropriate, you might even want to provide a reference.

When you have prepared table of resources (which could include different types of software, people, tools, and facilities), it is time to write about skills. Just as you did with your list of resources, create a table that summarises the skills that you will either need to have, or need to master in order to use these resources.

Considering reflection

Identifying the resources and skills that you need is both important and helpful.

When you get to the end of your project, you will need to complete the reflection section. When you get to this bit of your project ask yourself:

  • Did you choose the right set of resources?
  • Have you developed the skills that you expected to develop?

There is always a further question to ask, which is:

  • Have there been any surprises?

There is (or will be) a whole other blog that relates to reflection, and the importance it plays in TM470.

Acknowledgements

Many thanks to the TM470 project team and fellow TM470 tutors. Although this blog (and other TM470 blogs) are intended to provide useful additional guidance, always refer to the module materials. If you have any questions, please do contact your tutor.

Permalink Add your comment
Share post
Christopher Douce

TM470 Considering project risks

Visible to anyone in the world
Edited by Christopher Douce, Thursday, 18 Apr 2024, 17:05

The nature and character of risk can influence your project in a big way. 

To begin, it is perhaps useful to define what risk means. Drawing on the M815 project management module, I have found the following two definitions:

‘The potential of situation or event to impact on the achievement of specific objectives.’ (APM, 2019, p. 215)

‘An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.’ (PMI, 2017, p. 10)

Fundamentally, risk can influence your choice of project model, and directly influence how you gather requirements. If everything is known, and you are not going to be doing anything risky, you might opt for a simplistic project model. If there are elements of your project that you know nothing about, and have never done certain tasks, you might choose an iterative approach.

When you have chosen a project model for your project, you can then start to think about how risk will potentially influence the different phases of your project. To do this well, you need to a number of things:

Write your risks down. By doing this, you will begin to create what is sometimes called a risk register. 

  • The next task is to consider how important your risks are.
  • You the need to consider how to deal with those risks.
  • In some cases you may choose to mitigate against risks. In other words, if these risks were to appear, you need to know how to respond to them.
  • After having done this, you then need to make some changes to your plan. You might, for example, choose to add more slack into certain elements of your schedule if you need to use some of your mitigations.

When it comes to TM470 you should be carrying out risk planning from the very start of your project since it can guide what you do. Importantly, LO3 directly relate to how you deal with risk:

L03. Identify, list and justify the resources, skills and activities needed to carry out the project successfully. Identify and address any associated risks

To gain a distinction, you must have

… identified the resources, skills and activities, the timely availability of which is essential. Has judged risks appropriately.

Module materials

There are a number of sections within the TM470 module materials that you should look to.

Section 2.5 Risk in project lifecycles: This section relates to the point that the structure of your project may well be driven by risks.

Section 3.2 Risk Assessment: This section encourages you to consider risk in two different ways: impact, and likelihood. There are three different levels of each. A practical suggestion is offered; you might want to think about creating a risk table (which is a bit like a mini risk register). The decision on how you present and summarise your risks is, of course, up to you. It is, of course, dependent upon your project.

Section 3.3 Risk management: This is about how you deal with the risks that you identify. Do you avoid a risk, find a way through, or accept that something is a risk?

Risk analysis

In the TM470 FAQ a fellow tutor, Karl Wilcox, has written about the notion of risk analysis, which extends what is mentioned in sections 3.2 and 3.3. Karl begins with a simple question: where do risks come from? Karl offers some practical advice:

‘One primary source is the list of resources that you need for your project (which is why we ask you to provide one). Since you have identified a need for each of those resources, the lack of any resource will affect your project plan to a greater or lesser extent. Some might be trivial but you should definitely go through all your resources and ask yourself whether each one should have an entry in your risk register or not.

The other main source of risks is "external events". Obviously, you need to be a bit sensible about this and really just consider events that apply specifically to you, so illness, illness of a family member, unexpected work commitments, etc.

Finally, there is a smaller source (that may not be relevant to your particular project) but is there a possibility that some part of your project turns to be impossible? (Or more likely, prohibitively difficult). Do you need to develop new skills? (Another reason we ask for a list of these…) What if it turns out that something just doesn't "click" and you find that skill too hard? Are there any possibly technical or legal or ethical issues that might arise?’ (Wilcox, 2024)

Karl relates a number of potential risks to the different tables that you have been asked to create. For each skill or resource, is there an accompanying risk?

How do we deal with, or mitigate our risks? Karl offers some practical advice, which I abridge for brevity:

‘These [mitigations] can take many forms, from exploring alternatives, adding in contingency time, or sometimes carrying out activities specifically to minimise risk, or at least to bring forward a better understanding of them. … Active steps include things like taking backups of all your work to mitigate the risk of hardware failure, or replacing a laptop that you know to be a bit flaky. If you need input from other people, can you at least get some time in their diaries now, rather than leaving it until later to find out they are not available?

In reality, especially with the limited timescale (and limited personnel resources!) of a TM470 project the most likely response to a risk actually arising is "do fewer things", but again you can prepare for this. Are there parts of your project that you can consider as "stretch" goals, to be achieved if everything goes well but that can be set aside if things go ill? Can you perhaps arrange your plan so that a crude "prototype" of your final deliverable can be developed early, so at least you will have something working if things fall apart at a later stage?’ (Wilcox, 2024).

Karl’s comments about ‘stretch goals’ is both interesting and useful. Another way to think of this is in terms of what a ‘minimum viable product’ might look like. Here we can see an implicit link between the project model and risk. For example, if things do go ‘ill’, we may well wish to curtail a final iteration (if we adopt an iterative lifecycle, of course).

It is worth noting that Karl takes all this pretty seriously: 

‘So I don't see the "Risk Analysis" part of TM470 as simply being a "paper" exercise, in which the construction of a risk register listing risks, likelihood, impact and mitigation for a dozen or so factors is presented in TMA01 and then ignored. That may well gain you some of the marks but it can actually be a genuinely useful exercise that will affect what you do and how you do it and give you a much better chance to complete the project to your own satisfaction and gain better marks all around!’ (Wilcox, 2024).

The Risk Register

Following on from Karl’s FAQ, fellow tutor Trevor Forsythe shared a forum post with his TM470 students, outlining what types of information that you might hold in a risk register. His post had been based the PRINCE2 approach to managing risk (PRINCE2, 2024).

Trevor began by writing: ‘this is one of those learning outcomes that is regularly reviewed, and we are looking to see how students assess and manage risk. A quick search of the Internet will identify a number of risk templates either in word or Excel formats. There is no mandated template to use so you will have to identify one that you think works for your project. As an example, a risk register could contain the following …’

What follows is an abridged and edited version of what Trevor shared (which draws on the PRINCE2 original):

  • Risk identifier: Provides a unique reference for every risk entered into the risk register, typically a numeric or alphanumeric value.
  • Date registered: The date the risk was identified. This is helpful with knowing whether the current version of the risk is the one that is up to date.
  • Risk category: The type of risk in terms of the project’s chosen categories (e.g. schedule, quality, legal, technical, learning, hardware). 
  • Risk description: The risk in terms of the cause, event (threat or opportunity) and effect (in words of the impact) e.g. "my hardware could fail and I lose all my software development".
  • Probability impact: It is helpful to estimate the inherent values (pre-response action) and residual values (post-response action). These should be recorded in accordance with the project’s chosen scales.
  • Proximity:  This would typically state how close to the present time the risk event is anticipated to happen (e.g., imminent, within the management stage, within the project, beyond the project). Proximity should be recorded in accordance with the project’s chosen scales.
  • Risk response: Actions to be taken to resolve the risk. These actions should be aligned with the chosen response categories. Note that more than one risk response may apply to a risk. For example "regular backups of software and configurations will be made into a cloud storage system e.g. OneDrive or Dropbox”.

Materials from other modules

Although TM470 is primarily intended to build on your earlier level 3 studies, if you have previously studied TM254 Managing IT: the why, the what and the how, it is worthwhile visiting Block 3, Part 6: Software quality, risk and risk management. In this block, there are three sections which have particular relevance to TM470, which are: Section 3.1 Categories of risk, Section 3.2 Risk assessment, and Section 3.3 Risk management. It is also worth noting that the TM254 module website (which you may still have access to, if you finished studying this module only a few years ago) has an extensive glossary, which defines the terms: risk register, risk mitigation, risk management, risk exposure, risk reduction, and others.

Although risk isn’t explicitly studied in TM353 IT systems: planning for success, it might be useful to review Block 3, Part 3, Part 3 – How to recover from failure: Business Continuity Planning, which includes a Business Continuity Management Toolkit.

Looking forward to the OU postgraduate module, M815 Project Management, sees the link between risk and project planning and management discussed and handled in quite an extensive way. Risk management is, of course, a subject all of its own. 

Summary

Risk can guide not only what is done, but how things are done. In TM470 LO3 indicates that you need to demonstrate your understanding of risk, and how it relates to your project. For the sake of TM470, a practical approach is necessary. It is important to keep things simple (since the project only lasts for a relatively small amount of time), but it is important to make sure that risks are clearly and carefully considered. A practical recommendation: create a risk table, and keep it updated throughout your project. When you get to the end, make sure you reflect on your approach to risk, and what you learnt from it.

References

Association for Project Management (APM) (2019) APM Body of Knowledge. 7th edn. Princes Risborough: Association for Project Management.

Prince 2 (2024) Prince2 wiki: Risk Register. Available at: https://prince2.wiki/management-products/risk-register/  (Accessed 15 April 2024)

Project Management Institute (PMI) (2017) PMI Lexicon of Project Management Terms. Version 3.2. Available at: https://www.pmi.org/pmbok-guide-standards/lexicon (Accessed: 15 April 2024). 

Wilcox, K. (2024) Risk Analysis - what makes a good one?  TM470 FAQ.

Acknowledgements

Many thanks are ended to Karl Wilcox and Trevor Forsythe whose words have directly found their way into this article. Thanks are also extended to the TM470 module team, and the other module teams that are mentioned: TM254 and TM353.

Permalink
Share post
Christopher Douce

TM470: Considering planning

Visible to anyone in the world

When considering planning, I’m minded of a familiar glib phrase: “if you fail to plan, you plan to fail”. When it comes to TM470, planning is really important. Effective project planning is the backbone which holds up your project. Also, a big bit of learning that can come from TM470 is learning about planning, and how to maintain a project plan during the course of a project.

Importantly, planning is mentioned very clearly within the EMA learning outcomes, for example:

LO9. Plan and organise your project work appropriately, and keep systematic records of plans, progress and outcomes.

To get a distinction for this criterion, you must provide evidence that you have: “clearly planned and accurately managed progress in relation to the original plan” and that you understand “what has gone well and what has not gone to plan.”

In the EMA summary, it is suggested that you should provide evidence of your ability to: “plan and organise your project work appropriately, and keep systematic records of plans, progress and outcomes”.

This leads us to some questions: what kind of records do we need to provide, and how do we go about creating a plan?

To begin with, there’s a lot of practical advice within the ‘planning and organising a project’ module resource, which offers a lot of helpful advice and some helpful background information. A recommendation is to get a printout of this.

Your first TMA emphasises planning. This TMA assessment guide suggests that your first assessment should have three main sections: “preparing for and planning your project; the project work; reviewing and reflecting upon your planning and preparation, and project work”. In other words: what you are doing to do, what you have done, and what points you have to share about what you have done.

This is expanded in one of the tables that can be found within the TMA 1 guidance, which offers the following points which relate to planning: 

  • Outline of the major tasks and subtasks within the project at an appropriate level of detail to enable your tutor to assess the viability of your project.
  • Choice and justification of a lifecycle model for its management. Within the context of the chosen lifecycle model, a schedule for completing the tasks and subtasks.
  • An outline of the resources and skills needed and the methods you are considering using, taking into account the risks and how these will be minimised.

What to provide

Your first TMA (as well as your EMA), you need to provide the following:

Choice of lifecycle model: you need to justify what overall project management approach you have chosen. There is a useful resource about this in the module materials. Different projects will necessitate the choice of different models. Choose a model that works for you and your project, and justify your choice. A practical suggestion is to provide a table. Say something about each of the different modules, saying why a particular approach either is or isn’t appropriate for your project.

Table of tasks: Give your tutor a very high level of the things you’re going to do as a part of your project. You could think of these in terms of project phases. Keep it high level. Again, use a table. Give each task a name, a potential start date and end date, and a brief description, providing no more than a sentence. Your choice of project model will help you to form your task table. Your table s will help your tutor (and your examiner) to get a good idea about what you’re going to do to solve your problem. 

Table of resources: The resources you use within your project are important. Although the primary resource is yourself, you may need to get other people involved in your project. If you’re doing an interaction design project, you might need some help with the evaluation of your designs. If you can’t get hold of ‘ideal’ users, you can also use proxy users (such as friends or family members); users who are pretending to be your target users. You also might need to use software tools, or maybe even some cloud computing resources. Like with the tasks, do share everything in a table. Try to describe everything as succinctly as possible.

Gantt chart: Gantt charts are really useful tools. When you have created your task table, have a go to great a Gantt chart for your project. Aim to have two Gantt charts. Create one at the very start of your project, make a copy of it and save it somewhere. When you start work on your project, maintain a Gantt chart to reflect progress on your project. Submit a copy of your chart for your first TMA. When you get to your EMA, submit both your first Gantt, and the one that you have maintained throughout your project. By looking at the one that you had at the start, and one that you had at the end, you will be able to see the difference between what you thought would happen, and what actually happened.

On the subject of Gantt charts, you can create them in different ways. If you are working on a company, you might be able to use of products such as Microsoft Project to help you to plan your project and to create a Gantt chart. Another approach is to make use of an number of Gantt chart templates for Microsoft Excel.

What to do

There is some good guidance about planning within the module materials. In terms of creating a Gantt chart, I recommend that you do, and take account of the following:

  • Record all your TMA cut off dates as milestones. If you’re studying multiple modules at the same time, do put these in too.
  • Do make a note of time that you need to allocate to writing and submitting both your TMAs and your project report (your EMA).
  • Make a note of when you’re going to be on holiday and put these dates on your chart.
  • Make a note of any other non-working time. For example, if there are any family or work responsibilities that need to be attended to, make sure you make a note of them.
  • Begin to record high level tasks, or project phases that match your choice of project model.
  • Within those phases, attempt to break them down to one or more subtasks.
  • Consider the risks that might apply to your project. (There will a blog post about TM470 and project risks. When you get to your EMA, project planning and project risks should go into the same section).

Some accompanying thoughts are: 

  • Do expect to change your plan during the course of your project.
  • Don’t prioritise your plan over your project. If you find yourself spending loads of time on the plan, you might need a simpler plan, or find another way to plan, or choose a different tool.

Some important tip that I share with all project students are:

  • Create a project log. This could be something as simple as a Word document, which has dates for headings. Use this to make notes of what you’ve done. This could only be a few sentences; it doesn’t have to be anything very detailed. You can also use your log to make a note of what you have learnt.
  • Email your tutor regularly, ideally every two weeks, just to keep them informed of what you’re doing. You might think about emailing your tutor sections of your log.
  • When you compile your EMA, you can put a copy of your project log, or emails, or both into an appendix. Doing so relates to learning outcomes LO5 and LO6, where to get a distinction, you need to provide evidence of having “worked under own supervision, communicating regularly and accurately in respect of progress” and “sought guidance when needed, but offered own ideas when doing so”, and “has clearly recognised new skills and knowledge”.

Reflections

When you get to the end of your project and you have to write the reflection section (which accounts for 20% of the overall mark) if you have made a good plan, and have your original plan, you will be able to say something about what went well, what didn’t go well, and what you have learnt about running a project. Of course, you should also be saying something about what technical skills you have further developed too. Although project planning isn’t very exciting, it is pretty important, and it is also important to get on top of it early. One of the jobs of your tutor is to offer you some practical advice about how your plan might be further developed or improved.

Acknowledgements

Many thanks to the TM470 project team who have prepared some very helpful materials on choosing a project model and carrying out a project planning.

Permalink Add your comment
Share post
Christopher Douce

TM470 Choosing a project

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 28 June 2023, 09:01

I’m a tutor for the Open University's TM470 Computing and IT project moduleTM470 is different from most other OU modules, since it is less about learning about Computing and IT concepts, and more about applying what has been learnt. 

When I was a computing undergraduate, I had to write a dissertation. I had to identify a problem, do some background reading, figure out what I needed to do, go ahead and do what I needed to do, and then write everything up. TM470 asks you to follow a similar process, whilst offering some helpful guidance.

One of the most important decisions that has to be made is choosing a project, or identifying a problem that you want to solve. 

This blog has been written for TM470 students, and aims to share some useful advice and pointers to help you with the process of choosing a project. This post accompanies earlier articles that I have written relate to TM470, which can be found by following my TM470 blog tag (OU blog). The articles about Understanding the literature reviewAcademic writingand the TM470 Project report structure might be helpful.

In essence, the project is all about showing off: showing off how you can use the skills and knowledge you have acquired throughout your studies. It is also about showing off how you’re able to plan. Finally, it is an opportunity to show off what you have learnt from the process of completing a project.

Starting points

Within the resources section of the TM470 website, there is a section called Study Materials. 

At the start of TM470, it is recommended that you have a good look through four different resource sections:

  • Study Guide
  • Project Choice
  • Sample Project Titles
  • Choosing a Lifecycle Model

Defining a project

The module materials shares dictionary definition of a project: “a carefully planned piece of work to get information about something, to build something, to improve something, etcetera.” 

It goes onto mention some of the key characteristics of a project:

  • They are unique – i.e. specific to a particular set of circumstances and not part of routine activity – and would not arise without deliberate intervention.
  • They are planned around a collection of available resources, schedules, budgets, etcetera.
  • They are self-contained around aims and objectives, and it is possible to decide when they are complete, and whether they have been completed successfully.

For TM470, the module team suggests that a project should:

  • identify a problem,
  • be practical or have a strong practical context,
  • have a proposed solution using (or related to) computing and IT,
  • include aspects of planning, evaluation and revision,
  • be broadly based on one or more level 3 computing and IT modules
  • will not be pure research but will extend and apply what has previously been learnt at level 3 to a practical problem.

Types of projects

There are, broadly speaking, three different types of TM470 project:

  • Development projects: involve creating something: processes, algorithms, software, hardware, interface design, etc.
  • Research projects: involve addressing a research question or analysing the possible solutions to a research problem, making detailed recommendations. This typically involves investigating the relevant academic area in depth.
  • Evaluation projects: are sometimes named ‘compare and contrast’. You might compare processes, analyse an implementation, assess different user interactions, etc.

The most popular type of project is the development project. This is where you build something, and then write a report that describes what you have built, and how you have built it. You would, of course, start the building after you have done some detailed planning and shared a detailed summary of all the resources and skills you need to start the project.

Sometimes, projects will not have a clear boundary between each of these categories. A development (or implementation) project might contain bits of research, and also bits of evaluation too. A project that is based on the interaction design module is a good example of this, where you might ask the question “is my design any good?”

Project choice guidelines

Your project should address a non-trivial question. The question should not have an obvious answer, and this means that it should be “reasonably difficult” (but not too difficult). It should ideally occupy the time that you have available, the resources that you have access to, and draw on many of the skills that you already have. 

Here are a set of collated and edited tips from both myself and fellow tutors:

  • Your project should ideally be based around a clear, concrete problem or scenario that needs a solution.
  • Your project must have a clear focus and ideally focus on a specific level 3 modules that have been previously studied.
  • Your project should be sufficiently detailed to allow you to achieve significant depth of analysis and reflection about what you have learnt and achieved during your project.
  • You should not attempt to do too much.
  • You should choose something that enables you to play on your existing strengths rather trying to learn an entirely new skill set.
  • You should choose something that you are interested in; this will keep you motivated. Make sure that you have fun whilst working on your project.

Starting your project

The first TMA is all about setting the scene and sharing your project ideas with your tutor. It is also used to help you to plan what you are going to be doing:

  • Choose (and justify) an appropriate lifecycle module; always ask why you have chosen the approach you have chosen.
  • Create a project plan and include this in the TMA (and all subsequent TMAs); create a Gantt chart.
  • In your plan, outline very concrete 'deliverables' (including your TMA submission dates), regardless of the type of project.
  • Take time to identify risks: what are they? Write them down and submit them in your TMA.
  • Make notes of what you have read; this can feed into your literature review, and have a look at the OU library to carry out some further research.
  • Write about the resources that you need, the skills that you need, and the skills that you need to develop.
  • Start to think about ethics.
  • Take time to review all the marking grids that are provided with the TMAs: you can almost mark yourself!

Projects connected to your workplace

If you are thinking of basing your project on something that you do in your workplace, there are a number of things that you need to carefully think about:

  • Timing: does the timing of a work-based project align with the timing of TM470? For TM470, you need to go through a complete project lifecycle, from beginning until end.
  • Who is involved: sometimes work-based projects involve teamwork. If this is the case, whatever you do on a work-based project might not be suitable for TM470 for the simple reason that everything that you do, and you submit in your project report must be all your own work.
  • Planning: are you able to do your own planning for the project? If someone else is doing the planning, or deciding on deadlines for your project work, your work-based project might not be suitable for TM470.
  • Complexity: some work-based project address a very small part of a much bigger project. Are you able to choose something that enables you to demonstrate a breath of skills and abilities?

Essentially, TM470 is all about what you do, and what you learn through the process of completing a project. Another way to choose a project is to think about what skills you might like to develop. Only choose a work-based project if all the above criteria can be met.

The degree apprenticeship version: TMXY475

There are two versions of TM470; a degree apprenticeship version, which goes by the code TMXY475, and the non-degree apprenticeship version. Although the aim and structure is broadly similar, TMXY475 has a slightly different focus to TM470. 

Apprentices who are taking TMXY475 have the challenge of identifying a project that aligns in two different ways: it connects with the level 3 OU modules they have previously studied, and also relates to some task or activity which relates to their workplace. Working with their module tutor and line manager, apprentices must choose a project that aims to address a particular business need, or to provide a clear benefit. Their project must also fit within the module timescales.

An important difference is that apprentices will need to not only write a project report, but also to prepare and deliver a presentation about their project.

Reflections

Choosing the right project at the start of TM470 is really important. If it is too simple, there might not be enough to get your teeth into; you need something that really allows you to show off your skills and abilities.

A TM470 must always link back to Computing and IT, irrespective of how technical it is.

Whilst it is often great to see technical skills demonstrated through an implementation or development project, some of the best projects I have seen have been about design. Rather than developing lots of a code, a project might share a series of detailed designs, which are then thoroughly evaluated, by applying the concepts presented through the interaction design module.

TM470 is all about sharing a technical story about what you have done within your project. Within this wider story there will be other stories, such as a story about your reading and what you know (which is presented through the literature review section), and what you have learnt (through the reflection section). 

The key bits of advice I have are: play to your strengths, and try to have fun with it. If you’re having fun with your project, you’re likely to be motivated. Also, do some thorough planning, write down potential risks, and consider the resources and skills that you need to do what you need to do.

Acknowledgements

I would like to thank fellow tutors Chris Thomson and Eleanor Dare, who were kind enough to share some PowerPoint materials which offered useful advice and guidance about TM470 project choice. I would also like to acknowledge the TM470 module team, some of whose words I have creatively shared through this post. I would also like to acknowledge Alexis Lansbury, who is my TM470 line manager.

Permalink Add your comment
Share post
Christopher Douce

Making a TM470 log by using a blog

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 10 Apr 2024, 17:05

TM470 is the Computing and IT project module. The project module allows students to draw on skills and ideas that they have studied and developed during earlier level three modules. It enables students to demonstrate skills across a more substantial piece of work.

This short blog post is basically a bunch of ideas that might be useful for fellow TM470 tutors, but also for any TM470 student (and anyone else who might be involved in a project module).

A really important part of TM470 is the end of project report which summarises everything that has been done. The report requires students to present a description of the outcomes of the project, and what has happened during the project.

The project log

TM470 project can last up to eight months. During that time, a lot can happen. To keep track of things the TM470 module team recommend that students create something that is called a project log. Here’s an excerpt from the module materials that offer a bit of guidance:

"Keeping a project log is similar to keeping a diary. It is a useful aid in helping to manage a project. In a project log, ideally you should make a log entry each time you have a work session.

Whether recorded on paper or electronically, your log is where you keep details at regular intervals of salient events or facts that have occurred in your project. The log differs from your plan in that it provides more detail of things you have done, whereas the plan is a schedule of what you are or should be doing. The log is purely historical information; it can contain facts about your project but probably more important is writing down reflections about what you are doing."

The module team suggests that a log serves three purposes:

  1. They provide a reminder of how your project developed; this will be useful when it comes to writing your TMAs and EMA.
  2. They help you when in discussions with your tutor because they provide a record of how you planned your project, how you managed your time, how you tackled the tasks and how you dealt with any problems.
  3. Using the log sheets on a regular basis will help you to keep to your schedule, and may suggest changes to your schedule. 

Students are told that they should be spending approximately ten hours per week on their project. The project log also enables students to keep track of how much time they’re spending on the project. 

Students are also encouraged to submit excerpts of their blog to their tutor, to keep them informed about how their project is progressing.

The OU VLE

The module team suggests that a log might be recorded on paper, or recorded electronically. An accompanying question is: what form might an electronic log take? One approach is to use a word processing document. You could have a day for every page. One idea is to record a ‘session number’, record a date, record how long was spent working, and also a summary of what was done during that session, and perhaps some thoughts about what the next steps might be. In some ways, this kind of log has parallels to a ‘work log’ that a researcher might keep.

Rather than using a word processing document another idea is to keep a TM470 log in the OU VLE blog.

Every OU student is given their own blog, which is hosted in the university virtual learning environment. The OU blog is useful because it provides a number of useful features:

  1. It allows students to automatically record the date and time of any entry that is made.
  2. It allows students to add ‘tags’ against particular blog entries. A tag, of course, is a useful word that can be used to help find things again. Using the OU blog you can quickly find blog entries with the same tag (in the way that the tag for this post is TM470).
  3. Students can any log entry with other TM470 students, and they can share their TM470 log entries with you. Blogs can be easily shared with a tutor, enabling them to more directly understand progress on a particular project.
  4. The blog can be accessed easily through a web browser: you don’t have to use the same word processing software every time.
  5. The blog is automatically backed up by the university, which means that you don’t have to worry. 

Another feature of the OU blog is that students can choose who sees what is posted. 

The OU blog has three settings: students can keep every blog (or log) post private; this means that a blog can be a bit like a private diary. Another setting is that blog posts are only visible to people within the university. This setting is useful for sharing blog posts to other TM470 students. The final setting is to make a blog post visible to the entire world. In terms of TM470, I personally recommend that this first two options are used.

An accompanying question is: how can students begin to use their blog? The answer is to look for their VLE profile. They will soon find a link that allows them to begin posting a blog.

Note taking advice

Whilst the TM470 module team offers some great advice for creating a log, the university also offers other advice which might be useful too, such as note taking techniques which is available on the skills for study website.

Also, the following three useful points (Making notes strategically) have been adapted from Northedge (2005) from his book The Good Study Guide, p.155:

  1. Take an active and enquiring approach to study. Ask yourself questions, such as ‘what is this about?’, ‘what do I want to remember?’ and ‘what do I want to say?’ and writing down the answers.
  2. Flexibility. Make sketched notes or detailed notes according to need. This can be particularly useful when making note to support creativity. These notes could then be ‘written up’ and used within the project log. Plus, having them in a blog form allows them to be searched.
  3. Reflection. Looking at notes and ask: ‘are they doing the job I want?’ and ‘could I be using my time more effectively?’ Or, put another way: are these the right kind of notes.

Sharing blogs with other students

The best way to share blogs with fellow students is to share links to the blogs in the module discussion forums. Once you have a link to a blog, you can then add it to something called a ‘blog feed’, to receive a notification whenever a new update has been made. Another advantage of a blog is, of course, students will see that they’re not alone; that there are others who have to contend with similar challenges.

Update 10/4/24: a fellow tutor, Karl Wilcox has written an (arguably better) companion article, Thoughts on Project logs, which might be helpful. An important point to note is that this article, and Karl's article are opinions from tutors. Students should always refer to the official module materials for guidance.

Permalink
Share post
Christopher Douce

TM470 New tutor day

Visible to anyone in the world
Edited by Christopher Douce, Tuesday, 22 Nov 2016, 09:46

I first joined The Open University as a part time tutor back in 2006 where I tutored a module called M364 Fundamentals of Interaction Design. Knowing that this module was coming to an end I decided to apply to tutor on another module: TM470 The Computing and IT project, and I was successful!

I was invited to attend a ‘new tutor day’ which took place in the West Midlands regional centre in Birmingham (which is, sadly, closing in the new year) to learn about the ins and outs of tutoring this module. This was also an opportunity to meet my TM470 mentor, fellow TM470 tutors, and some of my colleagues who support the delivery of computing and IT modules from the Manchester and Birmingham offices. This blog post has been drawn from a set of notes I’ve made during the day, which took place on 2 July 2016.

Project choice

I’ve noted down the question: ‘what makes a good project theme?’ It’s a simple question and one that is very important: students must have a clear idea about what the problem is that they want to solve within their project. It should also have sensible limits, i.e. students shouldn’t aspire to creating the next big app for the iPhone.

Successful projects are those that draw upon practical skills that have been learnt (or studied) in previous level 3 modules. A project could also build on something that has been done before. Students should (ideally) be knowledgeable about the domain or environment in which a project relates to (so they don’t have to spend lots of time doing research into an area that isn’t familiar to them). Also, importantly, a project should be connected with something that a student is interested in doing (so they maintain their motivation).

Another bit of advice is: students should stick with using software that they know; don’t be tempted to play with new things, since it’s easy to get tied up in knots.

Sometimes students might be tempted to draw upon projects that relate to their work place. An important point is: work and TM470 have different goals; it is probably best to keep work and study separate for the simple reason that changes at work might jeopardise the project. This rule, however, doesn’t have to apply in all cases: students need to understand what is required from TM470.

Another really important point is: a project doesn’t have to have a successful outcome to submit a final project report. Students can still pass if things go horribly wrong: it is the description of the project, the learning, and the reflections that all count towards the final scores. If these are done really well, students will get a really good pass.

Another note I’ve made is all about research: ‘not really understanding what is meant by research that is academic, or what is meant by an academic literature review (and analysis)’. Some projects may be research projects, in the sense that they are an in-depth and critical study of a particular area. If students choose research projects, the need to be clear in terms of what is required of them. 

Independent learning

TM470 is different to other modules, since what really matters is being able to demonstrate independent learning; tutors will not be subject experts in all the areas in which projects are chosen from. A note I’ve made is: ‘if software breaks, it is part of your job on a project to fix it’. The role of a tutor is to push a student into this mind set.

Practicalities

I made a note that we discussed the importance of the introductory letter, and that we might connect this to the use of our module discussion forum.

A really important resource is the OU Library which allows student direct access to a wealth of prestigious journals. Another thought is to direct students to library tutorials (understanding eJournals) about how they can get started.

The project module doesn’t have any official tutorials, since it is difficult to run group events where every student is working on a different project (and will have different learning needs and problems). This said, some tutors do use OU Live to run some unofficial introductory tutors. 

Towards the end of the day, we discussed practicalities about end of module assessment marking, and assignment marking. Key questions that were asked were: ‘how do you do it?’ and ‘what processes do you use?’ The module has a very clear set of marking guidelines that are also known to the students. Ultimately, everything comes back to the question of whether students have met the learning outcomes.

Reflections from first presentation

Now that I have more of an idea how the module works and how it is structured, I think I will run an introductory OU Live tutorial at the start of the next presentation. This will allow me to learn more about the student’s ideas and understand more about their potential problems. I will also use this to emphasise the importance of time management.

In comparison to other modules that I have tutored on, I found the marking to be pretty straightforward once I knew how it worked. It took me a bit of time to find the forms, and then to internalise the marking criteria (but this is always the case when starting to work on a new module). One of the things that I really enjoyed was looking at the diversity of the projects, and how the students tackled them.

Permalink
Share post
Christopher Douce

Aegis Project : Open accessibility everywhere

Visible to anyone in the world
Edited by Christopher Douce, Wednesday, 21 July 2010, 18:20

Aegis project logo: Open accessibility everywhere - groundwork, infrastructure, standards

I recently attended a public dissemination event that was held by the AEGIS project, hosted by the European headquarters of the company that developed the Blackberry, Research in Motion.

The Aegis project has the strapline that has three interesting keywords: groundwork, infrastructure and standards.  When I heard about the project from a colleague, I was keen to learn what lay hidden underneath these words and how they connect to the subject of accessibility.

The Aegis project website states that it 'seeks to determine whether 3rd generation access techniques will provide a more accessible, more exploitable and deeply embeddable approach in mainstream ICT (desktop, rich Internet and mobile applications)' and goes on the say that the project will explore these issues through the development of an Open Accessibility Framework (or OAF).  This framework, it is stated, 'provides embedded and built-in accessibility solutions, as well as toolkits for developers, for "engraving" accessibility in existing and emerging mass-market ICT-based products'.  It goes on to state that the users of assistive technologies will be placed at the centre of the project.

The notion of the 'generations' of access techniques is an interesting concept that immediately jumped out at me when reading this description (i.e. what is the third generation and what happened to the other two generations?), but more of this a little later on.

Introductory presentations

The dissemination day began with a couple of contextualising presentations that outlined the importance of accessibility.  A broad outline of the project was given by the project co-ordinator who emphasised that the point that the development of accessibility required the co-operation of a large number of different stakeholders, ranging from expert users of assistive technology (AT), tutors, and developers.

There was a general call for those who are interested in the project to 'become involved' in some of the activities, particularly with regards to understanding different use cases and requirements.  I'm sure the project co-ordinator will not be offended if I provided a link to the project contacts page.

AT Generations

The next presentation was made by Peter Korn of Sun Microsystems who began by emphasising the point that every hour (or was it every second?) hundreds of new web pages are created (I forget the exact figure he presented, but the number is a big one).  He then went on to outline the three generations of assistive technologies.

The first generation of AT could be represented by the development of equipment such as the Optacon (wikipedia), an abbreviation for Optical to Tactile Converter.  This is the first time I had heard of this device before, and this represented the first 'take away' lesson of the day.  The Wikipedia page looks to be a great summary of its development and its history.

One thing that is missing is the lack of an explicit link to a personal computer.  The development of a PC gave way to a new second generation of AT that served a wider group of potential users.  This generation saw the emergence of specialist AT software vendors, such as companies who develop products such as screen readers and screen magnifiers.  Since computer operating systems are continuing to develop and hardware is continually changing (in terms of increases in processing power), this places unique pressures on the users of assistive technology.

For some AT systems to operate successfully, developers had have to apply a number of clever tricks.  Imagine a brand new application package, such as a word processing program, that had been developed for the first generation of PCs, for example.

The developers of such an application would not be able to write code in such a way that allows elements of the display to be presented to users of assistive technology.  One solution for AT vendors is to rely on tricks such as the reading of 'video memory' to convert on-screen video displays that could be presented to users with visual impairments using synthetic speech.

The big problem of this second generation of AT is that when there is a change to the underlying operating system of a computer it is possible that the 'back door' routes that assistive technologies may use to gain access to information may become closed, making AT systems (and the underlying software) rather brittle.  This, of course, leads to a potential increase in development cost and no end of end user frustration.

The second generation of AT is said to have existed between the late 1980s to the early 2000s.  The third generation of AT aims to overcome these challenges since operating systems and other applications begin to providing a series of standardised Accessibility Application Programming Interfaces (AAPIs).

This means that different suppliers of assistive technology can write software that uses a consistent interface to find out what information could be presented to an end user.  An assistive technology, such a screen reader, can ask a word processor (or any other application) questions about what could be presented.  An AAPI could be considered as a way that one system could ask questions about another.

Other presentations

Whilst an API, in some respects can represent one type of standard, there are a whole series of other standards, particularly those from the International Organization for Standardization (ISO) (and other standards bodies) that can provide useful guidance and assistance.  A further presentation outlined the complex connections between standards bodies and underlined the connection to the development of systems and products for people with disabilities.

A number of presentations focussed on technology.  One demonstration used a recent release of the OpenSolaris operating system (which makes use of the GNOME desktop system) to demonstrate how the Orca screen reader can be used in conjunction with application software such as OpenOffice.

With all software systems, there is often loads of magic stuff happening behind the scenes.  To illustrate some of this magic (like the AAPI being used to answer questions), a Gnome application called Accerciser was used.  This could be viewed as a software developer utility.  It is intended to help developers to 'check if an application is providing correct information to assistive technologies'.

OpenOffice can be extended (as far as I understand) using the Java programming language.  Java can be considered as a whole software development framework and environment.  It is, in essence, a virtual machine (or computer) running on a physical machine (the one that your operating system runs on).

One of the challenges that developers of Java had to face was to how to make its user interface components accessible to assistive technology.  This is achieved using something called the Java Access Bridge.  This software component is, in essence, 'makes it possible for a Windows based Assistive Technology to get at and interact with the Java Accessibility API'.

On the subject of Java, one technology that I had not heard of before is JavaFX.  I understand this to be a Java based language that has echoes of Adobe Flash and Microsoft Silverlight about it, but I haven't had much of a time to study it.  The 'take home' message is that rich internet applications (RIA) need to be accessible too, and having a consistent way to interface with them is in keeping with the third generation approach to assistive technologies.

Another presentation made use of a Blackberry to demonstrate real time texting and show the operation of an embedded screen reader.  A point was made that the Blackberry makes extensive use of Java, which was not something that I was aware of.  There was also a comment about the importance of long battery life, an issue that I have touched upon in an earlier post.  I agree, there is nothing worse than having to search for power sockets, especially when you rely on technology.  This is even more important if your technology is an assistive technology.

Towards the fourth generation

Gregg Vanderheiden gave a very interesting talk where he mentioned different strategies that could be applied to make systems accessible, such as making adaptations to an existing interface, providing a parallel interface (for example, you can carry out the same activities using a keyboard or a mouse), or providing an interface that allows people to 'plug in' or make use of their own assistive technology.  One example of this might be to use a software interface through an API, or to use a hardware interface, such as a keyboard, through the use of a standard interface such as USB.

Greg's talk made me think about an earlier question that I had asked during the day, namely 'what might constitute the fourth generation of assistive technologies?'  In many respects this is an impossible question to answer since we can only identify generations when they have passed.  The present and especially the future will always remain perpetually (and often uncomfortably) fuzzy.

One thought that I had regarding this area firmly connects to the area of information pervasiveness and network ubiquity.  Common household equipment such as central heating systems and washing machines often continue to remain resolutely unfathomable to many of us.   I have heard researchers talking about the notion of 'networked homes', where it is possible to control your heating system (or any other device) through your computer.

I remember hearing a comment from a delegate who attended the Open University ALPE project workshop who said, 'the best assistive technologies are those that benefit everyone, regardless of disability, such as optical character recognition'.  But what of a home of networked household goods which can potentially offer their own set of wireless accessible interfaces?  What benefit can such products provide for users who do not have the immediate need for an accessible interface?

The answer could lie with increasing awareness of the subject of energy consumption and management.  Washing machines, cookers and heating systems all consume energy.  Exposing information about energy consumption of different products could allow households to manage energy expenditure more effectively.  In my view, the need for 'green' systems and devices may facilitate the development and introduction of products could potentially contain lightweight device level accessibility APIs.

Further development directions

One of the most interesting themes of the day was the idea of the accessibility API that has made the third generation of assistive technologies what they are today.  A minor comment that featured during the day was the question of whether we might be able to make our software development tools and environments accessible.  Since accessibility and usability are intrinsically connected, the question of, 'are the current generation of accessibility API's as usable as they can be?'

Put another way, if the accessibility APIs themselves are not as usable as they could be, this might reduce the number of software developers who may make use of them, potentially reducing the accessibility of end user applications (and frustrating the users who wish to make use of assistive technologies).

Taking this point, we might ask, 'how could we test (or study) the accessibility of an API?'  Thankfully, some work has already been carried out in this area and it seems to be a field of research that is becoming increasingly active.  A quick search yields a blog post which contains a whole host of useful resources (I recommend the Google TechTalk that is mentioned).  There is, of course, a presentation on this subject that I gave at an Open University conference about two years ago, entitled Connecting Accessibility APIs.

It strikes me that a useful piece of research to carry out is to explore how to conduct studies to evaluate the usability of the various accessibility APIs and whether they might be able to be improved in some way.  We should do whatever we can to try to smooth the development path for developers.  Useful tools, in the form of APIs, have the potential to facilitate the development of useful and accessible products.

And finally...

Towards the end of the day delegates were told about a site called RaisingTheFloor.net (RTF).  RTF is described as a consortium of organizations, projects and individuals from around the world 'that is focused on ensuring that people experiencing disabilities, literacy problems, or the effects of aging are able to access and use all of the information, resources, services and communities available on or through the Web'.  The RTF site provides a wealth of resources relating to different types of assistive technologies, projects and stakeholders.

We were also told about an initiative that is a part of Aegis, called the Open Accessibility Everywhere Group (OAEG).  I anticipate that more information about OAEG will be available in due course.

I also heard about the BBC MyWebMyWay site.  One of the challenges for all computer users is learning and knowing about the range of different ways in which your system can be configured and used.  Sites like this are always a pleasure to discover.

Summary

It's great to go to project dissemination events.  Not only do you learn about what a project aims to achieve, but sometimes the presentations can often inspire new thoughts and point you toward new (and interesting) directions.  As well as learning about the Optacon (which I had never heard of before), I also enjoyed the description of the different generations of assistive technologies.  It was also interesting witness the various demonstrations and be presented with a teasing display of the complexities that lie very often hidden amidst the operating system of your computer.

The presentations helped me to connect the notions of the accessibility API and pervasive computing.  It also reminded me of some research themes that I still consider to be important, namely, the usability of accessibility APIs.  In my opinion, all these themes represent interesting research directions which have the fundamental potential of enhancing the accessibility and usability of different types of technologies.

I wish the AEGIS project the best of luck and look forward to learning more about their research findings.

Acknowlegements

Thanks are extended to Wendy Porch who took the time to review an earlier draft of this post.

Permalink
Share post

This blog might contain posts that are only visible to logged-in users, or where only logged-in users can comment. If you have an account on the system, please log in for full access.

Total visits to this blog: 2309423