The wiki server iGEM provides is a space to document research over the course of our project. It organizes data and notes, attributes credit to researchers and collaborators, and communicates the project in a clear format. The competition guidelines [1] for the wiki are open-ended, giving our team creative space to document our project. After an in-depth exploration of awarded past iGEM wikis, we have developed literary and technical guidelines for wiki design.
Standard academic journals assume a niche understanding of the foundations of their research beforehand, which allows them to focus on methods, data, and results for peers in the field. The wiki must do more than this. Future iGEM teams looking for project ideas, current iGEM teams looking for collaboration, potential sponsors, iGEM judges, and the general public need to be able to access and comprehend the wiki content. Our audience may use a variety of devices and browsers, have an increased likelihood of sensory disabilities, and a range of academic backgrounds.
The public accesses the internet in a variety of different ways. Therefore, adapting the website code to be inclusive to different devices, browsers, and inputs is essential. The most commonly used devices are phones, tablets, and personal computers. Phone screens have a portrait aspect ratio and take touch input. Laptops and desktops usually have landscape-oriented monitors and use mice to click elements. Tablets frequently switch between portrait and landscape, but always use touch.
Due to this, we implemented adaptable styling that changes based on the size of the user’s screen-space, using units such as percent height/width, default font size based on zoom (em & rem), view height (vh) and view width (vw), rather than pixels (px) to position and size elements on the page. These units are relative to aspects of the user’s display. When possible, diagrams, illustrations, logos, and other icons were made in the Scalable Vector Graphic (.svg) format (rather than the common .png or .jpg) to decrease page load time and keep images sharp at all screen resolutions (svg's are made of 'vector' lines & shapes, rather than 'rasterized' pixels). When coding the website itself, Javascript (JS) elements were kept to a minimum (only the given bootstrap.bundle.min.js from the iGEM template's Bootstrap 5 is currently being used), so interactivity is almost entirely coded in the 'less direct' Cascading Style Sheets (CSS) language instead. We opted for CSS solutions to commonly JS-solved problems because many older devices struggle to run intensive javascript, and some browsers can entirely disable it for security reasons (e.g. Tor). When a visitor is using a mouse, clickable elements may be smaller, and hovering the cursor over elements can display tooltips (e.g. glossary reference links & sponsers in the footer), expand images, and navigate pull-down menus (e.g. the main navigation bar). Or when using touch, the wiki adapts by having larger buttons (e.g. the Jump-to-Top button), leaving some hidden elements open, and relying on direct presses to open other elements (e.g. the main navigation bar). All of these features together make our wiki accessible across devices.
An additional component unique to wiki is user engagement. In order to improve accessibility of the wiki, a temporary installation of Google Analytics 4 (GA) allows our team to collect anonymous information about the viewing habits of our visitors. This allows us to gauge the effect of changes made to the wiki that improve accessibility (Figure 1).
Figure 1: Our current viewership mostly originates from the US, but we have also received traffic from China, Egypt, Germany, Netherlands, Hong Kong, Mexico, Austria, Brazil, Canada, Finland, France, India, Iran, Singapore, South Korea, Switzerland, Taiwan, and the United Kingdom.
We’ve found that our wiki visitors use several different internet browsers (Figure 2). With this in mind, we have been careful to use elements and properties that are supported across all major browsers. The wiki has duplicate sections that use alternative frameworks when necessary to display the same result across all browsers, since browsers can use different libraries (e.g. ‘moz’ & ‘webkit’).
Figure 2. Graphed above are the number of users per browser who came to our website before the 10/12/22 wiki freeze.
In the future, we hope to see a continued trend of increased user engagement. Visual multimedia such as videos, diagrams, animations, and visual abstracts helps support a broader audience.
A common complication of diabetes is impaired eyesight resulting from nerve damage, known as diabetic retinopathy [2]. Such nerve damage is correlated with an increased chance of hearing loss [3]. To help members of our target audience with diabetic retinopathy and other forms of sensory impairment, aesthetic and supportive aspects were considered. Illustrations and a color blind friendly palette were made with care to ensure a proper contrast ratio between themselves and elements such as buttons, text, and their backgrounds. Our wiki adheres to the Web Content Accessibility Guidelines 3 (WCAG3) standard, now known as Accessible Perceptual Contrast Algorithm (APCA) [4] [5], which is the newest edition of a widely accepted standard for contrast. For those experiencing complete blindness, screen readers are imperative, which require descriptive image captions (alt="") and embedded ‘aria-’ labels for elements within the website code. The wiki also offers support for individuals with hearing impairments; all videos contain subtitles. Youtube’s subtitle generator creates predicted timings for text on screen based on the audio, making a good transcript to add closed captioning (Figure 3).
Figure 3. An example of the user interface for Youtube's subtitle generator.
At every step of the project, we have taken great effort to make our wiki functional and available for the people we aim to help. We have provided accessibility for a wider audience, improving the potential impact for our project.