How could KTracks look like?

In a series of articles we illustrate the user centered design process from scratch, based on a still missing application in the KDE world: KTracks, an endurance activity tracker. In this part #3 we present mockups of the application.


So far we presented ideas about the user centered development of KTracks, the KDE activity tracker. Learn more about vision, persona and scenario in this blog post. And if you didn’t read the last posting on requirements that are the basis for this mockup you can find it here.

The mockup has been developed based on the KDE HIG, in particular the section about organization.

Command structure

A command is any function performed by the application based on user input. Commands that perform similar functions may be grouped together. The collection of commands and command groups make up the command structure of the application.

KTracks offers only a few globally applicable functions. Therefore the command structure should be treated as simple.

Content structure

The content structure depends on how the underlying content of the application is organized. The content of KDE applications fall into in out of four categories.

A simple command structure allows a content with just

  • a (fix) menu button,
  • a context menu depending on where the user clicks, and
  • a context panel where additional functions are hidden until needed.

In KTracks we have two major aspects:

  • the data handling including import, export, share, browse, filter etc. and
  • the visualization of one or more selected activities via map and diagram.

Special features like access to settings or owner-defined calculation, might be useful from time to time but not always. So the required pattern is the context panel with context menus at the necessary places.

Navigation pattern

Navigation Patterns depend on the structure of the application content. Navigation patterns can be combined with command patterns and content patterns to design the complete layout for your application.

The content of KTracks can be seen as grouped into different activities, which means you have to select the type of activity first. On the other hand both persona do either only one type or want to handle all types at once (and perhaps filter the content). So the content structure is flat.


Mockups are used to create preliminary user interfaces that show the end user what the software will look like without having to build the software or the underlying functionality. Mockups can range from very simple sketches used to show the idea, through realistic bitmaps to give an impression about the visual design, to semi functional user interfaces which proof the interaction concept.

Basic layout of KTracks

Figure 1: Basic layout of KTracks.

On the left hand a list view shows which activities have been collected so far. It is completed by the KDE search pattern, a very flexible way to filter the data. Users can select what columns are shown using the menu button at the right most column, and get more room for details with the vertical splitter if needed. Right hand the selected track is shown on the map, and the collected parameters in the graph below. The current selection is marked to link both diagrams. If more than one activity is selected, the details view should be adopted respectively.

Functions that can be applied to the selected activity are offered via context menu. More general features are hidden behind the context panel (menu button top right). The most relevant function ‘load’ (or ‘import’) has its own button. Whether it loads from a file, directly from a connected device, or via KDE Connect is specified in the dialog.


Would you want to use this tool? Do you miss something? Please join the discussion. Even more welcome are developers. Help us to give birth to KTracks.

0) { foreach ($sd_categories as $category) { array_push ($sd_result,$category->term_id);//<-- geändert von name zu term_id anpassungen nötig!! } } ?>