Lessons Learned

  • Technical issues with the APIs upon which the project relied caused some delays, but it would have been impractical to have done a complete functionality audit during the bidding phase. In retrospect we would have benefited from structuring the development work in such a way as to build in contingency for this kind of problem solving, and also included a work package that could be achieved if the contingency development time went unused.
  • As a result of the open development approach that we took, we tasked ourselves with implementing interface usability requirements at the same time as implementing code that was simple for developers to reuse in other development projects. This brought to the fore the oft-cited (for example here: http://jonoscript.wordpress.com/these-things-i-believe/) observation that open source development practices do not often deal gracefully with usability concerns. In the case of this project’s outputs we feel that we managed to address both usability and reusability within an open development environment. The project team intends to look more closely in the future at how best to generalise the lessons learned to help reconcile general open development methodologies with diligent usability design and implementation more easily.
  • We had greater success in engaging interest in a more general software community space (Apache Wookie) than we did in engaging interest in the smaller academic communities that were the focus of the bid. It may be worth exploring the idea that software development to benefit the UK HE/FE community or a subset of that community might nevertheless benefit from being initially pitched into the widest applicable global project. From there, it may be easier to gain external developer support, achieve sustainability and thereby gain the time needed to properly engage the narrower academic community’s requirements.

PDF of edited blogs posts

Measures of success

In our project proposal, we set forth three criteria for judging success of the project: i) acceptance by users, ii) uptake by three specific communities and iii) acceptance into upstream projects.

i) Acceptance by users during our three user evaluation activities

We planned three face-to-face user evaluations, but for time and organizational reasons were able to hold only two. We received a great deal of positive feedback and useful advice in both events. The specifics and outcomes are recorded on the project’s Google Code web site and are linked to from the Usability Evaluation Plan here:


While most of the feedback was positive, outstanding usability issues were raised and these were recorded formally within the issue tracking systems associated with the software, both in the Rave in Context project site and in the Apache Wookie site. We feel that this method of finishing a relatively short project by recording and transitioning outstanding suggestions and requests greatly facilitates the ongoing life of the code, and indeed some of these issues have been resolved since the formal completion of the project.

ii) Uptake of our widgets by users of myExperiment, Simal and openDOAR

Although we have made contact with the communities associated with the projects whose functionalities we were seeking to generalise in producing the Rave in Context templates, the templates themselves have yet to receive significant uptake by any of those communities. To some extent our work has influenced work that was already taking place within MyExperiment to refine the user interface with particular reference to mobile access. Although we were unable to initiate extensive contact with OpenDOAR during the life of the project, we will continue to keep them informed of the ongoing development of our code. In the case of Simal, technical issues meant that in order to test the widgets functionality in a timely fashion we had to integrate them instead with the JISC’s project management registry PIMS. The fact that this was successful indicates that use of our widgets within Simal is entirely possible, because Simal similar to PIMS in that it records and displays data about software projects. We are keen to pursue this further in the future.

To some extent these issues can be attributed to the fact that it is still ‘early days’ and therefore too soon to assess the impact of Rave in Context. The ongoing support of our code within the Apache Wookie project should ensure that the code is available for those communities, and for reuse in other research-driven web sites, going forward.

iii) Acceptance of our templates and recommendations into upstream projects

Here we have achieved more uptake in a shorter time than we expected. The widgets have been enjoyed further refinement and expansion by the Apache Wookie development team. Indeed, they will be used in an ongoing project to replace the administrative interface to Wookie itself. The aim of this project is to standardise the interface across Wookie and another widget server project, in an interesting reflection of the aims of our project. They have also been adapted to create a widget for accessing Twitter, and will shortly be adapted to provide access to Facebook. The widgets are also to be used as a basis for the onward development of the MAAVIS (Managed Access to Audio Visual and Information Services) software developed at the University of Sheffield. Finally the Wookie team has also enhanced the templates to produce widgets that have no dependency on Wookie itself, thus making the templates useful in a broader range of use cases, such as being served from other widget servers and compiled into native mobile applications using development toolkits such as Phonegap.

Project Recap

The Rave In Context project has created W3C widgets and widget templates that provide a user interface to common functions of the MyExperiment, Simal and OpenDOAR web sites. We concentrated on usability and reusability, both in two distinct senses: the interfaces themselves needed to be simple and effective for users to make use of across a range of client devices, and the code which presented the interfaces needed to be simple to use and reuse for downstream developers.

