-
-
Notifications
You must be signed in to change notification settings - Fork 0
Functionality
When talking about each requirement and functionality that have been implemented in this project, I will justify my design and implementation of the functionality with established sources that are leading in web design and development such as Google (with material.io as their design system) and Apple (publishing their Human Interface Guidelines). These are two examples of sources that I have derived inspiration and guidance from, with many more below.
Below are the minimum requirements that were issued for the project:
- Users should be able to browse talks by speaker
- Users should be able to browse talks by session
- Users should be able to browse talks by tag
- Users should be able to mark talks as ‘interesting’ and view an individualised schedule of interesting talks, which should not include more than one talk at any given time
- Users should be able to rate talks and the average rating for each talk from all users should be shown when browsing
Through the brainstorming phase, I identified 3 options that were suitable for the application. The options were as follows:
The first option was to have three dropdown menus, one for speaker, one for session and the third for tags as displayed in this figure. This was ruled out as it contained three primary call to actions and did not implement one primary call to action which is recommended in the user interface guidelines outlined by Google. Google recommends primary and secondary call to actions through the use of color or size for focus. This option was also ruled out as it was not mobile friendly. When scaled down to mobile, the dropdown menus would take up half the screen and lead to users not being able to see the information they would want to immediately. This leads to a bad user experience.
IMAGE HERE
The second option was to have a combination of tabs which the user would be able to click on a top navigation tab and then click on an item that they would want to browse talks by. This was ruled out as it would lead to a clunky user interface where half the screen would be used to find talks by the tag you are searching for. On mobile, this would be an even worse experience as there would be a very small portion of the screen dedicated to displaying valuable information.
IMAGE HERE
The third option was to have a search bar at the top of the display which would handle searching and browsing talks by speaker, session and tag. Although more complicated behind the interface, it would result in a cleaner interface which is less busy and has direct and has a single, clear call to action. Having one primary call to action is a web design standard. It clearly guides the user in the correct path that the user presumably would like to take.
IMAGE HERE
The inspiration for this was the classic Google search engine. Allowing you to search for anything in the world, the search engine has one clear call to action which is unmistakable. All users of the internet are familiar with this clean and easy to understand user interface. For this reason, I have decided to implement a clean user interface which is scalable to mobile as well.
IMAGE HERE
The requirement specified that the user could mark the talk interesting and that no two talks could be scheduled at the same time. To address this requirement, I broke it down into two tasks:
- User can click on a button and add it to a schedule
- A schedule should manage and display talks that the user has marked as interested
For the user to mark a talk as interested, they need to know the details associated with the talk such as the name, speaker, session, tags, time and rating. This information is conveyed in both table and card form, but for this requirements we will be showing the table as the example. As there is so much information to be conveyed, the interested button shows the time on the call to action button. This declutters the view and clearly shows the user that by pressing the button, they are interested in the talk.
IMAGE HERE
When a user clicks on the ‘interested’ button it is added to their schedule and they are redirected to the schedule screen for an instant visual confirmation of the action that they instantiated taking effect on the system. The reason that the button is associated with the time and not any other attribute within the talks is that this allows the user to correlate the talk which the button is a part of and the schedule and time which the talk will be added to when a user presses the button.
To rate a talk, the user must click on the dropdown of a talk and will be presented with a range of 0 to 5, however 0 is not selectable. The 0 is present as a visual indication that the user has not rated the talk and provides a subtle queue for the user to do so. Although this may seem far-fetched that a ‘0’ represents a queue to the user to rate a talk, this is the standard for modern websites. Netflix for example use a star system that displays five outlined stars and when the user hovers over the display, they can select from one to five stars. They do not have the option to select zero stars as this would have no visual feedback that the user has rated the movie at all. This same concept was adopted on the rating of talks.
The dropdown list is also dependent on the operating system. It uses the native dropdown to ensure a user feels at home when using the website as it is natural and they have seen a native dropdown before, thus making the system feel more user-friendly as displayed below.
IMAGE HERE Operating System - Apple Mac
IMAGE HERE
Operating System - Apple iPhone
Understanding that this module would benefit from adding additional functionality, I began to brainstorm. The first thought process was to identify the user of the system and attributes that make this user different from the general public and how this specific application impacted them. Therefore a diagram below identifies the attributes of the user and potentially what the user finds important about the system.
IMAGE HERE
From this brainstorming session, I identified additional functionality that the system had to achieve. Below are a list of all the additional functionality that was implemented in the process:
- Dark Mode
- Cards
- Schedule view
- Schedule Print
- Rating Chart
- Progressive Web Application
These will now be discussed in more detail, showing how the site implemented the functionality and why the implementation of each objective was conducted in the manner it was.
Based on a recent poll released by Hashnode showed that 92% of developers on the site rathered using dark mode over light mode. Apart from being a movement in the developer community, dark mode is much better for eyesight and reduces stress in the eye from bright screens.
IMAGE HERE
For this reason, dark mode was implemented. However instead of having dark mode implemented site-wide, there is a call to the device’s settings that checks to see if the user has dark mode enabled on their device. If they do, the webpage will update and display in the dark mode settings, if not the website will continue in light mode. Although this is useful, I understand that some users may want a light themed operating system and a dark themed website or vice versa, therefore I have provided the option for a user to manually select their theme if they wish with a ‘moon’ icon located in the top right corner of the screen which represents the theme change. This is a standard in websites and native apps on all operating systems.
IMAGE HERE
Cards are essentially bordered division elements. Cards are a standard in web and are an alternative for a table display. The main issues when displaying tables are with mobile. Mobiles aren’t able to fully support a table as there is too much data per row to display all on a single view and therefore needs a horizontal scroll as shown below.
IMAGE HERE
The card functionality came about as an option for users if they did not want to see a table for their data. With images and icons, cards are much more visual and allow a user to see all data clearly with a smaller screen size. Just like dark mode has a check to see if the user prefers dark mode by default, cards have a check to see if the device is mobile. If this is the case, it will set the default view from table to cards as shown below.
IMAGE HERE
The schedule view was originally going to be a table with the details of the talk as shown above but just talks the user has accepted. On reflection, it was decided that this was a bad user experience and did not respect the value of time that was allocated to each talk and the space between talks. For example, the user has added two talks, one at 9am and another at 3pm, if the schedule was in table format just showing a list of talks, the user would have to manually work out how much time they have between talks, however I decided to take inspiration in Apple Calendar and Google Calendar which represents time visually allocating a set height for each hour of the day as shown below.
IMAGE HERE
For this reason, I decided to implement a visual schedule system which provides meaningful feedback with minimal user effort as shown below.
IMAGE HERE
As the website does not implement sessions, there had to be a way that the user was able to have a saved copy of the events they are attending, or else there would be a bad user experience. For this reason, printing functionality has been incorporated in the schedule. This allowed users to print the schedule and save a physical copy so they would have the work they put in to the site last longer than one screen refresh. There was one issue however with having the printing functionality in the schedule. When a user would print in dark mode, the page would print black with white font. This is costly for the user and bad for the environment. To mitigate these costs, when the user clicked the print button, the site would reverse to light mode, print the page and revert back to dark mode. This was the most effective and least costly solution for the user and is shown below.
IMAGE HERE
Users are known for responding better to visual interactions rather than text. For this reason, a ratings chart was implemented so the user was able to see a comparison between all ratings and potentially make a decision on the talk they are attending based on the visual representation in the chart as shown below.
IMAGE HERE
Progressive Web Applications (PWAs) are a new concept as of 2016. PWAs are web apps that work offline, as well as they are downloadable. This means they can work on any operating system and act like a native app whilst only having data stored in cache.
The structure of a PWA is similar to a regular web application, however contains a manifest file for routing and configurations of different operating systems and the PWA also contains a service worker which is responsible for caching relevant files for offline use and handling interactions of installing the app, updating the app and more. PWAs can be used for a variety of scenarios such as downloading fully fledged applications that work on a browser, to hosting live data that would reduce the number of callbacks to the server, which in turn reduces server load and admin costs.
For the purposes of this app, the talk-goer may lose connection whilst watching a talk or entering a tunnel trying to get directions to a talk. The attendee may want an app on their device so they can instantly receive data for their next talk. Whatever the circumstances, it is beneficial to have data be cached on the client for all parties. Although this is the case it is not essential for the web app to be downloaded, however it is a convenience.
As this is the case, the application has implemented the following functionality surrounding PWA:
- The application has cached and registered all html, styling and javascript files that would be necessary for offline regular use
- The application has downloaded the entire database of entries into the browser of the client, ensuring that if the device lost connection and the user refreshed the screen, all data would remain on the device and available to the user.
Caching the website and data has had a huge benefit for myself as the developer. If you look at the charts below, they show metrics of different aspects of the website. Week one of development (which is the dotted lines on the charts) showed a small number of site visits as shown in the downloads section, however had a much larger number of invocations, reads and writes. In comparison, this week (solid blue lines) displayed an average increase of 947.3%, however the invocations, reads and writes are all down 6.1%, 87.4% and 100% respectively as shown below.
IMAGE HERE