Design
Contents
SmartUni
SmartPlanner
StudyBuddyMatch
General SmartUni Design
UI/UX Design
When developing a digital product, as in the case of our SmartUni with its SmartPlanner and StudyBuddyMatch, the design process is usually referred to as UX/UI design framework.
UX design stands for “user experience” design and is concerned with the overall feel of the experience that the user has with the product. The goal of UX design is to develop and improve the interaction between the user and the product in order to make it easy, efficient, and relevant.
UI design stands for “user interface” design (where “user interface” refers to the graphical layout of an application) and is thus related to the interaction between the user and a strictly digital product.
The goal of UI design is to make the experience with the product attractive, guiding, and responsive for the user by means of visual and interactive elements of the product interface. Even if the two definitions seem overlapping, UI and UX imply two different, though complementary, design directions: UX design is in charge of determining how the user interface operates, while UI design is tasked with deciding how the user interface will look.
As a consequence, when developing our SmartUni, we first focused on UX design to identify the necessary backbone structures and functionalities, and then we moved to UI design to take care of the aesthetics and visual appearance of the interface.
Design Principles
When designing the base of our website and our mockups, we strived to follow the principles below:
-
Simplicity We tried to follow the principle of simplicity in terms of visual, semantic, and structural clarity. We tried to keep pages fairly simple without sacrificing functionality. We therefore chose an easily readable font and kept the navigation through our website simple and logical. Additionally, we avoided large chunks of text.
-
Color Here, we tried to choose a consistent design and to choose a complementary color palette. Complementary colors make it easy to differentiate between objects and highlight certain elements or areas. Complementary colors can also attract attention and increase overall readability. Using our color palette, we also tried to follow a consistent visual hierarchy. For this, we used primary and secondary colors, but also lighter versions of those colors to ex. show a subordinate element with a lighter version of the primary color used in the element itself as a whole.
-
Consistency Our website should show a consistent look and layout over the different pages so the users feel like they are on one single website and not on a cluster of singular pages. For this, we used the same colors and a consistent layout and elements throughout the site.
-
Mobile Friendly We wanted our website to be usable on varying screen sizes, including mobile phones. Therefore, we designed our website and elements in such a way as to support these different screens and input methods.
Style Guide
In order to have a concrete idea of what our final website would look like, we started our conceptualization phase by creating mock-ups for the different elements as a style guide, using a web service called Figma.
In this guide (see [2]), we defined our main colors, decided on a main font, and created mockups of many other elements to have a reference for the different developers who were involved in this project.
Here, we also defined sizes of elements and spaces and the relevant sizes for the mobile, tablet, and desktop views. This was done in order to achieve a cohesive design in the end product. It further helped the developers to create a resource where they could easily look again at the proposed design of some elements or some colors, which made the implementation of these elements easier and more efficient. The completed guide was a list of pages with HTML-elements, HTML-code, CSS-code and pictures of buttons, textfields, icons, headlines and other elements, which acted as reference material for the later implementation phase.
Grid-Based Layout
We chose to build our pages on the grid system included in bootstrap. Such a grid system can help designers and developers with positioning and organizing elements on a page. Additionally, this system can help with keeping a consistent look not only over different pages, but also over different screen sizes. The grid can also be re-sized based on certain rules. For example, the number of columns might be reduced when the screen is under a certain number of horizontal pixels. This can also help with simplicity, keeping a consistent feel, and helping with mobile-friendliness.
Colors
For the colors, we oriented ourselves on the color theory regarding primary and secondary colors. After a short discussion, we decided on a complementary color pair suggested by one of the team members.
We decided on
as our primary and
as our secondary color.
Additionally, we defined other general colors
(
,
,
,
,
,
),
used for different elements throughout the website. Besides the lighter versions of the primary and secondary colors, we chose these colors as they are easy to distinguish from each other and the primary and secondary colors.
Additionally, we defined state colors (
,
,
),
indicating success, warning and error messages.
Elements and Icons
We used the bootstrap elements as a basis and adjusted them to fit our color scheme and further design criteria. Additionally, we decided before the implementation phase which specific elements, including buttons and forms and different variants of those elements, we wanted to use and how they should react when hovered over or clicked on. We also decided on specific types of cards and illustrations.
For the icons, we used feather icons [5], which is a free, open-source icon pack.
Font
For the font, we decided for Roboto, following the dyslexia font and style guide in this decision [4]. Additionally, we defined the typography hierarchy we wanted to use throughout our website. This is the same font we used in this documentation.
Furthermore, we decided on the color of the text on certain elements. Here, we also followed color theory in respect to the background to make the text as easy to read as possible. The deciding factor here is the contrast between the background and the font color. This gets calculated, for example, using the brightness differential between the two colors. If this differential is above 70%, legibility of the text can be assured.
Conceptualizing Pages
For the conceptualization of the pages, we also used a Figma project to create mockups of the respective pages. In this project (see [3]), we used the elements defined in our style guide to create a visual mockup of the individual pages, which we then implemented later for our site. Using this approach, we had the possibility to discuss and look at a page beforehand without needing to implement it first. In this phase, we also designed the pages in a way that they could be used on a desktop with a mouse and keyboard and also on a mobile device with a smaller touchscreen. This further gave us the possibility to have an exact mock-up to try to recreate, which made the implementation of the specific pages a lot easier.
Design of SmartPlanner
In the following we will describe the designing process of the SmartPlanner in more detail.
Our Design Philosophy
The design phase took place early in the project lifecycle, as it constitutes the stage in which the key features, structures and design specifications of a product are defined in order to be then implemented in the following stages of product development.
For us, the very first and most crucial step of this phase was articulating our design philosophy, i.e. the rationale behind all the decisions and choices that we would make while designing the SmartPlanner.
We conceptualized our design philosophy as a mission statement manifesting the set of principles that establish what our team believes to be a good design for such a product and why. These principles constituted not only the guideline for our design decisions and execution, but also the reference point to validate the coherence of our work during the design review and more broadly throughout the entire development process.
Our Principles
Our design philosophy was based on 5 principles identifying the core values and characteristics that we deemed essential for the success of our product. More in detail, we wanted our SmartPlanner to be:
I. Simple
Simplicity should apply both at the functional (UX design) and structural (UI design) levels. We wanted to provide users with the simplest way to achieve their goals with an interface that was exhaustive but minimal. For this reason, we decided to group all the functionalities and actions that the user can perform within a single layout (either in a daily or a weekly view that the user can select), making all the relevant elements visible and directly modifiable.
Indeed, by using a limited number of navigational options and call-to-action (CTA) buttons, a user can easily:
- Create new tasks or events;
- Visualize, modify, and delete already existing tasks and events that are displayed in the calendar;
- Toggle between the daily and weekly views (and within those views between days and weeks);
- Check and uncheck tasks as completed;
- Move tasks in and out of the calendar;
- Filter the events and tasks to be displayed based on their category;
- Receive suggestions on how to organize their schedule in a SMART way, etc.
II. Consistent
The principle of consistency is crucial for intuitive design because making similar elements look and function in a similar way improves usability and learnability. In addition, having a set of predefined components whose function and visual structure are agreed upon saves a lot of time and effort in the design and implementation phases.
Internal consistency within the SmartPlanner was obtained as a combination of visual (UI) and functional (UX) consistency.
Some design decisions that we made for ensuring visual consistency were:
- Selecting a single library for our icons;
- Standardizing the size and colors of icons having similar functionalities (e.g. bin and pen icons to delete and modify events or tasks in the detailed view);
- Designing different layouts for tasks and events in the calendar;
- Using similar shadowing effects for unselected items (e.g. day/week selector or completed tasks).
Similarly, for functional consistency:
- Buttons with the same icon performing the same action (e.g. bin icon to delete, arrow icon to toggle);
- Clicking on an event or task opens the detailed view for that event/task;
- Clicking on the date (both in the calendar view and when creating a new event) opens the calendar displaying the selected month.
In addition, since the SmartPlanner was developed within the larger SmartUni project, we also wanted to maintain external consistency with the other projects’ components. This need played a decisive role in the design of the task sidebar for example, both in terms of visual structure and in terms of functionalities, as we wanted to be consistent and coherent with the sidebar of the StudyBuddyMatch interface.
III. Efficient
Efficiency is connected to the effective usage of the product after construction. For the SmartPlanner to be efficient, we meant to provide adequate functionalities and necessary structures that allow the users to achieve their goals and satisfy their needs with minimal effort.
We aimed at accomplishing this by creating a structurally simple but operationally rich interface. In fact, a few simple visual elements (calendar, CTA buttons, task sidebar) allow the user to perform a wide range of actions (see I. Simple) with ease and great flexibility (e.g. tasks can be viewed and/or modified by clicking on them in the calendar as well as on the sidebar, the detailed view of an event can be seen by clicking on it on the calendar or displayed in the appointment list by toggling to the daily view, etc.).
IV. Self-Evident
The users should focus on executing the task and not on learning how the SmartPlanner interface works, which is why self-evidence is the fourth principle of our design philosophy. Being self-evident means that the functions and structures should be so obvious and straightforwardly clear to the users that they will not need to spend any time and effort thinking when interacting with the interface.
Self-evidence is closely linked on the one hand to simplicity (I. Simple), in that if the the elements’ structure and function is kept simple it does not need to be explained, and on the other to efficiency (III. Efficient), in that not needing any instruction or guidance increases the chance of making the experience with the interface effective and successful.
We made numerous decisions following this principle. One example is that we labelled buttons to perform specific actions using standard icons and colors for the most common functionalities (e.g. bin to delete, red for warning message before deleting). We also provided concise and clear suggestions for the information to be inserted in input fields in the form of single word titles (e.g. ‘comment’ and ‘location’ for the input boxes when creating an event). Where possible, we further adopted easily recognizable symbols and icons instead of linguistic labels for displayed information (e.g. the exclamation marks for priority level, the hourglass for duration, the checkbox for deadline, the speech balloon for commenting, etc.), and we followed common practice in setting the pointer to change into a cursor to indicate clickable items.
V. Modern
Last but not least, we wanted our SmartPlanner to be aligned with the current style trend in web design. At present, modern design is increasingly heading towards minimalism, which in web design is translated into the enhancement of white space, the employment of simple high-contrast color palettes, and the preference for neat spaces delineated by clean design lines.
To fit into this trend, we designed the visual structure of the SmartPlanner to be as simple and minimal as possible. We used font size and style to create hierarchy and rounded edges to increase visual softness. We developed a full-width design that automatically adapts to the size of the screen and improved visual depth by inserting overlapping elements (e.g. plus button on top of the calendar) and dimmed background effects (e.g. darker background when a popup is open). Finally, in our selection of the color palette, we did not only follow the color gradient trend, but we also took into account psychology of color in the selection of our primary and secondary colors. Thus, neutral gradients of grey were used for the background, soft cool blue for informative sections, and bold warm orange for CTA elements (plus button, new task/event popup, save button, current date and time, etc.).
A 4-Step Design Process
Our design process developed over 4 steps:
1. Research and Description. This first phase of the design process consists of researching and understanding the user’s needs that the product is supposed to meet. Given that the target users for our SmartPlanner application are university students, in this phase we discussed how the SmartPlanner could meet our own needs and necessities in terms of time management, meeting arrangements, schedule organization, and general work-life balance issues in the overall planning of activities.
2. Planning. In this phase we analysed and organized more systematically the information gathered in the previous stage about the user’s needs, breaking them down into smaller goals that can be performed with single actions, thus defining our target user stories. User stories are a widely used tool in software development as they allow, in a short, plain-language explanation, the capture of a simplified description of a software feature from the perspective of the user by describing what value a product feature can bring and why users need a certain functionality. For our user stories, we adopted the typical user story template following the formula:
As a [type of user/who], I want [goal/what] so that [benefit/why].
We extended this formula with additional and more specific information on the visual structures (UI design) and/or functionalities (UX design) to be designed.
For example, we defined our first user story - ‘Creating a new event’ - as follows:
As a student, I want to be able to create a new event including a title, start and end date, location, and short description.
From this story, we identified the following elements that we needed to implement:
- There should be a button to create a new event.
- If the button is pressed, there should be a pop-up that consists of different parts where you can insert/select a title, start and end date, location, and a short description.
- The event should be saveable and show up afterwards, but it should also be possible to exit the pop-up without saving the event.
3. Ideation and Discussion. Once the user stories were defined and conceptualized, we worked, either individually or in pairs, on different design proposals for each user story. This was the phase of UI design, in which the focus was on the graphical layout of the application (selection of colors, icons, font size, positioning and shapes of buttons, layouts, transitions, and generally everything that concerns the visual structure and appearance of the interface).
When one or more mock-up sketches were ready, the designer would make the prototype available for reviewing. We created the designs and shared them for review using Figma.
4. Review. The review process was usually a 2-step process. In the first review phase, which took place asynchronously, the team members who did not work on the design of the user story currently being revised would individually go through the design and leave comments to express doubts or suggest improvements. The designer would then adapt the prototype following the critiques and suggestions (if any) in preparation for the second review phase. In this second phase, which took place synchronously during the weekly team meetings, the entire team (designer included) would discuss the prototype and agree on a finalized version that would then be ready for implementation.
The design process was directional but not linear. It always started at step 1 and flowed in the direction of step 4, but knowledge and information acquired in the later steps of the process did inform repeats of earlier stages, resulting in a highly iterative process. For some user stories, we even realized that the scope of the original user story was too large, necessitating us backtracking to the planning phase and splitting that user story into two smaller ones.
Similarly, sometimes due to observations and criticism raised during the review phase, the design of some user stories had to be entirely rethought. For example, when reviewing the first mock design for the user story in which a user wishes to create a recurring event, we realised that the way the original design was planned did not account for events that repeat every 2/3 weeks (for example). So we went back to the planning phase and reanalysed the types of information that would be needed when setting the repetition of an event in the calendar, and then added an option to personalise the rate of repetitions by inserting a number (e.g. every 2 weeks, every 3 months etc.). Similarly, we noticed that providing an input field to select the start date for the recurring event was unnecessary because the common understanding would be that the date selected above in the form constitutes the start date. Therefore, when reworking the design, we removed this input field and left only the option to select an end date for the recurring event. These changes can be seen in the two pictures below, showing the first design (see Fig. 1) that was discarded and the reworked design (see Fig. 2) that was finally accepted, with the relevant changes circled.
Through this iterative loop we gained continuous feedback on our choices, which allowed us to flexibly adapt and improve our design.
Design Decisions
When developing an application, it is important to first work out and design the various requirements for the components. The design should remain true to the principles developed in the design philosophy.
- Simple
- Consistent
- Efficient
- Self-Evident
- Modern
The design decisions took place iteratively, as described in the design process section. First, the use cases were developed and a design proposal was created, and then these were reviewed by the group.
In the following, the final design decisions of the SmartPlanner are presented and evaluated:
When creating the use cases, we had to keep in mind whom we wanted to target with this application. SmartUni is developed for students, therefore it was easy for us to create the use cases ourselves by checking our schedules and thinking about what would support us in our daily routines as students. We decided that the SmartPlanner should be a calendar that supports students in improving their time management with regard to a healthy work-life balance. For this purpose, we used use cases to elaborate the following requirements:
As a student, I want to
- have an overview over my weekly and daily events
- be able to skip to previous or next days/ weeks
- be able to create, edit and delete events
- edit events to contain certain information like
- title, start and end date and time, location, short description, category
- be able to create a recurring event, so that I don’t have to create the event every time again
- be able to create, edit and delete a task
- a task should contain information as title, description, deadline, priority, duration
- categorize events and tasks in the calendar
- have an AI that helps me automatically place tasks into my calendar for optimal productivity
This resulted in the following requirements and design components:
- Overviews
1.1. Calendar Overviews
1.1.1. Daily
1.1.2. Weekly
1.2. Task Overview - Events
2.1. Creating
2.2. Editing
2.3. Deleting
2.4. Recurring - Tasks
3.1. Creating
3.2. Editing
3.3. Deleting - AI Component
Site Structure
In order to make design specific decisions, we first looked at the as-is state of the webpage.
In Fig. 3, the blue areas represent the settings and navigation bars already taken over from the main SmartUni layout and therefore not usable space for the SmartPlanner. Since we wanted to keep the design simple and minimalistic, we decided to display 3 main components, (1) the user’s settings and options, (2) the calendar, and (3) to-dos displayed as a sidebar. From this main page, all options and features of the SmartPlanner were to be accessible. Since the calendar is the most important component, it should be displayed and visible to the user at all times. Therefore, we decided to create the events and tasks as a pop-up and not as a separate page. Furthermore, the main page of the SmartPlanner is grayed out in this state, but is still visible and thus accessible for the user.
(1) Options
The first components on the SmartPlanner webpage are the selectable options for the calendar (see Fig. 4). While on the left side of the component there are the options and settings related to the current displayed calendar overview, we decided to display the button to switch between the views on the right side. We decided to separate these two areas, since one refers to the current view while the one on the right changes the state.
The current view settings are again divided into the time setting, the category filter, and the smart settings. They are visible as buttons and stand out from the background with the dark gray color scheme.
The first button displays the current date and two arrows to jump to the previous or next weeks (see Fig. 5). When you click on the button, a small calendar opens to get a monthly overview, where the current day is highlighted in color. Next to it, represented by the filter icon, is the category filter. We chose this icon since it is familiar and self-explanatory.
The last selectable option for the current calendar is the Smart component. This is the AI component that is designed to help the user find a suitable place in the calendar for certain tasks. When the user hovers over this icon, they will be shown a tooltip for more information (see Fig. 6). When the smart button is clicked, various selectable options appear in a pop-up that the user can choose to add the tasks to the calendar (see Fig 5).
The design chosen here is based on the SmartUni style guide on how to create certain widgets. It is kept simple so the user will not be distracted by any colors or unnecessary information. While the user has not finished selecting the settings, we made the submit button slightly transparent, such that the user has the visual feedback that there is still information missing.
The last button in the optional settings is for switching between the daily and weekly overviews. The button is kept as simple as possible to not distract the user from the calendar. The currently selected option is underlined and in color, while the other option is grayed out.
(2) Calendar Overviews
We addressed the following user story in the listed ways:
As a student, I want to have an overview over my weekly events.
- The event is shown in a reduced view in the weekly overview. If we click on the event, a pop-up with all the information appears.
- There is a default category with a default color that should be considered in this user story.
- The current day is highlighted in a simple manner.
The most important component of a planner is the actual calendar. A calendar typically shows the days and the respective times of events. For this, we looked at common calendars (such as those used in Google, Apple, and Microsoft applications) for inspiration.
We chose to display the time vertically on the left side and the days as headers of the columns, so users can easily scroll through the time and have all days displayed at all times in the weekly overview (see Fig. 8). We chose to simply and minimalistically highlight the current day and time with the orange of the SmartUni color scheme. Furthermore, the current time is indexed with a thin colored line to provide a visual aid to the user. In the calendar, solid lines represent whole hours, while dashed lines represent half hours. We decided to show half hours as well to give the user more visual anchor points. According to the international standard for the representation of dates and times, ISO 8601 [1], the week starts on Mondays, so we followed this representation. Furthermore, the background for the weekend days - Saturday and Sunday - is in a darker gray than weekdays to emphasize a difference to the working days. Since the main working hours are between 8 a.m to 8 p.m, the default value for the calendar display is set here, to keep it simple and not too crowded.
Another requirement is the display of daily tasks and appointments in the daily overview (see Fig. 9). Here, not only the daily calendar should be displayed, but also a list of appointments. This view also followed the SmartPlanner’s principle of providing the user with a quick, rough overview of what’s coming up on any given day. The appointments’ view and daily view are able to be adjusted in width at the user’s preference.
(3) Task Sidebar
The third component on the SmartPlanner start page is the task sidebar. It is on the right side next to the calendar and can be hidden or folded out. In the hidden state, it can be recognized by the task icon (see Fig. 10). The icon is colored blue and displayed on a dark gray background that contrasts with the actual background to highlight the interaction option. Selecting this icon opens the task overview (see Fig. 11). Here, the tasks are displayed sorted by priority and the user is given an overview of the tasks that are still open. The tasks are grouped according to their priority and can be collapsed, as indicated by the arrows next to the priority tags. All tasks belonging together are summarized in a gray box, which once again clarifies their grouping. The tasks have corresponding color markings on the left side, which display the category in a simple way. If a task is overdue, this is marked with the message “Overdue” written in red.
(4) Pop-Ups
The interactions with tasks and events take place with the help of pop-ups. This way, the user knows at any time where they are and how to get back to the calendar. When a pop-up is opened, the background is grayed out. On the calendar component, an orange plus button is provided to indicate that the user can add something to the calendar (see Fig. 12). With this button, the user can create a task or an event. Although the calendar and task icon are self-explanatory, we have written the respective terms next to them for the sake of clarity and to reduce errors.
Events
Events are a basic functionality that should be displayed in the calendar. Accordingly, the user should be able to interact with them, i.e. create, edit and delete them. While conducting the use cases, we decided that an event should have the following properties:
- title
- start date and time
- end date and time
- location
- comment
- recurring event
Event Creation
In this pop-up a tile design is used where each tile represents an input field (see Fig. 13).
Since the event title is the most important and the only mandatory input for an event, this was highlighted in a light orange. As soon as an event title is entered, the colors from the title and the submit button change from light orange to darker orange to indicate that the event can be saved. We chose to gray out the non-mandatory fields to make it intuitively clear to the user that they are not mandatory to create an event. As soon as an event title is entered, the colors change from light orange to strong orange to clarify that the title is necessary and is now provided and thus the confirm button at the bottom right is activated and the event can be saved. So that the pop-up looks simplistic, we decided to make the recurrence pattern section collapsible and expandable so that the pop-up doesn’t look cluttered and simplistic. If the user wants to use a recurrence pattern, the pop-up can be expanded (see Fig. 14).
Event Details
The details of an event are also displayed in a pop-up (see Fig. 15). All available parameters are displayed with a line separating the title from the information with the respective category color. The details are displayed next to the corresponding icon, which ensures that the pop-up is not too crowded.
Event Deletion
A user gets to the event deletion function when clicking on the trash icon in the event details. To reduce errors, we decided to warn the user before deleting an event. For this purpose, a pop-up appears in the warning color red (see Fig. 16). In the top center, there is also a red trash can, so that the user can see directly what this action does.
Tasks
The task creation is also implemented as a pop-up. The design is similar to the event creation pop-up to keep it consistent. Tasks should have a title, description, deadline, priority, category and duration. The title is the only field where an input of the user is obligatory. In the other fields, default values are already entered, and thus the submit button and the input field are slightly transparent as long as it is not filled in. However, as soon as a task has a title, the color changes, thus intuitively and clearly signaling to the user that the task can be created and saved. In addition, further information can optionally be provided through the input field category and description.
Design of StudyBuddyMatch
Our Design
For designing the seven web pages of the StudyBuddyMatch module, we were indecisive at first and focused more on the functionalities and the matching algorithm. On the one hand, we wanted to deviate a little from the other two modules, but on the other hand, we didn’t want it to be too inconsistent with the overall feel of the site. In the end, we cooperated with the SmartPlanner and Core teams and agreed with their design philosophy on visual (UI) and functional (UX) consistency, minimalism, and simplicity. Yet, we differ in some design decisions, e.g. in our navigation bar.
Color Style Guide
The Core team provided the color theme of blue as the primary and orange as the secondary color, and the font for the whole project website, which the other modules aligned to. The style guide specifies neutral gradients of gray for the background, darker gray for the navigation bar, black for the text, blue for buttons to submit, bold orange for interactive CTA elements, pastel/light orange for more elements to be highlighted and activated, red for error or deletion, and light green for indicating success.
Navigation Bar
The navigation bar of the StudyBuddyMatch module gives an overview of the six pages (five questionnaire pages and one for the actual matching) a user can visit by listing the pages’ icons and titles. It also indicates which page a user is currently on and, on the first pass, how many pages are still to be visited. Further, they are able to explore all questionnaires or go back to change their submissions. The Welcome Page is not included in the navigation bar.
UI
Background Color
First, we colored the navigation bar light orange, as we wanted it to be distinguishable from the gray navigation bars of the other two modules. But as the first usability testers rated it not visually appealing, we changed it to a mixture of light blue and gray, making it more consistent and less distracting in alignment with the other modules, while still being distinct (Fig. 17).
Icons
For the navigation bar icons, we used the collections of Noun Project and Iconscout, taking icons related to the respective page themes of academic interests, communication level, learning styles, course list, partners, and matching. The five questionnaire icons are filled in black for a clear appearance on the gray background, whereas the Matching Page icon is not filled in so it stands out from the rest.
UX
Toggle Function
With the navigation bar, we wanted to give the users the option to collapse it, as it could distract from the page content or might not be needed. Therefore, we implemented a JavaScript function that collapses the sidebar to the standalone icons. It can be collapsed by clicking on the subtle toggle button showing two arrows at the top right of the bar, pointing in the respective direction: right for collapsing, and left for expanding (Fig. 18). For this, we were inspired by the navigation bar appearing on the web development organizational tool GitLab that we were using for this project.
If the users forget what page an icon refers to, they can have the respective questionnaire name displayed below the icon by a mouseover (Fig. 19).
Highlighting
Another JavaScript function that highlights elements serves to illustrate which page a user is currently on. We used the light orange color specified in the Core’s general style guide to highlight pages in the sidebar.
Sequential Appearance of Icons and Text Titles
We wanted to ensure that the users answer all questionnaires completely for matching. For the first time a user visits the StudyBuddyMatch Welcome Page, we decided to let each navigation bar icon and respective questionnaire title appear only after the previous questionnaire was filled in. But later, we judged it as confusing for the users to see only one icon on the bar when they first start filling out the questionnaires. Therefore, we implemented a CSS class that initially only hides the Matching Page icon and title and makes it visible on the condition that all previous questionnaires are submitted (Fig. 20).
State Retention Across Webpage (Re-)Loading
We have also implemented the functionality that our sidebar’s state (i.e. being collapsed or expanded) is remembered when visiting a different page or when the users simply reload the webpage, since this state is not retained by default.
To implement this feature, we first had to decide on one of three different options to store the sidebar’s state, namely localStorage, sessionStorage, and cookies. After reading about the properties and differences between the mentioned storage functions, we decided to go with sessionStorage, which stores the state within a browser tab, meaning that if a user expands the sidebar in tab A and then loads a different page with the sidebar, the sidebar stays expanded. However, if they load a page in tab B, the state of the sidebar there might differ from the state in tab A.
Layout and Input Fields
Django itself does not provide a single method but rather a range of libraries to help with form development, which can be used to style the layout, input fields, and buttons of different pages.
For the form elements on the frontend, i.e. the text fields for user inputs, answer options, and buttons, we used django-crispy-forms support.
Crispy-forms defines the classes Submit and FormHelper that set the order of the helper texts, input fields, and buttons instead of programming the layout template in pure HTML.
Buttons
UI
The colors and rounded corners of the buttons adhere to SmartUni’s general style guide. The primary color bold blue is used for the Next button to submit the input and simultaneously move to the next page. The secondary color orange is used for buttons secondary to the main Next button, e.g. the Start button on the Welcome Page and for inputs to Add, as on the Courses and Grades page (CG). And finally, red is used for Delete buttons (Fig. 21).
UX
Position
To speed users’ answer submissions, we placed the save and delete buttons right beneath the input fields. In earlier versions of the website, we positioned the Next button separately with more space in between on the right side of the page (Fig. 22).
During development, we noticed that having both the initial Submit button of the Core and the Next button is redundant, and that only one button for both actions would be sufficient.
Therefore, we combined the buttons (Fig. 23), simply replacing the Submit label with Next.
Labels of Functionality
To clarify the functionality of the different buttons for the users, they are labeled according to their functionality. The Add button is used to add a course to the user’s course list displayed on the CG page. The Next button is used to move the user to the following page, with an Arrow icon additionally symbolizing the move, and the Delete button is used to erase inputs. The Match me (again)! button is used to trigger calculation of the final matching score. A further text description of a button’s functionality can be accessed via mouseover (Fig. 24).
During development, we replaced the exclamation mark in Next! with the Arrow icon to indicate the function of moving on to the next questionnaire page while simultaneously submitting/saving the answers.
The Match me! button still has the exclamation mark to stress the finalization of submitting all questionnaires so that the matching process can finally start.
Hover Effects
We wanted to make sure that the users are aware of the respective buttons being coupled with more actions. Therefore, the buttons change color as soon as a user moves the cursor over them (Fig. 25).
Toggle Function
Not only our navigation bar, but also some buttons are implemented with a toggle function to have the option to hide or expand further information, ex. on the different learning styles page (Fig. 26) or the course history page (Fig. 27). A toggle is also used to show or hide the user status on the Matching Page (Fig. 28).
Notifications
Our notification messages aim to inform the users of changes in their submissions, such as successfully deleted inputs (Fig. 29), additions to the course history (Fig. 30), and triggers of the matching process (Fig. 31). When we implemented them, we had to make sure that the messages did not overlap with the sidebar and we shortened the sidebar accordingly.
If a user triggers the Next button but has not answered a question on the current questionnaire yet, the text for that question changes from black to red, notifying the user that the field is required (Fig. 32). With free text fields, the border around it turns red (Fig. 33).
Moreover, if a users clicks on the Next button on the last questionnaire of the Partner Preferences page without having submitted all questionnaires, a notification appears to inform the user that entering the study buddy pool is not possible yet (Fig. 34).
Sequential Appearance
If one answer option contradicts another, it will be automatically removed to prevent confusion. On the Partner Preferences questionnaire, for example, a JavaScript function unselects the option for having no preferences if a preference was chosen (Fig. 35).
References
[1] What is the First Day of the Week? https://www.calendarr.com/united-states/first-day-of-the-week/ [last accessed: 23.08.2022]
[2] SmartUni Style Guide https://www.figma.com/file/TO8bkgo0jDSuUBqAnFQrvs/Style-Guidelines [last accessed: 17.09.2022]
[3] SmartUni Design Space https://www.figma.com/file/jvY93PKMZCZeVoA4CEA9nd/Landing-Page?node-id=0%3A1 [last accessed: 17.09.2022]
[4] Dyslexia Font and Style Guide https://www.dyslexia-reading-well.com/dyslexia-font.html [last accessed: 17.09.2022]
[5] Feather v4.29.0 https://feathericons.com/ [last accessed: 17.09.2022]