By providing useful templates for common interfaces across devices, we hoped to contribute to reducing the learning overhead required to access complex functionality on research-focused sites. As well as reducing the overhead of learning many different interfaces, providing templates can also facilitate the building of unified means of access to multiple research-focused sites. Finally, by providing templates that encompass best practice in usability it will be much easier for template users to provide this best practice in their own widgets.

We adopted an open development methodology to achieve this, starting a project on Google Code and placing the code and our reports there as the project proceeded. By doing this we hoped to make what we were doing as transparent to observers as possible. We also believed that the process of interacting via open development methodologies would ease another important aspect of completing the project: the transitioning of both the code and its development status and history into a live third party open source project at completion.

As with any project, there were some unanticipated departures from our original plan. Staff changes within OUCS meant that management of the project moved from Sander van der Waal to Rowan Wilson, with a concomitant overhead in transferring knowledge and planning. In addition some staff timetabling issues meant that work on the usability strand of the project began later than was originally envisaged. As we proceeded, we also experienced what would probably be best characterised as cultural difference between the practices of the usability community and the software development community. This again highlighted the distinction drawn above between the use that users make of code and the use that developers make of code.

Finally we encountered problems with the uniformity and functionality of the APIs which we sought to connect across the projects. It would have been difficult to have predicted these at bid stage without an impractical time investment to fully test the implementations of the APIs’ feature sets. As a result we had to simulate some aspects of the operation of the widgets during usability testing.

Despite this, all the templates were developed, tested and completed on time, and all the reports were produced, including two user experience reports for the Usability UK website. Engagement with the communities around the various academic projects in the JISC Usability and Learnability programme was less active than we had hoped, although we acknowledge valuable input into accessibility considerations provided by EA Draffan of the ALUIAR project. This low level of engagement with the programme was to some extent mitigated by the much greater than expected uptake and use of the templates in the software project (Apache Wookie) to which we contributed. This in turn means, we hope, that the templates will continue to improve and that they will remain up to date and available for use both within the academic community and without. Indeed, ten template-related issues have been worked on within the Apache Wookie project since Jan 1st 2012 – by developers other than team members from this project:


Reusable widgets demonstrating the potential of open innovation

The Rave in Context is developing templates to easily write W3C widgets that encompass best-practices in usability and accessibility out-of-the-box. It is not feasible or useful for small projects like this one to try and develop a completely new community around the software. Instead, we looked for an existing project that would be a good home for the software and found that in Apache Wookie (Incubating). However, the project is also closely related to Apache Rave (also Incubating), because this project also supports the W3C widget standard and a few people involved with that project have shown an interest in what we’re doing.

Because of the close connection with these Apache projects and for the benefit of wider uptake of our project code, we thought it would be good to present about the Rave in Context project at ApacheCon 2011 in Vancouver. I was happy to be allocated a session in the ‘Fast Feather’ track, a track that focuses on latest developments and upcoming technologies.

The widgets that are being developed by the Rave in Context project will conform to the W3C widget standard. This allows for deployment in a W3C widget container such as Wookie. However, there are many other standards in the widgets and gadgets space. Another popular one is the OpenSocial gadget specification, which defines not only social concepts but also the packaging and specification of the gadgets themselves. Because of the big overlap between W3C widgets and OpenSocial gadgets, it has been relatively easy for the Rave project, that started of as an OpenSocial container, to also support W3C widgets. This makes the Rave in Context widget templates useful for that community as well.

During the presentation and some of the other talks and meetups at ApacheCon, it became clear that there is a lot of interest in the gadget/widget portal functionality that is being developed by the Rave project. Also the gadgets and widgets that are being developed may themselves be interesting to the wider community. We talked to a few people, for example, that have worked with portals based on the Java portlet specification, and are finding that this is not a specification that is suiting their needs anymore. They are looking to use a different technology for their front-end portals and the Rave portal is an option they’re considering. Also a project like Sakai OAE (f.k.a. Sakai 3) are working with gadgets and gadget repositories on their front-end. They are currently not working with a gadget standard, but moving to OpenSocial and using Rave as their front-end is something they are interested in.

