User Interface / User Experience

After our final presentation of our project to our clients, we can confidently say that our user interface is a strong point of the product. Their core UI requirements for the split pane view, match case and match regex toggles were all implemented well, and we based our UI off their existing solution to ensure that the team can easily familiarise themselves with the new tool. We made use of colour theory to ensure that the randomly generated colours for highlighting were selected such that they were easy on the eyes, and this was a feature appreciated by the clients.

Functionality

All of the core functional requirements were completed, and our clients were very pleased with the result. The customisable filter groups feature, in particular, was built to their expectations, and was merged within their production codebase the earliest, so we got to have feedback of several Cisco engineers using it, which was overall very positive. We have extended on the core requirement by making all of their static filters editable too, which further enhances the customizability and flexibility of our tool. This was also met with positive user feedback, empowering them to adjust filters in real-time and tailor the experience to their specific needs.

However, the functionalities are not without room for improvement. As part of our experimental features in our prototype, we added asynchronous and incremental filtering which we believed was the ultimate feature that improves snappiness and responsiveness of filtering. But unfortunately, as has been made clear by our clients, adding this to the existing codebase would have proved extremely challenging requiring major code refactors. Perhaps if we had access to the repository a bit earlier than only 1 month prior to the deadline, we might have made progress towards this feature as well.

Efficiency

Efficiency has been a key requirement that has been at the forefront of all the features that we have implemented in the log viewer. We have ensured responsive and efficient loading of log files through asynchronous programming. The technologies that we decided to use for the backend, namely elasticsearch, was due to its high speed processing of log files. We have also created caching techniques to store previously computed RegEx patterns, so that they are not recompiled. We have also created efficient custom data structures for faster retrieval of previously searched substring/regex patterns.

Compatibility

We have built a highly compatible product. Cross compatibility with multiple devices is one of the core requirements established from the beginning. The issue with Cisco’s current call-tracker app is that it is a downloadable app, rather than a web-app which has a much easier accessibility. Therefore, we went down the web-app route, to make this log viewer compatible across a range of devices. We even chose an online LLM Agent as offline ones can be OS native, whereas online models such as ChatGPT are machine agnostic.

We might have been able to achieve full compatibility with offline models as well if we had more time. Unfortunately, llama.cpp, the inference code we used for our offline mode, has compatibility issues running with accelerated hardware in Windows & Linux, and that’s why we have disabled offline AI by default. If we had experimented with other inference tools such as ollama, we might have achieved compatibility with this part of our project as well.

Maintainability

We have strived to ensure a high level of maintainability through good coding practices. Since this project will be merged into a production environment, and will likely be built on further by Cisco’s engineers, we had to ensure that our code adheres to their standards. We made sure to create detailed documentation too, so that the engineers at Cisco will be able to easily understand the code.

Project Management

Throughout the project, the team made good use of agile techniques and demonstrated strong collaboration.

Communication was open and frequent, both during scheduled meetings and through daily interactions on messaging platforms. This helped maintain momentum and allowed quick adjustments when project requirements shifted. The use of agile principles like iterative development and continuous feedback helped ensure that deliverables stayed aligned with stakeholder expectations. Each week, we presented our latest developements, and made a detailed todo list for the features that have to be developed/modified for the upcoming weeks.

We made effective use of GitHub issues and PRs to track the tasks that we had to do and task assignment. Our communication with the clients was done on WebEx chatrooms, which was very useful as the material & documentation was all in one location. We discussed with our clients the tools that we can use to track tasks, comparing products like Jira, Kanban etc. We wanted our workflow to align with Cisco's as much as possible, therefore, we used GitHub and WebEx as the main forms of communication.

Finally, we also studied and aimed to enforce good Git principles throughout the project. This included maintaining a clean commit history, writing clear and descriptive commit messages, and following a consistent branching strategy to avoid conflicts and maintain code quality. Feature branches were used to isolate development work, and pull requests were reviewed by team members to ensure code quality and encourage collaboration. We also made use of `.gitignore` to manage unnecessary files and avoided committing sensitive or temporary data.

However, there was room for improvements too. At times, sprint goals could have been more clearly defined, which occasionally led to scope creep or misaligned priorities, such as putting too much emphasis on the frontend instead of ensuring certain functionalities. Another issue was in the delay that we had in gaining access to Cisco's repository. Some team members also got access to the repo faster than others, resulting those team members being further along the developement process.