29
.
04
.
2024
4
.
04
.
2023
Startups
Business
Design

Poltrax design - story of POLTRAX (part 3)

Mateusz Wodyk
Project Manager

Designing a user-friendly and comprehensive layout is a challenging task in general. Designing such a layout for a complex system like Poltrax, which tracks competitors during long hours of sport events and showing their progress in real-time on the map view, is challenging even more. It requires careful consideration of the user's needs, the type of competition your product is about to handle, and the devices on which the system will be used. In this blog post, we will discuss some important factors to keep in mind when designing such a system and UI that we developed for Poltrax – in collaboration with Visux.

image (18).png

Brevity and simplicity

The first important factor is to keep the user interface as simple and intuitive as possible, while – obviously – also providing useful information. It can be tempting to overload the UI with a multitude of options and information, but this can make the UI confounding and unclear. Instead, it is best to focus on the most important information and options that the user will need. Hence, at the beginning refrain from adding various features, like the event replay option or live chat/messages. Focus rather on highlighting the location of competitors using markers on a map. Plus, allow users whenever they need it to obtain relevant information about each competitor displayed on their respective contestant cards. And make all these parts as visible and easy to understand as possible (for example it’s good for better grasping map situations to differentiate between male and female competitors by using different colors for their markers). Unfortunately, when designing a complex tracking system it's easy to lose sight of what the user really needs. Your main goal is to tell the user whether what they are looking at, i.e. the location of the participant's marker on the map, is what they want to look at and whether its state is current or not. In Poltrax, for that purpose we introduced non-transparent and semi-transparent markers to indicate whether displayed location data for a particular competitor is up-to-date or delayed due to lack of internet connection. We strengthen this “message” by adding extra information to the contestant card whenever the location data is not current.

blurred 17.png

Comprehensiveness and flexibility

Another crucial factor is to design a layout that is comprehensive or flexible enough to handle various types of competitions, routes, and competitors. For example, last year Poltrax had to service routes from point A to B, repeated loops of the selected way, as well as routes on which participants can decide during the competition whether they cover a longer or shorter variant of the course planned by the organizers. And a mixture of all these three. And events where there’s no route at all. What’s more, your designed map view probably should be able to present markers for competitors competing in duos, relays/teams, checkpoints, start and finish points, kilometer markers, and more! Even such a comprehensive layout can’t ensure that the system will handle a variety of competition scenarios. There’s always an edge case you haven’t thought about. That’s why the most critical system principles should be design simplicity and flexibility.

blurred 19.png

Responsiveness and versatility