The code of all the gadgets and widgets are currently scattered around the different projects, and this is not usually the best place for this kind of code. Hence, there is a clear need for a separate project to host the gadgets and widgets created, and this can also include the widgets created as part of the Rave in Context project. Although this is out of scope for the Rave in Context project, there are plans to set one up at the Apache Extras site, which is a code hosting site specifically for Apache-related projects. This will enable anyone to reuse widgets and/or gadgets generated in any of the projects, thereby delivering on the promise of open innovation in software.

Real open development in action

Ross Gardler, lead developer on the project, reports:

I discovered an issue: Wookie doesn’t pass cookies from widgets to remote servers, which means we can’t log in to MyExperiment. I reported the issue to the Wookie project and got on with doing stuff that didn’t require login, intending to go back to this issue later.

In the meantime, a new community member on the Wookie project sent a mail identifying the same problem. I pointed him at the issue and discussed how it impacts users in the hope someone has time to fix it our find a workaround.

Two days later Scott Wilson committed a fix for the problem.

In summary, by taking the time to collaborate in a viable community I’ve reduced the work I need to do.

Why did Scott do this? Well, whatever the reason, we are all better off thanks to his efforts, including both the Rave in Context and Wookie projects.

Open Development is more than just the reuse of open source code. It is also a sharing of expertise and the appropriate application of resources.

Ross has already thanked Scott on the Wookie list; this is a public thank-you from the rest of the Rave in Context team as well.

Evaluation findings prompt a reassessment of our assumptions

This is a somewhat belated post on the usability evaluation of our UI mock-ups which we conducted in mid-September. The evaluation was intended to:

  • Appraise the proposed form designs for tablets and smartphones for (i) layout and readability and (ii) flow;
  • Appraise the proposed functionality in terms of its usefulness: are the actions to be supported ones that users would want to perform on a mobile device?

Using iMockups, a low-cost prototyping tool for the iPad, we created mockups of all the forms for two form factors: the iPhone (representing smartphones) and iPad (representing tablets). We then walked through the forms with five individuals, who among them represented expertise in the following areas:

  • Use of myExperiment or another collaborative research tool;
  • Experience in using a range of apps on mobile devices;
  • Use of a website for professional purposes that has a strong social-network component (e.g. LinkedIn);
  • Knowledge of good practice in usability in general;
  • Knowledge of good practice in accessibility.

We had prepared a list of questions relating to aspects of layout and functionality which had proved problematic to design, but also allowed the participants to give their impressions freely.

Participants’ feedback was fed directly into a redesign of the UI and a revision of the final UX requirements document which we passed to the development team. However,  the evaluation caused us to reappraise the rationale underlying some of our original design decisions, which we note here:

Nature of the activities carried out on each form factor:
The UX design requirements envisaged variations in the likely scenarios of use on desktops, tablets and smartphones, as follows:

‘A researcher who uses myExperiment from a desktop computer, a tablet and a mobile device is likely to perform different tasks in each environment. The desktop might be most commonly used for executing workflows and analysing results, a tablet might be commonly used in meetings to search for and present available resources, and to make minor modifications to existing materials, while a mobile phone might largely be restricted to social activities such as monitoring the activity streams of friends and groups.’

Feedback from the evaluation suggests that this is not necessarily the case: people use smartphones for more demanding tasks than one might expect, and so the differences between form factors specified in the first version of the UX Design Requirements document have been considerably ironed out.

‘Real estate’ on screens:
The simple inability to display very much on a smartphone led us to omit certain items from the smartphone UI, including the option to display a full-size image of a workflow. However, feedback from the evaluation suggests that people are willing (even happy) to scroll around sizeable graphics on their smartphones. We have therefore made smartphones display the same data as tablets, but have included the file size of the larger images so that users can decide whether or not to view them.

Technological limitations:
Issues associated with the robustness and speed of networks led us to reduce the functionality available on smartphones. However, feedback from the evaluation suggests that this less of an issue than the usability literature led us to expect: smartphones are often used with wireless networks, and people are willing to wait a reasonable time to access or download something which they know they want and which will be useful to them.

Horizontal swiping and fat finger syndrome

…are just two of the topics covered in Jakob Nielsen’s latest Alertbox article, Mobile Usability Update, hot off the (virtual) press.

Noting the overall improvements in mobile usability since his first report two years ago (although I’m unsure whether it’s a good thing that the number of guidelines has increased from 85 to 210), Nielsen singles out Android apps as being markedly better  – a sign, he suggests, of a growing attention to quality resulting from an increase in market share.

