PACT Analysis
People The video player design will be targeted towards outdoor enthusiasts who have large video libraries from a variety of different locations. Outdoor enthusiasts are of any age but tend to be of a younger generation due to their improved physical abilities. As a result, they are likely to be fairly knowledgeable on technology but that cannot be assumed and enough pointers explaining what to do would be helpful. The video player will be targeted to those speaking English as that is the language we speak in our group, but translations are possible and there should be enough icons to ensure someone with just a basic knowledge of English can use it. Accessibility features should also be considered for those who are hard of hearing or sight.
Activities
The goal of this video player as a whole is to allow outdoor enthusiasts to watch the videos they shoot on their mobiles, Go-Pro or drones etc. How often they use the program entirely depends on how often they shoot their videos. As this could be fairly infrequent, it’s important to make sure the basic tasks of the video (such as uploading, pausing, muting, etc.) are straightforward and self-explanatory or else the users may forget between each usage. The most likely use for the video player is opening the app, watching the videos then closing the app down again without much continuous usage. As a result, don’t believe our time is well spent ensuring users can ‘find their place’ again, especially since it is also quite easy for the user to do that themselves without any need for caching. The length of time the user will spend on the video player depends on how long the videos are – longer videos will mean longer uploads and more time spent watching the video. Due to this, the interface should be as responsive as possible to ensure the user can have a fluid and continuous experience with the video player. There is also a possibility that the user may wish to have multitasking features, for example the ability to upload a video and watch another one simultaneously. Finally, it is important that any error messages are caught and sent to the interface in a user-friendly way that allows them to continue their session.
Context
Due to the fact our target audience is outdoor enthusiasts, it is entirely possible that the users wish to open the video player on a mobile phone or another portable device whilst on the go. For this reason, we think it is important to ensure our layout is responsive and our icons/words should be clear and descriptive enough for the user to understand what to do, whilst still being small enough for the user to see on a smaller screen. Perhaps some of the icons could be emitted from the window on mobile sized screens. The social environment in which the videos can be played may vary between solo watching to a large group of people. As a result, it would be good to have features that support both scenarios – perhaps loud volume and full-screen mode for larger groups or more menu options and playback tools for a more comprehensive solo viewing. Regarding support for the program, we do not think a video player is enough of a complex application to warrant any extensive tutorial or any kind of help desk approach, but it may be useful to have a ‘help’ icon in the menu bar to display some frequently asked questions or to explain some key features of the program.
Technology
The inputs to the video player would include the buttons the user clicks, the bars the user scrolls, any drop-down menu navigations, the size of the window that is being used and videos that are taken in as files. The outputs of the video player would include the responsiveness of the user interface, the sound outputted through speakers or headphones as well as the video being played to the user and the changes to the playback based on the changes to certain widgets. It is important that all of the inputs are handled appropriately and used in the most efficient way to ensure both the correct output is displayed and the GUI is as responsive and user-friendly as possible. The program would run on just the one machine and will not normally output to any other device unless that is handled by the user on their own machine. No inputs be taken from any other devices through the program either, however users may choose to connect and upload videos from storage devices to their machine and run them on the video player. The program isn’t always on and will need to be launched and set up by the user. It isn’t a real-time system, nor it is a safety critical system, so the program doesn’t necessarily need to be ultra-quick, but responsiveness is important from a user experience perspective. Finally, the video player will run as a program through an IDE using C++ and Qt libraries for the scope of the project.
Platform
For the time being, we plan to have our app work within an IDE only, running in Qt Creator and developed with C++. We believe this suits the scenarios we have created as well as allowing us to create the best possible application within the scope of the task provided. However, our program and ideas could be implemented into a desktop application in the future quite easily based upon the user interface designs we create. In order to plan for a web-based application using our designs, we would likely have to plan an implementation diagram, amongst other designs techniques, in order to model the server-based network architecture we would need to properly access our application on a browser. Similarly, a mobile application could be designed and created based on what we create if the networking was planned out as well as changing the user interface to suit a much smaller screen. This would involve abstracting the whole design to be much simpler, with smaller icons and displaying in portrait.
Prototype
Our group has decided that the goal of this cycle is to implement some final features that will improve the quality of the video player to a high standard, ready to be finalised. This includes a separate list to favourite videos onto, the addition of keyboard shortcuts with a menu list to explain them, as well as next and previous buttons to quickly move between videos and buttons to allow the user to skip to the start and end of a given video. We also want to replace some of the text with icons. We decided upon implementing the favourites bar because from the previous evaluative interviews we realised that although the delete button was a poor idea, the ability to shorten the playlist and better organise your videos is a feature that people want to see. The shortcuts menu should tell users what keys they can press to do certain things; this will speed up the process of viewing a video if the user knows the shortcuts. The next and previous buttons will allow the user to quickly switch between videos and the addition of the skip buttons means they can go to the start and end of the video much easier. We will also try and add a full screen button into the new design as it is a feature we ideally wanted to include, but temporarily took out after the interviews. Finally, we decided to include icons on some of the buttons rather than text to make it more recognisable to people and make our program open to other languages more easily.
For our final design, we decided to do a drawing using an iPad Pro and a graphics pen using Notes bought from the Apple Store. This means we can create a high-fidelity digital design that can be used for our final evaluation. We thought a higher fidelity design was important for the fourth iteration because we would like as much detail as possible within the final design to get as much insight out of the evaluation as we possibly can. We also did some annotations on the final image to ensure the respondents to our evaluation fully understand what each of the new features are. Attached below is a copy of that image.
From the image you can see how all of the final features should be implemented. On the left-hand side of the image, we have moved the stop button and the play/pause button to go alongside the playback bar as well as putting the new next and previous buttons beneath it. These buttons are padded and are often used together frequently so we decided that it’d be a good idea to place them close by to each other. In the new design we have also moved the volume bar and mute button to be further on the left too. In the scroll area at the bottom, we have now also added in a small heart button alongside the text with the video to enable the user to place videos into the favourites bar. This bar is now on the right-hand side of the video and is a vertical scroll area. Next to each video that is placed in the favourites bar, there will be a small cross which will remove a video from there. Beneath this we placed the new full screen button and the new skip buttons, helping to balance the number of buttons either side of the playback bar. Finally, in the bottom right-hand corner, we have listed the different shortcuts the user can utilise. We are currently unsure of how many hotkeys we will implement.