The third factor to keep in mind is to ensure that the layout is responsive and versatile enough to work on different devices and under different conditions. Based on our data around 80% of Poltrax users interact with the system via mobile phone. And most of them are at the competition site. Knowing that, in Poltrax, we designed our layout to be used

  • both in a comfortable static environment (e.g. user's sofa or armchair) and in motion, when the user often chases something or someone outside in difficult, demanding terrain,
  • on very large organizer screens, laptops and mobile phones.

The layout needed to be responsive to work well on smaller screens, but also detailed enough to be useful on larger ones.

mobile blurred 2 - meta - mniejszy mniejszy.png

Contextuality

One important aspect of the layout is making the range of data you collect and show adaptable to various conditions and needs. As an example, we can use the contestant card, which displays relevant information about each competitor, such as their current speed, average speed, the remaining distance to the finish line, and more. We designed the contestant card to be simple and easy to read, with only the most important information displayed prominently. It’s been achieved by customizing the displayed statistics data depending on the type of sport or competition. That way, again, you have better chances to avoid overloading your user.

blurred mobile 1 - mniejszy.png

Accessibility and speed

Another important aspect of the layout is the competitor search system, which allows users to look for specific competitors using a list of competition participants or by inputing name/starting number to query field. We designed this system to be easily accessible on the map view and pre-opened on mobile devices in order to shorten the number of actions that users need to perform to find a given event participant.

blurred mobile start list - mniejszy.png

Providing a sense of competition

Finally, we included a leaderboard that allows users to easily see the order of competitors on the route and their time differences. This information is useful for all the organizers, competitors and their fans, as it helps to make the competition more exciting and engaging. It can also reduce costs for organizers as they no longer have to provide timekeeping gates at many checkpoints during the sport event.

blurred 14.png

Is that all?

In conclusion, designing a layout for a system like Poltrax requires careful consideration of the user's needs, the type of competition, and the devices on which the system will be used. Paradoxically, instead of thinking what to include, the key aspect for creating a layout for a dynamic and compound system is to decide what type of information or feature should be skipped. The layout needs to be comprehensive, but simple enough to avoid user’s information overload. Therefore the final effect has to be flexible, responsive, and versatile to ensure that the system is easy to use and provides valuable information. The devil is in details though so make sure you’re making decisions based on the actual data or broad experience. When you're designing something that is complex, like the above system, try to follow the guidance of a well-thought-out framework like Dave Snowden's Cynefin.

Probe. Sense. And respond.

Mateusz Wodyk
Project Manager

Check my Twitter

Check my Linkedin

Did you like it? 

Sign up To VIsuality newsletter

READ ALSO

LLM Embeddings in Ruby - Paweł Strzałkowski

LLM Embeddings in Ruby

17
.
03
.
2024
Paweł Strzałkowski
Ruby
LLM
Embeddings
ChatGPT
Ollama
Handling Errors in Concurrent Ruby, Michał Łęcicki

Handling Errors in Concurrent Ruby

14
.
11
.
2023
Michał Łęcicki
Ruby
Ruby on Rails
Tutorial
Recap of Friendly.rb 2024 conference

Insights and Inspiration from Friendly.rb: A Ruby Conference Recap

02
.
10
.
2024
Kaja Witek
Conferences
Ruby on Rails

Covering indexes - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby on Rails
Postgresql
Backend
Ula Sołogub - SQL Injection in Ruby on Rails

The Deadly Sins in RoR security - SQL Injection

14
.
11
.
2023
Urszula Sołogub
Backend
Ruby on Rails
Software
Michal - Highlights from Ruby Unconf 2024

Highlights from Ruby Unconf 2024

14
.
11
.
2023
Michał Łęcicki
Conferences
Visuality
Cezary Kłos - Optimizing Cloud Infrastructure by $40 000 Annually

Optimizing Cloud Infrastructure by $40 000 Annually

14
.
11
.
2023
Cezary Kłos
Backend
Ruby on Rails

Smooth Concurrent Updates with Hotwire Stimulus

14
.
11
.
2023
Michał Łęcicki
Hotwire
Ruby on Rails
Software
Tutorial

Freelancers vs Software house

02
.
10
.
2024
Michał Krochecki
Visuality
Business

Table partitioning in Rails, part 2 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
Ruby on Rails

N+1 in Ruby on Rails

14
.
11
.
2023
Katarzyna Melon-Markowska
Ruby on Rails
Ruby
Backend

Turbo Streams and current user

29
.
11
.
2023
Mateusz Bilski
Hotwire
Ruby on Rails
Backend
Frontend

Showing progress of background jobs with Turbo

14
.
11
.
2023
Michał Łęcicki
Ruby on Rails
Ruby
Hotwire
Frontend
Backend

Table partitioning in Rails, part 1 - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend
Ruby on Rails

Table partitioning types - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Backend

Indexing partitioned table - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Backend
Postgresql
SQL Views in Ruby on Rails

SQL views in Ruby on Rails

14
.
11
.
2023
Jan Grela
Backend
Ruby
Ruby on Rails
Postgresql
Design your bathroom in React

Design your bathroom in React

14
.
11
.
2023
Bartosz Bazański
Frontend
React
Lazy Attributes in Ruby - Krzysztof Wawer

Lazy attributes in Ruby

14
.
11
.
2023
Krzysztof Wawer
Ruby
Software

Exporting CSV files using COPY - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Postgresql
Ruby
Ruby on Rails
Michał Łęcicki - From Celluloid to Concurrent Ruby

From Celluloid to Concurrent Ruby: Practical Examples Of Multithreading Calls

14
.
11
.
2023
Michał Łęcicki
Backend
Ruby
Ruby on Rails
Software

Super Slide Me - Game Written in React

14
.
11
.
2023
Antoni Smoliński
Frontend
React
Jarek Kowalewski - ILIKE vs LIKE/LOWER - Postgres Stories

ILIKE vs LIKE/LOWER - Postgres Stories

14
.
11
.
2023
Jarosław Kowalewski
Ruby
Ruby on Rails
Postgresql