A mobile app still tends to be superior to a mobile website – but in the case of the Rave in Context project, we don’t have this luxury, as we want to develop a single set of widgets to run across a range of devices and form factors.

So, what guidelines have we gleaned in particular? Well, I have just emailed these two to our development team:

Horizontal swiping:

‘Swiping is still less discoverable than most other ways of manipulating mobile content, so we recommend including a visible cue when people can swipe, or they might never do so and thus miss most of your offerings. Also, you should avoid swipe ambiguity: don’t employ the same swipe gesture to mean different things on different areas of the same screen. This recommendation is the same for mobile phones and tablet usability, showing the similarity between these two gesture-based platforms.’

Fat-finger syndrome:

‘…we still see users struggle to hit tiny areas that are much smaller than their fingers. The fat-finger syndrome will be with us for years to come…’

Usability in Context

‘The phrase “mobile usability” is pretty much an oxymoron. It’s neither easy nor pleasant to use the Web on mobile devices’ (Jakob Nielsen, Mobile Usability: Alertbox, 20/07/09).

Thus usability guru Jakob Nielsen throws down the gauntlet to the designer of a mobile app: how to get it right, so that your future users can do the tasks they need in the brightest sunlight, at the top of the highest mountain, in the far reaches of the taiga or in the loudest tropical thunderstorm – in short, accommodating all manner of environments and connectivity?

However, that’s only one of the usability challenges confronting the Rave in Context project. As Sander noted in his previous post, we are creating usable templates – patterns/models – for other developers to apply to specific contexts. We’re doing this by developing widgets based on the functionality of a specific VRE (myExperiment), which will ultimately be decontextualised into the templates. Therefore, we are not only working at one remove from our ultimate users but also, in designing and evaluating the user experience in myExperiment, we have constantly to ask whether the features that make the widgets usable by myExperiment users will be translatable, via the templates, to other – as yet unknown – tools. It’s this aspect that makes the project so intriguing from the usability perspective.

The process by which we are tackling this twin usability challenge is being documented in the Evaluation Plan on the project wiki, but I’ll summarise it here.

Scoping the usability problem space

The first task was to establish the usability ‘problem space’: specifically, our baseline definition of usability and its associated concepts:

  • Learnability: How easy it is to learn to use the app?
  • Ease of use, or throughput: How easily and efficiently can users perform their tasks with the app?
  • Usefulness: To what extent does the app supports the purpose for which it is intended: i.e. can users do what they want/need to do in it?
  • Affective response: Do users like using the app?
  • Memorability: how easy it is to re-familiarise oneself with the app after a period of non-use?
  • Flexibility: to what extent has the app has been designed such that it can accommodate changes in the tasks that users do?

Aspects of usability on which our evaluation activities with users are focusing are: learnability, usability and usefulness. Users’ affective response will also be captured, but it can be expected to flow, in part, from data collected in relation to the other factors. Flexibility, in the sense of i) adaptability of the code to support different form factors and ii) adaptability of the templates for use with other tools, can only be evaluated internally by the open-source developer community.

From concepts to prototypes

The next step was to conduct a Web search for literature on usability issues relating to mobile applications, which happily revealed an emerging consensus among developers regarding good UI design practice. Combining the guidance most relevant to our needs with established principles of usability (guided largely the work of Jakob Nielsen), we collated a set of general guidelines for designing the widget UIs (which is also published on our wiki). These, in turn, informed the compilation of a set of detailed requirements for the user experience.

From the UX requirements we have produced a set of paper mock-ups, which we are currently evaluating through cognitive walkthroughs with five individuals. Each participant has been selected for their expertise in at least one of the following areas: usability, mobile app design, accessibility and the use of research tools with a Web 2.0 dimension. On Thursday 15th September we visited E.A. Draffan of the ALUIAR project at the University of Southampton, who, in an energising conversation, set us right on several matters of accessibility (thank you, E.A!).

Where next?

We will complete the evaluations and modify the UI designs over the coming week. Unfortunately, resource constraints are preventing us from carrying out our original intention to evaluate digital versions of the revised designs with users. Instead, beginning in the last week of September, we will be conducting a rolling internal evaluation during the development process (which is following an agile methodology). Our final evaluation will be a workshop with potential users in the first half of November: details to follow.

Towards a more usable and accessible web, one template at a time

There are very many mobile devices and more are coming out each month. Similarly, the diversity of form factors is growing; there are many different screen sizes for example and a larger variety in device capabilities. People want to access and use their favourite research tools on these devices, but this is currently very hard. You could create an app for your research tool, but then again you’d have to create a different app for each platform and still have to take device capabilities into account, especially on a platform like Android.

A better approach could be to build a web application. Harnessing the possibilities that HTML5 offers, it is possible to create web-based applications that look and feel very similar to native applications. In the Rave in Context project we will focus on creating web-accessible W3C widgets for the popular e-Science tool myExperiment, but we will also create widgets for OpenDOAR and Simal. This will allow researchers to have a usable interface to these research tools and use them on a variety of devices. By using the W3C widget standard it will be possible to embed the widgets in popular widget-enabled tools such as Drupal, WordPress, Elgg and Moodle.

To make sure the widgets are usable on the different devices with their specific form factors we will use a technique called progressive enhancement to dynamically match the features of the device that is used to access the tools. This technique adapts the user interface based on the features of the device.

We will make prototypes and perform a walkthrough with users of the myExperiment community to determine what the most usable design is on each type of device. By working with an accessibility expert on the team we will make sure the design is not only usable and learnable, but accessible as well.

We will make sure that the results of our research and development are reusable by building widget templates where we will base the myExperiment, OpenDOAR and Simal widgets on. Using these templates will enable other research tools to create usable, learnable and accessible widgets for their own tools easily. We will work with the wider research community to aim for a wider uptake of these templates. We are already working with two projects, Apache Wookie and Apache Rave (both incubating), that build servers to host widgets and gadgets. We will work with those communities to make it easier to integrate widgets in existing widget portals.

We hope you’ll find our work in creating widget templates useful. Please follow us on Twitter and subscribe to our mailing list. We look forward to hearing from you!

Rave in Context Project Plan

Aims and Objectives

The Rave in Context project will build a new user interface for the popular eScience tool myExperiment. Our new interface will focus on usability, accessibility and adaptability to user experience and device form factor. Furthermore, we will build a uniform search feature across myExperiment, Simal and OpenDOAR repositories in order to make it easier for researchers to learn how to use these research tools together. All user interface components will be delivered as reusable W3C Widgets, allowing features of myExperiment to be embedded in other widget enabled tools such as Drupal, WordPress, Elgg and Moodle. We expect the ability to embed discrete units of myExperiment functionality in common dissemination tools will help myExperiment expand its user community. Finally, by providing open source widget templates for progressively enhanced user interfaces we intend to make it easier for future projects to build similar user interfaces.
The overall objectives of the project are to:

  1. Build new progressively enhanced , usable, accessible, learnable and adaptable user interfaces for myExperiment, an e-Science tool for building communities to find, use and share scientific workflows and other research objects.
  2. Demonstrate how, by adopting a W3C Widget-based user interface, features of myExperiment can be embedded within other tools, and features of other tools can be embedded within this new interface to present a consistent user experience (UX).

The areas of functionality within myExperiment for which we are building and evaluating widgets are:

  • Account creation
  • Finding workflows
  • Sharing workflows
  • Creating and finding packs
  • Finding people and making friends
  • Creating, joining and monitoring groups

To demonstrate progressive enhancement, we are developing the widgets to run on two broad, overlapping classes of platform: smartphones and tablets.

Success criteria

The success criteria defined in the project proposal are:

a) Acceptance by users during the user evaluation activities conducted within the remit of the JISC-funded Rave in Context project. This is considered an initial approval of the user interface approach implemented in the widgets;

b) Uptake of the widgets by users of myExperiment, Simal and openDOAR. Since each widget will be operational independently of all other widgets, the developers hope to see users embedding appropriate widgets in their chosen dissemination tools, such as blogs;

c) Acceptance of the templates and recommendations into subsequent open-source projects. This will indicate approval from a broad community seeking to reuse the work of the Rave in Context project.

Criteria b) and c) are primarily technology-driven; however, for the widgets to be taken up by projects they need to be demonstrably usable by their target audience – researchers who share their workflows and maintain a professional social network within a virtual research environment (VRE) – as well as usable (in terms of quality and readability of code) by the OS development community. The usability evaluation that will be conducted with by the project’s usability specialist, therefore, is almost wholly focused on criterion a).

It is important to emphasise that we are not developing mobile versions of myExperiment itself: this has been done to some extent by the development team (e.g. an Android app and a Silverlight mashup). Rather, we are using certain functions within myExperiment as the basis for developing templates for widgets in specific areas of functionality that can then be customised and applied to other, similar, applications.

Equally, we are not seeking to redesign the desktop browser version of myExperiment; instead, we have used it as the baseline for deciding on the cut-down features and functionality that will be supported on the mobile devices through the technique of progressive enhancement.

Even though the developers of myExperiment report that they have designed the UX in close conjunction with users, and have subjected it to usability evaluations, a brief review of the application from the perspective of good usability practice leaves much to be desired, and it is questionable whether less IT-minded researchers outside the core community of scientists would find it particularly learnable or usable. Therefore, although consistency of look and feel across platforms is a desideratum of usability, in developing and evaluating the widgets consistency with the current interface is secondary to overall usability.

However, we have to be mindful of the desktop browser version as a ‘concept’: e.g. it is good usability practice to refer the user to the full desktop version if they wish to avail themselves of functionality that is not available in the mobile web version, even though, for reasons just explained, we will not actually do so.

For more details please see the project’s Google Code site.

Project Team

Liz Masterman has an MSc in Human-Centred Computer Systems from the University of Sussex and a PhD in Educational Technology from the University of Birmingham. She is currently a senior researcher in the Learning Technologies Group. Liz has 14 years’ experience in conducting usability and pedagogic evaluations of software for learning and teaching, and since 2004 has participated in a number of JISC projects in the Design for Learning and Learner Experiences of E-learning programmes. Liz will lead the usability work, conducting the initial review of literature and current practice, running the evaluation workshops and assisting with the design of usable and learnable user interfaces.

Steve Lee has both a passion for and experience of, combining open development and accessibility in order to bring the benefits of innovation and user engagement to those with specific accessibility needs. He is actively involved in several key accessibility communities, including Mozilla, GNOME, OATSoft and Project:Possibility, and has developed wide experience with many contacts in the field. He will address the accessibility aspects of our designs, evaluating each design and assisting in the continual improvement process. Steve will also liaise with TECHDIS and the REALISE project community.

Ross Gardler is senior consultant at OpenDirective. Ross was previously manager of OSS Watch and is Vice President of Community Development at The Apache Software Foundation. He is a committer on many open source projects, including Simal, Apache Wookie and Rave projects used here, and is listed in the top 0.5% of the world’s open source contributors at Ohloh (www.ohloh.net). Ross, will be responsible for the design and implementation of all the widgets and templates and will liaise with the upstream projects to ensure our code is maintained in the long term.

Rowan Wilson has been involved in web development using a variety of CGI languages since 1996. He was the co-creator of the earliest fully automatic domain-name ordering, DNS setup and virtual-server allocation software deployed by a UK ISP (FDD), using a combination of Apache-SSL, Sendmail, Perl and Bind. Since then he has developed web-based internal product management systems for the ISP Netscalibur, again using open source software (Postgres, Perl, Apache). He now works within the Research Technologies Service of Oxford University Computing Services.

Timeline and Work Packages

For details of the timeline and associated work packages please see the project’s Google Code site.

Risk Analysis

Risk P S P x S Action to prevent/manage risk
Lack of stakeholder engagement 2 5 10 Careful design of workshops with invited participants to cover a range of people and needs.
Widget template code refused by upstream projects 2 5 10 Ross Gardler is a committer on each of the upstream projects and will champion all code contributions. If donations are rejected, a new project will be created at http://www.apache-extras.org where we will document the reasons for rejection and encourage contributions to resolve these issues.
Widget implementations not accepted by host projects 3 2 6 The Outercurve Foundation Research Accelerator would make an ideal alternative home. Should they also reject our code, we will create a project on http://www.apache-extras.org and release the code under the open source Apache Licence v2.
Technical problems with projects not under our control 2 3 6 Project members are committers on most of the projects involved in this project and are therefore familiar with the limitations of each platform. In the event of unexpected difficulties we will reduce the scope of our final code deliveries and focus on the usability and accessibility aspects of the project, delivering robust templates and recommendations.